Please use the Apache issue tracking system for new NetBeans issues ( !!
Bug 199478 - Netbeans regenerates glassfish-web.xml every deploy
Netbeans regenerates glassfish-web.xml every deploy
Product: javaee
Classification: Unclassified
Component: Maven
PC Linux
: P2 (vote)
: 7.0.1
Assigned To: David Konecny
: 199255 200709 (view as bug list)
Depends on:
  Show dependency treegraph
Reported: 2011-06-16 21:46 UTC by kingsob
Modified: 2011-08-24 07:42 UTC (History)
6 users (show)

See Also:
Issue Type: DEFECT


Note You need to log in before you can comment on or make changes to this bug.
Description kingsob 2011-06-16 21:46:47 UTC
if you create a new maven web app 

File -> New Project -> Maven -> Web Application

now run the application, it will ask you if you which server to use, so I select my Glassfish 3.1 server

if you look in the project, netbeans has generated a new glassfish-web.xml.. so I change the the context-root to <context-root>/</context-root>.. clean and deploy.. and its back to the default context-root
Comment 1 kingsob 2011-06-16 21:47:53 UTC
oh and I am using

Product Version: NetBeans IDE Dev (Build 201106120600)

due to the deploy on save bug for EAR maven applications in 7.0
Comment 2 David Konecny 2011-06-16 22:34:39 UTC
Vince, could you please have a look. Sounds very suspicious. It is second report in last few days. Perhaps something to fix in 7.0.1?
Comment 3 David Konecny 2011-06-16 22:39:17 UTC
*** Bug 199255 has been marked as a duplicate of this bug. ***
Comment 4 Vince Kraemer 2011-06-16 23:35:31 UTC
I can duplicate the behavior.

It looks like the Clean is thing that is overwriting the context-root element.

Here are some steps that I used to verify the situation.

1. create a maven web app.

2. assign the app to run on a gf 3.1 server

   a glassfish-web.xml file is created, since the CR /maveprojectX-1.0-SNAPSHOT does not match the defaultcr that the GF plugin expected for the project /mavenprojectX.  I opened issue 199482 to track this.

3. Edit the Context Path property of the project.
    the value of context-root in the glassfish-web.xml file is updated.

4. edit the value of the context-root element in glassfish-web.xml
   the property value for Context Path changes, as expected.

5. Clean the project.
     the value of context-root reverts to the value that was set when the user did step 3... That is a bit unexpected.

At this point, the plugin is 'doing what is told to do' by the Maven project code.
Comment 5 David Konecny 2011-06-17 01:15:26 UTC
Interesting, for a while I was not able to reproduce it and now it is happening all the time. I'm investigating.
Comment 6 David Konecny 2011-06-17 02:39:34 UTC
Short term workaround is to permanently associate server with project. In such case this should work fine.

I fixed some parts of code which were incorrect but I'm experiencing different issues now so I will have to test this more early next week.
Comment 7 David Konecny 2011-06-30 03:10:07 UTC
This issue has workaround so it is not a show stopper. I have not found fix yet.
Comment 8 kawazu428 2011-07-27 07:55:16 UTC
Interestingly enough, this still does happen in recent builds even with having the project permanently associated with a given local Java EE server (Glassfish). Adding to that, however: Initially, in the project there is a "sun-web.xml" (Java EE 5 project, reproducible with both the .war artifacts in in example), which gets "regenerated" / refreshed / emptied every time I run the application. Tried to rename the file to "glassfish-web.xml", I saw the file itself remains untouched but an empty "sun-web.xml" is generated which seems to contain no meaningful information. Hard to see which of these, in the end, is about to be used by the server. ;)
Comment 9 kawazu428 2011-07-28 12:11:33 UTC
And another insight I just used to have: Had glassfish-web.xml and pom.xml open in a newly created (next to empty) project:

Did set the desired context root in glassfish-web.xml. Saved. Fine. Edited pom.xml. Saved pom.xml. Saw "something happening" in the glassfish-web.xml editor. Switched there, to see the context root reset to /<artifactId>-<artifactVersion>. Funnily enough, I was editing the <buiLd><finalName> property in pom.xml. Not sure whether this is the same problem, just happened to fall into my current struggle of working around this issue.

Product Version: NetBeans IDE Dev (Build 201107250600)
Java: 1.6.0_25; Java HotSpot(TM) Client VM 20.0-b11
System: Linux version 2.6.38-10-generic running on i386; UTF-8; de_DE (nb)
Userdir: /home/kr/.netbeans/7.0m2
Comment 10 David Konecny 2011-08-03 22:01:45 UTC
Thanks for all the info kawazu428. That does sound like pain. There is something really rotten and I need to find enough time to dive into that and finally solve it. I wrote a BIG note to myself to look into this issue sometimes next week.
Comment 11 David Konecny 2011-08-07 21:49:10 UTC
*** Bug 200709 has been marked as a duplicate of this bug. ***
Comment 12 David Konecny 2011-08-10 00:09:59 UTC
I think I finally got it right: 3b18c64ffab0
I did thorough testing but I would appreciate if somebody could download a dev build with this fix (will be available in a day or two) and verify it. Thanks!
Comment 13 Jiri Skrivanek 2011-08-18 13:29:21 UTC
Verified in build 201108170601.
Comment 14 David Konecny 2011-08-19 01:54:46 UTC
integrated into releases repo: db9a1e9fb701, 9c70f18fe87d

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo