Wednesday, 21 May 2008

Another WTF Moment brought to you this time from Spring Framework

I had to configure some spring configuration files and one request was that the properties should be extracted into a separate properties file so that a user can change them without messing around with XML. Looking into Spring that seemed to be quite easily to achieve and so I started adjusting the configuration file which contained this snippet:


    <bean id="propertyPlaceholder"
        class="org.springframework.beans.\
            factory.config.PropertyPlaceholderConfigurer">
       <property name="location"
            value="classpath:ldap/authenticationConfiguration.properties"/>
    </bean>
  keep on reading here

Posted by schaefera at 8:04 PM in Java

Responses (0)

Friday, 16 May 2008

Continuing NetBeans Problems

First and foremost I have to admit this is the first time I do a Swing Application with an IDE and therefore I could well be that the other IDEs like IntelliJ and Eclipse have their own share of problems. That said I find some of the nasty features of NetBeans quite appalling and they let me waste quite some time. Slowly I start to understand how it should be done and therefore can avoid some of the problems but most of these problems should not arise in the first place because it makes the developer's job more difficult than easier.

  keep on reading here

Posted by schaefera at 7:11 PM in Java

Responses (0)

Tuesday, 13 May 2008

Custom Servlet Filter Chains Injection

Lately I had the task to add additional Java Servlet Filters at runtime to an existing Filter stack. Logically that sounds pretty simple but the implementation was not that simple and I had to use some Swiss ingenuity to make it work. A Filter has one important message called doFilter( Request, Response, Chain ). In order to make sure that the chain of filters is executed the Filter has in some place to call the method doFilter( Request, Response ) and the Filter Chain instance will then call the next filter in the chain or the target resource if there are no more filters. Because a filter has an in piece (the code before the chain.doFilter() call) and an out piece making it impossible to just loop through my own filters and then call the next through the filter chain. In addition the Filter Chain does not have any add/remove method to inject filters at runtime. Well, now what to do?

After a few minutes it finally dawned on my that I could replace the Filter Chain with my own one to make sure that my filters are included. But then what do I do with the remaining filters in the original filter chain. Well, I just do the same to it as the original filter chain does when it reached it end, I just call the target which in this case is the original filter chain. This led me to the ProxyFilterChain class that looks like that:

  keep on reading here

Posted by schaefera at 5:51 PM in Java

Responses (0)

Thursday, 8 May 2008

Nothing Beats Persistence except you are a Wunderkind

If you are not lucky (or unlucky) enough to be a Wunderkind like Mozart or Einstein then you need persistence on way or the other. Well today I had to use persistence and patience to wade through the jungle called Spring Framework. In this case I was trying to setup the ACEGI security (now called Spring Security, go figure) without their Namespace Configuration. The NC might look nice and convenient but when you need to know how that thing is wired up and how to configure it to your special needs it   keep on reading here

Posted by schaefera at 9:57 PM in Java

Responses (0)

Wednesday, 7 May 2008

Did I already say that I Hate NetBeans

Since four months I am using NetBeans on my daily job and things only went downhill from the beginning on. Today I ran into an issue which is particularly annoying because it is not a problem in NetBeans 6.0 and there was not trace whatsoever of what could be the reason for the failure. The implication was more or less that I could not develop anything using the NetBeans UI editor for my Swing application. Eventually the problem could be solved using a different version of the library (don't know what the difference is) but just the mere fact that I ran into an issue and NetBeans just silently ignores a library is dead wrong. Then I rather use a buggy IDE if it gives at least some hints how to resolve problems.

  keep on reading here

Posted by schaefera at 5:53 PM in Java

Responses (1)

Wednesday, 23 April 2008

Update: Is Bean Bindings in Swing Dead?

A few weeks has past since I blogged about Bean Bindings and I learned a lot since then. I still cannot update the source object easily but I found ways to hide it from the users of that code. One of the tasks I am working on right now is that I should find a model on how to create UI components like lists, tables, forms etc that can be plugged into any application and then easily configured to work with the rest of the application. More or less the old idea of reusable components but here just limited to the company I am working for.

  keep on reading here

Posted by schaefera at 7:01 PM in Java

Responses (1)

Wednesday, 16 April 2008

Is Bean Bindings in Swing Dead?

In the past few weeks I started to look into Bean Bindings as made available in Netbeans. Bean Bindings is based on JSR 295 and that JSR did not produce anything so far still Netbeans is using it and the Java.net project already release version 1.2.1. So far I am wondering if the idea is more ore less dead because the JSR 295 group did not produce anything and the Java.net project implementation is quite complicated at least for my goals.

My project req  keep on reading here

Posted by schaefera at 9:02 AM in Java

Responses (0)

Sunday, 13 January 2008

Guilder: a Build System with Groove Part II

This Sunday because of some lousy Football teams I had a chance to look a little bit deeper into the Guilder project. Beside the overall project goals I also wanted to accomplish two other goals:

  • Writing the core and the plugins in Groovy
  • Building the project with the project itself meaning to bootstrap the project with itself

That means I need a Groovyc and Jar plugin in order to compile and create the project archive. To create the archive I didn't see much of a problem but with the Groovy Compiler I wasn't so sure therefore I tackled it first.

  keep on reading here

Posted by schaefera at 10:53 PM in Java

Responses (0)

Guilder: a Build System with Groove

After meeting with some friends on last Thursday I started to further investigate how a build system could be made using Groovy as the core as well as the scripting language for the plugins. What I basically want is to merge the excellent features of Maven 1 and Maven 2 and so creating a flexible, extensible and easy to use Build System. What I first did after my first blog about the idea of a Groovy based Build System was to see how to create a plugin in Groovy and then how to call it from another Groovy class. It was a little bit harder than I thought but eventually I solved all the problems learning a lot of Groovy along the way. Contrary to Jim White's statement that one needs to buy and read Groovy in Action book I figured out that using the Groovy code base helps a lot to understand how to actually use it even though I agree that is not for everyone. The trickiest part was how to call another script that contains a set of goals inside and also to provide some help for plugin developers. Eventually I opted for Groovy Classes because they can extend a base class (aka the support) as well as methods that represent the goals.

  keep on reading here

Posted by schaefera at 12:18 AM in Java

Responses (0)

Friday, 11 January 2008

Netbeans Does Not Work for Me

Since a week I have to work with Netbeans and I don't like it. In my opinion an IDE should support a developer rather than telling him/her how to develop software. This also means that the developer has the choice how he builds a project and how he names stuff. But not with Netbeans because I forces you to develop as it sees fit and it sits in the middle of your project like a fat spider pulling all the strings. Probably it does it so because it can force the entire team to use Netbeans.

  keep on reading here

Posted by schaefera at 5:36 PM in Java

Responses (1)

Sunday, 6 January 2008

Could Groovy / Gant be a replacement for Maven 2?

I don't like Maven 2 for various reasons but the most important one is that the developer team dumped the Jelly Scripting in favor of the Java class approach they call Mojos. First I was thinking to create a Groovy plugin for Maven 2 to inject the ability of scripting but I thought that the other problems around Maven 2 are severe enough that I would warrant a complete rewrite putting Groovy into the center rather than adding it on the side lines.

  keep on reading here

Posted by schaefera at 10:33 PM in Java

Responses (1)

Monday, 17 December 2007

Continous Intergration

In my current job I am looking into some strategies on how to develop software efficiently and one of the best working model I know of is how software is develop in open-source. It is mind boggling to watch how companies are unable to do basic things like automated builds, automated tests, notifications about failures, release management even though they have the resources, the manpower and they work in close proximity. But I think actually all these points are the reasons why it doesn't work because they make it easy to cheat on them which over time becomes a way of how software is developed. Open-source projects on the other hand do not have a choice and because of their setup they cannot cheat and so it becomes a way of how they develop software without expensive and resource intensive tools like Clearcase, Project Management tools, (UML) Design tools and many more. Therefore the streaming lining of a project because of its open-source nature is their biggest advantage for developing great software. Another point would be that many users see the code a give more feedback than in a for-profit company but there is not much a company could do about it.

  keep on reading here

Posted by schaefera at 10:25 AM in Java

Responses (1)

Wednesday, 7 November 2007

Software Development Process: Treat the Symptoms rather than the Cause

I know, I know I sound like an old LP with a crack that make the song repeating itself but it seems that certain things are coming back over and over even though there is no proof that it is working. A process is there to make sure that repetitive actions are executed correctly. Now the question is is software development are repetitive task? In my opinion for the most part it is not and if it were we could easily automate it. So why is this theme coming back over and over again, you may ask. It is because the managers, executives and maybe some project leaders would like to make it so so that software development becomes controllable and easy to manage. Controllable because they want to assess the risks and then minimize it and Easy because they don't want to work hard for it. And then, not to forget, there are many consultants out there that make big bucks with feeding into that hunger even though the results are nearly non-existent.

  keep on reading here

Posted by schaefera at 8:29 AM in Java

Responses (0)

Tuesday, 6 November 2007

ServiceMix MEP In-Depth

As discussed yesterday there is a significant difference on how to code MEPs based on if they are synchronous or asynchronous. First let's have a look on the synchronous MEP on a provider (acting also as consumer) assuming we are coding it with the ServiceMix Bean's MessageListener interface:

  keep on reading here

Posted by schaefera at 9:46 AM in Java

Responses (0)

Monday, 5 November 2007

ServiceMix: JBI Message Exchange Patterns

I am working with ServiceMix for some time now but it took a considerable amount of time to understand the JBI message exchange patterns (MEP) and to know what it means when coding Service Units to be deployed on ServiceMix. The first problem is that most of the examples or test cases in ServiceMix are working with synchronous calls only which makes it quite easy to work with but in most cases is not a good choice for a real world project. Then the JBI specification is not very good (as discussed earlier) and so the the allowed interactions in a MEP is not quite clear. Finally some of the MEPs don't make much sense at the first glance. For example the In-Option-Out MEP give the consumer (the one from which the MEP originates) the ability to send a Fault back to the provider (the one that provides the response) if there is something wrong with the response. Even though that sounds good there is not much that the provider could do because he can only set the message exchange (ME) to either DONE or ERROR. But then I realized that he could initiate corrective actions like compensatory transactions.

  keep on reading here

Posted by schaefera at 5:04 PM in Java

Responses (0)