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 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 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:xxxxxx....PortletBridge" 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 to the >> >> >>>> framework? >> >> >>>>>>> >> >> >>>>>>> Again, it might help if you let us know what your problem is >> with >> >> it >> >> >>>>>>> in the first place. That said, I'm not against adding a switch >> to >> >> >>>>>>> disable it but it is somewhat tricky.... >> >> >>>>>>> >> >> >>>>>>> >> >> >>>>>>> regards, >> >> >>>>>>> >> >> >>>>>>> Karl >> >> >>>>>>> >> >> >>>>>>>> Cheers, >> >> >>>>>>>> >> >> >>>>>>>> Migue >> >> >>>>>>>> >> >> >>>>>>>> -- >> >> >>>>>>>> Un saludo, >> >> >>>>>>>> >> >> >>>>>>>> Migue >> >> >>>>>>>> >> >> >>>>>>>> http://migue.github.com >> >> >>>>>>> >> >> >>>>>>> >> >> >>>>>>> >> >> >>>>>>> -- >> >> >>>>>>> Karl Pauls >> >> >>>>>>> karlpa...@gmail.com >> >> >>>>>>> http://twitter.com/karlpauls >> >> >>>>>>> http://www.linkedin.com/in/karlpauls >> >> >>>>>>> https://profiles.google.com/karlpauls >> >> >>>>>>> >> >> >>>>>> >> >> >>>>>> >> >> >>>>>> >> >> >>>>>> -- >> >> >>>>>> Un saludo, >> >> >>>>>> >> >> >>>>>> Migue >> >> >>>>>> >> >> >>>>>> http://migue.github.com >> >> >>>>> >> >> >>>>> >> >> >>>>> >> >> >>>>> -- >> >> >>>>> Karl Pauls >> >> >>>>> karlpa...@gmail.com >> >> >>>>> http://twitter.com/karlpauls >> >> >>>>> http://www.linkedin.com/in/karlpauls >> >> >>>>> https://profiles.google.com/karlpauls >> >> >>>>> >> >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> -- >> >> >>>> Un saludo, >> >> >>>> >> >> >>>> Migue >> >> >>>> >> >> >>>> http://migue.github.com >> >> >>>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> -- >> >> >>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> >> >> >>> <http://twitter.com/#!/rotty3000> | Senior Software Architect | >> >> >> *Liferay, >> >> >>> Inc.* <http://www.liferay.com> <https://twitter.com/#!/liferay> >> >> >>> >> >> >>> --- >> >> >>> >> >> >>> 24-25 October 2012 |* Liferay **Spain Symposium* | >> >> >>> liferay.com/spain2012<http://www.liferay.com/spain2012> >> >> >>> >> >> >>> 16 November 2012 |* Liferay **Italy Symposium* | >> >> >>> liferay.com/italy2012<http://www.liferay.com/italy2012> >> >> >> >> >> >> >> >> > >> >> > >> >> > -- >> >> > *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> >> >> > <http://twitter.com/#!/rotty3000> | Senior Software Architect | >> >> *Liferay, >> >> > Inc.* <http://www.liferay.com> <https://twitter.com/#!/liferay> >> >> > >> >> > --- >> >> > >> >> > 24-25 October 2012 |* Liferay **Spain Symposium* | >> >> > liferay.com/spain2012<http://www.liferay.com/spain2012> >> >> > >> >> > 16 November 2012 |* Liferay **Italy Symposium* | >> >> > liferay.com/italy2012<http://www.liferay.com/italy2012> >> >> >> >> >> >> >> >> -- >> Karl Pauls >> karlpa...@gmail.com >> http://twitter.com/karlpauls >> http://www.linkedin.com/in/karlpauls >> https://profiles.google.com/karlpauls >> > > > > -- > *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> > <http://twitter.com/#!/rotty3000> | Senior Software Architect | *Liferay, > Inc.* <http://www.liferay.com> <https://twitter.com/#!/liferay> > > --- > > 24-25 October 2012 |* Liferay **Spain Symposium* | > liferay.com/spain2012<http://www.liferay.com/spain2012> > > 16 November 2012 |* Liferay **Italy Symposium* | > liferay.com/italy2012<http://www.liferay.com/italy2012> -- Karl Pauls karlpa...@gmail.com http://twitter.com/karlpauls http://www.linkedin.com/in/karlpauls https://profiles.google.com/karlpauls
