You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Di...@t-systems.com on 2014/09/28 17:58:27 UTC
Comprehension question about ProtectionDomain of a Bundle
Hi all,
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).
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.
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")
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?
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?
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.Rudolph@t-systems.com<ma...@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
AW: Comprehension question about ProtectionDomain of a Bundle
Posted by Di...@t-systems.com.
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:fmeschbe@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 <ka...@gmail.com>:
> On Mon, Sep 29, 2014 at 12:56 PM, <Di...@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:karlpauls@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 <Di...@t-systems.com> <
>>> Dirk.Rudolph@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:karlpauls@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.Rudolph@t-systems.com<ma...@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
>>>> karlpauls@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
>> karlpauls@gmail.com
>> http://twitter.com/karlpauls
>> http://www.linkedin.com/in/karlpauls
>> https://profiles.google.com/karlpauls
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
>
>
> --
> Karl Pauls
> karlpauls@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
Re: Felix DependencyManager on OSGi 3
Posted by Marcel Offermans <ma...@luminis.nl>.
Good question. The first release at Felix was already using R4 (2.0.1 that is). I must say that I have a hard time finding any “older” code. After a lot of digging in personal archives, I did manage to find a very old R3 version. It probably makes sense to contact me off-list if you want a copy. :)
Greetings, Marcel
On 20 Jan 2015 at 15:36:02 , Bulu (bulu@romandie.com) wrote:
OK thanks. Do you know of another dependency manager which might work on
OSGi 3?
Regards Philipp
On 20.01.2015 13:01, Marcel Offermans wrote:
> Hello Philipp,
>
> When the DM project was started, a long time ago, it was compatible with an OSGi R3 framework. However, we currently build against R4 classes, so out of the box that won’t work. I do think that, with a few patches, you could make it work.
>
> Greetings, Marcel
>
> On 20 Jan 2015 at 11:11:02, Bulu (bulu@romandie.com) wrote:
>
> Dear Felix DM users
>
> Is it possible to use Felix DM on OSGi 3?
>
> I hope it is :-)
>
> Regards Philipp
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Felix DependencyManager on OSGi 3
Posted by Bulu <bu...@romandie.com>.
OK thanks. Do you know of another dependency manager which might work on
OSGi 3?
Regards Philipp
On 20.01.2015 13:01, Marcel Offermans wrote:
> Hello Philipp,
>
> When the DM project was started, a long time ago, it was compatible with an OSGi R3 framework. However, we currently build against R4 classes, so out of the box that won’t work. I do think that, with a few patches, you could make it work.
>
> Greetings, Marcel
>
> On 20 Jan 2015 at 11:11:02, Bulu (bulu@romandie.com) wrote:
>
> Dear Felix DM users
>
> Is it possible to use Felix DM on OSGi 3?
>
> I hope it is :-)
>
> Regards Philipp
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Felix DependencyManager on OSGi 3
Posted by Bulu <bu...@romandie.com>.
Yes, don't tell me... I'm working with the ZB4O project which insists on
using OSGi 3 (presumably, because it uses less resources on constraint
devices).
Regards Philipp
On 20.01.2015 13:21, Neil Bartlett wrote:
> Fascinated to hear why you need this, by the way! OSGi R3 was superseded by R4 more than ten years ago…
>
> Neil
>
>
>> On 20 Jan 2015, at 10:05, Bulu <bu...@romandie.com> wrote:
>>
>> Dear Felix DM users
>>
>> Is it possible to use Felix DM on OSGi 3?
>>
>> I hope it is :-)
>>
>> Regards Philipp
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Felix DependencyManager on OSGi 3
Posted by Neil Bartlett <nj...@gmail.com>.
Fascinated to hear why you need this, by the way! OSGi R3 was superseded by R4 more than ten years ago…
Neil
> On 20 Jan 2015, at 10:05, Bulu <bu...@romandie.com> wrote:
>
> Dear Felix DM users
>
> Is it possible to use Felix DM on OSGi 3?
>
> I hope it is :-)
>
> Regards Philipp
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Felix DependencyManager on OSGi 3
Posted by Marcel Offermans <ma...@luminis.nl>.
Hello Philipp,
When the DM project was started, a long time ago, it was compatible with an OSGi R3 framework. However, we currently build against R4 classes, so out of the box that won’t work. I do think that, with a few patches, you could make it work.
Greetings, Marcel
On 20 Jan 2015 at 11:11:02, Bulu (bulu@romandie.com) wrote:
Dear Felix DM users
Is it possible to use Felix DM on OSGi 3?
I hope it is :-)
Regards Philipp
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Felix DependencyManager on OSGi 3
Posted by Bulu <bu...@romandie.com>.
Dear Felix DM users
Is it possible to use Felix DM on OSGi 3?
I hope it is :-)
Regards Philipp
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: DependencyManager: publish object as several interfaces and change their properties in init()
Posted by Marcel Offermans <ma...@luminis.eu>.
Hello Philipp,
On 10 Dec 2014, at 14:43 pm, Bulu <bu...@romandie.com> wrote:
> On 09.12.2014 10:18, Marcel Offermans wrote:
>> Hello Philipp,
>>
>>> On 09 Dec 2014, at 10:03 am, Bulu <bu...@romandie.com> wrote:
>>>
>>> In Felix DM, can I publish a certain object as several services / interfaces, but each with different properties?
>>> Calling setInterface() multiple times does not seem to do the trick. Calling setInterface(String[],Dictionary) will assign the same properties to each.
>>>
>>> If I use several interface (with that last call), can I change the properties in init(). I see I can do the following, but that changes the one set of properties for all interfaces
>>>
>>> public void init(Component c){
>>> ...
>>> Dictionary<String, Object> props = c.getServiceProperties();
>>> props.put(someKey, someValue);
>>> c.setServiceProperties(props);
>>> }
>> OSGi allows you to publish a service with multiple interfaces, but the properties then apply to all of them. DM follows that model, so what you’re seeing makes sense from that point of view. If you want different properties, you have to define multiple DM “components” (which can all use the same instance if that’s what you want).
>
> If the component is instantiated only when the dependencies are met, can this approach also be used?
>
> Component c1 = Component compo = createAdapterService(Device.class, null)
> .setImplementation(DeviceAdapterImpl.class)
> .setInterface(DeviceAdapter.class.getName(), null);
> mgr.add(compo);
>
> // here also publish all instances of the component (ie. for each adapted Device) as an EventHandler with properties topic & filter.
If you have an adapter, it will create an instance of DeviceAdapterImpl for every Device it finds. That makes it a bit harder to create a second component based on that same implementation, because only after the adapter instance has been created can you try to use it in a second component. I would take this approach:
in your activator:
mgr.add(createAdapterService(…)…); // basically with the same interface and implementation you had
in DeviceAdapterImpl create an init / destroy method as follows:
private Component c2;
void init(Component c) {
dm = c.getDependencyManager();
c2 = dm.createComponent()
.setInterface(EventHandler.class.getName(), propsForTopicAndFilter)
.setImplementation(this);
dm.add(c2);
}
void destroy(Component c) {
dm = c.getDependencyManager();
dm.remove(c2);
}
So as soon as you have an instance created by the adapter, in its init method create another component, with the right service interface and properties, and in the destroy clean up again.
However, in your example, if you need the adapter to publish both as DeviceAdapter and as EventHandler, why not just register it as both and have the properties for topic/filter available on both interfaces. They are not used for DeviceAdapter, but that is not really a problem. Service properties that have no special meaning for a service can in general be ignored.
>>> Unrelated: can I use component as a dependency without publishing it as a service? Like so:
>> You might have hit “send” too soon… You cannot depend on something that is not a service. You can have a component that does not publish a service but does have dependencies on other services.
>>
>> Well, the only thing you could do is implement some custom form of dependency, but that would then have to lookup components in a registry. Which almost sounds like another service registry. :)
>>
>>
> OK too bad. My tendency was to use DM as a more general dependency injection framework. But I'm reluctant to publish a service just to acquire it again in the same bundle, because it then becomes public API.
Well, that is not necessarily true:
If you publish a service, as an interface or class, that is private to your bundle, then it will be in the service registry, but since nobody else outside your bundle will be able to access that class or interface so effectively it will be invisible. The only way to “see” it is to getAllServiceReferences() instead.
Another option is to use a component that consists of a composition, instead of a single instance. A composition is a fixed collection of instances associated with a component. All dependencies that are declared on that component will be injected into all instances in the collection. This is probably not the best way to “privately” publish a service and consume it in the same bundle, but it might be something that comes in handy in similar situations.
Greetings, Marcel
Re: DependencyManager: publish object as several interfaces and change
their properties in init()
Posted by Bulu <bu...@romandie.com>.
Hello Marcel
Thanks for you answer and the clarification.
On 09.12.2014 10:18, Marcel Offermans wrote:
> Hello Philipp,
>
>> On 09 Dec 2014, at 10:03 am, Bulu <bu...@romandie.com> wrote:
>>
>> In Felix DM, can I publish a certain object as several services / interfaces, but each with different properties?
>> Calling setInterface() multiple times does not seem to do the trick. Calling setInterface(String[],Dictionary) will assign the same properties to each.
>>
>> If I use several interface (with that last call), can I change the properties in init(). I see I can do the following, but that changes the one set of properties for all interfaces
>>
>> public void init(Component c){
>> ...
>> Dictionary<String, Object> props = c.getServiceProperties();
>> props.put(someKey, someValue);
>> c.setServiceProperties(props);
>> }
> OSGi allows you to publish a service with multiple interfaces, but the properties then apply to all of them. DM follows that model, so what you’re seeing makes sense from that point of view. If you want different properties, you have to define multiple DM “components” (which can all use the same instance if that’s what you want).
If the component is instantiated only when the dependencies are met, can
this approach also be used?
Component c1 = Component compo = createAdapterService(Device.class, null)
.setImplementation(DeviceAdapterImpl.class)
.setInterface(DeviceAdapter.class.getName(), null);
mgr.add(compo);
// here also publish all instances of the component (ie. for each
adapted Device) as an EventHandler with properties topic & filter.
>> Unrelated: can I use component as a dependency without publishing it as a service? Like so:
> You might have hit “send” too soon… You cannot depend on something that is not a service. You can have a component that does not publish a service but does have dependencies on other services.
>
> Well, the only thing you could do is implement some custom form of dependency, but that would then have to lookup components in a registry. Which almost sounds like another service registry. :)
>
>
OK too bad. My tendency was to use DM as a more general dependency
injection framework. But I'm reluctant to publish a service just to
acquire it again in the same bundle, because it then becomes public API.
Regards Philipp
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: DependencyManager: publish object as several interfaces and change their properties in init()
Posted by Marcel Offermans <ma...@luminis.eu>.
Hello Philipp,
> On 09 Dec 2014, at 10:03 am, Bulu <bu...@romandie.com> wrote:
>
> In Felix DM, can I publish a certain object as several services / interfaces, but each with different properties?
> Calling setInterface() multiple times does not seem to do the trick. Calling setInterface(String[],Dictionary) will assign the same properties to each.
>
> If I use several interface (with that last call), can I change the properties in init(). I see I can do the following, but that changes the one set of properties for all interfaces
>
> public void init(Component c){
> ...
> Dictionary<String, Object> props = c.getServiceProperties();
> props.put(someKey, someValue);
> c.setServiceProperties(props);
> }
OSGi allows you to publish a service with multiple interfaces, but the properties then apply to all of them. DM follows that model, so what you’re seeing makes sense from that point of view. If you want different properties, you have to define multiple DM “components” (which can all use the same instance if that’s what you want).
> Unrelated: can I use component as a dependency without publishing it as a service? Like so:
You might have hit “send” too soon… You cannot depend on something that is not a service. You can have a component that does not publish a service but does have dependencies on other services.
Well, the only thing you could do is implement some custom form of dependency, but that would then have to lookup components in a registry. Which almost sounds like another service registry. :)
Greetings, Marcel
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
DependencyManager: publish object as several interfaces and change
their properties in init()
Posted by Bulu <bu...@romandie.com>.
Hello All
In Felix DM, can I publish a certain object as several services /
interfaces, but each with different properties?
Calling setInterface() multiple times does not seem to do the trick.
Calling setInterface(String[],Dictionary) will assign the same
properties to each.
If I use several interface (with that last call), can I change the
properties in init(). I see I can do the following, but that changes the
one set of properties for all interfaces
public void init(Component c){
...
Dictionary<String, Object> props = c.getServiceProperties();
props.put(someKey, someValue);
c.setServiceProperties(props);
}
Unrelated: can I use component as a dependency without publishing it as
a service? Like so:
Thanks & Regards Philipp
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: DependencyManager: notify third party object of changed adaptee properties
Posted by Marcel Offermans <ma...@luminis.eu>.
Hello Pierre, Philipp,
On 16 Oct 2014, at 8:50 am, Pierre De Rop <pi...@gmail.com> wrote:
> Now, if you really need to be able to specify a callback instance to be
> called when the adaptee service properties are changed (Device), then can
> you please create a Jira issue for it, and I will add a
> createAdapterService signature allowing to specify a callbackObject,
> similar to what is currently done int the createResourceAdapterService
> methods.
> (Marcel, would you be OK for this new feature ?)
Definitely, I can't think of a valid reason not to add this. We simply did not create this signature yet (mainly because nobody asked). I would propose we only implement new features in our upcoming DM4 release though.
Greetings, Marcel
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: DependencyManager: notify third party object of changed adaptee
properties
Posted by Bulu <bu...@romandie.com>.
Hello Pierre
Thanks for coming up with this solution. I will try it out. The only
downside I see, is that bundle-internal objects (the adapters) are
published on the framework, so we lose a bit of encapsulation, but I can
live with that.
About the usage of the DeviceManager:
I want to show devices with their properties in a Vaadin GUI, for this,
they must be collected in a Container which is linked to the Widget (a
Tree). So two things need to happen:
1. for each Device appearing, create a DeviceAdapter which is of a
convenient form (a Bean) for the Vaadin framework to use, and which
forwards calls to the actual Device
2. for each DeviceAdapter created, add it to the Container (and remove
when disappearing...). The DeviceManager holds the Container and
adds/removes the adapters in it.
For separation of concerns, I didn't want the DeviceAdapters to directly
hold a reference to the deviceManager/container (ie. they should not
add/remove themselves).
Now I also want to track changes in the properties (which do not destroy
the adapter, its filter is still met), so that I can update the
container (a typical property which might change is the "parent" node in
the tree widget). So it is also the DeviceManager which needs to get
these property change notifications.
I will file a Jira request. I guess the difficulty might lie in the fact
that you will have to distinguish two case:
1. adaptee property change which make the adapter disappear (filter no
longer met)
2. adaptee property change but adapter is kept - so call callbacks on
itself or third party object
Regards Philipp
On 16.10.2014 08:50, Pierre De Rop wrote:
> Hello Philipp,
>
> I think that currently, it is not possible to specify a third party
> callback object to be notified when the adaptee services properties are
> changed, and only your adapter will be notified.
>
> One possible alternative could consist in letting the adapter impl provide
> an adapted interface and you could then track the adapted interface itself,
> because when the adaptee (Device) service properties are changed, the
> Device changed properties are then also propagated to the service
> properties provided by the adapter (if the adapter provides an adapted
> service).
>
> For example, when you create your adapter, you can manage to let it provide
> a service (like 'DeviceAdapter' service):
>
> mgr.add(createAdapterService(Device.class,null)
> .setImplementation(DeviceAdapter.class)
> .setInterface(DeviceAdapter.class, null)
> .setCallbacks("init", "start", "stop", "destroy"));
>
> Then you could manage to define your "DeviceManager" as a DM component, and
> that component could listen to all DeviceAdapter services, including
> propagated service properties change events:
>
> mgr.add(createComponent()
> .setImplementation(DeviceManager.class)
> .add(createServiceDependency(DeviceAdapter.class).setRequired(true)
> .setCallbacks("added", "changed", "removed)));
>
> then your DeviceManager could be called back it its changed method when a
> DeviceAdapter propagates its adapted Device service properties change
> events.
>
> This should work, but I don't know if this would be compatible with your
> current application design ?
> (maybe you could describe a but what is doing your DeviceManager ?)
>
> Now unfortunately, regarding your last question, I think that the work
> around won't work, because when the adaptee services comes up, the first
> dependency (the one that your work around has modified) is removed and
> replaced by another dependency (see the AdapterServiceImpl.
> AdapterImpl.createService() method()).
>
> Now, if you really need to be able to specify a callback instance to be
> called when the adaptee service properties are changed (Device), then can
> you please create a Jira issue for it, and I will add a
> createAdapterService signature allowing to specify a callbackObject,
> similar to what is currently done int the createResourceAdapterService
> methods.
> (Marcel, would you be OK for this new feature ?)
>
> kind regards;
> /Pierre
>
> On Wed, Oct 15, 2014 at 2:52 PM, Bulu <bu...@romandie.com> wrote:
>
>> Addition to my own question:
>> I came up with the following, but the callbacks seem not to get called on
>> the deviceManager...
>>
>> Component adapter = createAdapterService(Device.class,null)
>> .setImplementation(DeviceAdapter.class)
>> .setCallbacks(deviceManager, INIT_METHOD, START_METHOD, STOP_METHOD,
>> DESTROY_METHOD);
>>
>> // Ugly: supposing the adapter has always the adaptee as first service
>> dependency
>> ServiceDependency dep = (ServiceDependency) adapter.getDependencies().get(
>> 0);
>> logger.debug("Dependency is {}", dep); // OK, in my tests it's the right
>> dependency
>> dep.setCallbacks(deviceManager, BIND_METHOD, CHANGED_METHOD,
>> UNBIND_METHOD);
>> mgr.add(adapter);
>>
>> Is this the right way?
>>
>> Regards Philipp
>>
>>
>> On 15.10.2014 14:12, Bulu wrote:
>>
>>> Hello All
>>>
>>> Using Dependency Manager, I declare adapters like this:
>>> mgr.add(createAdapterService(Device.class,null)
>>> .setImplementation(DeviceAdapter.class)
>>> .setCallbacks(deviceManager, "init", "start", "stop", "destroy"));
>>>
>>> So deviceManager gets notified when the adapters appear. Now I also want
>>> deviceManager to be notified when the properties of any of the adaptees
>>> (Device.class) change (need to update the UI).
>>>
>>> For normal ServiceDependency I can specify callbacks to be called on a
>>> third party object with
>>> ServiceDependency.setCallbacks(Object instance, String added, String
>>> changed, String removed);
>>>
>>> For adapters and I can specify the callbacks, but only calling the
>>> adapter itself:
>>> createAdapterService(Device.class.name, null, "add", "change",
>>> "remove")
>>>
>>> How can I tell the adapter to use callbacks on a third party object
>>> (deviceManager) when the adaptee's properties change?
>>>
>>> Thanks & regards
>>> Philipp
>>>
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: DependencyManager: notify third party object of changed adaptee properties
Posted by Pierre De Rop <pi...@gmail.com>.
Hello Philipp,
I think that currently, it is not possible to specify a third party
callback object to be notified when the adaptee services properties are
changed, and only your adapter will be notified.
One possible alternative could consist in letting the adapter impl provide
an adapted interface and you could then track the adapted interface itself,
because when the adaptee (Device) service properties are changed, the
Device changed properties are then also propagated to the service
properties provided by the adapter (if the adapter provides an adapted
service).
For example, when you create your adapter, you can manage to let it provide
a service (like 'DeviceAdapter' service):
mgr.add(createAdapterService(Device.class,null)
.setImplementation(DeviceAdapter.class)
.setInterface(DeviceAdapter.class, null)
.setCallbacks("init", "start", "stop", "destroy"));
Then you could manage to define your "DeviceManager" as a DM component, and
that component could listen to all DeviceAdapter services, including
propagated service properties change events:
mgr.add(createComponent()
.setImplementation(DeviceManager.class)
.add(createServiceDependency(DeviceAdapter.class).setRequired(true)
.setCallbacks("added", "changed", "removed)));
then your DeviceManager could be called back it its changed method when a
DeviceAdapter propagates its adapted Device service properties change
events.
This should work, but I don't know if this would be compatible with your
current application design ?
(maybe you could describe a but what is doing your DeviceManager ?)
Now unfortunately, regarding your last question, I think that the work
around won't work, because when the adaptee services comes up, the first
dependency (the one that your work around has modified) is removed and
replaced by another dependency (see the AdapterServiceImpl.
AdapterImpl.createService() method()).
Now, if you really need to be able to specify a callback instance to be
called when the adaptee service properties are changed (Device), then can
you please create a Jira issue for it, and I will add a
createAdapterService signature allowing to specify a callbackObject,
similar to what is currently done int the createResourceAdapterService
methods.
(Marcel, would you be OK for this new feature ?)
kind regards;
/Pierre
On Wed, Oct 15, 2014 at 2:52 PM, Bulu <bu...@romandie.com> wrote:
> Addition to my own question:
> I came up with the following, but the callbacks seem not to get called on
> the deviceManager...
>
> Component adapter = createAdapterService(Device.class,null)
> .setImplementation(DeviceAdapter.class)
> .setCallbacks(deviceManager, INIT_METHOD, START_METHOD, STOP_METHOD,
> DESTROY_METHOD);
>
> // Ugly: supposing the adapter has always the adaptee as first service
> dependency
> ServiceDependency dep = (ServiceDependency) adapter.getDependencies().get(
> 0);
> logger.debug("Dependency is {}", dep); // OK, in my tests it's the right
> dependency
> dep.setCallbacks(deviceManager, BIND_METHOD, CHANGED_METHOD,
> UNBIND_METHOD);
> mgr.add(adapter);
>
> Is this the right way?
>
> Regards Philipp
>
>
> On 15.10.2014 14:12, Bulu wrote:
>
>> Hello All
>>
>> Using Dependency Manager, I declare adapters like this:
>> mgr.add(createAdapterService(Device.class,null)
>> .setImplementation(DeviceAdapter.class)
>> .setCallbacks(deviceManager, "init", "start", "stop", "destroy"));
>>
>> So deviceManager gets notified when the adapters appear. Now I also want
>> deviceManager to be notified when the properties of any of the adaptees
>> (Device.class) change (need to update the UI).
>>
>> For normal ServiceDependency I can specify callbacks to be called on a
>> third party object with
>> ServiceDependency.setCallbacks(Object instance, String added, String
>> changed, String removed);
>>
>> For adapters and I can specify the callbacks, but only calling the
>> adapter itself:
>> createAdapterService(Device.class.name, null, "add", "change",
>> "remove")
>>
>> How can I tell the adapter to use callbacks on a third party object
>> (deviceManager) when the adaptee's properties change?
>>
>> Thanks & regards
>> Philipp
>>
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Re: DependencyManager: notify third party object of changed adaptee
properties
Posted by Bulu <bu...@romandie.com>.
Addition to my own question:
I came up with the following, but the callbacks seem not to get called
on the deviceManager...
Component adapter = createAdapterService(Device.class,null)
.setImplementation(DeviceAdapter.class)
.setCallbacks(deviceManager, INIT_METHOD, START_METHOD, STOP_METHOD,
DESTROY_METHOD);
// Ugly: supposing the adapter has always the adaptee as first service
dependency
ServiceDependency dep = (ServiceDependency)
adapter.getDependencies().get(0);
logger.debug("Dependency is {}", dep); // OK, in my tests it's the right
dependency
dep.setCallbacks(deviceManager, BIND_METHOD, CHANGED_METHOD, UNBIND_METHOD);
mgr.add(adapter);
Is this the right way?
Regards Philipp
On 15.10.2014 14:12, Bulu wrote:
> Hello All
>
> Using Dependency Manager, I declare adapters like this:
> mgr.add(createAdapterService(Device.class,null)
> .setImplementation(DeviceAdapter.class)
> .setCallbacks(deviceManager, "init", "start", "stop", "destroy"));
>
> So deviceManager gets notified when the adapters appear. Now I also
> want deviceManager to be notified when the properties of any of the
> adaptees (Device.class) change (need to update the UI).
>
> For normal ServiceDependency I can specify callbacks to be called on a
> third party object with
> ServiceDependency.setCallbacks(Object instance, String added, String
> changed, String removed);
>
> For adapters and I can specify the callbacks, but only calling the
> adapter itself:
> createAdapterService(Device.class.name, null, "add", "change",
> "remove")
>
> How can I tell the adapter to use callbacks on a third party object
> (deviceManager) when the adaptee's properties change?
>
> Thanks & regards
> Philipp
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
DependencyManager: notify third party object of changed adaptee properties
Posted by Bulu <bu...@romandie.com>.
Hello All
Using Dependency Manager, I declare adapters like this:
mgr.add(createAdapterService(Device.class,null)
.setImplementation(DeviceAdapter.class)
.setCallbacks(deviceManager, "init", "start", "stop", "destroy"));
So deviceManager gets notified when the adapters appear. Now I also want
deviceManager to be notified when the properties of any of the adaptees
(Device.class) change (need to update the UI).
For normal ServiceDependency I can specify callbacks to be called on a
third party object with
ServiceDependency.setCallbacks(Object instance, String added, String
changed, String removed);
For adapters and I can specify the callbacks, but only calling the
adapter itself:
createAdapterService(Device.class.name, null, "add", "change", "remove")
How can I tell the adapter to use callbacks on a third party object
(deviceManager) when the adaptee's properties change?
Thanks & regards
Philipp
Re: DependencyManager: start order relevant for adapters?
Posted by Pierre De Rop <pi...@gmail.com>.
Hello Philipp;
On Wed, Oct 1, 2014 at 9:34 AM, Bulu <bu...@romandie.com> wrote:
> Hello Pierre
> Thanks. Indeed my additional conditions were not added atomically.
>
> Should the setInstanceBound(true) be called on each dependency separately
> before being added to the list?
> Does setInstanceBound() make only sense on adapters or should I call it
> for all type of components when dependencies are added in init()? (the
> JavaDoc " Sets this dependency to be instance bound or not." is not so
> helpful).
>
> Is it only for adapters that additional conditions must be added
> atomically or for all type of components?
>
>
for all types of components (and for all required dependencies defined
within the init method); and you can then add each dependency in the list
safely; then after, you can add the list atomically, using
component.add(List dependencies) method.
For instance:
class MyComponent {
void init(Component c) {
DependencyManager dm = c.getDependencyManager();
List l = new ArrayList();
l.add(dm.createServiceDependency()
.setInstanceBound(true)
.setService(OtherService1.class, "(name=xxx)")
.setRequired(true));
l.add(dm.createServiceDependency()
.setInstanceBound(true)
.setService(OtherService2.class, "(name=yyy)")
.setRequired(true));
// atomically adds the list to our component
c.add(l);
}
To clarify, in dm 3.2.0, when you add some extra-dependencies from your
init() method, the setInstanceBound(true) method ensures that when your
component is being created (because it has been injected with all initial
required dependencies defined from the Activator), then it then won't be
immediately destroyed if the dynamically added dependencies from the init
method are not yet available.
But in the DM 4.0.0, using the setInstanceBound method for all init's
dependencies has been relaxed it is not necessary to use it anymore. But we
also changed the add method, using varargs list of dependencies, so you can
define multiple extra-dependencies without using a List:
// Using DM 4.0
class MyComponent {
void init(Component component) {
DependencyManager dm = c.getDependencyManager();
// Atomically adds two dependencies in our component.
component.add(
dm.createServiceDependency()
.setInstanceBound(true)
.setService(OtherService1.class, "(name=xxx)")
.setRequired(true),
dm.createServiceDependency()
.setInstanceBound(true)
.setService(OtherService2.class, "(name=yyy)")
.setRequired(true))
);
}
}
kind regards;
/pierre
Regards Philipp
>
>
>
> On 30.09.2014 23:03, Pierre De Rop wrote:
>
>> Hello Philipp,
>>
>> I don't know if this may help, but if you are using DM 3.2.0, please don't
>> forget that if you are declaring some extra-service dependencies from your
>> init() methods (in your adapter for example), then you have to declare
>> them
>> as "instance bound" dependencies: you have to make a call to the
>> setInstanceBound(true) method on the extra dependency declared from your
>> init methods.
>>
>> And also, if you have more than one dependency to add in your init()
>> method, then you should add them atomically using a list of Dependencies,
>> passed to the dm.add(List dependencies) method.
>>
>> You can take a look at [1] for an example.
>>
>> kind regards;
>> /Pierre
>>
>> [1]
>> http://svn.apache.org/viewvc/felix/trunk/dependencymanager/
>> test/src/test/java/org/apache/felix/dm/test/integration/api/
>> MultipleExtraDependenciesTest.java?revision=1532440&view=markup
>>
>> On Tue, Sep 30, 2014 at 7:46 PM, Bulu <bu...@romandie.com> wrote:
>>
>> Obviously it works great on the small example... :-)
>>> Ergo: the problem is in my code or more complex than explained...
>>>
>>>
>>> On 30.09.2014 19:14, Marcel Offermans wrote:
>>>
>>> On 30 Sep 2014, at 9:50 am, Bulu <bu...@romandie.com> wrote:
>>>>
>>>> Hi all
>>>>
>>>>> Using DM I declare adapter services like this
>>>>>
>>>>> // without filter
>>>>> mgr.add(createAdapterService(SomeClass.class,null)
>>>>> .setImplementation(...)
>>>>> .setCallbacks(...));
>>>>>
>>>>> // with filter
>>>>> String someFilter = ...
>>>>> mgr.add(createAdapterService(OtherClass.class, someFilter))
>>>>> .setImplementation(...)
>>>>> .setCallbacks(...));
>>>>>
>>>>> I notice that, if I first start this adapter bundle and later the
>>>>> SomeClass and OtherClass appear, all get picked up correctly and
>>>>> forwarded
>>>>> to the callbacks.
>>>>>
>>>>> However, if first the SomeClass and OtherClass service are present and
>>>>> later the Adapter gets started, it only picks up the ones without
>>>>> filter
>>>>> (in the example the "SomeClass", but not the "OtherClass" services).
>>>>>
>>>>> I know the filter is correct, as it does work when done in the right
>>>>> order. The services are the same in both cases.
>>>>>
>>>>> Has anybody else noticed this? Is the problem in my code?
>>>>>
>>>>> Not sure, could you provide a small working example or test?
>>>>
>>>> Greetings, Marcel
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>>>
>
Re: DependencyManager: start order relevant for adapters?
Posted by Bulu <bu...@romandie.com>.
Hello Pierre
Thanks. Indeed my additional conditions were not added atomically.
Should the setInstanceBound(true) be called on each dependency
separately before being added to the list?
Does setInstanceBound() make only sense on adapters or should I call it
for all type of components when dependencies are added in init()? (the
JavaDoc " Sets this dependency to be instance bound or not." is not so
helpful).
Is it only for adapters that additional conditions must be added
atomically or for all type of components?
Regards Philipp
On 30.09.2014 23:03, Pierre De Rop wrote:
> Hello Philipp,
>
> I don't know if this may help, but if you are using DM 3.2.0, please don't
> forget that if you are declaring some extra-service dependencies from your
> init() methods (in your adapter for example), then you have to declare them
> as "instance bound" dependencies: you have to make a call to the
> setInstanceBound(true) method on the extra dependency declared from your
> init methods.
>
> And also, if you have more than one dependency to add in your init()
> method, then you should add them atomically using a list of Dependencies,
> passed to the dm.add(List dependencies) method.
>
> You can take a look at [1] for an example.
>
> kind regards;
> /Pierre
>
> [1]
> http://svn.apache.org/viewvc/felix/trunk/dependencymanager/test/src/test/java/org/apache/felix/dm/test/integration/api/MultipleExtraDependenciesTest.java?revision=1532440&view=markup
>
> On Tue, Sep 30, 2014 at 7:46 PM, Bulu <bu...@romandie.com> wrote:
>
>> Obviously it works great on the small example... :-)
>> Ergo: the problem is in my code or more complex than explained...
>>
>>
>> On 30.09.2014 19:14, Marcel Offermans wrote:
>>
>>> On 30 Sep 2014, at 9:50 am, Bulu <bu...@romandie.com> wrote:
>>>
>>> Hi all
>>>> Using DM I declare adapter services like this
>>>>
>>>> // without filter
>>>> mgr.add(createAdapterService(SomeClass.class,null)
>>>> .setImplementation(...)
>>>> .setCallbacks(...));
>>>>
>>>> // with filter
>>>> String someFilter = ...
>>>> mgr.add(createAdapterService(OtherClass.class, someFilter))
>>>> .setImplementation(...)
>>>> .setCallbacks(...));
>>>>
>>>> I notice that, if I first start this adapter bundle and later the
>>>> SomeClass and OtherClass appear, all get picked up correctly and forwarded
>>>> to the callbacks.
>>>>
>>>> However, if first the SomeClass and OtherClass service are present and
>>>> later the Adapter gets started, it only picks up the ones without filter
>>>> (in the example the "SomeClass", but not the "OtherClass" services).
>>>>
>>>> I know the filter is correct, as it does work when done in the right
>>>> order. The services are the same in both cases.
>>>>
>>>> Has anybody else noticed this? Is the problem in my code?
>>>>
>>> Not sure, could you provide a small working example or test?
>>>
>>> Greetings, Marcel
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
Re: DependencyManager: start order relevant for adapters?
Posted by Pierre De Rop <pi...@gmail.com>.
Hello Philipp,
I don't know if this may help, but if you are using DM 3.2.0, please don't
forget that if you are declaring some extra-service dependencies from your
init() methods (in your adapter for example), then you have to declare them
as "instance bound" dependencies: you have to make a call to the
setInstanceBound(true) method on the extra dependency declared from your
init methods.
And also, if you have more than one dependency to add in your init()
method, then you should add them atomically using a list of Dependencies,
passed to the dm.add(List dependencies) method.
You can take a look at [1] for an example.
kind regards;
/Pierre
[1]
http://svn.apache.org/viewvc/felix/trunk/dependencymanager/test/src/test/java/org/apache/felix/dm/test/integration/api/MultipleExtraDependenciesTest.java?revision=1532440&view=markup
On Tue, Sep 30, 2014 at 7:46 PM, Bulu <bu...@romandie.com> wrote:
> Obviously it works great on the small example... :-)
> Ergo: the problem is in my code or more complex than explained...
>
>
> On 30.09.2014 19:14, Marcel Offermans wrote:
>
>> On 30 Sep 2014, at 9:50 am, Bulu <bu...@romandie.com> wrote:
>>
>> Hi all
>>>
>>> Using DM I declare adapter services like this
>>>
>>> // without filter
>>> mgr.add(createAdapterService(SomeClass.class,null)
>>> .setImplementation(...)
>>> .setCallbacks(...));
>>>
>>> // with filter
>>> String someFilter = ...
>>> mgr.add(createAdapterService(OtherClass.class, someFilter))
>>> .setImplementation(...)
>>> .setCallbacks(...));
>>>
>>> I notice that, if I first start this adapter bundle and later the
>>> SomeClass and OtherClass appear, all get picked up correctly and forwarded
>>> to the callbacks.
>>>
>>> However, if first the SomeClass and OtherClass service are present and
>>> later the Adapter gets started, it only picks up the ones without filter
>>> (in the example the "SomeClass", but not the "OtherClass" services).
>>>
>>> I know the filter is correct, as it does work when done in the right
>>> order. The services are the same in both cases.
>>>
>>> Has anybody else noticed this? Is the problem in my code?
>>>
>> Not sure, could you provide a small working example or test?
>>
>> Greetings, Marcel
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Re: DependencyManager: start order relevant for adapters?
Posted by Bulu <bu...@romandie.com>.
Obviously it works great on the small example... :-)
Ergo: the problem is in my code or more complex than explained...
On 30.09.2014 19:14, Marcel Offermans wrote:
> On 30 Sep 2014, at 9:50 am, Bulu <bu...@romandie.com> wrote:
>
>> Hi all
>>
>> Using DM I declare adapter services like this
>>
>> // without filter
>> mgr.add(createAdapterService(SomeClass.class,null)
>> .setImplementation(...)
>> .setCallbacks(...));
>>
>> // with filter
>> String someFilter = ...
>> mgr.add(createAdapterService(OtherClass.class, someFilter))
>> .setImplementation(...)
>> .setCallbacks(...));
>>
>> I notice that, if I first start this adapter bundle and later the SomeClass and OtherClass appear, all get picked up correctly and forwarded to the callbacks.
>>
>> However, if first the SomeClass and OtherClass service are present and later the Adapter gets started, it only picks up the ones without filter (in the example the "SomeClass", but not the "OtherClass" services).
>>
>> I know the filter is correct, as it does work when done in the right order. The services are the same in both cases.
>>
>> Has anybody else noticed this? Is the problem in my code?
> Not sure, could you provide a small working example or test?
>
> Greetings, Marcel
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: DependencyManager: start order relevant for adapters?
Posted by Marcel Offermans <ma...@luminis.eu>.
On 30 Sep 2014, at 9:50 am, Bulu <bu...@romandie.com> wrote:
> Hi all
>
> Using DM I declare adapter services like this
>
> // without filter
> mgr.add(createAdapterService(SomeClass.class,null)
> .setImplementation(...)
> .setCallbacks(...));
>
> // with filter
> String someFilter = ...
> mgr.add(createAdapterService(OtherClass.class, someFilter))
> .setImplementation(...)
> .setCallbacks(...));
>
> I notice that, if I first start this adapter bundle and later the SomeClass and OtherClass appear, all get picked up correctly and forwarded to the callbacks.
>
> However, if first the SomeClass and OtherClass service are present and later the Adapter gets started, it only picks up the ones without filter (in the example the "SomeClass", but not the "OtherClass" services).
>
> I know the filter is correct, as it does work when done in the right order. The services are the same in both cases.
>
> Has anybody else noticed this? Is the problem in my code?
Not sure, could you provide a small working example or test?
Greetings, Marcel
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
DependencyManager: start order relevant for adapters?
Posted by Bulu <bu...@romandie.com>.
Hi all
Using DM I declare adapter services like this
// without filter
mgr.add(createAdapterService(SomeClass.class,null)
.setImplementation(...)
.setCallbacks(...));
// with filter
String someFilter = ...
mgr.add(createAdapterService(OtherClass.class, someFilter))
.setImplementation(...)
.setCallbacks(...));
I notice that, if I first start this adapter bundle and later the
SomeClass and OtherClass appear, all get picked up correctly and
forwarded to the callbacks.
However, if first the SomeClass and OtherClass service are present and
later the Adapter gets started, it only picks up the ones without filter
(in the example the "SomeClass", but not the "OtherClass" services).
I know the filter is correct, as it does work when done in the right
order. The services are the same in both cases.
Has anybody else noticed this? Is the problem in my code?
Thanks Philipp
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Comprehension question about ProtectionDomain of a Bundle
Posted by Karl Pauls <ka...@gmail.com>.
I assigned it to me. I'll try to get back to it soon.
regards,
Karl
On Mon, Sep 29, 2014 at 2:23 PM, <Di...@t-systems.com> wrote:
> 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:karlpauls@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 <fm...@adobe.com>
> wrote:
> >
> > Hi
> >
> > Am 29.09.2014 um 13:13 schrieb Karl Pauls <ka...@gmail.com>:
> >
> > > On Mon, Sep 29, 2014 at 12:56 PM, <Di...@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:karlpauls@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 <Di...@t-systems.com> <
> > >>> Dirk.Rudolph@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:karlpauls@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.Rudolph@t-systems.com<mailto:mDirk.Rudolph@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
> > >>>> karlpauls@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
> > >> karlpauls@gmail.com
> > >> http://twitter.com/karlpauls
> > >> http://www.linkedin.com/in/karlpauls
> > >> https://profiles.google.com/karlpauls
> > >>
> > >> -------------------------------------------------------------------
> > >> -- To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > >> For additional commands, e-mail: users-help@felix.apache.org
> > >>
> > >
> > >
> > >
> > > --
> > > Karl Pauls
> > > karlpauls@gmail.com
> > > http://twitter.com/karlpauls
> > > http://www.linkedin.com/in/karlpauls
> > > https://profiles.google.com/karlpauls
> >
>
>
>
> --
> Karl Pauls
> karlpauls@gmail.com
> http://twitter.com/karlpauls
> http://www.linkedin.com/in/karlpauls
> https://profiles.google.com/karlpauls
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
--
Karl Pauls
karlpauls@gmail.com
http://twitter.com/karlpauls
http://www.linkedin.com/in/karlpauls
https://profiles.google.com/karlpauls
AW: Comprehension question about ProtectionDomain of a Bundle
Posted by Di...@t-systems.com.
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:karlpauls@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 <fm...@adobe.com>
wrote:
>
> Hi
>
> Am 29.09.2014 um 13:13 schrieb Karl Pauls <ka...@gmail.com>:
>
> > On Mon, Sep 29, 2014 at 12:56 PM, <Di...@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:karlpauls@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 <Di...@t-systems.com> <
> >>> Dirk.Rudolph@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:karlpauls@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.Rudolph@t-systems.com<mailto:mDirk.Rudolph@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
> >>>> karlpauls@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
> >> karlpauls@gmail.com
> >> http://twitter.com/karlpauls
> >> http://www.linkedin.com/in/karlpauls
> >> https://profiles.google.com/karlpauls
> >>
> >> -------------------------------------------------------------------
> >> -- To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> >> For additional commands, e-mail: users-help@felix.apache.org
> >>
> >
> >
> >
> > --
> > Karl Pauls
> > karlpauls@gmail.com
> > http://twitter.com/karlpauls
> > http://www.linkedin.com/in/karlpauls
> > https://profiles.google.com/karlpauls
>
--
Karl Pauls
karlpauls@gmail.com
http://twitter.com/karlpauls
http://www.linkedin.com/in/karlpauls
https://profiles.google.com/karlpauls
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Comprehension question about ProtectionDomain of a Bundle
Posted by Karl Pauls <ka...@gmail.com>.
On Mon, Sep 29, 2014 at 1:34 PM, Felix Meschberger <fm...@adobe.com>
wrote:
>
> Hi
>
> Am 29.09.2014 um 13:13 schrieb Karl Pauls <ka...@gmail.com>:
>
> > On Mon, Sep 29, 2014 at 12:56 PM, <Di...@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:karlpauls@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 <Di...@t-systems.com> <
> >>> Dirk.Rudolph@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:karlpauls@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.Rudolph@t-systems.com<ma...@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
> >>>> karlpauls@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
> >> karlpauls@gmail.com
> >> http://twitter.com/karlpauls
> >> http://www.linkedin.com/in/karlpauls
> >> https://profiles.google.com/karlpauls
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> >> For additional commands, e-mail: users-help@felix.apache.org
> >>
> >
> >
> >
> > --
> > Karl Pauls
> > karlpauls@gmail.com
> > http://twitter.com/karlpauls
> > http://www.linkedin.com/in/karlpauls
> > https://profiles.google.com/karlpauls
>
--
Karl Pauls
karlpauls@gmail.com
http://twitter.com/karlpauls
http://www.linkedin.com/in/karlpauls
https://profiles.google.com/karlpauls
Re: Comprehension question about ProtectionDomain of a Bundle
Posted by Felix Meschberger <fm...@adobe.com>.
Hi
Am 29.09.2014 um 13:13 schrieb Karl Pauls <ka...@gmail.com>:
> On Mon, Sep 29, 2014 at 12:56 PM, <Di...@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:karlpauls@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 <Di...@t-systems.com> <
>>> Dirk.Rudolph@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:karlpauls@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.Rudolph@t-systems.com<ma...@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
>>>> karlpauls@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
>> karlpauls@gmail.com
>> http://twitter.com/karlpauls
>> http://www.linkedin.com/in/karlpauls
>> https://profiles.google.com/karlpauls
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
>
>
> --
> Karl Pauls
> karlpauls@gmail.com
> http://twitter.com/karlpauls
> http://www.linkedin.com/in/karlpauls
> https://profiles.google.com/karlpauls
Re: Comprehension question about ProtectionDomain of a Bundle
Posted by Karl Pauls <ka...@gmail.com>.
On Mon, Sep 29, 2014 at 12:56 PM, <Di...@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 but I
wouldn't be surprised if they don't (URLs and how to handle them are a mess
in java).
regards,
Karl
> Regards,
> Dirk
>
> -----Ursprüngliche Nachricht-----
> Von: Karl Pauls [mailto:karlpauls@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 <Di...@t-systems.com> <
> > Dirk.Rudolph@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:karlpauls@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.Rudolph@t-systems.com<ma...@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
> > > karlpauls@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
> karlpauls@gmail.com
> http://twitter.com/karlpauls
> http://www.linkedin.com/in/karlpauls
> https://profiles.google.com/karlpauls
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
--
Karl Pauls
karlpauls@gmail.com
http://twitter.com/karlpauls
http://www.linkedin.com/in/karlpauls
https://profiles.google.com/karlpauls
AW: Comprehension question about ProtectionDomain of a Bundle
Posted by Di...@t-systems.com.
What happens with Bundle-Location: inputstream:bundle-1.0.0.jar. Is a URLHandler available for this?
So in this case JCE implemtation of OpenJDK will not be supported by Apache Felix (OSGI in general?) out of the box?
Regards,
Dirk
-----Ursprüngliche Nachricht-----
Von: Karl Pauls [mailto:karlpauls@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 <Di...@t-systems.com> <
> Dirk.Rudolph@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:karlpauls@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.Rudolph@t-systems.com<ma...@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
> > karlpauls@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
karlpauls@gmail.com
http://twitter.com/karlpauls
http://www.linkedin.com/in/karlpauls
https://profiles.google.com/karlpauls
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Comprehension question about ProtectionDomain of a Bundle
Posted by Karl Pauls <ka...@gmail.com>.
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 <Di...@t-systems.com> <
> Dirk.Rudolph@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:karlpauls@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.Rudolph@t-systems.com<ma...@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
> > karlpauls@gmail.com
> > http://twitter.com/karlpauls
> > http://www.linkedin.com/in/karlpauls
> > https://profiles.google.com/karlpauls
> >
> B�KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB� �
> [��X��ܚX�K K[XZ[ � \�\��][��X��ܚX�P �[ ^ �\ X� K�ܙ�B��܈ Y ] [ۘ[ ��[X[�
> � K[XZ[ � \�\��Z [ �[ ^ �\ X� K�ܙ�B
>
>
--
Karl Pauls
karlpauls@gmail.com
http://twitter.com/karlpauls
http://www.linkedin.com/in/karlpauls
https://profiles.google.com/karlpauls
AW: Comprehension question about ProtectionDomain of a Bundle
Posted by Di...@t-systems.com.
The (OpenJDK-)JCE implementation uses the ProtectionDomain of the ClassLoader to get the CodeSource of the JCE provider implementation and yes the location of the CodeSource is used by the JarVerifier to check the signature of the jar and the containing files too.
So I agree with you that the CodeSource location should be a URL pointing to the actual Content not the Bundle. Additionally we have to assign the ProtectionDomain to the Content to use it when the Class gets defined in the BundleClassLoader (or we provide any other Method for this that is able to return a ProtectionDomain for a given Content). Currently the creation of the ProtectionDomain is done after a new BundleRevision has been added to the Bundle. Wouldn't it be better to create a ProtectionDomain when a Class is loaded from a certain Content?
Regards,
Dirk
-----Ursprüngliche Nachricht-----
Von: Felix Meschberger [mailto:fmeschbe@adobe.com]
Gesendet: Montag, 29. September 2014 11:53
An: users@felix.apache.org
Betreff: Re: Comprehension question about ProtectionDomain of a Bundle
Hi Dirk
Does the JCR provider use the CodeSource to actually access the JAR library to validate it in some way ? I know there is a JCE library out there, which does not nasty hacks on the ClassLoader to get to the JAR file to calculate and validate the checksum. If so, that provider would be assuming the CodeSource URL to refer to actual JAR file in use to load classes from.
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.
WDYT ?
Regards
Felix
Am 29.09.2014 um 11:27 schrieb <Di...@t-systems.com> <Di...@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:karlpauls@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.Rudolph@t-systems.com<ma...@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
> karlpauls@gmail.com
> http://twitter.com/karlpauls
> http://www.linkedin.com/in/karlpauls
> https://profiles.google.com/karlpauls
> B KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK
> KCB [ X ܚX KK[XZ[
\ \ ][ X ܚX P [^
\X K ܙ B ܈Y][ۘ[ [X[ K[XZ[
\ \ Z[ [^
\X K ܙ B
B KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB [ X ܚX KK[XZ[
\ \ ][ X ܚX P [^
\X K ܙ B ܈Y][ۘ[ [X[ K[XZ[
\ \ Z[ [^
\X K ܙ B
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Comprehension question about ProtectionDomain of a Bundle
Posted by Felix Meschberger <fm...@adobe.com>.
Hi Dirk
Does the JCR provider use the CodeSource to actually access the JAR library to validate it in some way ? I know there is a JCE library out there, which does not nasty hacks on the ClassLoader to get to the JAR file to calculate and validate the checksum. If so, that provider would be assuming the CodeSource URL to refer to actual JAR file in use to load classes from.
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.
WDYT ?
Regards
Felix
Am 29.09.2014 um 11:27 schrieb <Di...@t-systems.com> <Di...@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:karlpauls@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.Rudolph@t-systems.com<ma...@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
> karlpauls@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
AW: Comprehension question about ProtectionDomain of a Bundle
Posted by Di...@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:karlpauls@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.Rudolph@t-systems.com<ma...@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
karlpauls@gmail.com
http://twitter.com/karlpauls
http://www.linkedin.com/in/karlpauls
https://profiles.google.com/karlpauls
Re: Comprehension question about ProtectionDomain of a Bundle
Posted by Karl Pauls <ka...@gmail.com>.
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.Rudolph@t-systems.com<ma...@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
karlpauls@gmail.com
http://twitter.com/karlpauls
http://www.linkedin.com/in/karlpauls
https://profiles.google.com/karlpauls