On Fri, Oct 26, 2012 at 8:37 AM, Karl Pauls <karlpa...@gmail.com> wrote:
> On Thu, Oct 25, 2012 at 5:15 PM, Raymond Auge <raymond.a...@liferay.com> > wrote: > > 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. > > Yes and no. I don't think that it is required to do it like this by > the spec but we do it this way. The proper way would probably to > require to have felix be loaded by a special, felix provided class > loader (or maybe at least a classloader with a felix specific > interface). > Ok, sure! > > > We can certainly do that (and as of right now it looks like we have no > > choice). > > If you want to use extension bundles then yes. However, keep in mind > that if you know the extension bundle(s) in question up-front you > might as well just put them in the same classloader and delegte the > packages down -- hence, > > yes, if you need to support dynamic installation of extension bundles > with felix embedded inside an environment that doesn't load felix with > a URLclassloader (or doesn't use the URLclassloader as the normal one > would) you have no choice atm. > Ok, I think this is where I may have cause the most confusion. Perhaps I have used an incorrect term. I believe the issue we are seeing is not with "extension bundles" in the pure sense. We are having problems with "felix" extensions which are dynamically identified within the classloader used to load felix (and it's parent(s)?). There is no problems with "extension bundles" deployed directly to felix. Felix, at least in what we are seeing, appears to search upward within the classloader hierarchy which loaded it, for code containing "felix" extensions. e.g. consider this example: - 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] searches classloader[b] and classloader[a] for "felix" extensions This appears to be the case when our app (a webapp using felix via the Framework (embedded) API) running in a felix enabled app server like Glassfish. (irrelevant here, but) Same thing happens when we replace felix with equinox and run in a equinox based container (e.g. jetty). > > > 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) > > I'm not sure I understand what you are proposing. The point is that > one can dynamically install extension bundles which become part of the > classloader that loaded felix. How would a) help there? > I'm just brain storming and might be already way off base. I surely defer to brighter minds. But hopefully the example above makes it a little more clear. > > > b) pass an actual ClassLoader object during init as part of the > > configuration map associated with a extension loader property. > > So this classloader would be doing what? If it is a URLclassloader we > could try to hack it like we currently do but if we need to add > extensions it would be much better to have a defined interface, no? > > > In both cases (which would not be the default of course), the classLoader > > in question would be used to load framework extensions. > > I'm missing how your external classloader would merge with the > classloader that loaded felix. Would it have to delegate to it? > > > If we (Miguel and I) implemented this, would it be acceptable/considered? > > Well, I'm certainly not against doing something better than we > currently do. It clearly is a hack and has caused problems before. > Additionally, I can't see any reason why we wouldn't consider a > reasonable approach and a corresponding implementation, provided, all > the ip is cleared etc. > > That said, lets not jump the gun - maybe you should first describe how > your proposed solution would look like in a little more detail so that > we see that it does cover what we need it to do. > > regards, > > Karl > > > 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> > > > > -- > 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>
