Thanks Carsten, Dennis and David for this discussion and your suggestions.
I think all ideas brought up are great starting points for a more flexible
Spring configuration support for the next major version of Jetspeed 2.2.
I think we have two separate configuration flexibility issues to address though
which require different handling, although they can and should go hand in hand.
The first one is flexibility in overriding/augmenting a predefined
configuration with company/project specific settings.
Currently we support this (besides hacking the configurations themselves) through the WEB-INF/assembly/override folder from which configurations are loaded
after the initial/default configuration from the WEB-INF/assembly folder. Furthermore, configuration properties are loaded from WEB-INF/conf/jetspeed.properties
but overrides/additional values can be provided through the WEB-INF/conf/override.properties too.
The Cocoon Spring configurer (or something similar) could be used to make this more flexible/extended, although I agree with Dennis we might want to make that
more "project" independent, e.g. not looking for cocoon specific folders like META-INF/cocoon/ etc., but that should be easy enough to do.
The more complex configuration flexibility issue though is what David Jencks brought up: swapping or plugging in specific configurations as replacement for
default provided features, e.g. replacing the CastorXmlPageManager for the DatabasePageManager.
Currently we only have a "convenience" solution by providing a
WEB-INF/assembly/alternate/db-page-manager.xml which replaces all the beans defined in
the WEB-INF/assembly/page-manger.xml configuration.
The real problem with this is that these two files contain multiple beans which depends on each other, so you really need to "override" not just one bean
definition but a whole set. This of course is just one example. A similar (and even more complex to override) one is swapping the default database security
store for LDAP.
The real problem here is that other beans within the configuration refer to these beans too (by id), so the network of dependencies is actually quite complex
and difficult to maintain or to track down by hand. Using the Spring Eclipse IDE plugin (for instance) helps, but still it is quite a task to handle this
without extensive documentation and trial and error testing if you didn't miss anything or maybe want to "strip out" beans you won't need in a certain setup.
For the above situations, our current override solution, nor something like the
Cocoon Spring configurer can provide a real solution.
I do think though we might be able to solve this too *with* spring itself using
a special Spring 2.0 XML Schema-based extension.
AFAIK, one "feature" Spring currently doesn't provide out of the box (but IMO
should) is *conditional* bean loading.
As the Spring documentation says: a custom XML Schema NamespaceHandler can
register *zero* or more bean definitions.
So, with a new XML Schema handling conditional logic beans for things like if, when,
choose (e.g. like jstl) which can wrap around "normal" bean definitions,
it should become rather easy to test on conditions if a bean definition is
needed or should be ignored.
Example:
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xmlns:cond="http://portals.apache.org/jetspeed-2/schema/spring-cond";
... >
<cond:choose>
<cond:when test="${pagemanagment='database'}">
<!-- DB PageManager -->
<bean id="org.apache.jetspeed.page.PageManagerImpl"
name="pageManagerImpl"
init-method="init"
class="org.apache.jetspeed.page.impl.DatabasePageManager">
...
</bean>
<!-- Transaction Proxying -->
<bean id="org.apache.jetspeed.page.PageManager" name="pageManager"
parent="PageManagerTransactionProxy">
<property name="proxyInterfaces">
<value>org.apache.jetspeed.page.PageManager</value>
</property>
<property name="target">
<ref bean="pageManagerImpl" />
</property>
...
</bean>
</cond:when>
<cond:otherwise>
<bean id="org.apache.jetspeed.page.PageManager" name="pageManager"
class="org.apache.jetspeed.page.psml.CastorXmlPageManager">
...
</bean>
<!-- other CastorXmlPagemaner related/dependent beans -->
<bean ..../>
</cond:otherwise>
...
</beans>
Using something like this, selecting a different implementation for a certain jetspeed *feature*, possibly involving multiple beans, would only require changing
a single property!
Additionally, setting up test configurations for (only) a certain feature would too become much easier instead of our current "hard coded" selection of certain
assembly files in the JUnit test suites: we can simply have all standard configurations loaded but only "enable" those we need.
And we can also provide some tooling to actually "strip down" the large and complex set of assembly definitions down to that what's actually needed and write
that out to a (single) custom configuration file. I myself hate it to have to track down which assembly file contains a certain bean definition.
Some time ago I slightly proposed a new maven-2 plugin for setting up a Jetspeed-2 Spring
configuration by defining only the "features" needed like:
...
<configuration>
<features>
<feature name="pagemanagement" value="database"/> <!-- or JCR, Xml, etc.
-->
<feature name="server" value="Jetty"/> <!-- or Tomcat, WebSphere, etc.
-->
<feature name="naming" value="JNDI" />
<feature name="authentication" value="NTLM"/> <!-- or Container, A-Select,
etc. -->
<feature name="pageaggregator" value="portal,desktop"/> <!-- or maybe just
portal, etc. -->
...
</features>
</configuration>
My idea back then was using these settings to actually generate/write out only the bean definitions needed for a custom portal, but with a conditional XML
Schema extension that might not even be needed anymore and a simple jetspeed-configuration.properties file loaded at runtime would do the trick too.
I really wonder why such a conditional XML Schema extension isn't provided by Spring already. Of course, I haven't actually tried to write this yet, but it
seems quite plausible to do so.
Does anyone have knowledge about something like this or similar already
available?
I guess I probably need to check the Spring forums/mailing lists first before
continuing down this path...
Anyway, comments are welcome :)
Regards,
Ate
David Jencks wrote:
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
