Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (athena.apache.org: domain of kevan.miller@gmail.com
 designates 66.249.82.226 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:mime-version:in-reply-to:references:content-type:message-id:content-transfer-encoding:from:subject:date:to:x-mailer;
        b=YnRSPv5k71xqDNR6zSZRwUrQan+7RwX3eFI1oSmsSMAChkQP+aHIPAk5wJU/lvf9HacInZKf++43yL/N/qeDLmIN3Z2CQzQScDNLsJLqmjBYLCTRrOy9Skf+RWVo9gqDVE4doRMAMifhLVQDZKXrG3v9npBbqoRkQNsTfmsJrDY=
Mime-Version: 1.0 (Apple Message framework v752.3)
In-Reply-To: <46D04261.5080606@apache.org>
References: <79A45AD7-8237-4603-9A88-21899F7FC5D7@gmail.com>
 <46CF4F0E.6080400@apache.org>
 <763B383C-95A3-48A3-B7C1-2591AD85B1A5@gmail.com>
 <46D04261.5080606@apache.org>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <A8E5C383-A0B0-42E3-ACA6-AD636D8BAFFB@gmail.com>
Content-Transfer-Encoding: 7bit
From: Kevan Miller <kevan.miller@gmail.com>
Subject: Re: removal of spring dependencies from cxf module
Date: Sat, 25 Aug 2007 14:07:26 -0400
To: dev@geronimo.apache.org


On Aug 25, 2007, at 10:53 AM, Jeff Genender wrote:

>
>
> Kevan Miller wrote:
>>
>> On Aug 24, 2007, at 5:35 PM, Jeff Genender wrote:
>>
>>> Kevan,
>>>
>>> IIU the reason you are asking, removal of the Spring dependencies  
>>> from
>>> CXF would appear to be a band aid and temporary fix to the real  
>>> issue.
>>> Is this about the Spring versioning and different versions getting
>>> loaded? (If not then never mind)
>>
>> I wouldn't characterize this as a band-aid. And I doubt that I would
>> advocate a different approach to solving this problem in a 2.0.x  
>> release.
>>
>
> Umm...why wouldn't you characterize this as a band aid?  The  
> problem is
> our class loaders.  You still have this problem if someone integrates
> something that uses Spring...right?

Sorry. I must not be explaining things very well... At present our  
CXF integration requires access to the same instance of Spring in  
both the cxf module as well as the client application module. This  
means that the client application module cannot have a unique  
instance of Spring and work with CXF -- this must be fixed regardless  
of our ClassLoader structure.  I'm pretty sure that you would agree  
with this?

In addition, I would not advocate a significant change to our  
ClassLoader behavior in a 2.0.x release (although I may be about to  
advocate for a change to our EAR classloading structure -- more on  
this in a different thread). At best this type of change would belong  
in a 2.x release, IMHO, since client applications are likely to be  
reliant on our current classloading behavior.

>
>
>> FYI, at present, cxf-based web services client code requires  
>> access to
>> Spring classes from the application's ClassLoader. So, even if you
>> wanted to completely isolate the application ClassLoader from system
>> ClassLoaders, this must be changed. I probably could have narrowed my
>> request a bit by saying can we just fix this web services client code
>> dependency -- better, I think to remove the spring dependency all
>> together from our cxf module.
>>
>
> So what would happen if I integrate another 3rd party component that
> uses Spring...say...Terracotta DSO? Or...ServiceMix?  What happens  
> then?

At present, these components can be integrated into Geronimo.  
Depending on their module-level dependencies, there might be some  
intra-server spring versioning problems. I assume that we would  
resolve those.

Currently, client applications that want to run their own Spring  
instance would need the following in their deployment plan environment:

     <hidden-classes>
       <filter>org.springframework.</filter>
       <filter>META-INF/spring</filter>
     </hidden-classes>

Until the above CXF-Spring requirement is fixed, this filtering may  
cause problems in some client applications using web services.

Geronimo used to hide these Spring classes/resources from client  
applications automatically. However, this automatic hiding of Spring  
was removed because of the CXF-Spring issue that is currently being  
discussed.

So, IMO:

1. We need to break the requirement for the sharing of a single  
instance of Spring betweeen the cxf module and a client application  
module. This can be via removal of the CXF Spring dependency all  
together, or by some alternate means (e.g. reworking of the web  
services client code)... Sorry to be vague, here. I'm not currently  
familiar with the details of the client code...

2. Once 1 is addressed, reinstate the automatic filtering of Spring  
classes/resources.

3. For a 2.x release, discuss alternate/preferred behavior.

--kevan