Mark Hansen wrote:
> I'm deploying a @WebService / @Stateless. The WSDL generated in GF V2
> B39 (built with JAX-WS 2.1) contains a bunch of WS-Policy markup (see
> below).
>
> When I generate a service/port from this WSDL using this code:
>
> String hostVal = System.getProperty("glassfish.host");
> String portVal = System.getProperty("glassfish.deploy.port");
> URL wsdlURL =
> new URL("http://"+hostVal+":"+portVal+"/HelloService/Hello?wsdl");
> printWSDL(wsdlURL);
> QName serviceQName = new QName("http://samples/", "HelloService");
> QName portQName = new QName("http://samples/", "HelloPort");
> Service service = Service.create(wsdlURL, serviceQName);
> Hello port = (Hello) service.getPort(portQName, Hello.class);
> String result = port.sayHello("Java Programmer");
>
> (Hello.class is the SEI generated from the Hello class below by wsgen)
>
> then, I get this error:
>
> java.lang.NoClassDefFoundError"
> message="com/sun/enterprise/transaction/TransactionImport">java.lang.NoClassDefFoundError:
> com/sun/enterprise/transaction/TransactionImport
>
> Why am I getting this error? And how can I turn off the WS-Policy
> markups in the WSDL?
Mark,
First off, I would like to state that the example above should just work.
There possibly is a configuration issue (such as classpath) or
something we can do better in packaging WSIT in glassfish.
The missing class is defined in <glassfish-install>/lib/appserv-rt.jar.
You could assist our evaluation of this issue if you could confirm the
following information.
Are you running a standalone client?
<glassfish-install>/bin/appclient specifies appserv-rt.jar so I assume
the class is not defined for that reason.
If you are running an application client, it could be you are getting the wrong version of
appserv-rt.jar. TransactionImport is not defined in AS 9.0
but it has been defined in AS 9.1 since June 27th.
http://fisheye5.cenqua.com/browse/glassfish/appserv-core/src/java/com/sun/enterprise/transaction/TransactionImport.ja
Lastly, could you confirm what JDK version and platform that you encountered this problem.
If you have a stack trace when the TransactionImport class was not found, it would be helpful
but this is not necessary if you don't have it.
*****************************
WORKAROUND suggestions:
If you do not want to introduce appserv-rt.jar to the classpath for
the possible standalone client, you may want to use a Java EE
concept that does not default to enabling transactions.
The easiest workaround would be to remove @javax.ejb.Stateless.
(Since transactions are enabled by default on a Stateless EJB.)
I noted in your other mail that you also discovered you could
use TransactionAttribute(NEVER). Addtionally, you could
use TransactionManagement(BEAN). No WS-AT policy assertions
will be generated for these EJBs.
While Web Service transaction semantics are only implemented in web and EJB tier in
Glassfish v2; however, you should be able to call an EJB method with
TransactionAttribute of REQUIRED.
**********
Explanation on why generated wsdl of a Container Managed Transaction (CMT) EJB
was generating a wsdl with ws-atomic transaction policy assertions in it.
By default, a stateless EJB has the following Transaction Attributes.
TransactionManaged(CONTAINER)
TransactionAttributeType(REQUIRED)
To ease mapping existing transacted Java EJB to a transactd web service, the above
attributes are getting mapped to semantically equivalent
ws-atomic transaction policy assertions. This is intended to be a feature.
I understand your frustration that this feature is not currently working properly
in your environment.
As the workaround pointed out, if transaction support is not required,
it might be best to just use a servlet or BEAN managed transaction.
-Joe Fialli
> -- Mark