Hello, I am not able to reproduce using these steps:

- create maven web app (tried with both EE5 a EE6)
- create new servlet
- create new junit test for existing class (for NewServlet class), unchecked  "generate default method bodies"
- invoke test action -> test passes, no error.

I worked when I unchecked "Default Method Bodies"! The "Default Method Bodies" checked will generate testProcessRequest, testDoGet, testDoPost and testGetServletInfo, which all fails!

The test script must be updated to explicitly say "Uncheck Default Method Bodies".

I'll update test specification.  Anyway, passing to j2ee guys in order to decide if those default method bodies are correct or not.


------------------------------------------------------------------------------
Test set: com.mycompany.mavenproject2.NewServletTest
-------------------------------------------------------------------------------
Tests run: 4, Failures: 1, Errors: 3, Skipped: 0, Time elapsed: 0.042 sec <<< FAILURE!
testProcessRequest(com.mycompany.mavenproject2.NewServletTest)  Time elapsed: 0.017 sec  <<< ERROR!
java.lang.NullPointerException
	at com.mycompany.mavenproject2.NewServlet.processRequest(NewServlet.java:30)
	at com.mycompany.mavenproject2.NewServletTest.testProcessRequest(NewServletTest.java:40)

testDoGet(com.mycompany.mavenproject2.NewServletTest)  Time elapsed: 0.001 sec  <<< ERROR!
java.lang.NullPointerException
	at com.mycompany.mavenproject2.NewServlet.processRequest(NewServlet.java:30)
	at com.mycompany.mavenproject2.NewServlet.doGet(NewServlet.java:58)
	at com.mycompany.mavenproject2.NewServletTest.testDoGet(NewServletTest.java:53)

testDoPost(com.mycompany.mavenproject2.NewServletTest)  Time elapsed: 0.001 sec  <<< ERROR!
java.lang.NullPointerException
	at com.mycompany.mavenproject2.NewServlet.processRequest(NewServlet.java:30)
	at com.mycompany.mavenproject2.NewServlet.doPost(NewServlet.java:71)
	at com.mycompany.mavenproject2.NewServletTest.testDoPost(NewServletTest.java:66)

testGetServletInfo(com.mycompany.mavenproject2.NewServletTest)  Time elapsed: 0.001 sec  <<< FAILURE!
junit.framework.ComparisonFailure: expected:<> but was:<Short description>
	at junit.framework.Assert.assertEquals(Assert.java:81)
	at junit.framework.Assert.assertEquals(Assert.java:87)
	at com.mycompany.mavenproject2.NewServletTest.testGetServletInfo(NewServletTest.java:79)

Well, this is typical project configuration problem related to Java EE 6. javaee-web-api(6.0) artifact on project classpath cannot be used for project execution, ie. for unit test running. The jar contains stripped down Java bytecode and only method signatures are present. This is known issue and workaround is to use real java ee 6 APIs coming from application server being used.

I'm keeping this issue open and will try to enhance an existing editor hint to cover this case as well or try to war user in some way.

This is not a Beta stopper as this problem always existed since introduction of EE 6.

Thanks for great feedback. I think all hints/improvements that can help the user understanding what is going on should be added! :)

Editor Error hint added: 3d2378fcca8a
It warns user about the problem.

Integrated into 'main-golden', will be available in build *201102240001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/3d2378fcca8a
User: David Konecny <dkonecny@netbeans.org>
Log: #195442 - Unable to test file; error hint added to help user identify the problem

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

David,

I believe this bug still exists. I mentioned in Bug 196647 that I can reproduce this bug under dev build 201103130400.

(In reply to comment #9)
> I believe this bug still exists. I mentioned in Bug 196647 that I can reproduce
> this bug under dev build 201103130400.

Well, it was "designed" that way. Java EE 6 API artifact available in public repo is suitable only for compilation and there is no general solution to solve execution of unit tests. But that is not NetBeans issue: it is Java EE 6 + Maven issue. Usual answer is to use Maven artifact representing Java EE 6 APIs from application server which you are developing against. Which has lot of its own problems. So once somebody comes with a solution which works in Maven (IDE independent) then IDE can try to mimic it. Till then I place hint into IDE which in certain situations warns user that things will get broken in their current setup because real EE 6 API is missing on classpath.

David,

Why not omit the JAR from the test classpath at runtime? Users will get ClassNoDefError if they try referencing it at which point we tell them to provide their container-specific implementation.

PS: What is the problem with depending on the container implementation to begin with?

(In reply to comment #11)
> Why not omit the JAR from the test classpath at runtime? Users will get
> ClassNoDefError if they try referencing it at which point we tell them to
> provide their container-specific implementation.

ClassNoDefError would certainly be better than the current cryptic ClassFormatError. How do you omit the JAR from the test classpath at runtime in Maven?

> PS: What is the problem with depending on the container implementation to begin
> with?

There is no problem with that and that's exactly what Ant-based projects do. The Maven is the problem here. What Maven dependency do you specify when your server is  Weblogic or Websphere? And even for GlassFish it is not straightforward - there is embeddable GF artifact in repository but I would be reluctant to use that dependency in all Maven EE projects testing classpath.

Basically, I understand this is frustrating and I've been explaining this issue on and on, but my approach is currently following: if Maven users (independently of IDE) come up with a way to deal with EE 6 unit testing then we will provide support for that in NetBeans ASAP.

David,

I think I finally understand what you mean. Are you saying that Maven doesn't differentiate between test-compile and test-runtime hence you're forced to use the same classpath? In that case, couldn't you omit javaee-web-api from web projects and only add a dependency once the user selects a Web Server using Project Properties?

(In reply to comment #13)
> David,
> 
> I think I finally understand what you mean. Are you saying that Maven doesn't
> differentiate between test-compile and test-runtime hence you're forced to use

Yes, I do not know how to do that. But my experience with Maven is limited and perhaps there is a way how to differentiate test-compile from test-runtime. I'm waiting for somebody else to craft such pom.xml and show me how to do that.

> the same classpath? In that case, couldn't you omit javaee-web-api from web
> projects and only add a dependency once the user selects a Web Server using
> Project Properties?

How would the compilation work in such case? Maven projects does not have any concept of selected server and running pom.xml from IDE or from command line should produce the same results. Omitting javaee-web-api would stop project from compiling.

But my biggest problem is the second part of your suggestion: "add a dependency once the user selects a Web Server". As I said earlier if selected server is for example Weblogic which is not developed in open source and there is no public Maven repository containing Weblogic artifacts, what dependency should IDE add to pom.xml in such case?? There is none.

My own answer to that question is: a team using Weblogic has to setup their own internal Maven repo and upload hand selected Weblogic binaries there and give them an artifact group and id. Then pom.xml can use this dependencies instead of javaee-web-api and successfully run unit tests against them.

I would love to hear that I'm wrong and that there is much simpler solution. Please attach a pom.xml to this issue which runs EE 6 unit tests without problems and I will gladly reopen this issue and fix it. Thanks.

Read for example:
http://www.adam-bien.com/roller/abien/entry/trouble_with_crippled_java_ee

> differentiate between test-compile and test-runtime 

This sounds like a trick to use:

http://stackoverflow.com/questions/2116220/how-can-i-use-different-jars-for-compiling-and-testing-in-maven

> Omitting javaee-web-api would stop project from compiling.

I'm actually in favor of this. The project shouldn't compile until valid dependencies are provided. I don't consider the stubbed dependencies to be valid.

If a user tries using Weblogic it is up to him/her to add the relevant dependency to the pom file (and by extension the local Maven repository).

Check out these interesting posts for an alternative approach:

http://community.jboss.org/wiki/WhatsthecauseofthisexceptionjavalangClassFormatErrorAbsentCode

http://stackoverflow.com/questions/1979957/maven-dependency-for-servlet-3-0-api

The key sentence from the JBoss article is: "The workaround is to not use javax.javaee-api but rather use the individual, "real" artifacts that you need."

The stackoverflow answer seems to suggest the same.

What happens if you use the Glassfish implementation under a non-Glassfish container? Will anything actually break?

(In reply to comment #16)
> > Omitting javaee-web-api would stop project from compiling.
> 
> I'm actually in favor of this. The project shouldn't compile until valid
> dependencies are provided. I don't consider the stubbed dependencies to be
> valid.

I understand your reasoning but result would be even duplicates of this issue and even more explaining on my side without solving anything. So it is not particularly seductive option. :-)

> The key sentence from the JBoss article is: "The workaround is to not use
> javax.javaee-api but rather use the individual, "real" artifacts that you
> need."

I agree with that. Once each server has something like JBoss's 'org.jboss.spec:jboss-javaee-6.0-1.0.0.Final' then NetBeans can easily update pom.xml to use that one instead of javaee-web-api. But that raises one important question: if JBoss can release artifact containing full EE 6 APIs and it is legal and there are no license issues then what justifies existence of javaee-web-api with stripped bytecode?

> The stackoverflow answer seems to suggest the same.
> 
> What happens if you use the Glassfish implementation under a non-Glassfish
> container? Will anything actually break?

If what you are using from GF is just EE 6 API then nothing will break and everything will just work. People probably file an issue for NB saying that their pom.xml contains reference to GlassFish despite their server being ServerABC.

---

My take on this is to wait and see. As there is more EE 6 servers released and more complaints from Maven users (and more complaints from annotation processor users who needs to *execute* their annotation processor in order to compile their sources which at the moment fails similarly to unit test execution) this issue will get resolved. In the meantime existing Maven users has to fix it by hand. Or do not use Maven. :-)

I don't see the problem with just depending on the Glassfish implementation. It sounds like an easier solution in the long run instead of having to inject a different JAR file depending on the configured server.

You can include a comment above the dependency explaining that this dependency in no way implies a dependency on the Glassfish container and point them to this issue if they need more information.

(In reply to comment #18)
> I don't see the problem with just depending on the Glassfish implementation. It
> sounds like an easier solution in the long run instead of having to inject a
> different JAR file depending on the configured server.
> 
> You can include a comment above the dependency explaining that this dependency
> in no way implies a dependency on the Glassfish container and point them to
> this issue if they need more information.

I agree. The only problem is that GlassFish does not produce such artifact. As far as I know.

David,

What about the following artifacts?

http://download.java.net/maven/glassfish/org/glassfish/javaee-api/3.1/
http://download.java.net/maven/glassfish/org/glassfish/javax.servlet/3.1/

Similar artifacts can be found under http://download.java.net/maven/glassfish/org/glassfish/

For example, in my case I replaced:

		<dependency>
			<groupId>javax</groupId>
			<artifactId>javaee-web-api</artifactId>
			<version>6.0</version>
			<scope>provided</scope>
		</dependency>

with

	 <dependency>
	  <groupId>org.glassfish</groupId>
	  <artifactId>javax.servlet</artifactId>
	  <version>3.1</version>
		<scope>provided</scope>
	 </dependency>

(In reply to comment #20)
> http://download.java.net/maven/glassfish/org/glassfish/javaee-api/3.1/

"Could not find artifact glassfish:javaee-api:jar:3.1 in http://download.java.net/maven/glassfish/"

> http://download.java.net/maven/glassfish/org/glassfish/javax.servlet/3.1/

This is just a Servlet API. EE 6 has dozens of other APIs.


If you want to help setup your pom.xml so that everything works for you and then attach it here.

David,

We could take the approach suggested by Stackoverflow: include the specific APIs the user is trying to use (i.e. servlet) as dependencies instead of javaee-web-api.jar.

David,

There is a new solution as of July 2011: http://stackoverflow.com/a/8008846/14731

Simply add this dependency:

<dependency>
        <groupId>javax.servlet</groupId>
        <artifactId>javax.servlet-api</artifactId>
        <version>3.0.1</version>
</dependency>

Can Netbeans include this by default in front of javaee-web-api? At then people trying to use the servlet API won't run into trouble, and over time we can swap out the remaining J2EE apis.

Martin, could you have a look please at last comment from gtzabari and respond to it? Thanks.

I don't have the complete background, but I tried to follow steps from comment 1 and add dependency mentioned in comment 23 to pom.xml and I still see 3/4 failed tests (or rather causing an error). The exception isn't the same as before, but I don't think this is a solution (--> only thing is that the user don't see the same output which might be even worse, because it's harder to find out what's going on)

> Can Netbeans include this by default in front of javaee-web-api? At then people
> trying to use the servlet API won't run into trouble, 

We could definitely do that, but it would make sense only if everything would work as expected.

> and over time we can swap out the remaining J2EE apis.

Not sure what this mean?
..anyway would be great if you could attach simple project with pom.xml where tests work correctly and I'll try to find an implementation based on it.