During my recent studies, I found a brilliant paper out there, it is called Definition Languages for RESTful Web Services: WADL vs. WSDL 2.0. Eventually you already knew this one, but for me was a novelty that unveiled me the important differences between WADL and WSDL.

Congratulations to the six authors of this, and I hope you also enjoy the reading.

Following my open questions series to Jazoon'08, I will abandon my server roots for a moment and I will visit the the GUI programming - a joy I usually delegate to other people but I must confess that also has it goodies. Preparing for the conference, I am applying an extra effort on my open source Cejug-Classifieds, a J2EE application that uses a JAXWS SOAP WebService as business facade. You can visit our home-page to check the complete information Cejug-Classifieds, but its main components can be illustrated in the collaboration diagram below. I have a EJB J2EE component that encapsulates the business logic, and I have a set of JAXWS web-services that expose the Session Facade methods of the EJB module in format of SOAP messages. The first two components are under development and some features can already be tested through the available functional tests. The problem is we don't have anyone working on the end user GUI - the web-services client - and that's why we decided to visit a GUI Shop.

The GUI Shop

Asking through mailing lists and reading Internet blogs, you can find an uncountable options to produce the front-end of J2EE applications, including different platforms - J2ME, J2SE and J2EE - and different technologies and frameworks on each of these platforms. It is hard to say at first sight what is better, so let's start creating some criteria to evaluate our options. First of all I will reduce the scope of my search to web technologies (Desktop and Mobile technologies deserve another blog entries).

1. Price: I will only check the free stuff since my project is open source.
2. SOAP 1.2 ready: the framework will consume SOAP web-services, so it is naturall to expect some built-in feature to communicate with soap. The minimum version that should be supported is 1.2, but a 2.0 support is a plus.
3. Tooling: the selected technology should allow the automatic build of my web-application, specially using the tools I have at home: scripts like Ant or Maven controlled by the common IDEs like Eclipse and Netbeans.
4. Server friendly: the web technology should be easily deployed in the most common open source servers, like Tomcat, Glassfish and JBoss. Despite the candies offered by the server vendors, I don't want to be locked in a server because they convinced me about their fast development methodologies and proprietary frameworks.

After reading a lot of propaganda about web application development frameworks, I finished with the following candidates:

1. Grails: a very popular framework supported by an enthusiastic community. The programming language is groovy and it gets powered with the usage of some of the large amount of available plugins. It works on top of Hibernate and Spring, so be prepared for a lot of dependencies. Best if consumed with Maven (IMHO). My preliminary attempts to run the helloworld proved the weak support of the groovy language both in Eclipse and Netbeans. I know there are paid plugins that can help, but to pay is not an option - groovy seems to follow that lemma: simple things to solve simple problems.
2. jMaki: Carol McDonald was also visiting the GUI Shop and brought me an impressive introduction to fast web 2.0 development based on jMaki. Good option.
3. JRuby: after few years being promoted as the prospective replacement of Java, Ruby language was ported to JVM and for some strange reason it was not adopted as widely as we expected. Nevertheless, the language is available in our virtual machine and deserves a trial. The promise of very fast development of web applications is very attractive, but I want to verify what it offers beyond CRUD operations.
4. JSF: polemic technology since it pushes the rendering of the view layer to the server side. At first sight I would say it should perform worse than its ultra-light competitors, but due to the good examples (1,2) and excellent documentation on the web, I should include JSF as one of my options.
5. JBoss Seam: I included seam in my shop list because the impressive demos and natural integration of the seam web-applications and j2ee applications. The negative point seem to be a fear about the coupling between the framework and the JBoss server, what matches my server friendly constraint. I need to think better about that, because I found some interesting articles on the Internet showing Boss Seam running on Glassfish (1, 2). So, if we can have the full power of Seam without locking the application in the JBoss container, it is a first class option.
6. JavaFX: the rich-client sector of the GUI Shop is full of colors and music, there is also a big animated banner at the corner that says Applets are back. I should confess that the idea of resurrection of my school-time Applets is a nice dream. So I will include JavaFX and all its open possibilities in my check list. FLEX would be another good option, if the FLEX development tools were not paid :(

Shopping Cart - Checkout

Time to pick up a product and go home to try the new gift. As you can notice above, there is no golden hammer in the web applications market, but as any other buying stuff, you must select one. For today, I will just enumerate my preference and discuss with my Jazoon pals about that :) After the conference I plan to write a new blog entry with my conclusions. If you ask me today, I would bet on JRuby, even more because it comes with a nice free gift: a free online course starting on July :)

Remember: it is an open discussion and not a formal product evaluation, it is based only on my opinion and also on the discussion I read in my mailing lists. If you remember some missed web-framework, please send to me and I will include in the selection list.

More than a community and business event, Jazoon'08 offers you a chance to discuss technology free of pressure. You can meet the top evangelists and share with international developers your technical issues and questions - a pervasive brain storm about the Java platform. Excellent opportunity to validate your ideas on how to do better software - and if they don't survive the community's scrutiny, you can always blame the beers and back home with good learned lessons :).

I have my own set of (Not So) Stupid Questions, and the first one I want to discuss with you is about web-services and EJB3.

Is it a good design to expose EJB3 Session Facade as web-services?

Reading patterns and examples on the Internet, EJB3 + @WebService seem to be a fast and furious way to go straight to SOA with few lines of code and a good container. Despite the simplicity of annotations, I started designing an Open Source Classifieds system based on J2EE technologies and I have some observations about that.

Instead of replicating here all discussions about web-services design and its technology support, I prefer to bring you a few design options and get your feedback live during Jazoon.

1. Web Client -> JAXWS SOAP web-services -> Session Facade -> Domain Model Facade -> @Entities
2. Web Client -> @WebService Session Facade -> Domain Model Facade -> @Entities
3. Web Client -> @WebService Session Facade -> @Entities

Some considerations about the above design options:

• If I use annotations, I am assuming SOAP web-services, right? And what about REST?
• If I do expose my Session Facade directly, how can I change later my interface from SOAP web-service to something else ?
• What about validation and security? My business component should care about data input validation and authorization and authentication?
• Load balance and orchestration. Can I use a web server (Tomcat?) to expose the service interface and a j2ee container to do the business? What about service collaboration? The session beans will have references one to each other?

Using a same class to expose services interface and realizing business use cases seems a bit overlapped to me, but eventually I am missing some point here. It is up to you, see you in Zürich :)

From my last conferences experience, I learned to create a conference schedule divided in topics instead of just going there and selecting the topic of the day. I first collect the list of conference's topics and then I prioritize them by day. For every day, I know the two or three presentation I must go, the ones I want to go, and the ones I would like to go. I also include some community slots in my schedule and, of course, some free slots - to give me a chance to checkout something I've never heard about. It is not a scientific method, but at least it gives me a chance to monitor my conference day-by-day, avoiding myself of missing that fantastic session because I was watching an impressive demo in a commercial booth :)

Jazoon'08 Fish Menu: Glassfish and Web-Services Nowadays I am focused in web-services, specially SOAP web services and Glassfish/Metro technologies, so let's check the Jazoon'08 fish menu:

• Monday, 2008-06-23, 09:00 - 15:00, Arena 7

  GlassFish Community Day: six hours fully dedicated to the latest novelties on Glassfish technologies. Commanded by Jerome Dochez - the Glassfish architect - it is one of the unmissable sessions for any glassfisherman.

• Tuesday, 2008-06-24, 15:00 - 15:50, Arena 5

  SAML: Identity Federation in Practice: you know, strange fishes deserve precautions about how they are prepared. Security is the base of comfort when you try something exotic and it is even better if you know the cooker and from where the fished are coming from. Security and person identification is a key concern in interoperability between web-services, and I am definitely interested about that session.

• Wednesday, 2008-06-25, 11:00 - 11:50, Arena 6

  JAX-RS: The Java API for RESTful Web Services: a small and fast fish served flambé, a kind of spiced web-services. If well prepared, it can offer you a surprisingly experience, and be aware you can eventually becomes addictive to it. Why not?

• Wednesday, 2008-06-25, 11:00 - 11:50, Arena 6

  JAX-RS: The Java API for RESTful Web Services: a small and fast fish served flambéed, a kind of spiced web-services. If well prepared, it can offer you a surprisingly experience, and be aware you can eventually becomes addictive to it. Why not?

• Wednesday, 2008-06-25, 14:00 - 14:50, Arena 9

  Integration Profile for GlassFish v3: in case you swallow a spine of fish, it is better to do a checkup. This session bring us a way to find out where are the dangerous spines of our JEE applications.

• Wednesday, 2008-06-25, 16:30 - 17:20, Arena 6

  Web Services and Transactions: a good dinner ends with bittered bill, and while you taste your wakeup expresso you should pay the bill and finish the transaction. This simple scenario in a restaurant becomes weird if you have the cooker, the waiter and the clients in separate rooms :).

• Thursday, 2008-06-26, 14:00 - 14:50, Arena 9

  Glassfish V2/V3 - the killer appserver for development and production: visit our kitchen - this session introduces a guide tour to the Glassfish server's features. An unmissable session for a new fisherman.

It is just my Glassfish guide for Jazoon'08, I hope we can meet there and share ideas on how to produce better web-services based on Glassfish.

Since it was created, the cejug-classifieds project served as a proof of concept for a lot of technologies. Now it comes back with a new set of SOA technologies.

I plan to post our detailed plans asap, but until I find time to create better documents, I published a collaboration diagram in the cejug-classifieds home page and I also published a WAR file you can run in Glassfish for testing - the deployment descriptor included in the WAR is only ready for Glassfish, and I am looking for a volunteer to adapt it to Tomcat or JBoss :). If you prefer to inspect the code snapshot, you can checkout the complete source code from SVN.

Take the subway and visit us at the Cejug-Classifieds, we are waiting for your best tips about our new plans.

CEJUG is organizing the Caravan Jazoon'08, a group of JUG members interested in to participate of Jazoon'08. Inspired in similar initiatives by SouJava and other groups, this one has a differential: the JUG serves not only as communication channel, but also as a secure source of information about who are attending the conference - and it is a valuable input for conference organizers.

Jazoon'08 is open for business and the goal of the conference administrators is to give fair opportunities for everyone interested in joining the conference, including very low fares for students, discount for JUG members and discount for groups of professionals. One of the main issues of that flexibility is how to control Who is JUG member?. Since the conference is international, it is virtually impossible for the conference organizers to check the information provided by more than two thousand attendees.

The social network strength of Java User Groups

As a JUG leader and also as a professional, I helped Jazoon to organize its first edition in 2007. My task was to provide information about Java community, and put the conference administrators in contact with the community stake holders - not all of them, of course, but I guess I did a good work in helping conference and Java community to get closer to each other. The experience provided me a good feedback on how big conferences are organized and what are the big issues in provide discount vouchers and free passes - basically, the lack of accurate information restricts the ability of conference organizers of thinking about better conditions for the Java community. Jazoon has a very elegant package of benefits for its attendees, but it causes a lot of headache for the organizers, and I can assume this is the same scenario for JavaOne, Javapolis and any other conference with superlative numbers. The good news: JUGs can help conferences to attract more people in a more fair way - JUGs are the local community snapshot, and they are the place you must go if you need information about Java communities all over the world.

How Caravana Jazoon'08 works?

It is simple: we created a home-page, where we publish useful information about traveling to Switzerland, and we also publish the pictures and names of the confirmed attendees. This way, we can identify ourselves, exchange traveling tips and - the most important - guarantee for the conference organizers clear and trustful information about who is asking discount vouchers.

It is our first travel initiative, but we plan to extend it to JavaOne and others. If our group of interested travelers grows up enough, we can start to negotiate with conference organizers, tourism agencies, etc.

* Caravan @ wikipedia

The discussion started in my JUG mailing list, where some members started celebrating the availability of YouTube for Mobile Devices, including remarkable advances of the nowadays gadgets, like the supposedly revolutionary features of IPhone and a lot of other technologies.

The aftermath of the flame produced some insights I would like to share with you, but not before a context quiz:

1. When the keyboard was invented?
2. When the mouse was invented?
3. How frequently you run applications in your cell phone? If not much, why?
4. How many pages you can type in a small device before to hit it in the wall?
5. How many hours - compared to your TV or your computer - you spend using your mobile devices? If not much, why?
6. Which is more expensive in your working place: your computer or your chair?
7. When was the last time you updated or replaced a software?
8. When was the last time you updated or replaced a hardware?
9. Pervasive computing means you to carry everything in your pocket? If not, why you still carrying it?

So, if you start looking around and thinking of what your are using, perhaps you share my perception about the gap between hardware and software. Few more thoughts and you realize the different velocity some technologies are adopted comparing to others, and the obvious commercial side-effects.

One of the key points of our discussion was about powerful tools of mobile devices and the real adoption of such features. No doubt modern cell phones can seduce you with those colored keys, multimedia features and fancy design... but think twice, how frequently you actually use it for something you really need?

The hardware hurts you

A short survey gave us the impression about the most popular features of mobile devices: SMS, GPS and - of course - the phone. We could not identify the adoption of anything much beyond those basic functionalities. Despite all arguments used to justify why the revolutionary features are not being adopted in large scale by end user, I have a strong feeling about the main reason: the hardware is just boring. The hardware hurts you, it destroys your body and your patience, and doesn't matter your expectations about the next cell phone xyz99, it will come with a newer version of the same too small buttons, tiring screen and probably it will be just a replacement of your current walkman. Keyboards? Come on, when was the last time you invest real money in a keyboard? Cheapest seems to be the most successfully brand in the keyboards market. Mouse? Do you really like it? And what about the furniture? Do you really believe the designer/architect who designed your chair spends 12 hours coding every day? eheh, I guess not, the artistic designer is probably more busy thinking about colors and other very important details. Important for sale, I guess :)

Innovation == renovation?

Thinking about the last 30 years (sorry, more than that I should be born again), I can remember real revolutions in movies, image, sound, software. From computer technology, hardware evolved a lot, including astronomical amount of memory we use nowadays and the allucinogenous CPU velocity. But about design, it is a bit hard to defend. While we wait for the Quantum Physics to offer us another computer model, we seem to be locked in old paradigms. I would like not to go so far in science because it is just a blog, but returning to the subject of our mundane gadgets I guess we are waiting too long for better devices, aren't we?

I must confess the discussion was quite interesting and I pretty sure about its controversial side-effects, but instead of bothering you more about my insights, I prefer to leave these ideas open for discussion. Perhaps you can show me other perspective, something to convince me to give a second chance to try the cell phone.

A wish for my next cell phone

I want my cell phone to read my email messages for me, and I want to have a chance to speak the responses or new messages while the phone converts the sound in text messages.

It seems better than another five different ways to manipulate the renewed versions of the same icons through the same buttons :)

Pictures copied from Wikipedia for non-commercial purposes ;)

After few trials, I was forced to abandon NetBeans due to the absence of support for JUnit 4.1, but after the release of the newest NetBeans, I got JUnit and several other interesting features that put me back on track about offering the community a more comfortable development environment. Today, you can checkout Footprint Project both in Eclipse and NetBeans IDE without loss of productivity or any need of special configuration tricks.

And what about configuration files? The configuration files of both platforms are committed under version control and I noticed they are ignored by the other platform. Eclipse shows an alert in the problems list, and the internal file used by NetBeans for automatic updating of ANT tasks is also marked as problem, but it has no impact on the development environment and the project normally compiles, runs and executes tests in both IDEs. What is the big deal on using two IDEs in a same project? In commercial projects, probably the best strategy is to bet in a unique platform and find a way to extract the best that IDE can give you, eventually including some platform specific tricks in your configuration to enhance your productivity. But technology is not static and sometimes it is nice to keep an open mind about what is going on in the open source community. I will not promote here another tiring comparison of IDE flame, we have enough of that in every Java mailing list, but I'd rather to post some positive thoughts from my personal experience: NetBeans offers automatic updating of ANT tasks if you change artifacts and/or structure of your project. For example, if you include a new folder, NetBeans add its reference in your ANT tasks definition. The Sun IDE also offers an impressive i18n support with features to refactor old projects in order to verify missed constants. On the other side, Eclipse is still the most comfortable Java editor available, fast and reliable. Both IDEs offer a very good Subversion support and the most common development features without great differences - despite personal opinions, of course ;) That's it for now, I am very happy with the recent advances of NetBeans IDE and I am for a long time fan of Eclipse, so what I suggest you to do is to try both IDEs and find out what best fits your project requirements. Afterwards, the best comparison available continues to be your own experience.

PUJ - a code competition template

In this link you can find the translated rules of PUJ (Prêmio Universitário Java), a competition organized by CEJUG at the end of 2007. The competition inspiration states as:

	To offer the local market a chance to evaluate what is produced	in Java classes
	of universities, allowing companies and universities to share the same goal of 
	helping people and market to become more productive.

The idea is to promote the collaboration between local people toward a better society, identifying shared values in all layers of the IT productivity chain, including students, teachers and professionals. Apparently obvious at first sight, this idea proved not so simple to be implemented in the real world. CEJUG held the first edition of PUJ at the end of 2007, and some very interesting feedback was collected. Some of those experiences, including the polemic points are discussed below.

1. Can I reuse the PUJ format in my local JUG or company?

   Please copy the PUJ idea, be my guest to reuse the proposed rules. PUJ was invented to help people to promote Java and to unify Java people around the idea of quality software development. The competition format and its former ideas are not new, and you probably can enumerate a large set of similar initiatives, but PUJ is distributed without authorship in a hope to be adopted by the largest number of people. If you have a JUG, please do your own PUJ - you can change the name, and if you like it we only ask you to quote CEJUG somewhere ;)

2. Everyone is responsible by the quality of the education process.

   A beautiful side-effect of PUJ is to distribute the idea quality on all partners of the educational process: students, professors and companies. When a teacher knows his class statements will go public, he becomes naturally concerned about the quality of the statements. Other good side-effect is the comparison between several statements done by students and the market professionals, avoiding bad teachers to continue to destroy the future of the young talents. Basic posting: bad professionals, bad teachers and bad students do not find space to hide under PUJ - I invite you to think about that.

3. What kind of statement is used in PUJ?

   All kind of statement, the submissions of PUJ should include works already done - the competition itself does not provide any statement. The goal of PUJ is to ask IT professionals to evaluate what is being produced inside classrooms, and it does not make sense to restrict or to force a specific type of work to be evaluated. Advanced mathematics and tic-tac-toe programs are supposed to be eligible to participate in the same level. Apparently unfair, we detected some interesting points about that:

   • The number of submitted works was much lower than we expected. It unveiled a simple fact that graduation students are not producing much Java code or they are producing low quality works. We didn't received the advanced mathematics works as well we didn't received the tic-tac-toe ones :) The small number of submission suggests us to promote PUJ and forces the universities to explain why their students are not competing - since the universities are always doing marketing about their high-quality classes, where is this quality?

   • The local universities share a very similar curriculum. The subjects and type of works are the same. Part of this similarity comes from the government regulation of education, and part comes from the lack of creativity of the teachers, who prefer to copy the old statements instead of adapting it to their pupils reality.

   • The code of students from different universities was much less different than we expected. In a first moment, the famous universities were considered virtual champions and we expected their students will annihilate the other ones by superior education. The reality exposed a close ability between students from several different universities. We don't have a stable opinion about the causes, but we believe it is due to the fact that academic recognition comes from scientific research and not from technical education.

4. What are the evaluation criteria?

   This is a recurrent question, and it seems locked in the traditional programming competition formats, where the rules are settled as static criteria from a point of view of a unique company or group of persons. In the real world, the idea of quality is not limited to a tabular enumeration of criteria, and the common sense about what is good or not seems to be more a natural perception about quality than cold numbers or technical arguments. The only criterion suggested by PUJ to the evaluators was: Classify the quality of the students work using your own point of view.

5. Does it make sense to allow people to judge something without establishing clear rules on how to do that?

   Simple answer: YES, it makes absolute sense to ask people about the quality of something even if we know some of them may not have solid background to understand or even classify it - because this is what happens in the real world. How many times did you notice that amazing idea failing as commercial product?

   In case of PUJ, it is even more fair because the evaluators are participating in the competition themselves - students, teachers and IT professionals looking for a shared mind about what is being produced inside classrooms. The trick to minimize deviations is to consider the different level of maturity of the participants - we adopted weights based on the role each evaluator play in the local market: students opinion is weaker than senior professionals opinion, but all opinions are contributing to the final grade of the works. The more people you include in this peer-review process the more fair it becomes. In the first edition of PUJ, we defined the following opinion weights:

   • IT professionals: grade x 7
   • Instructors: grade x 4
   • Students: grade x 1

6. Why not to use technologies categories?

   This is an open decision, and in the first edition of the prize we asked people to focus more on the quality of the implemented solution than in its underneath technologies. We believe it reflects the IT market, because no client ask you to do a software with technology A or B, clients are looking for solutions to their problems. One nice side-effect of the first edition of PUJ was to discuss the epistemic view of the novice developers: Students tend to focus on technologies instead of focus on the solution of problems.

   To contribute to dismiss this problem, PUJ asked the students to compete in the same arena with their preferred weapons ;). The first reaction to this idea was a lot of questions like How can I apply my Swing application against the other student's Ajax application ? This reflected the students' fetish about hype technologies instead of the quality of solutions. Students tend to classify something better even before to look at it, just because they know certain technology was used - and it is nocive to their own carriers. The goal here is to put experimented professionals and students evaluating the same code and to give the students a chance to think about why some works are better than others even using a supposedly worse technology?

   Special remark: it worked fine in the first edition and the controversial discussion about that continue to echo in our JUG lists. We believe this was one of the best contribution of PUJ to the approximation of academic reality to the local market expectations. The PUJ competition does not aim to evaluate technologies, the goal is to evaluate the quality of students' works - in a perfect scenario, people learn how to think about the problems and their solutions instead of trying to force the adaptation of the problems to their preferred technologies. Of course the grades were contaminated with the hype but we believe with time this strategy will help to reduce the gap between classrooms and development centers.

And the winner is...

First edition of PUJ was experimental, but proved its values with some good competitors, besides going under the spotlight of Ceará IT market. The local results are more important in local community, but I would like to use this space to honor the great winner of the 1st PUJ: Alexandre Pinheiro e Silva, student of UNIFOR University. He produced a work titled "Virtual Video Rental Store", a web application using Struts and EJB3 technologies. The second place was granted to Francisco de Assis Ribeiro Junior, student of FIC Faculty. He produced a work about process communication, a Peer to Peer application based on Sockets. Both works with source code and comments (only in Portugese) are available here.

That's it, we confirmed the second edition of PUJ to the first semester of 2008, and we expect to evolve from the original model to something that can help universities and companies to establish their shared values. We believe one of the prime goals of a JUG is to promote Java, and to put students to compete is a good action in this sense.

If you have ideas on how to improve the PUJ format, or if you identify problems in our rules, please comment in the form below.

HAPPY NEW YEAR, WELCOME JAVA 2008

Click here to check the conference page

The Jazoon'08 conference invites you to share your experience and knowledge in the following categories:

• Technical short talks (20' incl. Q&A) within the technical program
  (Submission deadline 2007-12-31)
• Technical long talks (50' incl. Q&A) within the technical program
  (Submission deadline 2007-12-31)
• Jazoon Labs (2 consecutive slots of 50' with a break of 10' in between)
  (Submission deadline 2007-12-31)
• Birds-of-a-feather sessions (90')
  (Online Submission deadline 2008-06-15)

All abstracts have to be submitted in English using the submission forms.

Well, you actually cannot escape from programming, but instead of digging details of the Footprint library, you can use Dependency Injection to minimize your effort.

How Footprint publishes the signed PDF files?

First of all, a brief explanation on how Footprint generates documents - shown in the diagram below:

Using Constructor Injection to modify the behavior of the Exporter

The core interface of Footprint is the Exporter, which describe the following set of methods:

	package net.java.dev.footprint.exporter;
	public interface Exporter {
		String DEFAULT_SIGNED_PDF_EXPORTER = "net.java.dev.footprint.exporter.pdf.SignedPdfExporter";
		String export(File outputFolder) throws Exception;
		String export(File outputFolder, Map fields) throws Exception;
		String export(String filename, Map fields) throws Exception;
	}

Following the Dependency Injection pattern proposed by Martin Fowler, the Footprint uses Construction Injection to allow different implementations of the Exporter interface. In order to produce different documents - other than signed PDF files - or to change the way the documents are generated, you must do:

1. Create a class that realize the Exporter interface:
public class MyRtfExporter implements net.java.dev.footprint.exporter.Exporter
2. Pass an instance of this class to the constructor of the publisher:
FootprintPublisher rtfPublisher = new JdbcPublisher(new MyRtfExporter(), config, logger);

That's it. Dependency Injection is an overhyped term used to promote the idea of an advanced usage of Design Patterns, but simply posting: dependency injection is a realization of an interface passed as parameter of a constructor or a method.. The so called inversion of control means you are creating a program based on abstract concepts - the interfaces - but the concrete way your program will produce its results will come from outside the code: it will be injected. Your code will not control the way the interfaces will be realized, the user of your code will do that ;)

Final tips:

• Footprint uses reflection to load the instances of the injected implementations.
• Don't forgett to include your custom implementations of Exporter in the same classpath of the footprint-core.jar.
• Footprint Project is licensed under LGPL, and the full source code is available at the SVN repository.

java.util.Properties	JAXB
The configuration files:
text=word primitive=2 anobj.name=test anobj.integer=3	<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <myConfig text="word" primitive="2" >    <my.obj name="test" integer="3"/> </myConfig>
The code required for loading the configuration in the memory:
// Read properties file. Properties properties = new Properties(); properties.load(new FileInputStream("filename.properties"));	// Unmarshal the properties XML file into a Java Object JAXBContext jc = JAXBContext.newInstance( AbstractJaxbFootprintStream.FOOTPRINT_CONTEXT, this.getClass() .getClassLoader()); Unmarshaller unmarshaller = jc.createUnmarshaller(); unmarshaller.setEventHandler(new FootprintConfigValidationHandler()); unmarshaller.setListener(listener); SchemaFactory sf = SchemaFactory .newInstance(javax.xml.XMLConstants.W3C_XML_SCHEMA_NS_URI); Schema schema = sf.newSchema(getClass().getClassLoader().getResource( "config.xsd")); unmarshaller.setSchema(schema); MyConfig properties = (JAXBElement) unmarshaller .unmarshal(new FileInputStream("filename.xml")).getValue();
Reading the configuration values:
// A String: String text = properties.getProperties("text"); // Other primitive values: int number = Integer.parseInt(properties.getProperties("primitive")); // An object: String name = properties.getProperties("anobject.name"); int integer = properties.getProperties("anobject.integer"); Object yourObj = new YourObj(name, integer);	// A String: String text = properties.getText(); // Other primitive values: int number = properties.getPrimitive(); // An object: Object yourObj = properties.getMyObject();
My arguments for adopting JAXB instead of java.util.Properties:
The red text are hard-codes occurrences. Even if you create constants, you continue with the issue to remembers its names, and if you commit a typo or other minor mistake, nor the IDE neither the compiler will help you to avoid problems under production. Other issue is about creating complex types: you are responsible for converting the key/values pairs in Java Objects in case of complex types. You need to check if the attributes required for creating the object are present and also its types and/or if the value associated to the key is not null. Property files cannot be checked against its syntax or contents, since it is just a plain text file. Complex types should be simulated by a set of key/value pairs and later converted in a non-bullet-proof code. If the application requires different set of properties, it should rely on several different files. These files are independent and you must create a custom code to manage it in your application.	No hard-codes, you don't need to check which string map to a certain object. No types conversion by code - the methods you use to retrieve the values from the Configuration Object are defined with the correct type. There is no risk of deploying typos or minor mistakes since the compiler and the IDE will notify your mstakes on the fly. XML Property files can be verified against its Schema definition. Support for complex types. Different set of properties can be modeled in a unique file, using nested elements. Even if you need to use different XML properties files, you can import files in a master definition, creating a formal relationship between them.

* The title of this blog is an intentional reference to this 4 years old article.

1. How to check if all key/values are really present in the properties file?
2. How to check if the type of the values are consistent with the types required by the application?
3. How to represent complex types (nested properties)? For example: I have a property that is a set of properties.
4. How to represent values that are not Java primitive types?

Special remind: properties loading using the java API just reads the key/values pair in the memory , it doesn't check its consistency or any data structure related to the configuration. And more: unfortunately the Properties class is locked in the old Properties DTD and it doesn't support nested structures or complex types. It also provides a XML validation mechanism, but it is really too simple to be useful in more complex scenarios - like the one I present below.

A real world example where java.util.Properties seems not to be enough

My need for a better Properties loading mechanism started when I coded the Footprint project - Footprint is a signed PDF generator that requires three distinct set of Properties:

1. The JDBC Driver Properties: required by java.sql.DriverManager#getConnection
2. A mapping between the name of the fields in the PDF template and the name of the column names in the database.
3. The general properties used to configure the system (number of threads, resources directories, etc.).

My prime code was based on three different files, and I also thought of creating a unique properties file referring the other ones or adopting some pre-defined prefixes/sufixes in order to identify the different set of properties - like jdbc.prop1=value. After some analysis it became clear my system required a more sophisticated configuration mechanism than a collection of key/value pairs of strings. It requires nested structures and better yet if it can have validation of its configuration data. Natural conclusion: these requirements can be easily achieved with an XML file. After deciding to use XML, I evaluated some options, including different XML frameworks and also the usage of XML with the Java API. I also checked the new features of JAXB 2.0, and the fact it is already distributed with the JRE 1.6 convinced me that JAXB is a first class configuration binder. The figure below summarizes my observations about property files versus XML:

Option #1: several Properties	Option #2: XML file converted in Configuration Object through JAXB
Good: Plain text file Easy visualization of key/values pairs Simple code for reading the properties Default Java API - required classes are distributed as part of JRE (since 1.2) Bad: Several files to manage Weak validation of files structure and contents Text editors or IDEs don't help to identify problems String + primitive types representation only Error prone - it is very hard to visualize missing data Custom binder - it requires a custom code to convert String values in Java Objects Inclusion of new key/pair on demand - hard to control the mess in big teams	Good: Plain text file Only 1 file to manage Configuration data defined in a model Validation support by default using the XML Schema Configuration versioning Data types and values range configurable in the model Any Java type supported Default Java API - required classes are distributed as part of JRE (since 1.6) Full support from IDEs in editing time (highlight, validation and auto-complete) Missing data never happens Automatic binding between the configuration values in Java Objects Inclusion of new properties depends on model changing - more easy to control the mess in big teams - just keep the model locked ;) Bad: Difficulty in visualizing the information Any new configuration value impacts in a model changing

Implemented solution: binding XML properties to Configuration Object through JAXB 2.0

The full source code I used to implement my JAXB based properties mechanism is available at the Footprint SVN repository - including the ANT task required to create the XML<->Object binder using XJC. I strongly recommend you to download the footprint source code and try it a bit before checking my conclusions at the end of this blog. Inspecting the code you will start seeing how clean is the application regarding to its configuration properties. I don't have hard-coded String representing the configuration acronyms, and I don't need to verify if the values in the properties are consistent with the values required by the code, it is implicit since we are calling the methods of the Configuration Object that are homonymous to the properties names. Other comfortable feature: if I modify the XML schema or try to change the code in a way both sides become inconsistent, the IDE will notify the problem, avoiding me to crash my own code - the code will not compile before the classes and the properties model become consistent to each other, even under that stressful deadline :)

First step: you first need to create a XML Schema, and then use an ANT task to generate the XML<->Object binder classes, like the one below:

	<taskdef name="xjc" classname="com.sun.tools.xjc.XJCTask">
		<classpath refid="classpath.base" />
	</taskdef>
	
	<target name="compileschema">
		<echo message="Compiling the Curriculum XML Schema..." />
		<mkdir dir="${jaxb.classes.dir}" />
		<xjc schema="${schema}" extension="true"
			classpath="${build.dir.classes}" target="${generated.dir}"
			package="${jaxb.bindingclasses.package}">
			<produces dir="${jaxb.classes.dir}" includes="**/*.java" />
		</xjc>
		<javac srcdir="${generated.dir}" destdir="${generated.dir}"
			debug="off" source="1.5" />
		<jar destfile="lib/footprint-config.jar" basedir="${generated.dir}"
			excludes="**/*.java" />
		<delete dir="${generated.dir}" />
	</target>

Before discussing the pros and cons of the JAXB adoption, let me show some code fragments. What we need to do is to load and to use the configuration properties, what is quite easy with the newest version of JAXB. The validation of the XML against its schema is automatic, but I can also implement a finer verification of the properties data using the Event Callbacks mechanism provided by JAXB.

1. A code for reading the XML properties file:

   	@SuppressWarnings("unchecked")
   	public JAXBElement read(InputStreamReader inputStream)
   			throws Exception {
   		JAXBContext jc = JAXBContext.newInstance(
   				AbstractJaxbFootprintStream.FOOTPRINT_CONTEXT, this.getClass()
   						.getClassLoader());
   
   		Unmarshaller unmarshaller = jc.createUnmarshaller();
   		unmarshaller.setEventHandler(new FootprintConfigValidationHandler());
   		unmarshaller.setListener(listener);
   		SchemaFactory sf = SchemaFactory
   				.newInstance(javax.xml.XMLConstants.W3C_XML_SCHEMA_NS_URI);
   		Schema schema = sf.newSchema(getClass().getClassLoader().getResource(
   				AbstractJaxbFootprintStream.SCHEMA_FILE));
   		unmarshaller.setSchema(schema);
   
   		JAXBElement footprintProperties = (JAXBElement) unmarshaller
   				.unmarshal(inputStream);
   		return footprintProperties;
   		// That's it! From this point I have a Java Object I use to retrieve the configuration values
   	}
   	

2. After binding the properties to Java Object, I can manipulate its attributes as any other class:

   	private void DemoMethod(FootprintProperties properties) {
   		ConfigEmail email = config.getEmail();
   		setMsgFrom(email.getMsgFrom()); // GOODBYE hard-coded strings like prop.get("msg.from");
   	}
   

3. An optional Unmarshal Event Callbacks, to check what is being read. Observe in the code below that I can inspect every element of my configuration, which means I can stop the application loading if I detect something inconsistent. I am using this listener also to log what is being loaded. And since I have a model, I know what any fragment of my configuration file is about and I can do extra verification on the config values. Eventually I can also modify the created Object based on custom requirements.

   	@Override
   	public void afterUnmarshal(Object target, Object parent) {
   		if (target instanceof ConfigEmail) {
   			validateEmailData((ConfigEmail) target);
   		}
   		...
   	}
   		
   	// Observe I don't need to check if the msgTo attribute is present or not
   	// in my property file, the model guarantee that.
   	private void validateEmailData(ConfigEmail email) {
   		String msgFrom = email.getMsgFrom();
   		Pattern p = Pattern.compile(".+@.+\\.[a-z]+");
   		Matcher m = p.matcher(msgFrom);
   		boolean matchFound = m.matches();
   		if (!matchFound) {
   			severe(FootprintConfigUnmarshallerListener.I18N_KEY_EMAIL_MALLFORMED,
   				new String[] { msgFrom });
   		}
   	}

Conclusions

The implemented code works fine, and despite I didn't stressed too much the tests, I have some observations:

1. The loading performance is good, since a regular configuration file is never more than hundreds of values.
2. Memory impact: large sets of configuration can cause an explosion of Objects in the memory, and that is a good thing to keep in mind: each element of the XML will instantiate a different Object.
3. The complexity of the reading/writing algorithm is similar do the one required by the java.util.Properties, and after creating it once you can reuse it later.
4. The validation and verification of the configuration data are sound and robust processes - much more elegant and safe than using properties files.
5. Open the configuration example XML in your preferred IDE, and you will notice the helpful support available there, including highlight and auto-complete features.
6. Think about the natural match between the XML structure and the beans editors code out there. It is quite easy to create a GUI that presents to the user a tree with all configuration elements and its respective editors. I started a Swing prototype here, but it is still a pending task. Eventually I will use the NetBeans platform, that gives me a wonderful beans editor support, or even try JavaFX to produce the configuration editor GUI.

A polemic topic is about the large amount of Objects loaded in memory, what is controversial if you consider what happens when you load values using java.util.Properties. The properties are loaded as Strings, what in the worst case means one String object to each value. Even considering Strings are lightweight objects compared to complex types, all Strings will be used to instantiate an Object at some part of your code. One can suggest JAXB is much heavier since it loads all objects at once, while properties being used by demand will rarely cause all objects being loaded together. I agree in terms, but I think JAXB provides a better productivity - reducing the chances of mistakes and facilitating the verification of the configuration and the code. Imagine a developer using auto-complete for loading the properties, instead of checking constants somewhere or including weird hard-coded String all over the code. It is up to you to think about that.

My overall feeling about using JAXB instead of Properties is very good, I am feeling much more confident to code based on Objects than based on collection of Strings. At the end, both approaches are quite similar in terms of logic, but since I am an Object Oriented developer, I prefer to manipulate objects than lists of values - the old fashion procedural approach.

After a long vacation, I finally had time to release the first stable release of Footprint :). The project is new and should evolve to something more sophisticated in the next few months. For now, we are proud to provide the community a simple tool to enhance the quality of JUG events or perhaps bigger or more commercial events. I hope you follow our Footprint.

* The project's license is LGPL and the full source code is available at the SVN repository.

The Footprint project

As explained in my last blog about the Footprint, the aim of the project is to provide an easy way of delivering certificates to JUG meetings attendants. The basic user story is the following:

1. The JUG promotes an event.
2. During the event, a JUG representative collects the name and email of the participants.
3. After the event, all participants receive a certificate of presence - signed PDF file - through email.
4. The generated certificates can be validated through the public key of the JUG, published in the JUG web site.

How it works?

The algorithm of footprint:

1. Reads an XML config file, and uses JAXB to construct an Object representation of the configuration. The configuration file contains several definitions, such as JDBC connection, PDF template and keystore details.
2. Reads the PDF template, previously created with OpenOffice or other PDF generator tool.
3. Access the JDBC connection to read the JUG members data. For each addressee:
   1. Fill the PDF template with the member data (name, address, etc.)
   2. Generate a new PDF file with the member information.
   3. Sign the new PDF
   4. Send the new file by email to the addressee

The security part of the project is based on the Bouncy Castle's library, and all PDF manipulation is done with the fantastic iText library. Other basic features are the logging over all operations and the internationalization of all classes.

How to run the example?

The release contains a README.txt file with brief instruction on how to start using Footprint, but in short you must:

1. download the release and extract it in your computer.
2. Edit the file resources/configExample.xml and change the user and password of the SMTP server:

   <email smtp.user="EMAIL_ACCOUNT_LOGIN" smtp.password="EMAIL_ACCOUNT_PASSWORD" msg.from="EMAIL_ACCOUNT_LOGIN" smtp.transfer.protocol="smtp"
   	smtp.star.ttls.enable="true" smtp.host="SMTP_HOST" smtp.content.type="text/plain"
   	smtp.auth="true" socks.proxy.port="" socks.proxy.host=""
   	msg.subject="Footprint Certificate - DEMO"
   	msg.body="You can write a message body here.. or customize it through the code, check the demo file..." />
    />
   

   The example comes pre-configured to access the gmail server, but you can change it to any SMTP server. You can also configure the proxy information in case you are behind a firewall. You can also try a first time without configuring the SMTP settings, it will generate the signed PDF without sending it through email.
3. Edit the file demo.csv in order to include an email address you can verify later :). You can include several new lines in this file in order to observe the system generating multiple PDFs.
4. Open a console and run the following command:

   java -cp .;lib\bcprov-jdk16-136.jar;lib\csvjdbc.jar;lib\footprint-config.jar;lib\footprint-core.jar;lib\itext-2.0.2.jar;lib\mail.jar FootprintDemo

That's it - if it fails for any reason, please don't hesitate to send me an email with the failure description.

How to change the configuration file?

Documentation is an issue by design of our project. Since we don't have many collaborators, we always prioritize the implementation (code first). But you can check the configuration schema, and if you have doubts about its structure, please leave a comment below this page.