Deployment of EAR with exploded JAR failing since b72 with SaxParser Premature end of file error

[glassfishrobot]

If the ejb.jar is packed in an EAR as a directory, the deployment fails with:

Caused by: org.xml.sax.SAXParseException: Premature end of file. at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseExcept ion(ErrorHandlerWrapper.java:195) at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.fatalError(ErrorHand lerWrapper.java:174) at com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorRep orter.java:388) at com.sun.org.apache.xerces.internal.impl.XMLScanner.reportFatalError(XMLScanner.j ava:1414) at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$PrologDriver.next (XMLDocumentScannerImpl.java:1059) at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentS cannerImpl.java:648) at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocum entScannerImpl.java:140) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocum ent(XMLDocumentFragmentScannerImpl.java:510) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configu ration.java:807) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configu ration.java:737) at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:107) at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXPa rser.java:1205) at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXPar serImpl.java:522) at javax.xml.parsers.SAXParser.parse(SAXParser.java:395) at com.sun.enterprise.deployment.io.DeploymentDescriptorFile.read(DeploymentDescrip torFile.java:298)

I will try to attach a sample EAR.

Environment

Operating System: Windows XP Platform: All

Affected Versions

[3.1]

[glassfishrobot]

• Issue Imported From: https://github.com/javaee/glassfish/issues/11294
• Original Issue Raised By:@glassfishrobot
• Original Issue Assigned To: @tjquinno
• Original Issue Closed By:@glassfishrobot

[glassfishrobot]

@glassfishrobot Commented matthiasfraass said: Created an attachment (id=4088) Failing EAR

[glassfishrobot]

@glassfishrobot Commented matthiasfraass said: The attached EAR is a modified EAR from this article http://www.devx.com/ibm/Article/16365 -> download-link: http://www- 128.ibm.com/developerworks/views/download.jsp? contentid=14260&filename=HelloWorldApplicationDeveloper.zip&method=http&locale=w orldwide

I modified it so that HelloWorld.ear\HelloWorldEJBProject.jar -> HelloWorld.ear\HelloWorldEJBProject_jar

It deploys fine in b71, but fails from b72 on, including b74.

[glassfishrobot]

@glassfishrobot Commented @honghzzhang said: (v3 is just released today, so I am updating the release version to v3.1)

So were you doing a partial directory deployment with only ejb sub module being an exploded directory? If so, this is not something we officially support. I understand this has worked before and now not working, I will take a look but just wanted to tell you this is not something in the official support list (therefore lowered the priority).

[glassfishrobot]

@glassfishrobot Commented matthiasfraass said: Yes, it is a partial directory deployment.

I thought that'd be supported as it was recommended to me as a workaround during the bugfixing of 10660.

[glassfishrobot]

@glassfishrobot Commented @honghzzhang said: The directory deployment I was suggesting earlier is the full directory deployment, with the ear top level expanded and all the component sub modules expanded. I probably was not very clear as I just assumed you knew that's the only officially supported directory deployment way

[glassfishrobot]

@glassfishrobot Commented @honghzzhang said: Created an attachment (id=4089) the simple ear I created in a similar way which deployed and ran ok

[glassfishrobot]

@glassfishrobot Commented @honghzzhang said: I just tried this with a simple app (with a war and ejb jar). I expanded the ejb jar to a directory and modified application.xml accordingly and then rejarred the ear. The ear could deploy and run without any problem. I have attached the simple ear I tried.

So it might be something specific with your particular application. I will look next.

[glassfishrobot]

@glassfishrobot Commented @honghzzhang said: I actually was able to deploy your application without getting the parser error you got (I did get some warnings in the log: the war file manifest was referencing the ejb jar in the jar form and now that jar is not found as the jar is expanded).

I am on Ubuntu/X86.

When you say things worked ok with v71, did you try with the exact same application or some other application but packaged similarly?

[glassfishrobot]

@glassfishrobot Commented matthiasfraass said: Strange.. I tried both attached EARs again, and both give me the "Premature end of file" error with v3 final.

It's on WinXP, though.

[glassfishrobot]

@glassfishrobot Commented matthiasfraass said: Tested on Ubuntu/x86 + JVM 1.6.0_17 -> both EARs deploy fine!

So it might be a encoding/format issue...

[glassfishrobot]

@glassfishrobot Commented @honghzzhang said: Thanks for trying on the linux platform, so now we know it's a platform specific thing.

Tim: when you get a chance, maybe you could try on your windows box to see what you can find..

[glassfishrobot]

@glassfishrobot Commented matthiasfraass said: Another observation: I startet GF v3 final in debug mode and set the debugger to stop on SaxParseException. Then I started deployment of ss_test.ear.

When the breakpoint fired up, I saw that it was trying to read the file glassfish/domains/domain1/applications/ss_test/stateless-simpleEjb_jar/META- INF/ejb-jar.xml. It was there but empty: zero byte length. The same applies to the sun-ejb.jar and all class-files of stateless-simpleEjb_jar.

So the problem might not be a SAXParser or ejb-jar.xml problem, but rather a unpacking issue?

[glassfishrobot]

@glassfishrobot Commented @honghzzhang said: Thanks for the additional information, I assume this is on the windows (as these files seem ok on my linux box)?

[glassfishrobot]

@glassfishrobot Commented matthiasfraass said: Yes, that is on Windows.

[glassfishrobot]

@glassfishrobot Commented @honghzzhang said: assign to tim to take a look at the windows

[glassfishrobot]

@glassfishrobot Commented @tjquinno said: I can reproduce the problem on Windows. Continuing to investigate.

[glassfishrobot]

@glassfishrobot Commented @tjquinno said: Fix checked in.

The problem was that the EJB descriptor was zero-length, which caused the parsing error. And the file was zero length because:

• On Windows, attempts to rewrite an existing and open file do not work.

• In this use case, a submodule was packaged inside an EAR as a directory (not a JAR) and the directory name was the same as the name which GlassFish uses when it expands submodules in an EAR into directories...

• ...which means that GlassFish was trying to overwrite each file in the submodule with its own content. This works OK on non-Windows systems but not on Windows.

This fix basically bypasses the expansion of a submodule if it was packaged into the EAR as a directory (in which case the expansion of the EAR itself has already created the submodule directory correctly).

Author: tjquinn Date: 2010-02-04 19:18:55+0000 New Revision: 35555

Modified:

trunk/v3/deployment/common/src/main/resources/com/sun/logging/enterprise/system/tools/deployment/LogStrings.properties

trunk/v3/deployment/javaee-full/src/main/java/org/glassfish/javaee/full/deployment/EarHandler.java

[glassfishrobot]

@glassfishrobot Commented File: HelloWorld.ear Attached By: matthiasfraass

[glassfishrobot]

@glassfishrobot Commented File: ss_test.ear Attached By: @honghzzhang

[glassfishrobot]

@glassfishrobot Commented This issue was imported from java.net JIRA GLASSFISH-11294

[glassfishrobot]

@glassfishrobot Commented Reported by matthiasfraass

[glassfishrobot]

@glassfishrobot Commented Marked as fixed on Thursday, May 20th 2010, 3:48:38 pm