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 <[email protected]> wrote: > On Fri, Oct 26, 2012 at 4:24 PM, Raymond Auge <[email protected]> > 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 <[email protected]> > wrote: > > > >> On Fri, Oct 26, 2012 at 3:47 PM, Raymond Auge <[email protected] > > > >> 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 < > [email protected] > >> >wrote: > >> > > >> >> Hi > >> >> > >> >> Am 26.10.2012 um 15:21 schrieb Raymond Auge: > >> >> > >> >> > On Fri, Oct 26, 2012 at 8:52 AM, Felix Meschberger < > >> [email protected] > >> >> >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 < > >> >> >>> [email protected]> 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 <[email protected]> > wrote: > >> >> >>>> > >> >> >>>>> On Tue, Oct 2, 2012 at 9:47 AM, Miguel Angel Pastor Olivar > >> >> >>>>> <[email protected]> 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 <[email protected]> > 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 > >> >> >>>>>>> [email protected] > >> >> >>>>>>> http://twitter.com/karlpauls > >> >> >>>>>>> http://www.linkedin.com/in/karlpauls > >> >> >>>>>>> https://profiles.google.com/karlpauls > >> >> >>>>>>> > >> >> >>>>>> > >> >> >>>>>> > >> >> >>>>>> > >> >> >>>>>> -- > >> >> >>>>>> Un saludo, > >> >> >>>>>> > >> >> >>>>>> Migue > >> >> >>>>>> > >> >> >>>>>> http://migue.github.com > >> >> >>>>> > >> >> >>>>> > >> >> >>>>> > >> >> >>>>> -- > >> >> >>>>> Karl Pauls > >> >> >>>>> [email protected] > >> >> >>>>> 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 > >> [email protected] > >> 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 > [email protected] > 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>
