30 September 2008
Posted by on
For a few hours I was trying to understand why my simple BPEL process wasn’t working. I was using NetBeans IDE 6.1 (Build 200809100101). My simple BPEL process used two external partner links which were web services exposed by an EJB Module. Looking at the messy exception messages that Glassfish shows it was kind of hard to understand the issue. Everything seamed to be fine, building went smoothly and the deployment on a Composite Application as well, but the test always failed. The test failure wasn’t due to the fact that the contents of the output file and the file whose name contains the timestamp of the moment when the test was executed were different, because both of the files reported an error message (this is in fact a bug in NetBeans). I couldn’t understand why I could never obtain the desired results. Trying different things I found out that if I put the web services which acted like partner links in the BPEL process into different packages in the EJB Module, everything worked fine!! I think this was due to the fact that some of the output types used in the two web services were the same (for example java.lang.Exception) and maybe the BPEL schema importer couldn’t tell between the two. I don’t know, the important thing is that this seems to be yet another bug in the NetBeans platform. I resolved the problem with some simple refactoring, putting the two different web services into two different packages.
2 September 2008
Posted by on
Having worked with the .NET frameworks in Visual Studio, whenever I implemented an ASPNET web service I was used to return generalized collections of my business objects which were declared in nested layers and I never had any problems because the returned values would always be xml-serializations of my classes. However, having to work with GlassFish now I found that serialization isn’t that immediate. After days of looking for documentation on this issue, I discovered that Glassfish doesn’t serialize your objects unless they respect the java-beans structure (private fields, public getters and setters in CamelCase and a no-parameter constructor) and (obviously) they need to implement the java.io.serializable interface. I also found that nested classes can’t be serialized (but maybe I’m wrong).
I’ve written a more recent post on this topic. Click here to view it.
2 September 2008
Posted by on
This is a tough one,
for the last two days I’ve been trying to make a Silverlight client consume a Glassfish JAX-WS Web Service, but without any success till a few hours ago. I tried the procedure indicated at “Call a Java EE Web service from Silverlight Client” on the MSDN blogs (the only one I could find) but it didn’t work. That blog post says that the solution is copying an xml file called clientaccesspolicy.xml in the docroot folder of the GlassFish domain where the web service resides. I found that when you add a GlassFish WS web reference to a Silverlight project, Visual Studio (I use the Professional 2008 version) creates a configuration file that gives compilation problems, unless you manually change the “customBinding” to “basicHttpBinding” and manually add the endpoint. When I ran the Silverlight client it launched a CommunicationException due to a “cross-domain configuration error”. I had already copied the clientaccesspolicy.xml file on the docroot folder of my GlassFish domain as indicated on the msdn blog.
Then, after some hours, I had the idea of creating an ASPNET Web Service which acts as a wrapper for my GlassFish WS, but I found out that neither that would work and it would launch the same exception! I started to have strong suspicions that this was a Silverlight bug. I completely erased the existing project which didn’t work and created a new one, adding the web references normally (not manually). In this way it finally worked!
Just out of curiosity I tried adding another web reference to the Silverlight project to my original GlassFish WS, having to change the configuration file manually as before. It not only didn’t work, but it also caused the other (.NET) web service to stop working, even after I had removed it completely and had restored the configuration file to the original state. It’s so ridiculous! Silverlight is good looking, but still not serious enough for interoperability.