openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Prud'hommeaux <>
Subject Re: [jira] Updated: (OPENJPA-148) Parsing exception while using an "exploded" archive
Date Fri, 04 May 2007 09:31:15 GMT

This part of the patch fixes what is clearly a bug with scanning  

-                    scan(new FileMetaDataIterator(dir,  
+                    //TODO should this call setStoreDirectory(file)????
+                    scan(new FileMetaDataIterator(file,  

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 
+                    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:
>>      [ 
>> 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: 
>>> 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.

View raw message