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
