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.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> > >
