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.
Created attachment 107424 [details] test case An ear project with following structure: EAR EJB using entities.jar WAR is redeployed multiple times when "debug" or "run" button is hit and ejb modules are using an entity jar (just a jar with a persistence.xml seems to be enough). Using Netbeans 7 RC1. When adding this line in persistence.xml, the ear is redeployed one more time <property name="eclipselink.target-server" value="SunAS9"/> (ok, this line isn't necessary, but it could give some clue?) When adding an ejb module which depends on the entity jar, the ear is also redeployed once more. I included a test case : just running it on a Glassfish 3.1 server seems to redeploy multiple times. You can check Glassfish log to be sure: INFO: WEB0671: Loading application [EnterpriseApplication1#EnterpriseApplication1-war.war] at [EnterpriseApplication1-war] INFO: EnterpriseApplication1 was successfully deployed in 157 milliseconds. INFO: WEB0671: Loading application [EnterpriseApplication1#EnterpriseApplication1-war.war] at [EnterpriseApplication1-war] INFO: EnterpriseApplication1 was successfully deployed in 172 milliseconds.
I thought of packaging the entity lib manually in ear, but this workaround doesn't work because of 197321
I had difficulties reproducing it - I saw it happened once but in all other cases it WEB0671 was in the log just once. Passing to server plugin for evaluation. Originator, does it create any harm or is only performance issue? Did you try to deploy EAR file directly via GlassFish admin console?
The steps to reproduce the issue are a bit unclear. It looks like deploy on save is behaving correctly... You changed the app and the ear gets redeployed. Can you provide more detailed, step-by-step instructions to reproduce the issue... If the instructions are in a form like, "I did X. I saw Y happen and did/didn't expect it", it will be even easier to reproduce, since we will be able to 'see' the situation from your perspective. Please attach the glassfish log FILE that shows more details... (not the content of the viewer window, since that does not include things like the timestamps, etc)
I just run attached project from Netbeans. Netbeans seems to deploy it multiple times, as you can see from log extract. I could reproduce it on another machine.
I cannot reproduce it. If you have a stopped GlassFish server with previously deployed EnterpriseApplication1, you can see the message twice on the first start but every next run it appears only once. Product Version: NetBeans IDE 7.0 RC2 (Build 201103310000) Java: 1.6.0_24; Java HotSpot(TM) Client VM 19.1-b02 System: Windows XP version 5.1 running on x86; Cp1250; cs_CZ (nb)
It definitively reproduces here. Hitting the 'run' button just redeploys multiple times. I even timed the different deployment times under different contexts (not with the test case, but with a similar application, and the test case reproduces this). I can make it deploy 5 times (while only pressing the run button once), by just adding modules with a dependency on the entity jar. Here are my notes: Setup: EAR with EJB1/WAR/EJB2, both EJB jars depending on same entity jar A. deploy on save enabled on EAR/EJB1/WAR but *not* EJB2 --> 3 deployments with those timings: 19.062/12.999/12.109 B. deploy on save enabled on EAR/EJB1 but *not* WAR/EJB2 --> 3 deployments with those timings: 17.999/13.437/12.734 ... I tried a couple of different configurations, it only succeeded when I disabled deploy on save on EAR --> 1 deployment in 17.984 s I'll run it on my laptop, which has a quite different setup, just to be sure. Did you try to run the attached test case from Netbeans? I didn't try, but I'm quite sure it works fine from Glassfish CLI or console, as we have a big EAR app with the modules I tried + about 20 others and it deploys correctly from CLI, only once.
I think I found an additional condition for the bug to come up. It needs to have a class with wrong package name in entity jar. There is an hint in red in netbeans while editing the class, but it still compiles ok... But it redeploys multiple times.
Created attachment 107483 [details] better test case Attached a better test case- I think this one will let you reproduce the problem 100% of the time.
it looks like the TM value got set by somebody. Since there isn't an evaluation of this issue yet, I reset it to be TBD. I still do not see step-by-step instructions on how to reproduce the problem... These step-by-step instructions and notes about what you have observed are CRITICAL to have someone else reproduce and resolve this issue. It currently looks like you did the following... created an EAR project with some dependencies. used the run item on the ear file to deploy the ear it deploys. you saw some change that you needed to make in one of the dependent projects You made the change in the dependent project and saved that change. the ear deploys again... even though you did not use the Run item on the ear project If that is the sequence of events... then deploy on save is functioning correctly...
> I still do not see step-by-step instructions on how to reproduce the problem... I thought it was clear, I'll try to restate it starting from your explanation: created an EAR project with some dependencies. used the run item on the ear file to deploy the ear it deploys. ---> multiple times, right away, without changing anything to the project That's the description of the problem, it's in the title: my ear deploys multiple times when I hit 'run'. I created a test case. Did you try the last version? If you take this project and hit the 'run' button, it will deploy multiple times. The rest *isn't* what's happening > you saw some change that you needed to make in one of the dependent projects > You made the change in the dependent project and saved that change. No, I didn't change anything. Just hit run once and held my hands off, it deploys multiple times. Always. Run --> 2 deployments (or more). > the ear deploys again... even though you did not use the Run item on the ear project No, it deploys when I it run... but multiple times. > If that is the sequence of events... then deploy on save is functioning correctly... Yes, but that's not the sequence of events ;-) Additional info, found after some research: there is a class in my project with a bad package name. It compiles without any warning, but causes this. If I remove the class, the problem is gone (after some cleaning).
To reproduce: - open attached project - run project - in GlassFish log are two messages that project was deployed. If not try to run project once more - remove class NewClass in JavaLibrary project - run project again and there is only one message The project starts normally, so I don't think it is more or less harmless and I am decreasing priority. Product Version: NetBeans IDE 7.0 RC2 (Build 201104050000) Java: 1.6.0_24; Java HotSpot(TM) Client VM 19.1-b02 System: Windows XP version 5.1 running on x86; Cp1250; cs_CZ (nb)
> The project starts normally, so I don't think it is more or less harmless and I am decreasing priority. Not really: if the project is big enough, the browser is started right after the first deployment, while starting the second one. Most of the time, it results in a 404, letting the developper think it doesn't work. To me, it's a P2.
Here is some additional observations... The content of the gfdeploy directory is kind of strange. all the files in the directory have modify dates/times that appear to be about the same moment -- except for the lib/JavaLibrary.jar file, which is a few seconds YOUNGER than the rest of the files. The plugin is being told to redeploy the project because the IDE thinks the project has changed. This appears to be the by-product of some issue in the EAR project and/or deploy on save. If I turn off deploy on save for the EntApp project, the project gets deployed one time... Petr Hejl should probably look at this.
One thing I would like to clarify with the reporter and yamoros. Do you know the concept of Deploy On Save? If this is enabled and you change for example presistence.xml the app is redeployed and this is how DoS works. So such behavior would not be a defect. You can disable DoS in project properties, Run tab of EAR project. There might be another case (defective) covered by the attached project when project is redeployed by Run action (ok) and once more before or after that by DoS (wrong unless you made some immediate change). Do we agree we are trying to solve the issue described in the second paragraph? My evaluation so far: It looks like unwanted redeploy is triggered before the redeploy invoked by Run. It is caused by DoS still listening on changes when Run action is starting recompilation of the class library. yamoros does it make sense in context of your observation? I need to do some more debugging, patching etc.
Can you also confirm that disabling DoS on EAR project prevents multiple redeploys?
I think the workaround for large projects would be to disable DoS completely.
> I think the workaround for large projects would be to disable DoS completely. In some cases, that's what I do. But it should be possible to deploy at least web pages on save, Netbeans is quite infective without it.
@petr: btw, the simplest workaround isn't to disable DoS... but to correct badly packaged classes ;-)
(In reply to comment #16) > I think the workaround for large projects would be to disable DoS completely. That is ultimate workaround but let's first learn more about what's causing this problem. verpoorten, ymajoros - Petr asked some questions in comment #14. Could you clarify please whether that's what you are doing or not? Thanks.
@petr (14): yes, we know what DoS does. It is defective as shown with the test case I attached here and as you seem to have found. Correcting the badly packaged class solves it, although it isn't trivial for an end user to find out if there is such a problem in a dependent project (no warning, no error).
(In reply to comment #20) > @petr (14): yes, we know what DoS does. It is defective as shown with the test > case I attached here and as you seem to have found. Correcting the badly > packaged class solves it, although it isn't trivial for an end user to find out > if there is such a problem in a dependent project (no warning, no error). I'll attach the patch I have. I really think it is caused by FS events fired after ant execution (the change itself happens during the build, but events are fired later). David, Martin can you review the patch? ymajoros Can you describe your usecase for having enabled DoS and using run together? I'm not saying it's wrong I would just like to know the details.
Created attachment 107597 [details] the patch Attaching the patch. Only EAR solution so far. For other projects we would need API change in BaseActionProvider.
(In reply to comment #20) > @petr (14): yes, we know what DoS does. It is defective as shown with the test > case I attached here and as you seem to have found. Correcting the badly > packaged class solves it, although it isn't trivial for an end user to find out > if there is such a problem in a dependent project (no warning, no error). Sorry, I'm not following what you are talking about here. The question in #14 is: do you use Run command on project which has DoS enabled? If the answer is yes then I do not think this is P2 issue unless you provide a usecase explaining why Run is necessary. Juts to avoid misunderstanding: I agree with you that DoS and Run should play well but amount of users impacted by this problem is what's important for me - is it all users or only ones who Save and Run?
During taking look at the provided patch I got another idea... When the DoS will be virtually disabled in time when user will be deploying/running it manually, isn't that way to another issues like "when user has DoS -> invoke run manually -> change files and saved them before finished deploy -> no new changes will be deployed on the server since it was disabled for a while" ... it's just idea, maybe I'm wrong. Anyway I wanted to say when wouldn't be found reason why to use Run+DoS together I would prefere just display notification dialog that it's not recommended action with checkbox ("don't show again"). Anyway you are more experiences for these cases so please take my idea really like an idea. :) In addition the patch looks to me great. Maybe just one corner case: FileObject fo = ((ConfigSupportImpl) provider.getConfigSupport()).getProjectDirectory(); - can lead to NPE, but in really rare cases
Sorry, in addition to previous comment I explained it badly ... I wanted to say that the fo=null could lead in following code to NPE but getProjectDirectory() method will return null in rare cases...
(In reply to comment #24) > During taking look at the provided patch I got another idea... When the DoS > will be virtually disabled in time when user will be deploying/running it > manually, isn't that way to another issues like "when user has DoS -> invoke > run manually -> change files and saved them before finished deploy -> no new > changes will be deployed on the server since it was disabled for a while" ... > it's just idea, maybe I'm wrong. Thanks for your review Martin. In fact this should not really happen, but I changed the patch slightly so Run and DoS overlap safely. Either the change is deployed via Run or later with DoS. It should not introduce multiple redeploys, because DoS is reenabled just before deploy (invoked by Run) when there should not be any more changes caused by ant build. > Anyway I wanted to say when wouldn't be found > reason why to use Run+DoS together I would prefere just display notification > dialog that it's not recommended action with checkbox ("don't show again"). > > Anyway you are more experiences for these cases so please take my idea really > like an idea. :) > > In addition the patch looks to me great. Maybe just one corner case: > FileObject fo = ((ConfigSupportImpl) > provider.getConfigSupport()).getProjectDirectory(); > - can lead to NPE, but in really rare cases Fixed. Pushed to web-main 47b541bdebd9.
Reporter, could you please verify the issue is fixed in the continuous build http://bertram.netbeans.org/hudson/job/web-main/4920/ (or any later build).
Integrated into 'main-golden', will be available in build *201104090401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/47b541bdebd9 User: phejl@netbeans.org Log: #197320 deploy on save on ear project with entity jar redeploys multiple times
Reporters please can you verify the issue is fixed in the mentioned daily build?
(In reply to comment #29) > Reporters please can you verify the issue is fixed in the mentioned daily > build? I'm on holiday, and the colleague where the problem occurs wasn't here last week. So, I won't be able to have a look for some days. In the meantime: - we fixed our problem by resolving the badly packaged classes, although the cause was not easy to spot. It now works ok on my computer, but didn't have a confirmation for my colleague. - I guess, if you can reproduce the problem using the test case and the fixed version doesn't show it anymore, the problem should be gone. Is the fix included in Netbeans 7 RC2? If so, I could still give it a try (just running the workaround). Thanks for the good work and sorry for not being able to check the fix right now.
Filed #197838 to fix the EJB and WEB.
Fixed in a31e80c4924c by commit for #197838.
Happens with multiple projects in 7.0 and 7.1. I can reproduce it at will (just debug any affected project), but couldn't produce test case. Creating one could be complex or not feasible: if the project is small enough, the browser will start after the project has deployed multiple times, so it's difficult to see. Any idea how to progress this? Is there some log to see what triggered a deployment?
(In reply to comment #33) > Happens with multiple projects in 7.0 and 7.1. > > I can reproduce it at will (just debug any affected project), but couldn't > produce test case. Creating one could be complex or not feasible: if the > project is small enough, the browser will start after the project has deployed > multiple times, so it's difficult to see. > > Any idea how to progress this? Is there some log to see what triggered a > deployment? It is hard to do anything without a test case. Can you summarize the steps which trigger multiple deployment? It doesn't matter the browser shows up - the multiple deployment should be visible in the log? Am I right?
Waiting for feedback. Feel free to reopen.