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/ > >
