archiva-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Porter <br...@apache.org>
Subject Re: An experiment with Spring
Date Wed, 20 Feb 2008 20:48:08 GMT
This is way cooler than what I was doing :)

Can you replace the calls to the other factories so we can see this in  
action with a spring bean and plexus component all wired up?

I wouldn't worry about the portability for now - maybe if it were  
donated to Plexus itself that'd require some revision.

Cheers,
Brett

On 21/02/2008, at 2:31 AM, nicolas de loof wrote:

> I just added support for camelCase properties names using Xalan  
> extension.
>
> I don't know how to register a custom XpathFunction to a standard Trax
> Transformer. This will be required to make code fully portable, or  
> maybe we
> can hard-code the use of Xalan in place of Trax API.
>
> Nico.
>
> 2008/2/20, nicolas de loof <nicolas@apache.org>:
>>
>> I commited on the branch a first attempt to convert plexus  
>> descriptor to
>> spring context based on XSLT.
>>
>> Only basic convertion is supported yet.
>>
>> converting elements in <configuration> to camelCase properties would
>> require either some advanced XSLT, either a spring bean post- 
>> processor
>> (maybe the simpliest !)
>>
>> Support for plexus lifecycle in Spring could be handled by a
>> BeanPostProcessor to detect bean types to implement Plexus  
>> interfaces and
>> setup the required init/destroy-methods.
>>
>> Nicolas.
>>
>>
>> 2008/2/20, nicolas de loof <nicolas@apache.org>:
>>>
>>> Could'nt Spring mimic the PlexusContainer ?
>>>
>>> Archiva-webapp can be started with a spring context with support  
>>> from
>>> webwork/struts2 for IoC. We 'just' have to help the spring context  
>>> retrieve
>>> the components declared in plexus context files.
>>>
>>> As spring and plexus IoC concepts are equivalent, we could use a  
>>> custom
>>> ApplicationContext to parse plexus components.xml, and handle plexus
>>> lifecycle interfaces.
>>>
>>> It's not trivial, but not so difficult - it's only good old XML
>>> parsing... and some spring internals.
>>>
>>> On this basis, we can migrate components in isolation, without
>>> requirement for changes in many places because some other  
>>> component has (or
>>> has not yet) been updated to use spring.
>>>
>>> Nico.
>>>
>>> 2008/2/20, Brett Porter <brett@apache.org>:
>>>>
>>>> On 20/02/2008, at 6:33 PM, nicolas de loof wrote:
>>>>
>>>>> What about a Combined Plexus context, where the lookup method both
>>>>> search in
>>>>> the plexus components and the springFactory ?
>>>>>
>>>>> This would make initialization more complex, but we could use @
>>>>> plexus.requirement as is to get spring beans without having to  
>>>>> know
>>>>> they are
>>>>> managed by spring.
>>>>
>>>> If we think we have a long term requirement for this, then that  
>>>> makes
>>>> a lot of sense - and in fact Carlos did something similar for
>>>> Continuum with an acegi experiment once I believe.
>>>>
>>>> OTOH - since Archiva is a standalone app it would be best to be
>>>> consistent across it since we have that freedom. And actually,  
>>>> because
>>>> of the built-in support in webwork and struts2 for spring IOC,  
>>>> the web
>>>> layer is the easiest to change if everything else is already  
>>>> migrated,
>>>> so there'll be no need for the app itself to primarily be a  
>>>> Plexus run
>>>> app (though it might still have some plexus components we'll want  
>>>> to
>>>> pick up).
>>>>
>>>> Cheers,
>>>> Brett
>>>>
>>>> --
>>>> Brett Porter
>>>> brett@apache.org
>>>> http://blogs.exist.com/bporter/
>>>>
>>>>
>>>
>>

--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/


Mime
View raw message