archiva-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "nicolas de loof" <nico...@apache.org>
Subject Re: An experiment with Spring
Date Fri, 22 Feb 2008 06:03:26 GMT
I've asked springsource guys for help on this topic.

I sent Chris Beams <chris.beams@springsource.com> a simplified project with
testcase to investigate.

Nico.


2008/2/22, Brett Porter <brett@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 <brett@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 <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/
> >>
> >>
>
> --
> Brett Porter
> brett@apache.org
> http://blogs.exist.com/bporter/
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message