Community
Participate
Working Groups
Since Indigo SR1 RC1 the loading of Jubula's persistence unit fails due to a java.net.MalformedURLException (see bug 355346 and attachment 201898 [details]) for further information. I think this is caused due to an "API"-change in org.eclipse.osgi.baseadaptor.bundlefile.DirZipBundleEntry for bug 349192 with changeset: http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?h=R3_7_maintenance&id=160d5b85005022ee9026167f19e9d819479507f5 in combination with the org.eclipse.persistence.internal.jpa.deployment.ArchiveFactoryImpl.isJarInputStream(URL) implementation. In <= 3.7.0 the DirZipBundleEntry.openStream() always returned null which caused the ArchiveFactoryImpl to return an URLArchive instead of a JarInputStreamURLArchive; isJarInputStream(rootURL) always returned false for this bundle entry type. For 3.7.1 a JarInputStreamURLArchive is returned which points to an empty "new ByteArrayInputStream(new byte[0])" from which the loading of the persistence unit fails with an "misleading" MalformedURLException. I am not sure whether this is an EclipseLink or an Equinox issue, but as this completely blocks Jubula (and I think all other EclipseLink based projects which run against >= 3.7.1) from working, I have set the severity to blocker.
In Equinox we had an issue that DirZipBundleEntry.getInputStream() returned null. This violated the contract. This method must return an inputstream or throw an IOException. Returning null caused other violations such as the URL.openStream() method. According to the javadoc of URL.openStream() cannot be returned. Callers will not expect a null value here. It looks like org.eclipse.persistence.internal.jpa.deployment.ArchiveFactoryImpl.isJarInputStream is dependent on this behavior. I suppose we could have thrown an IOException instead from DirZipBundleEntry.getInputStream().
(In reply to comment #1) > > I suppose we could have thrown an IOException instead from > DirZipBundleEntry.getInputStream(). I did not got this route because of the behavior of ZipFile when directory entries are included. In this case an empty InputStream is returned for a ZipEntry which represents a directly. My guess is that eclipselink is getting the "root" entry of the bundle (e.g. bundle.getEntry("/") and the using that URL. In this case a DirZipBundleEntry is created to mimic a zip directory entry since ZipFile never has a root entry representing the root directory. bundle.getEntry("META-INF") for a jar'ed bundle will also give you a URL which has an empty input stream.
Targetting for our 2.3.1 release which should ship on a similar timeframe to SR1. I hope we can take a look at this issue quite soon. The code in this case is trying to figure out how to look inside something that contains a persistence unit based on its URL. For some URLs, we can tell based on the protocol whether we can treat it as a JarFile, a URL into a JarFile, a directory on the file system, etc... At the moment we do not have any specific handling of the "bundleresource" protocol, so we slip into code where we don't know what we have and try to figure out a way to look inside. We used to fall to what we call a URLArchive which appends to the RootURL to look inside. Now, it appears we are treating this archive as if it can be used as a JarInputStream. My initial thought is that we could add some handling of bundleresource that will allow us to go back to the previous state. The concern is what will happen on other OSGi implementations.
(In reply to comment #3) > My initial thought is that we could add some handling of bundleresource that > will allow us to go back to the previous state. The concern is what will > happen on other OSGi implementations. Another option is to have Equinox back out the change that is returning the empty stream. While I view that as introducing a bug back into Equinox it is not really a critical bug and one that has been around for many years. We only noticed the bug while doing a code review of the various BundleEntry implementations. I don't believe the bug has caused issues in the field. The bug 349192 fix was really for closing streams which we left open. The change for returning an empty stream is not directly related to that fix.
(In reply to comment #4) > (In reply to comment #3) > > My initial thought is that we could add some handling of bundleresource that > > will allow us to go back to the previous state. The concern is what will > > happen on other OSGi implementations. > > Another option is to have Equinox back out the change that is returning the > empty stream. While I view that as introducing a bug back into Equinox it is > not really a critical bug and one that has been around for many years. We only > noticed the bug while doing a code review of the various BundleEntry > implementations. I don't believe the bug has caused issues in the field. The > bug 349192 fix was really for closing streams which we left open. The change > for returning an empty stream is not directly related to that fix. Could EclipseLink/JPA work around this by simply doing a check to see if JarInputStream.getNextEntry() != null (i.e. the jar has at least one entry)? I would assume an emtpy jar file is pretty useless.
I think it should be possible for EclipseLink to check JarInputStream.getNextEntry().
(In reply to comment #6) > I think it should be possible for EclipseLink to check > JarInputStream.getNextEntry(). To be explicit, do you mean you can do this in time for Indigo SR1?
'planning on looking at it in the next week.
Can someone please point me at an eclipse build that demonstrates the problem?
(In reply to comment #9) > Can someone please point me at an eclipse build that demonstrates the problem? The Eclipse for Testers package for Indigo SR1 will do. See http://build.eclipse.org/technology/epp/epp_build/indigo/download/20110818-2321/ and choose one of the "eclipse_testing" packages.
Has there been any progress on this issue yet / is there a chance that the fix will already be included in the indigo-sr1 rc3 build this week? If not, we do need to implement / add a workaround.
This fix will be included in RC4.
Created attachment 202807 [details] Proposed fix - suggested by Thomas Watson
Fix checked into trunk and 2.3.1 streams. Tested with Manual test case - automated regression testing will be available when our OSGi tests upgrade to use the Equinox version in SR1. Review: Shaun Smith (pending) Also tested with JPA LRG
Fix will appear in tonight's nightly build. http://www.eclipse.org/eclipselink/downloads/nightly.php Getting the bundles from the 2.3.1 build should provide a workaround.
Reviewed by Shaun Smith.
*** Bug 360871 has been marked as a duplicate of this bug. ***
*** Bug 361679 has been marked as a duplicate of this bug. ***
The Eclipselink project has moved to Github: https://github.com/eclipse-ee4j/eclipselink
