Re: Configurable Extension Bundle system
On Thu, Oct 25, 2012 at 5:15 PM, Raymond Auge raymond.a...@liferay.com wrote: Hello All, I'd like to bump this issue as it appears to be a problem not only with Felix, but also with Equinox and I'd like to clarify the issue. It appears that even though an OSGi framework can be embedded, it does not appear there is any protection from the case where it is embedded within another OSGi container. For instance, while Miguel has highlighted the issue down to a very specific error, the problem just seems to be that an embedded framework sees, and loads the extension bundles deployed to a higher level container, at least it does if the developer does not use very strict classloader isolation such as themselves delegating to an isolated container. Yes and no. I don't think that it is required to do it like this by the spec but we do it this way. The proper way would probably to require to have felix be loaded by a special, felix provided class loader (or maybe at least a classloader with a felix specific interface). We can certainly do that (and as of right now it looks like we have no choice). If you want to use extension bundles then yes. However, keep in mind that if you know the extension bundle(s) in question up-front you might as well just put them in the same classloader and delegte the packages down -- hence, yes, if you need to support dynamic installation of extension bundles with felix embedded inside an environment that doesn't load felix with a URLclassloader (or doesn't use the URLclassloader as the normal one would) you have no choice atm. However, it wouldn't be a terribly difficult problem to solve. I'd like to propose that a small feature be added which allows for the extension mechanism to be defined as: a) using a specific classpath (as a property, from which we could create a URLClassLoader) I'm not sure I understand what you are proposing. The point is that one can dynamically install extension bundles which become part of the classloader that loaded felix. How would a) help there? b) pass an actual ClassLoader object during init as part of the configuration map associated with a extension loader property. So this classloader would be doing what? If it is a URLclassloader we could try to hack it like we currently do but if we need to add extensions it would be much better to have a defined interface, no? In both cases (which would not be the default of course), the classLoader in question would be used to load framework extensions. I'm missing how your external classloader would merge with the classloader that loaded felix. Would it have to delegate to it? If we (Miguel and I) implemented this, would it be acceptable/considered? Well, I'm certainly not against doing something better than we currently do. It clearly is a hack and has caused problems before. Additionally, I can't see any reason why we wouldn't consider a reasonable approach and a corresponding implementation, provided, all the ip is cleared etc. That said, lets not jump the gun - maybe you should first describe how your proposed solution would look like in a little more detail so that we see that it does cover what we need it to do. regards, Karl Note, that I will be proposing the same concept to the equinox project and making a similar offer to implement the addition. Sincerely, - Ray On Tue, Oct 2, 2012 at 5:28 AM, Miguel Angel Pastor Olivar miguelinl...@gmail.com wrote: Karl, I have created this ticket: https://issues.apache.org/jira/browse/FELIX-3696 Let me know if I can help in some way. Thx!! On 2 October 2012 10:05, Karl Pauls karlpa...@gmail.com wrote: On Tue, Oct 2, 2012 at 9:47 AM, Miguel Angel Pastor Olivar miguelinl...@gmail.com wrote: Ok, First of all sorry for not being too explicit. I will try to give some more details: - I am embedding Apache Felix (and Equinox because I would like to switch depending on the application server I am running on). - - The xalan ExtensionHandler executes something like this: ObjectFactory.findProviderClass(className, ObjectFactory.findClassLoader(), true) - The className has the format java:PortletBridge ( I am embedding the OSGI container into Liferay portal :) ) - The extension manager have already added the extension loader to the classloader Felix.m_secureAction.addURLToURLClassLoader(Felix.m_secureAction.createURL(Felix.m_secureAction.createURL(null, http:, extensionManager),http://felix.extensions:9/;, extensionManager), Felix.class.getClassLoader()); - When resolving the java:xxPortletBridge the previous loader added by the ExtensionManager cause an unhandled error. Well, it shouldn't do that I guess - maybe you could create a jira issue as a bug report against the framework and give me some more information like stack trace of the error etc. and I can see whether we
[jira] [Created] (FELIX-3737) HttpFilter service.ranking is not evaluated properly under some circumstances
Philipp Marx created FELIX-3737:
---
Summary: HttpFilter service.ranking is not evaluated properly
under some circumstances
Key: FELIX-3737
URL: https://issues.apache.org/jira/browse/FELIX-3737
Project: Felix
Issue Type: Bug
Components: HTTP Service
Affects Versions: http-2.2.0
Reporter: Philipp Marx
Priority: Minor
If a Http-Filter is registered with a service.ranking of Interger.MAX_VALUE and
another Http-Filter is registered with a negative service.ranking (like
org.apache.sling.i18n.impl.I18NFilter which has -700) the evaluation of the
sorting order (mostly) fails.
The problem is FilterHandler's compareTo method which leads to an overflow in
this case:
public int compareTo(FilterHandler other)
{
return other.ranking - this.ranking;
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Configurable Extension Bundle system
Hi, Am 25.10.2012 um 17:15 schrieb Raymond Auge: Hello All, I'd like to bump this issue as it appears to be a problem not only with Felix, but also with Equinox and I'd like to clarify the issue. It appears that even though an OSGi framework can be embedded, it does not appear there is any protection from the case where it is embedded within another OSGi container. For instance, while Miguel has highlighted the issue down to a very specific error, the problem just seems to be that an embedded framework sees, and loads the extension bundles deployed to a higher level container, at least it does if the developer does not use very strict classloader isolation such as themselves delegating to an isolated container. We can certainly do that (and as of right now it looks like we have no choice). However, it wouldn't be a terribly difficult problem to solve. I'd like to propose that a small feature be added which allows for the extension mechanism to be defined as: a) using a specific classpath (as a property, from which we could create a URLClassLoader) b) pass an actual ClassLoader object during init as part of the configuration map associated with a extension loader property. In both cases (which would not be the default of course), the classLoader in question would be used to load framework extensions. That's exactly what we do in the Sling Launchpad Base module to encapsulate the framework from the environment (our experience is deploying the Sling's OSGi framework as a web application in an OSGi-based servlet container). Regards Felix If we (Miguel and I) implemented this, would it be acceptable/considered? Note, that I will be proposing the same concept to the equinox project and making a similar offer to implement the addition. Sincerely, - Ray On Tue, Oct 2, 2012 at 5:28 AM, Miguel Angel Pastor Olivar miguelinl...@gmail.com wrote: Karl, I have created this ticket: https://issues.apache.org/jira/browse/FELIX-3696 Let me know if I can help in some way. Thx!! On 2 October 2012 10:05, Karl Pauls karlpa...@gmail.com wrote: On Tue, Oct 2, 2012 at 9:47 AM, Miguel Angel Pastor Olivar miguelinl...@gmail.com wrote: Ok, First of all sorry for not being too explicit. I will try to give some more details: - I am embedding Apache Felix (and Equinox because I would like to switch depending on the application server I am running on). - - The xalan ExtensionHandler executes something like this: ObjectFactory.findProviderClass(className, ObjectFactory.findClassLoader(), true) - The className has the format java:PortletBridge ( I am embedding the OSGI container into Liferay portal :) ) - The extension manager have already added the extension loader to the classloader Felix.m_secureAction.addURLToURLClassLoader(Felix.m_secureAction.createURL(Felix.m_secureAction.createURL(null, http:, extensionManager),http://felix.extensions:9/;, extensionManager), Felix.class.getClassLoader()); - When resolving the java:xxPortletBridge the previous loader added by the ExtensionManager cause an unhandled error. Well, it shouldn't do that I guess - maybe you could create a jira issue as a bug report against the framework and give me some more information like stack trace of the error etc. and I can see whether we can fix that. In addition; when trying to embed the container inside JBoss 7+ the extension manager fails to load because it is not being loaded by an instance of the URLClassloader (it is not really a problem) Yeah, that makes sense and is working as designed. If we can't add ourself to a urlclassloader we just don't provide extension bundle support but should continue to work correctly. As I have said in the previous mail, isolating the the framework into its own classloader is working but it is trickier. If you don't need extension bundle support you shouldn't have to do that then. Your real problems seems to be a bug in the extension manager that prevents it from working with your third-party library even so it likely should. Please create a bug report and lets try to fix the bug. regards, Karl So this was the reason of asking you guys! Thx a lot! On 2 October 2012 09:20, Karl Pauls karlpa...@gmail.com wrote: I am using Apache Felix as the internal OSGI container inside a webapp. The extension bundle manager adds the extension loader to the classloader which is causing me many headaches because some thirty-part libraries. What is the problem exactly? If you don't have any extension bundles, why would this cause problems (let alone with third-party libs)? My first solution was to isolate the embedded container into its own classloader but I think this approach adds too much complexity. Should be possible to make the Extension Bundle manager to be configurable? I mean, disabling it could cause some other problems
[jira] [Assigned] (FELIX-3737) HttpFilter service.ranking is not evaluated properly under some circumstances
[
https://issues.apache.org/jira/browse/FELIX-3737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Felix Meschberger reassigned FELIX-3737:
Assignee: Felix Meschberger
HttpFilter service.ranking is not evaluated properly under some circumstances
-
Key: FELIX-3737
URL: https://issues.apache.org/jira/browse/FELIX-3737
Project: Felix
Issue Type: Bug
Components: HTTP Service
Affects Versions: http-2.2.0
Reporter: Philipp Marx
Assignee: Felix Meschberger
Priority: Minor
Original Estimate: 1h
Remaining Estimate: 1h
If a Http-Filter is registered with a service.ranking of Interger.MAX_VALUE
and another Http-Filter is registered with a negative service.ranking (like
org.apache.sling.i18n.impl.I18NFilter which has -700) the evaluation of the
sorting order (mostly) fails.
The problem is FilterHandler's compareTo method which leads to an overflow in
this case:
public int compareTo(FilterHandler other)
{
return other.ranking - this.ranking;
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3737) HttpFilter service.ranking is not evaluated properly under some circumstances
[
https://issues.apache.org/jira/browse/FELIX-3737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13484901#comment-13484901
]
Felix Meschberger commented on FELIX-3737:
--
Thanks for reporting.
Fixed in Rev. 1402499. Can you confirm it works for your ? Thanks.
HttpFilter service.ranking is not evaluated properly under some circumstances
-
Key: FELIX-3737
URL: https://issues.apache.org/jira/browse/FELIX-3737
Project: Felix
Issue Type: Bug
Components: HTTP Service
Affects Versions: http-2.2.0
Reporter: Philipp Marx
Assignee: Felix Meschberger
Priority: Minor
Original Estimate: 1h
Remaining Estimate: 1h
If a Http-Filter is registered with a service.ranking of Interger.MAX_VALUE
and another Http-Filter is registered with a negative service.ranking (like
org.apache.sling.i18n.impl.I18NFilter which has -700) the evaluation of the
sorting order (mostly) fails.
The problem is FilterHandler's compareTo method which leads to an overflow in
this case:
public int compareTo(FilterHandler other)
{
return other.ranking - this.ranking;
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Configurable Extension Bundle system
Hi Am 26.10.2012 um 15:21 schrieb Raymond Auge: On Fri, Oct 26, 2012 at 8:52 AM, Felix Meschberger fmesc...@adobe.comwrote: Hi, Am 25.10.2012 um 17:15 schrieb Raymond Auge: Hello All, I'd like to bump this issue as it appears to be a problem not only with Felix, but also with Equinox and I'd like to clarify the issue. It appears that even though an OSGi framework can be embedded, it does not appear there is any protection from the case where it is embedded within another OSGi container. For instance, while Miguel has highlighted the issue down to a very specific error, the problem just seems to be that an embedded framework sees, and loads the extension bundles deployed to a higher level container, at least it does if the developer does not use very strict classloader isolation such as themselves delegating to an isolated container. We can certainly do that (and as of right now it looks like we have no choice). However, it wouldn't be a terribly difficult problem to solve. I'd like to propose that a small feature be added which allows for the extension mechanism to be defined as: a) using a specific classpath (as a property, from which we could create a URLClassLoader) b) pass an actual ClassLoader object during init as part of the configuration map associated with a extension loader property. In both cases (which would not be the default of course), the classLoader in question would be used to load framework extensions. That's exactly what we do in the Sling Launchpad Base module to encapsulate the framework from the environment (our experience is deploying the Sling's OSGi framework as a web application in an OSGi-based servlet container). Right, and we've created such a wrapper to work around the current issue ourselves. However, I'm just wondering if the intention of the Framework API was to allow for this type of isolation (at least in theory)? And if so, perhaps we could accommodate for it directly without having to write this extra code. The problem caused by such a wrapper, is that we can no longer directly access the OSGI apis from within the current application (which is emmbedding the framework). We'll end up having to front the APIs we want to access using a reflection layer which is very sad. Yes, you have to deploy shared API outside of the framework and explicitly configure the wrapper to let this api through the wrapper's wall. Regards Felix Thank you for thoughts, - Ray Regards Felix If we (Miguel and I) implemented this, would it be acceptable/considered? Note, that I will be proposing the same concept to the equinox project and making a similar offer to implement the addition. Sincerely, - Ray On Tue, Oct 2, 2012 at 5:28 AM, Miguel Angel Pastor Olivar miguelinl...@gmail.com wrote: Karl, I have created this ticket: https://issues.apache.org/jira/browse/FELIX-3696 Let me know if I can help in some way. Thx!! On 2 October 2012 10:05, Karl Pauls karlpa...@gmail.com wrote: On Tue, Oct 2, 2012 at 9:47 AM, Miguel Angel Pastor Olivar miguelinl...@gmail.com wrote: Ok, First of all sorry for not being too explicit. I will try to give some more details: - I am embedding Apache Felix (and Equinox because I would like to switch depending on the application server I am running on). - - The xalan ExtensionHandler executes something like this: ObjectFactory.findProviderClass(className, ObjectFactory.findClassLoader(), true) - The className has the format java:PortletBridge ( I am embedding the OSGI container into Liferay portal :) ) - The extension manager have already added the extension loader to the classloader Felix.m_secureAction.addURLToURLClassLoader(Felix.m_secureAction.createURL(Felix.m_secureAction.createURL(null, http:, extensionManager),http://felix.extensions:9/;, extensionManager), Felix.class.getClassLoader()); - When resolving the java:xxPortletBridge the previous loader added by the ExtensionManager cause an unhandled error. Well, it shouldn't do that I guess - maybe you could create a jira issue as a bug report against the framework and give me some more information like stack trace of the error etc. and I can see whether we can fix that. In addition; when trying to embed the container inside JBoss 7+ the extension manager fails to load because it is not being loaded by an instance of the URLClassloader (it is not really a problem) Yeah, that makes sense and is working as designed. If we can't add ourself to a urlclassloader we just don't provide extension bundle support but should continue to work correctly. As I have said in the previous mail, isolating the the framework into its own classloader is working but it is trickier. If you don't need extension bundle support you shouldn't have to do that then. Your real problems seems to be a bug in the extension manager
Re: Configurable Extension Bundle system
So, finally, so everyone is a little more clear on the proposal it might look like this (but not preclude the existing behaviour, being controlled by properties as suggested earlier) e.g. 2 - classloader[a] loads felix[a] - felix[a] searches in classloader[a] for felix extensions - felix[a] contains a OSGi bundle (classloader[b]) which loads felix[b] - felix[b] is configured to use extension classloader[b1] - felix[b] searches classloader[b1] for felix extensions Thanks for your time, - Ray On Fri, Oct 26, 2012 at 9:27 AM, Felix Meschberger fmesc...@adobe.comwrote: Hi Am 26.10.2012 um 15:21 schrieb Raymond Auge: On Fri, Oct 26, 2012 at 8:52 AM, Felix Meschberger fmesc...@adobe.com wrote: Hi, Am 25.10.2012 um 17:15 schrieb Raymond Auge: Hello All, I'd like to bump this issue as it appears to be a problem not only with Felix, but also with Equinox and I'd like to clarify the issue. It appears that even though an OSGi framework can be embedded, it does not appear there is any protection from the case where it is embedded within another OSGi container. For instance, while Miguel has highlighted the issue down to a very specific error, the problem just seems to be that an embedded framework sees, and loads the extension bundles deployed to a higher level container, at least it does if the developer does not use very strict classloader isolation such as themselves delegating to an isolated container. We can certainly do that (and as of right now it looks like we have no choice). However, it wouldn't be a terribly difficult problem to solve. I'd like to propose that a small feature be added which allows for the extension mechanism to be defined as: a) using a specific classpath (as a property, from which we could create a URLClassLoader) b) pass an actual ClassLoader object during init as part of the configuration map associated with a extension loader property. In both cases (which would not be the default of course), the classLoader in question would be used to load framework extensions. That's exactly what we do in the Sling Launchpad Base module to encapsulate the framework from the environment (our experience is deploying the Sling's OSGi framework as a web application in an OSGi-based servlet container). Right, and we've created such a wrapper to work around the current issue ourselves. However, I'm just wondering if the intention of the Framework API was to allow for this type of isolation (at least in theory)? And if so, perhaps we could accommodate for it directly without having to write this extra code. The problem caused by such a wrapper, is that we can no longer directly access the OSGI apis from within the current application (which is emmbedding the framework). We'll end up having to front the APIs we want to access using a reflection layer which is very sad. Yes, you have to deploy shared API outside of the framework and explicitly configure the wrapper to let this api through the wrapper's wall. Regards Felix Thank you for thoughts, - Ray Regards Felix If we (Miguel and I) implemented this, would it be acceptable/considered? Note, that I will be proposing the same concept to the equinox project and making a similar offer to implement the addition. Sincerely, - Ray On Tue, Oct 2, 2012 at 5:28 AM, Miguel Angel Pastor Olivar miguelinl...@gmail.com wrote: Karl, I have created this ticket: https://issues.apache.org/jira/browse/FELIX-3696 Let me know if I can help in some way. Thx!! On 2 October 2012 10:05, Karl Pauls karlpa...@gmail.com wrote: On Tue, Oct 2, 2012 at 9:47 AM, Miguel Angel Pastor Olivar miguelinl...@gmail.com wrote: Ok, First of all sorry for not being too explicit. I will try to give some more details: - I am embedding Apache Felix (and Equinox because I would like to switch depending on the application server I am running on). - - The xalan ExtensionHandler executes something like this: ObjectFactory.findProviderClass(className, ObjectFactory.findClassLoader(), true) - The className has the format java:PortletBridge ( I am embedding the OSGI container into Liferay portal :) ) - The extension manager have already added the extension loader to the classloader Felix.m_secureAction.addURLToURLClassLoader(Felix.m_secureAction.createURL(Felix.m_secureAction.createURL(null, http:, extensionManager),http://felix.extensions:9/;, extensionManager), Felix.class.getClassLoader()); - When resolving the java:xxPortletBridge the previous loader added by the ExtensionManager cause an unhandled error. Well, it shouldn't do that I guess - maybe you could create a jira issue as a bug report against the framework and give me some more information like stack trace of the error etc. and I can see whether
Re: Configurable Extension Bundle system
On Fri, Oct 26, 2012 at 3:47 PM, Raymond Auge raymond.a...@liferay.com wrote: So, finally, so everyone is a little more clear on the proposal it might look like this (but not preclude the existing behaviour, being controlled by properties as suggested earlier) e.g. 2 - classloader[a] loads felix[a] - felix[a] searches in classloader[a] for felix extensions - felix[a] contains a OSGi bundle (classloader[b]) which loads felix[b] - felix[b] is configured to use extension classloader[b1] - felix[b] searches classloader[b1] for felix extensions I don't think that really captures the problem. Either I'm missing something or you are :-). We don't search any classloader for extensions. Your scenario makes me think we are barking up the wrong tree. Is all you are talking about that you want to delegate down org.apache.felix packages from the classloader of the outer framework into the bundle of the inner felix and that is not working as felix assumes that the classloader that loads it is the one it should use to delegate system bundle classloads to? I.e., the inner felix in the bundle would get access to classes in the classloader of the outer felix? If so, than this is a know problem. Iirc, Richard and I discussed it a couple of times but never ended up doing something about it. The current solution would be to make sure your inner bundle _does_ include the org.apache.felix packages and _does not_ import them. It might be worthwhile to add a mechanism that allows to give us the classloader to use and it would look somewhat like what you are proposing but it doesn't have much todo with extensions. regards, Karl Thanks for your time, - Ray On Fri, Oct 26, 2012 at 9:27 AM, Felix Meschberger fmesc...@adobe.comwrote: Hi Am 26.10.2012 um 15:21 schrieb Raymond Auge: On Fri, Oct 26, 2012 at 8:52 AM, Felix Meschberger fmesc...@adobe.com wrote: Hi, Am 25.10.2012 um 17:15 schrieb Raymond Auge: Hello All, I'd like to bump this issue as it appears to be a problem not only with Felix, but also with Equinox and I'd like to clarify the issue. It appears that even though an OSGi framework can be embedded, it does not appear there is any protection from the case where it is embedded within another OSGi container. For instance, while Miguel has highlighted the issue down to a very specific error, the problem just seems to be that an embedded framework sees, and loads the extension bundles deployed to a higher level container, at least it does if the developer does not use very strict classloader isolation such as themselves delegating to an isolated container. We can certainly do that (and as of right now it looks like we have no choice). However, it wouldn't be a terribly difficult problem to solve. I'd like to propose that a small feature be added which allows for the extension mechanism to be defined as: a) using a specific classpath (as a property, from which we could create a URLClassLoader) b) pass an actual ClassLoader object during init as part of the configuration map associated with a extension loader property. In both cases (which would not be the default of course), the classLoader in question would be used to load framework extensions. That's exactly what we do in the Sling Launchpad Base module to encapsulate the framework from the environment (our experience is deploying the Sling's OSGi framework as a web application in an OSGi-based servlet container). Right, and we've created such a wrapper to work around the current issue ourselves. However, I'm just wondering if the intention of the Framework API was to allow for this type of isolation (at least in theory)? And if so, perhaps we could accommodate for it directly without having to write this extra code. The problem caused by such a wrapper, is that we can no longer directly access the OSGI apis from within the current application (which is emmbedding the framework). We'll end up having to front the APIs we want to access using a reflection layer which is very sad. Yes, you have to deploy shared API outside of the framework and explicitly configure the wrapper to let this api through the wrapper's wall. Regards Felix Thank you for thoughts, - Ray Regards Felix If we (Miguel and I) implemented this, would it be acceptable/considered? Note, that I will be proposing the same concept to the equinox project and making a similar offer to implement the addition. Sincerely, - Ray On Tue, Oct 2, 2012 at 5:28 AM, Miguel Angel Pastor Olivar miguelinl...@gmail.com wrote: Karl, I have created this ticket: https://issues.apache.org/jira/browse/FELIX-3696 Let me know if I can help in some way. Thx!! On 2 October 2012 10:05, Karl Pauls karlpa...@gmail.com wrote: On Tue, Oct 2, 2012 at 9:47 AM, Miguel Angel Pastor Olivar miguelinl...@gmail.com wrote: Ok,
Re: Configurable Extension Bundle system
On 10/26/12 09:21 , Raymond Auge wrote: On Fri, Oct 26, 2012 at 8:52 AM, Felix Meschberger fmesc...@adobe.comwrote: Hi, Am 25.10.2012 um 17:15 schrieb Raymond Auge: Hello All, I'd like to bump this issue as it appears to be a problem not only with Felix, but also with Equinox and I'd like to clarify the issue. It appears that even though an OSGi framework can be embedded, it does not appear there is any protection from the case where it is embedded within another OSGi container. For instance, while Miguel has highlighted the issue down to a very specific error, the problem just seems to be that an embedded framework sees, and loads the extension bundles deployed to a higher level container, at least it does if the developer does not use very strict classloader isolation such as themselves delegating to an isolated container. We can certainly do that (and as of right now it looks like we have no choice). However, it wouldn't be a terribly difficult problem to solve. I'd like to propose that a small feature be added which allows for the extension mechanism to be defined as: a) using a specific classpath (as a property, from which we could create a URLClassLoader) b) pass an actual ClassLoader object during init as part of the configuration map associated with a extension loader property. In both cases (which would not be the default of course), the classLoader in question would be used to load framework extensions. That's exactly what we do in the Sling Launchpad Base module to encapsulate the framework from the environment (our experience is deploying the Sling's OSGi framework as a web application in an OSGi-based servlet container). Right, and we've created such a wrapper to work around the current issue ourselves. However, I'm just wondering if the intention of the Framework API was to allow for this type of isolation (at least in theory)? And if so, perhaps we could accommodate for it directly without having to write this extra code. No, the Framework API was not intended to address the case where you embed frameworks inside of frameworks. It was explicitly NOT covering that aspect of embedding. It is purely a launching and embedding [in host] API, where the latter is purely a subset of the former...really it just treats the host application as the framework launcher. - richard The problem caused by such a wrapper, is that we can no longer directly access the OSGI apis from within the current application (which is emmbedding the framework). We'll end up having to front the APIs we want to access using a reflection layer which is very sad. Thank you for thoughts, - Ray Regards Felix If we (Miguel and I) implemented this, would it be acceptable/considered? Note, that I will be proposing the same concept to the equinox project and making a similar offer to implement the addition. Sincerely, - Ray On Tue, Oct 2, 2012 at 5:28 AM, Miguel Angel Pastor Olivar miguelinl...@gmail.com wrote: Karl, I have created this ticket: https://issues.apache.org/jira/browse/FELIX-3696 Let me know if I can help in some way. Thx!! On 2 October 2012 10:05, Karl Pauls karlpa...@gmail.com wrote: On Tue, Oct 2, 2012 at 9:47 AM, Miguel Angel Pastor Olivar miguelinl...@gmail.com wrote: Ok, First of all sorry for not being too explicit. I will try to give some more details: - I am embedding Apache Felix (and Equinox because I would like to switch depending on the application server I am running on). - - The xalan ExtensionHandler executes something like this: ObjectFactory.findProviderClass(className, ObjectFactory.findClassLoader(), true) - The className has the format java:PortletBridge ( I am embedding the OSGI container into Liferay portal :) ) - The extension manager have already added the extension loader to the classloader Felix.m_secureAction.addURLToURLClassLoader(Felix.m_secureAction.createURL(Felix.m_secureAction.createURL(null, http:, extensionManager),http://felix.extensions:9/;, extensionManager), Felix.class.getClassLoader()); - When resolving the java:xxPortletBridge the previous loader added by the ExtensionManager cause an unhandled error. Well, it shouldn't do that I guess - maybe you could create a jira issue as a bug report against the framework and give me some more information like stack trace of the error etc. and I can see whether we can fix that. In addition; when trying to embed the container inside JBoss 7+ the extension manager fails to load because it is not being loaded by an instance of the URLClassloader (it is not really a problem) Yeah, that makes sense and is working as designed. If we can't add ourself to a urlclassloader we just don't provide extension bundle support but should continue to work correctly. As I have said in the previous mail, isolating the the framework into its own classloader is working but it is trickier. If you don't need extension bundle support
Re: Configurable Extension Bundle system
Ok, I think I'm totally making a mess of this conversation. So, if you bare with me, let's go back to the original issue as stated by my colleague Miguel who listed this bit of code: Felix.m_secureAction.addURLToURLClassLoader(Felix.m_secureAction.createURL( Felix.m_secureAction.createURL(null, http:, extensionManager),http://felix.extensions:9/;, extensionManager), Felix.class.getClassLoader()); This, code adds an url to the parent (URLClassLoader) which loaded felix. If I may ask a question instead of making poor assumptions: What is that for? - Ray On Fri, Oct 26, 2012 at 10:04 AM, Karl Pauls karlpa...@gmail.com wrote: On Fri, Oct 26, 2012 at 3:47 PM, Raymond Auge raymond.a...@liferay.com wrote: So, finally, so everyone is a little more clear on the proposal it might look like this (but not preclude the existing behaviour, being controlled by properties as suggested earlier) e.g. 2 - classloader[a] loads felix[a] - felix[a] searches in classloader[a] for felix extensions - felix[a] contains a OSGi bundle (classloader[b]) which loads felix[b] - felix[b] is configured to use extension classloader[b1] - felix[b] searches classloader[b1] for felix extensions I don't think that really captures the problem. Either I'm missing something or you are :-). We don't search any classloader for extensions. Your scenario makes me think we are barking up the wrong tree. Is all you are talking about that you want to delegate down org.apache.felix packages from the classloader of the outer framework into the bundle of the inner felix and that is not working as felix assumes that the classloader that loads it is the one it should use to delegate system bundle classloads to? I.e., the inner felix in the bundle would get access to classes in the classloader of the outer felix? If so, than this is a know problem. Iirc, Richard and I discussed it a couple of times but never ended up doing something about it. The current solution would be to make sure your inner bundle _does_ include the org.apache.felix packages and _does not_ import them. It might be worthwhile to add a mechanism that allows to give us the classloader to use and it would look somewhat like what you are proposing but it doesn't have much todo with extensions. regards, Karl Thanks for your time, - Ray On Fri, Oct 26, 2012 at 9:27 AM, Felix Meschberger fmesc...@adobe.com wrote: Hi Am 26.10.2012 um 15:21 schrieb Raymond Auge: On Fri, Oct 26, 2012 at 8:52 AM, Felix Meschberger fmesc...@adobe.com wrote: Hi, Am 25.10.2012 um 17:15 schrieb Raymond Auge: Hello All, I'd like to bump this issue as it appears to be a problem not only with Felix, but also with Equinox and I'd like to clarify the issue. It appears that even though an OSGi framework can be embedded, it does not appear there is any protection from the case where it is embedded within another OSGi container. For instance, while Miguel has highlighted the issue down to a very specific error, the problem just seems to be that an embedded framework sees, and loads the extension bundles deployed to a higher level container, at least it does if the developer does not use very strict classloader isolation such as themselves delegating to an isolated container. We can certainly do that (and as of right now it looks like we have no choice). However, it wouldn't be a terribly difficult problem to solve. I'd like to propose that a small feature be added which allows for the extension mechanism to be defined as: a) using a specific classpath (as a property, from which we could create a URLClassLoader) b) pass an actual ClassLoader object during init as part of the configuration map associated with a extension loader property. In both cases (which would not be the default of course), the classLoader in question would be used to load framework extensions. That's exactly what we do in the Sling Launchpad Base module to encapsulate the framework from the environment (our experience is deploying the Sling's OSGi framework as a web application in an OSGi-based servlet container). Right, and we've created such a wrapper to work around the current issue ourselves. However, I'm just wondering if the intention of the Framework API was to allow for this type of isolation (at least in theory)? And if so, perhaps we could accommodate for it directly without having to write this extra code. The problem caused by such a wrapper, is that we can no longer directly access the OSGI apis from within the current application (which is emmbedding the framework). We'll end up having to front the APIs we want to access using a reflection layer which is very sad. Yes, you have to deploy shared API outside of the framework and explicitly configure the wrapper to let
Re: Configurable Extension Bundle system
On Fri, Oct 26, 2012 at 4:24 PM, Raymond Auge raymond.a...@liferay.com wrote: Ok, I think I'm totally making a mess of this conversation. I'm not so sure. I think you might need to state your goal and use-case more concretely :-) So, if you bare with me, let's go back to the original issue as stated by my colleague Miguel who listed this bit of code: Felix.m_secureAction.addURLToURLClassLoader(Felix.m_secureAction.createURL( Felix.m_secureAction.createURL(null, http:, extensionManager),http://felix.extensions:9/;, extensionManager), Felix.class.getClassLoader()); This, code adds an url to the parent (URLClassLoader) which loaded felix. Yup. If I may ask a question instead of making poor assumptions: What is that for? We do that in order to be able to support classpath extension bundles as described in the OSGi spec. The idea is that if we are loaded by an URLClassloader, we add our own url to it. If a classload happens that can't be satisfied we (i.e., our url and its urlhandler) is asked for the class. We then turn around and see whether we have an extension bundle installed that provides the resource. If so, we return it so that it can be loaded by our parent classloader. Yes, this is a hack :-) Next, if an extension bundle gets installed that has a felix specific activator header in its manifest we try to start it. This is a felix containerism that is not supposed to be used except by us. This is how I make the security extension bundle work. I only mention it as it is related to both, extension bundles as well as this hack because we assume we can load classes from it via the classloader that loaded felix (extension bundles don't have a class loader themselves). Anyways, this shouldn't be a problem at all (except maybe an ugly stacktrace printed out) for your scenario as such. It will be the case that you can't install/use extension bundles in the embedded felix instance but thats about it. If you need that functionality (and maybe need to workaround the tomcat problem determined in FELIX-3696) you need to go down the route that Felix Meschberger mentions and do what they do in sling. Now, given the scenario you described, it sounds to me you are actually facing a different problem that is unrelated to this. Namely, we are using the classloader that loaded the o.a.f.Felix class as the classloader to delegate to when bundles load classes from the system bundle. As a consequence, if you embed felix in a bundle inside of felix you need to make sure that the embedded instance is using its own version of that class (i.e., its o.a.felix.* classes have been loaded by the bundleclassloader and are not delegated down from the outer framework via Import/Export package). Otherwise, it delegates to the (in this case) *wrong* classloader namely, the one of the outer instance and not its bundleclassloader. That is not optimal but as Richard mentioned, we don't expect the framework api to be responsible for embedding frameworks inside frameworks. That was supposed to be a different spec :-). I think it would be solvable somewhat along the lines you outlined. Again, maybe you want to first describe what you are trying to do in more detail. regards, Karl - Ray On Fri, Oct 26, 2012 at 10:04 AM, Karl Pauls karlpa...@gmail.com wrote: On Fri, Oct 26, 2012 at 3:47 PM, Raymond Auge raymond.a...@liferay.com wrote: So, finally, so everyone is a little more clear on the proposal it might look like this (but not preclude the existing behaviour, being controlled by properties as suggested earlier) e.g. 2 - classloader[a] loads felix[a] - felix[a] searches in classloader[a] for felix extensions - felix[a] contains a OSGi bundle (classloader[b]) which loads felix[b] - felix[b] is configured to use extension classloader[b1] - felix[b] searches classloader[b1] for felix extensions I don't think that really captures the problem. Either I'm missing something or you are :-). We don't search any classloader for extensions. Your scenario makes me think we are barking up the wrong tree. Is all you are talking about that you want to delegate down org.apache.felix packages from the classloader of the outer framework into the bundle of the inner felix and that is not working as felix assumes that the classloader that loads it is the one it should use to delegate system bundle classloads to? I.e., the inner felix in the bundle would get access to classes in the classloader of the outer felix? If so, than this is a know problem. Iirc, Richard and I discussed it a couple of times but never ended up doing something about it. The current solution would be to make sure your inner bundle _does_ include the org.apache.felix packages and _does not_ import them. It might be worthwhile to add a mechanism that allows to give us the classloader to use and it would look somewhat like what you are proposing but it doesn't have much todo with extensions. regards, Karl Thanks for
Re: Configurable Extension Bundle system
Ok, it seems to be pretty clear that we just need to stick with a wrapper model, which is fine if not ideal but such is life. Thanks for your time, - Ray On Fri, Oct 26, 2012 at 10:56 AM, Karl Pauls karlpa...@gmail.com wrote: On Fri, Oct 26, 2012 at 4:24 PM, Raymond Auge raymond.a...@liferay.com wrote: Ok, I think I'm totally making a mess of this conversation. I'm not so sure. I think you might need to state your goal and use-case more concretely :-) So, if you bare with me, let's go back to the original issue as stated by my colleague Miguel who listed this bit of code: Felix.m_secureAction.addURLToURLClassLoader(Felix.m_secureAction.createURL( Felix.m_secureAction.createURL(null, http:, extensionManager),http://felix.extensions:9/;, extensionManager), Felix.class.getClassLoader()); This, code adds an url to the parent (URLClassLoader) which loaded felix. Yup. If I may ask a question instead of making poor assumptions: What is that for? We do that in order to be able to support classpath extension bundles as described in the OSGi spec. The idea is that if we are loaded by an URLClassloader, we add our own url to it. If a classload happens that can't be satisfied we (i.e., our url and its urlhandler) is asked for the class. We then turn around and see whether we have an extension bundle installed that provides the resource. If so, we return it so that it can be loaded by our parent classloader. Yes, this is a hack :-) Next, if an extension bundle gets installed that has a felix specific activator header in its manifest we try to start it. This is a felix containerism that is not supposed to be used except by us. This is how I make the security extension bundle work. I only mention it as it is related to both, extension bundles as well as this hack because we assume we can load classes from it via the classloader that loaded felix (extension bundles don't have a class loader themselves). Anyways, this shouldn't be a problem at all (except maybe an ugly stacktrace printed out) for your scenario as such. It will be the case that you can't install/use extension bundles in the embedded felix instance but thats about it. If you need that functionality (and maybe need to workaround the tomcat problem determined in FELIX-3696) you need to go down the route that Felix Meschberger mentions and do what they do in sling. Now, given the scenario you described, it sounds to me you are actually facing a different problem that is unrelated to this. Namely, we are using the classloader that loaded the o.a.f.Felix class as the classloader to delegate to when bundles load classes from the system bundle. As a consequence, if you embed felix in a bundle inside of felix you need to make sure that the embedded instance is using its own version of that class (i.e., its o.a.felix.* classes have been loaded by the bundleclassloader and are not delegated down from the outer framework via Import/Export package). Otherwise, it delegates to the (in this case) *wrong* classloader namely, the one of the outer instance and not its bundleclassloader. That is not optimal but as Richard mentioned, we don't expect the framework api to be responsible for embedding frameworks inside frameworks. That was supposed to be a different spec :-). I think it would be solvable somewhat along the lines you outlined. Again, maybe you want to first describe what you are trying to do in more detail. regards, Karl - Ray On Fri, Oct 26, 2012 at 10:04 AM, Karl Pauls karlpa...@gmail.com wrote: On Fri, Oct 26, 2012 at 3:47 PM, Raymond Auge raymond.a...@liferay.com wrote: So, finally, so everyone is a little more clear on the proposal it might look like this (but not preclude the existing behaviour, being controlled by properties as suggested earlier) e.g. 2 - classloader[a] loads felix[a] - felix[a] searches in classloader[a] for felix extensions - felix[a] contains a OSGi bundle (classloader[b]) which loads felix[b] - felix[b] is configured to use extension classloader[b1] - felix[b] searches classloader[b1] for felix extensions I don't think that really captures the problem. Either I'm missing something or you are :-). We don't search any classloader for extensions. Your scenario makes me think we are barking up the wrong tree. Is all you are talking about that you want to delegate down org.apache.felix packages from the classloader of the outer framework into the bundle of the inner felix and that is not working as felix assumes that the classloader that loads it is the one it should use to delegate system bundle classloads to? I.e., the inner felix in the bundle would get access to classes in the classloader of the outer felix? If so, than this is a know problem. Iirc, Richard and I discussed it a couple of times but never ended up doing something about it. The current solution would be
[jira] [Commented] (FELIX-3680) Exceptions in SCR using concurrent service activation/deactivation
[
https://issues.apache.org/jira/browse/FELIX-3680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13485012#comment-13485012
]
Pierre De Rop commented on FELIX-3680:
--
Thank you David, I ran the tests several times and the problems seem to be
fixed.
One point to notice: now I don't reproduce anymore the potential deadlock
problem from FELIX-3687.
It also sounds like the tests are now running faster.
I will do more tests next week. So, you think that this commit might not be
final and that some more work has to be done in FELIX-3729 ?
Exceptions in SCR using concurrent service activation/deactivation
--
Key: FELIX-3680
URL: https://issues.apache.org/jira/browse/FELIX-3680
Project: Felix
Issue Type: Bug
Components: Declarative Services (SCR)
Environment: linux fc16, jdk1.6.032
Reporter: Pierre De Rop
Attachments: FELIX-3680-concurrent-activate.diff,
integration_test_FELIX_3880_2.tgz,
logs_with_could_not_get_service_from_ref.txt.gz, serial-executor.tgz,
test.scr.tgz, test_with_fwk.tgz
This issue contains a sample code which reproduces many various exceptions,
using a concurrent
scenario, where some services are enabled/disabled concurrently.
I did not have time to commit an integration test about these exceptions but
I will try to do.
In the meantime, I join to this issue my scenario ...
Before trying to make an integration test, could you please run the scenario,
in order to confirm the problems, and that the scenario is valid ?
To execute the scenario
1) first, since the framework is not currently using any available log
service, you have to make a modification in the framework, in order to force
the framework to use a log service, when displaying caught exceptions. If you
don't do this, then you will get many exceptions thrown by many threads and
displayed in the console; and this is then not easy to diagnose problems.
So, in the framework, in the file
src/main/java/org/apache/felix/framework/Logger.java, in method
setBundleContext, just uncomment the following code, which activate the fwk
log service listener:
protected void setSystemBundleContext(BundleContext context)
{
// TODO: Find a way to log to a log service inside the framework.
// The issue is that we log messages while holding framework
// internal locks -- hence, when a log service calls back into
// the framework (e.g., by loading a class) we might deadlock.
// One instance of this problem is tracked in FELIX-536.
// For now we just disable logging to log services inside the
// framework.
m_context = context;
startListeningForLogService();
}
- this will make sure all logs caught by the framework are redirected to the
log service, and I did not find any deadlock issue, as described in the
comments.
Notice that even if you don't activate the log service listener, then the
Exceptions are also taking place ...
2) next, compile the attached concurrent scenario (it's a simple maven
project).
3) run the framework with the following bundles:
org.apache.felix.scr from trunk
org.apache.felix.configadmin-1.4.0.jar
4) wait for about 20 seconds, then suspend the framework, and kill it (using
kill -9)
Don't do Ctrl-C, because this might interrupt some locked threads and some
exceptions might be generated because of the Ctlr-C ... So doing a Kill -9
is better.
5) Then take a look at the produced ./logs.txt file.
scenario description:
===
here is a description of the Components used in the scenario:
A: delayed component, enabled, depending on B,C,D,E,F
B,C,D,E: delayed components, disabled, without any dependencies
F: delayed component, disabled, depending on G
G: delayed component, disabled, depending on H
I: delayed component, disabled, depending on J
J: delayed component, disabled, depending on K
Main: depends on A.
Main is the main scenario component: it uses a thread pool in order to
enable B,C,D,E,F,G,H,I,J,K in parallel, randomly.
Main depends on A.
When B,C,D,E,F,G,H,I,J,K are enabled, then A becomes satisfied, provided and
injected in the Main component.
Once A is bound to Main, then B,C,D,E,F,G,H,I,J,K are then disabled in
parallel, randomly. Main also checks that A is properly unbound.
LogService logs are written to ./logs.txt.
So, running the test using scr 1.6.0 runs seamlessly. But with trunk we have
many various exceptions.
For example, I have noticed the three following exceptions:
1) we have some IllegalMontorStateException:
=
log level: 1 D=Mon Sep 24 11:07:45 CEST 2012, T=Thread-1: [F] Locking
activity before IllegalMonitorStateException:
[jira] [Created] (FELIX-3738) [DS] ComponentInstance.getServices(String refName) is implemented wrong for 0..1 and 1..1 refs
David Jencks created FELIX-3738: --- Summary: [DS] ComponentInstance.getServices(String refName) is implemented wrong for 0..1 and 1..1 refs Key: FELIX-3738 URL: https://issues.apache.org/jira/browse/FELIX-3738 Project: Felix Issue Type: Bug Components: Declarative Services (SCR) Affects Versions: scr-1.6.0 Reporter: David Jencks Assignee: David Jencks Fix For: scr-1.8.0 For 0..1 and 1..1 refs getServices is supposed to return null (no good services) or an array of one service. Currently it returns all the services matching the filter. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
