Class Cast Exception under Endpoint.publish()

[adinn]

I am using JBossAS 5.0.0.GA with JBossWS 3.0.4 and I am trying to publish an endpoint using

 Endpoint publish(String address, Object implementor)

I supply the call with an instance of my endpoint class which is annotated with the appropriate WebService, SOAPBinding, WebMethod, etc annotations.

During deployment of the endpoint I get a Class Cast Exception as follows

11:40:51,731 ERROR [AbstractKernelController] Error installing to PostClassLoader: name=/xtsservicetests1 state=ClassLoader mode=Manual requiredState=PostClassLoader
org.jboss.deployers.spi.DeploymentException: Error during deploy: /xtsservicetests1
 at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)
 at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:177)
 at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439)
 at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157)
 at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1098)
 at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
 at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1598)
 at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
 at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1062)
 at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
 at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
 at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
 at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781)
 at org.jboss.deployers.plugins.main.MainDeployerImpl.deploy(MainDeployerImpl.java:418)
 at org.jboss.wsf.container.jboss50.transport.EndpointAPIHttpTransportManager.deploy(EndpointAPIHttpTransportManager.java:169)
 at org.jboss.wsf.container.jboss50.transport.EndpointAPIHttpTransportManager.createListener(EndpointAPIHttpTransportManager.java:85)
 at org.jboss.wsf.framework.deployment.HttpTransportDeploymentAspect.create(HttpTransportDeploymentAspect.java:76)
 at org.jboss.wsf.framework.deployment.DeploymentAspectManagerImpl.create(DeploymentAspectManagerImpl.java:121)
 at org.jboss.wsf.container.jboss50.BareWSFRuntime.create(BareWSFRuntime.java:61)
 at org.jboss.wsf.container.jboss50.transport.WSFRuntimeDelegateHttpServer.publish(WSFRuntimeDelegateHttpServer.java:96)
 at org.jboss.ws.core.jaxws.spi.EndpointImpl.publish(EndpointImpl.java:172)
 at org.jboss.ws.core.jaxws.spi.EndpointImpl.publish(EndpointImpl.java:129)
 at org.jboss.ws.core.jaxws.spi.ProviderImpl.createAndPublishEndpoint(ProviderImpl.java:83)
 at javax.xml.ws.Endpoint.publish(Endpoint.java:184)
 at org.jboss.jbossts.xts.servicetests.service.XTSServiceTestServiceManager.publish(XTSServiceTestServiceManager.java:19)
 at org.jboss.jbossts.xts.servicetests.test.XTSPublishAndInvokeTest.run(XTSPublishAndInvokeTest.java:20)
 at org.jboss.jbossts.xts.servicetests.bean.XTSServiceTestRunnerBean$1.run(XTSServiceTestRunnerBean.java:74)
Caused by: java.lang.ClassCastException: org.jboss.deployers.structure.spi.helpers.AbstractDeploymentUnit
 at org.jboss.deployment.security.AbstractSecurityDeployer.deploy(AbstractSecurityDeployer.java:148)
 at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
 ... 25 more

The problem is that AbstractSecurityDeployer.deploy is invoked with an AbstractDeploymentUnit as argument. However, at line 148 it tries to cast its argument to a VFSDeploymentUnit.

Any ideas why this is happening?

Has anyone successfully managed to use Endpoint.publish previously? If so what did you do to avoid running up against this exception?

[ropalka]

Endpoint.publish() isn't supported on AS 5.x, see (JBWS-1967)

[adinn]

Thanks for the quick response, Richard.

Endpoint.publish(), Endpoint.unpublish() is faulty by design IMHO.
It doesn't make sense to be able to publish POJOs to different web contexts.

Here are top two reasons why I think it is broken and hence excluded from TCK5 tests:
* security issue (how to configure java security for such ugly published endpoints where e.g. Security Manager is turned on)?
* design problem (why web archive should be able to publish another web/ejb archive)?

I'm not sure exactly why you think this makes it either undesirable or impossible to implement the Endpoint API as defined in the JaxWS spec. Let's go through these in turn:

1) It definitely makes sense to publish a specific POJO to a specific web context. Firstly, this API is simpler to use than providing a war with web.xml config. Secondly, it is dynamic, which allows all sorts of options not available using fixed web.xml config. For example, the endpoint implementation class might be loaded (or even generated) dynamically by the application.

And, actually, if you want to use the same POJO to masquerade behind two (or more) different URLs what is wrong with that? I can imagine good reasons for presenting a single service via multiple URLs and iIt's quite straightforward to deal with any threading issues this might imply.

2) The JaxWS spec does talk about security (Subsection 5.2.3 of the 21. spec) and, indeed, the Security permission it defines is checked by the current implementation of class EndpointImpl. Why can this implementation not be retro-fitted to conform to the JBoss Security Manager requirements?

3) I don't want a web archive to publish another web/ejb archive. In my case I have a test runner program for the XTS (Web Services Transactions) implementation. I deploy the test runner as a POJO via a jboss-beans.xml file. The test runner dynamically loads and executes different tests on different runs. Depending upon the specifics of the test, it needs to be able to install 0 or more POJOs as web service endpoints during test bootstrap.

I could, of course, deploy my test runner inside a war which statically deploys N endpoints via a web.xml config file. At present, I only use a single POJO service implementation but I don't always need the same value of N. In fact, for some runs (more precisely, on some of the AS instances employed in some of the runs -- the tests employ more than one AS) I don't even need to deploy a web service to complete the test.

[ropalka]

Thanks for your valuable feedback Andrew. I reopened the aforementioned issue.

[adinn]

Wow, that's certainly what I call quality service! I'm not 100% sure why you immediately reopened it though. I was posting more to discuss the reasons for excluding it than to state an absolute requirement :-)

Well, ok, I actually saw that Alessio told you to do it on the assumption that eventually the TCK tests will be reinstated. However, I noticed that the JaxWS spec doesn't actually include a Conformance note indicating that the Endpoint API must be implemented. Maybe this is why the TCK tests are commented out?

I would still like to be able to use the Endpoint API but as it is not available now I am going to have to go ahead with static configured endpoints. So, although this feature would be nice to have don't prioritise it before other important customer-driven features on my account.

[ropalka]

"adinn" wrote:
Well, ok, I actually saw that Alessio told you to do it on the assumption that eventually the TCK tests will be reinstated.

Yes, this was the reason of reopening it. (We were discussing this issue on IRC with Alessio)

"adinn" wrote:
However, I noticed that the JaxWS spec doesn't actually include a Conformance note indicating that the Endpoint API must be implemented. Maybe this is why the TCK tests are commented out?

Maybe, but we see Sun folks are working on these TCK5 excluded tests at the moment.

[ropalka]

"adinn" wrote:
So, although this feature would be nice to have don't prioritise it before other important customer-driven features on my account.

Don't worry, we'll start working on it once it will be available in TCK5 test suite again ;)