users@glassfish.java.net

Re: Glassfish classloaders

From: <glassfish_at_javadesktop.org>
Date: Fri, 22 Feb 2008 01:55:37 PST

> delegate = false must always be used with extreme caution, as it can
> lead to nasty ClassCastException.

What would be a scenario where a class cast exception would occur?


> When you specify delegate = false,
> that means the WebAppClassloader prefers classes defined in the war to
> classes defined outside the war. But, if a class is not defined in the
> war, then it eventually delegates up the hierarchy.

Right, that is what we are also gathering from the app deployment guide documentation.


> So, I don't quite agree that with what is documented there.

Do you mean to say that you do not agree with the statement in the app deployment guide stating that you "must" have delegate set to try for a web app to access an ejb?


> If you know you are not
> duplicating local EJB interface classes in your ejb-jar and war, then
> you should still be able to use delegate = false. The key here is that
> you must *not* have classes that are used in the local EJB interfaces
> packaged as part of the war. May be someone can correct me here.

I think that makes sense. Do you mean to say that it should be safe to use delegate=false in the webapp as long as the local interfaces are not included in the webapp?

I think our confusion stems from the documentation. The app deployment guide uses the term "must" in the first paragraph of the delegate attribute description, but then uses the term "safe" in the second paragraph, suggesting that it IS possible to use delegate=false in the web app and still use ejbs from a separate ejb component, but doing so opens up some possible problems.

In my own testing, I've found that setting delegate=false still allows webapps to use the ejbs in just the same way as when delegate=true is set, or the class loader element is omitted altogether. At the same time, a singleton class is actually shared by two web app modules if the class loader element is ommited or set to delegate=true... whereas each webapp has it's own instance of the singleton when delegate=false is set.

In the case of whartung's use of frameworks that utilize singletons in multiple webapps packaged in the same ear, non-delegated classloading is the only way to have it work properly. But sacrificing the use of EJBs is a poor penalty to pay :(
[Message sent by forum member 'philross' (philross)]

http://forums.java.net/jive/thread.jspa?messageID=260396