I would like to know as well please. I would rather use the Metro stuff than the native stuff.
Actually you can not mix the web service implementation in the war or jar files. JBossWS uses "ant deploy-jboss5.x.x" command to replace and install the new stack into jboss container . There is only one soap stack can be deployed in jboss container. This wiki for your reference : http://community.jboss.org/wiki/JBossWS-Installation
There is not mentioned there can be only one stack implementation at a time on the JBossWS-Installation wiki page I cannot see it.
Do I even need to install an alternative stack like Metro?
What happens if I simply bundle in all Metro libraries to my WAR file plus all generated java stuff (from wsgen) and sun-jaxws.xml and web.xml to WEB-INF. The Metro stack should be used then shouldn't it?
Content of sun-jaxws.xml:
<endpoints xmlns="http://java.sun.com/xml/ns/jax-ws/ri/runtime" version="2.0"> <endpoint name="FooService" implementation="esp.home.wsarena.service.FooService" url-pattern="/FooService"/> </endpoints>
Content of web.xml:
<web-app ...> <listener> <listener-class>com.sun.xml.ws.transport.http.servlet.WSServletContextListener</listener-class> </listener> <servlet> <servlet-name>MyWebService</servlet-name> <servlet-class>com.sun.xml.ws.transport.http.servlet.WSServlet</servlet-class> </servlet> <servlet-mapping> <servlet-name>MyWebService</servlet-name> <url-pattern>/FooService</url-pattern> </servlet-mapping> </web-app>
I am just worried that deployer will scan classes for @WebService annotations and try to make JBossWS Native web services from them anyway. How to prevent class scanner to checking this particular application or WAR.
How to get feedback that my service really uses Metro and not Native?
You can see what the soap stack implementation in your jboss server from : 1. jboss start up log message : 14:47:17,780 INFO [AbstractServerConfig] JBoss Web Services - Native Server 14:47:17,781 INFO [AbstractServerConfig] 3.2.2-SNAPSHOT 2. jbossws web console : http://localhost:8080/jbossws/ I did not test deploy the ws with metro runtime libaraies into a native soap stack. I believe there is error happens, because the class conflicts or other things. Could you explain why you need to mix the two soap implementation?
Yes it is definitively possible to deploy a Metro based web service to a JBoss with Native stack or without any WS support at all.
Yes it is definitively possible to deploy a project using two or more WS stack implementations.
I have just finished this example project proving it. You are more then welcome to test it:
Steps to deploy Metro based web service to a hosting AS in a target implementation agnostic way:
Package libraries to WAR: sun-jaxws:jaxws-rt, sun-jaxws:streambuffer, sun-jaxws:stax-ex (Maven naming)
Generate WSDL and server Java stubs (hosting AS will not do it for you) and bundle them. Use CLI, Ant or Maven tools: wsgen.
In web.xml define FooService servlet as a com.sun.xml.ws.transport.http.servlet.WSServlet class. Also set servlet/service URL pattern.
In sun-jaxws.xml define a real implementation class for FooService, it is esp.home.wsarena.service.FooService in my case, and define service URL pattern (t is already defined in web.xml!? Rather keem them same)
There are 2 modules in my project - webservice-metro and webservice-native. One using SUN Metro stack (bundled in), other JBoss native stack (expected to be provided by server). Both deploy on the server at the same time successfully. I did not put them in one EAR, there should be no difference. Service implementation is in separate JAR module, the same identical JAR is included into both native and metro WAR packages. There is aslo a simple test client to prove functionality of both modules.
You are welcome to try them as:
The question remains – how JBoss recognized that FooService in my webservice-metro module is intended to be run as Metro and not a Native? Why JBoss reacted on annotated FooService in webservice-metro modue and not on the very same class in my webservice-native module?
A) it detects presence of jaxws libraries (how? Some specific class or a Jar name?)
B) it detects presence of jaxws configuration file the sun-jaxws.xml (is it a simple file detection? Or it does deepr context analysis looking for present class names?)
C) both above
I am very keen to know the answer.
What you example is doing is basically leveraging classloading isolation in the war; the Sun libraries you include in the web application take over to the corresponding ones installed in the server (the jaxws impl, etc.)
The application server "knows to use Metro" in that case just because of the web.xml you're providing:
As you can see there's no reference to a jaxws annotated class here above; on the countrary, you're refferring to the Metro's servlet and specifying it's servlet context listener. At that point, the Metro specific descriptor (sun-jaxws.xml) enter the game and the rest of the setup is up to the Sun libs.
In the case above, the web app is like any other web app to JBoss.
The problem with your solution is in the fact you need to bundle a stack implementation with your own application.
When you install JBossWS-Metro (the same could be said about JBossWS-CXF, of course) to the application server, instead, you get a proper integration to the AS. For example, besides slimming down the size of you app archive, you no longer need to provide the proprietary sun-jaxws descriptor in your deployment (it's automatically generated by JBossWS-Metro), you get access to the common JBossWS features (centralized endpoint registry, for instance). Also, I did not try your sample (need to mangle with my maven repository setup ;-) to make it build), but can you use EJB3 endpoints with your solution? what about webservice context injection in ejb3 endpoints? what about webservicerefs?
I'm not saying what you did is wrong, it's a nice way of having a single app running on Metro on a JBWS-Native configured application server. Unfortunately it's going to suffer from some issues, that's all ;-)
1 of 1 people found this helpful
Also, if you're interested in the details of the webservice endpoint deployment process, you might want to delve into the deployers code of the AS.
There's an interesting series of posts on DZone on this topic by Ales Justin.
Btw, on a related topic, I've recently worked on having 2 stacks coexist on AS for providing jaxrpc functionalities with Metro / CXF; you can read about that here.
Thank you for the very interesting links. The answer must lay in the details of deployment process. Shame that official docs/wiki is very vague on this topic. So far it seems to me that my assumption was correct, that deployment must be intelligent enough to spot Metro servlet configuration and recognize that Metro stack (bundled in stack) is to be used as WS implementation.
I am just worried how much reliable is this way. Does new version of JBossWS, JBoss, or Metro breaks it?
Yes, I perfectly aware of pros/cons of bundled in ws stack libraries inside EAR/WAR. My summary:
- simple, simpler then in your blog, you don't have to know many details about JBoss internals
- target server agnostit, "hermeutic" solution.
- nearly any WS implementation, including old version, version supporting WS-RPC can be used
- combined with my empiric observation that "all-containing" EARs are common practice not only regarding WS
- much bigger EAR/WAR, slower deploy
- is it really reliable solution?
I definitively don't assume my way as ideal, suggested, or recommended! It was simply one that I found first, that I know it works. Something that could stir the discussion. Which in your case worked .
My original reason was the very same. In some project we need to support two WS stacks, normal one and one "legacy" with support for WS-RPC (Apache Axis 1.x). The other reason was simple curiosity. Is it possible? How? And poor documentation coverage of this topic.