2 Months of Ubuntu on Mac Mini

I am finally happy with my OS. I had previously some complaints about MacOs X and the Mac Mini. It is now over, with Ubuntu, I am very happy of my quiet system.

I use Quod Libet for Audio, it has similar interface as iTunes, with more features (ability to play most audio formats). I chose Quod Libet instead of the standard Rhythmbox because of its practical mp3 tags handling. This also means that unlike iTunes, when I reimport my full library with another player, or on another computer, I have it all organized the right way, because the right meta data is in the audio files and not in a xml file that sometimes gets corrupted.

I can use Open Office (not yet available in non alpha version for Mac Os X).

I can use Picasa or other more standard alternatives instead of iPhoto.

I can use free guitar tuners, plenty of esoteric software.

Remote control, fancy bluetooth apple keyboard, cd burning, dvd player, printer work flawlessly. And it's all free software (except Picasa which is only gratis).

I am happy with my Ubuntu system :).

2 Months of Ubuntu on Mac Mini

I am finally happy with my OS. I had previously some complaints about MacOs X and the Mac Mini. It is now over, with Ubuntu, I am very happy of my quiet system.

I use Quod Libet for Audio, it has similar interface as iTunes, with more features (ability to play most audio formats). I chose Quod Libet instead of the standard Rhythmbox because of its practical mp3 tags handling. This also means that unlike iTunes, when I reimport my full library with another player, or on another computer, I have it all organized the right way, because the right meta data is in the audio files and not in a xml file that sometimes gets corrupted.

I can use Open Office (not yet available in non alpha version for Mac Os X).

I can use Picasa or other more standard alternatives instead of iPhoto.

I can use free guitar tuners, plenty of esoteric software.

Remote control, fancy bluetooth apple keyboard, cd burning, dvd player, printer work flawlessly. And it's all free software (except Picasa which is only gratis).

I am happy with my Ubuntu system :).

Spring Web Services, Finally!

Spring Web Services seems to be the technology I have been looking for recently. I am not a Spring bigot (too XML oriented), but here the Spring folks have something right.

I used to work with Web Services the simple way: create a java class (or EJB), expose it as Web Service through Axis or RAD, generating the WSDL in the process. And then a client would just be the reverse, take the WSDL, use a tool (Axis or RAD) that creates client Java classes from it automatically. Simple, easy.

But this process starts to fail if you have

1. several very similar WSDL: you want reuse instead of copy.
2. other means of communicating XML represented by the XML schema embedded in the WSDL, for example via direct MQ use.

In those cases, the contract first approach is particularly interesting. However most tools, if they allow contract first approach, they don't give you enough access on the message itself, and you can do 1), but not 2). I always found a bit silly that Axis or RAD had to have the logic to marshall/unmarshall java objects, but they did not give any explicit API access to do it, or to replace it with a standard way (JAXB 2 for example).

I found 2 techs that can help:

• SDOs (Service Data Objects): from my short experience, I find it a bit too verbose, and not yet fully mature, as you depend on libraries external to SDO ones for it to work in the case of web services. It can work, and if you use IBM products, it could be a good way to write Web Services Providers/Clients.
  
• Spring Web Services: I have not tried it yet, but it seems to solve exactly the kind of problems I described earlier. And you can plug-in any marshalling/unmarshalling framework you want :).
  

There are so many libraries to do web services, and different approaches, that an initiative like Spring Web Services is more than welcome!

Spring Web Services, Finally!

Spring Web Services seems to be the technology I have been looking for recently. I am not a Spring bigot (too XML oriented), but here the Spring folks have something right.

I used to work with Web Services the simple way: create a java class (or EJB), expose it as Web Service through Axis or RAD, generating the WSDL in the process. And then a client would just be the reverse, take the WSDL, use a tool (Axis or RAD) that creates client Java classes from it automatically. Simple, easy.

But this process starts to fail if you have

1. several very similar WSDL: you want reuse instead of copy.
2. other means of communicating XML represented by the XML schema embedded in the WSDL, for example via direct MQ use.

In those cases, the contract first approach is particularly interesting. However most tools, if they allow contract first approach, they don't give you enough access on the message itself, and you can do 1), but not 2). I always found a bit silly that Axis or RAD had to have the logic to marshall/unmarshall java objects, but they did not give any explicit API access to do it, or to replace it with a standard way (JAXB 2 for example).

I found 2 techs that can help:

• SDOs (Service Data Objects): from my short experience, I find it a bit too verbose, and not yet fully mature, as you depend on libraries external to SDO ones for it to work in the case of web services. It can work, and if you use IBM products, it could be a good way to write Web Services Providers/Clients.
  
• Spring Web Services: I have not tried it yet, but it seems to solve exactly the kind of problems I described earlier. And you can plug-in any marshalling/unmarshalling framework you want :).
  

There are so many libraries to do web services, and different approaches, that an initiative like Spring Web Services is more than welcome!

Original Pattern: ServletRequest in ThreadLocal

After seeing Scala had elements of Erlang through Actors, I decided to take a closer look at the language. There is an interesting new web framework in Scala, called Lift. One drawback of Lift is that it seems to be very cutting edge and not that easy to grasp. While reading its source code, I stumbled upon a strange pattern: Storing the ServletRequest in a ThreadLocal .

I had not seen that before, and was wondering why one would do such a thing. It seems to be unintuitive. I found my answer through... GWT widgets. In this page, the author explain motivations behind doing such a thing:

While not 100% in tune with the MVC pattern, it is often convenient to access the servlet
container, the HTTP session or the current HTTP request from the business layer. The GWT-SL
provides several strategies to achieve this which pose a compromise in the amount of configuration
required to set up and the class dependencies introduced to the business code.

The easiest way to obtain the current HTTP request is by using the ServletUtils class
which provides convenience methods for accessing the HttpServletRequest and
HttpServletResponse instances. Please note that it makes use of thread local variables
and will obviously not return correct values if used in any other than the invoking thread.

Still one can doubt if this is good design. In my long experience of web apps in Java I never had the need to do such a thing. Have you seen that pattern before?

Original Pattern: ServletRequest in ThreadLocal

After seeing Scala had elements of Erlang through Actors, I decided to take a closer look at the language. There is an interesting new web framework in Scala, called Lift. One drawback of Lift is that it seems to be very cutting edge and not that easy to grasp. While reading its source code, I stumbled upon a strange pattern: Storing the ServletRequest in a ThreadLocal .

I had not seen that before, and was wondering why one would do such a thing. It seems to be unintuitive. I found my answer through... GWT widgets. In this page, the author explain motivations behind doing such a thing:

While not 100% in tune with the MVC pattern, it is often convenient to access the servlet
container, the HTTP session or the current HTTP request from the business layer. The GWT-SL
provides several strategies to achieve this which pose a compromise in the amount of configuration
required to set up and the class dependencies introduced to the business code.

The easiest way to obtain the current HTTP request is by using the ServletUtils class
which provides convenience methods for accessing the HttpServletRequest and
HttpServletResponse instances. Please note that it makes use of thread local variables
and will obviously not return correct values if used in any other than the invoking thread.

Still one can doubt if this is good design. In my long experience of web apps in Java I never had the need to do such a thing. Have you seen that pattern before?