portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ate Douma <...@douma.nu>
Subject Re: [RT] Spring Configuation
Date Wed, 21 Nov 2007 01:39:16 GMT
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:cziegeler@apache.org] Sent: Friday, 
>>> November 16, 2007 12:27 PM
>>> To: jetspeed-dev@portals.apache.org
>>> 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
>>> cziegeler@apache.org
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
>>> For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
>>>
>>> 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: jetspeed-dev-unsubscribe@portals.apache.org
>>> For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
>> For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
>>
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org


Mime
View raw message