After several attempts, I fixed my problem by deleting the C:\Users\..\.netbeans\6.9\var\cache\index directory
(deleting var\cache\index\s.. directories was not enough)

I encountered Security warnings about inconsistencies from GlassFish, but they disappears after NetBeans and GlassFish restarts

My Java Web project executes correctly but some JSF files disappears and I lost functionalities, but this is maybe another problem...

Reassigning.

There is an inconsistency problem between NORMAL or DEBUG case: 

Now after several months, I have the same problem on another new project with no connection with package refactoring :

My new project is organized like this:
Project 1: a pure Java library.
Project 2: a Java library importing Project 1 and defining EJB interfaces.
Project 3: a Java EE module importing both Project 1 and Project 2 for persistence and Stateless EJBs of my entities.
Project 4: the Java Web main project importing everybody.

I can run the main project without any problem (F6).

But if I put a breakpoint and try to debug the application (F4), I have:

java.lang.IllegalArgumentException: Invalid ejb jar [Project_3]: it contains zero ejb. 
Note: 
1. A valid ejb jar requires at least one session, entity (1.x/2.x style), or message-driven bean. 
2. EJB3+ entity beans (@Entity) are POJOs and please package them as library jar. 
3. If the jar file contains valid EJBs which are annotated with EJB component level annotations (@Stateless, @Stateful, @MessageDriven, @Singleton), please check server.log to see whether the annotations were processed properly.
        at com.sun.enterprise.deployment.util.EjbBundleValidator.accept(EjbBundleValidator.java:72)
        at com.sun.enterprise.deployment.util.ApplicationValidator.accept(ApplicationValidator.java:124)
...


I heard about packaging all this stuff in a EAR to fix a problem of failing annotation processing but I fall with the following messages:

ATTENTION: Error in annotation processing: java.lang.NoClassDefFoundError: com/corp/app/web/controller/Controller
GRAVE: Exception while invoking class org.glassfish.ejb.startup.EjbDeployer load method
java.lang.RuntimeException: Unable to load EJB module.  DeploymentContext does not contain any EJB  Check archive to ensure correct packaging for ...

Now I am still stuck for the moment and currently found no solution on the Web.

Hi, can you please try whether it helps to turn off Compile on Save in your project's properties and rebuild the project?

I am not sure if I understand your setup correctly, but I believe you do need an EAR project as the container. Project 4 can *reference* Project 3, but it can not *contain* it. Is Project 3 packaged in WEB-INF/lib of Project 4? Such setup would be incorrect. 
Cc'ing David who was dealing with issues like this before.

OK, Project4 is referencing Project3.

Thank you, I was able to debug Project3 by putting a breakpoint in it after turning off Compile on Save on Project1 and Project2 and turning off Deploy on Save on Project3 and Project4.

But in fact, the bug still remains:

I am obliged to put a dummy breakpoint in the main project (Project4) first and do F5 to have the debugger stopping on the real breakpoint I want to debug in Project3.

I will consider packaging in a EAR file and keep you informed.

It sounds like your EJB has remote interface and you deployed Project 3 first and then deployed Project 4 which accesses the EJB from Project 3 via remote interface. If this is the case then you basically dealing with two separate J2EE modules and therefore if you start debugging of Project 4 and want to step into Project 3 you have to start Project 3 in debugger as well. Imagine two J2SE applications running and one communicating with the other via TCPIP - both apps needs to be started in debug session.

Packaging EJB and WAR into EAR would make this easier as both J2EE modules would be deployed as single EAR app and debugging would work as you are expecting - you are debugging EAR in this case.

There has been a few other bugs fixed in Compile/Deploy on Save area for NB7.0.

You are right, I have remote interface definitions, but I am not currently using them. I do accesses to my EJBs through local interfaces defined in Project3:

I did not used EAR in the past because I remember having spending to much time on the problem without success. Maybe I need to restart from scratch on a small project but here is where I am now:


I use the NetBeans wizard to create a ear file with : New Project/Java EE/Enterprise Application with Existing Sources. Then I add Project4 as a Web Module and Project3 as a EJB Module.

F6 gives:

GRAVE: Class [ Lcom/company/project/singleton/GlobalStatistics; ] not found. Error while loading [ class com.project.web.controller.GlobalStatisticsController ]
ATTENTION: Error in annotation processing: java.lang.NoClassDefFoundError: Lcom/company/project/singleton/GlobalStatistics;
INFO: Cannot find module Project3.jar in application bundle
GRAVE: com/company/project/web/controller/WebController
java.lang.NoClassDefFoundError: com/company/project/web/controller/WebController

I added Project3.jar in the Properties of the ear project but nothing changed and I cannot yet understand what the 'Cannot find module Project3.jar in application bundle' means.

Hard to say what's wrong. In your EAR's project properties you should have in your Packaging panel two J2EE module - Project 4 and 3. Nothing else. and Libraries should be empty as well. Could you describe please content of built EAR file (from yourEar/dist folder)? Again there should be Project 4 war and Project 3 JAR in root of EAR and in EAR's lib folder should be Project 1 and Project 2 jars (these two are not J2EE module but just libraries).

There have been several issues fixed in last year or so in this area and I'm not sure which of these are still present in 6.9.

Btw. are you using EE6? or EE5?

I'm attaching a test case from different issue which illustrates similar setup which just works for me. Have a look and perhaps compare it with your one. Might help find some clue. I included all built artifacts in attached ZIP so that you can have a look what correct layout of folders and files should be.

Created attachment 105322 [details]
test case

For testing purpose I tried to install NetBeans 7.0 Beta but without success: JVM has not enough space to start on a 8 Go RAM machine running Windows 7... (I sent a message...)

I use EE6.

Ear/dist folder contains:

gfdeploy\testear\Project 3_jar\com\company\...\*.class files
gfdeploy\testear\Project 4_war\*.xhtml, and subdirectories
gfdeploy\testear\lib\Project 1.jar 15 Ko
gfdeploy\testear\lib\Project 2.jar 15 Ko

Ear/build folder contains:
Project 1.jar 0 Ko
Project 2.jar 0 Ko
Project 3.jar 57 Ko
Project 4.war 113 Ko
lib\Project 1.jar 15 Ko
lib\Project 2.jar 15 Ko

I'll take a look to your attachments.

(In reply to comment #11)
> For testing purpose I tried to install NetBeans 7.0 Beta but without success:
> JVM has not enough space to start on a 8 Go RAM machine running Windows 7... 

Well, I cannot help with that. :-) When I myself bumped into similar "not-enough-memory" on Vista on my 2GB RAM laptop a few years ago I replaced the OS with Ubuntu and would never ever ever ever use Windows again.

> Ear/dist folder contains:
> 
> gfdeploy\testear\Project 3_jar\com\company\...\*.class files
> gfdeploy\testear\Project 4_war\*.xhtml, and subdirectories
> gfdeploy\testear\lib\Project 1.jar 15 Ko
> gfdeploy\testear\lib\Project 2.jar 15 Ko
> 
> Ear/build folder contains:
> Project 1.jar 0 Ko
> Project 2.jar 0 Ko
> Project 3.jar 57 Ko
> Project 4.war 113 Ko
> lib\Project 1.jar 15 Ko
> lib\Project 2.jar 15 Ko

This looks pretty much OK. The JARs with 0 size is issue 194041 which has been fixed recently and which will be available in Beta2 of NB 7.0 in a few weeks but it should not cause much harm I believe.

One more option: would it be possible to send me your projects (stripped down from any essential business logic you do not want me to see)? I would be happy to have a look what's wrong.

Created attachment 105338 [details]
Stripped down project

Thanks, I can reproduce the problem and looking at it right now.

Created attachment 105341 [details]
test case with 5 projects

user's projects modified to open in the IDE and be compilable out of of the box

Created attachment 105343 [details]
test case with 5 projects (fixed!)

Vince, there is problem either in deployment to GlassFish from IDE or in GlassFish itself. Could you have a look and file issue for GlassFish if necessary? The projects (use the last fixed attachment) looks OK but deployment fails with "java.lang.ClassNotFoundException: com.company.domain.web.controller.WebController" in server log. I could not figure out what's wrong till I realize that it must be something obscure like...space in the jar file name!...which it is. If I patch the projects and rename all jar artifact to not contain any space characters in its names then project deploys correctly. I will attach a patch which I applied on unzipped projects.

Created attachment 105344 [details]
patch for build scripts which fixes broken deployment

Btw. I used GlassFish 3.1-b33.

Alain, thanks for your project. Apart from discovering this problem I also identified two more issues:

* issue 194711 - "Error occurred during deployment: Application name Product_Portal is already in use"

* issue 194709 - "IllegalStateException: No classpath for /some/path"

Alain, one more comment about your project. Having WebController base class in EJB project and extending it from WEB project is not a good idea as it forces you to add EJB project to the classpath of Web project. I would stick with your separation of interfaces/base classes and place WebController and both GlobalConfigurator and GlobalStatistics to "Product Libraries" project. That way Web does not depend on EJB implementation project.

Doing this I was able to run it without problems - index.xhtml calling #{webConfigurationController.portalWebServerURL} via WebConfigurationController.getPortalWebServerURL. via GlobalConfigurator.getPortalWebServerURL (I added a fake one) and finally getting into GlobalConfiguratorSingleton. I was not able to do this when WEB project had dependency on EJB implementation jar. In theory it should work as well though. But I'm not very surprise it did not. HTH.

(In reply to comment #17)
> Vince, there is problem either in deployment to GlassFish from IDE or in
> GlassFish itself. Could you have a look and file issue for GlassFish if
> necessary? The projects (use the last fixed attachment) looks OK but deployment
> fails with "java.lang.ClassNotFoundException:
> com.company.domain.web.controller.WebController" in server log. I could not
> figure out what's wrong till I realize that it must be something obscure
> like...space in the jar file name!...which it is. If I patch the projects and
> rename all jar artifact to not contain any space characters in its names then
> project deploys correctly. I will attach a patch which I applied on unzipped
> projects.

There is a problem in the deployment code of GF... it is way too freaked out by spaces... especially on non-windows environments.

The plugin could correct the names of the 'modules' that are created to support directory deployment... but I do not think the plugin gets a chance to remap the names of jar files in the lib directory of an ear at all.

I opened http://java.net/jira/browse/GLASSFISH-15690 to make it visible on the server team's radar.

You should probably get involved with it... since you have the most direct experience with the issue.

(In reply to comment #22)
> http://java.net/jira/browse/GLASSFISH-15690

Thanks Vince. Considering only part of the problem is going to be fixed for GF31 I wonder whether we should add a check to GF deployment plugin in NB which would refuse to deploy EAR if one of its J2EE modules or library jars has space character in its name and GF server is 3.0* and 3.1. And provide an error message explaining that GF does not support it. What do you think? That should be simple to do no? On the other hand considering this is first time I've heard about this problem it is certainly not high priority issue - just a good example of usefulness of IDE. :-)

I think adding a check during deployment for this case is worth doing.  I will get started on it.

http://hg.netbeans.org/web-main/rev/47c0f4d5ba3a applies to this issue also...