geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: svn commit: r712326 - in /geronimo/server/trunk: framework/modules/geronimo-kernel/src/main/java/org/apache/geronimo/kernel/classloader/ framework/modules/geronimo-kernel/src/main/java/org/apache/geronimo/kernel/config/ framework/modules/geronimo-kerne...
Date Tue, 18 Nov 2008 21:00:06 GMT

On Nov 18, 2008, at 12:39 PM, Gianny Damour wrote:
> On 19/11/2008, at 5:19 AM, Joe Bohn wrote:
>> Joe Bohn wrote:
>>> Just a heads up that I *think* there are still some issues with  
>>> this change.
>>> It appears that the hiddenResource processing from the  
>>> MultiParentClassloader was removed.
>> Correction ... it was not removed but rather changed and  
>> relocated.  I'm still looking to understand why this is causing a  
>> problem.
> Hi,
> Indeed, I changed the implementation to properly encapsulate class  
> loading rules. The new implementation is way cleaner this way; when  
> my frustration coming from reported issues will reduce, I may use  
> this better encapsulation to add import and export class loading  
> rules.
>> I think this has resulted in some
>>> testsuite failures involving tld processing.  There are failures  
>>> in the web-testsuite/test-2.1-jsps and web-testsuite/test-myfaces  
>>> tests.  I'm looking at what would be necessary to add in the  
>>> hiddenResource logic again hoping that will resolve the issue.
>>> This is a really nice feature and it is great to have the  
>>> capability. However could you please run the testsuite in the  
>>> future to avoid problems like this (especially when introducing  
>>> fundamental changes like this)?
> If this is indeed a bug related to this change, then let's ensure  
> that we have a proper unit test to prevent regression. Let's also  
> ensure that this test is collocated with the proper component to  
> improve cohesion. I have been observing various changes, many of  
> them do not have proper unit tests and this causes problems further  
> down the path as other developers can not safely change code.
> Regarding private-classes, the current Geronimo <-> OpenEJB DD  
> coupling is unfortunate. Does the OpenEJB deployer needs to know  
> about the Geronimo environment? If it does not need to know about  
> it, then let's strip from the DD the environment element and pass to  
> OpenEJB the stripped version. This will reduce a little bit  
> coupling. Another approach is to transform the Geronimo DD into an  
> OpenEJB supported DD when it is handed over to OpenEJB (in this  
> case, we simply remove the private-classes). The creation of a  
> canonical DD representation between Geronimo and OpenEJB will reduce  
> coupling.

I think the problem is caused by mismatch between our xmlbeans plan  
handling and the openejb jaxb plan handling.  Maybe we should consider  
moving the jaxb classes to a more neutral location?  This will  
probably take some work though.

david jencks
> I let you re-revert the private-classes change.
> Thanks,
> Gianny

View raw message