geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jules Gosnell <ju...@coredevelopers.net>
Subject Re: Spring/cgllib woes...
Date Wed, 09 Feb 2005 15:13:51 GMT
Thanks Jeremy - much appreciated

Jules


Jeremy Boynes wrote:

> Jules Gosnell wrote:
>
>> Jeremy,
>>
>> I've been wondering whether I can do without upgrading cglib for the 
>> whole of Geronimo, just doing it for the Spring module, since we use 
>> it to build a standard 1.3 proxy. The problem is that this is done at 
>> runtime, so I guess that the only version of cglib around will be the 
>> one defined in etc/project.properties ?
>
>
> cglib is a kernel dependency so will be loaded on the system classpath 
> - there will only be one version at runtime
>
>> If this is the case, then I think I do need to upgrade it here...
>>
>> here are the options:
>>
>> 2.0 - no InterfaceMaker (required by SpringGBean proxy code)
>> 2.0.1 - InterfaceMaker present but breaks my Geronimo build
>> 2.0.2 - InterfaceMaker present - seems not to cause any more 
>> exceptions than I already get during my Geronimo build
>> 2.1-dev - InterfaceMaker present but breaks my Geronimo build (also 
>> involves jar name change and is not yet available via ibiblio)
>>
>> I think it would be very unwise for me to make a major change like 
>> upgrading the cglib version, without knowing what the current test 
>> success rate is, running against the new version and confirming that 
>> it does not break anything.... I don't want to impact your J2EE testing.
>>
>
> All unit and integration tests should pass - if not, someone broke 
> something and vigourous application of a trout would be in order.
>
> If you are seeing exceptions during the build pre-upgrade please open 
> a JIRA issue - or better still, once you've finished wielding the 
> trout, fix 'em :-)
>
>> I tried porting InterfaceMaker from 2.0.2 back onto 2.0, but I got an 
>> exception out of its superclass when I used it - so the port is 
>> non-trivial as it involves class patching as well as addition.
>>
>
> Running with a custom version of cglib doesn't seem like a goodf idea 
> anyway.
>
>> So, I shall leave the ball in your court. If you have the time, I 
>> should be very grateful if you would kick of a build/test cycle 
>> against a version of cglib>2.0 (probably 2.0.2). If it is successful, 
>> bump the version, ping me and I shall check in my code. 
>
>
> I'm currently working on MX4J fixes and am using a older version of 
> Geronimo to avoid very similar stability issues (I also have a couple 
> busy days at work). Can someone else help look at this for Jules, please?
>
> Does anyone have issue objecting to 2.0.2 either?
>
> -- 
> Jeremy



-- 
"Open Source is a self-assembling organism. You dangle a piece of
string into a super-saturated solution and a whole operating-system
crystallises out around it."

/**********************************
 * Jules Gosnell
 * Partner
 * Core Developers Network (Europe)
 *
 *    www.coredevelopers.net
 *
 * Open Source Training & Support.
 **********************************/


Mime
View raw message