I've asked springsource guys for help on this topic. I sent Chris Beams <[EMAIL PROTECTED]> a simplified project with testcase to investigate.
Nico. 2008/2/22, Brett Porter <[EMAIL PROTECTED]>: > > 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 <[EMAIL PROTECTED]>: > >> > >> 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 <[EMAIL PROTECTED]>: > >>>> > >>>> 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 <[EMAIL PROTECTED]>: > >>>>> > >>>>> 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 <[EMAIL PROTECTED]>: > >>>>>> > >>>>>> 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 > >>>>>> [EMAIL PROTECTED] > >>>>>> http://blogs.exist.com/bporter/ > >>>>>> > >>>>>> > >>>>> > >>>> > >> > >> -- > >> Brett Porter > >> [EMAIL PROTECTED] > >> http://blogs.exist.com/bporter/ > >> > >> > > -- > Brett Porter > [EMAIL PROTECTED] > http://blogs.exist.com/bporter/ > >
