The fix goes like this:
if ( filePart.startsWith( "/" ) || new File(url.getFile()).isAbsolute() ) {
// the URL is already an absolute form
return url;
}
The reason why it works on Linux/Macs is that absolute paths start with "/".
With this fix works on Windows too, but I wonder if we shouldn't have
it like this instead:
if ( new File(url.getFile()).isAbsolute() ) {
// the URL is already an absolute form
return url;
}
I think this should work on any OS, right?
Vlad
On Thu, Mar 10, 2016 at 9:18 AM, Vlad Mihalcea <mihalcea.v...@gmail.com>
wrote:
> Hi,
>
> I managed to find what caused this test to start failing. The reason is
> this commit:
>
> Commit: 5c77f279afaecb505f7a22bfa05c172b493096bd [5c77f27]
> Parents: 8670b4211e
> Author: Steve Ebersole <st...@hibernate.org>
> Date: Tuesday, January 12, 2016 11:21:54 PM
> Commit Date: Tuesday, January 12, 2016 11:22:19 PM
> Labels: HEAD
> HHH-4161 - persistence.xml <jar-file> not following JSR220 spec
>
> This commit was done for this issue
> https://hibernate.atlassian.net/browse/HHH-4161.
>
> The problem is that StandardArchiveDescriptorFactory#adjustJarFileEntryUrl
> applies even when we don't deal with relative paths.
>
> In the context of the PackagedEntityManagerTest#testExternalJar test, we
> have a PAR whose persistence.xml uses a jar-file that's declared with an
> absolute path
> (file:D:/Vlad/Work/GitHub/hibernate-orm/hibernate-entitymanager/target/packages/externaljar.jar),
> and the jar resides next to the PAR (it's not embedded).
>
> If I disable the check,
> StandardArchiveDescriptorFactory#adjustJarFileEntryUrl returns the URL as
> is
> (file:D:/Vlad/Work/GitHub/hibernate-orm/hibernate-entitymanager/target/packages/externaljar.jar),
> which is passed to the ArchiveDescriptor.
>
> But the check is enabled because the URL has a file protocol:
>
> final boolean check = StringHelper.isEmpty( protocol )
> || "file".equals( protocol )
> || "vfszip".equals( protocol )
> || "vfsfile".equals( protocol );
>
> So, StandardArchiveDescriptorFactory#adjustJarFileEntryUrl will return
> this instead:
>
>
> jar:file://D:\Vlad\Work\GitHub\hibernate-orm\hibernate-entitymanager\target\packages\explicitpar.par!/D:/Vlad/Work/GitHub/hibernate-orm/hibernate-entitymanager/target/packages/externaljar.jar
>
> And, the jar will not be located because this is not an embedded jar use
> case.
>
> I wonder how is it working on Linux and it only fails on Windows?
>
> Can someone run this test and check what's the return value from the
> StandardArchiveDescriptorFactory#adjustJarFileEntryUrl method when running
> the PackagedEntityManagerTest#testExternalJar test?
>
> Thanks,
> Vlad
>
>
> On Thu, Mar 10, 2016 at 12:49 AM, Steve Ebersole <st...@hibernate.org>
> wrote:
>
>> A PAR is just an archive with a META-INF/persistence.xml file in it. The
>> JPA spec does cover this. The extension is irrelevant.
>>
>> On Wed, Mar 9, 2016 at 4:08 PM Sanne Grinovero <sa...@hibernate.org>
>> wrote:
>>
>>> I remember JBoss had "HAR" deployments to package Hibernate models and
>>> PU definitions.. as far as I know this was a JBoss only thing, it
>>> wouldn't surprise me if other app servers experimented with similar
>>> non-standardized archives.
>>>
>>> https://docs.jboss.org/jbossas/jboss4guide/r3/html/ch13.html
>>>
>>> On 9 March 2016 at 18:39, Vlad Mihalcea <mihalcea.v...@gmail.com> wrote:
>>> > Hi,
>>> >
>>> > The part is backslashes comes from the absolute path set by Gradle when
>>> > supplying the module OS folder.
>>> > The right part containing slashes is the one set in persistence.xml.
>>> > I'll try to replace backslashes with slashes and see how it goes.
>>> >
>>> > I was curious if people use the jar-file with absolute paths because
>>> the
>>> > JPA spec only implies it in the context of relative paths inside an
>>> EAR or
>>> > WAR.
>>> > As for PAR, I guess that was included in some JPA 1.0 draft but it got
>>> > rejected in the end, right?
>>> >
>>> > Vlad
>>> >
>>> >
>>> >
>>> >
>>> > On Wed, Mar 9, 2016 at 6:39 PM, Emmanuel Bernard <
>>> emman...@hibernate.org>
>>> > wrote:
>>> >
>>> >> We usually strive on having functionalities work on both Java EE and
>>> >> Java SE.
>>> >> you example though shows a mix of forward and backslash in your
>>> >> <jar-file>, is that expected ?
>>> >>
>>> >> Emmanuel
>>> >>
>>> >> On Wed 2016-03-09 17:05, Vlad Mihalcea wrote:
>>> >> > Hi,
>>> >> >
>>> >> > I have two tests in the PackagedEntityManagerTest unit test that
>>> fail on
>>> >> my
>>> >> > machine, but work just fine for everybody else.
>>> >> > It could be an OS thing or not, but during the check, I found hat
>>> we are
>>> >> > testing against an use case that is not found in the JPA spec.
>>> >> >
>>> >> > The testExternalJar() creates an externaljar.jar and an
>>> explicitpar.par.
>>> >> >
>>> >> > I found an old reference on the PAR archive (
>>> >> > http://radio-weblogs.com/0135826/2005/07/07.html) but the JPA 2.1
>>> >> doesn't
>>> >> > mention anything about it.
>>> >> > The explicitpar.par contains the persistence.xml which contains a
>>> >> jar-file
>>> >> > attribute that references the externaljar.jar with an absolute path:
>>> >> >
>>> >> >
>>> >>
>>> <jar-file>D:\Vlad\Work\GitHub\hibernate-orm\hibernate-entitymanager\target/packages/externaljar.jar</jar-file>
>>> >> >
>>> >> > The JPA spec says that: "Such JAR files are specified relative to
>>> the
>>> >> > directory or jar file that contains the root of the persistence
>>> unit",
>>> >> and
>>> >> > gives several examples
>>> >> > for when using an EAR with or without a WAR.
>>> >> >
>>> >> > While debugging, I found that the JarFileBasedArchiveDescriptor
>>> scans the
>>> >> > "explicitpar.par" and looks for:
>>> >> >
>>> >> > if ( getEntryBasePrefix() != null && ! entryName.startsWith(
>>> >> > getEntryBasePrefix() ) ) {
>>> >> > continue;
>>> >> > }
>>> >> >
>>> >> > where the getEntryBasePrefix() is
>>> >> >
>>> >>
>>> "D:/Vlad/Work/GitHub/hibernate-orm/hibernate-entitymanager/target/packages/externaljar.jar"
>>> >> >
>>> >> > The way that JarFileBasedArchiveDescriptor is implemented matches
>>> the JPA
>>> >> > description.
>>> >> > Nevertheless, the scan cannot locate the jar, and the entities that
>>> are
>>> >> > contained in the "externaljar.jar" don't get loaded, and the test
>>> fails.
>>> >> >
>>> >> > I can ignore this on my machine and just consider it a white noise,
>>> but I
>>> >> > wonder why we still check for PAR when we might want to have a test
>>> with
>>> >> an
>>> >> > EAR instead and relative paths.
>>> >> >
>>> >> > Vlad
>>> >> > _______________________________________________
>>> >> > hibernate-dev mailing list
>>> >> > hibernate-dev@lists.jboss.org
>>> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> >>
>>> > _______________________________________________
>>> > hibernate-dev mailing list
>>> > hibernate-dev@lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev@lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
