[ https://issues.jboss.org/browse/AS7-5062?page=com.atlassian.jira.plugin.s... ] Craig Ringer commented on AS7-5062: ----------------------------------- It looks like JBoss AS 7 is non-compliant with the spec. I've closed the EclipseLink bug as AS7 isn't giving EclipseLink what the spec says it should. Here's an example of the persistenceUnitRootUrl provided during persistence unit creation in an Arquillian test: vfs:/content/8744d775-9837-4a5f-b1ab-22259f7e19b6.war/WEB-INF/classes/ It's a URL object, but the scheme isn't something EclipseLink will be able to do anything with without help. AS7 can provide a custom archive factory to allow EclipseLink to cope with such URLs, and that's what the new support code is doing. What AS7 is doing would seem questionable in standards terms though. The spec says the URL must be a file: schema URL, or must be some other URL resolvable to a jar. This is neither; it's a vfs:/ url to (in this case) the class-root of an exploded jar. The URL object has an assigned handler of type org.jboss.vfs.protocol.VirtualFileURLStreamHandler AS7 will need to provide EclipseLink with an archive factory, assigned via system properties, to allow EclipseLink to cope with such archives. One has already been implemented by Rich DiCroce. I'll get his OK to submit it for inclusion in AS7 in-tree. Patch pending. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-5062?page=com.atlassian.jira.plugin.s... ] Scott Marlow commented on AS7-5062: ----------------------------------- Does EclipseLink see that "vfs:/content/8744d775-9837-4a5f-b1ab-22259f7e19b6.war/WEB-INF/classes/" doesn't start with "file:" and as a result ignore the url? It doesn't really matter but my read of the JPA specification doesn't require the URL to be a "file:". What matters is that we get this working. I don't currently have a good way to change the "vfs:" into a "file:", otherwise I would of done so already. In the Hibernate adapter (https://github.com/jbossas/jboss-as/blob/master/jpa/hibernate4/src/main/j...), we started with scanning the "vfs:" URL but ended up using the passed in jandex (index of all annotations) for better performance. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-5062?page=com.atlassian.jira.plugin.s... ] Craig Ringer edited comment on AS7-5062 at 7/6/12 4:23 AM: ----------------------------------------------------------- It took me a bit of time to find out the answer to how EclipseLink is choking on the persistence unit root. It turns out that it does in fact check the protocol explicitly in org.eclipse.persistence.internal.jpa.deployment.ArchiveFactoryImpl using URL.getProtocol() and looking for "jar" or "file". If neither are found it tries to open the URL as an input stream using ArchiveFactoryImpl.isJarInputStream() , which calls url.openStream(), getting a valid org.jboss.vfs.VirtualJarInputStream, which it wraps in a java.util.jar.JarInputStream and calls JarInputStream.getNextEntry() on. This call returns null, so EclipseLink decides it can't iterate through the contents of the archive. Failing all else, it falls back to return a org.eclipse.persistence.internal.jpa.deployment.URLArchive if its various container-specific hacks and heuristics can't work out a more specific archive adapter to use. The comment on URLArchive says: {quote} * This is an implementation of {@link Archive} when container returns a url * that is not one of the familiar URL types like file or jar URLs. So, we can * not recursively walk thru' its hierarchy. As a result {@link #getEntries()} * returns an empty collection. {quote} Here's the ArchiveFactory code that makes the decision about the archive adapter to use: {code} package org.eclipse.persistence.internal.jpa.deployment; public class ArchiveFactoryImpl implements ArchiveFactory { // ... public Archive createArchive(URL rootUrl, String descriptorLocation, Map properties) throws URISyntaxException, IOException { // ... String protocol = rootUrl.getProtocol(); if ("file".equals(protocol)) { // ... } else if ("jar".equals(protocol)) { // ... } else if (isJarInputStream(rootUrl)){ result = new JarInputStreamURLArchive(rootUrl, descriptorLocation); } else { result = new URLArchive(rootUrl, descriptorLocation); } } } {code} Here's the complete code for ArchiveFactoryImpl.isJarInputStream: {code} /** * This method is called for a URL which has neither jar nor file protocol. * This attempts to find out if we can treat it as a URL from which a JAR * format InputStream can be obtained. * @param url */ protected boolean isJarInputStream(URL url) throws IOException { InputStream in = null; try { in = url.openStream(); if (in == null) { // for directories, we may get InputStream as null return false; } JarInputStream jis = null; try { jis = new JarInputStream(in); if (jis.getNextEntry() == null){// if there is no next entry, this jar stream can't be used return false; } return true; // we are successful in creating a Jar format IS } finally { if (jis != null){ jis.close(); } } } catch (IOException ioe) { if (in != null) { in.close(); } return false; } } {code} was (Author: ringerc): It took me a bit of time to find out the answer to how, exactly, EclipseLink is choking on the persistence unit root. It does, indeed, check the protocol explicitly in org.eclipse.persistence.internal.jpa.deployment.ArchiveFactoryImpl . It falls back to return a org.eclipse.persistence.internal.jpa.deployment.URLArchive if its various container-specific hacks and heuristics can't work out a more specific archive adapter to use. The comment on URLArchive says: {quote} * This is an implementation of {@link Archive} when container returns a url * that is not one of the familiar URL types like file or jar URLs. So, we can * not recursively walk thru' its hierarchy. As a result {@link #getEntries()} * returns an empty collection. {quote} Here's the ArchiveFactory code that makes the decision about the archive adapter to use: {code} package org.eclipse.persistence.internal.jpa.deployment; public class ArchiveFactoryImpl implements ArchiveFactory { // ... public Archive createArchive(URL rootUrl, String descriptorLocation, Map properties) throws URISyntaxException, IOException { // ... String protocol = rootUrl.getProtocol(); if ("file".equals(protocol)) { // ... } else if ("jar".equals(protocol)) { // ... } else if (isJarInputStream(rootUrl)){ result = new JarInputStreamURLArchive(rootUrl, descriptorLocation); } else { result = new URLArchive(rootUrl, descriptorLocation); } } } {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-5062?page=com.atlassian.jira.plugin.s... ] Scott Marlow commented on AS7-5062: ----------------------------------- We might try to change PersistenceUnitParseProcessor.getRelativeURL() + PersistenceUnitParseProcessor.getPersistenceUnitURL() to try using VirtualFile.getPhysicalFile() javadoc for VirtualFile.getPhysicalFile(): {code} /** * Get a physical file for this virtual file. Depending on the underlying file system type, this may simply return * an already-existing file; it may create a copy of a file; or it may reuse a preexisting copy of the file. * Furthermore, the returned file may or may not have any relationship to other files from the same or any other * virtual directory. * * @return the physical file * * @throws IOException if an I/O error occurs while producing the physical file */ {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-5062?page=com.atlassian.jira.plugin.s... ] Scott Marlow commented on AS7-5062: ----------------------------------- VirtualFile.getPhysicalFile() does make an extra copy of the deployment files, but seems to clean them up at undeploy time (as you would expect). I'll make the use of VirtualFile.getPhysicalFile() optional based on a persistence unit flag that the user will have to add to their persistence.xml. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-5062?page=com.atlassian.jira.plugin.s... ] Scott Marlow commented on AS7-5062: ----------------------------------- code change is pushed to https://github.com/scottmarlow/jboss-as/tree/AS7-5062_vfshell -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-5062?page=com.atlassian.jira.plugin.s... ] Craig Ringer commented on AS7-5062: ----------------------------------- Thanks for that. It's pretty ugly that EclipseLink works how it does, but it's good to have a spec compliant impl in AS7 - even if perhaps it'd be nice if the spec *didn't* work quite this way. Thanks for taking the time to check it out. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-5062?page=com.atlassian.jira.plugin.s... ] Adriano Verona commented on AS7-5062: ------------------------------------- Hi. The URL I get back from PersistenceUnitInfo#getPersistenceUnitRootUrl() points to an empty folder. Interestingly the parent of this folder does contains the user application jar file. For instance inside our PersistenceProvider#createContainerEntityManagerFactory() implementation this Url looks like: file:/D:/Java/jboss-as-7.2.0.Alpha1/standalone/tmp/vfs/tempedcf4c778eabcd67/vjpa_jboss_example.jar-24c2c4a891a97d13/contents/ If I look into D:/Java/jboss-as-7.2.0.Alpha1/standalone/tmp/vfs/tempedcf4c778eabcd67/vjpa_jboss_example.jar-24c2c4a891a97d13 I do see vjpa_jboss_example.jar. Is this behavior correct? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-5062?page=com.atlassian.jira.plugin.s... ] Adriano Verona commented on AS7-5062: ------------------------------------- Hi Scott. Thanks for being so responsive :) I've create a new issue and linked to this one. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-5062?page=com.atlassian.jira.plugin.s... ] Scott Marlow commented on AS7-5062: ----------------------------------- It looks like the approach of converting VFS urls to FILE urls is not working, I'm going to reject the VFS change since its not really working. Also, AS is allowed to return VFS urls by the JPA spec. Below is the javadoc for getPersistenceUnitRootUrl(): {code} /** * Returns the URL for the jar file or directory that is the * root of the persistence unit. (If the persistence unit is * rooted in the WEB-INF/classes directory, this will be the * URL of that directory.) * The URL will either be a file: URL referring to a jar file * or referring to a directory that contains an exploded jar * file, or some other URL from which an InputStream in jar * format can be obtained. * @return a URL referring to a jar file or directory */ {code} I thin that the VFS url should fit the "or some other URL..." -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira