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 <[email protected]> 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" <[email protected]> > 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 <[email protected]> > wrote: > > > > > On 25 May 2012 15:51, Holly Cummins <[email protected]> > > > 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 <[email protected]> > > > wrote: > > > >> On 25 May 2012 14:59, Holly Cummins <[email protected] > > > > > 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 > > > >>> <[email protected]> wrote: > > > >>>> On Fri, May 25, 2012 at 2:09 PM, Balázs Zsoldos > > > >>>> <[email protected]> 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 > > > > > >
