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.

Bug 194884 - IDE quits incrementally deploying EAR when running or debugging and seemingly can only get it back occasionally
Summary: IDE quits incrementally deploying EAR when running or debugging and seemingly...
Status: RESOLVED WORKSFORME
Alias: None
Product: serverplugins
Classification: Unclassified
Component: GlassFish (show other bugs)
Version: 6.x
Hardware: PC Windows XP
: P3 normal (vote)
Assignee: Vince Kraemer
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-01-30 19:48 UTC by _ wadechandler
Modified: 2011-11-10 20:20 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

Attachments
My log file with this issue (132.11 KB, text/x-log)
2011-01-30 19:50 UTC, _ wadechandler 		Details
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description _ wadechandler 2011-01-30 19:48:21 UTC 
In my log file I see:
...
INFO [org.netbeans.modules.j2ee.deployment.impl.TargetServer]: Cannot incrementally deploy to more than one target
WARNING [glassfish-eecommon]: Deployment plan not supported in GlassfishConfiguration.save()
WARNING [glassfish-eecommon]: Deployment plan not supported in GlassfishConfiguration.save()
...
Dotted name path applications.application.*.context-root not found.%%%EOL%%%

This is after I have been editing some files and hit save. If I have the IDE log opened in "Output" I can see this get printed after every save once this state is in place. Too, restarting, restarting the computer, glassfish, etc doesn't make this go away. At this point, once this started happening to me, I only have see it successfully incrementally redeploy once.

Anyways, this has just killed my productivity. I'm usnig GlassFish 3.0.1. NB & JDK Info is:

  Product Version         = NetBeans IDE 6.9 (Build 201011082200) (#cb6bcdf0c6ce)
  Operating System        = Windows XP version 5.1 running on x86
  Java; VM; Vendor        = 1.6.0_20; Java HotSpot(TM) Client VM 16.3-b01; Sun Microsystems Inc.
  Runtime                 = Java(TM) SE Runtime Environment 1.6.0_20-b02
  Java Home               = C:\java\jdk1.6.0_20\jre

I can attach my current log as an attachment if it will help.

A different bug had this message in the log file which was attached to it, but that issue seems to not be about this, so it seems nobody noticed this error in the person log. The issue was marked as a duplicate of another one though, and might have been part of not seeing that in the log:
http://netbeans.org/bugzilla/show_bug.cgi?id=184247

has the attached log which has this same issue if you look for "Dotted name path applications.application.*.context-root not found."

It was marked as a duplicate of:
http://netbeans.org/bugzilla/show_bug.cgi?id=183595

Not sure if there is anything related in these or not, but was something I found during a Google search. My issue certainly isn't fixed in 6.9.1 with latest updates.
Comment 1 _ wadechandler 2011-01-30 19:50:07 UTC 
Created attachment 105499 [details]
My log file with this issue
Comment 2 _ wadechandler 2011-01-31 15:39:37 UTC 
More on this issue. Perhaps not helpful, but last night it started working again. The only thing I can think of which I did was noticed that editing and saving web.xml, even if I just put a space in it, and saving it would cause the IDE to successfully redeploy. I first found out when I re-enabled an error page. I then thought...hmmm it is fixed, so I changed a JSP, and it didn't redeploy incrementally. So, I put a space in web.xml and saved. It redeployed. I did that a few times, I then edited a css and jsp file, and it redeployed, and it seemed to work all last night until I quit working on that project. 

I will be working on it more later today, and will report back whether it continues to work. Next I'll report back on whether restarting the IDE, computer, etc causes it to stop working again or not. Seems it may some how be related to the cache, but not sure yet.

Off topic note: This and some other issues has me thinking I need to start using my own builds, even of the releases, so I can help debug these things as someone using the different project types and often running into issues I think will be hard for NB employees to run into unless they are doing the same: web, EAR, EJB-JAR, Spring, MyBatis (xml files with different content), RCP (custom), class libraries, etc. I may go ahead and get the latest 6.9.1 sources and see if I can't go ahead and get this going using my same cache etc.
Comment 3 David Konecny 2011-01-31 21:59:08 UTC 
Passing to GlassFish plugin for evaluation.
Comment 4 Vince Kraemer 2011-02-24 17:52:31 UTC 
(In reply to comment #2)
> More on this issue. Perhaps not helpful, but last night it started working
> again. The only thing I can think of which I did was noticed that editing and
> saving web.xml, even if I just put a space in it, and saving it would cause the
> IDE to successfully redeploy. I first found out when I re-enabled an error
> page. I then thought...hmmm it is fixed, so I changed a JSP, and it didn't
> redeploy incrementally. 

which is the correct behavior in that situation....  A jsp change should not trigger a redeploy.

> So, I put a space in web.xml and saved. It redeployed.
> I did that a few times, I then edited a css and jsp file, and it redeployed,
> and it seemed to work all last night until I quit working on that project. 

The change in the css file probaby triggered the redeploy.  I can tweek some of the code that decides whether a change should trigger a redeploy to prevent the additional redeploy...

> 
> I will be working on it more later today, and will report back whether it
> continues to work. Next I'll report back on whether restarting the IDE,
> computer, etc causes it to stop working again or not. Seems it may some how be
> related to the cache, but not sure yet.
> 
> Off topic note: This and some other issues has me thinking I need to start
> using my own builds, even of the releases, so I can help debug these things as
> someone using the different project types and often running into issues I think
> will be hard for NB employees to run into unless they are doing the same: web,
> EAR, EJB-JAR, Spring, MyBatis (xml files with different content), RCP (custom),
> class libraries, etc. I may go ahead and get the latest 6.9.1 sources and see
> if I can't go ahead and get this going using my same cache etc.
Comment 5 _ wadechandler 2011-02-24 19:24:44 UTC 
>which is the correct behavior in that situation....  A jsp change should not
>trigger a redeploy.

Hmmm. It is the case that every time I change a JSP or any other file that an "incremental" redeploy takes place it seems. I don't think incremental redeploy is just a notion of GF right? Incrementally copying pieces from source to build. Seems what ever copies the source files to the running web directory isn't taking place. That must take place after a JSP or CSS is saved certainly or else it won't be in the folder the application is running. Either way the terminology is used here, that copy operation seems to be the problem. It isn't taking place.

>> So, I put a space in web.xml and saved. It redeployed.
>> I did that a few times, I then edited a css and jsp file, and it redeployed,
>> and it seemed to work all last night until I quit working on that project. 
>
>The change in the css file probaby triggered the redeploy.  I can tweek some of
>the code that decides whether a change should trigger a redeploy to prevent the
>additional redeploy...

Well, the issue is really that whenever that redeploy takes place things get copied from the source folders to the built folder. Whether it should redeploy or what ever it is doing seems separate, but of course I lob them together since I noticed that if the IDE doesn't say "redeploying" in the status area for running tasks the changed CSS or JSP will not be in the running/debugged application.
Comment 6 Vince Kraemer 2011-11-10 20:20:28 UTC 
I cannot reproduce this in a 7.1/gf 3.1.1 environment.

Please reopen with more info if you still see this issue in an updated environment.