Community
Participate
Working Groups
Created attachment 163014 [details] Error details and possible workaround There is an error in the org.eclipse.persistence.internal.jpa.deployment.ArchiveFactoryImpl#createArchive method causing a FileNotFoundException to be thrown. ArchiveFactoryImpl is unable to resolve .jar's on a remote Windows drive as on line 73 the path is passed into a java.io.File which results in the first backslash ('\') being ommited. See attachment the stacktrace and possible rough workaround reusing a the 'jar:' URI approach. The exact build version is: 2.0.0.v20091127-r5931 BTW using a new implementation of ArchiveFactory was not an option for me due to the way spring loads it's classes via a SimpleThrowawayClassLoader resulting in ClassLoader Class missmatches.
Setting target and priority. See the following page for details of the meanings of these fields: http://wiki.eclipse.org/EclipseLink/Development/Bugs/Guidelines
>taking a quick look at this one flagged critical, no milestone set
>Dan, Hi, could you post the relevant part of your persistence.xml Also are you deploying as EE in an EAR - as SE classloading is different. This issue occurs whether the jar is remote or local - it involves absolute as opposed to relative (to the persistenc.xml location) file paths. The <jar-file> element uses a relative path to a jar inside the EAR, otherwise something like <jar-file>file://c:/opt/entities.jar</jar-file> fails with the same Caused by: java.io.FileNotFoundException: \opt\entities.jar (The system cannot find the path specified) .. at org.eclipse.persistence.internal.jpa.deployment.ArchiveFactoryImpl.createArchive(ArchiveFactoryImpl.java:93) >The FNFE is not good and should throw a warning on the absolute file format instead of attempting to load the file >Your patch to try the jar: URI format would normally be classified as an enhancement request As normally the jar-file element is limited to jars inside the EAR (for security) However, the JarFileArchive class needs some exception handling, deprecation, documentation changes. >I will verify this change in an EAR that references a JAR outside the server This will need to be passed by a good review - as it changes functionality and affects all server especially WebSphere and NetWeaver in bug # 295124
Hi Micheal, If you'd asked me 6 months ago I could have supplied this. Unfortunately, I'm now working for a different client. As for runtime environment, if I remember correctly it was in a bespoke process which was using Spring as a container so is was using an EE style, but not via an EAR. Sounds strange I know, but I wasn't responsible for that gem. :oP
>understood - thank you for raising the details in the bug.
>references https://fisheye2.atlassian.com/changelog/eclipselink/?cs=5415 https://fisheye2.atlassian.com/changelog/eclipselink/?cs=5810
>Changes in bug# 311234 will be significant https://fisheye2.atlassian.com/changelog/eclipselink/?cs=7130
The Eclipselink project has moved to Github: https://github.com/eclipse-ee4j/eclipselink
