HEADS-UP: ASM 3.1 shaded and org.objectweb.asm becomes org.apache.xbean.asm

[Jacek Laskowski]

Hi,

I've just committed a new module xbean-asm-shaded and some ASM package
changes (rev. 777524) to work around a known binary incompatibility
between ASM 3.1 and former versions issue. XBean uses two ASM versions
- 3.1 (xbean-finder) and 2.5.6 (xbean-reflect) which are incompatible.
OpenEJB 3.1 uses xbean-finder quite extensively so when run together
with Hibernate (as a JPA provider) that comes with ASM 2.5.6
NoClassDefFoundErrors surface.

The new maven project - xbean-asm-shaded - moves org.objectweb.asm to
org.apache.xbean.asm.

You've been warned. :)

Jacek

--
Jacek Laskowski
Notatnik Projektanta Java EE - http://www.JacekLaskowski.pl

[djencks]

Umm, why not upgrade xbean-reflect to asm 3.1?

thanks
david jencks

On May 22, 2009, at 6:55 AM, Jacek Laskowski wrote:

> Hi,
>
> I've just committed a new module xbean-asm-shaded and some ASM package
> changes (rev. 777524) to work around a known binary incompatibility
> between ASM 3.1 and former versions issue. XBean uses two ASM versions
> - 3.1 (xbean-finder) and 2.5.6 (xbean-reflect) which are incompatible.
> OpenEJB 3.1 uses xbean-finder quite extensively so when run together
> with Hibernate (as a JPA provider) that comes with ASM 2.5.6
> NoClassDefFoundErrors surface.
>
> The new maven project - xbean-asm-shaded - moves org.objectweb.asm to
> org.apache.xbean.asm.
>
> You've been warned. :)
>
> Jacek
>
> --
> Jacek Laskowski
> Notatnik Projektanta Java EE - http://www.JacekLaskowski.pl

[Jacek Laskowski]

On Fri, May 22, 2009 at 6:39 PM, David Jencks <david_jencks@...> wrote:
> Umm, why not upgrade xbean-reflect to asm 3.1?

One (small) step at a time? :) I'll give it a shot ->
https://issues.apache.org/jira/browse/XBEAN-129

Or did you mean why did I bother with the shading in the first place?
If so, the issue is Hibernate that comes with the older version of asm
so it's not xbean-reflect or xbean-finder and their asm versions, but
when openejb uses hibernate as a jpa provider the newer asm in xbean
made the asm binary incompatibility surfaced. Not sure if you asked
about it though.

Jacek

--
Jacek Laskowski
Notatnik Projektanta Java EE - http://www.JacekLaskowski.pl

[Jacek Laskowski]

On Fri, May 22, 2009 at 11:37 PM, Jacek Laskowski
<jacek@...> wrote:

> One (small) step at a time? :) I'll give it a shot ->
> https://issues.apache.org/jira/browse/XBEAN-129

Done. It turned out very easy. Thanks for encouragement :)

Jacek

--
Jacek Laskowski
Notatnik Projektanta Java EE - http://www.JacekLaskowski.pl

[David Blevins]

Great patch.  Nice putting the shaded asm stuff in it's own module so  
it could be simply referenced by the other modules.  That's exactly  
how I would have done it.

Any FYI that we can still leave the asm dep in xbean-reflect as  
optional.  There's magic code that loads AsmParameterNameLoader via  
reflection so if asm isn't present everything can still work.  In fact  
we could possibly have two copies of that class, one for the shaded  
version of asm and one for the non-shaded version of asm.  Maybe  
AsmParameterNameLoader and XbeanAsmParameterNameLoader?  Maybe for  
order we'd try to load the XbeanAsmParameterNameLoader version first  
then try the non-shaded AsmParameterNameLoader version second.

-David


On May 22, 2009, at 3:11 PM, Jacek Laskowski wrote:

> On Fri, May 22, 2009 at 11:37 PM, Jacek Laskowski
> <jacek@...> wrote:
>
>> One (small) step at a time? :) I'll give it a shot ->
>> https://issues.apache.org/jira/browse/XBEAN-129
>
> Done. It turned out very easy. Thanks for encouragement :)
>
> Jacek
>
> --
> Jacek Laskowski
> Notatnik Projektanta Java EE - http://www.JacekLaskowski.pl
>

[Jacek Laskowski]

On Tue, May 26, 2009 at 1:11 AM, David Blevins <david.blevins@...> wrote:
> Great patch.  Nice putting the shaded asm stuff in it's own module so it
> could be simply referenced by the other modules.  That's exactly how I would
> have done it.

With all the hints around it wasn't really such an achievement :)

> Any FYI that we can still leave the asm dep in xbean-reflect as optional.
>  There's magic code that loads AsmParameterNameLoader via reflection so if
> asm isn't present everything can still work.  In fact we could possibly have
> two copies of that class, one for the shaded version of asm and one for the
> non-shaded version of asm.  Maybe AsmParameterNameLoader and
> XbeanAsmParameterNameLoader?  Maybe for order we'd try to load the
> XbeanAsmParameterNameLoader version first then try the non-shaded
> AsmParameterNameLoader version second.

Noted. I don't know where you're heading yet, but will digest it in a
couple of days and eventually get back with a patch.

Jacek

--
Jacek Laskowski
Notatnik Projektanta Java EE - http://www.JacekLaskowski.pl

[djencks]

On May 22, 2009, at 6:11 PM, Jacek Laskowski wrote:

> On Fri, May 22, 2009 at 11:37 PM, Jacek Laskowski
> <jacek@...> wrote:
>
>> One (small) step at a time? :) I'll give it a shot ->
>> https://issues.apache.org/jira/browse/XBEAN-129
>
> Done. It turned out very easy. Thanks for encouragement :)


I'm not very happy with the current way this is implemented.  I guess  
my fundamental point of view is that shading is only needed when you  
don't have good classloaders such as osgi or (some version of) the  
geronimo ones.  I don't think the core xbean libraries should make  
such assumptions about classloaders but should assume good classloading.

So I'd prefer that the core xbean libraries use plan asm and that we  
provide shaded xbean libraries that use the shaded asm jar.  If no one  
objects I'm happy to set this up.

thanks
david jencks

>
>
> Jacek
>
> --
> Jacek Laskowski
> Notatnik Projektanta Java EE - http://www.JacekLaskowski.pl

[David Blevins]

On May 26, 2009, at 9:44 AM, David Jencks wrote:

>
> On May 22, 2009, at 6:11 PM, Jacek Laskowski wrote:
>
>> On Fri, May 22, 2009 at 11:37 PM, Jacek Laskowski
>> <jacek@...> wrote:
>>
>>> One (small) step at a time? :) I'll give it a shot ->
>>> https://issues.apache.org/jira/browse/XBEAN-129
>>
>> Done. It turned out very easy. Thanks for encouragement :)
>
>
> I'm not very happy with the current way this is implemented.  I  
> guess my fundamental point of view is that shading is only needed  
> when you don't have good classloaders such as osgi or (some version  
> of) the geronimo ones.  I don't think the core xbean libraries  
> should make such assumptions about classloaders but should assume  
> good classloading.
>
> So I'd prefer that the core xbean libraries use plan asm and that we  
> provide shaded xbean libraries that use the shaded asm jar.  If no  
> one objects I'm happy to set this up.

Ok, the end result will be the same for any G assemblies that pull in  
OpenEJB.  I.e. OpenEJB needs to satisfy the embedded scenario where  
there are just plain classloaders, so the end result is that xbean-
finder + xbean-reflect + xbean-asm-shaded are still going to be  
required as they are now (or some equivalent form of them).

-David

[djencks]

On May 26, 2009, at 2:40 PM, David Blevins wrote:

>
> On May 26, 2009, at 9:44 AM, David Jencks wrote:
>
>>
>> On May 22, 2009, at 6:11 PM, Jacek Laskowski wrote:
>>
>>> On Fri, May 22, 2009 at 11:37 PM, Jacek Laskowski
>>> <jacek@...> wrote:
>>>
>>>> One (small) step at a time? :) I'll give it a shot ->
>>>> https://issues.apache.org/jira/browse/XBEAN-129
>>>
>>> Done. It turned out very easy. Thanks for encouragement :)
>>
>>
>> I'm not very happy with the current way this is implemented.  I  
>> guess my fundamental point of view is that shading is only needed  
>> when you don't have good classloaders such as osgi or (some version  
>> of) the geronimo ones.  I don't think the core xbean libraries  
>> should make such assumptions about classloaders but should assume  
>> good classloading.
>>
>> So I'd prefer that the core xbean libraries use plan asm and that  
>> we provide shaded xbean libraries that use the shaded asm jar.  If  
>> no one objects I'm happy to set this up.
>
> Ok, the end result will be the same for any G assemblies that pull  
> in OpenEJB.  I.e. OpenEJB needs to satisfy the embedded scenario  
> where there are just plain classloaders, so the end result is that  
> xbean-finder + xbean-reflect + xbean-asm-shaded are still going to  
> be required as they are now (or some equivalent form of them).

I posted a patch to XBEAN-128 showing what I have in mind.

- xbean-reflect and xbean-finder use unshaded asm (dependencies should  
be provided like they used to be, I guess)
- 2 new modules xbean-finder-shaded and xbean-reflect shaded that are  
shaded to use the xbean-asm-shaded jar instead of plain asm jars

So if we go with something like this patch openejb would depend on the  
xbean-finder-shaded and xbean-reflect-shaded jars and geronimo might  
use the plain ones instead.

One difference between the proposed xbean-finder-shaded and current  
trunk xbean-finder is that the proposed -shaded jars don't have a  
dependency on xbean-asm-shaded whereas the trunk jars do.  However  
this was something of a change as previously xbean-finder listed the  
asm jars as scope provided.

thanks
david jencks

>
>
> -David
>

[Jacek Laskowski]

On Tue, May 26, 2009 at 9:33 PM, David Jencks <david_jencks@...> wrote:

> I posted a patch to XBEAN-128 showing what I have in mind.

I'm fine with it. I concur we definitely need a better classloading
layer like OSGi so we don't bother with the asm incompatibility. It
should be asm that changes its packages between releases so others
don't have to repackage them themselves. I didn't like the idea of
repackaging from the very first day as it wasn't clear what project
(openejb or xbean) should deal with the issue.

Jacek

--
Jacek Laskowski
Notatnik Projektanta Java EE - http://www.JacekLaskowski.pl