I agree with you too. Should I open an issue for that? The last think what I do not understand is the role of the FakeURLStreamHandler itself. The Class comment says it should prevent any unknown protocol errors. But why did I get a unknown protocol error for jcrinstall?
Regards, Dirk -----Ursprüngliche Nachricht----- Von: Felix Meschberger [mailto:fmesc...@adobe.com] Gesendet: Montag, 29. September 2014 13:34 An: users@felix.apache.org Betreff: Re: Comprehension question about ProtectionDomain of a Bundle 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. > 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 B KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB [ X ܚX KK[XZ[ \ \ ][ X ܚX P [^ \X K ܙ B ܈Y][ۘ[ [X[ K[XZ[ \ \ Z[ [^ \X K ܙ B
