Hi Am 29.09.2014 um 13:13 schrieb Karl Pauls <[email protected]>:
> On Mon, Sep 29, 2014 at 12:56 PM, <[email protected]> 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:[email protected]] >> Gesendet: Montag, 29. September 2014 12:47 >> An: [email protected] >> 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 <[email protected]> < >>> [email protected]>: >>> >>>> 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:[email protected]] >>>> Gesendet: Montag, 29. September 2014 10:23 >>>> An: [email protected] >>>> 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: >>>>> [email protected]<mailto:[email protected]> >>>>> 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 >>>> [email protected] >>>> 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 >> [email protected] >> http://twitter.com/karlpauls >> http://www.linkedin.com/in/karlpauls >> https://profiles.google.com/karlpauls >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > > > -- > Karl Pauls > [email protected] > http://twitter.com/karlpauls > http://www.linkedin.com/in/karlpauls > https://profiles.google.com/karlpauls
