-
1. Re: Visibility of several (versions of) jar's in JBoss EAP 5.1
alesj Dec 12, 2011 8:07 AM (in response to simon_jongsma)Can you help us? It’s rather urgent; our development time window ends this week.
Since this is EAP, I suggest you use JBoss Support.
That's the easiest way how you get urgent things done. ;-)
-
2. Re: Visibility of several (versions of) jar's in JBoss EAP 5.1
simon_jongsma Dec 12, 2011 8:25 AM (in response to alesj)Thanks Ales,
We were walking that road that anyway..
But if you know the answer beforehand I would be grateful.
Regards,
Simon
-
3. Re: Visibility of several (versions of) jar's in JBoss EAP 5.1
alesj Dec 12, 2011 11:52 AM (in response to simon_jongsma)At the same time F ear now contains a class "com.getronics.slg.civmk.common.jaas.listener.CivisionSessionListener"
that we want to be visible for ear’s A through E.
If it wasn't for this, then it would be pretty simple to do this -- simply putting F into own CL domain, with DefaultDomain as parent.
But with this, it means that A-F still need to be in a shared CL domain.
Let me think about this ...
-
4. Re: Visibility of several (versions of) jar's in JBoss EAP 5.1
alesj Dec 12, 2011 12:02 PM (in response to alesj)For F: perhaps try to avoid big-ball-o-mud, and filter out the xxx.jar from ext delegates.
This is the code in BaseCLDomain that should help:
if (policy.isImportAll()) allExports = true; } // Next we try the old "big ball of mud" model if (allExports) { loader = findLoaderInExports(classLoader, name, trace); if (loader != null) return loader; } else if (trace) log.trace(this + " not loading " + name + " from all exports"); // Next we try the imports if (info != null) { loader = findLoaderInImports(info, name, trace);
-
5. Re: Visibility of several (versions of) jar's in JBoss EAP 5.1
simon_jongsma Dec 13, 2011 3:14 AM (in response to alesj)Are you suggesting that I do a extend/override on the JBoss class loading?
I'm new at this..
Can you elaborate a bit: which class I need to subclass/override & how I could do this?Thanks in advance!
-
6. Re: Visibility of several (versions of) jar's in JBoss EAP 5.1
alesj Dec 13, 2011 3:31 AM (in response to simon_jongsma)Are you suggesting that I do a extend/override on the JBoss class loading?
No. :-)
I was thinking of having a proper jboss-classloading.xml configuration.
e.g. import-all=false, right requirements, etc
-
7. Re: Visibility of several (versions of) jar's in JBoss EAP 5.1
simon_jongsma Dec 15, 2011 9:15 AM (in response to alesj)For your info:
We were able to solve this by isolating the Fear adding a jboss-app.xml and a simple loader-repository entry there.
In the F ear is a top-level lib directory with our xxx.jar version 1,0.
xxx.jar 2.0 is in the lib directory. The other ear's no changes.
The visibility of the CivisionSessionListener class is not solved yet (needed for Shiro single-signoff).
Could that be arranged with jboss-classloading.xml? Can you provide an example?
Besides this:There were some plugin jars that needed to be outside the ear (must be customizable).
These were callable but could not talk back to classes inside the ear.
We were able to solve this by loading these separately using raw byte streams (nasty but effective).
-
8. Re: Visibility of several (versions of) jar's in JBoss EAP 5.1
alesj Dec 20, 2011 12:30 PM (in response to simon_jongsma)Isolating F helps with seeing the x.jar v1.0 first.
But that hides the CSL class.
Those jars should be able to see classes from A-E, if they are not .war classes.
Ah, direct streams, it always helps. :-)
Hopefully I'll find some more time soon to check how to do proper solution.
I will have to be "OSGi"-like in order to work w/o hacks.