[douglm]

I'm surprised we're not hearing from more people, but possibly people are concerned that they are at fault, and certainly suggestions that we don't know how to package stuff are unhelpful in that respect.

Maybe it would help to work the other way, show how we are packaging apps and ask, is it wrong, outside the spirit of j2ee or better done another way.

As an example of how we package many of our applications, we have a back end ejb component, usually one session bean, a number of entity beans which communicates with it's callers using value objects. The value objects and entity beans are usually based on a common class.

Front ending that we have zero or more application front ends.

For the one back end we may have a general web client, maybe authenticated, maybe not, which provides the service to the user community. There might be an administrative authenticated client and maybe some runnable app. For database driven applications that app may provide dump restore and bulk update facilities.

Furthermore, we have a small number of session bean based modules used throughout by many of these applications. For example, there is one which provides a front end to email services to package up messages in a manner appropriate for this institution.

All of these applications use utility classes, most use databases, some are clones of each other with build time parameters setting ejb references, entity references and the like.

They are all interconnected through ejb refs. Performance has never been a problem under 2.x.

We have one undeployed app which may show very high usage. We held off deploying till 3 because we intend dealing with performance issues by clustering, i.e. buy more hardware.

We absolutely have to be able to redeploy one of those applications without disturbing the rest. By an app I mean the session bean part + it's associated front end components.

However, there is no meaningful way for us to partition these off from the rest because of the use of ejb references to shared modules.

It may be there is a way to configure our modules and/or jboss to allow this but my experience has been otherwise.

None of this is to say that the UnifiedClassLoader is a bad thing in itself. For situations where performance is critical it's probably a very good thing. But I'm convinced we need something that's as flexible as the 2.4 world was if we are to be able to continue working in the jboss world.

[nathancblair]

Hi,

I believe you can get around this problem by specifying a loader repository in your .ear's jboss-app.xml. I used this successfully a while back to get around a castor conflict (somewhere around 3.0.1 or 3.0.2 I think).

Have a look at the ClassLoading manual, pg 59-60.

Hope this helps
Nate

[douglm]

I think this works if you can identify a group of ears that will al be deployed together and have no interactions with other ejbs.

However, most of my ejb modules refer to shared ejb modules so we're back to rebuilding and redeploying everything (I think).

I've tried to get this to work resulting in all the CLassCastExceptions that others saw.

If anybody has managed to deploy and redeploy a large number of independent ejb modules with different versions of the same classes on their class paths on 3.2 (or I guess 3.0.6) please speak up and show us your config.

[aanno]

Dear Pra,

thank you for joining in. There is still no consensus on this forum if there is really a problem with the JBoss ClassLoader but anyway, I like to elaborate on my ClassLoader/Dependency idea.

First of all I have to admit that I don't tried the ByValue Invoker. I strongly believe that it doesn't work because of the problems you mentioned. But apart from that I still think that a WORKING ByValue Invoker would help JBoss a lot. It would sacrifice performance but would improve compatibility. It would be nice to see a working ByValue Invoker implementation in JBoss4. Anyone interested in writing one?

My ClassLoader/Dependency solution will not solve the problem in all situations. But I believe that it will solve the problem in most of the 'real world' cases. (For the more obskure cases, there should be a ByValue Invoker, see above.)

I'm thinking of a solution that works with the standard (one) parent ClassLoader solution. Sticking to the problem you have drafted, however, I can't see the point. For me, it seems quite possible to solve that the standard way.

The hierachy seems to be the following D -> (B && C) -> A, where '->' is for 'depends on'. The ClassLoader hierachy could be d -> b -> c -> a or d -> c -> b -> a, where '->' is for 'parent ClassLoader' and normal association is from right to left.

At first glance it seems difficult to get this kind of dependency right and unique, especially if the components are deployed one after another. However, If we would successfully implement dependency tracking, this magic is possible as well. The trick is to redeploy some components at the 'right' time if other are added.

To be more concrete, we would proceed like this:

Components deployed | ClassLoader hierachy | Resulting redeployment of
---------------------------------------------------------
A | a | none
A B | b -> a | none
A B C | b -> a && c -> a | none
A B C D | d -> c -> b -> a | C

Kind regards,

aanno

[douglm]

Our situation looks more like

(D && C) -> B -> (X && Y && Z)

(P && Q) -> R -> (X && Y && Z)

and so on. All use utility classes u. Just because I build P, Q, R with a different build of u shouldn't force me to redeploy X, Y, Z?
Worse still it percolates back up making me redeploy B, C and D, MNO EFG...etc etc. And all that without any change to the visible interfaces between those components.

It seemed to me that the dependency we had to concern ourselves with in 2.4 was the contract between the modules as defined by the EJB interface.

Now we have to worry about all our 'private' classes being compatible.

One concern I'm having is that it looks like we all have to become classloader experts to make this work.

I suspect there are at least two different views of the j2ee world. My viewpoint, (and what I had assumed was the spirit of j2eee) is that we are working in a system, much like an OS, with cooperating services, modules whatever, defined only by their interface to the outside world as represented by the EJB interface.

Others seem to view a jboss instance as a monolithic whole, one giant 'program'.

I'm not trying to suggest that either approach is wrong but that the modular approach is necessary for us to be able to develop and deploy in parallel. I view deploying an application as much like installing a program in linux/unix.

aanno is right to say there's no consensus on the rightness or wrongness of this approach, maybe because they're both right and maybe they're both necessary.

I'd love to move forward with this. I'm very anxious to get into the 3.x world. As it is I had to retrofit the latest jetty in 2.7.

[pra]

There IS a problem with the classloader architecture; why would it have to be retroifited between every 3.0.x release if it was not? Why would this thread exists if it was not.

In my view it is even severly broken. I remember back when Richard Öberg had to battle the tomcat people to make them understand that they should use the context classloader and not Class.forName; but do you know: the current classloader repository arhcitecture has actually reinforced the Class.forName semantics in its classloading scheme. So yes, it is broken. However, having done a lot of work with the classloading in 3.0 I am now possitively shure of that the solution is solving the classloading scheme in itself. The problem is that Marc and others did away with Richards J2EE/EJB spec compliant way of doing invocations.

I have now browsed through the 2.4 code to see how he did it and I think that the most reasonable way of solving this is to write a more intellient EJB spec compliant LocalInvoker.

The deal would basically be to ckeck if the UnifiedClassloader3 of the calling thread belongs to the same repository as the URL3 of the container (MBean) the invoker will invoke. If and only if this is the case a local optimized call is allowed; othervise a MarshalledInvokation, through a MarshalledObject should be done. The tx problems could probably be solved by keeping the tx outside of the serialization and reinstating it on "the other side".

The trick here its to get at/save the target component repository (quite easy for EJB, a little bit harder with the current invikotion of MBeans).

JNDI would probably to have to take a change in the same way: when an object is looked up; the same check will happen (is the respoitory of the calling thread the same as the repository of the thread that bound the object: if not marshall).

It this way we could basically skip the classloader issues (and I can say thay are hard to work with; the smallest changes triggers large changes) and focus instead on how interfaces are made available to other components.

Unfortunately I don'tthink I will have time to test this lane the next couple of weeks; but feel free to test it and I might be able to lend a hand.

//Peter

[aanno]

Hello,

well, perhaps I didn't say this clear enough: I was thinking about AUTOMATIC redeployment in my last post.

My answer to cl43 depends on if library U is used in the implementation or in the interface part of the components. If U is used only in the implementation it would be:

Components deployed | ClassLoader hierachy | Resulting redeployment of
---------------------------------------------------------
X Y Z | x | None
. . . | y |
. . . | z |
---------------------------------------------------------
X Y Z B R | b -> x -> y -> z | X Y
---------------------------------------------------------
X Y Z B R D C | d -> b -> x -> y -> z| None
. . . . . . . | c -> b -> x -> y -> z|
---------------------------------------------------------
X Y Z B R D C R P Q | d -> b -> x -> y -> z| None
. . . . . . . . . . | c -> b -> x -> y -> z|
. . . . . . . . . . | p -> r -> x -> y -> z|
. . . . . . . . . . | q -> r -> x -> y -> z|

In this case U (and u) are never mentioned because the different versions of U (and u) are only seen by the 'active' implementation (that is isolated from each others). For example implementation of component B sees the following: (b impl) -> u -> b -> x -> y -> z.

If, however, U is used in the interface part of my ClassLoader idea would FAIL. I still think that the best thing to do in this case is to have a ByValue Invoker at hand.

I never said that that the ClassLoader thing is easy to rectify. It is indead tricky to do it right. I'm not sure that my ClassLoader scheme will work to all users satisfaction. To tell the true I'm not sure if it is a good idea anyway and because of this I put my idea under review here. I like to get the requirements right first place. If this forum is collecting the true requirements of the EJB component behaviour, somebody can come up with the 'real' solution later and is able to verify it against the requirements.

I'm not familiar with the ClassLoader implementation in Tomcat or JBoss 2.4 (but my experience as user tells me it wasn't that better in JBoss 2.4). It will take me some time to get an idea what was tried there...

I doubt about using ContextClassLoader as a Solution to any problem you have with ClassLoaders.

Cheers,

aanno

[aanno]

Epilog (Part I)
======

With the adveniat of JBoss4 the JBoss Group has choosen another path than the one I suggested here. If you are interested you could read about the new ClassLoader technology at http://www.jboss.org/index.html?module=html&op=userdisplay&id=developers/projects/jboss/aop and at http://www.onjava.com/pub/a/onjava/2003/05/28/aop_jboss.html .

When you read about AOP carefully, you must conclude that it will still be impossible to have different version of the same (AOPied) class within JBoss at the same time. This directly implies that all problems mentioned in this thread remain UNRESOLVED.

I think AOP is a complex issue and an interesting idea and I will not juge about its benefits here. But I also see that it changes the feeling of the Java language to something more Smalltalk like. I also expect security issue to arise from AOP and feel that the original hierachical ClassLoader idea of Java is much more save for networked applications.

[aanno]

Epilog (Part II)
======

The main point is still that AOP is NOT COMPATIBLE WITH THE J2EE SPECIFICATION. ejb-2_0-fr2-spec.pdf, chapter 24.2.7, page 500:

An enterprise bean s remote home and remote interfaces are remote interfaces for Java RMI. The Container must ensure the semantics for passing arguments conforms to Java RMI. Non-remote objects must be passed by value. Specifically, the EJB Container is not allowed to pass non-remote objects by reference on inter-EJB invocations when the calling and called enterprise beans are collocated in the same JVM. Doing so could result in the multiple beans sharing the state of a Java object, which would break the enterprise bean s semantics.

[juhalindfors]

What does AOP have to do with J2EE spec in the first place?

[sgodden]

I have to lend my voice to those saying that the current classloader implementation is a critical blocking factor to the use of JBoss in many situations where we would like to use it.

As an ISV serving very large customers with multiple suppliers, synchronisation of the necessary components *will not occur*.
I understand people's desire to have a situation with everyone co-ordinated so that the organised beauty of the perfect solution shines through, but we cannot rely on that happening, and experience shows it will not in practise.

This seems an odd inversion of the "make it work, then make it faster" principle. Imposing limitations to solve a problem by making an optimisation that has not been proved to be necessary. It should work first, then allow us to optmise where that can be safely done.

Classloaders within EARs, Marshalled operations between EARS. I just can't see any other way without, as one poster said, us all becoming classloader experts, which we just can't afford to do. It should not be our concern as application developers.

I *want* to recommend JBoss for production, but increasingly I can't be sure of it. We can use it for development and small customers where we are the only supplier, but no more.

WHAT IS THE STATUS OF THIS? Initially, I care only about a solution that will work.

[chrishumphrey]

what hapened here? The talks seemd to just fizzle out. is there a fix in the works for this?

[brado]

Interesting thread -- I was totally unaware of this discussion, but had come across the same issue and had posed it to one of the JBG guys myself.

Anyway, I am interested in possibly contributing a solution to this problem, but I guess the primary question, as the Classloading scheme is core to JBoss, the better question is: Will the JBoss Group be open to such a change? There is obviously a reason for the unified classloader design, (already stated), and changing it may eliminate that reason. So before spinning my wheels any, will presenting classloader isolation be accepted and integrated, or is the mere idea something that JBG is not open to?

BradO