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/
