AngularJS – The good parts

As promised in the „bad parts“ article I now want to speak about some of the things AngularJS shines in my eyes. I promise to keep it shorter this time :)

Without further ado:

Forced to structure your app  in a decent way

Especially when you’re new to the Single-Page-Application world, this is a good thing. Angular is opinionated, but so chances are good, your app will be maintainable months later.


Rather subjective. I enjoyed working with Angular very much. APIs seem clean, and because of the gradual learning success, we didn’t get stuck anywhere.

Productivity and turnaround

You get to see results very quickly. I could showcase real results „live“ while discussing with our requirements guy. Not always, but more often than I expected.

Quick first successes

Getting started with Angular went quite fast for me, thanks to good documentation and tooling.

Testing is first class citizen

Looking at the documentation, the community and tooling, testing (and especially unit testing) is really taken seriously. More seriously than in most Java projects, I’ve seen. Feels great!


The documentation by Angular itself is very good. But there exist tons of third party docs as well (for example this). Many books, video tutorials and usergroups are available.

Large community

Many devs are discovering SPAs and Angular in particular. Stackoverflow, Twitter and the blogosphere are rich on content.

Many good third party components, less need for homegrowing

There exist tons of third party components for AngularJS. Some are well tested and good, some not. Compared to Eclipse RCP, there are only rare cases that you need to homegrow your extension.

Loads of best practices accessible

A mix of the three aforementioned aspects: Beyond the structure given by Angular and the availability of third-party components, you get a lot of content that tells you how to manage your app if it gets bigger. Best-practices, design/architectural blueprints, or simple opinion. For example this.

Until now no hard roadblocks

Being in production mode now, we have yet to find a hard blocker, that stops us developing a longer time than, say, a day. I’m surprised.

Asynchronicity applied well

I wrote about the asynchronicity in the bad parts bit. Especially promises are a bit quirky at first. But you get the idea fast and asynchronicity felt natural fast. Very powerful bit with Angular, that I miss in my Java environment at times.

Two way data binding just works

This is a feature that is discussed a lot. Some people argue, that you don’t need it after all. I think it comes quite handy. I have worked  with JFace Databinding within Eclipse RCP. Angular databinding seems nicer to me. But I can apply the same set of patterns that I applied in the Eclipse RCP context. Good thing.
Minor drawback: There maybe some negative perfomance implications, if you have more than 2000 bindings on your page. But most of the time, you can use things like one-time-bindings to leverage this. One-time-bindings are available in AngularJS 1.3 (use this if you use Angular < 1.3).

 Integration of Non-Angular-Libraries

Besides some minor glitches with some JQueryUI widgets, we did not have any mentionable problems integrating Non-Angular-Libs. For example we used D3.js, which could be nicely packaged as a directive.

„Backendless development“ – REST backend with express suffices

As Angular more or less forces the usage of a REST backend, you have the complete freedom how this REST backend is fleshed out. Having node.js on our desks already, we found it extremely handy to just start with some simple express endpoints. You can even mock your endpoints completely from within Angular.

That’s all for now. Thanks for reading!

AngularJS – The „bad“ parts

In my current project I am developing an application using AngularJS as its frontend technology. The task was to break out specific parts of an existing rich-client and build a ‚fancy‘ app to be used by a small part of the users.

Out of several alternatives we chose AngularJS and we are quite happy with our choice. I knew Angular beforehand, having used it in small private projects. So I consider myself as a slight Angular-fanboy.

But the other day a colleague of mine from another team asked a fair question: „You are telling all these raving things about Angular all the time. But what does suck about it?“

I had to think hard, but I couldn’t tell any flaws right away. So I started to compile things that bother me about Angular. And sadly :) this list grew to some degree.

In this post I’d like to present to you my 2 cent about those bad parts. Those bad parts aren’t bad per se. It’s rather a list of things my team and me had some more or less hard time with during our development. This list is supposed to serve mainly as a reminder for me.

I’m still a fanboy, but I think those raving reviews can be found by some googling. (I will compile my ‚Good Parts‘ list later on :))

But let’s begin. Those points are more or less in random order:

Learning curve

Though you get to first successes rather quickly, the learning process might take you longer than you might expect. This short post describes it quite well. Some moments where I stumbled a little were $scope communication and visibility, $promises and custom directives.

Promises are hard

As I mentioned before, I think the concept of promise is kinda hard. Useful, but overwhelming at first. There are many places throughout your Angular app where you eventually stumble upon promises, the most obvious one being $resource. Coming from a java world, I haven’t used promises (or futures) quite that often.

Not exactly lightweight

Angular seems to be a tiny, lightweight thing, when looking from the outside, but it really isn’t.

For example: The HTML templates you develop and use with Angular are just that: templates. Angular compiles and transforms those templates into something similar looking but different thing. Think of JSP => HTML conversion, but on the client side. So you get an implicit additional layer, you might not expect.

It works like a charm, but it gets me shivers now and then ;)


Also mentioned before, you have to understand the relationship between controllers and scopes and how to stack scopes properly. Communication between scopes is something you don’t do right the first time. You could do events (event-hell), $rootScope (global state), services (view not accesible), or access a parent scope (might seem magic) or perhaps more. We had to spend some time thinking about this and to discover the possible ways.


This might be more of a tooling issue. Using Batarang the overview of stacked scopes gets quite overwhelming. Most of the time we fell back to console.log().


I guess this is everyones favorite. We stumbled across this more than once.

Really not usable in every use case

This might be a topic for another post. Angular should only be used if you are developing a „real webapp“ where you need all these interactive gimmicks. If you are developing a plain old form website, it might be too much, and a simpler approach might better fit your needs. As with every technology, look at your requirements first :)

Forced to use node.js

Working in Java based shops, node.js has this esoteric aura and is frowned upon. But if you want to develop properly and use all these shiny recommended tools like grunt, bower etc. you should at least have a working node.js installation on your dev machine. And it doesn’t hurt to have node running on your CI machine as well. We found it handy to use express to sketch some early REST endpoints, that could work as mock endpoints. Feels easier than, say, use Jetty/Jersey to do the same.

Grok Javascript and prototypical inheritance

If you stumble upon the dot issue I talked about earlier, you’ll understand why. Scoping relies heavily on the prototypical inheritance. You might not guess its effects the first time, you will eventually read about it and get some understanding.

Decent development only with Chrome

We have to build our application for a newer version of IE. Like most of us. But the best development tool Batarang is only available in Chrome (at least now). So you will have to use both.

Syntactical overhead to prevent minification issues

When you declare a controller and its dependencies you could just rely on the naming conventions.

But in case you minify your code, the naming gets lost

This clearly is a duplication, and kind of ugly I think.

All Dependencies on one page

Even if you compose your app from multiple modules, all dependencies are loaded upfront. There is no built-in dynamic loading mechanism. Angular 2.0 might have such feature. One might use libs like require.js to leverage this, if it is a problem.

This might be a problem, if you face a really large application.

Pluggable subapps hard

If you are developing a larger app,  you may want to compose your app from smaller apps (like a portlet, or Eclipse RCP/OSGi). This is possible, but you have to homegrow your solution. Communication between those subapps seems nontrivial. Say you have a sidebar to which you might want to contribute from many possible unknown parts. Yes, I admit this is quite unfair, as no other contender to Angular (afaik) does this. But if you want to port some real largish application to the browser this might be something you need.

Slightly bad press

There is some discussion going on, whether Singe Page Applications (and AngularJS) are a proper way to structure applications. One might be intimidated by that.

For example here or here or here or here.

Some criticism is justified, some not. I’d say: If your requirements call for a SPA, go for it.

Error Messages could be better

Looking at this:

Error: [$injector:unpr] Unknown provider: PageSizeServiceProvider$injector/unpr?p0=PageSizeServiceProvider%20%3C-%20PageSizeService
at http://localhost:8000/app/vendor/angular.js:78:12
at http://localhost:8000/app/vendor/angular.js:3705:19
at Object.getService [as get] (http://localhost:8000/app/vendor/angular.js:3832:39)
at http://localhost:8000/app/vendor/angular.js:3710:45
at getService (http://localhost:8000/app/vendor/angular.js:3832:39)
at invoke (http://localhost:8000/app/vendor/angular.js:3859:13)
at Object.instantiate (http://localhost:8000/app/vendor/angular.js:3880:23)
at http://localhost:8000/app/vendor/angular.js:7134:28
at link (http://localhost:8000/app/vendor/angular-route.js:913:38)
at nodeLinkFn (http://localhost:8000/app/vendor/angular.js:6579:13)

a seasoned Angular Developer might guess what the problem here might be, but a beginner is put off.  In this more or less trivial example the provided Error website (great idea!) works fine, but often times the provided website was rather misleading.

REST Backend

If you are not able to provide a REST backend (that speaks JSON) to your data, things might be a bit harder. $resource and friends assume you use REST. I don’t know if there is an elegant way to access SOAP backends.

Forced to be asynchronous ($resource)

Speaking of $resource: Angular proposes the usage of asynchronous resource access. Though I think this is good after all, many beginners (me included) wished to have synchronous way to access a resource, to get an easy headstart.

But hey, jQuery does this as well.

Writing directives is not exactly easy

Directives are a powerful concept and it’s surely possible to master them, though I haven’t grokked them in their full glory yet (what the heck is transclusion? ;)).

For example: I always wonder what the syntax might be to bind the directive to attributes and element?

Not exactly intuitive.

Lately I’ve seen directives as a first code example in a beginners talk. Might not be my first choice.

Besides the official docs I enjoyed reading this and this.

Vast forest of third party components

Lately covered by this article. Though I tend to disagree with a fair bit of this article, I think there may be a point here.

There are third party components for every scenario you might think of. It’s not easy to review them all. Some are very good some are of poor quality.

But on the other hand there are components for every scenario you might think of. An active community is a good thing after all

Usage of jQuery can be inconvenient

This seems to me like a minor issue, but I include this anyway:

If you want to reuse some functionality supplied by jQuery or jQueryUI chances are that this will not work out-of-the-box. A colleague of mine wanted to reuse a DatePicker iirc and he spent a day integrating it. But most of the time, there will be some already built Angular Directive that will help you.

Math.round seems not to work in templates directly

Another more or less minor issue: Though you can use some JavaScript expressions in your template. We stumbled upon a tiny glitch (really?). You cannot use Math.round directly. We solved by using a controller function, a filter might be another solution.


So, if you kept reading until now, thank you very much! I didn’t expect this article to become this long. ;) Stay tuned for the good parts part ;)

WJax 2014

Well, first of all, thanks to @rheinjug, for providing me with the tickets, I’ve won! Yeah! ;))

For me conferences are always a good time, and I really like the energy and inspiration I draw from a conference. And WJax was no difference!

Let’s dive right into of what I saw at WJax 2014.

The basics

It’s quite a large conference in a large venue, I would guess around 2000 people there. The overall setup was very good: Large enough rooms, little technical difficulties, good tram connection, nice food, not that much queueing up and acceptable WIFI coverage. Have seen this far worse, thumbs up!

Sadly the conference was overshadowed by a strike of the german train union, so lots of people had some difficulties getting back home. Quite some conversation went about that. But the organizers did a good job communicating this and trying to leverage things.

The topics


The main topic this time was ‚Microservices‘ and all the things buzzing around that term: Docker, DevOps, Cons/Pros of the Application Server.

I think the idea of Microservices sounds quite appealing: Small, self-contained and focussed applications.
One the one hand Microservices might help you prevent monolithic architectures, allow you to establish quicker turnaround times and give you and your team some sort of organisational independence,
On the other hand, if your system consists of too many Microservices you might experience something like a Microservice hell.
Newer companies like Etsy, Netflix or Groupon use and/or coined some of those microservicy ideas.
Stefan Tilkov did a very good one about this. He presented ideas how you can borrow some of these newer architectural approaches in an existing enterprise world. Liked that. I think we will stumble upon some of those concepts sooner or later.

Docker provides tooling to assist you in achieving quicker turnaround times for your applications. It allows smart packaging of your application and its context (i.e. OS), so you could take your application (and its container/os) from your dev box to your staging and production environment.
Loads of talks about that. There seem to be rough edges here and there (Continuous Delivery tool support, dealing with databases, clustering, etc ), but nonetheless a very influential and promising tool. It naturally shines, when used in an DevOps environment.

The discussion about whether we still need an application server or not is closely related.
On the one hand people argued, that the application server provides a stable ground, which may need some refinement here and there.
On the other hand people said, the application server is too big, needs application specific adjustment anyway, does not allow you to port a random JEE application, that vendors are too slow, etc.
Some kind of middle ground was the notion to use a plain tomcat with spring, instead of waiting an average of 3 1/2 years to be able to use a newer JEE version.

One surprising outcome for me was, that most people on this conference agree on the 1:1 relation between an app and an appserver. Given that it would not be a harsh step to embed some kind of server in the application itself.

Some talks dealt with REST and Hypermedia. Learned how this could make your application logic more transparent. Things seem to be a little rough and ‚in progress‘ in that field.

I somehow managed to miss the talks dealing with ‚reactiveness‘ altogether. Important topic. Shame on me.


Though there was a JavaScript day I would have expected a little more buzz around AngularJS and JavaScript.
I saw an interesting talk how to combine AngularJS and TypeScript. I like how TypeScript provides with optional typing, the usage with AngularJS seems a little clunky to me. AngularJS 2.0 seems to go that way, we will see if that feels better.

I missed one talk that summarized the current state of JavaScript development.  Did not sound promising looking at the abstract, but reviewing the slides, it seemed to have been great.

Non Dev stuff

Two of the best talks I saw at WJax were both dealing with non dev stuff.

One talk by Elmar Jürgens was about the proper usage of quality measurement tools and processes in your project: Use simpler metrics, don’t control the developers, don’t show quality numbers to management unless you provide context to those numbers. Entertaining talk and well done slides!

The other talk by Stefan Toth was about architectural decisons and how you can defer them. It presented no fundamental new insights, but it showed the idea to explicitly use and try to extend a learning phase, to make your decison more elaborate. You will know more about your project as time passes by. Also very entertaining talk and great slides! Thanks to Stefan Zörner for pointing me at this talk.

Java 8 / JEE 7 /Spring

Quite some talks, but I felt that I heard most of those topics elsewhere. An interesting one by Lars Röwekamp questioned existing JEE Patterns.
I am a little bit tired of Java 8 and JEE7 talks. I want to finally use it in everday work. And it seems to me that I am not alone in that.
Not that much on Spring, though Spring Boot (a way to build self-contained applications) looks promising to me.

Alternative Languages

Is saw very little on alternative JVM languages, though I heard a good talk by Silvia Schreier and Philipp Schirmacher about real world Clojure. I always wondered how Clojure would work in an ordinary web app. This talk showed it and saved me some time.

What else

Other notable bigger topics, that I not dug deeper into were the Internet of Things (IoT) and white collar stuff like BPM and friends.

The conclusion

Hell of a lot of talks. It was a difficult decision all the time, I probably missed some more good ones.

Less geeky than for example Devoxx, more focussed on business IT. Which could be either good or bad. Though I appreciate the nerdy and perhaps more visionary approach of other conferences, I liked the „down-to-earth“ (if you might call it so) approach. The attendees seemed to work in similar contexts. So I could connect to most of the experiences that were presented. I would definitely go there again, if getting the opportunity.

What is a unit?

Recently we had a discussion in our team regarding good testing practices (again) :)
With this post I try to summarize this discussion for myself.

The system under test

We were developing a piece of software exposing a REST-Interface using Spring for all kinds of things (REST-communication, DI, Hibernate integration, etc.)

Many of the tests already in place made use of the SpringTestRunner. Most of these tests were declared ‚unitests‘. I did not regard this as a good practice using test which boot up Spring (and quite a lot of the adjacent dependencies of the springbeans) as our lowest level of tests. Some team members defended those tests as it is the most convenient way for them to write tests. Anything less was not regarded helpful to show any meaningful failures.

In my book a unit test does not need the presence of a containing framework. The test take less time and you can express your dependencies more clearly when you state them explicitly. It helps me to mock out those dependencies if I don’t need them in my test.
Spring should only help to glue those pieces seamlessly together.

But we thought this may not be a Spring issue, so we tried to take this discussion to a more general level.

Taking it to a general level

Basically it boiled down to the questions:

  • How do we test?
  • In which extend do we test each layer?
  • Of which granularity should our tests be?

We agreed to some extent to applying TDD and
having read [Growing Object-Oriented Software, Guided by Tests]1, we assumed we had a similar understanding of what ‚testing‘ means regarding that context.

To quickly summarize [Growing Object-Oriented Software, Guided by Tests]1:
The book describes two essential feedback loops:

  1. One outer loop, containing the acceptance tests
  2. Several inner loops containing the unit_test

Comparing our way we drive development by tests, we encountered subtle differences

  • I put more emphasis on the unit test
  • My teammate put more effort in acceptance tests or coarse grained tests, as the seem to have more realworld value

To understand where this difference might come from, we got back to the picture (pictures do always help, don’t they ;) of the TestPyramid:

  • In my case it took the form of the pyramid, putting most emphasis on the unit layer.

unitTest PostingPyramide

  • In his case it took the form of a diamond, having more enphasis in the middle layer.

unitTest PostingPyramide2

As one result my teammate stated, he was not fond of the term ‚unittest‘ as it is too vague for him. In his eyes it could mean anything. It may even be a strictly technical term derivied from the TestRunner, as a testcase is often implemented as a JUnit Test (yes, we have a Java background). So every test done by JUnit could possibly be regarded as a Unit test.

I disagreed and insisted that the term Unit in Object-oriented software is commonly defined as of being the class you’re looking at.

He proposed a different term for that matter.
For above reasons i rejected this for now as I saw no need for another overloading of words.


As we didn’t come to a conclusion, we agreed on doing do a short survey in our team, and possibly elsewhere, stating the question:

‚How do you define the term unit in Object Oriented Software?‘

As a result we had (surprisingly) many definitions of „unit“

  • Everything run by JUnit
  • Unit is a class
  • Unit is everything
  • Unit is not defined

I took this discussion outside of our team and asked the same question. While some quickly replied with ‚A unit refers to a class in oo‘, I got one rather interesting definition:

@DerTeta said:

Everything that has an interface I can write tests
against. Have hit the occasional wall with this
definition, though.


If I can test it in isolation (i.e., without db, etc.) I
consider it a unit. Anything else is blurry.

While I question part one of this statement. (A UI has an interface but tests using this interface are mostly no unit tests), part two is rather important to me.
A unit test with all its dependencies mocked out is clearly tested in isolation23. It depends on the thing and the intent of your test, how much you loosen this isolation statement. You may not need to mock out your domainmodel, perhaps you don’t need to mock out some other helper structures, if they don’t blur the intent of your test. But things like a DB, a service call, a complex algorithm or be it some framework dependency (JSF or maybe Spring), might violate the isolation of your test to some degree and possible test failures might be harder to spot.

Coming back to the starting point

I still don’t think that the SpringRunnableTest serve a good purpose as a unittest, when you apply a TDD approach. They come with a additional load and for many testcases you don’t need Spring in place, though it might it might come handy at times that your dependencies are kicked in externally. I still do like them, when used in higher layers of the testpyramid.

If the part you are about to build is not that complex – say some more straightforward CRUD part – SpringRunnableTest (as a more diamond like approach) might serve you well.
Also if you do prefer a more ‚acceptance-test-centric‘ approach (with Spring in place and the testconfiguration at your service), you might treat and design them in a unittest-like fashion.

But I’ve often seen those tests degenerate from a unittest to an integration test (yet still be named unittest), becoming dependent on the outside world and becoming slower and more brittle.


Another colleague showed us a handy technique using Mockito that I haven’t come across yet (Though I used mockito before, shame on me!). To avoid Spring dependency injection, and to avoid handrolling all your mocks Mocktio comes with a similar feature, that allows you to define mocks and inject them in a more concise manner link.
I kind of like this approach, but some of my initial criticism kicks in here as well. The definition of your dependencies becomes more implicit. But compared to starting up Spring this approach seems to be way faster and your tests become more readable.
What about isolation? As I see it, my CuT is still run as isolated as done without mockito-trickery, only your test-class becomes dependent on mockito.
This may be the best of both worlds, let’s see if this technique helps that a unittest remains a unittest over time.

  1. „Growing Object-Oriented Software, Guided by Tests“ 
  2. „Martin Fowler, Mocks aren’t Stubs“ 
  3. „The Art of Unittesting“ 

My personal IntelliJ top features

I have been using Eclipse more or less heavily for the past 10 years now.
For my last project I decided to give IntelliJ a spin. And as it turned out, I like it! IntelliJ does many things a little bit better than Eclipse.
This list should highlight those ‚little things‘:

  1. Maven Integration
    • Maven Integration works smoothly, unmatched by Eclipse
    • Maven is mostly hidden from you
    • If you have to use maven, there is comfortable tools support
  2. Jump to test
    • Quickly see related tests for a class
    • Nice companion for tdd
  3. Find resource
    • Nice in Eclipse, this really feels like Spotlight/Alfred on Mac
  4. Live templates
    • Quickly generate boilerplate code
    • More poweful than Eclipse
    • Extensible
  5. Code Completion everywhere
    • Even in the debugger view!
  6. Facelets editor Smooth code-completion based on taglibs
  7. Spring editor: Show resolved property from config
  8. Team city integration: Pre Tested commits/Run test locally
    • Keeps your repository clean
    • Less broken builds
    • The option is quite hiddem
  9. Subversion: Show Outdated version while editing
    • Quickly see you might want to update this file
  10. Analyze
    • Quickly do a static analysis of your code
    • Built in
  11. Handy shortcuts to extract an expression to a variable/method, or class
  12. Variable name guessing mostly works
    • If you assign a method to a variable for example
  13. Bind constructor parameters to fields
    • And create getters/setters on the fly
  14. IDE Chat: Quickly send code pointers to your team mate
    • Based on jabber
    • Worked out-of-th box, no need for a jabber server
  15. SQL Editor: Run SQL to:
    • Surprisingly good
    • Tools like SQLDeveloper are needed only occasionally
  16. Code folding using anonymous classes
    • Almost feels like closures (#prejdk8)
  17. Encoding Support: – Properties (native to ascii)
    • no \u…
    • Notices you if the encoding of your file is wromg
    • Helpful info in the statusbar (a little small though)
  18. Deployment
    • Run script beforehand or after deployment
    • Possible to manually tweak artifacts
  19. Server Support
    • Set PATH variables
  20. Structural Select (Ctrl-w)
    • Do complex search and replaces
  21. Fun!!
    • Yes experimenting with IntelliJ was fun
    • Less cursing than eclipse
  22. Add Missing Switch Branches
    • When using enums
  23. Very good diff tool
  24. Fast svn updates via patches
  25. Fullscreen Support
  26. Darcula Theme
    • I like it, some don’t
  27. AspectJ Support
    • Show active aspects of a method, or related methods to an aspect
  28. JPA Support
    • JPA console (Send JPA queries, to the DB)
    • See connection of JPA class to DB table (complains, if theres is none)
  29. XML Editor
    • Very good XPath support (Show XPath of this node, apply XPath on document)
    • XML Refactoring
  30. Refactoring Support für POMs
    • Looks for changes in other pom-files
  31. Emmet Support

Oracle SQL Syntax

As I tend to forget the syntax of Oracle SQL commands, I will write them down here, every time I have to look them up. Beginning now:

Turn off variable replacement in SQL+

set define off;

Add Column

alter table <tablename> add <column_name> <column_datatype> <column_constraint>


alter table test_table add property varchar2(255) NOT NULL;

Drop Column

alter table <tablename> drop column <column_name>
Also look here.

Rename Column

alter table <tablename> rename column <column_name_old> to <column_name_new>;

Modify Column

alter table tablename modify darfabgerechnetwerden null;

Using SQL+ Command Line tool


connect scott/tiger

Excecute a sql-file

also see this


Hibernate SequenceHiLoGenerator

Recently I digged a little in the mechanism of our ID generation.
One of our IDs was annotated like this:
@GeneratedValue(strategy = GenerationType.SEQUENCE, generator = "myIdGen")
@SequenceGenerator(name = "myIdGen", sequenceName = "MY_SEQUENCE")
protected Long id;

But seemingly the underlying (Oracle-)sequence remained untouched.
On an empty DB, with a sequence value of 1, the id that was returned by:
Serializable id = this.getHibernateTemplate().save(domainObject);
was 50. Strange! I would have expected: 1.

The Logfiles then hinted me, that Hibernate chose the SequenceHiLoGenerator for ID Generation.

Looking through the web here, here and here , I came  close to understanding the algorithm.

The idea is to not touch the DB everytime an ID is needed but to „reserve“ a block of numbers, using 50 as a default block size. Reservation is done by: 50*CurrentSequenceValue. Then Hibernate adds 1 to this base value everytime a new id is needed. When it has added 50 times, a new block is reserved using a fresh sequence value.

Perhaps this picture makes it clearer:

All of this configurable of course. I am a little surprised that this is the Hibernate default though.


JMS Fun in JEE Wonderland

Recently I had to dig into JMS to implement some asynchronous behaviour in our current application.
I haven’t used JMS thus far, but it looked quite promising and straightforward to me.
I got the ConnectionFactory and queues working quite fast and the first messages appeared in my queue. Horray!
To consume those messages I had to implement a MessageListener which looked something like this

name = "MyQueueListener",
mappedName ="jms/MyQueue",
activationConfig = {
@ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue")}

public class MyQueueListener implements MessageListener {

private IMyStalelessSessionBean myStalelessSessionBean;

public MyQueueListener () {}

public void onMessage(Message message) {
//Consume my message

public void IMyStalelessSessionBean (IMyStalelessSessionBean myStalelessSessionBean ) {
this.myStalelessSessionBean = myStalelessSessionBean ;

Looked quite ok to me, deployment on the Weblogic server went well. So I should be ready to rock!
But, after I put something meaningful in my queue, onMessage() was not called, instead I was greeted by:

#### <> <> <> java.lang.IllegalArgumentException: argument type mismatch.
java.lang.IllegalArgumentException: argument type mismatch
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(
at sun.reflect.DelegatingMethodAccessorImpl.invoke(
at java.lang.reflect.Method.invoke(
at com.bea.core.repackaged.springframework.util.ReflectionUtils.invokeMethod(
at com.bea.core.repackaged.springframework.jee.inject.MethodInjection.apply(
at com.bea.core.repackaged.springframework.jee.inject.Jsr250Metadata.applyInjections(
at com.bea.core.repackaged.springframework.jee.inject.Jsr250Metadata.inject(
at weblogic.ejb.container.injection.EjbComponentCreatorImpl.injection(
at weblogic.ejb.container.injection.EjbComponentCreatorImpl.getBean(
at weblogic.ejb.container.manager.BaseEJBManager.createNewBeanInstance(
at weblogic.ejb.container.manager.BaseEJBManager.allocateBean(
at weblogic.ejb.container.manager.MessageDrivenManager.createBean(
at weblogic.ejb.container.pool.MessageDrivenPool.createBean(
at weblogic.ejb.container.pool.MessageDrivenPool.getBean(
at weblogic.ejb.container.internal.MDListener.execute(
at weblogic.ejb.container.internal.MDListener.transactionalOnMessage(
at weblogic.ejb.container.internal.MDListener.onMessage(
at weblogic.jms.client.JMSSession.onMessage(
at weblogic.jms.client.JMSSession.execute(
at weblogic.jms.client.JMSSession$

IllegalArgumentException while calling onMessage! WTF! I was quite lost!
Tweaked the @MessageDriven-annotation and doublechecked the correct signature of onMessage. But no success!
After a while I set an ExceptionBreakpoint for IllegalArgumentException and found myself in the middle of JEE internals. Reflection all the way!

Eventually I found the culprit:
The stateless session bean I wanted to be injected seemed to be null.
Removed that code temporarily. And bang! onMessage was called. After fixing the injection everthing worked well.

But to cut a long story short:
What does an IllegalArgumentException do to help me under that circumstances. My mistake had no obvious connection to the onMessage-method.
Something more meaningful would be highly appreciated and would have saved me a lot of time.
But still it is always a little fun to me, to finally get my head around something like that ;)

EclipseCon 2011 Session proposed

I managed to propose a session for the EclipseCon 2011 conference the last minute.
The talk will deal with ouir experiences while implementing a Rich Client based on Eclipse RCP.
The decision if it will accepted is announced on September, 1st. So keep your fingers crossed. I am excited already! And a little nervous ;-)
Here is a link to the proposal.