keyboardsamurais.de » Coding http://keyboardsamurais.de thoughts on software development, warts and all... Sun, 19 Jun 2011 12:36:37 +0000 en hourly 1 http://wordpress.org/?v=3.1.3 Repository for maven-timestamp-plugin added http://keyboardsamurais.de/2010/02/17/repository-for-maven-timestamp-plugin-added/ http://keyboardsamurais.de/2010/02/17/repository-for-maven-timestamp-plugin-added/#comments Wed, 17 Feb 2010 22:53:12 +0000 Toni http://keyboardsamurais.de/?p=237 A while back I released the maven timestamp plugin. While I was not able to convince the gatekeepers of the central repository that it is worthy to add (I mean after all that thing is trivial), some 370+ users have already downloaded and used it.

So, to make things easier I added a maven repository for you maven lovers to enjoy. Have fun.

flattr this!

]]> http://keyboardsamurais.de/2010/02/17/repository-for-maven-timestamp-plugin-added/feed/ 0 Whats all the fuss about spring source charging big money? http://keyboardsamurais.de/2008/09/29/whats-all-the-fuss-about-spring-source-charging-big-money/ http://keyboardsamurais.de/2008/09/29/whats-all-the-fuss-about-spring-source-charging-big-money/#comments Mon, 29 Sep 2008 21:45:02 +0000 Toni http://keyboardsamurais.de/?p=230 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.

flattr this!

]]> http://keyboardsamurais.de/2008/09/29/whats-all-the-fuss-about-spring-source-charging-big-money/feed/ 9 Matching XML content with XPath – the magic is in the ‘.’ http://keyboardsamurais.de/2008/01/16/matching-xml-content-with-xpath-the-magic-is-in-the/ http://keyboardsamurais.de/2008/01/16/matching-xml-content-with-xpath-the-magic-is-in-the/#comments Wed, 16 Jan 2008 15:03:54 +0000 Toni http://keyboardsamurais.de/2008/01/16/matching-xml-content-with-xpath-the-magic-is-in-the/ Sometimes it's the simple things that make you wonder how they are done on a high level. For example, if you are wondering how you'd match the content of a node in Xpath, you might think to yourself: "Gee I really would like to know which food-nodes in my xml document contain the word 'Donuts' - this should be easy to find out with XPath".

Well, let me save you some time here. At first you might be looking for a function that matches strings. By looking into the w3c xpath function reference you'd find a function called contains(). 'contains()' takes two parameters. And here the fun starts.

What the reference doesn't tell you (ok I'm sure it does tell you somewhere), is how to fiddle your matches into the first contains() parameter, which incidentally is the text you want to scan. If your document looks something like this:

<mydocument>
   <food>Bavarian Donuts</food>
   <food>Cheesecake</food>
   <food>Oranges</food>
</mydocument>

Your first approach might look like this: /mydocument/food[contains(/mydocument/food,'Donuts')] Which, in a universe where everything makes perfect sense, would yield you one hit. However, this one just breaks your XPath processor, because contains() doesn't accept multiple matches as the first parameter.

Instead you can do this: /mydocument/food[contains(.,'Donuts')]

The trick is that you use the '.' which is a shortcut for the current node function to reference the currently matched node as input to your contains() function. That's all there's to it.

flattr this!

]]> http://keyboardsamurais.de/2008/01/16/matching-xml-content-with-xpath-the-magic-is-in-the/feed/ 0 Deleting packages with Eclipse and Subversion / Subversive plugin http://keyboardsamurais.de/2007/12/06/deleting-packages-with-eclipse-and-subversion-subversive-plugin/ http://keyboardsamurais.de/2007/12/06/deleting-packages-with-eclipse-and-subversion-subversive-plugin/#comments Thu, 06 Dec 2007 14:00:09 +0000 Toni http://keyboardsamurais.de/2007/12/06/deleting-packages-with-eclipse-and-subversion-subversive-plugin/ Something I just can't wrap my head around is the sheer brittleness of development with a Subversion repository. While I do realize that this technology is way younger than the old cvs, it just boggles that mind what kind of crazy bugs you come across.

My pet peeve was this one bug, where you'd delete a package and try to commit and your server tells you that your directory is out of sync. I only now discovered that "out of sync" means you'll have to "svn update" the parent folder of your deleted packages to be able to commit the delete. See the developer comments on this here - the gist of it: it's not a bug, it's a feature. Oh brother.

I guess I'll have to give mercurial, git or some other versioning system a try in the next project. SVN just makes me want to cry.

flattr this!

]]> http://keyboardsamurais.de/2007/12/06/deleting-packages-with-eclipse-and-subversion-subversive-plugin/feed/ 3 Spring 2.5 and the runtime paradigm shift http://keyboardsamurais.de/2007/11/22/spring-25-and-the-runtime-paradigm-shift/ http://keyboardsamurais.de/2007/11/22/spring-25-and-the-runtime-paradigm-shift/#comments Thu, 22 Nov 2007 01:32:09 +0000 Toni http://keyboardsamurais.de/2007/11/22/spring-25-and-the-runtime-paradigm-shift/ I just finished reading up on the new features of Spring 2.5 and I have to say I'm pretty excited. One thing that bothered me from the start of the Spring project has always been the need for xml wiring of components. No matter what you do in Spring land, you will have to create at least a minimal stub of xml in your config files to make your component known to Spring. And now, the freshly released 2.5 version of Spring is reaping the benefits of annotation driven development and completely does away with that.


Sure, you can still wire your static beans if you want to, but much more excitingly you can use component scanning to look for beans at runtime. No fiddling with XML at all.

Mark Fisher does a very good job of explaining the full impact of this in his InfoQ article on Spring 2.5. Also there is the much more comprehensive Introduction to 2.5 by Rod Johnson on TSS.com.

But what really caught my interest was Interface 21 CTO Adrian Colyer's elaboration on Spring's investment into the OSGi spec. If you listen to him you suddenly realize why exactly the runtime wiring became necessary. The upcoming Spring OSGi API takes the fact into account that Spring configuration at runtime is cool and all, but modularity gets ever more important. Coyler talks about all the interest the application server vendors have in OSGi and how big Web application projects may look like in the future.

In large applications we may see lots of dynamic service OSGi modules, wired together at runtime by Spring, that, as a whole, make up one or more applications. Spring takes into account that OSGi services may come and go at any given moment. Thus updating parts of the application (deploying a new service) instead of changing out a monolithic WAR file becomes a possibility. Exciting stuff. I will look into that some more.

Of course there is plenty of other cool stuff in 2.5, just check out the SpringSource blog or read the Changelog.

flattr this!

]]> http://keyboardsamurais.de/2007/11/22/spring-25-and-the-runtime-paradigm-shift/feed/ 1 Never mix Spring transactional aop:advice and TransactionProxy http://keyboardsamurais.de/2007/11/21/never-mix-spring-aopadvice-and-transactionproxy/ http://keyboardsamurais.de/2007/11/21/never-mix-spring-aopadvice-and-transactionproxy/#comments Wed, 21 Nov 2007 21:31:19 +0000 Toni http://keyboardsamurais.de/2007/11/21/never-mix-spring-aopadvice-and-transactionproxy/ ...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> anotation based @Transactional support: All session management code stopped working.

Yes, I should have known better. No, I didn't think of this immediately. Yes I did waste a lot of time with this. No, you may not slap me across the face with a Spring manual, I RTFS...by now.

What happens if you mix the two is this: The AOP Advice will open a Hibernate session for the method you are currently doing work in, then you invoke your DAO code which is wired up with your old TransactionProxyFactoryBean and the HibernateInterceptor. HibernateInterceptor will say: "Alright, this isn't so bad, there is already an open session." and pass the steering wheel back to your DAO. When the DAO is finished, HibernateInterceptor is called again and closes whatever session it finds...which happens to be...the ONLY session you have. All further code that involves accessing your pojos will fail, from this point on.

Note to self: Read the docs more carefully.

flattr this!

]]> http://keyboardsamurais.de/2007/11/21/never-mix-spring-aopadvice-and-transactionproxy/feed/ 0 Fixing crashy Eclipse installations http://keyboardsamurais.de/2007/11/01/fixing-crashy-eclipse-installations/ http://keyboardsamurais.de/2007/11/01/fixing-crashy-eclipse-installations/#comments Thu, 01 Nov 2007 19:46:41 +0000 Toni http://keyboardsamurais.de/2007/11/01/fixing-crashy-eclipse-installations/ I've been suffering permanent Eclipse crashes. Especially when developing with the WTP on Tomcat. I found that it just takes some tweakage on the eclipse.ini file to get rid of this noisy little OutOfMemoryException permGen fucker. Here it is, my eclipse.ini. It works like a charm for me.

-showsplash
org.eclipse.platform
--launcher.XXMaxPermSize
256M
-vmargs
-Dosgi.requiredJavaVersion=1.5
-Xms40m
-Xmx512m
-XX:PermSize=64m
-XX:MaxPermSize=128m

flattr this!

]]> http://keyboardsamurais.de/2007/11/01/fixing-crashy-eclipse-installations/feed/ 2 Google Gears, the app that would’ve been a godsent – ten years ago http://keyboardsamurais.de/2007/06/01/google-gears-the-app-that-wouldve-been-a-godsent-ten-years-ago/ http://keyboardsamurais.de/2007/06/01/google-gears-the-app-that-wouldve-been-a-godsent-ten-years-ago/#comments Fri, 01 Jun 2007 11:10:18 +0000 Toni http://keyboardsamurais.de/2007/06/01/google-gears-the-app-that-wouldve-been-a-godsent-ten-years-ago/ 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.

flattr this!

]]> http://keyboardsamurais.de/2007/06/01/google-gears-the-app-that-wouldve-been-a-godsent-ten-years-ago/feed/ 3 Pain is the cost of Spring MVC’s elegance http://keyboardsamurais.de/2007/05/16/pain-is-the-cost-of-spring-mvcs-elegance/ http://keyboardsamurais.de/2007/05/16/pain-is-the-cost-of-spring-mvcs-elegance/#comments Wed, 16 May 2007 01:17:10 +0000 Toni http://keyboardsamurais.de/2007/05/16/pain-is-the-cost-of-spring-mvcs-elegance/ I'm surprised about how far Spring has come without ever adressing simple everyday problems. If you really, honestly want to use Spring for your application all the way through, be prepared for some good shockers. Want some spring oddities?

Lets start with a question, what do you think caused this exception?

Now, you may come to the conclusion that
a.) Jetty has had a problem in transferring some streams back and forth
d.) The Hibernate Session may have been closed
c.) Space aliens hijacked your VM

...but, no - that all didn't happen. It was just the Spring way of telling me: Your Hibernate mapping needs some lazy loading if you're gonna mess around with circular dependencies. Nice one. Even better that the OpenSessionInViewFilter covered up the original error message that could've been actually helpful. Just adding @OneToMany(fetch = FetchType.LAZY, cascade = CascadeType.ALL,mappedBy="user") helped me though. The time it took me to figure this out, would've bought me many a meal, had I only opted to spend it on real work.

But on to the next one: the Spring taglib. Whether you want to use the old tags or the new form:* tags that spring offers you, you will have to specify a commandName. That wouldn't be so bad if it wasn't for the fact that the tags will just flip out and throw one hell of an Exception, if you fail to have an actual instance of the command that is being referenced in your Model. This means if you want to embed a login form on every page you use, you will have to make sure, that every single Controller for every single page adds a blank LoginCommand class to your Model. Note that the form:* tag is Spring's the second take on tackling the problem of creating a usable taglib. Why Rob Harrop and Juergen Hoeller, the two (usually brilliant) guys who are to blame for this abomination, don't just crawl into a cave and cry, because of the shame they brought on themselves, is a mystery that boggles the mind. Why not just let the poor tag fail silently, like in EL? We may never know, what drugs were at play during design.

You think I'm joking? It gets better. Since the SimpleFormController allows only support for exactly one type of form-backing command, you will have to deal with multiple commands yourself - manually, or use a command that has nested properties - *yay*. What this means is, adding every command to the page with multiple forms, so those form:* tags don't detonate in your face. The SimpleFormController really isn't of much help here. Instead you have to mess around violently in xml hell, or abuse springs design principles to get what you need. That is, unless you take the time to bring the old MSPC modules, whose sf.net page looks pretty dead to me, up to date. This is a problem the Spring community has been struggling with for YEARS. I cannot possibly understand how it can be so hard to create something nice here. I am constantly tempted at writing my own spring extensions.

I had to vent. Overall Spring MVC isn't that bad - there are just some parts of it, you better just don't touch, lest you want to suffer a heart attack.

Update: Found a cumbersome workaround for the taglib issue.

flattr this!

]]> http://keyboardsamurais.de/2007/05/16/pain-is-the-cost-of-spring-mvcs-elegance/feed/ 1 Spring MVC and the <welcome-file> directive http://keyboardsamurais.de/2007/05/10/spring-mvc-and-the-directive/ http://keyboardsamurais.de/2007/05/10/spring-mvc-and-the-directive/#comments Thu, 10 May 2007 11:26:22 +0000 Toni http://keyboardsamurais.de/2007/05/10/spring-mvc-and-the-directive/ 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.

flattr this!

]]> http://keyboardsamurais.de/2007/05/10/spring-mvc-and-the-directive/feed/ 3