[juha]

However I didn't notice that supposed order of magnitude performance hit that supposedly comes with switching to remote interfaces in my webapps. I suppose it's possible that JBoss is doing some sort of magic and actually using the local interfaces under the cover for me.

Nope, it's just detecting that you're invoking a component within a same process space and decides to pass a reference rather than make a copy of the values and serialize it. That is what the spec formalizes with local interfaces. We don't require them.

It's just another non-standard feature (actually violates the spec too) for sloppy loving people like me. Once you configure that away you'll see your performance drop way down.

You can configure this by setting ByValueInvokerInterceptor into your proxy interceptor stack. You're also going to need it once you have completely isolated your EJBs, as there's no way to share references across classloaders for duplicate class definitions (unless you start building "standard" Java classloader trees at which point you can say goodbye to hot-deploying individual packages of your application).

HTH

[clajoie]

"clajoie" wrote:
So, why can't I use local interfaces? Both the entity beans and the webapps are running in the same VM. If this worked then there wouldn't be a violation of the spec and I wouldn't see a performance hit (because I could use the local instead of the remote interfaces). Also, at that point isolating my EJBs wouldn't be a bad thing either.

[juha]

Of course you can use local interfaces. But local interfaces only work within the same classloading scope. So using local interfaces between servlets and EJBs requires an EAR file at which point you have one single classloader that you must completely redeploy (meaning the whole application at a time).

And yes, isolating your EJB classloader from your servlet classloader is a problem since both classloaders contain the class definitions (you can't pass references but are forced to serialize) so there's no way to use local interfaces across classloaders unless they share a common ancestry that has visibility to classes you share in the components interface.

So either you package everything into a single package (including your servlets, EJBs, MBeans, etc etc) and redeploy entire applications at once, or you use the UCL.

[julien.dubois]

"julien.dubois" wrote:

"julien.dubois" wrote:
Hello everybody,

Juha, you tell us it's "either the UCL, either redeploy entire applications". Well, redeploying entire applications is exactly what I want to do.
I've got an Ant task that create an EAR, and which drops it to the deploy/ directory. That's all I want.
Now you seem to say it's something I wouldn't want to do... Why? Seems to me you're not packaging your apps correctly... You just drop all your jars and wars into deploy/, am I right?

[jim_b_o]

"jim_b_o" wrote:
I really like JBoss but...

I've tried all the workarounds (appart from creating a .sar) mentioned above but can't get my EAR to use the old version of JDOM that is required by some third party utilities. It always picks up the JDOM from the jboss.home/lib directory and I can't replace or remove that because JBoss needs it.

Do I have to create a .sar? Or do I have to go back to using WebLogic?

[juha]

"julien.dubois" wrote:
Well, redeploying entire applications is exactly what I want to do.
I've got an Ant task that create an EAR, and which drops it to the deploy/ directory. That's all I want.

Right, so use a separate loader-repository for your EAR if you don't want to share those classes with anyone else.

"julien.dubois" wrote:

Now you seem to say it's something I wouldn't want to do... Why?

No, I'm not saying that at all. It is the easiest solution if it fits your deployment procedure. But someone may have different needs (they may want to redeploy their web tier but not touch the ejb-tier).

[sprhodes]

Ok, first of all, I just want to say that I think the UCL scheme is extremely , horribly, terribly broken, and I will throw in my "vote' if you will, for a switch of some sort, to allow a more "normal" class-loading scheme in JBoss.

Rant aside, I'm wondering if anybody can help me solve the problem I have right now. I have been forced to package my applications using the "each ear is it's own sandbox" model, to avoid problems caused by UCL. However, with my ear packaged that way, I get about a bazillion exceptions during deployment.... JBoss is apparently looking for some classes related to XML parsing, and either not finding them, or finding the wrong ones. After a deployment, my log is full of errors like:

javax.management.NotcompliantMBeanException: Error parsing the XML file, from XMLMetaData: java.lang.ClassCastException

and

java.lang.ClassCastException at
org.xml.sax.helpers.XMLReaderFactory.createXMLReader( XMLReaderFactory.java:131)

and

org.jdom.JDOMException: Error in building: SAX2 driver class org.apache.xerces.parsers.SAXParser does not implement XMLReader

etc.

So, given the usage of the "sandbox per ear" methodology, can anybody tell me what I need to do to eliminate these errors?

Thanks...

[sprhodes]

Also, can somebody answer me this: Under the "sandbox per ear" scheme, is it the case that the only classes available to your application are the ones bundled in the ear itself?

That is, there's no middle ground, right? It's either UCL where everything is shared, or the other way, where nothing is shared? Or is there a place where I can put jar files so that they are available to all deployed applications - something like the idea of common/lib in a standalone servlet container like Tomcat?

Thanks again...

[adrian.brock]

sphrodes - stop your moaning, the config for scoped deployments could be made
easier, e.g. a global flag

<attribute name="IsolateDeployments">true</attribute> on the EAR deployer.

Having said, I'm not going to answer your questions for three reasons.

1) This is not your thread. There is nothing worse for other people to follow than
long forums threads that go off in all sorts directions because newbies think
their problem is in some way related.
IF YOU ARE NOT GOING TO HELP THE ORIGINAL POSTER OF THE TOPIC
START YOUR THREAD

2) You haven't posted any useful information.
Where is your confguration? You say you have configured a "Sandbox"?
I think I know what you are trying to say, but it doesn't give me any confidence
that you have done it correctly, since it is called a LoaderRepository in JBoss.

3) POST THE FULL STACKTRACE
java.lang.ClassCastException at
org.xml.sax.helpers.XMLReaderFactory.createXMLReader( XMLReaderFactory.java:131
is useless. It doesn't even contain any JBoss code - it lacks context.

Regards,
Adrian

[timothy]

sorry to distrub...

adrian,

can you tell me which config file should i put

<attribute name="IsolateDeployments">true</attribute>

as when i put the attribute to the config file it throw attribute not found exception

thx
From Timothy

[adrian.brock]

Which part about "Don't post on other people's threads" didn't you understand?

To answer your question, that was a suggestion about how the config might be
improved. It does not exist. That is the meaning of the word "could".

Regards,
Adrian

[juha]

I think it's about time to move this thread to the rants category then ;-)

[rhook]

One thing I really don't understand. Why was this discussion moved to be noted a "useless rant". It seems to me to contain a reasoned discussion about some apparent short-falls of the jboss approach to class loading, something that a lot of people are struggling with.

[juha]

Why this thread was considered a rant (wrong forum, non-constructive).

An example of UCL discussion that is constructive and not just a mere rant.

HTH