Bugs item #848106, was opened at 2003-11-24 02:55
Message generated for change (Comment added) made by millz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=848106&group_id=22866
Category: JBossSOAP
Group: v3.2
Status: Closed
Resolution: Works For Me
Priority: 5
Submitted By: Stephane Nicoll (stephane_nicoll)
Assigned to: Dr. Christoph Georg Jung (cgjung)
Summary: ClassCastException on SOAP calls upon redeployment
Initial Comment:
OS: Redhat linux 9
Java: SUN VM 1.4.1_02
The bug is reproductible with both JBoss 3.2.2 and
3.2.3RC1
We have an application, packaged as an EAR and
containing mainly:
- an EJB module JAR containing SessionBeans, Entity
Beans and MDB
- an WSR module JARr containing a web service
declaration
- Some librairies
The WSR module defines a web service that use a
SessionBean to process incoming SOAP calls
Eveything runs fine but when we hot-redeploy the EAR,
we have a ClassCastException and the web service does
not work anymore (we need to restart JBoss to fix this).
My guesses is that this is an Axis bug but I already
opened a bug @t apache without any feedback. We
discussed this issue in the JBoss-user mailing list see the
thread:
JBossNET hot deployment problem (ClassCastException)
This shows the classes / interfaces are OK after un
hotdeploy (see the thread for test output suggested by
Adrian)
What we have after the hot-redeploy at server side is
the following:
2003-11-24 08:40:57,873 INFO
[org.apache.axis.utils.bytecode.ParamNameExtractor]
AXIS error:java.io.IOException: Unable to load bytecode
for
class "com.kiala.kserver.driver.nodesynch.NodeSyncherLo
cal"
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.PortableRemoteObjec
t.narrow(PortableRemoteObject.java:293)
at javax.rmi.PortableRemoteObject.narrow
(PortableRemoteObject.java:134)
at
org.apache.axis.providers.java.EJBProvider.createRemote
EJB(EJBProvider.java:168)
at
org.apache.axis.providers.java.EJBProvider.makeNewServi
ceObject(EJBProvider.java:147)
at
org.apache.axis.providers.java.JavaProvider.getNewServi
ceObject(JavaProvider.java:261)
at
org.apache.axis.providers.java.JavaProvider.getServiceOb
ject(JavaProvider.java:138)
at
org.apache.axis.providers.java.JavaProvider.invoke
(JavaProvider.java:313)
at
org.apache.axis.strategies.InvocationStrategy.visit
(InvocationStrategy.java:71)
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:339)
Should you need further info, let me know.
Regards,
Stephane Nicoll
----------------------------------------------------------------------
Comment By: Jason Miller (millz)
Date: 2004-03-12 16:21
Message:
Logged In: YES
user_id=684546
I had the same hot-deploy issue (same issue, different
error).
I re-deploy both an EJB and its corresponding wsr file on each
build cycle but the only one that gets hot-reloaded is the
EJB. When that happens, my SOAP clients then receive this
error:
16:00:23,206 ERROR [LogInterceptor] EJBException:
javax.ejb.EJBException: Invalid invocation, check your
deployment packaging, method=public abstract
com.incogen.gp.data.entities.xml.EntityXmlController
com.incogen.gp.data.entities.xml.EntityXmlControllerBean.crea
te() throws
java.rmi.RemoteException,javax.ejb.CreateException
at
org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.
invokeHome(StatelessSessionContainer.java:632)
at
org.jboss.resource.connectionmanager.CachedConnectionInter
ceptor.invokeHome(CachedConnectionInterceptor.java:205)
at org.jboss.ejb.plugins.TxInterceptorBMT.invokeHome
(TxInterceptorBMT.java:54)
at
org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invo
keHome(StatelessSessionInstanceInterceptor.java:51)
at org.jboss.ejb.plugins.SecurityInterceptor.invokeHome
(SecurityInterceptor.java:92)
at org.jboss.ejb.plugins.LogInterceptor.invokeHome
(LogInterceptor.java:120)
at
org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invokeHom
e(ProxyFactoryFinderInterceptor.java:93)
at
org.jboss.ejb.StatelessSessionContainer.internalInvokeHome
(StatelessSessionContainer.java:319)
at org.jboss.ejb.Container.invoke(Container.java:720)
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:324)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke
(ReflectedMBeanDispatcher.java:284)
at org.jboss.mx.server.MBeanServerImpl.invoke
(MBeanServerImpl.java:546)
at org.jboss.invocation.local.LocalInvoker.invoke
(LocalInvoker.java:101)
at org.jboss.invocation.InvokerInterceptor.invoke
(InvokerInterceptor.java:90)
at org.jboss.proxy.TransactionInterceptor.invoke
(TransactionInterceptor.java:46)
at org.jboss.proxy.SecurityInterceptor.invoke
(SecurityInterceptor.java:45)
at org.jboss.proxy.ejb.HomeInterceptor.invoke
(HomeInterceptor.java:173)
at org.jboss.proxy.ClientContainer.invoke
(ClientContainer.java:85)
at $Proxy37.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:324)
at
org.jboss.net.axis.server.EJBProvider.makeNewServiceObject
(EJBProvider.java:139)
at
org.apache.axis.providers.java.JavaProvider.getNewServiceObj
ect(JavaProvider.java:261)
at
org.apache.axis.providers.java.JavaProvider.getServiceObject
(JavaProvider.java:138)
at org.apache.axis.providers.java.JavaProvider.invoke
(JavaProvider.java:313)
at org.apache.axis.strategies.InvocationStrategy.visit
(InvocationStrategy.java:71)
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:339)
at javax.servlet.http.HttpServlet.service
(HttpServlet.java:853)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter
(ApplicationFilterChain.java:247)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter
(ApplicationFilterChain.java:193)
at
org.apache.catalina.core.StandardWrapperValve.invoke
(StandardWrapperValve.java:256)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineVal
veContext.invokeNext(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.java:191)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineVal
veContext.invokeNext(StandardPipeline.java:643)
at
org.jboss.web.tomcat.security.JBossSecurityMgrRealm.invoke
(JBossSecurityMgrRealm.java:220)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineVal
veContext.invokeNext(StandardPipeline.java:641)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke
(AuthenticatorBase.java:553)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineVal
veContext.invokeNext(StandardPipeline.java:641)
at org.apache.catalina.valves.CertificatesValve.invoke
(CertificatesValve.java:246)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineVal
veContext.invokeNext(StandardPipeline.java:641)
at
org.jboss.web.tomcat.tc4.statistics.ContainerStatsValve.invok
e(ContainerStatsValve.java:76)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineVal
veContext.invokeNext(StandardPipeline.java:641)
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.StandardContext.invoke
(StandardContext.java:2417)
at org.apache.catalina.core.StandardHostValve.invoke
(StandardHostValve.java:180)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineVal
veContext.invokeNext(StandardPipeline.java:643)
at
org.apache.catalina.valves.ErrorDispatcherValve.invoke
(ErrorDispatcherValve.java:171)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineVal
veContext.invokeNext(StandardPipeline.java:641)
at org.apache.catalina.valves.ErrorReportValve.invoke
(ErrorReportValve.java:172)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineVal
veContext.invokeNext(StandardPipeline.java:641)
at
org.jboss.web.tomcat.security.SecurityAssociationValve.invok
e(SecurityAssociationValve.java:65)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineVal
veContext.invokeNext(StandardPipeline.java:641)
at org.apache.catalina.valves.AccessLogValve.invoke
(AccessLogValve.java:577)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineVal
veContext.invokeNext(StandardPipeline.java:641)
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.StandardEngineValve.invoke
(StandardEngineValve.java:174)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineVal
veContext.invokeNext(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.coyote.tomcat4.CoyoteAdapter.service
(CoyoteAdapter.java:197)
at org.apache.coyote.http11.Http11Processor.process
(Http11Processor.java:781)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionH
andler.processConnection(Http11Protocol.java:549)
at org.apache.tomcat.util.net.TcpWorkerThread.runIt
(PoolTcpEndpoint.java:605)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.ru
n(ThreadPool.java:677)
at java.lang.Thread.run(Thread.java:534)
However, restarting the jboss (3.2.3) server fixes everything
up. I have "resolved" this issue by removing the wsr file from
the deploy directory, waiting 20 seconds for the server to
realize the change, and then moving the new version of the
wsr file into the deploy dir. I am using
org.jboss.net.axis.server.EJBProvider in the xml config, BTW.
----------------------------------------------------------------------
Comment By: Stephane Nicoll (stephane_nicoll)
Date: 2003-12-01 03:47
Message:
Logged In: YES
user_id=448198
Thanks a lot, this is working as expected.
Sorry for the noise (not-a-bug)
Regards,
Stephane
----------------------------------------------------------------------
Comment By: Dr. Christoph Georg Jung (cgjung)
Date: 2003-11-24 08:45
Message:
Logged In: YES
user_id=175199
Our EJBprovider is derived from the axis one and ovverides
only the necessary bits with regard to container integration.
We did not override the urn shortcuts for handlerclasses
(would be an idea, maybe I will take this as a feature
request ;-), so you would have to use
<parameter name="handlerClass"
value="org.jboss.net.axis.server.EJBProvider"/>
in your wsdd service declaration
But the wsdl should of course be the same, if it isnīt please
let me know or file a bug!
CGJ
----------------------------------------------------------------------
Comment By: Stephane Nicoll (stephane_nicoll)
Date: 2003-11-24 08:15
Message:
Logged In: YES
user_id=448198
I suspect this could be the problem :/
We didn't changed anything because our WSDL should not
change at all. We have a C++ client running on a palm and
the SOAP library is lacking of features. So if we change the
WSDL a bit (names are changing) the client could not
connect anymore.
I hope chaning the provider will note change the generation
of the WSDL
Changing to provider java:/EJB is enough?
Regards,
Stephane
----------------------------------------------------------------------
Comment By: Dr. Christoph Georg Jung (cgjung)
Date: 2003-11-24 08:06
Message:
Logged In: YES
user_id=175199
You should use the org.jboss.net.axis.server.EJBProvider
instead of the axis one (this is what i suspect from your
trace) as our provider is especially designed to cope with the
classloading environment of jboss (and does not employ all
the complicated jndi/narrow stuff which is faster).
CGJ
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=848106&group_id=22866
-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
