aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Balázs Zsoldos <balazs.zsol...@everit.biz>
Subject Re: proxy-api needs at least org.osgi.framework 1.6.0
Date Fri, 25 May 2012 21:57:27 GMT
Hi,

I am really sorry to have a false alarm. I created a test case and I could
not reproduce the problem. Maybe ASM was not published well onto my dev
system.

Regards,
Balazs Zsoldos
Software Architect
Mobile: +36-70/594-92-34

Everit Kft.
https://www.everit.biz




On Fri, May 25, 2012 at 7:46 PM, Jeremy Hughes <jpjhughes@gmail.com> wrote:

> Hi. If you could open a JIRA for this and post a test that would really
> help us track the problem down.
>
> Thanks,
> Jeremy
> On May 25, 2012 6:22 PM, "Balázs Zsoldos" <balazs.zsoldos@everit.biz>
> wrote:
>
> > Hi,
> >
> > I had a problem with this check as well. For me on an Equinox server the
> > proxy-blueprint couple used jdkproxy for <reference> tags although asm
> 3.2
> > and asm 4 was on the classpath as well. I wanted to import the
> jetty.Server
> > service that is a class and is not based on interface. I solved it on the
> > end by writing a simple service tracker and leaving blueprint out.
> However
> > it would be nice if this would work in the future... I did not create a
> > "how to reproduce" that is why I have not reported it till now. I did not
> > know if this was a problem of Equinox class resolving or and issue of
> Aries
> > proxy.
> >
> > Regards,
> > Balazs Zsoldos
> > Software Architect
> > Mobile: +36-70/594-92-34
> >
> > Everit Kft.
> > https://www.everit.biz
> >
> >
> >
> >
> > On Fri, May 25, 2012 at 6:09 PM, Jeremy Hughes <hughesj@apache.org>
> wrote:
> >
> > > On 25 May 2012 15:51, Holly Cummins <holly.k.cummins@googlemail.com>
> > > wrote:
> > > > Jeremy wrote:
> > > >
> > > > "So that raises the question as to how the other proxy bundles cope
> > with
> > > this."
> > > >
> > > > I was quoting from the current pom of the proxy impl bundle. I guess
> > > > the assumption is that if the framework doesn't support weaving the
> > > > weaving code won't get driven so the classes with 1.6 dependencies
> > > > won't be driven.
> > >
> > > Yeah. The ProxyManagerActivator checks to see if ASM is available and
> > > if so, registers a weaving hook.
> > >
> > >        Class<?> cls =
> > > Class.forName("org.apache.aries.proxy.impl.weaving.ProxyWeavingHook");
> > >
> > >
>  context.registerService("org.osgi.framework.hooks.weaving.WeavingHook",
> > >
>  cls.getConstructor(BundleContext.class).newInstance(context),
> > > null);
> > >
> > > so if WeavingHook is not available on the classpath (because it's
> > > running on org.osgi.framework.osgi 1.5) I'd expect an Exception. Still
> > > this is all conjecture, I haven't tried anything.
> > >
> > > > I agree it seems like a risky strategy compared to
> > > > just carving the weaving-related classes off into their own bundles
> or
> > > > fragments, though - and that kind of major refactoring is something
> > > > we'd want to do before 1.0.0.
> > > >
> > > > FWIW, the other bundle with a 1.6 osgi.framework dependency is the
> > > > ejb-extender, which has dependencies on BundleWiring.
> > > >
> > > > Holly
> > > >
> > > > On Fri, May 25, 2012 at 3:14 PM, Jeremy Hughes <hughesj@apache.org>
> > > wrote:
> > > >> On 25 May 2012 14:59, Holly Cummins <holly.k.cummins@googlemail.com
> >
> > > wrote:
> > > >>> I've just looked at how the rest of the proxy bundles build and
> they
> > > >>> use OSGi 4.3, but override the osgi framework package import
> version
> > > >>> so that things still work with OSGi 4.2. They also make the weaving
> > > >>> code optional. That's probably what the proxy.api bundle should
do
> as
> > > >>> well:
> > > >>>
> > > >>>            org.osgi.framework;version="[1.5,2)",
> > > >>>            org.osgi.framework.hooks.weaving;resolution:=optional,
> > > >>>            org.osgi.framework.wiring;resolution:=optional,
> > > >>
> > > >> I don't think that's a good idea. proxy-api needs
> > > >> org.osgi.framework.hooks.weaving. If the proxy-api bundle imports
> > > >> [1.5,2) and is run on a '1.5' framework there could be
> > > >> ClassNotFoundExceptions.
> > > >>
> > > >> So that raises the question as to how the other proxy bundles cope
> > with
> > > this.
> > > >>
> > > >>>
> > > >>> Do you want to raise a JIRA, Balázs?
> > > >>>
> > > >>> Holly
> > > >>>
> > > >>> On Fri, May 25, 2012 at 2:47 PM, Holly Cummins
> > > >>> <holly.k.cummins@googlemail.com> wrote:
> > > >>>> On Fri, May 25, 2012 at 2:09 PM, Balázs Zsoldos
> > > >>>> <balazs.zsoldos@everit.biz> wrote:
> > > >>>>> Hi,
> > > >>>>>
> > > >>>>> as I look at it org.apache.aries.proxy.api needs at least
> > > >>>>> org.osgi.framework 1.6 which is part of OSGI 4.3. Is it
knowingly
> > > changed?
> > > >>>>> Based on this proxy will not work with older OSGI containers
> (e.g.
> > > >>>>> glassfish till version 3.1.1).
> > > >>>>
> > > >>>> I was wondering about this as well. It doesn't seem ideal,
does
> it?
> > > >>>>>
> > > >>>>> This problem may occurs at other places as well where
the
> osgi.core
> > > >>>>> dependency was changed to 4.3.
> > > >>>>
> > > >>>> It looks like the proxy changes were made as part of ARIES-826.
I
> > > >>>> think the original intention of the weaving code was that
it would
> > > >>>> still be compatible with OSGi 4.2. I guess our options are
to do
> > > >>>> something like what we've done with util-42, or split off
an
> > optional
> > > >>>> advanced.api bundle with the 4.3-dependent classes.
> > > >>>>
> > > >>>> Holly
> > >
> >
>

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