felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Raymond Auge <raymond.a...@liferay.com>
Subject Re: Configurable Extension Bundle system
Date Fri, 26 Oct 2012 13:47:52 GMT
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 <fmeschbe@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 <fmeschbe@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 <
> >>> miguelinlas3@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 <karlpauls@gmail.com> wrote:
> >>>>
> >>>>> On Tue, Oct 2, 2012 at 9:47 AM, Miguel Angel Pastor Olivar
> >>>>> <miguelinlas3@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 <karlpauls@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
> >>>>>>> karlpauls@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
> >>>>> karlpauls@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>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message