This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
| Summary: | NoClassDefFoundError: org/openide/util/Enumerations$1RDupls due to use of WebServices | ||
|---|---|---|---|
| Product: | webservices | Reporter: | Exceptions Reporter <exceptions_reporter> |
| Component: | JAX-WS | Assignee: | Denis Anisimov <ads> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | ads, dkonecny, FrantaM, jglick, jtulach, jungi, mmirilovic, muellermi, pjiricka, vkraemer |
| Priority: | P1 | Keywords: | RELNOTE |
| Version: | 7.1 | ||
| Hardware: | All | ||
| OS: | All | ||
| URL: | http://java.net/jira/browse/JAX_WS-1059 | ||
| Issue Type: | DEFECT | Exception Reporter: | 186151 |
| Bug Depends on: | 213802 | ||
| Bug Blocks: | |||
| Attachments: |
stacktrace
Error message to blame GF 3.1.2 Error message to blame GF 3.1.2 generate different ant scripts to isolate wsimport task patch detecting buggy wsimport version addresses Denis' comments about previous proposed patch |
||
|
Description
Exceptions Reporter
2012-05-02 12:03:05 UTC
Created attachment 118971 [details]
stacktrace
The webservices Ant tasks cleaned the classpath again. (In reply to comment #2) > The webservices Ant tasks cleaned the classpath again. Jaroslav: Can you give me a bit more info about this note? Is there a previous issue that I might be able to look at for more info? Since there isn't any reference to GlassFish integration code in the ST, I am struggling to figure out what change I can make to the plugin code to resolve this issue. Lukáš should know. see #210690 btw: will be fixed in next GF 3.1.2 patch Hmm. So, this is assigned to GF integration plugin because we bundle a GF that has a bug in JAX-WS? What code change do you think would be necessary in the plugin to prevent this issue? It looks like we are actually dependent on changes in JAX-WS to resolve this. *** Bug 212470 has been marked as a duplicate of this bug. *** *** Bug 212471 has been marked as a duplicate of this bug. *** *** Bug 212467 has been marked as a duplicate of this bug. *** *** Bug 212469 has been marked as a duplicate of this bug. *** *** Bug 211999 has been marked as a duplicate of this bug. *** see issue 210690 for details. The number of duplicates is enormous, we cannot release 7.2 without a fix, imho. there are 2-3 options: -wait for GF 3.1.2.2 - not sure about its release date -wait for Metro 2.2.0.1 (question of days), update it in NB and patch current GF from within the GF plugin (=replace metro jars in GF by NB ones) during server registration step -release note this on some highly visible place (In reply to comment #15) > there are 2-3 options: > > -wait for GF 3.1.2.2 - not sure about its release date The code change for this would be in the code that creates the installation archives. > -wait for Metro 2.2.0.1 (question of days), update it in NB and patch current > GF from within the GF plugin (=replace metro jars in GF by NB ones) during > server registration step This is dependent on the metro bits getting updated in NB. I am going to assign this back onto webservices. When the bits for 2.2.0.1 get integrated into NB, assign this issue back onto serverplugins/GlassFish v3 and I will finish the change. Which files will be updated in the nb release bits? nbbuild/netbeans//enterprise/modules/ext/javaee6-endorsed/jaxb-api-osgi.jar nbbuild/netbeans//ide/modules/ext/jaxb/api/jaxb-api.jar nbbuild/netbeans//ide/modules/ext/jaxb/jaxb-impl.jar nbbuild/netbeans//ide/modules/ext/jaxb/jaxb-xjc.jar nbbuild/netbeans//ide/modules/ext/jaxb/jaxb1-impl.jar nbbuild/netbeans//java/modules/ext/jaxws22/api/jaxws-api.jar nbbuild/netbeans//java/modules/ext/jaxws22/jaxws-rt.jar nbbuild/netbeans//java/modules/ext/jaxws22/jaxws-tools.jar > -release note this on some highly visible place Lukas could you please comment is it duplicate of issue #210690 ? I know the exception is different but as I understand the reason is the same. I've updated the JAX-WS with recent version 2.2.6-1 where the bug #210690 is fixed: see issue #212616 and issue #212617. So the following jars are up-to-date and doesn't have the problem: nbbuild/netbeans//ide/modules/ext/jaxb/api/jaxb-api.jar nbbuild/netbeans//ide/modules/ext/jaxb/jaxb-impl.jar nbbuild/netbeans//ide/modules/ext/jaxb/jaxb-xjc.jar nbbuild/netbeans//ide/modules/ext/jaxb/jaxb1-impl.jar nbbuild/netbeans//java/modules/ext/jaxws22/api/jaxws-api.jar nbbuild/netbeans//java/modules/ext/jaxws22/jaxws-rt.jar nbbuild/netbeans//java/modules/ext/jaxws22/jaxws-tools.jar JAX-WS and JAXB has the latest available version. Metro lib is still 2.0 in NB. Does this version contain the issue ? I suppose the problem is GF bundled jar files used in the NB project. So this is not NB bug . It is consequence of using GF as target JEE server. So this is not NB bug and I can't fix it. Please point to me what can I do on the WS area. (In reply to comment #17) > Lukas could you please comment is it duplicate of issue #210690 ? > I know the exception is different but as I understand the reason is the same. yes, both issues are the same but this one has higher priority > > I've updated the JAX-WS with recent version 2.2.6-1 where the bug #210690 > is fixed: see issue #212616 and issue #212617. > So the following jars are up-to-date and doesn't have the problem: ... > JAX-WS and JAXB has the latest available version. almost true, I had to release 2.2.6-2 for metro 2.2.0.1 (diff is only in definition of version number for OSGi, so since you don't use/include these bundles, it is not necessary to update to this version) > > Metro lib is still 2.0 in NB. Does this version contain the issue ? no but it is quite old > > I suppose the problem is GF bundled jar files used in the NB project. > So this is not NB bug . It is consequence of using GF as target JEE server. > So this is not NB bug and I can't fix it. > Please point to me what can I do on the WS area. the idea is -on ws side - update Metro lib in NB to 2.2.0.1 as soon as it becomes available (currently being tested and I should know the status within <24h) and make sure it contains Metro OSGi bundles -on gf plugin side - patch GF 3.1.2 during server registration (replace metro jars in gf by those bundled in NB ) (In reply to comment #18) > (In reply to comment #17) > > Lukas could you please comment is it duplicate of issue #210690 ? > > I know the exception is different but as I understand the reason is the same. > > yes, both issues are the same but this one has higher priority > > > > > I've updated the JAX-WS with recent version 2.2.6-1 where the bug #210690 > > is fixed: see issue #212616 and issue #212617. > > So the following jars are up-to-date and doesn't have the problem: > ... > > JAX-WS and JAXB has the latest available version. > > almost true, I had to release 2.2.6-2 for metro 2.2.0.1 (diff is only in > definition of version number for OSGi, so since you don't use/include these > bundles, it is not necessary to update to this version) > > > > > Metro lib is still 2.0 in NB. Does this version contain the issue ? > > no but it is quite old - This is out of scope this issue. - It means there is nothing to do in the WS area respectively the bug. > > > > > I suppose the problem is GF bundled jar files used in the NB project. > > So this is not NB bug . It is consequence of using GF as target JEE server. > > So this is not NB bug and I can't fix it. > > Please point to me what can I do on the WS area. > > the idea is > -on ws side - update Metro lib in NB to 2.2.0.1 as soon as it becomes available Once again : this issue has no relation to current Metro version bundled with NB. Separate issue should be filed against Metro lib update. It should not has a high priority because it just about version update. All works fine with the current version. > (currently being tested and I should know the status within <24h) and make sure > it contains Metro OSGi bundles > -on gf plugin side - patch GF 3.1.2 during server registration (replace metro > jars in gf by those bundled in NB > ) This bug is purely runtime libs issue and has no any relation to WS area in NB. There is nothing to do on WS side. Newer version GF should be bundled with NB and GF 3.1.2 should be deprecated to use. Reassigning back. > patch GF 3.1.2 during server registration (replace metro jars in gf by those bundled in NB)
I must say I don't like this approach much - it's too much magic, and our philosophy is to let the user use a vanilla GlassFish without any tweaks and modifications. I don't like if the IDE is silently modifying GlassFish. Besides, the IDE may not have the write privileges for the GlassFish directory.
One other possibility that we discussed with Lukas Jungmann and Martin Grebac: Would it be possible to detect the situation when this is about to happen, and alert the user? The alert would just be a warning with a link to information page telling the user how to avoid the problem, e.g. by asking him to download the new Metro and modify GlassFish installation herself. This alert would be displayed e.g. when the user is about to create a ws client, or build a project that uses the wsimport task, or in other relevant situations.
Cc'ing David Konecny as the owner of web project so he can comment on the "alert the user before building" possibility.
Would it be possible to implement the check Petr is talking about directly in Ant script defining wsimport task? Detect problematic version of library on classpath used to define wsimport task and simply abort the build with error describing what's wrong and what user should do. If logic of detection of wrong jar version would be too complicated to be done in Ant script then we could introduce a new property in WebProject/EjbProject/Java project(?) which would be passed to build (eg. version of problematic jar or something) so that build script itself can abort itself based on it. As this is just a hotfix to help users we should make this as isolated change as possible. Btw. you can fork new Ant process before using wsimport. That would leave IDE unaffected of wrong behavior of wsimport task. another option, perhaps simpler, could be in case of GF 3.1.2 to alter wsimport/wsgen classpath in project/private properties to not use jars from GF but those from IDE (only web/ejb project types are affected) Created attachment 119827 [details]
Error message to blame GF 3.1.2
This patch will change info message in wizard to error informing user about bug in JAX-WS. It's one of possible fixes that were discussed before.
Comment on attachment 119827 [details]
Error message to blame GF 3.1.2
diff -r 026c2639abcc glassfish.common/src/org/netbeans/modules/glassfish/common/wizards/AddServerLocationPanel.java
--- a/glassfish.common/src/org/netbeans/modules/glassfish/common/wizards/AddServerLocationPanel.java Thu May 24 16:37:10 2012 +0200
+++ b/glassfish.common/src/org/netbeans/modules/glassfish/common/wizards/AddServerLocationPanel.java Thu May 24 16:37:59 2012 +0200
@@ -61,6 +61,7 @@
import javax.swing.event.ChangeEvent;
import javax.swing.event.ChangeListener;
import org.netbeans.modules.glassfish.common.GlassfishInstance;
+import org.netbeans.modules.glassfish.common.ServerDetails;
import org.netbeans.modules.glassfish.spi.TreeParser;
import org.netbeans.modules.glassfish.spi.Utils;
import org.openide.filesystems.FileUtil;
@@ -228,9 +229,14 @@
wizard.putProperty(PROP_ERROR_MESSAGE, statusText);
return false;
} else {
- wizard.putProperty(PROP_ERROR_MESSAGE, null);
- wizard.putProperty(PROP_INFO_MESSAGE, NbBundle.getMessage(
+ if (candidate == ServerDetails.GLASSFISH_SERVER_3_1_2) {
+ wizard.putProperty(PROP_ERROR_MESSAGE, NbBundle.getMessage(
+ AddServerLocationPanel.class, "ERR_BrokenGF3_1_2", candidate)); // NOI18N
+ } else {
+ wizard.putProperty(PROP_ERROR_MESSAGE, null);
+ wizard.putProperty(PROP_INFO_MESSAGE, NbBundle.getMessage(
AddServerLocationPanel.class, "MSG_NextForSpecial", candidate)); // NOI18N
+ }
}
}
}
diff -r 026c2639abcc glassfish.common/src/org/netbeans/modules/glassfish/common/wizards/Bundle.properties
--- a/glassfish.common/src/org/netbeans/modules/glassfish/common/wizards/Bundle.properties Thu May 24 16:37:10 2012 +0200
+++ b/glassfish.common/src/org/netbeans/modules/glassfish/common/wizards/Bundle.properties Thu May 24 16:37:59 2012 +0200
@@ -158,6 +158,7 @@
ERR_InvalidAdminPort=Invalid port value: {0}
MSG_RegisterRemote=Register remote instance: {0}:{1}
+ERR_BrokenGF3_1_2=<html>{0} is known to have serious bug in JAX-WS.<br>This bug may cause NetBeans to stop responding.<br>Click Next if you really want to register remote or custom local domains with broken server.</html>
MSG_NextForSpecial=Detected a {0} install. Click Next to register remote or custom local domains.
ERR_InvalidDomainData=The domain ({0}) has invalid data in domain.xml
Created attachment 119829 [details]
Error message to blame GF 3.1.2
One more try. :)
(In reply to comment #22) > Btw. you can fork new Ant process before using wsimport. That would leave IDE > unaffected of wrong behavior of wsimport task. this is probably 'the better way' to resolve this. i will work up a patch that does this and attach it... since none of the changes will be in the GF plugin modules (as far as I can tell) I made this simple one just to have something ready. Lukas is also planning to try another fix - put one more ClassLoader before ant to let it close it without causing damage in existing ones. He'll give it a try next week. Unfortunately we can't do much with Glassfish itself now. I have no idea if there is some way to bundle sustaining patch update (3.1.2.2) with NetBeans. Those releases are usually only for customers paying support so we may need some management agreement for this. (In reply to comment #27) > (In reply to comment #22) > > Btw. you can fork new Ant process before using wsimport. That would leave IDE > > unaffected of wrong behavior of wsimport task. > > this is probably 'the better way' to resolve this. i will work up a patch that > does this and attach it... since none of the changes will be in the GF plugin > modules (as far as I can tell) This is trickier than I first thought... Just about any call to ActionUtils.runTarget could trigger a call to wsimport. Putting an exec of ant in that method will probably break something else. So, it seems like we need to change the generated ant script to run the wsimport task 'stand-alone'. Created attachment 119848 [details]
generate different ant scripts to isolate wsimport task
This is really only part if the patch. We probably need to add some code that detects that the jaxws-build.xml file was generated with the 'old' xsl file. If the file is old, we can/should regenerate it. I guess that would be done when a project opens?
it looks like the regen of jaxws-build.xml is already taken care of... so this patch may be all we need to close this... but I guess Lukas or Denis would need to evaluate the change... Denis and/or Lukas: please evaluate the attached patch. Are there other places where we use the wsimport ant task? (In reply to comment #32) > Denis and/or Lukas: please evaluate the attached patch. Are there other places > where we use the wsimport ant task? The fix looks good and it seems there are no other places where wsimport ant task is used. From my opinion the ant task modification respectively GF problem is not a best solution. Such situation with buggy ant task could appear at any time with any other external Ant task used by IDE. So the more appropriate solution could be denying any dangerous ant task actions in the NB Ant support infrastructure. (In reply to comment #33) > (In reply to comment #32) > > Denis and/or Lukas: please evaluate the attached patch. Are there other places > > where we use the wsimport ant task? > > The fix looks good and it seems there are no other places where wsimport ant > task is used. > From my opinion the ant task modification respectively GF problem is not > a best solution. > Such situation with buggy ant task could appear at any time with any > other external Ant task used by IDE. > So the more appropriate solution could be denying any dangerous ant task > actions > in the NB Ant support infrastructure. I agree with your statements about providing a better way to prevent this kind of problem by hardening the ant support. That kind of change may have broader ramifications that we would want to avoid at this point in the release cycle though. Let's see what's Jesse's opinion about the latest proposal. Jesse? *** Bug 213192 has been marked as a duplicate of this bug. *** *** Bug 213191 has been marked as a duplicate of this bug. *** I probably do not have all the context, but: Ant scripts are run in-VM and there is no straightforward way to change that; the Ant process is already isolated at the ClassLoader level as much as is feasible. If there is a task which makes some kind of unfounded assumption about its environment, it may not run correctly; usually this is harmless enough but bug #210690 comment #19 suggests that <wsimport> is bordering on malicious. My understanding of the current proposal is to forbid the user from running an obsolete and buggy version of this task, which makes sense. If this can be done easily at the GUI level, fine; it might also be possible to register an AntLogger which detects <wsimport> of a particular version, though currently an AntLogger callback cannot halt execution of a script (RuntimeException is caught and logged; maybe throwing ThreadDeath would work but this is drastic). Thanks Jesse for the analysis. Another proposal is to fork the execution of the wsimport task to a separate process, but this would also apply to the non-buggy versions of the task, so it does not sound very clean.
Next, regarding this comment by Denis:
> Such situation with buggy ant task could appear at any time with any
> other external Ant task used by IDE.
I would hope that this situation is very rare, it is the first time I am aware of such a situation, I don't think we faced this ever before. So I think it's ok to have a solution specific to this particular buggy version of wsimport.
Let me try to summarize the possible solutions, I am listing them in my own order of preference:
Option 1: Detect the buggy version of wsimport before running the build and tell the user to update JAX-WS in GlassFish before running the build.
Option 2: Detect the buggy version of wsimport while running the build (using AntLogger as Jesse suggests), assuming we can halt the execution of the script.
Option 3: Fork the wsimport execution task to a separate process in all cases (whether the version of wsimport is buggy or not).
Option 4: Detect the buggy version of wsimport while running the build (using AntLogger as Jesse suggests), assuming we can NOT halt the execution of the script.
Is Option 1 feasible? This would necessitate changes in the actions of several project types, right? I guess this is a question for David K (and Denis), right?
What do others think should be the preferred solution?
(In reply to comment #39) > Thanks Jesse for the analysis. Another proposal is to fork the execution of the > wsimport task to a separate process, but this would also apply to the non-buggy > versions of the task, so it does not sound very clean. > > Next, regarding this comment by Denis: > > Such situation with buggy ant task could appear at any time with any > > other external Ant task used by IDE. > > I would hope that this situation is very rare, it is the first time I am aware > of such a situation, I don't think we faced this ever before. So I think it's > ok to have a solution specific to this particular buggy version of wsimport. > > Let me try to summarize the possible solutions, I am listing them in my own > order of preference: > > Option 1: Detect the buggy version of wsimport before running the build and > tell the user to update JAX-WS in GlassFish before running the build. > Option 2: Detect the buggy version of wsimport while running the build (using > AntLogger as Jesse suggests), assuming we can halt the execution of the script. > Option 3: Fork the wsimport execution task to a separate process in all cases > (whether the version of wsimport is buggy or not). > Option 4: Detect the buggy version of wsimport while running the build (using > AntLogger as Jesse suggests), assuming we can NOT halt the execution of the > script. > > Is Option 1 feasible? This would necessitate changes in the actions of several > project types, right? I guess this is a question for David K (and Denis), > right? I'm not sure what do you mean under "build" term. The problem is not just project build action. There are number of usages "wsimport" task out of build project. F.e. it used inside WS from wsdl wizard. It means there are two ways to follow the Option 1: - Find each wsimport ant task call in NB and modify the code with suggested user notification. - Introduce the special code inside ant target where wsimport is called. I don't like the first way at all. It requires too many modifications. The second way localizes the code inside one Ant target and is more preferable against first. But there are disadvantages: - Some custom Ant task is required to notify the user about buggy wsimport task. I could be mistaken but I don't see a way to detect wsimport version using only standard Ant tasks. - We still need to modify ant target. As result it is very similar to Option 3. So from my point of view the Option 3 is most preferable way to provide workaround for the issue. I'm not sure if it is possible to improve the Option 3 approach with conditional fork: if there is a way to detect buggy wsimport task ( via some common ant project independent properties or via Ant targets ) then wsimport could be called in the separate process or not. > > What do others think should be the preferred solution? There is code available that implements option 3. Option 3 doesn't require the user to do anything with GF servers that they may already have. Option 3 also decouples the 7.2 release schedule from the release schedule of other components like: a JAX-WS update, a patch for 3.1.2 or a GF update to 3.1.3. To me any option is good as long as it does the work. If it is option 3 be it 3. Is there any performance penalty for forking new java process? Probably negligible, right? If you can ask to fork wsimport (#3) then I would recommend doing it that way. I did not realize this was even an option. Ah, if by "fork" you mean the patch in comment #30 then this is not very desirable; output will look poor and AntLogger's cannot "see" into the forked Ant process. I thought you meant that the <wsimport> task itself accepted some fork="true" parameter, as many Ant tasks do. (In reply to comment #44) > Ah, if by "fork" you mean the patch in comment #30 then this is not very > desirable; output will look poor and AntLogger's cannot "see" into the forked > Ant process. I thought you meant that the <wsimport> task itself accepted some > fork="true" parameter, as many Ant tasks do. Are there changes that you think would improve the patch that was proposed in comment #30 and address your concerns? (In reply to comment #45) > Are there changes that you think would improve the patch that was proposed in > comment #30 and address your concerns? No, this approach is just awkward. But it may be the least of the available evils. In the light of Jesse's comment Option 3 has disadvantage that such change is permanent while lifespan of broken wsimport is going to be very short. Let's look at Option 1 once again. I will comment on Denis' issues related to Option 1: (In reply to comment #40) [...] > > Option 1: Detect the buggy version of wsimport before running the build and > > tell the user to update JAX-WS in GlassFish before running the build. [...] > It means there are two ways to follow the Option 1: > - Find each wsimport ant task call in NB and modify the code with suggested > user notification. How many calls there really are? Few or dozens? I imagine we would introduce somewhere a helper public method like void updateAntPropertiesWithVersionOfJaxSomethingJar(Properties, Project); which would check project's classpath and detected version of problematic jar and hardcoded some property into properties which are then passed to Ant execution. And before <wsimport> task execution there would be <fail message="update your jax version first as described at ....." if="classpath.has.wrong.version.of.jax.jar"/> (Or alternatively the method could just show dialog box and abort Ant start) Calling such Java method in few places would not be a big deal. And it could be removed again in two years. :-) So I would say if it is 3-5 places that's OK. If it dozen and more that would be ugly. > - Introduce the special code inside ant target where wsimport is called. > I don't like the first way at all. It requires too many modifications. > The second way localizes the code inside one Ant target and is more preferable > against first. > But there are disadvantages: > - Some custom Ant task is required to notify the user about buggy wsimport > task. I could be mistaken but I don't see a way to detect wsimport version > using only standard Ant tasks. I would consider providing an Ant task only if answer to previous question is that there are indeed dozens on places where updateAntPropertiesWithVersionOfJaxSomethingJar() would have to be called. > - We still need to modify ant target. That's easy one. (In reply to comment #47) > Calling such Java method in few places would not be a big deal. And it could be > removed again in two years. :-) So I would say if it is 3-5 places that's OK. > If it dozen and more that would be ugly. > I've found 5 usages of "wsimport-client-xxxx" target and 2 usages of "wsimport-service-xxx" target. By the way the fix proposed by Vince doesn't contain correction for "wsimport-service-xxx" target. The "wsimport-client-xxxx" task is used for client generation but "wsimport-service-xxx" is used for service generation. Both contains "wsimport" Ant task call. So Denis, can you please create a patch that would implement option 1? When we have this patch, we can decide how ugly it is (from both code and user experience perspective). Thanks. (In reply to comment #49) > So Denis, can you please create a patch that would implement option 1? When we > have this patch, we can decide how ugly it is (from both code and user > experience perspective). Thanks. OK. Created attachment 120209 [details]
patch detecting buggy wsimport version
(In reply to comment #51) > Created attachment 120209 [details] > patch detecting buggy wsimport version Here is the patch. *** Bug 213286 has been marked as a duplicate of this bug. *** (In reply to comment #51) > Created attachment 120209 [details] > patch detecting buggy wsimport version The message to the user in websvc.jaxwsmodel/src/org/netbeans/modules/websvc/api/jaxws/project/Bundle.properties should have a pointer to some document or the like to provide detailed instructions for 'Please update it with a newer version'. Otherwise, this looks ok to me. mnfst.getMainAttributes().getValue could return null - be careful. Also consider using o.o.m.SpecificationVersion if appropriate (catch NFE). Basic IDE of patch seems reasonable. You will not catch cases where the user explicitly runs one of the Ant targets e.g. from a build.xml node, but that is probably OK. *** Bug 213299 has been marked as a duplicate of this bug. *** *** Bug 213490 has been marked as a duplicate of this bug. *** web-main#65b668cbfb72 *** Bug 213493 has been marked as a duplicate of this bug. *** *** Bug 213701 has been marked as a duplicate of this bug. *** Integrated into 'main-golden', will be available in build *201206080001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/65b668cbfb72 User: Denis Anisimov <ads@netbeans.org> Log: Workaround for Metro/JAX-WS bug in GF 3.1.2 for BZ#211962 - NoClassDefFoundError: org/openide/util/Enumerations$1RDupls due to use of WebServices A few comments: - With the fix, when I generate a WS client, I get the alert dialog and the build fails, which is good. But when I then do Clean and Build, the build runs without any error, and I get the NoClassDefFoundError later. So I am reopening. - I think the alert dialog UI could be cleaner, I filed a separate bug 213802 for this. - This problem still be recorded in the release notes, adding the RELNOTE keyword. (In reply to comment #62) > A few comments: > - With the fix, when I generate a WS client, I get the alert dialog and the > build fails, which is good. But when I then do Clean and Build, the build runs > without any error, and I get the NoClassDefFoundError later. So I am reopening. > Right. wsimport-xxxx tasks are used as dependency for wsimport-service/client-generate task. The latter task could be used in some ant tasks defined in the main buil-impl.xml file. That's the case. That's why my original feelings was against of changes proposed by David in the Java source where ant task is called. The custom Ant task added as dependency in wsimport-xxx would avoid such problem: it would called at any time when original wsimport-xxx is called whenever it is called from Java code or via other Ant task. I see here only one solution : set property ( signal of bad jar file ) as project property instead of call wsimport-xxx ant task with this property as additional. So you are saying that it's not possible to pass this property by the Build/Clean and Build action itself? I guess this would need to be done for all kinds of projects that may contain a WS client, i.e. Java Web, EJB-JAR, Java SE. Also, there is one more issue: - I get no warning dialog when creating a web service client in a Java SE project (In reply to comment #64) > So you are saying that it's not possible to pass this property by the > Build/Clean and Build action itself? I guess this would need to be done for all > kinds of projects that may contain a WS client, i.e. Java Web, EJB-JAR, Java > SE. Currently the wsimport-xxx ant task is called via ActionUtils.runTarget() where third argument contains the property that fails ant task execution . If you mean that this property should be set for "clean/build" in the same manner as it set for wsimport-xxx then I strongly object against it. It will require a lot of changes in the places that has no relation to wsimport-xxx ant task. Such approach doesn't guarantee that the issue will not appear again with some other ant task that depends on wsimport-yyy-generate. So it is possible but it is very bad approach from my point of view. The alternate way which I've already mentioned: set the project property when wsimport-xxx ant task is called instead of passing the property as third argument in runTarget. This property will be set for project and each subsequent call of wsimport-xxx ant task will fail because existing property whenever it is called via NB code ( UI ) or any other way. > > Also, there is one more issue: > - I get no warning dialog when creating a web service client in a Java SE > project That's a correct behavior : JEE project ( car, war, ear ) uses target JEE server JAX-WS( Metro ) libraries. JSE project has no target JEE server. So JSE project uses NB bundled JAX-WS library without the GF issue . Thanks for explaining. So what's other people's opinion? Jesse, David? I do not know enough about the usage of the task to comment. Created attachment 120572 [details]
addresses Denis' comments about previous proposed patch
incorporates the change that Denis called out in a comment a couple days ago. Obsoletes my previous suggested patch...
Regarding the current poll for opinions: the detect and warn approach is becoming really complex. Maybe we should just take the boldest move to avoid the issue today and clean the ant tasks to behave better when we start to ship 7.x with 3.1.3...
(In reply to comment #68) > Created attachment 120572 [details] > addresses Denis' comments about previous proposed patch > > incorporates the change that Denis called out in a comment a couple days ago. > Obsoletes my previous suggested patch... Vince, there was an argument against such approach : output will look poor and AntLogger's cannot "see" into the forked Ant process ( see Jesse's comment #44 ). The suggested fix perfectly works but it calls wsimport via forked java process regardless of wsimport version ( for any GF target server and even if JAX-WS bundled with NB is used ). So it really has disadvantages. > > Regarding the current poll for opinions: the detect and warn approach is > becoming really complex. Maybe we should just take the boldest move to avoid > the issue today and clean the ant tasks to behave better when we start to ship > 7.x with 3.1.3... I agree that it becomes complex. We cannot fix the bug but just provide a workaround for it. The issue will be fixed when GF newer version will be used ( and bundled with NB ). My last suggestion about project property doesn't introduce too much complexity for the fix : it is localized in the one method and requires a several lines. It is also not ideal because project property will not be changed without wsimport related wizard running. But it is actually not a problem and it defends NB from wsimport-xxx ant task to be executed for sure. That's exactly we need to achieve and I would not introduce any other improvements for the fix. web-main#38cd91275787 The additional fix set project property that prevents wsimport-xxx to execute. Each wsimport-xxx direct involvement check the wsimport jar version and reset the property if version doesn't contain the bug. Integrated into 'main-golden', will be available in build *201206100001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/38cd91275787 User: Denis Anisimov <ads@netbeans.org> Log: Additional fix for BZ#211962 - NoClassDefFoundError: org/openide/util/Enumerations$1RDupls due to use of WebServices (In reply to comment #65) > If you mean that this property should be set for "clean/build" in the same > manner as it set for wsimport-xxx then I strongly object against it. > It will require a lot of changes in the places that has no relation to > wsimport-xxx ant task. Such approach doesn't guarantee that the issue will > not appear again with some other ant task that depends on > wsimport-yyy-generate. > So it is possible but it is very bad approach from my point of view. I thought that this is how we are hot-fixing the problem - any execution of Ant task which can result into execution of wsimport task must set the property. You fixed it for wizards which execute the wsimport directly but not for project actions itself. Each relevant project type should have set the property as well, for example for Web Project I think a single place where the property would have to be set is WebActionProvider.getTargetNames. I would never say this is a good approach - it's lesser evil option. :-) Re. setting property - sounds good to me if it works. The only worry is that after user upgraded the broken jar they must be aware that they need to trigger some wizard to remove the property from project properties. Otherwise build will get aborted even after jar was fixed. Should be solvable by a good error message explaining the issue. *** Bug 213956 has been marked as a duplicate of this bug. *** For reference, the root cause on the JAX-WS side is http://java.net/jira/browse/JAX_WS-1059. *** Bug 215753 has been marked as a duplicate of this bug. *** *** Bug 215652 has been marked as a duplicate of this bug. *** *** Bug 215651 has been marked as a duplicate of this bug. *** *** Bug 215649 has been marked as a duplicate of this bug. *** *** Bug 216504 has been marked as a duplicate of this bug. *** *** Bug 216118 has been marked as a duplicate of this bug. *** *** Bug 215189 has been marked as a duplicate of this bug. *** *** Bug 216542 has been marked as a duplicate of this bug. *** *** Bug 217329 has been marked as a duplicate of this bug. *** *** Bug 215653 has been marked as a duplicate of this bug. *** *** Bug 216453 has been marked as a duplicate of this bug. *** *** Bug 218011 has been marked as a duplicate of this bug. *** *** Bug 218249 has been marked as a duplicate of this bug. *** *** Bug 219625 has been marked as a duplicate of this bug. *** *** Bug 218473 has been marked as a duplicate of this bug. *** *** Bug 220314 has been marked as a duplicate of this bug. *** *** Bug 220776 has been marked as a duplicate of this bug. *** *** Bug 220777 has been marked as a duplicate of this bug. *** *** Bug 220781 has been marked as a duplicate of this bug. *** *** Bug 221164 has been marked as a duplicate of this bug. *** *** Bug 219623 has been marked as a duplicate of this bug. *** *** Bug 215654 has been marked as a duplicate of this bug. *** *** Bug 222726 has been marked as a duplicate of this bug. *** *** Bug 224424 has been marked as a duplicate of this bug. *** *** Bug 225129 has been marked as a duplicate of this bug. *** *** Bug 227795 has been marked as a duplicate of this bug. *** *** Bug 213311 has been marked as a duplicate of this bug. *** *** Bug 230915 has been marked as a duplicate of this bug. *** |