Created attachment 33145 [details]
server and IDE logs

Most likely a GlassFish bug.
This is what we actually do: we create couple of classes, compile them according
to the selected source level and create a war file.
Then we deploy war file to GlassFish. 

This is a message from server log :

Exception occured in J2EEC Phase
java.lang.UnsupportedClassVersionError: Bad version number in .class file
        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
        at
com.sun.enterprise.loader.EJBClassLoader.findClass(EJBClassLoader.java:667)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
        at com.sun.enterprise.webservice.WsUtil.genWSInfo(WsUtil.java:2056)
        at
com.sun.enterprise.deployment.backend.ModuleDeployer.loadDescriptors(ModuleDeployer.java:396)
        at
com.sun.enterprise.deployment.backend.WebModuleDeployer.deploy(WebModuleDeployer.java:155)
        at
com.sun.enterprise.deployment.backend.ModuleDeployer.doRequestFinish(ModuleDeployer.java:160)
        at
com.sun.enterprise.deployment.phasing.J2EECPhase.runPhase(J2EECPhase.java:169)
        at
com.sun.enterprise.deployment.phasing.DeploymentPhase.executePhase(DeploymentPhase.java:95)
        at
com.sun.enterprise.deployment.phasing.PEDeploymentService.executePhases(PEDeploymentService.java:871)
        at
com.sun.enterprise.deployment.phasing.PEDeploymentService.deploy(PEDeploymentService.java:266)
        at
com.sun.enterprise.deployment.phasing.PEDeploymentService.deploy(PEDeploymentService.java:739)
        at
com.sun.enterprise.management.deploy.DeployThread.deploy(DeployThread.java:174)
        at
com.sun.enterprise.management.deploy.DeployThread.run(DeployThread.java:210)
----------------

Seems that GlassFish is somehow processing the WS classes.

Which VM do you use for the GlassFish VM?
I cannot see this in the server log file...

Is Glassfish running on 1.6? It seems to be there's a clash that we push 1.6
classfiles, but GF running on 1.5 doesn't get them.

;O)) I just got an email from issuezilla and immediately replied without
noticing  your comment as the issue seemed obvious. Sorry for redundancy ;O)

> Is Glassfish running on 1.6?

This should not be so important, but I think that glassfish run on 1.5

We tried following steps on Milan's box:

-create new webproject (J2EE 1.4/src level 1.4)
-create new websvc w/ dummy operation in it
-build project
-backup wsdl and mapping file
-comment wscompile task in build-impl.xml
-clean & build project (just to be sure that classes are compiled by javac task
with sourcelevel set to 1.4)
-restore wsdl and mapping file
-build project again (to put wsdl and mapping files into war)
-deploy project

note that IDE was running on 1.6

I'll try to re-check this on my box...

If Gf is running 1.5 then this error indicates that GF is receiving *some*
classes that are 1.6

So it is a Nb issue, and not a GF issue.
To make sure, please check the content of the archive before it is deployed, and
see if it contains 1.6 classes.

In any case, this bug is not in the plugin category.
If oyu really think it is a GF bug, file a bug on GF product, but I doubt it is
in GF given what was said.

the problem is that the same as in case of issue 82736, I'd say:

-glassfish is running on JDK 1.5 
-IDE is running on JDK 1.6 - if you uncheck set src level checkbox then 1.6 will
be used for the project

=> project wizards/properties should probably check the version of java platform
the server is running on instead of one the IDE is running on and it should set
1.5 instead of 1.6 as project src level in this case. Project properties also
should not allow user to change project src level to 1.6 if target server is
running on 1.5...

question is, when and how to register java platform in the IDE if
J2eePlatformImpl.getJavaPlatform() returns null....

Vince: please start on this one.
First of:
1/ maybe no remote APIs to check the vm version for AS ?
2/ even if we have one, j2eeserver api needs a JavaPlatform object, and I am not
sure such object can represent a remote JDK, so this would be a bug in the
current j2eeserver API
3/ the error is reported (late I know) by the server: we need to file a bug
there as well to have a better error message for this common scenario: GF has to
emit a nice error without stacttrace when the archive is not compatible with the
current server vm.

Only for clarification - my glassfish is installed on JDK 1.5.0_07. 

Web module is not calling
http://www.netbeans.org/download/dev/javadoc/org-netbeans-modules-j2eeserver/org/netbeans/modules/j2ee/deployment/devmodules/api/J2eePlatform.html#getSupportedJavaPlatformVersions()

when the call to
http://www.netbeans.org/download/dev/javadoc/org-netbeans-modules-j2eeserver/org/netbeans/modules/j2ee/deployment/devmodules/api/J2eePlatform.html#getJavaPlatform()

returns null.

It probably should and limit the -source to the highest value returned in that set.

this issue is does not depend on 82736

Vince, if you say "Web module is not calling ..." could you say from where it is
not called and point to the code where it should be fixed once you investigated
it, please? It would save my evaluation time. Thank you.

Right... I misspoke.  The web project doesn't appear to call getJavaPlatform(),
so there is no null return.

Well, the web project should call both apis, to make sure the 'javac.source' and
'javac.target' properties is set correctly.

This is a more general issue. It does not apply only to web services but to all
our projects (web, ejb) so we should disscuss more how it could be solved and if
there is a way to solve it. Right now I don't see a way how to fix it. There is
a lot of ways how the user can set source level higher that is JDK version on
which the appserver is running (wizard, project properties). Or the user can
change the appserver which can also produce this issue.

What said Vince about J2eePlatform.getSupportedJavaPlatformVersions() and
J2eePlatform.getJavaPlatform() will not help. If you look into
org.netbeans.modules.j2ee.sun.ide.j2ee.PlatformImpl class you will see that
getSupportedJavaPlatformVersions() returns "1.4, 1.5" and getJavaPlatform()
returns null. Null value is a problem because we don't know on which JDK is
Glassfish running. It is a JDK which is not registered in the IDE. If we don't
know this JDK version we cannot do anything.

I agree with Ludo's three steps so I don't understand why this issue was
reassigned to web project. Reassigning back.

build 200609062200

I just found the same problem when deploying JAX-WS web service.I'm sure this
worked when I deployed this.Changing the summary and attaching server log,which
is  similar to the one in JAX-RPC case.

Created attachment 33679 [details]
server.log

The server provides a better error message now.

deployment started : 0%
Deploying application in domain failed; Error loading deployment descriptors for
module [WebApplication6] -- Class test.NewServlet has unsupported major or minor
version numbers, which are greater than those found in the Java Runtime
Environment version 1.5.0_06
/home/vbk/WebApplication6/nbproject/build-impl.xml:430: Deployment error:
The module has not been deployed.
See the server log for details.

It looks like nobody calls the getJavaPlatform() method, so even if the
serverplugin implemented it to return a JavaPlatform object, no project that
writes the project.properties and/or build-impl.xml will take that into account
when these files are written (to set "javac.target" to 1.5 instead of letting it
default to 1.6).

The plugin and server cannot do anything to stop the user from trying to deploy
something that is undeployable.  The server gives about as good a message as
possible.

closing.

Will open enhancements on the standard projects (ejb, appclient, web) to consult
the getJavaPlatform() method for the target server.

VERIFIED