I created an issues: FELIX-4658. I hope the description and title are ok :)
Unfortunately I'm not allowed to assign it to you but I am very interested in your solution. Thanks so far, Dirk -----Ursprüngliche Nachricht----- Von: Karl Pauls [mailto:karlpa...@gmail.com] Gesendet: Montag, 29. September 2014 14:00 An: users@felix.apache.org Betreff: Re: Comprehension question about ProtectionDomain of a Bundle 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.co > >>>>> m> > >>>>> 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 --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
