Chris’ Musings

How to tell if the server side is running in the hosted mode. A quick an dirty way I found was to check for the request gwt.codesvr.

Why would you want to do this. Actually, we generate the hosted.html file in a servlet and some of the embedded items change based on whether we are in a live app server or the hosted one.

Also, GWT.script() only works on the client side. Would have been nice to use this on the server side also.

We want to let our customers host a form on their web pages (so they can control the form L&F using whatever mechanism they want) and “post” the form to our servers. We also want to provide robust validation and error handling for the form. We created a little gwt app that can be downloaded (cross site script).

Everything worked great until we tried to post the results to our server (actually that worked) and get a result back to show to the user (this didn’t work). Getting the result back turned out to be really hard. We first tried to use a gwt form and modified the form to use the window.name tricks for the returned value; but couldn’t get it to work in all of the browsers. It was probably a mistake on our part; but after a couple of hours we did not get it to work.

So we ended up crafting a specific URL with the form fields as parameters, redirecting the browser to that URL and then the server “redirects” the user to the next page on success or back to the form page on error (with parameter values appended that the gwt app can read and display error message for).

We’re not entirely happy with the solution as there is a lot going on in the address bar; but it works.

We will revisit this shortly and try to get the window.name trick working. In the meantime I would like to hear about others experiences.

Love hibernate / hate hibernate.

I love it because we have not had to code boilerplate SQL in.. well … years. It gives us all kinds of flexibility and quick application development.

There are times I hate it though (that might be too strong). We are in the process of converting a large app and upgrading the UI. At the same time, we are removing all of the technical debt we have built up over time. Today we found a bug and the error from hibernate was:

org.hibernate.type.SerializationException: could not deserialize

Not very helpful. Turns out we are not the only ones who have had this issue. Gotta love search!

The gist of everyone’s problem is incorrect mappings. Once we were able to turn on debuging, we narrowed it down to a class and then to the specific field. Once we corrected the mapping, all was good with the world again.

Now you might look at this and wonder why it was such a big deal. We’ll, what was an hour exercise, should have been 5 minutes at most (the actual fix was 10 seconds once identified). First, the issue was we were missing a mapping in the configuration file (the mapping was correct on the object). So I would have though it would have been caught during hibernate startup. The actually problem was a missing @Type declaration for an enum.

At worst, the error message should be better in Hibernate (we are working with 3.3.2.6) – hibernate knows which object/property it had issues with.

Anyway, moral of the story is to always check your field mappings and the config file to make sure it is correct also.

Update:
Found another gotcha (again my fault). Watch association mappings. My index property on a list mapping was being updated with null. I had the following:

   @OneToMany(mappedBy = "form")
   @IndexColumn(name="sequence", base=0)
   public List<FormField> getFields(){
      return fields;
   }

It should have been:

   @OneToMany
   @JoinColumn(name = "form")
   @IndexColumn(name="sequence", base=0)
   public List<FormField> getFields(){
      return fields;
   }

Now that GWT 2.0 is out, I want to take the new panels for a spin.

We have been upgrading our UI with the pre 2.0 widgets. Now I want to try the tab panel. We have spent a lot of time trying to get an X icon in the upper right. Hopefully it will be easier with the the widget.

I’m calling no mas on the ESB project for now. I’ve learned a lot in the last week. I’ve installed 2 two different ESBs (servicemix and mule) and have read the docs for several more (camel, spring, jboss). I learned a lot about JMS – installed and configured activemq (really liked the ease of initial usage).

But in the end, I couldn’t make it do what I wanted (at least quickly). I have about 60 hours into the project and am not done. The use case I was trying to implement was a provisioning service. The essence of which is:

• a user registers in our application
• the subscribe to a service
• send a jsm message to the esb to provision the service
• route and transform the message in the esb to the correct URL (turns out I had to write a special router in mule to be able to dynamically change the http outbound-endpoint hostname)
• capture the return message, parse the response and act on it

I got to the last step and called no more. I am probably a few hours away, but there just seemed to be one more thing poping up. I was hoping the learning curve wasn’t so steep to get something simple going. So what I have learned…

We’ll a lot actually. First is that I understand why ESBs are not implemented everywhere and why point to point interface solutions are the norm. In fact the straw that broke the camels back that got me to implement an ESB in the first place was not as heavy as I thought. I went back into our app and extended our current infrastructure to support yet one more interface.

Second, doing something a little bit outside of “built in” requires a lot of knowledge. In Mule to create a dynamic host name for the outbound http endpoint took way more effort than it should have. Being able to “decorate” the functionality of an endpoint would be nice (basically I had to copy the Template router and make the hostname dynamic based on a property in the message – which I had to figure out how to get there in the first place).

Also, capturing the HTTP response was a lot tricker then it should have been. I have to imagine that is a frequent requirement but took custom code again. In mule I had to extended my custom router to also be a chained router…

And finally the community isn’t the largest in Mule. I don’t expect my questions to be answer immediately (or even at all). However, the lack of extensive historical advice in forums is a problem. I can’t believe I’m the first person that wanted to do either of these things.

Anyway, those were the biggest pain points so enough with the probably incoherent rant.

Third, ESB are actually very powerful. A messaging framework is something I want to implement at some point in the future. We have a strong need to integrate with lots of different inbound service. So in a couple of weeks when I get some other priorities completed, I will revisit this whole topic. However, I will choose new functionality to implement rather than try to replace existing stuff.

Fourth, being able to debug the running ESB in the java/eclipse debugger is 100% a requirement.

Fifth, so I don’t forget, the JBoss ESB looks promising. I read through some of the docs and like the fact that the message object is passed to the business logic components. I understand why/how mule takes the approach to have POJOs for components. But I found myself writing transformations when I needed access to the message. Also, it seems the JBoss message maintains previous items; whereas the mule message is a destructive context as it passes through different things. So I don’t get flamed to badly, these are just impressions after having spent only a relatively small time with each solution.

A concern about the JBoss solution is the weight of the standalone ESB. I liked Mules small footprint. The download for JBoss is very large. Hopefully it is not like the application server that includes everything but the kitchen sink (we have some experience with the JBoss AS and have removed it; EE was just too much overhead for us).

Sixth, good tooling support is a must. Mule has it (maven support), looks like JBoss ESB might, Spring does also.

We’ll that’s enough for now. The end result is there is ESB’s are powerful but come with a steep learning curve to implement and fully utilize. The ability to understand and customize an implementation to do exactly what you need takes more work that it should.