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.
I don't know exactly what mecanisms are involved in this, but on my imported maven 2 project (a J2EE1.4 compliant war), netbeans believe that it's a J2EE 6 webapp. I suppose this is because it doesnt look at the right place for the web.xml. This is because i use maven war overlay to create my project war. So the web.xml comes from a parent war, and netbeans doesn't look for ressources in parent. Netbean try to be clever, sometimes locking functionnality that it believes user should not use. One example is deploying a j2EE 1.6 webapp to a J2EE 1.4 container. Instead of warning user that it might fail, they juste refuse the deployement. One other is that is guesses J2EE version but does not let user tell exactly what version it want to conforms to. As a result of problem above, i am blocked, netbeans refuses to start a server and deploy app on it, making it just useless to run & debug the webapp. As a result 1) netbean could be fixed to detect properly J2EE version from maven projects 2) in any case, netbean should allow user to manually specify version (some complex project might involve custom maven plugins to create war, which mean you can never be sure netbeans guess is always correct) 3) netbean should not disallow user to deploy on server of it's choice, even if it doesn't support J2EE version netbean thinks application is (i use an IDE to do work, not to be disallowed to do work)
Can you provide source code of your project so I'll be able to reproduce the issue and fix detection problem? Anyway I'm catching your point about platform version. What do you think about that David? Shouldn't we provide at least some way to declare J2EE version manually or allows user to "try to deploy" his application to specified server even if seems that the server doesn't support it ? (I'm not sure how complicated is to change J2EE version on demand, but it seems reasonable to me)
If NetBeans supported "overlays" then we would not have this issue. I would prefer to fix the cause instead of adding workarounds. (In reply to comment #0) > Netbean try to be clever, sometimes locking functionnality that it believes > user should not use. One example is deploying a j2EE 1.6 webapp to a J2EE 1.4 > container. Instead of warning user that it might fail, they juste refuse the > deployement. If we did not lock some functionality based on what is known about project the IDE would not be very useful. The IDE would be a "thick" one - asking questions which it should know answers for. > One other is that is guesses J2EE version but does not let user > tell exactly what version it want to conforms to. This make sense to allow. But first I would prefer to fix overlays and then re-evaluate whether there is still a need for this customization or not. *** This bug has been marked as a duplicate of bug 200776 ***
Btw. delbd, could you please share why have you setup your projects to use Maven overlays? It is always good to hear real usecase. Thanks!
I also face the same problem on Netbeans 7.0.1. In our case, we do not use overlays, but we put our web.xml file in another directory. We see the exact same behavior : Netbeans seems to consider our Maven module as a Java EE 6 webapp, and thus refuse to deploy it on Tomcat 6 (because it does not fully comply with Java EE 6). It took a very long time for us to diagnose that... The reason why we put web.xml in another directory is that we have 2 different versions of this file. Our Maven build takes the one that matches the Maven profile, and put it in the war (by defining webResources in the maven-war-plugin). The only workaround we found is to put a dummy web.xml in webapp/WEB-INF (and also a dumy webapp/META-INF/context.xml) : these files are overwritten on a Maven build and their only purpose is to tell Netbeans that we have a Java EE 5 webapp. This way, Tomcat re-appears in the drop-down list and we can deploy on it. I saw that this bug has been marked as a duplicate of 200776 : I slightly disagree. There apparently can be many reasons why Netbeans would not detect correctly the Java EE version. I think that Netbeans should at least give a more meaningful message when it cannot detect the Java EE version. If you do not want to let the user override this detection, the fact that a server is not Java EE 6 compliant should be a warning, and should not prevent you (silently) to deploy on it.
David : sorry, I did not read the end of your comment #2 when you marked this bug as duplicate, and I did not see that this update was just a few hours ago. I understand that you first want to improve automatic detection before letting the user override it. So just consider my comment as a "vote" to let the user deploy, even if Netbeans did not detect the webapp as compatible.
(In reply to comment #4) > The reason why we put web.xml in another directory is that we have 2 different > versions of this file. Our Maven build takes the one that matches the Maven > profile, and put it in the war (by defining webResources in the > maven-war-plugin). Just out of curiosity: how those two web.xml differs? I would like to understand the real usecase or problem you are solving here. > The only workaround we found is to put a dummy web.xml in webapp/WEB-INF (and > also a dumy webapp/META-INF/context.xml) : these files are overwritten on a > Maven build and their only purpose is to tell Netbeans that we have a Java EE 5 > webapp. > This way, Tomcat re-appears in the drop-down list and we can deploy on it. The problem is that even if NB allowed you to set EE level that would not be complete solution for your usecase. web.xml is essential for lots of other IDE functionality. Short term workaround I would suggest is to use one of your real web.xml files instead of a dummy one. That way you do not have any issue and in other profile you simply override that web.xml with your other one.
(In reply to comment #6) > Just out of curiosity: how those two web.xml differs? I would like to > understand the real usecase or problem you are solving here. We have one for development, and another one for testing/production. These 2 environments are slightly different, which result in slightly different web.xml files. Production needs some additional XA datasources, and development needs some additional spring XML context files (in the init-param of the DispatcherServlet declared in web.xml) > The problem is that even if NB allowed you to set EE level that would not be > complete solution for your usecase. web.xml is essential for lots of other IDE > functionality. Short term workaround I would suggest is to use one of your real > web.xml files instead of a dummy one. That way you do not have any issue and in > other profile you simply override that web.xml with your other one. You're probably right. That should be a better way to handle it for now. Thanks for the hint
Ok, so do we need to do something for 7.1? Support for war:overlay is still valid and opened enhancement (issue 200776). And if we don't want to allow user to set J2EE version manually, this one can be closed, or?
mjanicek, if you don't want to let the user override the Java EE version, the following enhancements should be implemented to solve this issue (in my point of view) : - display a warning somewhere when Netbeans fails to recognize the Java EE version (for instance because there is no web.xml file in expected location) - do not remove an application server from the dropdown list if it does not comply to the detected Java EE version. Instead, display a warning if the user chooses it and let it deploy on it if he wants to
(In reply to comment #9) > mjanicek, > > if you don't want to let the user override the Java EE version, the following > enhancements should be implemented to solve this issue (in my point of view) : > - display a warning somewhere when Netbeans fails to recognize the Java EE > version (for instance because there is no web.xml file in expected location) This is unfortunately not that easy to detect. For example missing web.xml is perfectly OK in EE 6 where web.xml is optional. > - do not remove an application server from the dropdown list if it does not > comply to the detected Java EE version. Instead, display a warning if the user > chooses it and let it deploy on it if he wants to This sounds reasonable and would help in your case. But I afraid such fix can also have negative impact - a different user may complain that IDE shows them all servers including ones which are not relevant for his project execution and such user may argue that if we know that server is not appropriate (ie. because we show warning about it) then why we offer it to user anyway? If I know that we would make more people happy by allowing what you are requesting than I would go for it. But right now it looks like majority of users who does not use overlays (or custom handling of different versions of web.xml) would be negatively impacted by this change. I would suggest to leave this issue open for next version and try to fix overlay support in the meantime.
There are still two things to do: 1] Implement support for war:overlay (issue 200776) 2] Enable to set Java EE version (issue 208607 contains much transparent description --> marking this one as duplicate) *** This bug has been marked as a duplicate of bug 208607 ***