> On 1.3.1 - re-ran it on 1.4.2 and it worked ... > > Guess the exception on 1.3.1 is different ... Ah well, sorry > to bug you > about it ... :)
I'll try this on 1.3 at some point and see if I can make the test work in both cases. > > A quick question though : As most app. server have class-loading > restricted on a per jar, ear basis, is there a need when > using hivemind to > separate the modules using different class loaders or is it > fine for them > to share one, common one? > > Johan Using the WAR's class loader will give you maximum coverage; the WAR will see the EJBs and the system classpath. The HiveMind library may be on the system classpath or, with difficulty, packaged with the EAR. When constructing the registry (see the "Bootstrapping" documentation) it is possible to load modules from different class loaders. You would need to create new ClassResolver instances and invoke the processModule() method. HiveMind remembers the class loader used for each module, which is necessary when instantiating classes from that module. >-- Howard M. Lewis Ship Creator, Tapestry: Java Web Components http://jakarta.apache.org/tapestry http://jakarta.apache.org/commons/sandbox/hivemind/ http://javatapestry.blogspot.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
