[carmeanu]

Good Morning,

I am trying to deploy in my development environment (Glassfish v2 b50), but have issues deploying in exploded mode. While the EAR deploys, embedded applications do not.

In my concrete case, I have an EAR with one web application- Checking the admin console after deploying shows that the EAR was deployed and properly registered, however, the web application is only shown in the EAR sub-components section, but not registered as a web application. Trying to point a browser to the applications URL only produces a bunch of exceptions confirming that the web application *.war was not processed (class not found exceptions…)

My configuration is MyEclipse 20070521-5.5.1-GA with Glassfish v2 b50 on Windows XP Pro. Please advice…

Thanks,
/Chris

[Loyal Water]

Does deploying the WAR by itself works ?

Also, can you try out a different GF2 build to see if the behavior is different (e.g. 48). They are under heavy dev and seem to fix/break things with every build.

[carmeanu]

Yes, deploying the war alone works. Also, deploying in packaged mode (the whole EAR) works just fine also! However, that is not an option as it takes forever to build…

Thanks,
/Chris

[carmeanu]

I’ll give build 48 a shot. I’d have no issues using the v1.1 production build instead (which is our production environment anyway), but MyEclipse doesn’t provide exploded deployment for some reason…

/Chris

[Loyal Water]

The GlassFish exploded deployment issue was a known issue which the GlassFish team fixed in the nightly build 47. The new builds (47 and later) should allow you deploy in exploded mode. I hope GF2 B48 does the trick.

[carmeanu]

It doesn’t work with any of the builds I tried (v2 build 48, 49, and 50). The only difference is that build 48 does not produce all this class not found exceptions- but only because it does not access the application as such at all. Trying to point the browser to the applications URL delivers the directory listing!

The issue is the same for all builds: the sub-module is not registered/deployed properly.

Any thoughts?

Thanks,
/Chris

[carmeanu]

@carmeanu wrote:

It doesnI forgot to mention that ALL builds I tested have no issues in packaged deployment mode.

Thanks,
/Chris

[Loyal Water]

Hi crmeanu,
Can you switch your workspace and try setting up your app in the new workspace and deploying it from there ? This is the first time that I have heard of such an issue.

[Geoff]

I am also having difficulties deploying an ear with ejb and war as exploded versions.

I also had to make a small changes to the app to make it comply with the Java EE 5 spec. When building the app under MyEclipse I cannot find a way to package the jars from the project dependencies into the /lib directory of the ear. This makes them automatically available to the wars and ejbs without having to modify the MANIFEST.MF file. I believe this is the recommended procedure now, so I hope MyEclipse will be able to address it.

Anyway so after that I have an exploded deployment that looks like:
ear
— /lib/someJar.jar
–/someEjb_jar/
–/someWar_war/

My war uses the JAXWS webservices (by simply adding @WebService and @WebMethod annotations — super cool to be able to do that! Sooooo easy compared to most web service toolkits).

If I deploy the war directory using the _war naming convention I get an error about the WsGen.

If I deploy the war directory using the .war naming convention I get an error about the ClassNotFound stuff that is mentioned above. This is not even going through MyEclipse. I am posting this information in case it can help fix the problem. I don’t think this error has to do with MyEclipse unless the naming convention is wrong (.war instead of _war for the directory name).

Also, does anyone know which way it should be and why glassfish (v2 b51) would handle it differently? Does anybody know how to resolve this problem? I have posted some information on the glassfish site (http://forums.java.net/jive/thread.jspa?messageID=222881&#222881) Hopefully we can get to the bottom of this.

Thanks for any input!

-Geoff

[Riyad Kalla]

I also had to make a small changes to the app to make it comply with the Java EE 5 spec. When building the app under MyEclipse I cannot find a way to package the jars from the project dependencies into the /lib directory of the ear. This makes them automatically available to the wars and ejbs without having to modify the MANIFEST.MF file. I believe this is the recommended procedure now, so I hope MyEclipse will be able to address it.

Geoff, the way to do this is to edit the EAR’s properties, and under the EAR settings, tell it to JAR dependent Java Projects under it’s root, then make sure to mark all the dependent Java Projects that it needs to package under Project REferenes.

Also, does anyone know which way it should be and why glassfish (v2 b51) would handle it differently? Does anybody know how to resolve this problem? I have posted some information on the glassfish site (http://forums.java.net/jive/thread.jspa?messageID=222881𶚡) Hopefully we can get to the bottom of this.

Geoff keep us posted what the Glassfish team says… if you are able to put together a small test project to give them (a MyEclipse project is fine) that would help them out. We’ve been working with them to get certain things fixed, but it looks like some other more complex configurations are still having issues. But from what I’ve seen the team is very responsive so the more info you can give them the faster/more likely it will get fixed.

[Geoff]

Thank you for your response. Yes I am telling it to package them under its root. This is actually the problem. The Java EE 5 spec says to package dependent jars under the /lib directory to make them available to all of the ejb and war applications. Its not that you can’t have them in the root and add the entries to the MANIFESTS, its just that the new way of doing it doesn’t require your to. So simply being able to specify the directory as / or /lib for each dependency would solve this, or even just have normal java projects automatically go to the /lib directory I think would be fine too. Even when the project is an EJB3 entity bean only project it belongs in this /lib directory.

Thanks again for all the great work you guys do, and I hope this helps.

-Geoff

[Riyad Kalla]

Geoff, thanks for the clarifiaction. I’ll file this.

[Geoff]

After working with the Glassfish team I have found out that they have put a fix into place for this exact issue. I’m not sure if it will cover the orginal issue posted here, but it will cover the issue of the WsGen in the exploded war. I am very excited about the update and will post my results as soon as possible.

[Riyad Kalla]

Very cool thank you for the heads up.

[Geoff]

Okay I have more information about the deployment of the exploded ears.

First the nightly build of glassfish works like a champ for exploded deployments if they are are built as described in:

http://developers.sun.com/appserver/reference/techart/deployment.html#5

But let me just give you the short details.

When deploying the exploded ear directory, the ejb sub directories need to end in _jar not .jar. The web directories need to end in _war and not .war.

This is going to be a problem as I can’t deploy from MyEclipse. Is there a setting somewhere that I can change to force it to name them like this?

Also, if I start glassfish under MyEclipse and then try to deploy something (that I just deployed when starting glassfish outside of MyEclipse) it errors. So the good news is, glassfish is now working with the exploded deployments. The bad news is I guess we now need to get MyEclipse updated with some new stuff to work with it :-).

So here is the error I get when deploying a previously working ear to glassfish started with MyEclipse:

Jun 20, 2007 10:52:38 AM com.sun.enterprise.deployment.phasing.PEDeploymentService$AuditInfo <init>
INFO: Deployment by user Unknown of module MyTestEar (type=Application) starting
Jun 20, 2007 10:52:43 AM com.sun.enterprise.deployment.phasing.J2EECPhase runPhase
SEVERE: Exception occured in J2EEC Phase
com.sun.enterprise.deployment.backend.IASDeploymentException
at sun.net.www.ParseUtil.decode(ParseUtil.java:189)
at sun.misc.URLClassPath$FileLoader.<init>(URLClassPath.java:863)
at sun.misc.URLClassPath$3.run(URLClassPath.java:319)
at java.security.AccessController.doPrivileged(Native Method)
at sun.misc.URLClassPath.getLoader(URLClassPath.java:313)
at sun.misc.URLClassPath.getLoader(URLClassPath.java:290)
at sun.misc.URLClassPath.getResource(URLClassPath.java:160)
at java.net.URLClassLoader$1.run(URLClassLoader.java:192)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:242)
at java.lang.Package.getPackageInfo(Package.java:350)
at java.lang.Package.getAnnotation(Package.java:361)
at com.sun.xml.bind.v2.model.annotation.RuntimeInlineAnnotationReader.getPackageAnnotation(RuntimeInlineAnnotationReader.java:89)
at com.sun.xml.bind.v2.model.annotation.RuntimeInlineAnnotationReader.getPackageAnnotation(RuntimeInlineAnnotationReader.java:17)
at com.sun.xml.bind.v2.model.impl.ClassInfoImpl.getClassOrPackageAnnotation(ClassInfoImpl.java:381)
at com.sun.xml.bind.v2.model.impl.ClassInfoImpl.getAccessorOrder(ClassInfoImpl.java:400)
at com.sun.xml.bind.v2.model.impl.ClassInfoImpl.getProperties(ClassInfoImpl.java:263)
at com.sun.xml.bind.v2.model.impl.RuntimeClassInfoImpl.getProperties(RuntimeClassInfoImpl.java:141)
at com.sun.xml.bind.v2.model.impl.ModelBuilder.getClassInfo(ModelBuilder.java:190)
at com.sun.xml.bind.v2.model.impl.RuntimeModelBuilder.getClassInfo(RuntimeModelBuilder.java:60)
at com.sun.xml.bind.v2.model.impl.RuntimeModelBuilder.getClassInfo(RuntimeModelBuilder.java:42)
at com.sun.xml.bind.v2.model.impl.ModelBuilder.getClassInfo(ModelBuilder.java:156)
at com.sun.xml.bind.v2.model.impl.RuntimeModelBuilder.getClassInfo(RuntimeModelBuilder.java:55)
at com.sun.xml.bind.v2.model.impl.RuntimeModelBuilder.getClassInfo(RuntimeModelBuilder.java:42)
at com.sun.xml.bind.v2.model.impl.ModelBuilder.getTypeInfo(ModelBuilder.java:262)
at com.sun.xml.bind.v2.model.impl.ModelBuilder.getTypeInfo(ModelBuilder.java:277)
at com.sun.xml.bind.v2.runtime.JAXBContextImpl.getTypeInfoSet(JAXBContextImpl.java:416)
at com.sun.xml.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:270)
at com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:103)
at com.sun.xml.bind.api.JAXBRIContext.newInstance(JAXBRIContext.java:89)
at com.sun.xml.ws.model.AbstractSEIModelImpl$1.run(AbstractSEIModelImpl.java:132)
at com.sun.xml.ws.model.AbstractSEIModelImpl$1.run(AbstractSEIModelImpl.java:131)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.xml.ws.model.AbstractSEIModelImpl.createJAXBContext(AbstractSEIModelImpl.java:130)
at com.sun.xml.ws.model.AbstractSEIModelImpl.postProcess(AbstractSEIModelImpl.java:69)
at com.sun.xml.ws.model.RuntimeModeler.buildRuntimeModel(RuntimeModeler.java:230)
at com.sun.tools.ws.wscompile.WsgenTool.buildModel(WsgenTool.java:201)
at com.sun.tools.ws.wscompile.WsgenTool.run(WsgenTool.java:102)
at com.sun.tools.ws.util.WSToolsObjectFactoryImpl.wsgen(WSToolsObjectFactoryImpl.java:47)
at com.sun.tools.ws.spi.WSToolsObjectFactory.wsgen(WSToolsObjectFactory.java:93)
at com.sun.enterprise.webservice.WsUtil.runWsGen(WsUtil.java:1840)
at com.sun.enterprise.webservice.WsUtil.genWSInfo(WsUtil.java:2237)
at com.sun.enterprise.deployment.backend.AppDeployerBase.loadDescriptors(AppDeployerBase.java:359)
at com.sun.enterprise.deployment.backend.AppDeployer.deploy(AppDeployer.java:226)
at com.sun.enterprise.deployment.backend.AppDeployer.doRequestFinish(AppDeployer.java:148)
at com.sun.enterprise.deployment.phasing.J2EECPhase.runPhase(J2EECPhase.java:191)
at com.sun.enterprise.deployment.phasing.DeploymentPhase.executePhase(DeploymentPhase.java:108)
at com.sun.enterprise.deployment.phasing.PEDeploymentService.executePhases(PEDeploymentService.java:905)
at com.sun.enterprise.deployment.phasing.PEDeploymentService.deploy(PEDeploymentService.java:279)
at com.sun.enterprise.deployment.phasing.PEDeploymentService.deploy(PEDeploymentService.java:774)
at com.sun.enterprise.management.deploy.DeployThread.deploy(DeployThread.java:187)
at com.sun.enterprise.management.deploy.DeployThread.run(DeployThread.java:223)
Jun 20, 2007 10:52:43 AM com.sun.enterprise.deployment.phasing.PEDeploymentService$AuditInfo reportEnd
INFO: Deployment by user Unknown of module MyTestEar (type=Application) failed, elapsed time 4260 ms

Anyway I hope these two pieces of information help. Please let me know if there is anything I can do to help test fixes or work arounds.

-Geoff

[Author]

Posts