Re: iPojo @Stereotype annotated annotation from separate bundle
Hi Milen
Can you share a minimal project to help us reproduce the issue ?
If you could zip it and attach it to a new JIRA, that would be great.
Thanks
--
Guillaume Sauthier (OW2)
Sent with Airmail
On 22 Sep 2014 at 08:27:12, Clement Escoffier (clement.escoff...@gmail.com)
wrote:
Hi,
Sorry for the late reply (should never change my email program).
So, it should not be the case. As soon as the stereotype is available in the
manipulator class path, it should be used. Obviously, if it’s in the bundle,
it’s necessarily in the class path. Could you open an issue, it’s probably a
bug.
Cheers,
Clement
On 16 septembre 2014 at 10:57:46, Milen Dyankov (milendyan...@gmail.com) wrote:
OK, my bad, I asked the question poorly.
It of course works with private-package as well (I just used the export in
my simple test).
What I intended to ask was, why the stereotype class needs to be included
in the bundle using it? In another words - isn't it enough that the bundle
imports the package and the jar is on maven's classpath?
On Mon, Sep 15, 2014 at 3:26 PM, Clement Escoffier
clement.escoff...@gmail.com wrote:
Hi,
Could you check that the stereotype class is actually included in the jar
file when not exported ? Maybe the ‘private-package’ instruction contains
the error.
Cheers,
Clement
On 15 septembre 2014 at 15:05:17, Milen Dyankov (milendyan...@gmail.com)
wrote:
OK, found the problem. It's due to how Export-Package of
the maven-bundle-plugin is configured.
Here is an example:
- I have stereotype maven project where I define a @Stereotype as
*test.ipojo.stereotype*.MyComponent
- The bundle maven project where I try to use the stereotype has its
classes in the package *test.ipojo.bundle*
When I have this in the bundle maven project :
Export-Packagetest.ipojo.bundle*;version=${project.version}/Export-Package
it does not work! What I see in the console is:
[WARNING] Class test.ipojo.bundle.ComponentByStereotype has not been marked
as a component type (no @Component, @Handler, ...). It will be ignored by
the iPOJO manipulator.
However changing this to:
Export-Package*test.ipojo.stereotype**
,test.ipojo.bundle*;version=${project.version}/Export-Package
works just fine.
While I now know how to make it work, I'm still confused why do I need to
export the stereotype package?
On Mon, Sep 15, 2014 at 11:24 AM, Milen Dyankov milendyan...@gmail.com
wrote:
Thanks for explaining how it works Clement!
I am indeed using maven and I tried to add the jar as a maven-ipojo-
plugin dependency but it still does not seem to work.
I'll play a bit with it and if it still does not work I'll try to extract
and provide a simple example so you can eventually tell me what I'm doing
wrong.
Best,
Milen
On Sat, Sep 13, 2014 at 9:01 AM, Clement Escoffier
clement.escoff...@gmail.com wrote:
Hi,
Stereotypes are analyzed at build time, not at runtime. So they are
packaged in regular jars. To work as expected, the stereotype need to be
available from the ‘manipulator’ engine, in other words: be in the same
class path.
So, if you are using Maven, you can do as follows:
plugin
groupIdorg.apache.felix/groupId
artifactIdmaven-ipojo-plugin/artifactId
executions
execution
goals
goalipojo-bundle/goal
/goals
/execution
/executions
dependencies
dependency
groupIdyour.groupId/groupId
artifactIdyour.sterotype.artifactId/artifactId
versionyour.version/version
/dependency
/dependencies
/plugin
Cheers,
Clement
On 13 septembre 2014 at 02:06:25, Milen Dyankov (milendyan...@gmail.com
)
wrote:
Hi,
Is the usage of a @Stereotype annotated annotation from another bundle
supported? It doesn't seem to work even though the package is properly
exported and imported.
The docs only say:
If the stereotyped annotation is directly in the manipulated module, no
problems: any front-end will work as expected.
If not, the different manipulator's front-end have variable support
for
the stereotype feature.
This is not very clear to me and to be honest I'm no sure what a
manipulator's front-end is.
Regards,
Milen
--
http://about.me/milen
--
http://about.me/milen
--
http://about.me/milen
--
http://about.me/milen
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 WeakHashMapClass,URL that holds the URL to the location of the CodeSource. So I assume that it might be possible that the worng CodeSource location can be returned there when the cache points to a old revision location after a bundle update without garbage collection of the old revision. Am I right? No. The Class object is unique based on its class loader so you will get the code source URL that was associated with the bundle revision that this class has been loaded from. As long as they key the map by an actual Class object and get the URL from the code source of the BundleProtectionDomain of that class object you should be good. regards, Karl Kind Regards, Dirk Rudolph T-Systems Multimedia Solutions GmbH Organisationseinheit CCS Dirk Rudolph Software-Entwicklung, OCJP Hausanschrift: Riesaer Straße 5, 01129 Dresden Postanschrift: Postfach 10 02 24, 01072 Dresden +49 351 2820-5363 (Tel) E-Mail: dirk.rudo...@t-systems.commailto:mdirk.rudo...@t-systems-mms.com Internet: http://www.t-systems-mms.comhttp://www.t-systems-mms.de/ T-Systems Multimedia Solutions GmbH Aufsichtsrat: Thilo Kusch (Vorsitzender) Geschäftsführung: Peter Klingenburg, Susanne Heger, Dr. Rolf Werner Handelsregister: Amtsgericht Dresden HRB 11433 Sitz der Gesellschaft: Dresden Ust-IdNr.: DE 811 807 949 -- Karl Pauls karlpa...@gmail.com http://twitter.com/karlpauls http://www.linkedin.com/in/karlpauls https://profiles.google.com/karlpauls
AW: Comprehension question about ProtectionDomain of a Bundle
Thanks so far for your explanations. So Am I right that each provider that installs bundles in Felix using a custom bundle location (as Sling OSGI installer does) has to provide a URL handler that is able to resolve to the proper jar file? Think about the following cases: - Install a bundle using OSGI installer, the Bundle-Location will be jcrinstall:/apps/path/install/bundle-1.0.0.jar for example - Update the bundle with the same symbolic name but another version using the webconsole, the Bundle-Location will be the same or - Install a bundle using OSGI installer, the Bundle-Location will be jcrinstall:/apps/path/install/bundle-1.0.0.jar for example - Update the bundle with the same symbolic name by removing /apps/path/install/bundle-1.0.0.jar and uploading the new version to /apps/path/install/bundle-1.1.0.jar, the Bundle-Location will also be the same Due to this the I think the location of the CodeSource should always point to the cache jar (the one the actual class is loaded from, think about embedded dependency). Otherwise it would be hard to implement a proper URLStreamHandlerService. For the JarURLConnection: Is the cached file transient? Cheers, Dirk -Ursprüngliche Nachricht- Von: Karl Pauls [mailto:karlpa...@gmail.com] Gesendet: Montag, 29. September 2014 10:23 An: users@felix.apache.org Betreff: Re: Comprehension question about ProtectionDomain of a Bundle Hi Dirk, we are using bouncycastle as jce provider in our application setup based on AEM (Apache Sling) and I got an error during jar verification. (Something with MalformedURLException). Yeah, irrc they do assume that the code source of a protection domain is a valid url which isn't necessarily the case for OSGi bundles (I'd argue they shouldn't but oh well). For my use case I fixed the issue by implementing a URLStreamHandlerService providing a URLConnection to the bundle location but during my work on this I thought about the topic more in general. I guess that it is probably ok to handle the situation like this assuming you can provide the handler. As the comment in BundleProtectionDomain.java:38 says the CodeSource of a BundleProtectionDomain should be based on the revision of the bundle not the bundle itself. (for me the bundle location is jcrinstall:/a/path/to/the/bundle.jar) You should be able to ignore this comment. The BundleProtectionDomain does indeed provide the bundle revision. It just does get the revision in a stupid way - hence, the comment to remind me that I should figure out a better (i.e., less indirect) way to provide the revision to it. Is there any reason why the bundle location is used here and not the file:///file:///\\ URL of the revision located in the cache instead? Well, the idea is that you base your security policies on the code source url. That concept would be pretty much meaningless if the code source would be the cached jar. Regardless, the cache implementation (and its layout) is mostly undefined by the spec - the code source is the Bundle-Location URL (consider, for example, the JarURLConnection of the ire: it will cache the jar file on disc as a JarFile but the url will still be the one of the source for the code source). I mentioned that unfortunatly the JceSecurity implementation has a WeakHashMapClass,URL that holds the URL to the location of the CodeSource. So I assume that it might be possible that the worng CodeSource location can be returned there when the cache points to a old revision location after a bundle update without garbage collection of the old revision. Am I right? No. The Class object is unique based on its class loader so you will get the code source URL that was associated with the bundle revision that this class has been loaded from. As long as they key the map by an actual Class object and get the URL from the code source of the BundleProtectionDomain of that class object you should be good. regards, Karl Kind Regards, Dirk Rudolph T-Systems Multimedia Solutions GmbH Organisationseinheit CCS Dirk Rudolph Software-Entwicklung, OCJP Hausanschrift: Riesaer Straße 5, 01129 Dresden Postanschrift: Postfach 10 02 24, 01072 Dresden +49 351 2820-5363 (Tel) E-Mail: dirk.rudo...@t-systems.commailto:mdirk.rudo...@t-systems-mms.com Internet: http://www.t-systems-mms.comhttp://www.t-systems-mms.de/ T-Systems Multimedia Solutions GmbH Aufsichtsrat: Thilo Kusch (Vorsitzender) Geschäftsführung: Peter Klingenburg, Susanne Heger, Dr. Rolf Werner Handelsregister: Amtsgericht Dresden HRB 11433 Sitz der Gesellschaft: Dresden Ust-IdNr.: DE 811 807 949 -- Karl Pauls karlpa...@gmail.com http://twitter.com/karlpauls http://www.linkedin.com/in/karlpauls https://profiles.google.com/karlpauls
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 dirk.rudo...@t-systems.com dirk.rudo...@t-systems.com: Thanks so far for your explanations. So Am I right that each provider that installs bundles in Felix using a custom bundle location (as Sling OSGI installer does) has to provide a URL handler that is able to resolve to the proper jar file? Think about the following cases: - Install a bundle using OSGI installer, the Bundle-Location will be jcrinstall:/apps/path/install/bundle-1.0.0.jar for example - Update the bundle with the same symbolic name but another version using the webconsole, the Bundle-Location will be the same or - Install a bundle using OSGI installer, the Bundle-Location will be jcrinstall:/apps/path/install/bundle-1.0.0.jar for example - Update the bundle with the same symbolic name by removing /apps/path/install/bundle-1.0.0.jar and uploading the new version to /apps/path/install/bundle-1.1.0.jar, the Bundle-Location will also be the same Due to this the I think the location of the CodeSource should always point to the cache jar (the one the actual class is loaded from, think about embedded dependency). Otherwise it would be hard to implement a proper URLStreamHandlerService. For the JarURLConnection: Is the cached file transient? Cheers, Dirk -Ursprüngliche Nachricht- Von: Karl Pauls [mailto:karlpa...@gmail.com] Gesendet: Montag, 29. September 2014 10:23 An: users@felix.apache.org Betreff: Re: Comprehension question about ProtectionDomain of a Bundle Hi Dirk, we are using bouncycastle as jce provider in our application setup based on AEM (Apache Sling) and I got an error during jar verification. (Something with MalformedURLException). Yeah, irrc they do assume that the code source of a protection domain is a valid url which isn't necessarily the case for OSGi bundles (I'd argue they shouldn't but oh well). For my use case I fixed the issue by implementing a URLStreamHandlerService providing a URLConnection to the bundle location but during my work on this I thought about the topic more in general. I guess that it is probably ok to handle the situation like this assuming you can provide the handler. As the comment in BundleProtectionDomain.java:38 says the CodeSource of a BundleProtectionDomain should be based on the revision of the bundle not the bundle itself. (for me the bundle location is jcrinstall:/a/path/to/the/bundle.jar) You should be able to ignore this comment. The BundleProtectionDomain does indeed provide the bundle revision. It just does get the revision in a stupid way - hence, the comment to remind me that I should figure out a better (i.e., less indirect) way to provide the revision to it. Is there any reason why the bundle location is used here and not the file:///file:///\\ URL of the revision located in the cache instead? Well, the idea is that you base your security policies on the code source url. That concept would be pretty much meaningless if the code source would be the cached jar. Regardless, the cache implementation (and its layout) is mostly undefined by the spec - the code source is the Bundle-Location URL (consider, for example, the JarURLConnection of the ire: it will cache the jar file on disc as a JarFile but the url will still be the one of the source for the code source). I mentioned that unfortunatly the JceSecurity implementation has a WeakHashMapClass,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
Re: Comprehension question about ProtectionDomain of a Bundle
In the current Felix setup, though, this URL basically just is an immutable key referring to the abstract Bundle not to the concrete contents of the Bundle. If we expect the CodeSource URL to actually refer to the location from where classes are loaded, then the BundleProtectionDomain should probably take the Content from the BundleRevisionImpl to use as the basis for the CodeSource URL. In this case, though, it is not relevant any longer what the string for the bundle location actually is. The BundleProtectionDomain does the correct thing. The problem is purely that some library assumes it can get the code source of a protection domain and access it. That is wrong and a bad hack at best but nothing we can paper over. Setting the bundle location as the code source is the correct thing to do. If you want to work with that library (or others that do make the same bad assumption) you can use a URLHandlers to make it work with your own namespace and you are good. This would only be a problem if you would reuse bundle locations for bundles that are not identically which you shouldn't do in the first place. regards, Karl WDYT ? Regards Felix Am 29.09.2014 um 11:27 schrieb dirk.rudo...@t-systems.com dirk.rudo...@t-systems.com: Thanks so far for your explanations. So Am I right that each provider that installs bundles in Felix using a custom bundle location (as Sling OSGI installer does) has to provide a URL handler that is able to resolve to the proper jar file? Think about the following cases: - Install a bundle using OSGI installer, the Bundle-Location will be jcrinstall:/apps/path/install/bundle-1.0.0.jar for example - Update the bundle with the same symbolic name but another version using the webconsole, the Bundle-Location will be the same or - Install a bundle using OSGI installer, the Bundle-Location will be jcrinstall:/apps/path/install/bundle-1.0.0.jar for example - Update the bundle with the same symbolic name by removing /apps/path/install/bundle-1.0.0.jar and uploading the new version to /apps/path/install/bundle-1.1.0.jar, the Bundle-Location will also be the same Due to this the I think the location of the CodeSource should always point to the cache jar (the one the actual class is loaded from, think about embedded dependency). Otherwise it would be hard to implement a proper URLStreamHandlerService. For the JarURLConnection: Is the cached file transient? Cheers, Dirk -Ursprüngliche Nachricht- Von: Karl Pauls [mailto:karlpa...@gmail.com] Gesendet: Montag, 29. September 2014 10:23 An: users@felix.apache.org Betreff: Re: Comprehension question about ProtectionDomain of a Bundle Hi Dirk, we are using bouncycastle as jce provider in our application setup based on AEM (Apache Sling) and I got an error during jar verification. (Something with MalformedURLException). Yeah, irrc they do assume that the code source of a protection domain is a valid url which isn't necessarily the case for OSGi bundles (I'd argue they shouldn't but oh well). For my use case I fixed the issue by implementing a URLStreamHandlerService providing a URLConnection to the bundle location but during my work on this I thought about the topic more in general. I guess that it is probably ok to handle the situation like this assuming you can provide the handler. As the comment in BundleProtectionDomain.java:38 says the CodeSource of a BundleProtectionDomain should be based on the revision of the bundle not the bundle itself. (for me the bundle location is jcrinstall:/a/path/to/the/bundle.jar) You should be able to ignore this comment. The BundleProtectionDomain does indeed provide the bundle revision. It just does get the revision in a stupid way - hence, the comment to remind me that I should figure out a better (i.e., less indirect) way to provide the revision to it. Is there any reason why the bundle location is used here and not the file:///file:///\\ URL of the revision located in the cache instead? Well, the idea is that you base your security policies on the code source url. That concept would be pretty much meaningless if the code source would be the cached jar. Regardless, the cache implementation (and its layout) is mostly undefined by the spec - the code source is the Bundle-Location URL (consider, for example, the JarURLConnection of the ire: it will cache the jar file on disc as a JarFile but the url will still be the one of the source for the code source). I mentioned that unfortunatly the JceSecurity implementation has a WeakHashMapClass,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
AW: Comprehension question about ProtectionDomain of a Bundle
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:fmesc...@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 dirk.rudo...@t-systems.com dirk.rudo...@t-systems.com: Thanks so far for your explanations. So Am I right that each provider that installs bundles in Felix using a custom bundle location (as Sling OSGI installer does) has to provide a URL handler that is able to resolve to the proper jar file? Think about the following cases: - Install a bundle using OSGI installer, the Bundle-Location will be jcrinstall:/apps/path/install/bundle-1.0.0.jar for example - Update the bundle with the same symbolic name but another version using the webconsole, the Bundle-Location will be the same or - Install a bundle using OSGI installer, the Bundle-Location will be jcrinstall:/apps/path/install/bundle-1.0.0.jar for example - Update the bundle with the same symbolic name by removing /apps/path/install/bundle-1.0.0.jar and uploading the new version to /apps/path/install/bundle-1.1.0.jar, the Bundle-Location will also be the same Due to this the I think the location of the CodeSource should always point to the cache jar (the one the actual class is loaded from, think about embedded dependency). Otherwise it would be hard to implement a proper URLStreamHandlerService. For the JarURLConnection: Is the cached file transient? Cheers, Dirk -Ursprüngliche Nachricht- Von: Karl Pauls [mailto:karlpa...@gmail.com] Gesendet: Montag, 29. September 2014 10:23 An: users@felix.apache.org Betreff: Re: Comprehension question about ProtectionDomain of a Bundle Hi Dirk, we are using bouncycastle as jce provider in our application setup based on AEM (Apache Sling) and I got an error during jar verification. (Something with MalformedURLException). Yeah, irrc they do assume that the code source of a protection domain is a valid url which isn't necessarily the case for OSGi bundles (I'd argue they shouldn't but oh well). For my use case I fixed the issue by implementing a URLStreamHandlerService providing a URLConnection to the bundle location but during my work on this I thought about the topic more in general. I guess that it is probably ok to handle the situation like this assuming you can provide the handler. As the comment in BundleProtectionDomain.java:38 says the CodeSource of a BundleProtectionDomain should be based on the revision of the bundle not the bundle itself. (for me the bundle location is jcrinstall:/a/path/to/the/bundle.jar) You should be able to ignore this comment. The BundleProtectionDomain does indeed provide the bundle revision. It just does get the revision in a stupid way - hence, the comment to remind me that I should figure out a better (i.e., less indirect) way to provide the revision to it. Is there any reason why the bundle location is used here and not the file:///file:///\\ URL of the revision located in the cache instead? Well, the idea is that you base your security policies on the code source
AW: Comprehension question about ProtectionDomain of a Bundle
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:karlpa...@gmail.com] Gesendet: Montag, 29. September 2014 12:47 An: users@felix.apache.org Betreff: Re: Comprehension question about ProtectionDomain of a Bundle In the current Felix setup, though, this URL basically just is an immutable key referring to the abstract Bundle not to the concrete contents of the Bundle. If we expect the CodeSource URL to actually refer to the location from where classes are loaded, then the BundleProtectionDomain should probably take the Content from the BundleRevisionImpl to use as the basis for the CodeSource URL. In this case, though, it is not relevant any longer what the string for the bundle location actually is. The BundleProtectionDomain does the correct thing. The problem is purely that some library assumes it can get the code source of a protection domain and access it. That is wrong and a bad hack at best but nothing we can paper over. Setting the bundle location as the code source is the correct thing to do. If you want to work with that library (or others that do make the same bad assumption) you can use a URLHandlers to make it work with your own namespace and you are good. This would only be a problem if you would reuse bundle locations for bundles that are not identically which you shouldn't do in the first place. regards, Karl WDYT ? Regards Felix Am 29.09.2014 um 11:27 schrieb dirk.rudo...@t-systems.com dirk.rudo...@t-systems.com: Thanks so far for your explanations. So Am I right that each provider that installs bundles in Felix using a custom bundle location (as Sling OSGI installer does) has to provide a URL handler that is able to resolve to the proper jar file? Think about the following cases: - Install a bundle using OSGI installer, the Bundle-Location will be jcrinstall:/apps/path/install/bundle-1.0.0.jar for example - Update the bundle with the same symbolic name but another version using the webconsole, the Bundle-Location will be the same or - Install a bundle using OSGI installer, the Bundle-Location will be jcrinstall:/apps/path/install/bundle-1.0.0.jar for example - Update the bundle with the same symbolic name by removing /apps/path/install/bundle-1.0.0.jar and uploading the new version to /apps/path/install/bundle-1.1.0.jar, the Bundle-Location will also be the same Due to this the I think the location of the CodeSource should always point to the cache jar (the one the actual class is loaded from, think about embedded dependency). Otherwise it would be hard to implement a proper URLStreamHandlerService. For the JarURLConnection: Is the cached file transient? Cheers, Dirk -Ursprüngliche Nachricht- Von: Karl Pauls [mailto:karlpa...@gmail.com] Gesendet: Montag, 29. September 2014 10:23 An: users@felix.apache.org Betreff: Re: Comprehension question about ProtectionDomain of a Bundle Hi Dirk, we are using bouncycastle as jce provider in our application setup based on AEM (Apache Sling) and I got an error during jar verification. (Something with MalformedURLException). Yeah, irrc they do assume that the code source of a protection domain is a valid url which isn't necessarily the case for OSGi bundles (I'd argue they shouldn't but oh well). For my use case I fixed the issue by implementing a URLStreamHandlerService providing a URLConnection to the bundle location but during my work on this I thought about the topic more in general. I guess that it is probably ok to handle the situation like this assuming you can provide the handler. As the comment in BundleProtectionDomain.java:38 says the CodeSource of a BundleProtectionDomain should be based on the revision of the bundle not the bundle itself. (for me the bundle location is jcrinstall:/a/path/to/the/bundle.jar) You should be able to ignore this comment. The BundleProtectionDomain does indeed provide the bundle revision. It just does get the revision in a stupid way - hence, the comment to remind me that I should figure out a better (i.e., less indirect) way to provide the revision to it. Is there any reason why the bundle location is used here and not the file:///file:///\\ URL of the revision located in the cache instead? Well, the idea is that you base your security policies on the code source url. That concept would be pretty much meaningless if the code source would be the cached jar. Regardless, the cache implementation (and its layout) is mostly undefined by the spec - the code source is the Bundle-Location URL (consider, for example, the JarURLConnection of the ire: it will cache
Re: Comprehension question about ProtectionDomain of a Bundle
On Mon, Sep 29, 2014 at 12:56 PM, dirk.rudo...@t-systems.com wrote: What happens with Bundle-Location: inputstream:bundle-1.0.0.jar. Is a URLHandler available for this? No. So in this case JCE implemtation of OpenJDK will not be supported by Apache Felix (OSGI in general?) out of the box? If you choose to give a bundle location that doesn't work than yes, you have a problem there. I suppose we could re-work the FakeURLStreamhandler to actually serve up the content of the revision. So if the OpenJDK JCE implementation would at least do the right thing with the code source url it might work 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:karlpa...@gmail.com] Gesendet: Montag, 29. September 2014 12:47 An: users@felix.apache.org Betreff: Re: Comprehension question about ProtectionDomain of a Bundle In the current Felix setup, though, this URL basically just is an immutable key referring to the abstract Bundle not to the concrete contents of the Bundle. If we expect the CodeSource URL to actually refer to the location from where classes are loaded, then the BundleProtectionDomain should probably take the Content from the BundleRevisionImpl to use as the basis for the CodeSource URL. In this case, though, it is not relevant any longer what the string for the bundle location actually is. The BundleProtectionDomain does the correct thing. The problem is purely that some library assumes it can get the code source of a protection domain and access it. That is wrong and a bad hack at best but nothing we can paper over. Setting the bundle location as the code source is the correct thing to do. If you want to work with that library (or others that do make the same bad assumption) you can use a URLHandlers to make it work with your own namespace and you are good. This would only be a problem if you would reuse bundle locations for bundles that are not identically which you shouldn't do in the first place. regards, Karl WDYT ? Regards Felix Am 29.09.2014 um 11:27 schrieb dirk.rudo...@t-systems.com dirk.rudo...@t-systems.com: Thanks so far for your explanations. So Am I right that each provider that installs bundles in Felix using a custom bundle location (as Sling OSGI installer does) has to provide a URL handler that is able to resolve to the proper jar file? Think about the following cases: - Install a bundle using OSGI installer, the Bundle-Location will be jcrinstall:/apps/path/install/bundle-1.0.0.jar for example - Update the bundle with the same symbolic name but another version using the webconsole, the Bundle-Location will be the same or - Install a bundle using OSGI installer, the Bundle-Location will be jcrinstall:/apps/path/install/bundle-1.0.0.jar for example - Update the bundle with the same symbolic name by removing /apps/path/install/bundle-1.0.0.jar and uploading the new version to /apps/path/install/bundle-1.1.0.jar, the Bundle-Location will also be the same Due to this the I think the location of the CodeSource should always point to the cache jar (the one the actual class is loaded from, think about embedded dependency). Otherwise it would be hard to implement a proper URLStreamHandlerService. For the JarURLConnection: Is the cached file transient? Cheers, Dirk -Ursprüngliche Nachricht- Von: Karl Pauls [mailto:karlpa...@gmail.com] Gesendet: Montag, 29. September 2014 10:23 An: users@felix.apache.org Betreff: Re: Comprehension question about ProtectionDomain of a Bundle Hi Dirk, we are using bouncycastle as jce provider in our application setup based on AEM (Apache Sling) and I got an error during jar verification. (Something with MalformedURLException). Yeah, irrc they do assume that the code source of a protection domain is a valid url which isn't necessarily the case for OSGi bundles (I'd argue they shouldn't but oh well). For my use case I fixed the issue by implementing a URLStreamHandlerService providing a URLConnection to the bundle location but during my work on this I thought about the topic more in general. I guess that it is probably ok to handle the situation like this assuming you can provide the handler. As the comment in BundleProtectionDomain.java:38 says the CodeSource of a BundleProtectionDomain should be based on the revision of the bundle not the bundle itself. (for me the bundle location is jcrinstall:/a/path/to/the/bundle.jar) You should be able to ignore this comment. The BundleProtectionDomain does indeed provide the bundle revision. It just does get the revision in a stupid way - hence, the comment to remind me that I should figure out a better (i.e., less
Re: Comprehension question about ProtectionDomain of a Bundle
Hi Am 29.09.2014 um 13:13 schrieb Karl Pauls karlpa...@gmail.com: On Mon, Sep 29, 2014 at 12:56 PM, dirk.rudo...@t-systems.com wrote: What happens with Bundle-Location: inputstream:bundle-1.0.0.jar. Is a URLHandler available for this? No. So in this case JCE implemtation of OpenJDK will not be supported by Apache Felix (OSGI in general?) out of the box? If you choose to give a bundle location that doesn't work than yes, you have a problem there. I suppose we could re-work the FakeURLStreamhandler to actually serve up the content of the revision. So if the OpenJDK JCE implementation would at least do the right thing with the code source url it might work I have the impression, that this might work, indeed. but I wouldn't be surprised if they don't (URLs and how to handle them are a mess in java). +100 Regards Felix regards, Karl Regards, Dirk -Ursprüngliche Nachricht- Von: Karl Pauls [mailto:karlpa...@gmail.com] Gesendet: Montag, 29. September 2014 12:47 An: users@felix.apache.org Betreff: Re: Comprehension question about ProtectionDomain of a Bundle In the current Felix setup, though, this URL basically just is an immutable key referring to the abstract Bundle not to the concrete contents of the Bundle. If we expect the CodeSource URL to actually refer to the location from where classes are loaded, then the BundleProtectionDomain should probably take the Content from the BundleRevisionImpl to use as the basis for the CodeSource URL. In this case, though, it is not relevant any longer what the string for the bundle location actually is. The BundleProtectionDomain does the correct thing. The problem is purely that some library assumes it can get the code source of a protection domain and access it. That is wrong and a bad hack at best but nothing we can paper over. Setting the bundle location as the code source is the correct thing to do. If you want to work with that library (or others that do make the same bad assumption) you can use a URLHandlers to make it work with your own namespace and you are good. This would only be a problem if you would reuse bundle locations for bundles that are not identically which you shouldn't do in the first place. regards, Karl WDYT ? Regards Felix Am 29.09.2014 um 11:27 schrieb dirk.rudo...@t-systems.com dirk.rudo...@t-systems.com: Thanks so far for your explanations. So Am I right that each provider that installs bundles in Felix using a custom bundle location (as Sling OSGI installer does) has to provide a URL handler that is able to resolve to the proper jar file? Think about the following cases: - Install a bundle using OSGI installer, the Bundle-Location will be jcrinstall:/apps/path/install/bundle-1.0.0.jar for example - Update the bundle with the same symbolic name but another version using the webconsole, the Bundle-Location will be the same or - Install a bundle using OSGI installer, the Bundle-Location will be jcrinstall:/apps/path/install/bundle-1.0.0.jar for example - Update the bundle with the same symbolic name by removing /apps/path/install/bundle-1.0.0.jar and uploading the new version to /apps/path/install/bundle-1.1.0.jar, the Bundle-Location will also be the same Due to this the I think the location of the CodeSource should always point to the cache jar (the one the actual class is loaded from, think about embedded dependency). Otherwise it would be hard to implement a proper URLStreamHandlerService. For the JarURLConnection: Is the cached file transient? Cheers, Dirk -Ursprüngliche Nachricht- Von: Karl Pauls [mailto:karlpa...@gmail.com] Gesendet: Montag, 29. September 2014 10:23 An: users@felix.apache.org Betreff: Re: Comprehension question about ProtectionDomain of a Bundle Hi Dirk, we are using bouncycastle as jce provider in our application setup based on AEM (Apache Sling) and I got an error during jar verification. (Something with MalformedURLException). Yeah, irrc they do assume that the code source of a protection domain is a valid url which isn't necessarily the case for OSGi bundles (I'd argue they shouldn't but oh well). For my use case I fixed the issue by implementing a URLStreamHandlerService providing a URLConnection to the bundle location but during my work on this I thought about the topic more in general. I guess that it is probably ok to handle the situation like this assuming you can provide the handler. As the comment in BundleProtectionDomain.java:38 says the CodeSource of a BundleProtectionDomain should be based on the revision of the bundle not the bundle itself. (for me the bundle location is jcrinstall:/a/path/to/the/bundle.jar) You should be able to ignore this comment. The BundleProtectionDomain does indeed provide the bundle revision. It just does get the revision in a stupid way - hence, the comment to remind
AW: Comprehension question about ProtectionDomain of a Bundle
I agree with you too. Should I open an issue for that? The last think what I do not understand is the role of the FakeURLStreamHandler itself. The Class comment says it should prevent any unknown protocol errors. But why did I get a unknown protocol error for jcrinstall? Regards, Dirk -Ursprüngliche Nachricht- Von: Felix Meschberger [mailto:fmesc...@adobe.com] Gesendet: Montag, 29. September 2014 13:34 An: users@felix.apache.org Betreff: Re: Comprehension question about ProtectionDomain of a Bundle Hi Am 29.09.2014 um 13:13 schrieb Karl Pauls karlpa...@gmail.com: On Mon, Sep 29, 2014 at 12:56 PM, dirk.rudo...@t-systems.com wrote: What happens with Bundle-Location: inputstream:bundle-1.0.0.jar. Is a URLHandler available for this? No. So in this case JCE implemtation of OpenJDK will not be supported by Apache Felix (OSGI in general?) out of the box? If you choose to give a bundle location that doesn't work than yes, you have a problem there. I suppose we could re-work the FakeURLStreamhandler to actually serve up the content of the revision. So if the OpenJDK JCE implementation would at least do the right thing with the code source url it might work I have the impression, that this might work, indeed. but I wouldn't be surprised if they don't (URLs and how to handle them are a mess in java). +100 Regards Felix regards, Karl Regards, Dirk -Ursprüngliche Nachricht- Von: Karl Pauls [mailto:karlpa...@gmail.com] Gesendet: Montag, 29. September 2014 12:47 An: users@felix.apache.org Betreff: Re: Comprehension question about ProtectionDomain of a Bundle In the current Felix setup, though, this URL basically just is an immutable key referring to the abstract Bundle not to the concrete contents of the Bundle. If we expect the CodeSource URL to actually refer to the location from where classes are loaded, then the BundleProtectionDomain should probably take the Content from the BundleRevisionImpl to use as the basis for the CodeSource URL. In this case, though, it is not relevant any longer what the string for the bundle location actually is. The BundleProtectionDomain does the correct thing. The problem is purely that some library assumes it can get the code source of a protection domain and access it. That is wrong and a bad hack at best but nothing we can paper over. Setting the bundle location as the code source is the correct thing to do. If you want to work with that library (or others that do make the same bad assumption) you can use a URLHandlers to make it work with your own namespace and you are good. This would only be a problem if you would reuse bundle locations for bundles that are not identically which you shouldn't do in the first place. regards, Karl WDYT ? Regards Felix Am 29.09.2014 um 11:27 schrieb dirk.rudo...@t-systems.com dirk.rudo...@t-systems.com: Thanks so far for your explanations. So Am I right that each provider that installs bundles in Felix using a custom bundle location (as Sling OSGI installer does) has to provide a URL handler that is able to resolve to the proper jar file? Think about the following cases: - Install a bundle using OSGI installer, the Bundle-Location will be jcrinstall:/apps/path/install/bundle-1.0.0.jar for example - Update the bundle with the same symbolic name but another version using the webconsole, the Bundle-Location will be the same or - Install a bundle using OSGI installer, the Bundle-Location will be jcrinstall:/apps/path/install/bundle-1.0.0.jar for example - Update the bundle with the same symbolic name by removing /apps/path/install/bundle-1.0.0.jar and uploading the new version to /apps/path/install/bundle-1.1.0.jar, the Bundle-Location will also be the same Due to this the I think the location of the CodeSource should always point to the cache jar (the one the actual class is loaded from, think about embedded dependency). Otherwise it would be hard to implement a proper URLStreamHandlerService. For the JarURLConnection: Is the cached file transient? Cheers, Dirk -Ursprüngliche Nachricht- Von: Karl Pauls [mailto:karlpa...@gmail.com] Gesendet: Montag, 29. September 2014 10:23 An: users@felix.apache.org Betreff: Re: Comprehension question about ProtectionDomain of a Bundle Hi Dirk, we are using bouncycastle as jce provider in our application setup based on AEM (Apache Sling) and I got an error during jar verification. (Something with MalformedURLException). Yeah, irrc they do assume that the code source of a protection domain is a valid url which isn't necessarily the case for OSGi bundles (I'd argue they shouldn't but oh well). For my use case I fixed the issue by implementing a URLStreamHandlerService providing a URLConnection to the bundle location but during my work on this I thought about the topic more
Re: Comprehension question about ProtectionDomain of a Bundle
On Mon, Sep 29, 2014 at 1:34 PM, Felix Meschberger fmesc...@adobe.com wrote: Hi Am 29.09.2014 um 13:13 schrieb Karl Pauls karlpa...@gmail.com: On Mon, Sep 29, 2014 at 12:56 PM, dirk.rudo...@t-systems.com wrote: What happens with Bundle-Location: inputstream:bundle-1.0.0.jar. Is a URLHandler available for this? No. So in this case JCE implemtation of OpenJDK will not be supported by Apache Felix (OSGI in general?) out of the box? If you choose to give a bundle location that doesn't work than yes, you have a problem there. I suppose we could re-work the FakeURLStreamhandler to actually serve up the content of the revision. So if the OpenJDK JCE implementation would at least do the right thing with the code source url it might work I have the impression, that this might work, indeed. The only way it might work (again, this is hacking a hack so ymmv) is to override the JarUrl subsystem (and it will probably involve creating copies of stuff all over the place to make it work with the reference: protocol - which i wouldn't do initially). I can do it (please open a jira issue and assign it to me if you want that) but keep in mind that it will be a very brittle solution to the problem as it depends on the using library to do the right thing in regards to URLs (which mostly will not happen) - but it should work for the OpenJdk impl. regards, Karl but I wouldn't be surprised if they don't (URLs and how to handle them are a mess in java). +100 Regards Felix regards, Karl Regards, Dirk -Ursprüngliche Nachricht- Von: Karl Pauls [mailto:karlpa...@gmail.com] Gesendet: Montag, 29. September 2014 12:47 An: users@felix.apache.org Betreff: Re: Comprehension question about ProtectionDomain of a Bundle In the current Felix setup, though, this URL basically just is an immutable key referring to the abstract Bundle not to the concrete contents of the Bundle. If we expect the CodeSource URL to actually refer to the location from where classes are loaded, then the BundleProtectionDomain should probably take the Content from the BundleRevisionImpl to use as the basis for the CodeSource URL. In this case, though, it is not relevant any longer what the string for the bundle location actually is. The BundleProtectionDomain does the correct thing. The problem is purely that some library assumes it can get the code source of a protection domain and access it. That is wrong and a bad hack at best but nothing we can paper over. Setting the bundle location as the code source is the correct thing to do. If you want to work with that library (or others that do make the same bad assumption) you can use a URLHandlers to make it work with your own namespace and you are good. This would only be a problem if you would reuse bundle locations for bundles that are not identically which you shouldn't do in the first place. regards, Karl WDYT ? Regards Felix Am 29.09.2014 um 11:27 schrieb dirk.rudo...@t-systems.com dirk.rudo...@t-systems.com: Thanks so far for your explanations. So Am I right that each provider that installs bundles in Felix using a custom bundle location (as Sling OSGI installer does) has to provide a URL handler that is able to resolve to the proper jar file? Think about the following cases: - Install a bundle using OSGI installer, the Bundle-Location will be jcrinstall:/apps/path/install/bundle-1.0.0.jar for example - Update the bundle with the same symbolic name but another version using the webconsole, the Bundle-Location will be the same or - Install a bundle using OSGI installer, the Bundle-Location will be jcrinstall:/apps/path/install/bundle-1.0.0.jar for example - Update the bundle with the same symbolic name by removing /apps/path/install/bundle-1.0.0.jar and uploading the new version to /apps/path/install/bundle-1.1.0.jar, the Bundle-Location will also be the same Due to this the I think the location of the CodeSource should always point to the cache jar (the one the actual class is loaded from, think about embedded dependency). Otherwise it would be hard to implement a proper URLStreamHandlerService. For the JarURLConnection: Is the cached file transient? Cheers, Dirk -Ursprüngliche Nachricht- Von: Karl Pauls [mailto:karlpa...@gmail.com] Gesendet: Montag, 29. September 2014 10:23 An: users@felix.apache.org Betreff: Re: Comprehension question about ProtectionDomain of a Bundle Hi Dirk, we are using bouncycastle as jce provider in our application setup based on AEM (Apache Sling) and I got an error during jar verification. (Something with MalformedURLException). Yeah, irrc they do assume that the code source of a protection domain is a valid url which isn't necessarily the case for OSGi bundles (I'd argue they shouldn't but oh well).
AW: Comprehension question about ProtectionDomain of a Bundle
I created an issues: FELIX-4658. I hope the description and title are ok :) Unfortunately I'm not allowed to assign it to you but I am very interested in your solution. Thanks so far, Dirk -Ursprüngliche Nachricht- Von: Karl Pauls [mailto:karlpa...@gmail.com] Gesendet: Montag, 29. September 2014 14:00 An: users@felix.apache.org Betreff: Re: Comprehension question about ProtectionDomain of a Bundle On Mon, Sep 29, 2014 at 1:34 PM, Felix Meschberger fmesc...@adobe.com wrote: Hi Am 29.09.2014 um 13:13 schrieb Karl Pauls karlpa...@gmail.com: On Mon, Sep 29, 2014 at 12:56 PM, dirk.rudo...@t-systems.com wrote: What happens with Bundle-Location: inputstream:bundle-1.0.0.jar. Is a URLHandler available for this? No. So in this case JCE implemtation of OpenJDK will not be supported by Apache Felix (OSGI in general?) out of the box? If you choose to give a bundle location that doesn't work than yes, you have a problem there. I suppose we could re-work the FakeURLStreamhandler to actually serve up the content of the revision. So if the OpenJDK JCE implementation would at least do the right thing with the code source url it might work I have the impression, that this might work, indeed. The only way it might work (again, this is hacking a hack so ymmv) is to override the JarUrl subsystem (and it will probably involve creating copies of stuff all over the place to make it work with the reference: protocol - which i wouldn't do initially). I can do it (please open a jira issue and assign it to me if you want that) but keep in mind that it will be a very brittle solution to the problem as it depends on the using library to do the right thing in regards to URLs (which mostly will not happen) - but it should work for the OpenJdk impl. regards, Karl but I wouldn't be surprised if they don't (URLs and how to handle them are a mess in java). +100 Regards Felix regards, Karl Regards, Dirk -Ursprüngliche Nachricht- Von: Karl Pauls [mailto:karlpa...@gmail.com] Gesendet: Montag, 29. September 2014 12:47 An: users@felix.apache.org Betreff: Re: Comprehension question about ProtectionDomain of a Bundle In the current Felix setup, though, this URL basically just is an immutable key referring to the abstract Bundle not to the concrete contents of the Bundle. If we expect the CodeSource URL to actually refer to the location from where classes are loaded, then the BundleProtectionDomain should probably take the Content from the BundleRevisionImpl to use as the basis for the CodeSource URL. In this case, though, it is not relevant any longer what the string for the bundle location actually is. The BundleProtectionDomain does the correct thing. The problem is purely that some library assumes it can get the code source of a protection domain and access it. That is wrong and a bad hack at best but nothing we can paper over. Setting the bundle location as the code source is the correct thing to do. If you want to work with that library (or others that do make the same bad assumption) you can use a URLHandlers to make it work with your own namespace and you are good. This would only be a problem if you would reuse bundle locations for bundles that are not identically which you shouldn't do in the first place. regards, Karl WDYT ? Regards Felix Am 29.09.2014 um 11:27 schrieb dirk.rudo...@t-systems.com dirk.rudo...@t-systems.com: Thanks so far for your explanations. So Am I right that each provider that installs bundles in Felix using a custom bundle location (as Sling OSGI installer does) has to provide a URL handler that is able to resolve to the proper jar file? Think about the following cases: - Install a bundle using OSGI installer, the Bundle-Location will be jcrinstall:/apps/path/install/bundle-1.0.0.jar for example - Update the bundle with the same symbolic name but another version using the webconsole, the Bundle-Location will be the same or - Install a bundle using OSGI installer, the Bundle-Location will be jcrinstall:/apps/path/install/bundle-1.0.0.jar for example - Update the bundle with the same symbolic name by removing /apps/path/install/bundle-1.0.0.jar and uploading the new version to /apps/path/install/bundle-1.1.0.jar, the Bundle-Location will also be the same Due to this the I think the location of the CodeSource should always point to the cache jar (the one the actual class is loaded from, think about embedded dependency). Otherwise it would be hard to implement a proper URLStreamHandlerService. For the JarURLConnection: Is the cached file transient? Cheers, Dirk -Ursprüngliche Nachricht- Von: Karl Pauls [mailto:karlpa...@gmail.com] Gesendet: Montag, 29. September 2014 10:23 An:
Re: Comprehension question about ProtectionDomain of a Bundle
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, dirk.rudo...@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:karlpa...@gmail.com] Gesendet: Montag, 29. September 2014 14:00 An: users@felix.apache.org Betreff: Re: Comprehension question about ProtectionDomain of a Bundle On Mon, Sep 29, 2014 at 1:34 PM, Felix Meschberger fmesc...@adobe.com wrote: Hi Am 29.09.2014 um 13:13 schrieb Karl Pauls karlpa...@gmail.com: On Mon, Sep 29, 2014 at 12:56 PM, dirk.rudo...@t-systems.com wrote: What happens with Bundle-Location: inputstream:bundle-1.0.0.jar. Is a URLHandler available for this? No. So in this case JCE implemtation of OpenJDK will not be supported by Apache Felix (OSGI in general?) out of the box? If you choose to give a bundle location that doesn't work than yes, you have a problem there. I suppose we could re-work the FakeURLStreamhandler to actually serve up the content of the revision. So if the OpenJDK JCE implementation would at least do the right thing with the code source url it might work I have the impression, that this might work, indeed. The only way it might work (again, this is hacking a hack so ymmv) is to override the JarUrl subsystem (and it will probably involve creating copies of stuff all over the place to make it work with the reference: protocol - which i wouldn't do initially). I can do it (please open a jira issue and assign it to me if you want that) but keep in mind that it will be a very brittle solution to the problem as it depends on the using library to do the right thing in regards to URLs (which mostly will not happen) - but it should work for the OpenJdk impl. regards, Karl but I wouldn't be surprised if they don't (URLs and how to handle them are a mess in java). +100 Regards Felix regards, Karl Regards, Dirk -Ursprüngliche Nachricht- Von: Karl Pauls [mailto:karlpa...@gmail.com] Gesendet: Montag, 29. September 2014 12:47 An: users@felix.apache.org Betreff: Re: Comprehension question about ProtectionDomain of a Bundle In the current Felix setup, though, this URL basically just is an immutable key referring to the abstract Bundle not to the concrete contents of the Bundle. If we expect the CodeSource URL to actually refer to the location from where classes are loaded, then the BundleProtectionDomain should probably take the Content from the BundleRevisionImpl to use as the basis for the CodeSource URL. In this case, though, it is not relevant any longer what the string for the bundle location actually is. The BundleProtectionDomain does the correct thing. The problem is purely that some library assumes it can get the code source of a protection domain and access it. That is wrong and a bad hack at best but nothing we can paper over. Setting the bundle location as the code source is the correct thing to do. If you want to work with that library (or others that do make the same bad assumption) you can use a URLHandlers to make it work with your own namespace and you are good. This would only be a problem if you would reuse bundle locations for bundles that are not identically which you shouldn't do in the first place. regards, Karl WDYT ? Regards Felix Am 29.09.2014 um 11:27 schrieb dirk.rudo...@t-systems.com dirk.rudo...@t-systems.com: Thanks so far for your explanations. So Am I right that each provider that installs bundles in Felix using a custom bundle location (as Sling OSGI installer does) has to provide a URL handler that is able to resolve to the proper jar file? Think about the following cases: - Install a bundle using OSGI installer, the Bundle-Location will be jcrinstall:/apps/path/install/bundle-1.0.0.jar for example - Update the bundle with the same symbolic name but another version using the webconsole, the Bundle-Location will be the same or - Install a bundle using OSGI installer, the Bundle-Location will be jcrinstall:/apps/path/install/bundle-1.0.0.jar for example - Update the bundle with the same symbolic name by removing /apps/path/install/bundle-1.0.0.jar and uploading the new version to /apps/path/install/bundle-1.1.0.jar, the Bundle-Location will also be the same Due to this the I think the location of the CodeSource should always point to the cache jar (the one the actual class is loaded from, think about embedded dependency). Otherwise it would be hard to implement a proper
Re: iPojo @Stereotype annotated annotation from separate bundle
I can but most likely not before next week.
Thanks
On Mon, Sep 29, 2014 at 1:00 AM, Guillaume Sauthier (OW2)
guillaume@gmail.com wrote:
Hi Milen
Can you share a minimal project to help us reproduce the issue ?
If you could zip it and attach it to a new JIRA, that would be great.
Thanks
--
Guillaume Sauthier (OW2)
Sent with Airmail
On 22 Sep 2014 at 08:27:12, Clement Escoffier (clement.escoff...@gmail.com)
wrote:
Hi,
Sorry for the late reply (should never change my email program).
So, it should not be the case. As soon as the stereotype is available in
the manipulator class path, it should be used. Obviously, if it’s in the
bundle, it’s necessarily in the class path. Could you open an issue, it’s
probably a bug.
Cheers,
Clement
On 16 septembre 2014 at 10:57:46, Milen Dyankov (milendyan...@gmail.com)
wrote:
OK, my bad, I asked the question poorly.
It of course works with private-package as well (I just used the export in
my simple test).
What I intended to ask was, why the stereotype class needs to be included
in the bundle using it? In another words - isn't it enough that the bundle
imports the package and the jar is on maven's classpath?
On Mon, Sep 15, 2014 at 3:26 PM, Clement Escoffier
clement.escoff...@gmail.com wrote:
Hi,
Could you check that the stereotype class is actually included in the jar
file when not exported ? Maybe the ‘private-package’ instruction contains
the error.
Cheers,
Clement
On 15 septembre 2014 at 15:05:17, Milen Dyankov (milendyan...@gmail.com)
wrote:
OK, found the problem. It's due to how Export-Package of
the maven-bundle-plugin is configured.
Here is an example:
- I have stereotype maven project where I define a @Stereotype as
*test.ipojo.stereotype*.MyComponent
- The bundle maven project where I try to use the stereotype has its
classes in the package *test.ipojo.bundle*
When I have this in the bundle maven project :
Export-Packagetest.ipojo.bundle*;version=${project.version}/Export-Package
it does not work! What I see in the console is:
[WARNING] Class test.ipojo.bundle.ComponentByStereotype has not been
marked
as a component type (no @Component, @Handler, ...). It will be ignored by
the iPOJO manipulator.
However changing this to:
Export-Package*test.ipojo.stereotype**
,test.ipojo.bundle*;version=${project.version}/Export-Package
works just fine.
While I now know how to make it work, I'm still confused why do I need to
export the stereotype package?
On Mon, Sep 15, 2014 at 11:24 AM, Milen Dyankov milendyan...@gmail.com
wrote:
Thanks for explaining how it works Clement!
I am indeed using maven and I tried to add the jar as a maven-ipojo-
plugin dependency but it still does not seem to work.
I'll play a bit with it and if it still does not work I'll try to
extract
and provide a simple example so you can eventually tell me what I'm
doing
wrong.
Best,
Milen
On Sat, Sep 13, 2014 at 9:01 AM, Clement Escoffier
clement.escoff...@gmail.com wrote:
Hi,
Stereotypes are analyzed at build time, not at runtime. So they are
packaged in regular jars. To work as expected, the stereotype need to
be
available from the ‘manipulator’ engine, in other words: be in the
same
class path.
So, if you are using Maven, you can do as follows:
plugin
groupIdorg.apache.felix/groupId
artifactIdmaven-ipojo-plugin/artifactId
executions
execution
goals
goalipojo-bundle/goal
/goals
/execution
/executions
dependencies
dependency
groupIdyour.groupId/groupId
artifactIdyour.sterotype.artifactId/artifactId
versionyour.version/version
/dependency
/dependencies
/plugin
Cheers,
Clement
On 13 septembre 2014 at 02:06:25, Milen Dyankov (
milendyan...@gmail.com
)
wrote:
Hi,
Is the usage of a @Stereotype annotated annotation from another bundle
supported? It doesn't seem to work even though the package is properly
exported and imported.
The docs only say:
If the stereotyped annotation is directly in the manipulated module,
no
problems: any front-end will work as expected.
If not, the different manipulator's front-end have variable support
for
the stereotype feature.
This is not very clear to me and to be honest I'm no sure what a
manipulator's front-end is.
Regards,
Milen
--
http://about.me/milen
--
http://about.me/milen
--
http://about.me/milen
--
http://about.me/milen
--
http://about.me/milen
