[jboss-user] [Installation, Configuration & Deployment] - Re: Classloader separation between Webtier, EJBs and Contain

[worenk]

"asack" wrote : You can turn off JavaToParent delegation via a JBoss XML parameter (forgot what it was but look up ClassLoading in the WIKI Knowledge Base under the application server portal page) which may get around it, not sure.

I tried this by adding 

<loader-repository>
  |     com.my:loader=my-ear
  |     <loader-repository-config>java2ParentDelegation=false</loader-repository-config>
  | </loader-repository>

to my jboss-app.xml.

anonymous wrote : 
  | Andreas, its good practice to not have the same classes laying around in different deployable entities (because to the classloader they will BE DIFFERENT classes causing all kinds of havoc).

Problem is that our J2EE come from a separate deployment environment, where everything is perfectly isolated by different JVMs. Of course in such an environment, some classes must be duplicate (e.g. EJB-client classes). Also, we have different versions of 3rd party libs in webtier and EJB tier.

anonymous wrote : 
  | What you SHOULD DO is turn on EAR isolation/call by value during JBoss install (or edit the deployer.xml file afterward) so EARs are at least scoped.  
  | Besides being scoped, you can use JBoss specific parameters to setup a classloader repository per EAR (though if they are scoped, I'm not sure why this is neccessary).

I tried this, but I always get an exception on EJB invocation:

Caused by: java.lang.ClassCastException: $Proxy80
  | 	at $Proxy56.create(Unknown Source)
  | 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  | 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
  | 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
  | 	at java.lang.reflect.Method.invoke(Method.java:585)
  | 	at 
  | org.springframework.ejb.access.AbstractSlsbInvokerInterceptor.create(AbstractSlsbInvokerInterceptor.java:174)

I'm using Spring's SimpleRemoteStatelessSessionProxyFactoryBean pattern on the client side, but the DTOs that are being marshalled should not be replaced by a proxy, only the business interface itself. Strange.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3966667#3966667

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3966667