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.
- Create Maven Web project - Create Web service class Result : there is no special node Web Services with created WS subnode. It seems this is background scan related issue.
For some reason JAXWSLightSupport.getWebservicesMetadataModel() return null inside MavenJaxWsSupportProvider CTOR.
Partial fix : web-main#afd7f37cb17f. WS node appears if JAXWSLightSupport.getWebservicesMetadataModel() doesn't return null. Still it is unknown why JAXWSLightSupport.getWebservicesMetadataModel() returns null.
I've corrected the code related to the issue in maven.jaxws. These changes are just code improvement. web-main#6965cd337221 The main problem is unresolved : JAXWSLightSupport.getWebservicesMetadataModel() returns null. I've realized that this is some generic problem. Here are results of my investigation : - Mentioned code is called inside dedicated thread started inside CTOR of MavenJaxWsSupportProvider. - MavenJaxWsSupportProvider instantiated inside MavenJaxWsLookupProvider.createAdditionalLookup(). MavenJaxWsLookupProvider class is registered in the project's lookup via @LookupProvider.Registration(projectType="org-netbeans-modules-maven") - JAXWSLightSupport.getWebservicesMetadataModel() call delegate to invocation to the MavenJAXWSSupportImpl instance ( which is created inside mentioned createAdditionalLookup previously ). - Here is corrected implementation of MavenJAXWSSupportImpl.getWebservicesMetadataModel(): J2eeModuleProvider j2eeModuleProvider = prj.getLookup(). lookup(J2eeModuleProvider.class); if (j2eeModuleProvider != null) { return j2eeModuleProvider.getJ2eeModule().getMetadataModel( WebservicesMetadata.class); } return null; This result of this code is : j2eeModuleProvider appears to be null and method returns with "return null;". That's the issue. For some reason prj.getLookup().lookup(J2eeModuleProvider.class) returns null. I have been able to find it only setting breakpoint at the line "return null;". One can set breakpoint at the first line of the code. In this case j2eeModuleProvider will be set to some non-null value. It seems there is some race condition: some thread calculate lookup when current thread is suspended. So prj.getLookup().lookup(J2eeModuleProvider.class) returns null if current thread proceed its work without pause. As result there are two different behavior depending on current thread state: 1) j2eeModuleProvider is initialized with J2eeModuleProvider instance 2) j2eeModuleProvider is null It means that lookup() method works inconsistently and this is a bug. The same problem could be found when prj.getLookup().lookup(J2eeModuleProvider.class) is called inside CTOR of MavenJAXWSSupportImpl ( to exclude one more thread used to invoke JAXWSLightSupport.getWebservicesMetadataModel() ). J2eeModuleProvider is implemented by WebModuleProviderImpl class defined in the maven.j2ee module via project registration : @ProjectServiceProvider(service = {WebModuleProviderImpl.class, WebModuleProvider.class, J2eeModuleProvider.class}, projectType = { "org-netbeans-modules-maven/" + NbMavenProject.TYPE_WAR }) That's could be a reason of the described behavior: both callee and caller are registered via Lookup. I don't know where is the problem source: Maven modules or generic Lookup functionality. So I'm assigning to the Maven for evaluation. That's a regression so I rise the priority. There could be other reasons for the original issue but they cannot be identified without solving described above problem. Please reassign back to WS after fixing Lookup problem if necessary.
Integrated into 'main-golden', will be available in build *201203150400* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/afd7f37cb17f User: Denis Anisimov <ads@netbeans.org> Log: Partial fix for BZ#209555 - WebService is not recognized in Maven project.
this is the code in maven project's constructor: basicLookup = createBasicLookup(projectState, auxiliary); lookup = LookupProviderSupport.createCompositeLookup(new PackagingTypeDependentLookup(watcher, basicLookup), "Projects/org-netbeans-modules-maven/Lookup");//NOI18N the project instance will return the basicLookup until the lookup variable is initialized in getLookup(). The web related instances are injected into the PackagingTypeDependentLookup. Your own instances are part of the generic maven lookup (non packaging dependent) you sometimes get null and sometimes proper instance from lookup because in some cases the project instance initialization has completed and in some other cases it has not.
http://hg.netbeans.org/core-main/rev/1cfe2b43fe32 this makes sure that you can use LookupResult to listen to changes in the lookup. In other words be notified when the j2ee web instance lands in the project instance (or gets removed, eg if user changes packaging type in the pom file)
(In reply to comment #6) > http://hg.netbeans.org/core-main/rev/1cfe2b43fe32 > > this makes sure that you can use LookupResult to listen to changes in the > lookup. In other words be notified when the j2ee web instance lands in the > project instance (or gets removed, eg if user changes packaging type in the pom > file) Do you have any idea why it worked without problem with previous releases ?
maybe the conversion to @ProjectServiceProvider ? and/or introduction of non-default request processors? no idea really, it might have only shifted from rare to common.. (In reply to comment #7) > (In reply to comment #6) > > http://hg.netbeans.org/core-main/rev/1cfe2b43fe32 > > > > this makes sure that you can use LookupResult to listen to changes in the > > lookup. In other words be notified when the j2ee web instance lands in the > > project instance (or gets removed, eg if user changes packaging type in the pom > > file) > > Do you have any idea why it worked without problem with previous releases ?
Integrated into 'main-golden', will be available in build *201203170400* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/6965cd337221 User: Denis Anisimov <ads@netbeans.org> Log: Some corrections respectively issue BZ#209555.
final fix on maven.jaxws area : web-main#8887042b2ac5 will work after merging fix from core-main ( 1cfe2b43fe32 ) and web-main.
Integrated into 'main-golden', will be available in build *201203200400* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/8887042b2ac5 User: Denis Anisimov <ads@netbeans.org> Log: Final fix for BZ#209555 - WebService is not recognized in Maven project
Not working for me with 7.2 Product Version: NetBeans IDE 7.2 (Build 201207171143) Java: 1.7.0_03; Java HotSpot(TM) 64-Bit Server VM 22.1-b02 System: Windows 7 version 6.1 running on amd64; Cp1252; de_DE (nb)
This still isn't working in 7.2. 1. Create a Maven Web Project. 2. Create a Web Service from the Wizard. You don't see the generated "Web Services" folder in the project like you do in the non-maven projects. Here's my info: Product Version: NetBeans IDE 7.2 (Build 201207171143) Java: 1.7.0_04; Java HotSpot(TM) 64-Bit Server VM 23.0-b21 System: Mac OS X version 10.8 running on x86_64; US-ASCII; en_US (nb)
I'm not able to reproduce it. Please delete your .netbeans userdir and check the issue with fresh userdir.
Created attachment 123366 [details] Maven Project Layout - Missing Web Services
Comment on attachment 123366 [details] Maven Project Layout - Missing Web Services I tried as suggested and deleted the .netbeans but still no luck.
So, just for fun I tried the trunk build of NB 7.2+/7.3 and it appears to have fixed the issue. When I create a maven web project and add a new Web Service after the code is created it takes a few seconds for the "Web Services" node to appear in the tree. I went back to 7.2 and tried the same thing and I can't get it to show up no matter what I do. So, it appears something is fixed after 7.2 was released to the public. Here's the info: Product Version: NetBeans IDE Dev (Build 201208211308) Java: 1.7.0_04; Java HotSpot(TM) 64-Bit Server VM 23.0-b21 System: Mac OS X version 10.8 running on x86_64; US-ASCII; en_US (nb)
Thanks for verifying - it would be useful to identify how this was fixed, so this fix can also be backported to the 7.2 patch.
Denis says it is not easy to find out why this is now working in 7.3 if it was not working in 7.2, there were no changes on the web services side. Milos, any ideas whether there may have been changes on the Maven side which fixed this? I am adding the 72patch-candidate so we keep an eye on it. When we have the first build of the patch, let's see if this is still happening in this build and if it was fixed by some other fix in the patch. If not, we'll need to continue to investigate.
(In reply to comment #19) > Denis says it is not easy to find out why this is now working in 7.3 if it was > not working in 7.2, there were no changes on the web services side. > Milos, any ideas whether there may have been changes on the Maven side which > fixed this? unfortunately no. I'm not aware of any changes in maven support that could be related. Maybe something with lookups?
Same problem in NB 7.2. Some notes here: http://forums.netbeans.org/viewtopic.php?t=51025 This works in NB 7.1.1. So I thought a workaround would be to create the project in NB 7.1.1 and then go back to NB 7.2 and open the project there and hope that the Web Service node would then magically appear. No such luck, unfortunately. I'm wondering how NB - when it opens an existing project - detects that the project has Web Services in it solely from the files saved on disk? Anyway, I believe this problem is rather serious. What can we do to debug/assist?
it could be a timing issue. That would explain why it works for some and not for the others. I'm still convinced that my initial assessment is correct, something in webservices is querying the project lookup before it's completely constructed, given that it's "random" I would say it some code from inside the lookup initialization loop is calling RequestProcessor.post or something similar. It was less of an issue in old times, because there was a part of the basic lookup constructed before the modular declarative one and there was just one declarative layer, now we have alsmost everything declarative and some declarations are packaging specific, probably effectively switching order of the lookup initialization in some cases or making it less predictable.
Milos, you sure got a point. In NB 7.2.: I tried creating the project, but not adding the web service. Then exiting the IDE. Then starting same IDE again (i.e. 7.2) and then trying to add the web service. Now it kind of works. When I add the Web Service I first get the "Non JSR-109 compliant web server detected" window, presumably because I use Tomcat. I click "OK" in this window. Then an Error box comes up saying "Cannot find deployment descriptor folder (WEB-INF)". (I also saw this behaviour in 7.1.1). However the Web Services node is now created in the Project window. Voila ! All in all I would say that this little test has proved Milos' point.
I'm falling back to using Tomcat + "Java EE 5" as opposed to using Tomcat + "Java EE 6 Web" but still on NB 7.2. I still have the problem that I need to exit the IDE and come back and add the web service before the Web Services node appears in the Projects window, but it saves me from another issue, namely that of sun-jaxws.xml and web.xml files not being generated which is described in #217892. That was a side note. Just to be clear: As far as I can tell the current issue - the fact that the Web Services node is not created in the Projects window - happens regardless of choice of EE container and choice of EE version. Which again seems to add weight to Milos' point.
(In reply to comment #22) > it could be a timing issue. That would explain why it works for some and not > for the others. I'm still convinced that my initial assessment is correct, > something in webservices is querying the project lookup before it's completely > constructed, given that it's "random" I would say it some code from inside the > lookup initialization loop is calling RequestProcessor.post or something > similar. > That was a definitely timing issue when I filed the bug. There is a detailed explanation why it happens in the comment 3. So this is not a new information. You provided a fix for the Maven project's lookup : http://hg.netbeans.org/core-main/rev/1cfe2b43fe32 After which I've corrected the WS area code. So it seems it doesn't help. Do you have any idea why ? phansson, could you please check your scenarios with development NB binaries (upcoming 7.3 release)?
I've tested on latest development build 201209090001. Sorry, I cannot see any improvement on this bug in that release. I cannot get the Web Service node to appear in the Projects window no matter if I start a new project from scratch, open an existing project that contains web services or add to an existing (previously created) web project. At least on 7.2 I was able to mae the IDE show the node if I re-started the IDE just before adding the Web Service. With dev buuld I cannot even do that. Sorry, I'm at a loss here. How do we know if the IDE is even *attempting* to create the node in the tree ? Here are my platform details: Product Version: NetBeans IDE Dev (Build 201209090001) Java: 1.7.0_05; Java HotSpot(TM) 64-Bit Server VM 23.1-b03 System: Windows 7 version 6.1 running on amd64; Cp1252; en_US (nb)
(In reply to comment #26) > I've tested on latest development build 201209090001. > > Sorry, I cannot see any improvement on this bug in that release. > > I cannot get the Web Service node to appear in the Projects window no matter if > I start a new project from scratch, open an existing project that contains web > services or add to an existing (previously created) web project. At least on > 7.2 I was able to mae the IDE show the node if I re-started the IDE just before > adding the Web Service. With dev buuld I cannot even do that. > > Sorry, I'm at a loss here. > > How do we know if the IDE is even *attempting* to create the node in the tree ? > > Here are my platform details: > Product Version: NetBeans IDE Dev (Build 201209090001) > Java: 1.7.0_05; Java HotSpot(TM) 64-Bit Server VM 23.1-b03 > System: Windows 7 version 6.1 running on amd64; Cp1252; en_US (nb) I will try to review the code and find exact steps to reproduce but I'm not able to reproduce the issue at the moment. One more request : have you started NB with fresh userdir ? There could be a interference issues with cached binaries. Please delete .netbeans folder on your home directory and start NB with fresh userdir. Then please check the issue.
I tested with the nightly build Dev201209110001, and the issue is still there. I cleared the .netbeans folder and created a new maven Web application project, then added a new web service. The "Web Service" node does not show up. Curiously, when I create a RESTful Web Service, the "RESTful Web Services" node shows up straight away. Env: Win 7 Entreprise 64bit java 1.6.30 Hope this helps
Created attachment 124228 [details] Maven WS module with logging
(In reply to comment #29) > Created attachment 124228 [details] > Maven WS module with logging phansson, ftz2012 and all other who are able to reproduce: Please use the attached nbm file. Install it in the IDE and follow the steps to reproduce the issue. Please attach here the IDE log file . I need this information from your box to understand what is the reason of described behavior. I'm not able to get this information on my box because all works fine for me.
Added logging with INFO level web-main#9d0816a0205d
I've tried to install the plugin but it says that the plugin is already installed. So I deleted the Maven plugin, then installed your plugin. The problem now is that I do not have the option to create a Maven Web Application project anymore. Any suggestion?
(In reply to comment #32) > I've tried to install the plugin but it says that the plugin is already > installed. > So I deleted the Maven plugin, then installed your plugin. The problem now is > that I do not have the option to create a Maven Web Application project > anymore. > Any suggestion? Have you deleted Maven plugin or maven j2ee plugin ? Attached plugin is maven.jaxws.
Created attachment 124244 [details] Plugin withi increased version
I suppose I need to reinstall the IDE and use last attached plugin. I've increased its version and now it could be upgraded.
@denis On NB 7.2. I've installed your plugin (latest version), restarted IDE and followed my own steps for reproduction. When I add the web service I still run into bug 217892 (when using Tomcat), but the Web Services node now appears ! Bottom line. With the plugin installed I can no longer reproduce the issue. So I think: Let's verify this. So I want to uninstall the plugin again in order to reproduce the bug (again) without the plugin. However then something strange: The plugin doesn't appear in my list of installed plugins ! I'm supposedly looking for a plugin named "Maven JAX-WS", right ? If I try to re-install it from the nmb file it says it is already there. Yet it is not in the list of installed plugins. All in all: I can no longer reproduce the issue and I can no longer get back to where I came from. (unless of course I re-install NB 7.2 from scratch) What log files would you be looking for from me? They are probably no longer relevant as I can no longer reproduce?
> The plugin doesn't appear in my list of installed plugins ! No, it does not appear in the list because individual nbm files are not displayed - there are about 500 of them so it would get very messy. Only the higher-level components are displayed, in this case "SOAP Web Services" (and you have to check the Show Details checkbox to see it). If you want to go back to the original version, just delete the modified installation of NetBeans and do a fresh install.
(In reply to comment #36) > @denis > > On NB 7.2. > > I've installed your plugin (latest version), restarted IDE and followed my own > steps for reproduction. When I add the web service I still run into bug 217892 > (when using Tomcat), but the Web Services node now appears ! > > Bottom line. With the plugin installed I can no longer reproduce the issue. > > So I think: Let's verify this. So I want to uninstall the plugin again in order > to reproduce the bug (again) without the plugin. However then something > strange: The plugin doesn't appear in my list of installed plugins ! I'm > supposedly looking for a plugin named "Maven JAX-WS", right ? If I try to > re-install it from the nmb file it says it is already there. Yet it is not in > the list of installed plugins. > > All in all: I can no longer reproduce the issue and I can no longer get back > to where I came from. (unless of course I re-install NB 7.2 from scratch) > > What log files would you be looking for from me? They are probably no longer > relevant as I can no longer reproduce? That's right. The log file is useless if you are not able to reproduce the issue. So I'm closing the issue as WORKSFORME because I've never been able to reproduce the issue as well.
I've just got an idea why you were able to see the issue. It could be a result of different Java versions (may be even different compiler versions): issue disappeared immediately after you applied nbm, which has been built on my box. Different (newer) JDK versions probably performs some byte code optimizations and that could be a reason of the issue. I have moved one call invocation to the different thread and it should prevents such optimization. Here is the probable fix : web-main#c87703724cb5 Please check the development version when fix will available in the build.
Integrated into 'main-golden', will be available in build *201209150001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/c87703724cb5 User: Denis Anisimov <ads@netbeans.org> Log: Probable fix for BZ#209555 - WebService is not recognized in Maven project
I've reimplemented fix for the issue to avoid any possible behavioral cases. Please verify web-main#2d5f6e7c3b7b
Integrated into 'main-golden', will be available in build *201209180001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/2d5f6e7c3b7b User: Denis Anisimov <ads@netbeans.org> Log: Reworking fix for BZ#209555 - WebService is not recognized in Maven project
Verified in dev build 201209180001.
I have been able to reproduce the issue based on steps from the issue #218819. I'm not sure is it JEE specific maven issue of common Maven project lookup issue. So feel free to reassign. Here is the clarification (see below[1] for the reason to avoid remote project ref) : - use https://github.com/hanasaki/demo/tree/master/jpaspringmvc. - checkout it and open in the NB. - expand the project's node and find the app-war module. - open the latter module as a project via "Open Project" popup menu action. As a result the opened project doesn't contain the Web Services node . This is a consequence of J2eeModuleProvider instance absence in the project's lookup. One may look at the class org.netbeans.modules.maven.jaxws.MavenJaxWsSupportProvider. There is a dedicated request processor, which waits for J2eeModuleProvider appearance in the lookup. The J2eeModuleProvider instance has to be present for any JEE project type: org-netbeans-modules-maven/war org-netbeans-modules-maven/ejb org-netbeans-modules-maven/ear org-netbeans-modules-maven/app-client MavenJaxWsLookupProvider instance (it's a LookupProvider) is also registered for any such project type. The latter instance instantiate MavenJaxWsSupportProvider and J2eeModuleProvider instance search. [1]Here is what happened: there is a main project jpaspringmvc. For some reasons it initiate J2eeModuleProvider instance search via MavenJaxWsSupportProvider and blocks the request processor's thread. I don't know why MavenJaxWsLookupProvider is instantiated for parent "jpaspringmvc" project which is not JEE project. And why there is no J2eeModuleProvider instance in the lookup if "jpaspringmvc" is recognized as JEE project for some reason.
So here are the localized steps to reproduce: - Create POM Maven project (a Maven pom-packaging project). As a result org.netbeans.modules.maven.jaxws.MavenJaxWsLookupProvider instance is used as LookupProvider for this project. MavenJaxWsLookupProvider have to be used as LookupProvider only for org-netbeans-modules-maven/war org-netbeans-modules-maven/ejb org-netbeans-modules-maven/ear org-netbeans-modules-maven/app-client maven project types.
Denis, have you tried debugging to see what invokes the MavenJaxwsLookupProvider.createAdditionalLookup() method? I cannot make the IDE to stop at the breakpoint there in the current codebase for pom or jar projects. But I do recall getting the log message "Wait in cycle for J2eeModuleProvider instance in Maven lookup" for non-j2ee projects as well. But please note that today I've committed to core-main a changeset that could influence the result (mine and yours) http://hg.netbeans.org/core-main/rev/3c77a3e17dd9
(In reply to comment #46) > Denis, have you tried debugging to see what invokes the > MavenJaxwsLookupProvider.createAdditionalLookup() method? I cannot make the IDE > to stop at the breakpoint there in the current codebase for pom or jar > projects. But I do recall getting the log message "Wait in cycle for > J2eeModuleProvider instance in Maven lookup" for non-j2ee projects as well. > > But please note that today I've committed to core-main a changeset that could > influence the result (mine and yours) > http://hg.netbeans.org/core-main/rev/3c77a3e17dd9 Yes, that's odd. I haven't been able to stop on breakpoint in the MavenJaxWsLookupProvider.createAdditionalLookup(). But mentioned log messages are exactly the matter of the issue. And there is the other way to stop on the breakpoint with catching the issue: put it inside nested MavenJaxWsSupportProvider CTOR before runnable has been posted. Then you will be able to go by stacktrace inside MavenJaxWsLookupProvider.createAdditionalLookup(). I will also change the way of lookup polling to avoid a thread lock. But still the main issue has to be fixed. I will check recent version of the sources with your commit.
Denis, I'm not sure why are you reassigning this one to me (the problem obviously lies in the maven.jaxws area). First thing that could help is that the MavenJaxWsLookupProvider should be completely removed and @PSP annotation should be rather used for project lookup registration (I have done that in maven.j2ee and it fixed a lot of similar lookup issues in that area.. and it's a preferred way anyway) Also in MavenJaxWsSupportProvider constructor you shouldn't rely on the presence of the J2eeModuleProvider in lookup results (you cannot be sure whether it's already there or not - obviously you've seen some troubles with that according to the never-ending cycle trying to find J2eeModuleProvider from the project lookup).. you should rather do that in lazy way (which means call "lookup.lookup(J2eeModuleProvider.class)" when you really need the result - not in MavenJaxWsSupportProvider constructor (maybe in reactOnPomChanges() method)
(In reply to comment #48) > Denis, I'm not sure why are you reassigning this one to me (the problem > obviously lies in the maven.jaxws area). No it doesn't. You can easily read all text in the comments and find out the exact problem : non JEE project "POM Maven project (a Maven pom-packaging project)" register in its lookup the result of the MavenJaxWsLookupProvider.createAdditionalLookup() call. But it hasn't to do this. Because MavenJaxWsLookupProvider has no required annotations for this. This is definitely the issue. I don't know where the issue is exactly : JEE maven support or it's generic Poroject lookup issue as I've already mentioned. So feel free to reassign. > First thing that could help is that the MavenJaxWsLookupProvider should be > completely removed and @PSP annotation should be rather used for project lookup > registration (I have done that in maven.j2ee and it fixed a lot of similar > lookup issues in that area.. and it's a preferred way anyway) That's the option but it doesn't mean that behavior described above is allowed. > > Also in MavenJaxWsSupportProvider constructor you shouldn't rely on the > presence of the J2eeModuleProvider in lookup results (you cannot be sure > whether it's already there or not - obviously you've seen some troubles with > that according to the never-ending cycle trying to find J2eeModuleProvider from > the project lookup).. you should rather do that in lazy way (which means call > "lookup.lookup(J2eeModuleProvider.class)" when you really need the result - not > in MavenJaxWsSupportProvider constructor (maybe in reactOnPomChanges() method) J2eeModuleProvider is required to get WebservicesMetadata model to attach listener for it. It has to be done on the project initialization. Does reactOnPomChanges() method allows to do it ? If you know what has to be done to avoid the problems with J2eeModuleProvider lookup then could you please rewrite the code respectively as a Maven expert ?
Correction in maven.jaxws to avoid thread freeze : web-main#7a95747f3fd4
(In reply to comment #47) > (In reply to comment #46) > > Denis, have you tried debugging to see what invokes the > > MavenJaxwsLookupProvider.createAdditionalLookup() method? I cannot make the IDE > > to stop at the breakpoint there in the current codebase for pom or jar > > projects. But I do recall getting the log message "Wait in cycle for > > J2eeModuleProvider instance in Maven lookup" for non-j2ee projects as well. > > > > But please note that today I've committed to core-main a changeset that could > > influence the result (mine and yours) > > http://hg.netbeans.org/core-main/rev/3c77a3e17dd9 > By the way 3c77a3e17dd9 doesn't correct the behavior. MavenJaxWsLookupProvider.createAdditionalLookup() is still used for "POM Maven project".
(In reply to comment #51) > (In reply to comment #47) > > (In reply to comment #46) > > > Denis, have you tried debugging to see what invokes the > > > MavenJaxwsLookupProvider.createAdditionalLookup() method? I cannot make the IDE > > > to stop at the breakpoint there in the current codebase for pom or jar > > > projects. But I do recall getting the log message "Wait in cycle for > > > J2eeModuleProvider instance in Maven lookup" for non-j2ee projects as well. > > > > > > But please note that today I've committed to core-main a changeset that could > > > influence the result (mine and yours) > > > http://hg.netbeans.org/core-main/rev/3c77a3e17dd9 > > > By the way 3c77a3e17dd9 doesn't correct the behavior. > MavenJaxWsLookupProvider.createAdditionalLookup() is still used for > "POM Maven project". do you have the stacktrace which calls the method? please attach it. have you tried on a clean build of the ide?
To avoid mixing various functionalities I've created the issue #219108 for maven project. This issue is strongly related to the issue #219108 but it's currently fixed via my commit web-main#7a95747f3fd4.
> > First thing that could help is that the MavenJaxWsLookupProvider should be > > completely removed and @PSP annotation should be rather used for project lookup > > registration (I have done that in maven.j2ee and it fixed a lot of similar > > lookup issues in that area.. and it's a preferred way anyway) > That's the option but it doesn't mean that behavior described above is > allowed. That's true, but it will most probably solve the problem without much work. It's just a guess but based on your description it looks like the lookup registrators are wrongly merged for a different project types. Which is why I think @PSP could be a solution in this case. Could you please do this one? If it won't help we can take look at it again ..
> J2eeModuleProvider is required to get WebservicesMetadata model to attach > listener for it. It has to be done on the project initialization. Does > reactOnPomChanges() method allows to do it ? > If you know what has to be done to avoid the problems with J2eeModuleProvider > lookup then could you please rewrite the code respectively as a Maven expert ? I would love to, but I don't think I can. I can just guess what might help from the general point of view, but without deep knowledge of the maven.jaxws code I can't rewrite it safely ..as I said.. using @PSP annotation could solve the problem without much effort
(In reply to comment #54) > > That's true, but it will most probably solve the problem without much work. I don't think so. > It's just a guess but based on your description it looks like the lookup > registrators are wrongly merged for a different project types. Which is why I > think @PSP could be a solution in this case. It will allow to avoid the problem in the issue #219108. But I don't see a bulletproof way to avoid other possible problems. > Could you please do this one? If > it won't help we can take look at it again .. No I'm not sure that there is a way to avoid any kind of problems. So let me clarify : 1) Please take a look at the MavenJaxWsLookupProvider.createAdditionalLookup() There is a number of instances created which used to build final project's lookup. 2) jaxWsSupport and is required for constructing MavenJaxWsServicesProvider ( and J2eeModuleProvider is required for MavenJaxWsSupportProvider ). 3) It is possible to get it via lookup JAXWSLightSupportProvider which is exactly instantiated for this purpose. 4) But there is an issue which introduces J2eeModuleProvider lookup search behavior: some work is required to be done in the classes CTOR. So one is unable to expect presence of required classes in the project's lookup. That's exactly the situation with J2eeModuleProvider. It means that neither MavenJaxWsServicesProvider nor MavenJaxWsSupportProvider shouldn't expect fully initialized lookup in their CTORs. So there is no straight way to rewrite code avoiding LookupProvider usage. Probably it is possible to move out usage of J2eeModuleProvider and JAXWSLightSupportProvider from CTORs. And ask for them in a lazy way as you've suggested. But I don't know how. This is Maven details which I don't know. So the question is : is there any way to attach some listener for getting notification about project is loaded ( lookup is fully initialized ) so that project.getLookup().lookup(SomeClass.class) doesn't return null for SomeClass isntance registered for this project type ? It seems reactOnPomChanges() is not a good solution for requested notification.
> > It's just a guess but based on your description it looks like the lookup > > registrators are wrongly merged for a different project types. Which is why I > > think @PSP could be a solution in this case. > It will allow to avoid the problem in the issue #219108. > But I don't see a bulletproof way to avoid other possible problems. Agree, but still better than nothing ;] > > Could you please do this one? If > > it won't help we can take look at it again .. > No I'm not sure that there is a way to avoid any kind of problems. > > So let me clarify : > 1) Please take a look at the MavenJaxWsLookupProvider.createAdditionalLookup() > There is a number of instances created which used to build final project's > lookup. Sure, that shouldn't be a problem. > 2) jaxWsSupport and is required for constructing MavenJaxWsServicesProvider > ( and J2eeModuleProvider is required for MavenJaxWsSupportProvider ). The question is: is it really needed to lookup J2eeModuleProvider in constructor? From the code it looks like it's used only for finding server instance. And that server instance doesn't seem to be needed in time of object creation (or am I misreading the code?).. similar JAXWSLightSupport is passed through the constructor parameter (I can see two usages: MavenJaxWsSupportProvider and MavenJaxWsServicesProvider), but it's used only for field initialization. And you can definitely initialize it later on (e.g. accessing through private method and if the field wasn't initialized yet, find it through the project lookup - and in that time lookup should be fully loaded) > 3) It is possible to get it via lookup JAXWSLightSupportProvider which > is exactly instantiated for this purpose. > 4) But there is an issue which introduces J2eeModuleProvider lookup search > behavior: > some work is required to be done in the classes CTOR. > So one is unable to expect presence of required classes in the project's > lookup. > That's exactly the situation with J2eeModuleProvider. > > It means that neither MavenJaxWsServicesProvider nor MavenJaxWsSupportProvider > shouldn't expect fully initialized lookup in their CTORs. > So there is no straight way to rewrite code avoiding LookupProvider usage. > > Probably it is possible to move out usage of J2eeModuleProvider and > JAXWSLightSupportProvider from CTORs. And ask for them in a lazy way as you've > suggested. But I don't know how. This is Maven details which I don't know. Note above might explain it. Still don't know where do you see the connection to Maven :] > So the question is : is there any way to attach some listener for getting > notification about project is loaded ( lookup is fully initialized ) so that > project.getLookup().lookup(SomeClass.class) doesn't return null for > SomeClass isntance registered for this project type ? Don't know to be honest. AFAIK you can be sure after the type creation (meaning after constructor initialization). Which is why I'm suggesting lazy loading. > It seems reactOnPomChanges() is not a good solution for requested notification.
> So the question is : is there any way to attach some listener for getting > notification about project is loaded ( lookup is fully initialized ) so that > project.getLookup().lookup(SomeClass.class) doesn't return null for > SomeClass isntance registered for this project type ? BTW: Can't you just add a new lookup listener: "result.addLookupListener(listener);" and there check whether the J2eeModuleProvider instance is already in result and if it is do the rest of needed initialization? What is the benefit of all the weird code with endless while cycle? (MavenJaxWsSupportProvider: 121-156)
(In reply to comment #57) > is it really needed to lookup J2eeModuleProvider in constructor? As a rule a service should do nothing in its constructor beyond assigning final variables to parameters it was passed. All else should be computed on demand.
(In reply to comment #59) > (In reply to comment #57) > > is it really needed to lookup J2eeModuleProvider in constructor? > > As a rule a service should do nothing in its constructor beyond assigning final > variables to parameters it was passed. All else should be computed on demand. Which is exactly what I was saying in comment 48. Thanks Jesse
If the fix is final, please put the fix into patch branch. I verified in build 201210040002 with the following steps: - download and expand https://github.com/hanasaki/demo/zipball/master - open depend and jpaspringmvc projects in NetBeans - build with dependencies both projects - expand Modules in jpaspringmvc, right-click module-app-war and choose Open - project is opened, recognized as web project and Web Services node with one web service is present
releases#1ef15ead4e3a
releases#0308adad7a71
Integrated into 'releases', will be available in build *201210100934* or newer. Wait for official and publicly available build. Changeset: http://hg.netbeans.org/releases/rev/1ef15ead4e3a User: Denis Anisimov <ads@netbeans.org> Log: Port fix for BZ#209555 into release72 branch.