The problem seems to be in wsimport from GlassFish - if I take our (=from NB)
jaxws-tools.jar and copy its content to $GF_HOME/lib/webservices-tools.jar then
all works like a charm. Can we somehow get the build number of the JAX-WS 2.1
library in GF? Is it FCS version?

Seems this is problem of latest GlassFish builds.
Tested with the latest milestone build (V2 b33) and it works.

Rico can find out what version of jax-ws is used in lates GlassFish nightly build.

Still waiting for reply from the jaxws and jsr 109 folks, but looking at the
manifest of the jars in GF v2 b38, the jars are from jaxws 2.1.1 (i.e., post
jaxws2.1 FCS).
Also if I comment out the jvmargs (for the endorsed dir) or turn off the fork in
the wsimport task invocation, the wsimport succeeds. Are you getting the same
result?

I played also with wsgen, using the latest glassfish libraries (build 38).
Unlike for wsimport, specifying the fork="true" and jvmargs for endorsed
mechanism is necessary (the wsgen fails in compilation phase).

It turns out this is a known issue in Glassfish:
http://monaco.sfbay/detail.jsf?cr=6527842
There is a fix that was integrated from jaxws and we are waiting for the GF
build that will have this fix, probably late this week.

It does not seem to be in 5.5.1, perhaps this has occurred in trunk build.

Re Rico: "Also if I comment out the jvmargs (for the endorsed dir) or turn off
the fork in
the wsimport task invocation, the wsimport succeeds. Are you getting the same
result?"

Yes, my result is the same.

Re pflaska: It happens in NB 5.5.1 if you run IDE and latest GF (b37-38) on
JDK6, at least on linux platform

Glassfish has released a new version that has the jaxws 2.1 jars with some
fixes. With this, we need to take out the jvmargs for the endorsed dir in our
wsimport target, including the forking. In its place , we need to add a new
attribute to the wsimport invocation: xendorsed="true".

Lukas, as discussed kindly test this new GF--it will be b39 onwards.
Thanks.
Rico

the solution with xendorsed="true" works fine in gf-v2-b39-nightly-12_mar_2007;
feel free to implement the proposed fix for this, so we can get it into r551 ASAP

Thanks

I am working on the "xendorsed=true" solution and realized this will work with
GF V2 but not with GF V1 because this wsimport option is new in GF V2. I heard
that NB 5.5.1 should be able to support GF V1/SA 9.0 

AFAIK in 5.5.1 we should support only AS 8.2 (for J2EE 1.4) and AS 9.1 (for Java
EE 1.5), so if our solution works fine for these versions of AS, then it is OK.
Petre or Petre, am I right? 

OTOH: Other question is whether we (NetBeans) can bundle the FCS version of
JAX-WS 2.1, if we know that this version of JAX-WS contain an important bug (I'm
afraid that the following is similar situation as with toplink...):

"The JAX-WS 2.1 final specification  uses and references the W3C WSDL Binding
specification which was being defined in the WS-Addressing Working Group. The
Binding  spec was in the Candidate Recommendation stage ( and expected to go to
Final Recommendation)  when we did the final release of the JAX-WS specification
and RI few weeks back. Since then it has come to our attention that the Binding
spec is not going to be made a Final Recommendation  and will instead be
replaced with an alternative specification. We believe we need to take
corrective action to address this issue.

Hence, we have temporarily removed access to the JAXWS 2.1 RI to prevent any use
of these until the specification issue is resolved. We apologize for any
inconvenience caused. We will have some more updates on it in approximately two
weeks.

In the meantime, continue using JAXWS 2.1 nightly.
"

The quotation is from "https://jax-ws.dev.java.net/2.1/" page as it was on 15th
March 2007 (just for a reference...)

> in 5.5.1 we should support only AS 8.2 (for J2EE 1.4) and AS 9.1

Well, this needs to change. Appserver 9.1 will not be released in time for NB
5.5.1 FCS, so we need to support the latest FCS version, which is 9.0. Also,
"supported" refers to the fact that it is certified by QE, but even for servers
that are not QE certified, we need to make sure it works. We should not
knowingly break features in recent versions such as AS 9.0, whether it is
supported or not.

So, Rico, do you think you can find a solution that would work for both 9.0 and
9.1? If necessary, you may need have two different build scripts for 9.0 and 9.1.

Petr, Yes I think so. We have to determine if the target server is GFv1 or GFv2.
From Vince, there is a way in 5.5.1 to definitively determine that. He's working
on the same for 6.0. Having said that, I'll give it a try and hopefully it will
work.

Created attachment 39736 [details]
Diff of changes to GeneratedFilesHelper class

Created attachment 39737 [details]
Diff of changes to the web project's build-impl.xsl

Created attachment 39738 [details]
Diff of changes to the ejb project's build-impl.xsl

Created attachment 39739 [details]
Diff of changes to the app client project's build-impl.xsl

The "xendorsed" attribute was introduced in wsimport in the newer versions of
the jaxws jars. The fix is to determine the target server and add the xendorsed
attribute to the wsimport invocation only if the target server is AS 9.1.
Diffs are included

The fix looks fine for me.

I'd just simplify the line :
<xsl:when test="not($isJSR109 = 'false')">
to
<xsl:when test="$isJSR109 = 'true'">

GeneratedFilesHelper:

Should check if roots isn't null before checking the length?

What about the situation where we have AS 9.2 and that AS has sun-domain_1_3.dtd
and sun-domain_1_4.dtd in the lib directory?

You may want to recode the test to check for AS 9.0, by doing the following...
see if there is a sun-domain_1_2.dtd AND there is not a sun-domain_1_3.dtd in
the lib/dtds directory.  I guess that would mean that the name of the test would
be isJAXWS20....

I guess you could apply the same basic pattern to preserve the isJAXWS21
'semantics'.. test to see if there is a sun-domain_1_3.dtd and there isn't a
sun-domain_1_4.dtd

Merged the fix to the 551 code line

I just looked at the changes merged into release551....

They are not even close to the changes submitted for review.  

Oh, well.

BTW: what was all the code that actually got integrated into release551 to
resolve this issue? 

OK Will update the diffs. I made some changes after submitting this diff cuz of
some dependency problem which resulted in a build failure. That is, a class in
the ide8 cluster depended on a class in the enterprise4 cluster and enterprise4
is built after ide8. So I had to implement an SPI. But the basic logic is still
the same, including the improvements suggested by Vince K.

Created attachment 39790 [details]
This supersedes the earlier GeneratedFilesHelper.diff

Created attachment 39791 [details]
WSUtils.diff--contains the improvements suggested by Vince K.

Created attachment 39792 [details]
SPI implementation in the web project.

Aren't there also changes in the various project modules like web/project and
j2ee/ejbjarproject that need to be called out?

Yes the following line was added to the WebProject (and similarly to the
EJBProject) to include it in the project lookup:

Index: WebProject.java
===================================================================
RCS file: /cvs/web/project/src/org/netbeans/modules/web/project/WebProject.java,v
retrieving revision 1.106
retrieving revision 1.107
diff -w -r1.106 -r1.107
100a101
> import org.netbeans.modules.web.project.jaxws.WebProjectJAXWSVersionProvider;
353a355
>             new WebProjectJAXWSVersionProvider(helper),

and the implementation of those classes was added, too. Right?

org.netbeans.modules.web.project.jaxws.WebProjectJAXWSVersionProvider is in the
web/project project.... right?

Yes that would be in the WebProjectJAXWSVersionProvider.diff attachment. 

Created attachment 39828 [details]
Complete WebProjectJAXWSVersion.java file

did the appclient-buildimp.diff turn out to be unnecessary?

Yes it is unnecessary in release551 because the app client was getting its
wsimport class from the internal IDE jars. This has been changed in NB 6.0 to
get the jars from Glassfish. Thus appclient-buildimp.diff is necessary in NB
6.0. When I fixed NB 6.0( following the release551 high resistance process) it
was not yet apparent to me that this was the case so I attached this file to
Issuezilla.

In summary, no this is not necessary in release551, and yes it is necessary in
NB 6.0

Note: appclient part is necessary for 6.0 because of the fix of issue 97754.
Since this issue is P3 I didn't port the fix back to 5.5.1 (this is the
difference in appclient between trunk and release551 branch)

I feel that the issues that I raised in earlier comments are resolved.

The changes made in build-inpl.xsl (Web project and EJB Project) as well as
changes in GeneratedFilesHelper class looks fine for me.

v.