I think that we might be hitting the limitations of spring as a
component framework. My understanding is that spring is great as a
wiring framework for a single set of known components but does not
provide much functionality for swapping or plugging in
implementations (classes) or instances (spring beans) of services. I
think for this you need another level of component framework. I
really don't advise trying to write your own. The frameworks I know
about that would probably solve this kind of problem for jetspeed, in
order of my familiarity with them:
1. geronimo gbean framework. This definitely provides everything you
would need but AFAIK has never been run embedded in an application
and currently requires you to write down metadata for each
component. We can remove the latter restriction pretty easily but
this is not a popular solution at the moment and would probably have
too steep a learning curve.
2. osgi-spring. I don't know much about this but osgi provides a
pretty sophisticated classloader model and it combines with spring
for component wiring. I don't have any idea how or if component
references between modules (bundles) get resolved or how you specify
which bundles that provide a service you want to use. This seems to
be getting more popular.
3. plexus. I know virtually nothing about plexus or its capabilities
but suspect it has a lot of the needed properties since it's used in
maven for moderately similar purposes.
With any of these there may be odd interactions between the component
framework jetspeed is using and the component framework used by the
app server its running in. In particular using the classloader
structure provided by the app server may reduce inappropriate
interactions.
thanks
david jencks
On Nov 19, 2007, at 9:39 AM, Dennis Dam wrote:
Hi,
such a configuration framework could be useful, but I think what
Carsten is suggesting here goes much further than providing a
framework for injecting Spring properties from different
configuration sources. Please correct me if I'm wrong. It is *part*
of what the Cocoon Spring configurator does, but it also provides a
bean definition overriding functionality and bean registry
functionality. I think it would be useful to standardize these
functionalities in one project. There could be even more "common"
features which can be added. There are several advantages to such a
framework:
- reduce the development time for setting up the Spring
configuration (obviously)
- reduce the learning time for Apache developers coming from
different projects.
- a best-of-X-worlds solution: evaluate the Spring configuration
experiences / troubles of different projects and take the best
ideas from each project, starting with Jetspeed and Cocoon :)
Just another idea from my side for such a common Spring
configurator: make it possible to use N layers of bean definitions,
each layer overriding the bean definitions of the previous layer.
We do this in jetspeed now with 2 layers. But you could imagine the
usage of 3 layers or more (please replace "jetspeed" with your
favorite project here) :
1. the default jetspeed bean definitions
2. bean definitions for a company-specific jetspeed distribution
3. bean definitions for a project-specific implementation for the
company-specific jetspeed distribution
Although personally I think too many layers will make reading the
bean definitions too difficult, at least you leave the choice to
the developer.
It might also proof useful to have a default configuration engine
which reads properties from pre-defined locations (convention over
configuration). This is similar to the approach the Cocoon Spring
Configurator takes, but ofcourse the paths to the locations should
be project independent (i.e. replace 'cocoon' with something
neutral). In this way you know where to look for Spring properties
files in every Apache project.
By the way, the dynamic registry of the Cocoon Spring Configurator
is very similar to a bean registry I used before.. It seems like
the wheel is being reinvented a lot :)
Dennis
Boyce, Keith Garry wrote:
I suggest the following which I have used successfully for a while.
Rather than a particular solution it offers an integration point with
different configuration engines.
http://forum.springframework.org/showthread.php?t=12271
I use it with jconfig.
-----Original Message-----
From: Carsten Ziegeler [mailto:[EMAIL PROTECTED] Sent: Friday,
November 16, 2007 12:27 PM
To: [email protected]
Subject: [RT] Spring Configuation
Just sitting in Ate's and David's presentation about Jetspeed I
had the
feeling that the stuff you did for Spring configurations (like
overriding etc.) is similar to something we did in the Cocoon
project.
We have there a Spring configurator which is absolutely
independent of
Cocoon and provides support for property handling (we call settings),
overwriting of configurations, automatic configuration etc.
See here for some documentation:
http://cocoon.apache.org/subprojects/configuration/1.0/spring-
configurat
or/1.0/1304_1_1.html
Now, although the project is current hosted at Cocoon it has a
much more
common nature. This is just an idea out of my head, but perhaps we
could
work on a common configurator which is then used by several
projects at
Apache? This would make the live of users perhaps a little bit
easier as
they can apply the configuration knowledge for several projects.
This does not imply that I want to force Jetspeed to use our Cocoon
stuff, of course.
WDYT?
PS: Don't expect an answer from me in the next three weeks as I'm on
vacation, but I wanted to throw this in now :)
Carsten
--
Carsten Ziegeler
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
This message is a PRIVATE communication.
If you are not the intended recipient, please do not read, copy
or use it and do not disclose it to others. Please notify the
sender of the delivery error by replying to this message and then
delete from your system. Thank you.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
