Videa z únorového setkání CZJUGu jsou k dispozici ke stažení. Jen pro připomenutí: jednalo se o monotematicky zaměřené setkání věnované technologii JavaFX.

Úvodní prezentace Honzy Štěrby a Juraje Švece z pražského vývojového centra společnosti SUN Microsystems byla přímo nabitá demonstracemi předvádějícími jednotlivé funkce JavaFX.

Michal Škvor pak navázal předvedením nástrojů potřebných pro vývoj. Zajímavá byla ukázka podpory JavaFX v nástrojích firmy Adobe.

Setkání bylo zakončeno poměrně dlouhou diskuzí, kde prezentátoři nejen odpovídali na dotazy, ale předvedli další dema.

Jednotlivé záznamy jsou přístupné na následujících adresách:

• http://mediacast.sun.com/users/jakub.podlesak/media/CZJUG2009.02-JavaFX-talk1/details
• http://mediacast.sun.com/users/jakub.podlesak/media/CZJUG2009.02-JavaFX-talk2/details
• http://mediacast.sun.com/users/jakub.podlesak/media/CZJUG2009.02-JavaFX-QA/details

Slajdy jsou zde a zde. I když díky množství demonstrací platí, že kdo neviděl video, slajdy mu rozhodně stačit nebudou :-)

Poznámka: Po downloadu by měla videa být přehratelná na Linuxu/Solarisu mplayerem (vyzkoušeno), z platformy Apple byste je měli být schopni přehrát přímo z webu. Na systémech Windows věřím, že po stažení QuickTime Playeru by přehrání mělo být také bez problémů.

26. ledna 2009 proběhlo na půdě katedry počítačů, ČVUT FEL, setkání CZJUG na téma webové služby.

Za firmu SUN Microsystems vystoupil Marek Potočiar. Jeho prezentace projektu Metro byla obohacena několika povedenými demonstracemi, kdy jako runtime byl použit aplikační server GlassFish.

Následoval přehled webservices stacku aplikačního serveru JBoss v podání Richarda Opálky z firmy RedHat. Jako bývalého člena Metro týmu mě potěšilo, že i druhá prezentace se tohoto projektu dotkla. JBoss totiž použití Metra nabízí jako jednu z variant.

Slajdy a stručné představení obou přednášejících lze získat na adrese http://java.cz/detail.do?articleId=16971. A pokud vás zajímá víc, podívejte se i na videa dostupná na následujících adresách:

• http://mediacast.sun.com/users/jakub.podlesak/media/CZJUG2009.01-Metro-Marek-Potociar-part1.m4v/details
• http://mediacast.sun.com/users/jakub.podlesak/media/CZJUG2009.01-Metro-Marek-Potociar-part2.m4v/details
• http://mediacast.sun.com/users/jakub.podlesak/media/CZJUG2009.01-jboss-ws-Richard-Opalka.m4v/details

Poznámka: Po downloadu by měla videa být přehratelná na Linuxu/Solarisu mplayerem (vyzkoušeno), z platformy Apple byste je měli být schopni přehrát přímo z webu. Na systémech Windows věřím, že po stažení QuickTime Playeru by přehrání mělo být také bez problémů.

We have an old bridge in my city. The city is called Prague, and the bridge is called Charles bridge. Whenever i am passing the bridge, i recall the date when they started construction. It was 1357 9.7. at 5.31 in the morning. Truly magical and exceptional date.

My colleague Pavel told me today, in UNIX world, such a magical date and time happens to come today at 13 11:45:21 PST. Then if you issued the following command for obtaining UNIX time:

perl -e "print time"

1234567890

Anyway. I have been always curious, how the middle age people managed to start the Charles bridge construction at the very precisely defined point of time. And still have no clue. Then i have decided to do a small experiment. Our blogging infrastructure allows us to publish a blog post at an exact time and date. I am curious to see, how precise will it be. Planning this post to be published at a very magical second. And to keep this on Friday, February 13, even for my time zone, changing the magical number to 1234554321, which seems to me a way more magical, then the poor 1234567890 :-) Will see...

This is an update for a tech tip on configuring JSON in Jersey, which i wrote in October 2008. The way of JSON configuration, suggested in the tech tip, is now deprecated (but still functioning). Here i would like to describe the new API, which will hopefully last (and be supported) a way longer.

Notice: you will need to bundle jaxb-impl-2.1.10.jar with your application in order to take advantage of the recently added JSON NATURAL convention

Deprecated Configuration

Configuring JSON format, as described in the tech tip, meant to implement a JAXBContext resolver class returning an instance of JSONJAXBContext. This principle have not changed. What changed is a way, how the JSONJAXBContext itself is being configured. Lets look at the sample code below (using the deprecated API):

   @Provider
   public class MyJAXBContextResolver implements ContextResolver<JAXBContext> {

       private JAXBContext context;
       private Class[] types = {StatusInfoBean.class, JobInfoBean.class};

       public MyJAXBContextResolver() throws Exception {
           Map props = new HashMap<String, Object>();
           props.put(JSONJAXBContext.JSON_NOTATION, JSONJAXBContext.JSONNotation.MAPPED);
           props.put(JSONJAXBContext.JSON_ROOT_UNWRAPPING, Boolean.TRUE);
           props.put(JSONJAXBContext.JSON_ARRAYS, new HashSet<String>(1){{add("jobs");}});
           props.put(JSONJAXBContext.JSON_NON_STRINGS, new HashSet<String>(1){{add("pages"); add("tonerRemaining");}});
           this.context = new JSONJAXBContext(types, props);
       }

       public JAXBContext getContext(Class<?> objectType) {
           return (types[0].equals(objectType)) ? context : null;
       }
   }

There you needed to create a property bag, put appropriate configuration options into it, and then pass it to the JSONJAXBContext constructor.

Jersey 1.0.2 JSON Configuration

In the currently available 1.0.2 Jersey version, a new JSONConfiguration class was introduced to became a central point for JSON configuration options. For creating a new JSONConfiguration instance, a builder pattern is employed. It is not only more user friendly, but also ensures only meaningful JSON options could be combined together. You can compare the following code, with the deprecated example above:

   @Provider
   public class MyJAXBContextResolver implements ContextResolver<JAXBContext> {

       private JAXBContext context;
       private Class[] types = {StatusInfoBean.class, JobInfoBean.class};

       public MyJAXBContextResolver() throws Exception {
           this.context = new JSONJAXBContext(
                   JSONConfiguration.mapped()
                                      .rootUnwrapping(true)
                                      .arrays("jobs")
                                      .nonStrings("pages", "tonerRemaining")
                                      .build(),
                   types);
       }

       public JAXBContext getContext(Class<?> objectType) {
           return (types[0].equals(objectType)) ? context : null;
       }
   }

You can look at JSONConfiguration javadoc for detailed information on various configuration options.

Further Simplification

If you go a bit further, you can ask if the configuration could be simplified even more. Imagine you have much bigger number of JAXB beans in your model, and they are more complex. It could easily become unmanageable to maintain a reasonable JSON configuration as described so far. Then if you happen to have conflicting non-string/string values and/or arrays/non-arrays elements in your set, you could easily run out of options there.

A natural way to overcome above mentioned issues, is to simply use recently introduced Jersey NATURAL JSON notation. Then you need only to:

   @Provider
   public class MyJAXBContextResolver implements ContextResolver<JAXBContext> {

       private JAXBContext context;
       private Class[] types = {StatusInfoBean.class, JobInfoBean.class};

       public MyJAXBContextResolver() throws Exception {
           this.context = new JSONJAXBContext(
                   JSONConfiguration.natural().build(),
                   types);
       }

       public JAXBContext getContext(Class<?> objectType) {
           return (types[0].equals(objectType)) ? context : null;
       }
   }

Such configuration is simple from user point of view, but yet very powerful. You do not need to keep various configuration options in sync with your actual JAXB beans, and be worried what options to actually use (what exact names, etc.). Jersey will automatically take care about serializing Java collections/arrays as JSON arrays, Java booleans as JSON booleans, Java ints as JSON integers,and so on.

Jersey provides a great, easy-to-use REST client API. Recently someone wrote to our mailing list the opposite. We probably need to advertise better.

Paul initially introduced the API in this blog post almost a year ago. But it is, of course, not the only place to look at. Javadoc for Jersey Client API could be found here.

The Jersey Client API could be used pretty easily. However, instead of describing the API in detail, i would just like to present here a real life example. A Jersey based client talking to a 3rd party server application. The server application happens to be SmugMug. A photo sharing service application. I wrote the client application during the last Xmas break, because what was provided by SmugMug did not work well for me. I am happy with my Solaris, but sometimes i wish i have chosen another OS for my laptop ;-)

Putting together a functional prototype took me only a couple of hours, and this was mainly thanks to user friendliness of the Jersey Client API designed by Paul. Following is a screenshot of the main screen of the client.

I promised not to dig into details, but just for your curiosity. Only the very last statement of the java code below has anything to do with actual invocation of SmugMug API from java using Jersey Client API. All the rest is only about computing a digest for the file being sent, as SmugMug API requires it sent in a special HTTP request header.

MessageDigest digest = java.security.MessageDigest.getInstance("MD5");
File picFile = new File(picDir, pic);
fis = new FileInputStream(picFile);
byte[] buf = new byte[8196];
int l;
while ((l = fis.read(buf)) > -1) {
  digest.update(buf, 0, l);
}
String md5hash = asHex(digest.digest());

cr = uploadWebResource
         .path(pic)
         .header("Content-MD5", md5hash)
         .header("X-Smug-SessionID", sessionId)
         .header("X-Smug-Version", "1.2.0")
         .header("X-Smug-ResponseType", "JSON")
         .header("X-Smug-AlbumID", car.album.id)
         .put(ClientResponse.class, picFile);

In December, Paul described a way to easily obtain Jersey jar files from web. It was mainly focused on non-maven users. Then Ben asked for a zip file containing the jars.

From now on, everybody can obtain such a zip archive at http://download.java.net/maven/2/com/sun/jersey/jersey-archive. You just need to select a version of Jersey and your preferred archive format. Zip archive of current snapshot is available at http://download.java.net/maven/2/com/sun/jersey/jersey-archive/1.0.2-SNAPSHOT/jersey-archive-1.0.2-SNAPSHOT.zip. Gzipped and bzipped tar archives are available as well, with smaller footprints.

The archive contains 3 directories:

jersey

contains core jersey jars and it's dependencies

contribs

contains jersey modules contributed by community. You will need to download possible dependencies separately

apidocs

contains javadocs for JSR-311 and Jersey