glassfish
  1. glassfish
  2. GLASSFISH-3209

toplink fails when running on WIndows from a network filesystem

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 9.1pe
    • Fix Version/s: v2.1.1_dev
    • Component/s: entity-persistence
    • Labels:
      None
    • Environment:

      Operating System: Windows XP
      Platform: PC

    • Issuezilla Id:
      3,209
    • Status Whiteboard:
      Hide

      HIGH

      Show
      HIGH

      Description

      I have a Java SE app that uses Java Persistence. It was developed and packaged
      using NetBeans. It runs fine on Linux. It runs fine on Solaris. It fails to
      run on Windows if the app is located on a network filesystem (e.g., Samba).
      I get this exception:

      Exception in thread "main" java.lang.IllegalArgumentException: URI has an author
      ity component
      at java.io.File.<init>(Unknown Source)
      at oracle.toplink.essentials.ejb.cmp3.persistence.ArchiveFactoryImpl.cre
      ateArchive(ArchiveFactoryImpl.java:70)
      at oracle.toplink.essentials.ejb.cmp3.persistence.PersistenceUnitProcess
      or.findPersistenceArchives(PersistenceUnitProcessor.java:233)
      at oracle.toplink.essentials.ejb.cmp3.persistence.PersistenceUnitProcess
      or.findPersistenceArchives(PersistenceUnitProcessor.java:216)
      at oracle.toplink.essentials.internal.ejb.cmp3.JavaSECMPInitializer.init
      ialize(JavaSECMPInitializer.java:239)
      at oracle.toplink.essentials.internal.ejb.cmp3.JavaSECMPInitializer.init
      ializeFromMain(JavaSECMPInitializer.java:278)
      at oracle.toplink.essentials.internal.ejb.cmp3.JavaSECMPInitializer.getJ
      avaSECMPInitializer(JavaSECMPInitializer.java:81)
      at oracle.toplink.essentials.ejb.cmp3.EntityManagerFactoryProvider.creat
      eEntityManagerFactory(EntityManagerFactoryProvider.java:119)
      at javax.persistence.Persistence.createEntityManagerFactory(Persistence.
      java:83)
      at wine.WineList.<init>(WineList.java:51)
      at wine.WineList.main(WineList.java:392)

      My persistence.xml looks like this (although I don't think it's part
      of the problem):

      <?xml version="1.0" encoding="UTF-8"?>
      <persistence version="1.0" xmlns="http://java.sun.com/xml/ns/persistence"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="http://java.sun.com/xml/ns/persistence
      http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd">
      <persistence-unit name="WineListPU" transaction-type="RESOURCE_LOCAL">
      <provider>oracle.toplink.essentials.PersistenceProvider</provider>
      <class>wine.Wine</class>
      <properties>
      <property name="toplink.jdbc.user" value="shannon"/>
      <property name="toplink.jdbc.password" value="XXX"/>
      <property name="toplink.jdbc.url" value="jdbc:derby://nissan:1527/wine"/>
      <property name="toplink.jdbc.driver"
      value="org.apache.derby.jdbc.ClientDriver"/>
      <property name="toplink.logging.level" value="WARNING"/>
      <property name="toplink.cache.type.default" value="NONE"/>
      </properties>
      </persistence-unit>
      </persistence>

      If I copy the binary and dependent jar files to a local disk on Windows,
      it works.

      In all cases the app is being run from a directory with this structure:

      $ ls -lR
      .:
      total 136
      drwxr-xr-x 2 shannon wheel 4096 Jun 14 16:45 lib
      rw-rr- 1 shannon wheel 1303 Jun 16 00:20 README.TXT
      rw-rr- 1 shannon wheel 124859 Jun 16 00:20 winelist.jar

      ./lib:
      total 2752
      rw-rr- 1 shannon wheel 394495 Jun 14 16:45 derbyclient.jar
      rw-rr- 1 shannon wheel 2342 Jun 14 16:45 toplink-essentials-agent.jar
      rw-rr- 1 shannon wheel 2406599 Jun 14 16:45 toplink-essentials.jar

      The main jar file has this Class-Path entry:

      Class-Path: lib/toplink-essentials.jar lib/toplink-essentials-agent.ja
      r lib/derbyclient.jar

      I'm guessing that toplink is making some assumptions about the URI of the
      jar file that happen not to be true when the jar file is on a network
      filesystem.

      I tested this with last night's build and it still fails.

        Activity

        Hide
        Sanjeeb Sahoo added a comment -

        There are two JDK bugs here: 6582743 and 6585937. The latter one says there is
        work around provided in the former one and the former one has been closed as a
        duplicate of the latter one. I never understood how we could use the work around
        and there was no response to it. So, as far as I understand, there is no
        suitable work around to the underlying JDK bug.

        Show
        Sanjeeb Sahoo added a comment - There are two JDK bugs here: 6582743 and 6585937. The latter one says there is work around provided in the former one and the former one has been closed as a duplicate of the latter one. I never understood how we could use the work around and there was no response to it. So, as far as I understand, there is no suitable work around to the underlying JDK bug.
        Hide
        Sanjeeb Sahoo added a comment -

        I am attaching a patch to work around the JDK issue. The patch is generated
        against v2.1.1 workspace (i.e., SJSAS91_FCS_BRANCH branch). I have tested it on
        Windows using a network file system and it works. I have also run
        entity-persistence-tests successfully with the patch. The fix is described below:

        When we compute the PersistenceUnitRoot from the URL returned by
        ClassLoader.getResource("META-INF/persistence.xml"), we apply the work around.
        When there is a network file system in classpath, the classloader.getResource
        returns a file: URL with an authority component in it. See the associated JDK
        bug http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6585937.
        The URL looks like this: file://ahost/afile.
        Interestingly, authority and file components for the above URL
        are either "ahost" and "/afile" or "" and "//ahost/afile" depending on
        how the URL is obtained. If classpath is set as a jar, the former is true; if
        the classpath is set as a directory, the latter is true. So, we create a new URL
        by prefixing "//" or "////" depending on the value of the authority component.

        While testing this fix, I also discovered that in one of the places, the
        internal PU name was not called by calling buildPersistenceUnitName(). I have
        fixed that as well. Without this, when there is space in file name, things does
        not work properly.

        Show
        Sanjeeb Sahoo added a comment - I am attaching a patch to work around the JDK issue. The patch is generated against v2.1.1 workspace (i.e., SJSAS91_FCS_BRANCH branch). I have tested it on Windows using a network file system and it works. I have also run entity-persistence-tests successfully with the patch. The fix is described below: When we compute the PersistenceUnitRoot from the URL returned by ClassLoader.getResource("META-INF/persistence.xml"), we apply the work around. When there is a network file system in classpath, the classloader.getResource returns a file: URL with an authority component in it. See the associated JDK bug http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6585937 . The URL looks like this: file://ahost/afile . Interestingly, authority and file components for the above URL are either "ahost" and "/afile" or "" and "//ahost/afile" depending on how the URL is obtained. If classpath is set as a jar, the former is true; if the classpath is set as a directory, the latter is true. So, we create a new URL by prefixing "//" or "////" depending on the value of the authority component. While testing this fix, I also discovered that in one of the places, the internal PU name was not called by calling buildPersistenceUnitName(). I have fixed that as well. Without this, when there is space in file name, things does not work properly.
        Hide
        Sanjeeb Sahoo added a comment -

        Created an attachment (id=3131)
        Contains both the diff and the complete file

        Show
        Sanjeeb Sahoo added a comment - Created an attachment (id=3131) Contains both the diff and the complete file
        Hide
        Sanjeeb Sahoo added a comment -

        reassigning to myself

        Show
        Sanjeeb Sahoo added a comment - reassigning to myself
        Hide
        Sanjeeb Sahoo added a comment -

        The patch has been reviewed by Tom Ware from TopLink Essentials team. As per the
        feedback, removed some commented code and replaced System.out by logger.
        Checking in
        src/java/oracle/toplink/essentials/ejb/cmp3/persistence/PersistenceUnitProcessor.java;
        /cvs/glassfish/entity-persistence/src/java/oracle/toplink/essentials/ejb/cmp3/persistence/PersistenceUnitProcessor.java,v
        <-- PersistenceUnitProcessor.java
        new revision: 1.32.2.2; previous revision: 1.32.2.1
        done
        Checking in
        src/java/oracle/toplink/essentials/internal/ejb/cmp3/JavaSECMPInitializer.java;
        /cvs/glassfish/entity-persistence/src/java/oracle/toplink/essentials/internal/ejb/cmp3/JavaSECMPInitializer.java,v
        <-- JavaSECMPInitializer.java
        new revision: 1.33.2.2; previous revision: 1.33.2.1
        done

        Show
        Sanjeeb Sahoo added a comment - The patch has been reviewed by Tom Ware from TopLink Essentials team. As per the feedback, removed some commented code and replaced System.out by logger. Checking in src/java/oracle/toplink/essentials/ejb/cmp3/persistence/PersistenceUnitProcessor.java; /cvs/glassfish/entity-persistence/src/java/oracle/toplink/essentials/ejb/cmp3/persistence/PersistenceUnitProcessor.java,v <-- PersistenceUnitProcessor.java new revision: 1.32.2.2; previous revision: 1.32.2.1 done Checking in src/java/oracle/toplink/essentials/internal/ejb/cmp3/JavaSECMPInitializer.java; /cvs/glassfish/entity-persistence/src/java/oracle/toplink/essentials/internal/ejb/cmp3/JavaSECMPInitializer.java,v <-- JavaSECMPInitializer.java new revision: 1.33.2.2; previous revision: 1.33.2.1 done

          People

          • Assignee:
            Sanjeeb Sahoo
            Reporter:
            Bill Shannon
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: