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/
