You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@archiva.apache.org by Brett Porter <br...@apache.org> on 2008/02/20 02:53:02 UTC
An experiment with Spring
Hi,
Given the discussion yesterday, I played around with some changes on a
branch when I got up early this morning to show how we could do a
partial migration to Spring without having to do it all at once.
https://svn.apache.org/repos/asf/maven/archiva/branches/springy
This shows:
- ability to lookup plexus components via spring IoC
- ability to lookup spring beans during the Plexus component lifecycle
- basic functional setup for Spring in the Archiva application
Eventually, as whole subsystems no longer require plexus it will be
possible to clean it up, such as:
- get rid of the additional lookups
- use annotations for configuration
- use testng + get/set + mocks for the tests where possible (and
spring testcontext where integration testing is needed)
Here is how to obtain a plexus object from Spring (note there is some
pre-req setup in test cases you'll see in the commit, as there is in
the additional servlet listener):
<bean id="urlCache" factory-bean="plexusCacheFactory" factory-
method="createInstance" />
<bean id="plexusCacheFactory"
class="org.apache.maven.archiva.common.spring.PlexusFactory">
<constructor-arg index="0"
value="org.codehaus.plexus.cache.Cache"/>
<constructor-arg index="1" value="url-failures-cache"/>
</bean>
To get a spring bean inside a plexus component, it is like this (make
sure to implement Initializable):
/**
* @plexus.requirement
*/
private SpringFactory springFactory;
public void initialize()
throws InitializationException
{
urlFailureCache = (UrlFailureCache)
springFactory.lookup( "urlFailureCache" );
}
The next thing we should probably try is using something like
SpringCache as suggested to remove the plexus-cache dependency.
Have fun!
Cheers,
Brett
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
Re: An experiment with Spring
Posted by nicolas de loof <ni...@apache.org>.
I've asked springsource guys for help on this topic.
I sent Chris Beams <ch...@springsource.com> a simplified project with
testcase to investigate.
Nico.
2008/2/22, Brett Porter <br...@apache.org>:
>
> Wow, that's cool. :)
>
> On 22/02/2008, at 3:38 AM, nicolas de loof wrote:
>
> > Work in progress ...
> >
> > I've created a PlexusClassPathXmlApplicationContext that accept both
> > Spring
> > context files and plexus descriptors as resources.
> >
> > I also enhanced the XSLT to declare a bean alias for plexus
> > components :
> >
> > - plexus roles are by convention the FQCN of the interface
> > - spring IDs are by convention the simple interface class name with
> > lowercase first char
> >
> > the XSL now declares a spring-convention alias for the plexus role,
> > that is
> > used as bean ID, so that the same bean can be safely requested from
> > a plexus
> > component (by role using @plexus.requirement), or from a spring bean
> > by ID.
> >
> > I've made required changes to apply this to CachedFailuresPolicyTest
> >
> > I still have an issue to enable field injection with Spring
> > beanfactory,
> > that (unofficialy ?) supports this feature (for EJB3 injection) but
> > requires
> > some conf ...
> >
> > I've posted on spring forum :
> > http://forum.springframework.org/showthread.php?t=50181
> >
> > 2008/2/20, Brett Porter <br...@apache.org>:
> >>
> >> 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 <ni...@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 <ni...@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 <br...@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/
> >>
> >>
>
> --
> Brett Porter
> brett@apache.org
> http://blogs.exist.com/bporter/
>
>
Re: An experiment with Spring
Posted by Brett Porter <br...@apache.org>.
Wow, that's cool. :)
On 22/02/2008, at 3:38 AM, nicolas de loof wrote:
> Work in progress ...
>
> I've created a PlexusClassPathXmlApplicationContext that accept both
> Spring
> context files and plexus descriptors as resources.
>
> I also enhanced the XSLT to declare a bean alias for plexus
> components :
>
> - plexus roles are by convention the FQCN of the interface
> - spring IDs are by convention the simple interface class name with
> lowercase first char
>
> the XSL now declares a spring-convention alias for the plexus role,
> that is
> used as bean ID, so that the same bean can be safely requested from
> a plexus
> component (by role using @plexus.requirement), or from a spring bean
> by ID.
>
> I've made required changes to apply this to CachedFailuresPolicyTest
>
> I still have an issue to enable field injection with Spring
> beanfactory,
> that (unofficialy ?) supports this feature (for EJB3 injection) but
> requires
> some conf ...
>
> I've posted on spring forum :
> http://forum.springframework.org/showthread.php?t=50181
>
> 2008/2/20, Brett Porter <br...@apache.org>:
>>
>> 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 <ni...@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 <ni...@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 <br...@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/
>>
>>
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
Re: An experiment with Spring
Posted by nicolas de loof <ni...@apache.org>.
Work in progress ...
I've created a PlexusClassPathXmlApplicationContext that accept both Spring
context files and plexus descriptors as resources.
I also enhanced the XSLT to declare a bean alias for plexus components :
- plexus roles are by convention the FQCN of the interface
- spring IDs are by convention the simple interface class name with
lowercase first char
the XSL now declares a spring-convention alias for the plexus role, that is
used as bean ID, so that the same bean can be safely requested from a plexus
component (by role using @plexus.requirement), or from a spring bean by ID.
I've made required changes to apply this to CachedFailuresPolicyTest
I still have an issue to enable field injection with Spring beanfactory,
that (unofficialy ?) supports this feature (for EJB3 injection) but requires
some conf ...
I've posted on spring forum :
http://forum.springframework.org/showthread.php?t=50181
2008/2/20, Brett Porter <br...@apache.org>:
>
> 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 <ni...@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 <ni...@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 <br...@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/
>
>
Re: An experiment with Spring
Posted by Brett Porter <br...@apache.org>.
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 <ni...@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 <ni...@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 <br...@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/
Re: An experiment with Spring
Posted by nicolas de loof <ni...@apache.org>.
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 <ni...@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 <ni...@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 <br...@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/
> > >
> > >
> >
>
Re: An experiment with Spring
Posted by nicolas de loof <ni...@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 <ni...@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 <br...@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/
> >
> >
>
Re: An experiment with Spring
Posted by nicolas de loof <ni...@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 <br...@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/
>
>
Re: An experiment with Spring
Posted by Brett Porter <br...@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/
Re: An experiment with Spring
Posted by nicolas de loof <ni...@apache.org>.
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.
Nico.
2008/2/20, Brett Porter <br...@apache.org>:
>
> Hi,
>
> Given the discussion yesterday, I played around with some changes on a
> branch when I got up early this morning to show how we could do a
> partial migration to Spring without having to do it all at once.
>
> https://svn.apache.org/repos/asf/maven/archiva/branches/springy
>
> This shows:
> - ability to lookup plexus components via spring IoC
> - ability to lookup spring beans during the Plexus component lifecycle
> - basic functional setup for Spring in the Archiva application
>
> Eventually, as whole subsystems no longer require plexus it will be
> possible to clean it up, such as:
> - get rid of the additional lookups
> - use annotations for configuration
> - use testng + get/set + mocks for the tests where possible (and
> spring testcontext where integration testing is needed)
>
> Here is how to obtain a plexus object from Spring (note there is some
> pre-req setup in test cases you'll see in the commit, as there is in
> the additional servlet listener):
> <bean id="urlCache" factory-bean="plexusCacheFactory" factory-
> method="createInstance" />
> <bean id="plexusCacheFactory"
> class="org.apache.maven.archiva.common.spring.PlexusFactory">
> <constructor-arg index="0"
> value="org.codehaus.plexus.cache.Cache"/>
> <constructor-arg index="1" value="url-failures-cache"/>
> </bean>
>
> To get a spring bean inside a plexus component, it is like this (make
> sure to implement Initializable):
>
> /**
> * @plexus.requirement
> */
> private SpringFactory springFactory;
>
> public void initialize()
> throws InitializationException
> {
> urlFailureCache = (UrlFailureCache)
> springFactory.lookup( "urlFailureCache" );
> }
>
> The next thing we should probably try is using something like
> SpringCache as suggested to remove the plexus-cache dependency.
>
> Have fun!
>
> Cheers,
> Brett
>
> --
> Brett Porter
> brett@apache.org
> http://blogs.exist.com/bporter/
>
>
Re: An experiment with Spring
Posted by Brett Porter <br...@apache.org>.
On 20/02/2008, at 6:03 PM, Olivier Lamy wrote:
> Hi,
> Interesting, could you move this Spring/Plexus to a component in the
> plexus svn @ codehaus ?
That's a possibility - though it's really just a first draft right
now :)
Cheers,
Brett
>
>
> Thanks,
> --
> Olivier
>
> 2008/2/20, Brett Porter <br...@apache.org>:
>> Hi,
>>
>> Given the discussion yesterday, I played around with some changes
>> on a
>> branch when I got up early this morning to show how we could do a
>> partial migration to Spring without having to do it all at once.
>>
>> https://svn.apache.org/repos/asf/maven/archiva/branches/springy
>>
>> This shows:
>> - ability to lookup plexus components via spring IoC
>> - ability to lookup spring beans during the Plexus component
>> lifecycle
>> - basic functional setup for Spring in the Archiva application
>>
>> Eventually, as whole subsystems no longer require plexus it will be
>> possible to clean it up, such as:
>> - get rid of the additional lookups
>> - use annotations for configuration
>> - use testng + get/set + mocks for the tests where possible (and
>> spring testcontext where integration testing is needed)
>>
>> Here is how to obtain a plexus object from Spring (note there is some
>> pre-req setup in test cases you'll see in the commit, as there is in
>> the additional servlet listener):
>> <bean id="urlCache" factory-bean="plexusCacheFactory" factory-
>> method="createInstance" />
>> <bean id="plexusCacheFactory"
>> class="org.apache.maven.archiva.common.spring.PlexusFactory">
>> <constructor-arg index="0"
>> value="org.codehaus.plexus.cache.Cache"/>
>> <constructor-arg index="1" value="url-failures-cache"/>
>> </bean>
>>
>> To get a spring bean inside a plexus component, it is like this (make
>> sure to implement Initializable):
>>
>> /**
>> * @plexus.requirement
>> */
>> private SpringFactory springFactory;
>>
>> public void initialize()
>> throws InitializationException
>> {
>> urlFailureCache = (UrlFailureCache)
>> springFactory.lookup( "urlFailureCache" );
>> }
>>
>> The next thing we should probably try is using something like
>> SpringCache as suggested to remove the plexus-cache dependency.
>>
>> Have fun!
>>
>> Cheers,
>> Brett
>>
>> --
>> Brett Porter
>> brett@apache.org
>> http://blogs.exist.com/bporter/
>>
>>
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
Re: An experiment with Spring
Posted by Olivier Lamy <ol...@apache.org>.
Hi,
Interesting, could you move this Spring/Plexus to a component in the
plexus svn @ codehaus ?
Thanks,
--
Olivier
2008/2/20, Brett Porter <br...@apache.org>:
> Hi,
>
> Given the discussion yesterday, I played around with some changes on a
> branch when I got up early this morning to show how we could do a
> partial migration to Spring without having to do it all at once.
>
> https://svn.apache.org/repos/asf/maven/archiva/branches/springy
>
> This shows:
> - ability to lookup plexus components via spring IoC
> - ability to lookup spring beans during the Plexus component lifecycle
> - basic functional setup for Spring in the Archiva application
>
> Eventually, as whole subsystems no longer require plexus it will be
> possible to clean it up, such as:
> - get rid of the additional lookups
> - use annotations for configuration
> - use testng + get/set + mocks for the tests where possible (and
> spring testcontext where integration testing is needed)
>
> Here is how to obtain a plexus object from Spring (note there is some
> pre-req setup in test cases you'll see in the commit, as there is in
> the additional servlet listener):
> <bean id="urlCache" factory-bean="plexusCacheFactory" factory-
> method="createInstance" />
> <bean id="plexusCacheFactory"
> class="org.apache.maven.archiva.common.spring.PlexusFactory">
> <constructor-arg index="0"
> value="org.codehaus.plexus.cache.Cache"/>
> <constructor-arg index="1" value="url-failures-cache"/>
> </bean>
>
> To get a spring bean inside a plexus component, it is like this (make
> sure to implement Initializable):
>
> /**
> * @plexus.requirement
> */
> private SpringFactory springFactory;
>
> public void initialize()
> throws InitializationException
> {
> urlFailureCache = (UrlFailureCache)
> springFactory.lookup( "urlFailureCache" );
> }
>
> The next thing we should probably try is using something like
> SpringCache as suggested to remove the plexus-cache dependency.
>
> Have fun!
>
> Cheers,
> Brett
>
> --
> Brett Porter
> brett@apache.org
> http://blogs.exist.com/bporter/
>
>
Re: [OT] Re: An experiment with Spring... What about OSGi ?
Posted by Brett Porter <br...@apache.org>.
On 26/02/2008, at 9:11 AM, Rahul Thakur wrote:
>
> OK, this is just my personal opinion:
>
> I think choice of Spring OSGi is influenced by a few things:
> 1) Archiva is looking to garner more contributions from the
> community. Moving to Spring would, IMO, definately lessen the
> learning curve. There is a comprehensive documentation and large
> user base who work with Spring. Regards choice of Spring DM for
> OSGi, you might want to have a look here:
> http://static.springframework.org/osgi/docs/1.0/reference/html/why-spring-dm.html
Rahul is right.
We don't really have any requirement for the features of OSGi at this
time. Perhaps it would be useful as we add plugin support in a future
version though, and hopefully the Spring integration will be
sufficient at that point.
That said - Ludovic - if you see some way it might be of benefit and
are looking to contribute, by all means let us know :)
> 3) May be others can chip with their thoughts on Modello. But I
> think Modello could be dropped by using JPA annotations for the data
> model.
Yeah, that's not really related :)
Cheers,
Brett
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
Re: [OT] Re: An experiment with Spring... What about OSGi ?
Posted by Ludovic Maitre <lu...@free.fr>.
Hi Rahul,
All right, i understand better, it's a matter of taste :-) and
accessibility. If it's the choice of the community, it's fine, and it
will be exciting to use Spring in order to follow Archiva development...
Best regards,
Rahul Thakur a écrit :
>
> OK, this is just my personal opinion:
>
> I think choice of Spring OSGi is influenced by a few things:
> 1) Archiva is looking to garner more contributions from the community.
> Moving to Spring would, IMO, definately lessen the learning curve.
> There is a comprehensive documentation and large user base who work
> with Spring. Regards choice of Spring DM for OSGi, you might want to
> have a look here:
> http://static.springframework.org/osgi/docs/1.0/reference/html/why-spring-dm.html
>
>
> 2) Plexus is good but not as comprehensively documented. (I admit I
> haven't sustained in doing my bit with the documentation there).
>
> 3) May be others can chip with their thoughts on Modello. But I think
> Modello could be dropped by using JPA annotations for the data model.
>
> Cheers,
> Rahul
>
>
> Ludovic Maitre wrote:
>> Hi Carlos,
>>
>> Thanks for your answer,
>>
>> Carlos Sanchez a écrit :
>>> spring has good integration with OSGi to enable Spring beans to be
>>> OSGi services.
>>>
>> Yes, i'm aware that this integration exist and i've read a couple of
>> meetings reports related to it on the Equinox wiki, but why bother with
>> the complicated Spring xml descriptors (well for me i admit that i
>> haven't tried Spring since v1.2 iirc), is there any need in Archiva
>> which is not adressed by OSGi (Felix/Sling for instance) + Modello ? I'm
>> wondering what are the benefits of Spring (even with OSGi integration)
>> regarding the current Plexus architecture or an alternative architecture
>> based on some OSGi layer, which features does bring Spring which are not
>> implemented in the other frameworks (including modello) ?
>> Best regards, thanks for your time,
>>
>>> On Mon, Feb 25, 2008 at 11:05 AM, Ludovic Maitre
>>> <lu...@free.fr> wrote:
>>>> Hi Brett, all,
>>>>
>>>> Have you considered using OSGi instead of [Plexus|Spring] ? I'm not an
>>>> expert of one or the other, but i try to do some projects with OSGi
>>>> since a few months and i like it.
>>>> Best regards,
>>>>
>>>> Brett Porter a écrit :
>>>> > Hi,
>>>> >
>>>> > Given the discussion yesterday, I played around with some changes
>>>> on a
>>>> > branch when I got up early this morning to show how we could do a
>>>> > partial migration to Spring without having to do it all at once.
>>>> >
>>>> > https://svn.apache.org/repos/asf/maven/archiva/branches/springy
>>>> >
>>>> > This shows:
>>>> > - ability to lookup plexus components via spring IoC
>>>> > - ability to lookup spring beans during the Plexus component
>>>> lifecycle
>>>> > - basic functional setup for Spring in the Archiva application
>>>> >
>>>> > Eventually, as whole subsystems no longer require plexus it will be
>>>> > possible to clean it up, such as:
>>>> > - get rid of the additional lookups
>>>> > - use annotations for configuration
>>>> > - use testng + get/set + mocks for the tests where possible (and
>>>> > spring testcontext where integration testing is needed)
>>>> >
>>>> > Here is how to obtain a plexus object from Spring (note there is
>>>> some
>>>> > pre-req setup in test cases you'll see in the commit, as there is in
>>>> > the additional servlet listener):
>>>> > <bean id="urlCache" factory-bean="plexusCacheFactory"
>>>> > factory-method="createInstance" />
>>>> > <bean id="plexusCacheFactory"
>>>> > class="org.apache.maven.archiva.common.spring.PlexusFactory">
>>>> > <constructor-arg index="0" value="org.codehaus.plexus.cache.Cache"/>
>>>> > <constructor-arg index="1" value="url-failures-cache"/>
>>>> > </bean>
>>>> >
>>>> > To get a spring bean inside a plexus component, it is like this
>>>> (make
>>>> > sure to implement Initializable):
>>>> >
>>>> > /**
>>>> > * @plexus.requirement
>>>> > */
>>>> > private SpringFactory springFactory;
>>>> >
>>>> > public void initialize()
>>>> > throws InitializationException
>>>> > {
>>>> > urlFailureCache = (UrlFailureCache) springFactory.lookup(
>>>> > "urlFailureCache" );
>>>> > }
>>>> >
>>>> > The next thing we should probably try is using something like
>>>> > SpringCache as suggested to remove the plexus-cache dependency.
>>>> >
>>>> > Have fun!
>>>> >
>>>> > Cheers,
>>>> > Brett
>>>> >
>>>> > --
>>>> > Brett Porter
>>>> > brett@apache.org
>>>> > http://blogs.exist.com/bporter/
>>>> >
>>>> >
>>>> >
>>>>
>>>>
>>>> --
>>>> Cordialement,
>>>> Ludo - http://www.ubik-products.com
>>>> ---
>>>> "L'amour pour principe et l'ordre pour base; le progres pour but"
>>>> (A.Comte)
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
>
--
Cordialement,
Ludo - http://www.ubik-products.com
---
"L'amour pour principe et l'ordre pour base; le progres pour but" (A.Comte)
Re: [OT] Re: An experiment with Spring... What about OSGi ?
Posted by Rahul Thakur <ra...@gmail.com>.
OK, this is just my personal opinion:
I think choice of Spring OSGi is influenced by a few things:
1) Archiva is looking to garner more contributions from the community.
Moving to Spring would, IMO, definately lessen the learning curve. There
is a comprehensive documentation and large user base who work with
Spring. Regards choice of Spring DM for OSGi, you might want to have a
look here:
http://static.springframework.org/osgi/docs/1.0/reference/html/why-spring-dm.html
2) Plexus is good but not as comprehensively documented. (I admit I
haven't sustained in doing my bit with the documentation there).
3) May be others can chip with their thoughts on Modello. But I think
Modello could be dropped by using JPA annotations for the data model.
Cheers,
Rahul
Ludovic Maitre wrote:
> Hi Carlos,
>
> Thanks for your answer,
>
> Carlos Sanchez a écrit :
>> spring has good integration with OSGi to enable Spring beans to be
>> OSGi services.
>>
> Yes, i'm aware that this integration exist and i've read a couple of
> meetings reports related to it on the Equinox wiki, but why bother with
> the complicated Spring xml descriptors (well for me i admit that i
> haven't tried Spring since v1.2 iirc), is there any need in Archiva
> which is not adressed by OSGi (Felix/Sling for instance) + Modello ? I'm
> wondering what are the benefits of Spring (even with OSGi integration)
> regarding the current Plexus architecture or an alternative architecture
> based on some OSGi layer, which features does bring Spring which are not
> implemented in the other frameworks (including modello) ?
> Best regards, thanks for your time,
>
>> On Mon, Feb 25, 2008 at 11:05 AM, Ludovic Maitre
>> <lu...@free.fr> wrote:
>>> Hi Brett, all,
>>>
>>> Have you considered using OSGi instead of [Plexus|Spring] ? I'm not an
>>> expert of one or the other, but i try to do some projects with OSGi
>>> since a few months and i like it.
>>> Best regards,
>>>
>>> Brett Porter a écrit :
>>> > Hi,
>>> >
>>> > Given the discussion yesterday, I played around with some changes on a
>>> > branch when I got up early this morning to show how we could do a
>>> > partial migration to Spring without having to do it all at once.
>>> >
>>> > https://svn.apache.org/repos/asf/maven/archiva/branches/springy
>>> >
>>> > This shows:
>>> > - ability to lookup plexus components via spring IoC
>>> > - ability to lookup spring beans during the Plexus component lifecycle
>>> > - basic functional setup for Spring in the Archiva application
>>> >
>>> > Eventually, as whole subsystems no longer require plexus it will be
>>> > possible to clean it up, such as:
>>> > - get rid of the additional lookups
>>> > - use annotations for configuration
>>> > - use testng + get/set + mocks for the tests where possible (and
>>> > spring testcontext where integration testing is needed)
>>> >
>>> > Here is how to obtain a plexus object from Spring (note there is some
>>> > pre-req setup in test cases you'll see in the commit, as there is in
>>> > the additional servlet listener):
>>> > <bean id="urlCache" factory-bean="plexusCacheFactory"
>>> > factory-method="createInstance" />
>>> > <bean id="plexusCacheFactory"
>>> > class="org.apache.maven.archiva.common.spring.PlexusFactory">
>>> > <constructor-arg index="0" value="org.codehaus.plexus.cache.Cache"/>
>>> > <constructor-arg index="1" value="url-failures-cache"/>
>>> > </bean>
>>> >
>>> > To get a spring bean inside a plexus component, it is like this (make
>>> > sure to implement Initializable):
>>> >
>>> > /**
>>> > * @plexus.requirement
>>> > */
>>> > private SpringFactory springFactory;
>>> >
>>> > public void initialize()
>>> > throws InitializationException
>>> > {
>>> > urlFailureCache = (UrlFailureCache) springFactory.lookup(
>>> > "urlFailureCache" );
>>> > }
>>> >
>>> > The next thing we should probably try is using something like
>>> > SpringCache as suggested to remove the plexus-cache dependency.
>>> >
>>> > Have fun!
>>> >
>>> > Cheers,
>>> > Brett
>>> >
>>> > --
>>> > Brett Porter
>>> > brett@apache.org
>>> > http://blogs.exist.com/bporter/
>>> >
>>> >
>>> >
>>>
>>>
>>> --
>>> Cordialement,
>>> Ludo - http://www.ubik-products.com
>>> ---
>>> "L'amour pour principe et l'ordre pour base; le progres pour but"
>>> (A.Comte)
>>>
>>>
>>
>>
>>
>
>
Re: [OT] Re: An experiment with Spring... What about OSGi ?
Posted by Ludovic Maitre <lu...@free.fr>.
Hi Carlos,
Thanks for your answer,
Carlos Sanchez a écrit :
> spring has good integration with OSGi to enable Spring beans to be
> OSGi services.
>
>
Yes, i'm aware that this integration exist and i've read a couple of
meetings reports related to it on the Equinox wiki, but why bother with
the complicated Spring xml descriptors (well for me i admit that i
haven't tried Spring since v1.2 iirc), is there any need in Archiva
which is not adressed by OSGi (Felix/Sling for instance) + Modello ? I'm
wondering what are the benefits of Spring (even with OSGi integration)
regarding the current Plexus architecture or an alternative architecture
based on some OSGi layer, which features does bring Spring which are not
implemented in the other frameworks (including modello) ?
Best regards, thanks for your time,
> On Mon, Feb 25, 2008 at 11:05 AM, Ludovic Maitre <lu...@free.fr> wrote:
>
>> Hi Brett, all,
>>
>> Have you considered using OSGi instead of [Plexus|Spring] ? I'm not an
>> expert of one or the other, but i try to do some projects with OSGi
>> since a few months and i like it.
>> Best regards,
>>
>> Brett Porter a écrit :
>> > Hi,
>> >
>> > Given the discussion yesterday, I played around with some changes on a
>> > branch when I got up early this morning to show how we could do a
>> > partial migration to Spring without having to do it all at once.
>> >
>> > https://svn.apache.org/repos/asf/maven/archiva/branches/springy
>> >
>> > This shows:
>> > - ability to lookup plexus components via spring IoC
>> > - ability to lookup spring beans during the Plexus component lifecycle
>> > - basic functional setup for Spring in the Archiva application
>> >
>> > Eventually, as whole subsystems no longer require plexus it will be
>> > possible to clean it up, such as:
>> > - get rid of the additional lookups
>> > - use annotations for configuration
>> > - use testng + get/set + mocks for the tests where possible (and
>> > spring testcontext where integration testing is needed)
>> >
>> > Here is how to obtain a plexus object from Spring (note there is some
>> > pre-req setup in test cases you'll see in the commit, as there is in
>> > the additional servlet listener):
>> > <bean id="urlCache" factory-bean="plexusCacheFactory"
>> > factory-method="createInstance" />
>> > <bean id="plexusCacheFactory"
>> > class="org.apache.maven.archiva.common.spring.PlexusFactory">
>> > <constructor-arg index="0" value="org.codehaus.plexus.cache.Cache"/>
>> > <constructor-arg index="1" value="url-failures-cache"/>
>> > </bean>
>> >
>> > To get a spring bean inside a plexus component, it is like this (make
>> > sure to implement Initializable):
>> >
>> > /**
>> > * @plexus.requirement
>> > */
>> > private SpringFactory springFactory;
>> >
>> > public void initialize()
>> > throws InitializationException
>> > {
>> > urlFailureCache = (UrlFailureCache) springFactory.lookup(
>> > "urlFailureCache" );
>> > }
>> >
>> > The next thing we should probably try is using something like
>> > SpringCache as suggested to remove the plexus-cache dependency.
>> >
>> > Have fun!
>> >
>> > Cheers,
>> > Brett
>> >
>> > --
>> > Brett Porter
>> > brett@apache.org
>> > http://blogs.exist.com/bporter/
>> >
>> >
>> >
>>
>>
>> --
>> Cordialement,
>> Ludo - http://www.ubik-products.com
>> ---
>> "L'amour pour principe et l'ordre pour base; le progres pour but" (A.Comte)
>>
>>
>>
>
>
>
>
--
Cordialement,
Ludo - http://www.ubik-products.com
---
"L'amour pour principe et l'ordre pour base; le progres pour but" (A.Comte)
Re: [OT] Re: An experiment with Spring... What about OSGi ?
Posted by Carlos Sanchez <ca...@apache.org>.
spring has good integration with OSGi to enable Spring beans to be
OSGi services.
On Mon, Feb 25, 2008 at 11:05 AM, Ludovic Maitre <lu...@free.fr> wrote:
> Hi Brett, all,
>
> Have you considered using OSGi instead of [Plexus|Spring] ? I'm not an
> expert of one or the other, but i try to do some projects with OSGi
> since a few months and i like it.
> Best regards,
>
> Brett Porter a écrit :
> > Hi,
> >
> > Given the discussion yesterday, I played around with some changes on a
> > branch when I got up early this morning to show how we could do a
> > partial migration to Spring without having to do it all at once.
> >
> > https://svn.apache.org/repos/asf/maven/archiva/branches/springy
> >
> > This shows:
> > - ability to lookup plexus components via spring IoC
> > - ability to lookup spring beans during the Plexus component lifecycle
> > - basic functional setup for Spring in the Archiva application
> >
> > Eventually, as whole subsystems no longer require plexus it will be
> > possible to clean it up, such as:
> > - get rid of the additional lookups
> > - use annotations for configuration
> > - use testng + get/set + mocks for the tests where possible (and
> > spring testcontext where integration testing is needed)
> >
> > Here is how to obtain a plexus object from Spring (note there is some
> > pre-req setup in test cases you'll see in the commit, as there is in
> > the additional servlet listener):
> > <bean id="urlCache" factory-bean="plexusCacheFactory"
> > factory-method="createInstance" />
> > <bean id="plexusCacheFactory"
> > class="org.apache.maven.archiva.common.spring.PlexusFactory">
> > <constructor-arg index="0" value="org.codehaus.plexus.cache.Cache"/>
> > <constructor-arg index="1" value="url-failures-cache"/>
> > </bean>
> >
> > To get a spring bean inside a plexus component, it is like this (make
> > sure to implement Initializable):
> >
> > /**
> > * @plexus.requirement
> > */
> > private SpringFactory springFactory;
> >
> > public void initialize()
> > throws InitializationException
> > {
> > urlFailureCache = (UrlFailureCache) springFactory.lookup(
> > "urlFailureCache" );
> > }
> >
> > The next thing we should probably try is using something like
> > SpringCache as suggested to remove the plexus-cache dependency.
> >
> > Have fun!
> >
> > Cheers,
> > Brett
> >
> > --
> > Brett Porter
> > brett@apache.org
> > http://blogs.exist.com/bporter/
> >
> >
> >
>
>
> --
> Cordialement,
> Ludo - http://www.ubik-products.com
> ---
> "L'amour pour principe et l'ordre pour base; le progres pour but" (A.Comte)
>
>
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride
[OT] Re: An experiment with Spring... What about OSGi ?
Posted by Ludovic Maitre <lu...@free.fr>.
Hi Brett, all,
Have you considered using OSGi instead of [Plexus|Spring] ? I'm not an
expert of one or the other, but i try to do some projects with OSGi
since a few months and i like it.
Best regards,
Brett Porter a écrit :
> Hi,
>
> Given the discussion yesterday, I played around with some changes on a
> branch when I got up early this morning to show how we could do a
> partial migration to Spring without having to do it all at once.
>
> https://svn.apache.org/repos/asf/maven/archiva/branches/springy
>
> This shows:
> - ability to lookup plexus components via spring IoC
> - ability to lookup spring beans during the Plexus component lifecycle
> - basic functional setup for Spring in the Archiva application
>
> Eventually, as whole subsystems no longer require plexus it will be
> possible to clean it up, such as:
> - get rid of the additional lookups
> - use annotations for configuration
> - use testng + get/set + mocks for the tests where possible (and
> spring testcontext where integration testing is needed)
>
> Here is how to obtain a plexus object from Spring (note there is some
> pre-req setup in test cases you'll see in the commit, as there is in
> the additional servlet listener):
> <bean id="urlCache" factory-bean="plexusCacheFactory"
> factory-method="createInstance" />
> <bean id="plexusCacheFactory"
> class="org.apache.maven.archiva.common.spring.PlexusFactory">
> <constructor-arg index="0" value="org.codehaus.plexus.cache.Cache"/>
> <constructor-arg index="1" value="url-failures-cache"/>
> </bean>
>
> To get a spring bean inside a plexus component, it is like this (make
> sure to implement Initializable):
>
> /**
> * @plexus.requirement
> */
> private SpringFactory springFactory;
>
> public void initialize()
> throws InitializationException
> {
> urlFailureCache = (UrlFailureCache) springFactory.lookup(
> "urlFailureCache" );
> }
>
> The next thing we should probably try is using something like
> SpringCache as suggested to remove the plexus-cache dependency.
>
> Have fun!
>
> Cheers,
> Brett
>
> --
> Brett Porter
> brett@apache.org
> http://blogs.exist.com/bporter/
>
>
>
--
Cordialement,
Ludo - http://www.ubik-products.com
---
"L'amour pour principe et l'ordre pour base; le progres pour but" (A.Comte)