[JBoss Microcontainer] - EJB's and classloading
by Miklos Balazs
Miklos Balazs [http://community.jboss.org/people/mbalazs] created the discussion
"EJB's and classloading"
To view the discussion, visit: http://community.jboss.org/message/578544#578544
--------------------------------------------------------------
Hello!
Sorry for double posting it, I posted this question to the JBoss AS deployment forum yesterday, but I just found this forum and I think that more people read it here who may be able to help me with this.
I have successfully managed to get myself in classloading hell. :) And I would be glad if someone could help me out with this because I couldn't find enough information to resolve this problem. I am using JBoss AS 5.1.
Here is my scenario:
I have two top level EAR's: Service.ear and Application.ear
Service.ear contains an MBean and a WAR, and has no classloader isolation defined or any other classloader settings modified.
Application.ear has an EJB module and a WAR, and has an isolated classloader repository defined in the ear's jboss-app.xml, with java2ParentDelegation enabled.
The problem is the following:
The MBean in Service.ear is an event dispatcher, and the Application.ear's WAR registers an event listener object in the MBean during servlet context initialization. When the MBean dispatches the event, it can call the event listener registered by the application without problems, however, the event listener needs to use an SFSB, and at that point it fails because it can't access the EJB's remote interface:
2011-01-03 16:30:41,856 ERROR [...] (http-droolsdemo-portal%2F172.16.3.28-8080-1) Could not lookup GwtConsoleClient session bean: javax.naming.NamingException: Could not dereference object [Root exception is java.lang.RuntimeException: Can not find interface declared by Proxy in our CL + BaseClassLoader@2296c1d{vfszip:/opt/jboss-epp-5.0/jboss-as/server/default/deploy/Service.ear/}]
(GwtConsoleClient's classes are in the EJB module of Application.ear)
I can see that the problem is that the whole call chain was started from within the Service.ear's context, thus it uses its class loader domain. It is unclear to me that what exactly "BaseClassLoader@2296c1d{vfszip:/opt/jboss-epp-5.0/jboss-as/server/default/deploy/Service.ear/}" means.
Does it refer to a classloader repository?
If this is specific to the new classloading model in JBoss 5, where can I find a decent description of how it works?
Would it resolve the problem if I could somehow delegate the loading of the remote interface to the default classloader, so that that single class would not be isolated? Is it possible to do that?
Regards,
Miklos Balazs
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/578544#578544]
Start a new discussion in JBoss Microcontainer at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
15 years, 3 months
[JBoss Web Services] - Re: jboss6 final and jbossws 3.4.0
by Antoine Brun
Antoine Brun [http://community.jboss.org/people/abr] created the discussion
"Re: jboss6 final and jbossws 3.4.0"
To view the discussion, visit: http://community.jboss.org/message/578778#578778
--------------------------------------------------------------
ok, I'll try with jbossws native 3.4.1 as soon as it is available.
in the mean time, I tried to declare the handler like that:
@HandlerChain(file = "handler-chain.xml")
and I get:
DEPLOYMENTS IN ERROR:
Deployment "vfs:///home/abr/workspace/api/dist/ubi-api.ear" is in error due to the following reason(s): javax.xml.ws.WebServiceException: Could not find the handler configuration file handler-chain.xml specified by @HandlerChain annotation
so next I tried:
@HandlerChain(file = "/handler-chain.xml")
and I get:
DEPLOYMENTS IN ERROR:
Deployment "vfs:///home/abr/workspace/api/dist/ubi-api.ear" is in error due to the following reason(s): javax.xml.ws.WebServiceException: false false Element <?xml version="1.0" encoding="utf-8"?><handler-config>
<handler-chain>
<handler-chain-name>SoapHandler</handler-chain-name>
<handler>
<handler-name>SoapMessageValidationHandler</handler-name>
<handler-class>com.ubiqube.api.ws.soapHandler.MessageValidationSoapHandler</handler-class>
</handler>
</handler-chain>
</handler-config> is not a valid root element in file vfs:/home/abr/workspace/api/dist/ubi-api.ear/ubi-api-ejb.jar/handler-chain.xml
So with CXF 3.4.1the "/" must be there, wheras with native 3.4.0 it was not necessary (note that I did not try with the / and native 3.4.0).
Do you know when the jbossws native 3.4.1 will be available for download?
Another question, maybe you can point me to some doc: why choosing jbossws CXF against native? Is it a certification issue?
Thank you for your time and answer
Antoine
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/578778#578778]
Start a new discussion in JBoss Web Services at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
15 years, 3 months
[JBoss Microcontainer] - Re: How to stop my WAR loading JBoss's provided 3rd party classes?
by Petr H
Petr H [http://community.jboss.org/people/hostalp] created the discussion
"Re: How to stop my WAR loading JBoss's provided 3rd party classes?"
To view the discussion, visit: http://community.jboss.org/message/578813#578813
--------------------------------------------------------------
> You just need to <javabean> the right filter instance. ;-)
>
> e.g. <-- pseudo code -- I need to check this into more details (it's been a while since I wrote this javabean' stuff :) )...
Yeah, something of that sort would do it - CombiningClassFilter::
public static CombiningClassFilter create(ClassFilter... filters) ...
public static CombiningClassFilter create(boolean and, ClassFilter... filters) ...
public CombiningClassFilter(boolean and, ClassFilter[] filters) ...
so passing filters via array would probably work if it's implemented that way. Anyway use of JavaOnlyClassFilter or EverythingClassFilter will still be an issue due to their private constructors.
> Well, the "plain default" knows about deployment type:
> * ear --> isolation --> look locally first == parent-first=false
> * war, which has parent-first=false by default
>
> Whereas jb-cl-domain.xml is deployment type agnostic, hence uses the more natural default.
Right, understood, it's just unfortunate that it's not so simple to change the classloading back to plain ear default then..
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/578813#578813]
Start a new discussion in JBoss Microcontainer at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
15 years, 3 months
[JBoss Microcontainer] - Re: How to stop my WAR loading JBoss's provided 3rd party classes?
by Ales Justin
Ales Justin [http://community.jboss.org/people/alesj] created the discussion
"Re: How to stop my WAR loading JBoss's provided 3rd party classes?"
To view the discussion, visit: http://community.jboss.org/message/578801#578801
--------------------------------------------------------------
> The optimal target would be either to allow for multiple filters directly
You just need to javabean> the right filter instance. ;-)
e.g. <-- pseudo code -- I need to check this into more details (it's been a while since I wrote this javabean' stuff :) )
<before-filter>
<javabean xmlns="urn:jboss:javabean:2.0" class="org.jboss.classloader.plugins.filter.CombiningClassFilter">
<constructor>
<parameter>
<!-- some other filter missing here + some xml syntax -->
<javabean xmlns="urn:jboss:javabean:2.0" class="org.jboss.classloader.plugins.filter.NegatingClassFilter">
<constructor>
<parameter>
<javabean xmlns="urn:jboss:javabean:2.0" class="org.jboss.classloader.spi.filter.RecursivePackageClassFilter">
<constructor>
<parameter>org.hibernate</parameter>
</constructor>
</javabean>
</parameter>
</constructor>
</javabean>
</parameter>
</constructor>
</javabean>
</before-filter>
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/578801#578801]
Start a new discussion in JBoss Microcontainer at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
15 years, 3 months