Now I want to see if it is possible to call my service using sun’s jwsd inside JBOSS in my seam based application? if so, which libraries do I need to put and in where!!?

First some other notes from Heiko Braun in the very same forum post, which are worth repeating here:

I will try to explain what changes between 1.2.0 and 1.2.1 are causing the problems you encounter.
For EJB3 deployments we need to create a web app for HTTP invocations (obviously)
EJB’s don’t contain web context information, so we derive it automagically.
Until 1.2.0 the context name was derived from the ear/jar name.
This changed with 1.2.1 to an algorithm that derives it from the bean class name
So what’s happening when you deploy a EJB3 jar that contains multiple beans?

The default algorithm derives different context names for each bean in this deployment, which in turn we cannot use to setup the HTTP endpoint and thus throw an exception.

This also explains why the following did work:
    @WebContext(contextRoot="/beans")

Unfortunately this is left out in the specs and thus has been changed many times.

Until we a have a definite solution i suggest you refer to the @WebContext annotation, even though it’s not the most elegant solution.

And to use it: it’s org.jboss.ws.annotation.WebContext as found in jbossws-core.jar.

This also invalidates some comment at the bug I mentioned, which made me write “[..] might indicate that this only changes the URL in the generated WSDL, not the URL of the WSDL itself“, which is NOT true. So, the following works just fine (in AS 4.2.0.GA, and if META-INF/standard-jaxws-endpoint-config.xml is present):

// Service Endpoint Interface
@WebService
public interface DeepThoughtSEI {
  @WebMethod
  public String answer(String question);
}

and

@Stateless
@WebContext(contextRoot = "/guide/to/the/galaxy")
@WebService(endpointInterface = "my.package.DeepThoughtSEI")
public class DeepThought implements DeepThoughtSEI {
  public String answer(String question){
    return "42";
  }
 
  public String methodNotExposed(){
    return "not for public use";
  }
}


This serves the WSDL at http://universe.tld/guide/to/the/galaxy/DeepThought?wsdl — but I guess it’s to be considered a workaround.

Note that when not specifying a value for endpointInterface then ALL methods in the DeepThought implementation would be exposed, unless at least one method is explicitly annotated in that class — even though the interface explicitly only declares a single method to be exposed. In other words: the @WebMethod annotations in the interface are only honored when endpointInterface is used.

And for those who get to this page because of the “Multiple context root not supported” error: that might also be caused by some left-overs after refactoring. I changed the name of my service, leaving the old compiled classes in various exploded EAR folders, which were then still loaded by JBoss…

Peek at the SeamBay example!

Enjoy,
Arjan.
– the preview or stylesheet needs something to post pre-formatted code!

The META-INF/standard-jaxws-endpoint-config.xml file is the default filename as part of a JBoss proprietary annotation, @EndpointConfig. It has it’s own documentation page on the wiki, which took me some time to find but actually is linked in the “Appendix A” section of the JBoss JAX-WS User Guide. It doesn’t help me much but might have been enhanced by the time someone reads this…

The client side has its own default file, standard-jaxws-client-config.xml.

One might be able to change the URLs by using @WebContext, which is another JBoss proprietary annotation. However, some bug report (find JBWS-1622 or copy http://tinyurl.com/yv3da8 — the preview gets confused by too many URLs or something?) might indicate that this only changes the URL in the generated WSDL, not the URL of the WSDL itself. It also strikes me as odd to define the context root in the Java code… I did not try this.

The @WebContext annotation might also be a (temporary) solution when deploying multiple web services, at which point one might encounter “Multiple context root not supported” errors. The solution states:

Just make sure all EJB’s within a jar point to the same web context thriugh something like:
@WebContext(contextRoot=”/myEJBServices”)

Well, that’s it for today…!
Arjan.

very cool! Thank you very much for following up on that. I really need to checkout the newer stuff. I tried moving my 10MinuteMail app over to the newer Seam running on 4.2.0 GA, but the server hangs while booting up. Remove the ear and it’s fine. No error messages, just locks up. I haven’t had the time to dive too deeply into it and pull stacktraces and the like.

Wish me luck!

Regards,

Devon

For example, for org.jboss.seam.example.seambay.AuctionService JBoss AS (or actually: jbossws-1.2.1.GA which is included in AS 4.2.0.GA) now generates

http://127.0.0.1:8080/AuctionServiceService/AuctionService?wsdl

So: neither the package name nor the context name are used, whereas the application itself could still be hosted at

http://127.0.0.1:8080/seam-bay/home.seam

I have not yet figured out if one can control the names JBoss chooses — I’d rather not rely on JBoss AS choosing a different name if ever upgrading the application server. As a first start, to avoid the double word “Service” maybe one should no longer name the service endpoint classes XYZService…

Finally: please not that apparently I linked to an old version of the User Guide above; for jbossws-1.2.0 and higher the JBoss JAX-WS User Guide as found at the wiki should be used.

Arjan.

Devon

In CVS, AuctionService only uses @WebService and @WebMethod, and implements AuctionServiceRemote which uses @Remote. No further configuration in web.xml, but an additional configuration file META-INF/standard-jaxws-endpoint-config.xml which is included in the JAR file.

This gets one odd URI’s such as /seam-bay-seam-bay/AuctionService (the web site being available at /seam-bay, this name is simply duplicated to get a unique URL). I don’t know where this is defined; maybe one needs to change web.xml after all to get custom URLs.

See also the JBossWS User Guide and the JAX-WS Endpoint Configuration wiki pages.