Hi Joe,
Thanks for the nice explanation. I am not running the appclient. I am
running Java SE 5, as follows:
java version "1.5.0_10"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_10-b03)
Java HotSpot(TM) Client VM (build 1.5.0_10-b03, mixed mode)
So, <glassfish-install>/lib/appserv-rt.jar is not on the classpath.
I understand the various workarounds you describe - thanks for all the
detail.
My opinion on this, for what it is worth, is that its a *bad* idea to
generate WS-AT policy assertions *by default* for @STATELESS Web
services. WS-AT policy support is a great idea, but it should be
*optional* for a bunch of reasons:
* It introduces a sort of non-backward compatibilty from JAX-WS 2.1 to
JAX-WS 2.0. That is particulary bad since Java EE 5 services can use
either version of JAX-WS. By having this WS-AT behavior as the default,
you can get very different WSDLs and runtime client behaviors by
deploying an @STATELESS on 2 different containers that are both Java EE
5 certified. See my previous mail on this thread about that.
* As a general architectural principle, all the WS-* specs should be
turned off by default for WSDL generation. Nobody has much real-world
experience with these specs, and its a safe bet that most people will
want to keep their WSDL as simple as possible until they gain experience
working with the WS-*.
* Its a mistake to tightly couple the container behavior (e.g., the
transactional nature of a bean) to its WSDL. Think of the WSDL as a JSF
or interface definition wrapper around the bean.. It shouldn't by
*default* contain *all* the information about the underlying
implementation. JAX-WS should not be trying to reimplement Java
container semantics in the SOAP/XML world. There may be good reasons to
have a non-transactional WSDL representation that is implemented by an
underlying bean that is transacted.
JAX-RPC stumbled in part because it tied "RPC" semantics too tightly to
the WSDL/SOAP. Shortly after JAX-RPC came out, people realized that in
the WSDL/SOAP world, it is more useful to work with doc/lit services and
think in terms of message passing. I am worried that JAX-WS 2.1 is now
repeating that kind of mistake with the new WS-* specifications. JAX-WS
should not tightly couple things like transaction semantics or reliable
messaging (with MDB) to the WSDL representation that are generated by
default. For example, while it would be a nice option for a MDB to be
able to auto-generate WSDL with the proper WS-Reliability assertions,
that should not be required or even the default behavior.
JAX-WS is on the right track. Its a big improvement over JAX-RPC. It
would be great if we could keep it simple, not tie it too tightly to the
underlying Java, and give developers/deployers lots of options - with
the default behavior always being the simpliest possible WSDL that
sensibly maps to the underlying Java class.
-- Mark
Hi Joe,
Joseph Fialli wrote:
> 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
>
>