Toplink Essentials on Weblogic 10

Today we’ve spent the whole day trying to migrate our web application from Weblogic 9.2 to version 10. Nothing special, one would think, if it were not for the problems with getting Toplink running under Weblogic 10. Have you ever seen such a stacktrace?

java.lang.IllegalArgumentException: URI is not hierarchical

        at java.io.File.<init>(File.java:335)
        at oracle.toplink.essentials.ejb.cmp3.persistence.ArchiveFactoryImpl.cre
ateArchive(ArchiveFactoryImpl.java:85)
        at oracle.toplink.essentials.internal.ejb.cmp3.metadata.MetadataProcesso
r.readStandardMappingFiles(MetadataProcessor.java:358)
        at 
oracle.toplink.essentials.internal.ejb.cmp3.metadata.MetadataProcesso
r.readMappingFiles(MetadataProcessor.java:339)
        at oracle.toplink.essentials.ejb.cmp3.persistence.PersistenceUnitProcess
or.processORMetadata(PersistenceUnitProcessor.java:344)
        Truncated. see log file for complete stacktrace

I’ve been searching for the clue for the whole day. It appears that both Weblogic and Toplink are the guilty. Here’s the code excerpt which throws an exception:

    public Archive createArchive(URL url) throws URISyntaxException, IOException {
        logger.entering("ArchiveFactoryImpl", "createArchive", new Object[]{url});
        Archive result;
        String protocol = url.getProtocol();
        logger.logp(Level.FINER, "ArchiveFactoryImpl", "createArchive", "protocol = {0}", protocol);
        
        if ("file".equals(protocol)) {
            URI uri = null;
            try {
                // Attempt to use url.toURI since it will deal with all urls 
                // without special characters and URISyntaxException allows us 
                // to catch issues with special characters. This will handle 
                // URLs that already have special characters replaced such as 
                // URLS derived from searches for persistence.xml on the Java 
                // System class loader
                uri = url.toURI();
            } catch (URISyntaxException exception) {
                // Use multi-argument constructor for URI since single-argument 
                // constructor and URL.toURI() do not deal with special 
                // characters in path
                uri = new URI(url.getProtocol(), url.getUserInfo(), 
                url.getHost(), url.getPort(), 
                url.getPath(), url.getQuery(), null);
            }
            
            File f = new File(uri);

When an attempt is made to create a file from the URI, an exception is thrown. So why are there no exceptions under Weblogic 9? The thing is that under Weblogic 9 this branch of code is never executed, because the url parameter has the protocol zip and a simple ULRArchive is created, which reads from the jar, but under Weblogic 10 this method is executed with url with protocol file, which causes problem.

After quite a while of digging into Toplink’s code (thank god it’s opensource), I figured out that under Weblogic 9 Toplink creates and uses native implementation of javax.persistence.spi.PersistenceUnitInfo (SEPersistenceUnitInfo), as there is no JPA support built into the application server. And the method getJarFileUrls() returns urls with the “right” protocol - zip. However Weblogic 10 is a JEE5 compliant container, which provides its own JPA implementation - Kodo. Thus Toplink is fed with container’s own implementation of javax.persistence.spi.PersistenceUnitInfo. This implementation’s getJarFileUrls() method returns urls with protocol file :(, after which toplink’s PersistenceProvider goes crazy.

So, how do I solve the problem? If you urgently need a fix, just delete the branch if (“file”.equals(protocol)) and replace the ArchiveFactoryImpl with your own version. As did I. But of course this is not a solution for the long term, a bug should be posted to glassfish. Wich I will eventually do.

PS. This solution is of course not applicable to production environments as you know why. This is why we have decided to completely abandon Toplink Essentials. Just remove the node from persistence.xml - now Kodo is used by default. By the way transition from Toplink to Kodo did not take long (thanks to JPA). I spent an overall 2 hours fixing minor incompatibilities, related mostly to more strict typing conventions in Kodo as compared to Toplink. However I must admit that I did not notice any sharp difference in operation or performance between Toplink and Kodo. Time will tell of course :)

First published on the old anydoby.com blog on 2007-04-27.