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.

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>

Reply via email to