[jira] Commented: (OPENJPA-148) Parsing exception while using an "exploded" archive
[ https://issues.apache.org/jira/browse/OPENJPA-148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12497575 ] Marc Prud'hommeaux commented on OPENJPA-148: I've gone ahead and applied OPENJPA-148-2.patch. If this works for you, please go ahead and mark this issue as resolved. > Parsing exception while using an "exploded" archive > --- > > Key: OPENJPA-148 > URL: https://issues.apache.org/jira/browse/OPENJPA-148 > Project: OpenJPA > Issue Type: Bug > Components: jpa > Environment: Sun JDK 5.0 / EasyBeans / OpenJPA snapshot 0.9.7 >Reporter: Florent BENOIT >Priority: Minor > Fix For: 0.9.8 > > Attachments: debug_traces_directorymode.txt, > debug_traces_filemode_working.txt, OPENJPA-148-2.patch, OPENJPA-148.patch, > stacktrace-error.txt, steps.txt > > > This happens when using OpenJPA as persistence provider for the EasyBeans > ObjectWeb container. > The error is happening with "exploded" archive. > Exploded means that there is a directory, named "entitybean.jar" with a > folder META-INF which contains a file named persistence.xml, and other > directories/files for the classes. > It seems that when using this mode, OpenJPA is trying to parse the directory > inputstream (which is failing). > This exception is not occuring if a jar file is used instead of the > "exploded" mode, but the exploded mode is the default mode for EasyBeans. > Note also that this exception don't occur by using Hibernate Entity Manager > or Oracle TopLink Essentials as persistence provider. > I will attach to this issue a stack trace (with the exploded directory) which > fails and at the end with a jar file (which work) > And 4 steps used to reproduce this problem -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (OPENJPA-148) Parsing exception while using an "exploded" archive
Just one note (this problem caused us a lot of headaches in GlassFish): I'm not
sure if url.getFile() handles spaces in the url correctly. If it doesn't, our
solution was to use 'new File(url.toURI())'.
-marina
David Jencks (JIRA) wrote:
[ https://issues.apache.org/jira/browse/OPENJPA-148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493730 ]
David Jencks commented on OPENJPA-148:
--
Marc did not apply this part of the patch, which was actually the crucial part
to get this to work for geronimo :-). As I noted before this may well not be
the best way to solve the problem, its only virtue is that it works:
+if ("file".equals(url.getProtocol())) {
+File file = new File(url.getFile()).getAbsoluteFile();
+if (files.contains(file)) {
+continue;
+}
+}
For reasons that are not entirely clear to me yet, the war WEB-INF/classes
directory is showing up both in the files list (where it is processed
correctly) and the urls list where it is causing an error since the code tries
to treat it as an xml file. The patch excerpt above is a bit of a hack but it
checks each url to see if it matches a file in the files list and if so skips
it. In particular the directory WEB-INF/classes is matched so it is skipped,
thus sidestepping the problem.
IMO it would be better to avoid duplicating locations in the files and urls
list but I haven't figured out how to make that happen yet. I don't see much
harm in this patch in any case since AFAICT there is never a reason to process
a location twice.
Parsing exception while using an "exploded" archive
---
Key: OPENJPA-148
URL: https://issues.apache.org/jira/browse/OPENJPA-148
Project: OpenJPA
Issue Type: Bug
Components: jpa
Environment: Sun JDK 5.0 / EasyBeans / OpenJPA snapshot 0.9.7
Reporter: Florent BENOIT
Priority: Minor
Fix For: 0.9.8
Attachments: debug_traces_directorymode.txt,
debug_traces_filemode_working.txt, OPENJPA-148.patch, stacktrace-error.txt,
steps.txt
This happens when using OpenJPA as persistence provider for the EasyBeans
ObjectWeb container.
The error is happening with "exploded" archive.
Exploded means that there is a directory, named "entitybean.jar" with a folder
META-INF which contains a file named persistence.xml, and other directories/files for the
classes.
It seems that when using this mode, OpenJPA is trying to parse the directory
inputstream (which is failing).
This exception is not occuring if a jar file is used instead of the "exploded"
mode, but the exploded mode is the default mode for EasyBeans.
Note also that this exception don't occur by using Hibernate Entity Manager or
Oracle TopLink Essentials as persistence provider.
I will attach to this issue a stack trace (with the exploded directory) which
fails and at the end with a jar file (which work)
And 4 steps used to reproduce this problem
[jira] Commented: (OPENJPA-148) Parsing exception while using an "exploded" archive
[ https://issues.apache.org/jira/browse/OPENJPA-148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493746 ] David Jencks commented on OPENJPA-148: -- Craig said... > ';' separated string >> list of files + list of urls. I haven't figured out exactly what is going on here, and any comments on the codes' purpose would be welcome :-) > Parsing exception while using an "exploded" archive > --- > > Key: OPENJPA-148 > URL: https://issues.apache.org/jira/browse/OPENJPA-148 > Project: OpenJPA > Issue Type: Bug > Components: jpa > Environment: Sun JDK 5.0 / EasyBeans / OpenJPA snapshot 0.9.7 >Reporter: Florent BENOIT >Priority: Minor > Fix For: 0.9.8 > > Attachments: debug_traces_directorymode.txt, > debug_traces_filemode_working.txt, OPENJPA-148.patch, stacktrace-error.txt, > steps.txt > > > This happens when using OpenJPA as persistence provider for the EasyBeans > ObjectWeb container. > The error is happening with "exploded" archive. > Exploded means that there is a directory, named "entitybean.jar" with a > folder META-INF which contains a file named persistence.xml, and other > directories/files for the classes. > It seems that when using this mode, OpenJPA is trying to parse the directory > inputstream (which is failing). > This exception is not occuring if a jar file is used instead of the > "exploded" mode, but the exploded mode is the default mode for EasyBeans. > Note also that this exception don't occur by using Hibernate Entity Manager > or Oracle TopLink Essentials as persistence provider. > I will attach to this issue a stack trace (with the exploded directory) which > fails and at the end with a jar file (which work) > And 4 steps used to reproduce this problem -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-148) Parsing exception while using an "exploded" archive
[ https://issues.apache.org/jira/browse/OPENJPA-148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493739 ] Florent BENOIT commented on OPENJPA-148: I tested with the last revision 535321 (that includes the second commit of this patch) and the deployment works fine on EasyBeans when using exploded archive. Thanks. > Parsing exception while using an "exploded" archive > --- > > Key: OPENJPA-148 > URL: https://issues.apache.org/jira/browse/OPENJPA-148 > Project: OpenJPA > Issue Type: Bug > Components: jpa > Environment: Sun JDK 5.0 / EasyBeans / OpenJPA snapshot 0.9.7 >Reporter: Florent BENOIT >Priority: Minor > Fix For: 0.9.8 > > Attachments: debug_traces_directorymode.txt, > debug_traces_filemode_working.txt, OPENJPA-148.patch, stacktrace-error.txt, > steps.txt > > > This happens when using OpenJPA as persistence provider for the EasyBeans > ObjectWeb container. > The error is happening with "exploded" archive. > Exploded means that there is a directory, named "entitybean.jar" with a > folder META-INF which contains a file named persistence.xml, and other > directories/files for the classes. > It seems that when using this mode, OpenJPA is trying to parse the directory > inputstream (which is failing). > This exception is not occuring if a jar file is used instead of the > "exploded" mode, but the exploded mode is the default mode for EasyBeans. > Note also that this exception don't occur by using Hibernate Entity Manager > or Oracle TopLink Essentials as persistence provider. > I will attach to this issue a stack trace (with the exploded directory) which > fails and at the end with a jar file (which work) > And 4 steps used to reproduce this problem -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-148) Parsing exception while using an "exploded" archive
[ https://issues.apache.org/jira/browse/OPENJPA-148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493736 ] Craig Russell commented on OPENJPA-148: --- Just thinking a bit outside the box here. Is it possibly a bug that the classes directory is being presented as a file? And perhaps defensively OpenJPA might check to see if the file is actually a directory and then just ignore it. i.e. if (file.isDirectory()) continue; But I'd like to see a bit more investigation into whether the behavior of the container is correct. It does seem odd that the container is expecting the provider to remove duplicate items from the deployment artifact. > Parsing exception while using an "exploded" archive > --- > > Key: OPENJPA-148 > URL: https://issues.apache.org/jira/browse/OPENJPA-148 > Project: OpenJPA > Issue Type: Bug > Components: jpa > Environment: Sun JDK 5.0 / EasyBeans / OpenJPA snapshot 0.9.7 >Reporter: Florent BENOIT >Priority: Minor > Fix For: 0.9.8 > > Attachments: debug_traces_directorymode.txt, > debug_traces_filemode_working.txt, OPENJPA-148.patch, stacktrace-error.txt, > steps.txt > > > This happens when using OpenJPA as persistence provider for the EasyBeans > ObjectWeb container. > The error is happening with "exploded" archive. > Exploded means that there is a directory, named "entitybean.jar" with a > folder META-INF which contains a file named persistence.xml, and other > directories/files for the classes. > It seems that when using this mode, OpenJPA is trying to parse the directory > inputstream (which is failing). > This exception is not occuring if a jar file is used instead of the > "exploded" mode, but the exploded mode is the default mode for EasyBeans. > Note also that this exception don't occur by using Hibernate Entity Manager > or Oracle TopLink Essentials as persistence provider. > I will attach to this issue a stack trace (with the exploded directory) which > fails and at the end with a jar file (which work) > And 4 steps used to reproduce this problem -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-148) Parsing exception while using an "exploded" archive
[ https://issues.apache.org/jira/browse/OPENJPA-148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493735 ] Marc Prud'hommeaux commented on OPENJPA-148: I understand the reason for that part now. I've applied and committed the rest of the patch. Please comment in this issue if you still experience the problem with this patch. > Parsing exception while using an "exploded" archive > --- > > Key: OPENJPA-148 > URL: https://issues.apache.org/jira/browse/OPENJPA-148 > Project: OpenJPA > Issue Type: Bug > Components: jpa > Environment: Sun JDK 5.0 / EasyBeans / OpenJPA snapshot 0.9.7 >Reporter: Florent BENOIT >Priority: Minor > Fix For: 0.9.8 > > Attachments: debug_traces_directorymode.txt, > debug_traces_filemode_working.txt, OPENJPA-148.patch, stacktrace-error.txt, > steps.txt > > > This happens when using OpenJPA as persistence provider for the EasyBeans > ObjectWeb container. > The error is happening with "exploded" archive. > Exploded means that there is a directory, named "entitybean.jar" with a > folder META-INF which contains a file named persistence.xml, and other > directories/files for the classes. > It seems that when using this mode, OpenJPA is trying to parse the directory > inputstream (which is failing). > This exception is not occuring if a jar file is used instead of the > "exploded" mode, but the exploded mode is the default mode for EasyBeans. > Note also that this exception don't occur by using Hibernate Entity Manager > or Oracle TopLink Essentials as persistence provider. > I will attach to this issue a stack trace (with the exploded directory) which > fails and at the end with a jar file (which work) > And 4 steps used to reproduce this problem -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-148) Parsing exception while using an "exploded" archive
[
https://issues.apache.org/jira/browse/OPENJPA-148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493730
]
David Jencks commented on OPENJPA-148:
--
Marc did not apply this part of the patch, which was actually the crucial part
to get this to work for geronimo :-). As I noted before this may well not be
the best way to solve the problem, its only virtue is that it works:
+if ("file".equals(url.getProtocol())) {
+File file = new File(url.getFile()).getAbsoluteFile();
+if (files.contains(file)) {
+continue;
+}
+}
For reasons that are not entirely clear to me yet, the war WEB-INF/classes
directory is showing up both in the files list (where it is processed
correctly) and the urls list where it is causing an error since the code tries
to treat it as an xml file. The patch excerpt above is a bit of a hack but it
checks each url to see if it matches a file in the files list and if so skips
it. In particular the directory WEB-INF/classes is matched so it is skipped,
thus sidestepping the problem.
IMO it would be better to avoid duplicating locations in the files and urls
list but I haven't figured out how to make that happen yet. I don't see much
harm in this patch in any case since AFAICT there is never a reason to process
a location twice.
> Parsing exception while using an "exploded" archive
> ---
>
> Key: OPENJPA-148
> URL: https://issues.apache.org/jira/browse/OPENJPA-148
> Project: OpenJPA
> Issue Type: Bug
> Components: jpa
> Environment: Sun JDK 5.0 / EasyBeans / OpenJPA snapshot 0.9.7
>Reporter: Florent BENOIT
>Priority: Minor
> Fix For: 0.9.8
>
> Attachments: debug_traces_directorymode.txt,
> debug_traces_filemode_working.txt, OPENJPA-148.patch, stacktrace-error.txt,
> steps.txt
>
>
> This happens when using OpenJPA as persistence provider for the EasyBeans
> ObjectWeb container.
> The error is happening with "exploded" archive.
> Exploded means that there is a directory, named "entitybean.jar" with a
> folder META-INF which contains a file named persistence.xml, and other
> directories/files for the classes.
> It seems that when using this mode, OpenJPA is trying to parse the directory
> inputstream (which is failing).
> This exception is not occuring if a jar file is used instead of the
> "exploded" mode, but the exploded mode is the default mode for EasyBeans.
> Note also that this exception don't occur by using Hibernate Entity Manager
> or Oracle TopLink Essentials as persistence provider.
> I will attach to this issue a stack trace (with the exploded directory) which
> fails and at the end with a jar file (which work)
> And 4 steps used to reproduce this problem
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-148) Parsing exception while using an "exploded" archive
[
https://issues.apache.org/jira/browse/OPENJPA-148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12473942
]
Florent BENOIT commented on OPENJPA-148:
Here is a follow up for explaining the process that OpenJPA is using on
exploded jar files:
The PersistenceUnitInfo object build by the EJB3 container(EasyBeans in my
testcase) is sent to OpenJPA.
Then, in the method toOpenJPAProperties of
org.apache.openjpa.persistence.PersistenceUnitInfoImpl class
The getPersistenceUnitRootUrl() URL (which is the directory URL
file:/home/florent/workspace/easybeans/ejb3s/entitybean.jar/) is transformed
into /home/florent/workspace/easybeans/ejb3s/entitybean.jar/ as it is a
"file:" URL
Then, the getJarFileUrls() is returning the same URL
(file:/home/florent/workspace/easybeans/ejb3s/entitybean.jar/)
This URL is an exploded JAR file URL which is valid for this method as said in
the specification
"Returns a list of URLs for the jar files or exploded jar file directories
that the persistence provider [...]"
(It has been clarified between the proposed final specification and the final
specification)
The PersistenceUnitInfoImpl class is then transforming these two URLs into:
- "Files" property with the value
/home/florent/workspace/easybeans/ejb3s/entitybean.jar/
- "URLs" property with the value
file:/home/florent/workspace/easybeans/ejb3s/entitybean.jar/
Then, these values will be analyzed in parsePersistentTypeNames(ClassLoader
loader) method of
the class org.apache.openjpa.meta.AbstractCFMetaDataFactory
1/ First, the "Files" property is analyzed:
As /home/florent/workspace/easybeans/ejb3s/entitybean.jar/ is a directory, it
goes in:
if (file.isDirectory()) {
if (log.isTraceEnabled())
log.trace(_loc.get("scanning-directory", file));
scan(new FileMetaDataIterator(dir, newMetaDataFilter()),
cparser, names, true, file);
}
which found...nothing. (I have done another test with a file for the
PersistenceUnitRootUrl
(and not a directory) and in this case the scan of the file finds the Entity
class while it doesn't
find the entity class in directory mode).
Also here, dir is null, if dir = file, it finds the entity class.
The corresponding debug trace is:
[TRACE] MetaData - Scanning directory
"/home/florent/workspace/easybeans/ejb3s/entitybean.jar" for persistent types.
2/ Then, the "URLs" property is analyzed:
It's not a .jar file so the case "else if (url.getPath().endsWith(".jar"))" is
not used and it fallbacks
in the default case:
} else {
if (log.isTraceEnabled())
log.trace(_loc.get("scanning-url", url));
clss = cparser.parseTypeNames(new URLMetaDataIterator(url));
if (log.isTraceEnabled())
log.trace(_loc.get("scan-found-names", clss, url));
names.addAll(Arrays.asList(clss));
mapPersistentTypeNames(url, clss);
}
And mapPersistentTypeNames method do the following:
_unparsed.add((URL) rsrc);
so, the URL which is referencing an exploded jar is considered as an unparsed
URL from now.
The corresponding traces are:
[TRACE] MetaData - Scanning URL
"file:/home/florent/workspace/easybeans/ejb3s/entitybean.jar/" for persistent
types.
[TRACE] MetaData - Scan of
"file:/home/florent/workspace/easybeans/ejb3s/entitybean.jar/" found persistent
types [Ljava.lang.String;@14c7cd.
[TRACE] MetaData - Mapping resource location
"file:/home/florent/workspace/easybeans/ejb3s/entitybean.jar/" to persistent
types "[]".
(with [Ljava.lang.String;@14c7cd. being an empty array.)
When a class needs to be loaded by the load(Class cls, int mode, ClassLoader
envLoader) method of org.apache.openjpa.persistence.PersistenceMetaDataFactory
class, there is a check on the _unparsed attribute.
And in this case, it tries to parse the URL as an XML file:
for (URL url : _unparsed)
parseXML(url, cls, mode, envLoader);
And we can imagine the result of parsing a directory as an XML file.
The result is:
[WARN] Enhance - An exception was thrown while attempting to perform class file
transformation on
"org/objectweb/easybeans/examples/entitybean/SessionFacadeRemote":
<<0|false|0.9.7-incubating-SNAPSHOT> org.apache.openjpa.util.GeneralException:
org.xml.sax.SAXException:
file:/home/florent/workspace/easybeans/ejb3s/entitybean.jar/ [Location: Line:
1, C: 1]: org.xml.sax.SAXParseException: Content is not allowed in
prolog.><0|false|0.9.7-incubating-SNAPSHOT>
org.apache.openjpa.util.GeneralException: org.xml.sax.SAXException:
file:/home/florent/workspace/easybeans/ejb3s/entitybean.jar/ [Location: Line:
1, C: 1]: org.xml.sax.SAXParseException: Content is not allowed in prolog.
at
org.apache.openjpa.persistence.PersistenceMetaDat
