Hi,
thanks to David, Scott and the others, shared class-loading works now
as expected, but it seems that not all VM-local calls will be
optimized by jboss.
Last week, as I was having troubles with the shared classloader, I
made a quick and dirty workaround for our application. I added our
shared jar, which contains all classes and EJB interfaces except the
bean implementation classes, to jboss's main classpath. The app
consists of two more ejb-jars with EJBs that depend on the classes in
the shared jar. We test the EJBs in our app using JUnit as external
client.
Yesterday I switched back from this workaround, so jboss used the
Manifest-Classpath entries from the ejb-jars to set up the app
classpath. What I noticed is that the tests perform much slower now as
with the workaround. Here are some numbers from a test that creates,
updates, uses, and removes ~50 EJBs, taken on a Linux K7/800MHz with
the latest jboss snapshot:
shared jar on jboss' CLASSPATH:
1. run: 18.8s
2. run: 7.6s
3. run: 6.0s
shared jar on Manifest-Classpath:
1. run: 34s
2. run: 28s
3. run: 26s
It seems to me, that some calls still get marshalled in the latter
case.
Any ideas?
Gabor
--
Gabor Herr [EMAIL PROTECTED]
Computer Science Department [EMAIL PROTECTED]
Darmstadt University of Technology
Germany
