Re: error when accessing Webservice client within JBoss
Hi, It seems error from your web app code, since it says: java.lang.UnsupportedOperationException: s etProperty must be overridden by all subclasses of SOAPMessage can you show more codes... Thanks Jeff shaminda perera wrote: Hi all, This is the scenario. I created a WSDL and the generated the server side and client side code using the WSDL2Java tool. After that i published the Web service in Jetty,, as done by the generated server code. The web service is working fine when i tested it using a standalone client. I am having a web application which is deployed in JBoss. Now i need to access the Web service thru a client which sits in this web application. However, now i am now getting the following error: 11:05:26,030 FATAL [application] javax.ejb.EJBTransactionRolledbackException: java.lang.UnsupportedOperationException: s etProperty must be overridden by all subclasses of SOAPMessage javax.faces.el.EvaluationException: javax.ejb.EJBTransactionRolledbackException: java.lang.UnsupportedOperationException : setProperty must be overridden by all subclasses of SOAPMessage at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke (MethodBindingMethodExpressionAdapter.java:9 1) at com.sun.faces.application.ActionListenerImpl.processAction( ActionListenerImpl.java:91) at javax.faces.component.UICommand.broadcast(UICommand.java:383) This comes up when i am calling the Webservice methods using the generated client side stub. This does not come when i run the Web service client in standalone. Appreciate if someone can help or give any feedback. Thanks in advance.
Re: error when accessing Webservice client within JBoss
Hi, This looks to me as if it is a library problem. If you have bundled up the CXF classes in a war file then this will probably be what is happening. Explanation as follows: The JBoss implementation of SOAPMessage is an abstract class which provides default implementations of get/setProperty. The implementation is in a jar in $JBOSS_HOME/server/servername/deploy/jbossws.sar. The saaj jar which implements this abstract type also provides a META-INF/services file to define the SOAPMessage -- SOAPMessageImpl mapping. The file name is the fully qualified name of the SOAPMessage class and the contents of the file is a single line containing the fully qualified name of the implementation class. The mapped version of SOAPMessageImpl in the saaj implementation jar provided by JBoss relies upon inheriting these methods. Now, if your app bundles the cxf libs into a war file under WEBINF/lib then it will be picking up its implementation of SOAPMessage from a CXF lib which does not provide the get/setProperty methods. However, the SOAFPFactory finder will still be trying to instantiate the JBoss SOAPMessageImpl.class because the resource lookup it employs to identify which class to use will find the META-INF/services mapping file. You need to add META-INF/services files to your war which establish the correct mapping from the CXF saaj SOAPMessage class to the appropriate SOAPMessageImpl class in the CXF libs -- actually, I am not sure that the target for the map in CXF is called SOAPMessageImpl, perhaps Dan, Willem et al could advise. You may also find that jboswws.sar remaps several other classes which are looked up by a factory finder. You will probably need to add remap files in your war for these as well. regards, Andrew Dinn --- (JBoss Transactions developer) Jeff Yu wrote: Hi, It seems error from your web app code, since it says: java.lang.UnsupportedOperationException: s etProperty must be overridden by all subclasses of SOAPMessage can you show more codes... Thanks Jeff shaminda perera wrote: Hi all, This is the scenario. I created a WSDL and the generated the server side and client side code using the WSDL2Java tool. After that i published the Web service in Jetty,, as done by the generated server code. The web service is working fine when i tested it using a standalone client. I am having a web application which is deployed in JBoss. Now i need to access the Web service thru a client which sits in this web application. However, now i am now getting the following error: 11:05:26,030 FATAL [application] javax.ejb.EJBTransactionRolledbackException: java.lang.UnsupportedOperationException: s etProperty must be overridden by all subclasses of SOAPMessage javax.faces.el.EvaluationException: javax.ejb.EJBTransactionRolledbackException: java.lang.UnsupportedOperationException : setProperty must be overridden by all subclasses of SOAPMessage at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke (MethodBindingMethodExpressionAdapter.java:9 1) at com.sun.faces.application.ActionListenerImpl.processAction( ActionListenerImpl.java:91) at javax.faces.component.UICommand.broadcast(UICommand.java:383) This comes up when i am calling the Webservice methods using the generated client side stub. This does not come when i run the Web service client in standalone. Appreciate if someone can help or give any feedback. Thanks in advance. -- JBoss, a Division of Red Hat Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA) and David Owens (Ireland)
Re: error when accessing Webservice client within JBoss
Thanks Andrew and Jeff for the quick reply.. See below for some a more detailed stacktrace,,, if that helps.. 12:18:05,101 FATAL [application] javax.ejb.EJBTransactionRolledbackException: java.lang.UnsupportedOperationException: s etProperty must be overridden by all subclasses of SOAPMessage javax.faces.el.EvaluationException: javax.ejb.EJBTransactionRolledbackException: java.lang.UnsupportedOperationException : setProperty must be overridden by all subclasses of SOAPMessage at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke (MethodBindingMethodExpressionAdapter.java:9 1) at com.sun.faces.application.ActionListenerImpl.processAction( ActionListenerImpl.java:91) at javax.faces.component.UICommand.broadcast(UICommand.java:383) at org.ajax4jsf.component.AjaxViewRoot.processEvents( AjaxViewRoot.java:186) at org.ajax4jsf.component.AjaxViewRoot.broadcastEvents( AjaxViewRoot.java:164) at org.ajax4jsf.component.AjaxViewRoot.processApplication( AjaxViewRoot.java:352) at com.sun.faces.lifecycle.InvokeApplicationPhase.execute( InvokeApplicationPhase.java:97) at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java :251) at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java :117) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:244) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter( ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter( ApplicationFilterChain.java:206) at com.company.filter.doFilter(CompanyFilter.java:26) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter( ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter( ApplicationFilterChain.java:206) at org.jboss.seam.web.SeamFilter$FilterChainImpl.doFilter( SeamFilter.java:63) at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java :57) at org.jboss.seam.web.SeamFilter$FilterChainImpl.doFilter( SeamFilter.java:49) at org.jboss.seam.debug.hot.HotDeployFilter.doFilter( HotDeployFilter.java:60) at org.jboss.seam.web.SeamFilter$FilterChainImpl.doFilter( SeamFilter.java:49) at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java :45) at org.jboss.seam.web.SeamFilter$FilterChainImpl.doFilter( SeamFilter.java:49) at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java :79) at org.jboss.seam.web.SeamFilter$FilterChainImpl.doFilter( SeamFilter.java:49) at org.jboss.seam.web.SeamFilter.doFilter(SeamFilter.java:84) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter( ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter( ApplicationFilterChain.java:206) at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java :141) at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:281) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter( ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter( ApplicationFilterChain.java:206) at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter( ReplyHeaderFilter.java:96) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter( ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter( ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke( StandardWrapperValve.java:230) at org.apache.catalina.core.StandardContextValve.invoke( StandardContextValve.java:175) at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke( SecurityAssociationValve.java:179) at org.apache.catalina.authenticator.AuthenticatorBase.invoke( AuthenticatorBase.java:433) at org.jboss.web.tomcat.security.JaccContextValve.invoke( JaccContextValve.java:84) at org.apache.catalina.core.StandardHostValve.invoke( StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke( ErrorReportValve.java:104) at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke( CachedConnectionValve.java:157) at org.apache.catalina.core.StandardEngineValve.invoke( StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service( CoyoteAdapter.java:241) at org.apache.coyote.http11.Http11Processor.process( Http11Processor.java:844) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process( Http11Protocol.java:580) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run( JIoEndpoint.java:447) at java.lang.Thread.run(Thread.java:619) Caused by: javax.ejb.EJBTransactionRolledbackException:
Re: error when accessing Webservice client within JBoss
Oops, one more slip of the pasting finger! Here is the correct version of those last three mappings META-INF/services/javax.xml.soap.MetaFactory META-INF/services/javax.xml.soap.SOAPFactory META-INF/services/javax.xml.ws.spi.Provider should each contain a single line, respectively, com.sun.xml.messaging.saaj.soap.SAAJMetaFactoryImpl com.sun.xml.messaging.saaj.soap.SOAPFactoryImpl org.apache.cxf.jaxws.spi.ProviderImpl regards, Andrew Dinn --- Andrew Dinn wrote: Hi shaminda, Actually, I believe I have misled you slightly. The required mapping is for MessageFactory, not SOAPMessage. The mapping is provided by jboss in file jboss-saaj.jar which provides a file called META-INF/services/javax.xml.soap.MessageFactory You need to remap this by installing a corresponding file in your .war file. It needs to contain the following single line of text com.sun.xml.messaging.saaj.soap.DynamicMessageFactoryImpl I also added the following resource map files to my .war file in order to get the bundled cxf libs to operate correctly META-INF/services/javax.xml.soap.MetaFactory META-INF/services/javax.xml.soap.SOAPFactory META-INF/services/javax.xml.ws.spi.Provider The appropriate mapping targets were, respectively, com.sun.xml.messaging.saaj.soap.SAAJMetaFactoryImpl com.sun.xml.messaging.saaj.soap.SAAJMetaFactoryImpl com.sun.xml.messaging.saaj.soap.SAAJMetaFactoryImpl regards, Andrew Dinn --- shaminda perera wrote: Thanks Andrew and Jeff for the quick reply.. See below for some a more detailed stacktrace,,, if that helps.. 12:18:05,101 FATAL [application] javax.ejb.EJBTransactionRolledbackException: java.lang.UnsupportedOperationException: s etProperty must be overridden by all subclasses of SOAPMessage javax.faces.el.EvaluationException: javax.ejb.EJBTransactionRolledbackException: java.lang.UnsupportedOperationException : setProperty must be overridden by all subclasses of SOAPMessage at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke (MethodBindingMethodExpressionAdapter.java:9 1) at com.sun.faces.application.ActionListenerImpl.processAction( ActionListenerImpl.java:91) at javax.faces.component.UICommand.broadcast(UICommand.java:383) at org.ajax4jsf.component.AjaxViewRoot.processEvents( AjaxViewRoot.java:186) at org.ajax4jsf.component.AjaxViewRoot.broadcastEvents( AjaxViewRoot.java:164) at org.ajax4jsf.component.AjaxViewRoot.processApplication( AjaxViewRoot.java:352) at com.sun.faces.lifecycle.InvokeApplicationPhase.execute( InvokeApplicationPhase.java:97) at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java :251) at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java :117) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:244) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter( ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter( ApplicationFilterChain.java:206) at com.company.filter.doFilter(CompanyFilter.java:26) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter( ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter( ApplicationFilterChain.java:206) at org.jboss.seam.web.SeamFilter$FilterChainImpl.doFilter( SeamFilter.java:63) at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java :57) at org.jboss.seam.web.SeamFilter$FilterChainImpl.doFilter( SeamFilter.java:49) at org.jboss.seam.debug.hot.HotDeployFilter.doFilter( HotDeployFilter.java:60) at org.jboss.seam.web.SeamFilter$FilterChainImpl.doFilter( SeamFilter.java:49) at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java :45) at org.jboss.seam.web.SeamFilter$FilterChainImpl.doFilter( SeamFilter.java:49) at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java :79) at org.jboss.seam.web.SeamFilter$FilterChainImpl.doFilter( SeamFilter.java:49) at org.jboss.seam.web.SeamFilter.doFilter(SeamFilter.java:84) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter( ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter( ApplicationFilterChain.java:206) at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java :141) at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:281) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter( ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter( ApplicationFilterChain.java:206) at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter( ReplyHeaderFilter.java:96) at
Re: error when accessing Webservice client within JBoss
Hi shaminda, Actually, I believe I have misled you slightly. The required mapping is for MessageFactory, not SOAPMessage. The mapping is provided by jboss in file jboss-saaj.jar which provides a file called META-INF/services/javax.xml.soap.MessageFactory You need to remap this by installing a corresponding file in your .war file. It needs to contain the following single line of text com.sun.xml.messaging.saaj.soap.DynamicMessageFactoryImpl I also added the following resource map files to my .war file in order to get the bundled cxf libs to operate correctly META-INF/services/javax.xml.soap.MetaFactory META-INF/services/javax.xml.soap.SOAPFactory META-INF/services/javax.xml.ws.spi.Provider The appropriate mapping targets were, respectively, com.sun.xml.messaging.saaj.soap.SAAJMetaFactoryImpl com.sun.xml.messaging.saaj.soap.SAAJMetaFactoryImpl com.sun.xml.messaging.saaj.soap.SAAJMetaFactoryImpl regards, Andrew Dinn --- shaminda perera wrote: Thanks Andrew and Jeff for the quick reply.. See below for some a more detailed stacktrace,,, if that helps.. 12:18:05,101 FATAL [application] javax.ejb.EJBTransactionRolledbackException: java.lang.UnsupportedOperationException: s etProperty must be overridden by all subclasses of SOAPMessage javax.faces.el.EvaluationException: javax.ejb.EJBTransactionRolledbackException: java.lang.UnsupportedOperationException : setProperty must be overridden by all subclasses of SOAPMessage at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke (MethodBindingMethodExpressionAdapter.java:9 1) at com.sun.faces.application.ActionListenerImpl.processAction( ActionListenerImpl.java:91) at javax.faces.component.UICommand.broadcast(UICommand.java:383) at org.ajax4jsf.component.AjaxViewRoot.processEvents( AjaxViewRoot.java:186) at org.ajax4jsf.component.AjaxViewRoot.broadcastEvents( AjaxViewRoot.java:164) at org.ajax4jsf.component.AjaxViewRoot.processApplication( AjaxViewRoot.java:352) at com.sun.faces.lifecycle.InvokeApplicationPhase.execute( InvokeApplicationPhase.java:97) at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java :251) at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java :117) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:244) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter( ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter( ApplicationFilterChain.java:206) at com.company.filter.doFilter(CompanyFilter.java:26) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter( ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter( ApplicationFilterChain.java:206) at org.jboss.seam.web.SeamFilter$FilterChainImpl.doFilter( SeamFilter.java:63) at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java :57) at org.jboss.seam.web.SeamFilter$FilterChainImpl.doFilter( SeamFilter.java:49) at org.jboss.seam.debug.hot.HotDeployFilter.doFilter( HotDeployFilter.java:60) at org.jboss.seam.web.SeamFilter$FilterChainImpl.doFilter( SeamFilter.java:49) at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java :45) at org.jboss.seam.web.SeamFilter$FilterChainImpl.doFilter( SeamFilter.java:49) at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java :79) at org.jboss.seam.web.SeamFilter$FilterChainImpl.doFilter( SeamFilter.java:49) at org.jboss.seam.web.SeamFilter.doFilter(SeamFilter.java:84) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter( ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter( ApplicationFilterChain.java:206) at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java :141) at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:281) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter( ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter( ApplicationFilterChain.java:206) at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter( ReplyHeaderFilter.java:96) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter( ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter( ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke( StandardWrapperValve.java:230) at org.apache.catalina.core.StandardContextValve.invoke( StandardContextValve.java:175) at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke( SecurityAssociationValve.java:179) at
Re: error when accessing Webservice client within JBoss
Thanks Andrew,, But i didnt bundle any of the CXF jars in my WAR file to start with comments? On 10/17/07, Andrew Dinn [EMAIL PROTECTED] wrote: Oops, one more slip of the pasting finger! Here is the correct version of those last three mappings META-INF/services/javax.xml.soap.MetaFactory META-INF/services/javax.xml.soap.SOAPFactory META-INF/services/javax.xml.ws.spi.Provider should each contain a single line, respectively, com.sun.xml.messaging.saaj.soap.SAAJMetaFactoryImpl com.sun.xml.messaging.saaj.soap.SOAPFactoryImpl org.apache.cxf.jaxws.spi.ProviderImpl regards, Andrew Dinn --- Andrew Dinn wrote: Hi shaminda, Actually, I believe I have misled you slightly. The required mapping is for MessageFactory, not SOAPMessage. The mapping is provided by jboss in file jboss-saaj.jar which provides a file called META-INF/services/javax.xml.soap.MessageFactory You need to remap this by installing a corresponding file in your .war file. It needs to contain the following single line of text com.sun.xml.messaging.saaj.soap.DynamicMessageFactoryImpl I also added the following resource map files to my .war file in order to get the bundled cxf libs to operate correctly META-INF/services/javax.xml.soap.MetaFactory META-INF/services/javax.xml.soap.SOAPFactory META-INF/services/javax.xml.ws.spi.Provider The appropriate mapping targets were, respectively, com.sun.xml.messaging.saaj.soap.SAAJMetaFactoryImpl com.sun.xml.messaging.saaj.soap.SAAJMetaFactoryImpl com.sun.xml.messaging.saaj.soap.SAAJMetaFactoryImpl regards, Andrew Dinn --- shaminda perera wrote: Thanks Andrew and Jeff for the quick reply.. See below for some a more detailed stacktrace,,, if that helps.. 12:18:05,101 FATAL [application] javax.ejb.EJBTransactionRolledbackException: java.lang.UnsupportedOperationException: s etProperty must be overridden by all subclasses of SOAPMessage javax.faces.el.EvaluationException: javax.ejb.EJBTransactionRolledbackException: java.lang.UnsupportedOperationException : setProperty must be overridden by all subclasses of SOAPMessage at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke (MethodBindingMethodExpressionAdapter.java:9 1) at com.sun.faces.application.ActionListenerImpl.processAction( ActionListenerImpl.java:91) at javax.faces.component.UICommand.broadcast(UICommand.java :383) at org.ajax4jsf.component.AjaxViewRoot.processEvents( AjaxViewRoot.java:186) at org.ajax4jsf.component.AjaxViewRoot.broadcastEvents( AjaxViewRoot.java:164) at org.ajax4jsf.component.AjaxViewRoot.processApplication( AjaxViewRoot.java:352) at com.sun.faces.lifecycle.InvokeApplicationPhase.execute( InvokeApplicationPhase.java:97) at com.sun.faces.lifecycle.LifecycleImpl.phase( LifecycleImpl.java :251) at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java :117) at javax.faces.webapp.FacesServlet.service(FacesServlet.java :244) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter( ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter( ApplicationFilterChain.java:206) at com.company.filter.doFilter(CompanyFilter.java:26) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter( ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter( ApplicationFilterChain.java:206) at org.jboss.seam.web.SeamFilter$FilterChainImpl.doFilter( SeamFilter.java:63) at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java :57) at org.jboss.seam.web.SeamFilter$FilterChainImpl.doFilter( SeamFilter.java:49) at org.jboss.seam.debug.hot.HotDeployFilter.doFilter( HotDeployFilter.java:60) at org.jboss.seam.web.SeamFilter$FilterChainImpl.doFilter( SeamFilter.java:49) at org.jboss.seam.web.RedirectFilter.doFilter( RedirectFilter.java :45) at org.jboss.seam.web.SeamFilter$FilterChainImpl.doFilter( SeamFilter.java:49) at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java :79) at org.jboss.seam.web.SeamFilter$FilterChainImpl.doFilter( SeamFilter.java:49) at org.jboss.seam.web.SeamFilter.doFilter(SeamFilter.java:84) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter( ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter( ApplicationFilterChain.java:206) at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java :141) at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:281)
Re: error when accessing Webservice client within JBoss
shaminda perera wrote: Thanks Andrew,, But i didnt bundle any of the CXF jars in my WAR file to start with Ok, we'll come back to that in a second. Irrespective of this when using CXF within a JBoss server you are still going to face problems with the fact that CXF and JBoss employ competing versions of some libraries. Depending upon where you have placed the CXF libs you may interpose the CXF versions before or after the JBoss ones in the classloader lookup path. If you do it one way you may upset JBoss. If you do it another way you may upset CXF. Welcome to classloader hell :-) Given that you are getting the symptoms you described it looks as if the classloader is finding the CXF libraries first but is still being snookered by the JBoss resource mappings. Have you placed the CXF libraries in $JBOSS_HOME/lib? I believe this is the first place the classloader looks for an implementation class (after looking at a war /WEB-INF/lib, that is). Whatever you have done, the reason I claim this is that i) you are getting incompatible super and subclasses and ii) the super class in question does not implement getProperty. So, the super class must be from the CXF jar. This means the incompatible subclass must be from the JBoss implementation jar. Although you have enabled prior access to the CXF saaj jar you have not disabled the resource mappings which load the JBoss saaj implementation jar. That is because none of the CXF libs contain a mapping file so none of them overrides the one provided by JBoss. Another problem which occurs when you install the CXF libs this way is that legitimate JBoss apps which do not want to use CXF will be getting CXF versions of some classes. This is probably ok -- the latest (2.0+) CXF libs are likely to be later than the latest (4.2.1+) release JBoss libs -- but it is not the best way to organize things and, although it may work, there is no guarantee that there is no incompatibility here. Now, conversely, if you were to place the CXF libs in the deploy directory or the server/servername/lib directory they would get loaded after the ones in $JBOSS_HOME/lib. This way round you would run the opposite risk that CXF code would get the wrong version of its libs since they would be preceded by alternatives found first in the JBoss lib directory. This is likely to be a worse problem since CXF needs some later versions of APIs than JBoss. Also, I think you would clobber some of the libs of the same name in the JBoss directory, i.e. you would still enforce a partial upgrade of the libs used by JBoss. So, if your app is using CXF then it is probably best to ensure that it gets the libraries CXF wants it to have by bundling them in a .war file along with your app code. This also ensures that other apps do *not* get CXF libraries that they do not want. Of course, it also means a copy of the CXF libraries in every .war file . . . If you want to persist in placing the CXF apps in the $JBOSS_HOME/lib directory rather than scoping the app libs inside a .war file then you will have to ensure that suitable resources are defined to map the MessageFactory and other classes to the appropriate implementations. i.e. you cannot just install the libs you also have to ensure that the factory mappings provided by the jboss implementation libs are correctly remapped. regards, Andrew Dinn ---
Re: error when accessing Webservice client within JBoss
Thanks andrew for the detailed mail. This is what i am doing currently: I created a Web service client side related classes using the WSDL2Java tool provided by CXF, and then put just put these classes in a suitable package in the main web application. I didnt put any of the CXF provided jars/libraries in to the web application. Now when calling the web service i am getting this error ,,, that we are talking about. Just thinking,,, the jdk's rt.jar also has some webservices/xml related classes,,, is my web service client using any of those as well? ,, or is it picking the libs from JBoss only.. I havent placed any CXF libraries in $JBOSS_HOME/lib ,, actually i havent placed them anywhere in Jboss or anywhere in my web application. I will try to do what you are mentioning in this mail, and get back to you.. On 10/17/07, Andrew Dinn [EMAIL PROTECTED] wrote: shaminda perera wrote: Thanks Andrew,, But i didnt bundle any of the CXF jars in my WAR file to start with Ok, we'll come back to that in a second. Irrespective of this when using CXF within a JBoss server you are still going to face problems with the fact that CXF and JBoss employ competing versions of some libraries. Depending upon where you have placed the CXF libs you may interpose the CXF versions before or after the JBoss ones in the classloader lookup path. If you do it one way you may upset JBoss. If you do it another way you may upset CXF. Welcome to classloader hell :-) Given that you are getting the symptoms you described it looks as if the classloader is finding the CXF libraries first but is still being snookered by the JBoss resource mappings. Have you placed the CXF libraries in $JBOSS_HOME/lib? I believe this is the first place the classloader looks for an implementation class (after looking at a war /WEB-INF/lib, that is). Whatever you have done, the reason I claim this is that i) you are getting incompatible super and subclasses and ii) the super class in question does not implement getProperty. So, the super class must be from the CXF jar. This means the incompatible subclass must be from the JBoss implementation jar. Although you have enabled prior access to the CXF saaj jar you have not disabled the resource mappings which load the JBoss saaj implementation jar. That is because none of the CXF libs contain a mapping file so none of them overrides the one provided by JBoss. Another problem which occurs when you install the CXF libs this way is that legitimate JBoss apps which do not want to use CXF will be getting CXF versions of some classes. This is probably ok -- the latest (2.0+) CXF libs are likely to be later than the latest (4.2.1+) release JBoss libs -- but it is not the best way to organize things and, although it may work, there is no guarantee that there is no incompatibility here. Now, conversely, if you were to place the CXF libs in the deploy directory or the server/servername/lib directory they would get loaded after the ones in $JBOSS_HOME/lib. This way round you would run the opposite risk that CXF code would get the wrong version of its libs since they would be preceded by alternatives found first in the JBoss lib directory. This is likely to be a worse problem since CXF needs some later versions of APIs than JBoss. Also, I think you would clobber some of the libs of the same name in the JBoss directory, i.e. you would still enforce a partial upgrade of the libs used by JBoss. So, if your app is using CXF then it is probably best to ensure that it gets the libraries CXF wants it to have by bundling them in a .war file along with your app code. This also ensures that other apps do *not* get CXF libraries that they do not want. Of course, it also means a copy of the CXF libraries in every .war file . . . If you want to persist in placing the CXF apps in the $JBOSS_HOME/lib directory rather than scoping the app libs inside a .war file then you will have to ensure that suitable resources are defined to map the MessageFactory and other classes to the appropriate implementations. i.e. you cannot just install the libs you also have to ensure that the factory mappings provided by the jboss implementation libs are correctly remapped. regards, Andrew Dinn ---
