David-
This part of the patch fixes what is clearly a bug with scanning
directories:
- scan(new FileMetaDataIterator(dir,
newMetaDataFilter()),
+ //TODO should this call setStoreDirectory(file)????
+ scan(new FileMetaDataIterator(file,
newMetaDataFilter()),
I've gone ahead and applied that part of the patch. However, I don't
know what this part is expected to do:
+ if ("file".equals(url.getProtocol())) {
+ File file = new File(url.getFile
()).getAbsoluteFile();
+ if (files.contains(file)) {
+ continue;
+ }
+ }
If you explain this part, I'll also apply it. For the time being,
though, I'm marking the issue closed. Let me know if Geronimo works
once you have tested with the partial patch applied. If it doesn't,
please re-open the issue.
On May 3, 2007, at 11:54 PM, David Jencks wrote:
I'd really appreciate it if a committer could take a look at this
patch fairly soon and provide feedback or apply it. I don't think
geronimo can deploy persistence units in wars without it or its
equivalent.
Of course I'd also like to know if it helps EasyBeans :-)
thanks
david jencks
On May 2, 2007, at 3:07 PM, David Jencks (JIRA) wrote:
[ https://issues.apache.org/jira/browse/OPENJPA-148?
page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David Jencks updated OPENJPA-148:
---------------------------------
Attachment: OPENJPA-148.patch
This patch fixes the issue for me in the geronimo integration.
There are 2 changes:
1. there's an apparent bug in the treatment of a directory.
There's a var "dir" which is AFAICT never set that used to be
scanned. I changed it to scan the directory under consideration,
which does find the persistent classes in the dir. I don't know
if dir should be set to one of the scanned directories.
2. In the geronimo environment, the same locations show up in both
the files and urls lists. I haven't figured out exactly why.
However, this lets the second part of the fix work, which is to
ignore urls that point to a file that has already been scanned. I
think this is probably OK since non-file urls generally can't be
scanned like a directory.
I'll be happy to work on improvements given advice on problems
with this patch, but this patch would IMO be a good start.
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.
