Could you also please confirm that sample.HelloServiceSEI is not placed anywhere
else in the classpath [for example installroot/lib, domain-dir/lib]? Since you
were indicating that delegate="true" did not have any issues, I am suspecting
that this is the case.
If that is not the case, then probably more information might be needed to help
us understand the classcast exception. For example, if you could debug and see
which classloaders load sample.HelloServiceImpl and sample.HelloServiceSEI in
SyncMethodHandler or provide a simple test app to reproduce this locally?
> request: java.lang.ClassCastException: sample.HelloServiceImpl cannot be cast to sample.HelloServiceSEI)
> at com.sun.xml.ws.fault.SOAP11Fault.getProtocolException(SOAP11Fault.java:187)
> at com.sun.xml.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:108)
> at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:254)
> at
I wasn't suggesting placing it in a standalone jar. However if both wars needs
access to the WS classes, that might be the only option.
Thanks
--Siva.
glassfish_at_javadesktop.org wrote:
> Hi,
>
> web service classes are packaged within WAR archive in classes directory. I have following directory structure:
>
> application.ear
> .. some-web-app.war
> .. my-web-app.war
> .... - WEB-INF/classes/sample: contains HelloServiceImpl.class and sample.HelloServiceSEI
> .... - WEB-INF/webservices.xml: web services definitions
> .... - WEB-INF/wsdl: wsdl files and mapping files
> .... - WEB-INF/sun-web.xml with delegate="false"
>
> Are you suggesting to place web service classes inside standalone JAR directly inside EAR?
> [Message sent by forum member 'galet' (galet)]
>
> http://forums.java.net/jive/thread.jspa?messageID=244236
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>