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