On Thu, 2003-10-09 at 13:31, Stephane Nicoll wrote:
> Thanks Adrian,
>
> No, we used the standard axis distribution before and hot deployment went
> fine. It's new since we moved to JbossNET and .wsr files. Could you please
> give more details about your experience (i.e. guidelines to fix the problem
> like you did)
I debugged the RMI classloader by installing my own wrapper
using RMIClassLoaderSPI
You could try the same using the JBoss classloader, but I doubt you
can intercept Class.forName caching.
When you get the class that fails, before passing it to narrow()
run it through something like the following code (not tested or
compiled):
// Lookup
Object obj = context.lookup("whatever");
Class clazz = obj.getClass();
// Dump class and classloader heirarchy
System.out.println("Looked up class: " + clazz);
System.out.println("Id: " + System.identityHashCode(clazz));
ClassLoader cl = clazz.getClassLoader();
while (cl != null)
{
System.out.println(cl);
cl = cl.getParent();
}
// Load the class as seen by this deployment
cl = Thread.currentThread().getContextClassLoader();
System.out.println("My classloader: " + cl);
clazz = cl.loadClass(obj.getClass().getName());
// Dump class and classloader heirarchy
System.out.println("My class: " + clazz);
System.out.println("Id: " + System.identityHashCode(clazz));
ClassLoader cl = clazz.getClassLoader();
while (cl != null)
{
System.out.println(cl);
cl = cl.getParent();
}
Regards,
Adrian
>
> Regards,
>
> Stephane
>
> -----Original Message-----
> From: Adrian Brock [mailto:[EMAIL PROTECTED]
> Sent: Thursday, October 09, 2003 11:29 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [JBoss-user] JBossNET hot deployment
> problem(ClassCastException)
>
>
> We used to have the same problem with standard deployments running
> on java 1.4
> The problem boiled down to caching of proxy classes
> somewhere in the RMIClassLoader or Class.forName()
> that breaks hot deployment.
>
> This was usually seen when people included a jndi.properties in their
> deployments, forcing jndi to go over RMI to the local jndi tree.
>
> We added a workaround to the RMIClassLoader that tells it to
> cache proxy classes against the application's classloader rather than
> the guess made by RMI. Since the application's classloader changes
> at redeployment you no longer get the problem.
>
> If it is not the same problem, maybe Axis has a similar problem?
>
> Regards,
> Adrian
>
> On Thu, 2003-10-09 at 08:45, Stephane Nicoll wrote:
> > Hello,
> >
> > We used both 3.2.1 and 3.2.2RC4 and we got the same problem. We have an ear
> > containing EJBs, WAR, and a WSR defining our web service.
> >
> > Attached the web-service.xml we use
> >
> > If we deploy the ear, eveything went fine, jboss-net found the web service
> > and deploys it. We can access it throug our remote C++ client.
> >
> > SyncherLocal is the SessionBean used to get SOAP calls
> >
> > If we then remove the ear and put it back again (that is hot deployment) we
> > get a ClassCastException. Restarting JBoss fixes the problem but this is
> > quite annoying.
> >
> > 2003-10-08 09:33:08,375 [Thread-6 ] INFO ls.bytecode.ParamNameExtractor -
> > AXIS error:java.io.IOException: Unable to load bytecode for class
> > "com.kiala.kialapointserver.scannersynch.interfaces.SyncherLocal"
> > 2003-10-08 09:33:08,448 [Thread-6 ] INFO org.apache.axis.EXCEPTIONS -
> > AxisFault:
> > AxisFault
> > faultCode:
> {<http://schemas.xmlsoap.org/soap/envelope/}Server.userException>
> > faultSubcode:
> > faultString: java.lang.ClassCastException
> > faultActor:
> > faultNode:
> > faultDetail:
> > {<http://xml.apache.org/axis/}stackTrace:> java.lang.ClassCastException
> > at
> >
> com.sun.corba.se.internal.javax.rmi.PortableRemoteObject.narrow(PortableRemot
> > eObject.java:293)
> > at javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:134)
> > at
> >
> org.apache.axis.providers.java.EJBProvider.createRemoteEJB(EJBProvider.java:1
> > 68)
> > at
> >
> org.apache.axis.providers.java.EJBProvider.makeNewServiceObject(EJBProvider.j
> > ava:147)
> > at
> >
> org.apache.axis.providers.java.JavaProvider.getNewServiceObject(JavaProvider.
> > java:261)
> > at
> >
> org.apache.axis.providers.java.JavaProvider.getServiceObject(JavaProvider.jav
> > a:138)
> > at
> org.apache.axis.providers.java.JavaProvider.invoke(JavaProvider.java:313)
> > at
> >
> org.apache.axis.strategies.InvocationStrategy.visit(InvocationStrategy.java:7
> > 1)
> > at org.apache.axis.SimpleChain.doVisiting(SimpleChain.java:150)
> > at org.apache.axis.SimpleChain.invoke(SimpleChain.java:120)
> > at org.apache.axis.handlers.soap.SOAPService.invoke(SOAPService.java:481)
> > at org.apache.axis.server.AxisServer.invoke(AxisServer.java:323)
> > at org.apache.axis.transport.http.AxisServlet.doPost(AxisServlet.java:854)
> > at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
> > at
> >
> org.apache.axis.transport.http.AxisServletBase.service(AxisServletBase.java:3
> > 39)
> > at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
> > at
> >
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationF
> > ilterChain.java:247)
> > at
> >
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCha
> > in.java:193)
> > at
> >
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.jav
> > a:256)
> > at
> >
> org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invoke
> > Next(StandardPipeline.java:643)
> > at
> > org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
> > at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
> > at
> >
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.jav
> > a:191)
> > at
> >
> org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invoke
> > Next(StandardPipeline.java:643)
> > at
> >
> org.jboss.web.tomcat.security.JBossSecurityMgrRealm.invoke(JBossSecurityMgrRe
> > alm.java:228)
> > at
> >
> org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invoke
> > Next(StandardPipeline.java:641)
> > at
> >
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.
> > java:553)
> > at
> >
> org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invoke
> > Next(StandardPipeline.java:641)
> > at
> >
> org.apache.catalina.valves.CertificatesValve.invoke(CertificatesValve.java:24
> > 6)
> > at
> >
> org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invoke
> > Next(StandardPipeline.java:641)
> > at
> >
> org.jboss.web.tomcat.tc4.statistics.ContainerStatsValve.invoke(ContainerStats
> > Valve.java:76)
> > at
> >
> org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invoke
> > Next(StandardPipeline.java:641)
> > at
> > org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
> > at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
> > "axis.log" [readonly] 607L, 54964C
> >
> > Then we have this seems to be a *WELL KNOWN' error but got no infor
> regarding
> > this
> >
> > 2003-10-08 09:33:19,509 [Thread-7 ] INFO xis.providers.java.RPCProvider -
> > Tried to invoke method public abstract
> > com.kiala.kialapointserver.scannersynch.LoginResponse
> >
> com.kiala.kialapointserver.scannersynch.interfaces.SyncherLocal.login(java.la
> > ng.String,java.lang.String) with arguments
> java.lang.String,java.lang.String.
> > The arguments do not match the signature.
> > java.lang.IllegalArgumentException: object is not an instance of declaring
> > class
> >
> >
> > If now I restart JBsos everything went fine. Is it a classloader issue or
> > JbossNET (axis) caches some remote interface or something? When we remove
> the
> > ear the web service is undeployed (it's not shown in the axis servlet)
> >
> > Regards,
> >
> > Stephane
> >
> >
> > _______________________________________
> > Stéphane Nicoll
> > Software Engineer
> > KIALA NV - The last mile company
> > Avenue Louise/Louisalaan 149/28 (24th floor)
> > B-1050 Brussels (BELGIUM)
> > TEL +32 2 535 93 67
> > GSM +32 477 77 26 96
> > E-mail [EMAIL PROTECTED]
> > _______________________________________
--
xxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Director of Support
Back Office
JBoss Group, LLC
xxxxxxxxxxxxxxxxxxxxxxxx
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user
