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.
First I checked what to expect from GlassFish 3.1 Console|Domain|Applications Configuration Enable reloading so that changes to deployed applications are detected and the modified classes reloaded. Reload Poll Interval: 2 seconds Here is what I did to reproduce the problem: Load project from http://netbeans.org/bugzilla/show_bug.cgi?id=181173 zip file http://netbeans.org/bugzilla/attachment.cgi?id=94576 unzip and open project. - Application compile on save on, deploy on save off - Server Preserve sessions across deployments on - Start server in debug mode - Clean and build application - Deploy application Locate class file MySignInPage.class and take note of modification date Open/Edit MySignInPage.java Make a change and save public MySignInPage() { System.out.println("Hello"); } Locate class file MySignInPage.class and take note of modification date Expected results: a) modification date should change b) GlassFish should detect change and re-deploy class within 2 seconds Actual Result: Modification date is not changed because the class was not recompiled. I am suggesting to continue with classfile modification outside NetBeans for further clarification.
I try to view the corresponding page and see what happens if I compile the file manually. Wicket Menu|authentication|Admin Page Viewing this page displays the text in the GlassFish log. GlassFish does not detect the changes even if the file is compiled manually via single file compile. I would expect the single class file to be re-loaded. Is that not posssible?
You may want to read the docs about Dynamic application reloading... http://download.oracle.com/docs/cd/E18930_01/html/821-2417/gilfm.html#fwakh Assigning to Petr H to look into the class-file timestamp aspect of this issue.
Created attachment 107279 [details] the patch I think this is relict of Dos to CoS+DoS split where build scripts haven't been updated. Attaching patch and passing to David. Not sure if this is P2 - bht will it fix the original use case or there is other issue with GF.
I just found this while checking the file attributes. It will not fix the original use case, so not really P2 because of that. I don't think there is another issue with GF due to this from my current perspective.
Ok, then. Decreasing to P3.
PetrH, thanks for the patch. I'm looking at it and it seems to do the trick but it does not seem very logical: for example in web.project - why 'deploy.on.save' should be set even if only 'j2ee.compile.on.save' is set to true? Which code is actually using 'deploy.on.save'? I could not find any reference to it in build-impl.xml. I think I'm missing something. :-)
(In reply to comment #6) > PetrH, thanks for the patch. I'm looking at it and it seems to do the trick but > it does not seem very logical: for example in web.project - why > 'deploy.on.save' should be set even if only 'j2ee.compile.on.save' is set to > true? Which code is actually using 'deploy.on.save'? I could not find any > reference to it in build-impl.xml. I think I'm missing something. :-) IIRC it is used by javac redefined by jlahoda so it really put the classes to build dir. J2SE does not need it as the classes remain in cache and only the run classpath is modified. Our EE apps however need predefined structure, ie. WEB-INF/classes. The name is result of the original design - DoS or nothing.
Thanks for the clarification Petr. 353d7768039e
*** Bug 197106 has been marked as a duplicate of this bug. ***
I forgot to close this yesterday. Petr's patch was applied.
Integrated into 'main-golden', will be available in build *201104070400* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/353d7768039e User: David Konecny <dkonecny@netbeans.org> Log: #197067 - Compile on Save broken in J2EE App