keyboardsamurais.de

I know, i know, most bloggers usually make very bad fact checkers, but this is just absurd. The bruhaha around SpringSource’s decision to charge money for their binary (only binary) releases, finally got so big that I decided to call up a sales rep. Reports of astronomical sums, one blogger mentioned 22.000 US$, totally scared me and I wanted to know if that was true.

And sure enough: It’s not.

The salesperson was nice enough to let me know, that for the whole spring software stack and 10 incidents plus some development software, I would have to shell out 630€ – about 900 US$ per year and per CPU. Affected are only production systems, not developer machines. For all she cared I would’ve been able to supply every developer in India with a fresh release, as long as he works for me and doesn’t violate the EULA. Also, cores do not count as additional CPUs.

I don’t know what kind of support Ryan was talking about when he was offered the 22k$ package, but I suppose he wanted Rod Johnson to hold his hand while coding, singing him a lullaby and basically giving him the teet – for that, 22k$ seem pretty reasonable to me

Still, getting a community hooked on an open source product and then charging them for their dependence on said product – after all learning spring is a big investment – smells kinda funny to me. I will have to decide carefully if I really need Spring 3 and all those tools after all.

…just don’t do it. I used to work with TransactionProxyFactoryBean quite a lot, back then when Spring 1.x was out and it worked quite nicely – especially when dealing with HibernateInterceptor as a preInterceptor it was quite useful. So imagine my surprise when I tried to mix out the new, shiny Spring 2.0 <aop :advice></aop> anotation based @Transactional support: All session management code stopped working.
Continue reading ‘Never mix Spring transactional aop:advice and TransactionProxy’

In case anyone accuses me of not getting the idea of Google Gears, let me say this: I don’t get the whole Idea of google gears. I mean come on, it caches your javasript and html for offline use in a fashionable way and enables you to enter some input to your app which is later synchronized when you reconnect to the web. All right, this will certainly make things like playing ajax Tetris a whole lot easier. The weblogs are abuzz about how google gears is better than the second coming.

But wait…do you spot the error? Wasn’t Ajax meant to do some significant computing on the server side? Wasn’t the whole promise of Ajax, that you’d get some meaningful data from a remote server in a quick, painless way?

Right. What Gears accomplishes is nothing like that (how could they, it’s technically impossible). Of course, you would be able to edit your spreadsheets and word processors but these have been around for offline use since the advent of personal computing. In other words: Google Gears will make it easier for developers that feel comfortable in that niche that is Ajax desktop computing.

But they do this in a way that is downright scary. Instead of keeping it simple, they add this enormous complex layer of technology between your browser and the actual server. God knows how any sane developer is going to be able to debug the mess this will likely create in all those bug scenarios. Additionally, webapp developers need to comply with some design principles of Gears to make their apps “Gears ready”.

To make a long rant short: I know there are a lot of people out there, who desperately wish for a network computer – and so they hack away on applications that use ajax locally and eventually they can synchronize their data to the server. It’s a nice toy for a computer hacker, but I think by the time something as complex as this will be usable by Mom and Dad, ubiquitous WLAN will be a reality and the need to use these frameworks will have disappeared. But let’s wait and see if anyone can come up with some kind of killer app, that turns it all around …I highly doubt it.

If you use Spring’s awesome MVC framework you will likely encounter one problem that is common among Web frameworks. If the first page you want to open is a jsp page with a Controller – i.e. a page where some java code is executed to prepare data for the invoked jsp…there seems to be no traditional way to do it.

Say you want to be able to access the url http://server.com/ to your servlet container that’s just a directory. It will list the direcoty (if listig is enabled) or just show you a blank page. That is, unless you have defined a <welcome-file> directive in your web.xml which looks for a particular file to load in this case. But this is exactly the problem.

Assume you have defined the following:

<welcome-file-list>
<welcome-file>index.html</welcome-file>
</welcome-file-list>

And the index.html is the formView of, let’s say a SimpleFormController.

Now what your container will do upon a request to its root context is this. It will look for a file in your filesystem called index.html and try to deliver it. Of course your index.html is not really a file, it’s just mapped by, for example, a SimpleUrlHandlerMapping. Game over for the Server. It will not deliver what you expect.

Unfortunately there is no universal way of telling the container to take a look into the Spring context for the url. There is not even a possibility in web.xml to do simple forwards to other urls for the <welcome-file/>.

Instead the solution that seemed most practical to me was, to create a jsp as the <welcome-file>, save it as index.jsp and insert the following code:

<jsp:forward page="index.html" />

I assume that you chose *.html as your url-pattern for the DispatcherServlet here.