On Mon, Sep 29, 2014 at 1:34 PM, Felix Meschberger <fmesc...@adobe.com> wrote: > > Hi > > Am 29.09.2014 um 13:13 schrieb Karl Pauls <karlpa...@gmail.com>: > > > On Mon, Sep 29, 2014 at 12:56 PM, <dirk.rudo...@t-systems.com> wrote: > > > >> What happens with Bundle-Location: inputstream:bundle-1.0.0.jar. Is a > >> URLHandler available for this? > > > > > > No. > > > > > >> So in this case JCE implemtation of OpenJDK will not be supported by > >> Apache Felix (OSGI in general?) out of the box? > >> > > > > If you choose to give a bundle location that doesn't work than yes, you > > have a problem there. > > > > I suppose we could re-work the FakeURLStreamhandler to actually serve up > > the content of the revision. So if the OpenJDK JCE implementation would at > > least do the right thing with the code source url it might work > > I have the impression, that this might work, indeed.
The only way it might work (again, this is hacking a hack so ymmv) is to override the JarUrl subsystem (and it will probably involve creating copies of stuff all over the place to make it work with the reference: protocol - which i wouldn't do initially). I can do it (please open a jira issue and assign it to me if you want that) but keep in mind that it will be a very brittle solution to the problem as it depends on the using library to do the right thing in regards to URLs (which mostly will not happen) - but it should work for the OpenJdk impl. regards, Karl > > > > but I > > wouldn't be surprised if they don't (URLs and how to handle them are a mess > > in java). > > +100 > > Regards > Felix > > > > > regards, > > > > Karl > > > > > >> Regards, > >> Dirk > >> > >> -----Ursprüngliche Nachricht----- > >> Von: Karl Pauls [mailto:karlpa...@gmail.com] > >> Gesendet: Montag, 29. September 2014 12:47 > >> An: users@felix.apache.org > >> Betreff: Re: Comprehension question about ProtectionDomain of a Bundle > >> > >> In the current Felix setup, though, this URL basically just is an immutable > >>> key referring to the abstract Bundle not to the concrete contents of > >>> the Bundle. If we expect the CodeSource URL to actually refer to the > >>> location from where classes are loaded, then the > >>> BundleProtectionDomain should probably take the Content from the > >>> BundleRevisionImpl to use as the basis for the CodeSource URL. In this > >>> case, though, it is not relevant any longer what the string for the > >> bundle location actually is. > >>> > >> > >> The BundleProtectionDomain does the correct thing. > >> > >> The problem is purely that some library assumes it can get the code source > >> of a protection domain and access it. That is wrong and a bad hack at best > >> but nothing we can paper over. > >> Setting the bundle location as the code source is the correct thing to do. > >> If you want to work with that library (or others that do make the same bad > >> assumption) you can use a URLHandlers to make it work with your own > >> namespace and you are good. This would only be a problem if you would reuse > >> bundle locations for bundles that are not identically which you shouldn't > >> do in the first place. > >> > >> regards, > >> > >> Karl > >> > >> > >> WDYT ? > >>> > >>> Regards > >>> Felix > >>> > >>> Am 29.09.2014 um 11:27 schrieb <dirk.rudo...@t-systems.com> < > >>> dirk.rudo...@t-systems.com>: > >>> > >>>> Thanks so far for your explanations. > >>>> > >>>> So Am I right that each provider that installs bundles in Felix > >>>> using a > >>> custom bundle location (as Sling OSGI installer does) has to provide a > >>> URL handler that is able to resolve to the proper jar file? > >>>> > >>>> Think about the following cases: > >>>> > >>>> - Install a bundle using OSGI installer, the Bundle-Location will be > >>> jcrinstall:/apps/path/install/bundle-1.0.0.jar for example > >>>> - Update the bundle with the same symbolic name but another version > >>> using the webconsole, the Bundle-Location will be the same > >>>> > >>>> or > >>>> > >>>> - Install a bundle using OSGI installer, the Bundle-Location will be > >>> jcrinstall:/apps/path/install/bundle-1.0.0.jar for example > >>>> - Update the bundle with the same symbolic name by removing > >>> /apps/path/install/bundle-1.0.0.jar and uploading the new version to > >>> /apps/path/install/bundle-1.1.0.jar, the Bundle-Location will also be > >>> the same > >>>> > >>>> Due to this the I think the location of the CodeSource should always > >>> point to the cache jar (the one the actual class is loaded from, think > >>> about embedded dependency). Otherwise it would be hard to implement a > >>> proper URLStreamHandlerService. > >>>> > >>>> For the JarURLConnection: Is the cached file transient? > >>>> > >>>> Cheers, > >>>> Dirk > >>>> > >>>> -----Ursprüngliche Nachricht----- > >>>> Von: Karl Pauls [mailto:karlpa...@gmail.com] > >>>> Gesendet: Montag, 29. September 2014 10:23 > >>>> An: users@felix.apache.org > >>>> Betreff: Re: Comprehension question about ProtectionDomain of a > >>>> Bundle > >>>> > >>>> Hi Dirk, > >>>> > >>>> we are using bouncycastle as jce provider in our application setup > >>>> based > >>> on > >>>>> AEM (Apache Sling) and I got an error during jar verification. > >>>>> (Something with MalformedURLException). > >>>>> > >>>> > >>>> Yeah, irrc they do assume that the code source of a protection > >>>> domain is > >>> a valid url which isn't necessarily the case for OSGi bundles (I'd > >>> argue they shouldn't but oh well). > >>>> > >>>> > >>>>> For my use case I fixed the issue by implementing a > >>>>> URLStreamHandlerService providing a URLConnection to the bundle > >>>>> location but during my work on this I thought about the topic more > >>>>> in > >>> general. > >>>>> > >>>> > >>>> I guess that it is probably ok to handle the situation like this > >>> assuming you can provide the handler. > >>>> > >>>> > >>>>> As the comment in BundleProtectionDomain.java:38 says the > >>>>> CodeSource of a BundleProtectionDomain should be based on the > >>>>> revision of the bundle not the bundle itself. (for me the bundle > >>>>> location is > >>>>> "jcrinstall:/a/path/to/the/bundle.jar") > >>>>> > >>>> > >>>> You should be able to ignore this comment. The > >>>> BundleProtectionDomain > >>> does indeed provide the bundle revision. It just does get the revision > >>> in a stupid way - hence, the comment to remind me that I should figure > >>> out a better (i.e., less indirect) way to provide the revision to it. > >>>> > >>>> > >>>>> Is there any reason why the bundle location is used here and not > >>>>> the file:///<file:///\\> URL of the revision located in the cache > >> instead? > >>>>> > >>>> > >>>> Well, the idea is that you base your security policies on the code > >>> source url. That concept would be pretty much meaningless if the code > >>> source would be the cached jar. Regardless, the cache implementation > >>> (and its layout) is mostly undefined by the spec - the code source is > >>> the Bundle-Location URL (consider, for example, the JarURLConnection > >>> of the > >>> ire: it will cache the jar file on disc as a JarFile but the url will > >>> still be the one of the source for the code source). > >>>> > >>>> > >>>>> I mentioned that unfortunatly the JceSecurity implementation has a > >>>>> WeakHashMap<Class,URL> that holds the URL to the location of the > >>>>> CodeSource. So I assume that it might be possible that the worng > >>>>> CodeSource location can be returned there when the cache points to > >>>>> a old revision location after a bundle update without garbage > >>>>> collection of the old revision. Am I right? > >>>>> > >>>> > >>>> No. The Class object is unique based on its class loader so you will > >>>> get > >>> the code source URL that was associated with the bundle revision that > >>> this class has been loaded from. As long as they key the map by an > >>> actual Class object and get the URL from the code source of the > >>> BundleProtectionDomain of that class object you should be good. > >>>> > >>>> > >>>> regards, > >>>> > >>>> Karl > >>>> > >>>> > >>>>> Kind Regards, > >>>>> > >>>>> Dirk Rudolph > >>>>> > >>>>> > >>>>> T-Systems Multimedia Solutions GmbH Organisationseinheit CCS Dirk > >>>>> Rudolph Software-Entwicklung, OCJP > >>>>> Hausanschrift: Riesaer Straße 5, 01129 Dresden > >>>>> Postanschrift: Postfach 10 02 24, 01072 Dresden > >>>>> +49 351 2820-5363 (Tel) > >>>>> E-Mail: > >>>>> dirk.rudo...@t-systems.com<mailto:mdirk.rudo...@t-systems-mms.com> > >>>>> Internet: > >>>>> http://www.t-systems-mms.com<http://www.t-systems-mms.de/> > >>>>> > >>>>> T-Systems Multimedia Solutions GmbH > >>>>> Aufsichtsrat: Thilo Kusch (Vorsitzender) > >>>>> Geschäftsführung: Peter Klingenburg, Susanne Heger, Dr. Rolf Werner > >>>>> Handelsregister: Amtsgericht Dresden HRB 11433 Sitz der Gesellschaft: > >>>>> Dresden > >>>>> Ust-IdNr.: DE 811 807 949 > >>>>> > >>>>> > >>>>> > >>>> > >>>> > >>>> -- > >>>> Karl Pauls > >>>> karlpa...@gmail.com > >>>> http://twitter.com/karlpauls > >>>> http://www.linkedin.com/in/karlpauls > >>>> https://profiles.google.com/karlpauls > >>>> > >>> B KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK > >>> CB [ X ܚX K K[XZ[ \ \ ][ X ܚX P [ ^ \ X K ܙ B ܈ Y ] [ۘ[ > >> [X[ > >>> K[XZ[ \ \ Z [ [ ^ \ X K ܙ B > >>> > >>> > >> > >> > >> -- > >> Karl Pauls > >> karlpa...@gmail.com > >> http://twitter.com/karlpauls > >> http://www.linkedin.com/in/karlpauls > >> https://profiles.google.com/karlpauls > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org > >> For additional commands, e-mail: users-h...@felix.apache.org > >> > > > > > > > > -- > > Karl Pauls > > karlpa...@gmail.com > > http://twitter.com/karlpauls > > http://www.linkedin.com/in/karlpauls > > https://profiles.google.com/karlpauls > -- Karl Pauls karlpa...@gmail.com http://twitter.com/karlpauls http://www.linkedin.com/in/karlpauls https://profiles.google.com/karlpauls
