JavaBean Model Import: when it really works

Preface

There is a plenty of topics on SDN Web Dynpro Java, where developers complain about inability to use JavaBean model import. It stops working magically; it does not see beans from public parts; it starts malfunction after minimal changes introduced in bean etc.

As far as I’m intensively promote using models with WebDynpro programming, making it work becomes a very interesting topic for me. Moreover, in (A)POJO – (Almost)Plain Old Java Objects as model of my first articles I did not explain in details how to use it in NW04 SP10-13 and left incorrect guidelines.

My distribution of NetWeaver contains sources of necessary plugins so I can look what happen behind the scenes. Also I start Eclipse in console mode (remember this “trick”) and a lot of mysterious things come obvious. Sadly, for some reason developers of related plugins prefer to use System.out rather then Eclipse logging.

To manifest or not to manifest

The first thing found may surprise you if you ever try to resolve importing issue: JavaBeans acceptable by import wizard may but not ought to have corresponding JAR manifest entries. I.e. according to JAR manifest file specification it is possible to mark certain classes as JavaBean via the following sections:

Name: com/mycompany/myproject/mymodule/MyBean.class Java-Bean: true

I saw Re: WebDynpro Using JavaBean Model ->Please Help on WebDynpro forum and reproduce it in (A)POJO – (Almost)Plain Old Java Objects as model that having these entries is mandatory. This is not true. Actually, if you mark class as JavaBean it is just automatically pre-selected via import wizard. No more, no less. Moreover, if you in fact create such entries in manifest for all classes in public part, you will be unable to use import wizard due to one pesky bug. So, if you declare as JavaBeans in manifest all classes from public part, create at least one public empty class and add it to public part.

Class loading…

Second source of problems is type of properties (i.e. return type of getters, single argument type of setters). Let me explain this by example.

1. Create a Java DC (A) with one single bean.
2. Add “jms” to Used DCs of A.
3. In your bean create property (along with getter / setter) of type javax.jms.Queue.
4. Add this bean to public part and build DC.
5. Create WebDynpro DC (B).
6. Use public part of DC A in DC B.
7. Start to import JavaBean model.
8. Select public part as JavaBeans source.

Oops! No JavaBeans available for import! How this happens? Look at console (we start Eclipse in console mode for troubleshooting, aren’t we? ;). You see that javax.jms.Queue mentioned in stack trace. Yep, this is the root of problem.

When import plugin scans for properties it hits unknown class. Obviously, this hardly could be claimed as bug – the only class path available to plugin contains of a) core (system) Java classes; b) current project; and c) public part JAR. And no one has javax.jms.Queue declaration.

The solution is obvious: just add “jms” to Used DCs of B (WebDynpro DC), reload project (restart IDE as option of last resort), and re-start import wizard.

Conclusion

This is all known to me issues with JavaBean model import wizard. If you come around any new one, please feel free to left comments to this post, or… welcome to SDN Web Dynpro Java 🙂

Next time I will explain how to alter DC build process to let you include your own manifest entries in generated public part JAR.