Bug 215976

Created attachment 122381 [details]
IDE log

Comment on attachment 122381 [details]
IDE log

I noticed this in these logs but the server was set under 'properties > run'.

INFO [org.netbeans.modules.j2ee.deployment.impl.DeployOnSaveManager]: No server set for Maven project - Deploy on Save will not be performed

I also noticed this:

INFO [FaceletsLibrarySupport]: Invalidating facelets libraries due to a library descriptor change.

And this:

INFO [org.netbeans.modules.j2ee.deployment.impl.TargetServer]: Cannot incrementally deploy to more than one target


I hope it helps.

I confirm deploy-on-save doesn't work for Maven EAR project. It works in NB7.1.2 and some changes were done in bug 215089. To reproduce:

- have a GlassFish server registered in IDE
- open new project wizard and select "Maven|Enterprise Application"
- finish wizard with default values (Java EE 6, GlassFish)
- add session bean with business method to mavenproject1-ejb project
- right-click mavenproject1 and choose Build
- right-click mavenproject1-ear and choose Run
- wait until index page is opened in browser at localhost:8080/mavenproject1-web (bug 215454)
- open "mavenproject1-web|Web Pages|index.jsp" and change body
- save file but the project is not redeployed (if you reload page in browser it doesn't change)

Product Version: NetBeans IDE 7.2 (Build 201207171143)
Java: 1.7.0_06-ea; Java HotSpot(TM) 64-Bit Server VM 23.2-b09
System: Windows 7 version 6.1 running on amd64; Cp1250; en_US (nb)

Fixed together with issue 215454 in: web-main #752b7ed13c51

Integrated into 'main-golden', will be available in build *201207310001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/752b7ed13c51
User: Martin Janicek <mjanicek@netbeans.org>
Log: #215454 + #215976 - Redeployment doesnt works for maven EAR project.

*** Bug 216150 has been marked as a duplicate of this bug. ***

Created attachment 122567 [details]
Server and Maven logs.

Now it is not possible to deploy EAR project.

Product Version: NetBeans IDE Dev (Build 201207310001)
Java: 1.7.0_06-ea; Java HotSpot(TM) 64-Bit Server VM 23.2-b09
System: Windows 7 version 6.1 running on amd64; Cp1250; en_US (nb)

Looks like Windows specific issue --> works just fine on Ubuntu Linux after the changes. I'll try to fix it tomorrow on Windows 7.

*** Bug 216217 has been marked as a duplicate of this bug. ***

Gents, just to let you know, today i tried to use nightly build to find out if the problem was fixed, unfortunately hot deploy still is not working. Except for this I'm not able to deploy maven EAR Applications to Glassfish Server even manually. When i'm trying to depoy it i'm getting an exception:
========================================
In-place deployment at C:\root\programming\NBProjects\TestMavenProj2\TestMavenProj2-ear\target\TestMavenProj2-ear-1.0-SNAPSHOT
Initializing...
deploy?DEFAULT=C:\root\programming\NBProjects\TestMavenProj2\TestMavenProj2-ear\target\TestMavenProj2-ear-1.0-SNAPSHOT&name=file:_C:_root_programming_NBProjects_TestMavenProj2_TestMavenProj2-ear_&force=true failed on GlassFish Server 3+ 
 Error occurred during deployment: Exception while deploying the app [file:_C:_root_programming_NBProjects_TestMavenProj2_TestMavenProj2-ear_] : Expected to find an expanded directory for submodule TestMavenProj2-ejb-1.0-SNAPSHOT.jar but found a JAR.  If this is a directory deployment be sure to expand all submodules.. Please see server.log for more details.
The module has not been deployed.
See the server log for details.
	at org.netbeans.modules.j2ee.deployment.devmodules.api.Deployment.deploy(Deployment.java:210)
	at org.netbeans.modules.maven.j2ee.ExecutionChecker.performDeploy(ExecutionChecker.java:178)
	at org.netbeans.modules.maven.j2ee.ExecutionChecker.executionResult(ExecutionChecker.java:130)
	at org.netbeans.modules.maven.execute.MavenCommandLineExecutor.run(MavenCommandLineExecutor.java:212)
	at org.netbeans.core.execution.RunClassThread.run(RunClassThread.java:153)
========================================
It was tested on NetBeans IDE Dev (Build 201208110001) and 
NetBeans IDE Dev (201208200933)
OS Windows XP SP3
Java 1.7.0_05
GlassFish 3.1.2

(In reply to comment #10)
> Gents, just to let you know, today i tried to use nightly build to find out if
> the problem was fixed, unfortunately hot deploy still is not working. Except
> for this I'm not able to deploy maven EAR Applications to Glassfish Server even
> manually. When i'm trying to depoy it i'm getting an exception:
> ========================================
> In-place deployment at
> C:\root\programming\NBProjects\TestMavenProj2\TestMavenProj2-ear\target\TestMavenProj2-ear-1.0-SNAPSHOT
> Initializing...
> deploy?DEFAULT=C:\root\programming\NBProjects\TestMavenProj2\TestMavenProj2-ear\target\TestMavenProj2-ear-1.0-SNAPSHOT&name=file:_C:_root_programming_NBProjects_TestMavenProj2_TestMavenProj2-ear_&force=true
> failed on GlassFish Server 3+ 
>  Error occurred during deployment: Exception while deploying the app
> [file:_C:_root_programming_NBProjects_TestMavenProj2_TestMavenProj2-ear_] :
> Expected to find an expanded directory for submodule
> TestMavenProj2-ejb-1.0-SNAPSHOT.jar but found a JAR.  If this is a directory
> deployment be sure to expand all submodules.. Please see server.log for more
> details.
> The module has not been deployed.
> See the server log for details.
>     at
> org.netbeans.modules.j2ee.deployment.devmodules.api.Deployment.deploy(Deployment.java:210)
>     at
> org.netbeans.modules.maven.j2ee.ExecutionChecker.performDeploy(ExecutionChecker.java:178)
>     at
> org.netbeans.modules.maven.j2ee.ExecutionChecker.executionResult(ExecutionChecker.java:130)
>     at
> org.netbeans.modules.maven.execute.MavenCommandLineExecutor.run(MavenCommandLineExecutor.java:212)
>     at org.netbeans.core.execution.RunClassThread.run(RunClassThread.java:153)
> ========================================
> It was tested on NetBeans IDE Dev (Build 201208110001) and 
> NetBeans IDE Dev (201208200933)
> OS Windows XP SP3
> Java 1.7.0_05
> GlassFish 3.1.2

I can confirm this behavior!

Martine, will you have a chance to look at it soon, so that fix could get to 72patch1? ( Fri 09/31 is boundary for patch backports)

Sure, I'm on it..

The regression is caused by the changes made in revision http://hg.netbeans.org/web-main/rev/c0142fef8c9a
Milosi would it be safe to revert the changes?

Two more issues (217480, 215274) were introduced by that revision.

(In reply to comment #14)
> The regression is caused by the changes made in revision
> http://hg.netbeans.org/web-main/rev/c0142fef8c9a
> Milosi would it be safe to revert the changes?

It's probably fine to revert changeset that BUT as ProjectInformation's javadoc says: 

"Get a programmatic code name suitable for use in build scripts or other references."

So your code has some sort of assumptions about what will be there and/or you are leaking the name to the user, even though it displayName should be used in such cases. 

So I assume you will fix issue 215274 not just by reverting this changeset but by changing the code not to depend on project name.

same with issue 217480, the name should not be leaked into the UI (in form of persistence unit name)

I'm not very clear why the new name is causing problems in the current issue so I'm leaving that one out..


But once reverting the changeset, we are back at the beginning where loading the model just to get ProjectInformation.getName() is CPU expensive in some cases. The ant project's idea of folder name == project name (more or less) won't scale for hundreds of related projects that are fairly common in maven projects.

(In reply to comment #16)
> (In reply to comment #14)
> > The regression is caused by the changes made in revision
> > http://hg.netbeans.org/web-main/rev/c0142fef8c9a
> > Milosi would it be safe to revert the changes?
> 
> It's probably fine to revert changeset that BUT as ProjectInformation's javadoc
> says: 
> 
> "Get a programmatic code name suitable for use in build scripts or other
> references."
> 
> So your code has some sort of assumptions about what will be there and/or you
> are leaking the name to the user, even though it displayName should be used in
> such cases. 

Definitely agree, but the code assumptions are made in a different areas (in case of issue 217480 it's Persistence UI and in case of issue 215274 it's Glassfish server UI).

> So I assume you will fix issue 215274 not just by reverting this changeset but
> by changing the code not to depend on project name.
> 
> same with issue 217480, the name should not be leaked into the UI (in form of
> persistence unit name)

Ok, I'll revert the changeset and file new tickets to the areas where the change from getName() to getDisplayName() needs to be done - we should probably make those two things separate so the patch for 7.2.1 will be as small as possible.

> 
> I'm not very clear why the new name is causing problems in the current issue so
> I'm leaving that one out..
> 
> 
> But once reverting the changeset, we are back at the beginning where loading
> the model just to get ProjectInformation.getName() is CPU expensive in some
> cases. The ant project's idea of folder name == project name (more or less)
> won't scale for hundreds of related projects that are fairly common in maven
> projects.

I'm aware of that and in the long term we should probably made the change anyway, but it should be done together with evaluation of the getName() usages (as it looks it's badly use in many cases)..

Fixed in: web-main #cf6a199bfed4
(actually it's only reverted revision #c0142fef8c9a)

Vlado, could you please verified?

verified against case in comment #3

Product Version: NetBeans IDE Dev (Build web-main-8358-on-20120830)
Java: 1.7.0_03; Java HotSpot(TM) Client VM 22.1-b02
System: Windows 7 version 6.1 running on x86; Cp1252; en_US (nb)

Thanks Vlado for verification!

At the end it looks like the two problems were mixed up. Revision c0142fef8c9a wasn't as a part of the NetBeans 7.2FCS (because of that I think that only the first changeset from comment 5 needs to be transplanted). The second one (from the comment 18) is relevant only for trunk..

I've transplanted revision from comment 5 in:
- http://hg.netbeans.org/releases/rev/e422546e8548

...and increase specification version number + change long description in:
- http://hg.netbeans.org/releases/rev/f3fc5886aa5a

Would be really good to test it again with the release branch sources. I've done that, but only on Ubuntu Linux, because I don't have release72 branch cloned on Windows.

Thanks a lot for this fix.

Is it already available to download from trunk build? I may test it on Windows 7 64 when it is.

Hugs!

Integrated into 'main-golden', will be available in build *201208310001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/cf6a199bfed4
User: Martin Janicek <mjanicek@netbeans.org>
Log: #215976 - Redeployment doesnt works for maven EAR project.

Yes rbento, it is available in the todays nighly build (http://bits.netbeans.org/dev/nightly/2012-08-31_00-01-28/). Would be great if you could test it as well. Thanks!

I've tested it again at home on Windows XP and it works just fine. (again saying that it would be good to test the issue on release branch sources as well)

Created attachment 123782 [details]
Screenshot to show the messed application name.

Please, notice the application name.

I've tested it and the redeployment works but with a caveat.

The application name is still messed up.

There is a thread in GlassFish jira but it seems to be a problem with netbeans when deploying the app to the gfdeploy folder.

What happens is that when the application name is messed up, redeployment works. When it is correct, redeployment doesn't work.

For example, the application is deployed to the gfdeploy folder with name  

   - com.mycompany_mavenproject1-ear_ear_1.0

instead of 

   - com.mycompany.mavenproject1-ear-1.0

It breaks portable JNDI names when finding resources by lookup.

If you deploy the EAR to GlassFish via web console or autodeploy directory the application name is correct.

Could you please take a look?

http://java.net/jira/browse/GLASSFISH-16793

Let's track that as a separate issue. Can you please file a new bug report?

Hello,

I tested again the following scenario and found some issues:

 - Clean Netbeans 201208310001 install without GlassFish
 - Download Glassfish 3.1.2.2 zip.
 - Unzip it to a folder. (C:\Servers\glassfish-3.1.2.2)
 - Used the same application 'mavenproject1'.
 - Select app > Clean/Build > Right click and run on EAR module.
 - The application is deployed but it is not shown under Services > Server >
Your GF Instance > Applications. (Even if you keep refreshing it)
 - Redeployment doesn't work.

Another test case:

 - Have 2 simple apps mavenproject1 and mavenproject2
 - Open both, Clean/Build both, deploy both. Redeployment works.
 - Stop GlassFish.
 - Close one of the apps. Clean/Build the other.
 - Run it. 
 - You will notice that the closed application is deployed even if it is
closed.

Sorry, I was testing deployment now. I will file another issue for the
application name. 

Thanks a lot.

Integrated into 'releases', will be available in build *201209010822* or newer. Wait for official and publicly available build.
Changeset: http://hg.netbeans.org/releases/rev/e422546e8548
User: Martin Janicek <mjanicek@netbeans.org>
Log: #215454 + #215976 - Redeployment doesnt works for maven EAR project.
(transplanted from 752b7ed13c511ee8162c89e84718de2b0931dc1f)

(In reply to comment #28)
> Let's track that as a separate issue. Can you please file a new bug report?

Issue 215274 already exists to track this one. The problem lies in the Glassfish module (see issue 217619 for some details) which is using wrong Maven API method.

(In reply to comment #29)
> Hello,
> 
> I tested again the following scenario and found some issues:
> 
>  - Clean Netbeans 201208310001 install without GlassFish
>  - Download Glassfish 3.1.2.2 zip.
>  - Unzip it to a folder. (C:\Servers\glassfish-3.1.2.2)
>  - Used the same application 'mavenproject1'.
>  - Select app > Clean/Build > Right click and run on EAR module.
>  - The application is deployed but it is not shown under Services > Server >
> Your GF Instance > Applications. (Even if you keep refreshing it)
>  - Redeployment doesn't work.

Was the application deployed for the first time? I mean you were able to see index.html with "Hello World!" text in the browser, right?
Not sure if the issue is the same as the initial one, that's why I'm asking..

> 
> Another test case:
> 
>  - Have 2 simple apps mavenproject1 and mavenproject2
>  - Open both, Clean/Build both, deploy both. Redeployment works.
>  - Stop GlassFish.
>  - Close one of the apps. Clean/Build the other.
>  - Run it. 
>  - You will notice that the closed application is deployed even if it is
> closed.

Doesn't sound like a bug to me. As far as I know typically you need to undeploy your application manually (NetBeans don't do that when closing the project). Maybe I'm wrong but this behavior seems to me correct.

> 
> Sorry, I was testing deployment now. I will file another issue for the
> application name. 
> 
> Thanks a lot.

Test case in comment 3 works for me. I can't reproduce other problems mentioned by rbento. Also if project is closed it is not undeployed. Only the clean action does undeploy or you have to undeploy in Services view. I think you agree that redeployment works now. If you encounter a different problem, please file a new bug. Thank you.

Not working again in 7.4 daily, except when you save edits to a module Netbeans claims the ear was deployed in the status bar. To state the obvious, the "target/gfdeploy" folder does not reflect the changes.


Product Version: NetBeans IDE Dev (Build 201304252301)
Updates: Updates available
Java: 1.7.0_21; Java HotSpot(TM) 64-Bit Server VM 23.21-b01
Runtime: Java(TM) SE Runtime Environment 1.7.0_21-b12
System: Mac OS X version 10.8.4 running on x86_64; US-ASCII; en_US (nb)
User directory: /Users/alvin/Library/Application Support/NetBeans/dev
Cache directory: /Users/alvin/Library/Caches/NetBeans/dev

Could this be a duplicate of bug 226298? Jirko, do you know if this is also a problem in 7.3.1, or only in 7.4? Thanks.

It works for me in 7.3.1 dev build in Maven EAR EE6 project with GlassFish 4.

Product Version: NetBeans IDE Dev (Build web-main-javaee7-270-on-20130429)
Java: 1.7.0_17; Java HotSpot(TM) 64-Bit Server VM 23.7-b01
Runtime: Java(TM) SE Runtime Environment 1.7.0_17-b02
System: Windows 7 version 6.1 running on amd64; Cp1250; en_US (nb)

Maybe we should create another ticket (with TM = 7.4 and whiteboard containing "731-not-a-stopper") for for the current problem. It is most probably unrelated with respect to the fix, only the steps are identical.

With respect to the comment 37 (don't like the mess here to be honest:)) I have created identical issue 229328 with correct TM, whiteboard, etc. --> Closing this one. Anyone interested, please follow 229328 instead. Thanks