rave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ate Douma <...@douma.nu>
Subject Modularized feature managment and configuration
Date Fri, 13 May 2011 14:11:58 GMT
On 05/11/2011 05:47 PM, Marlon Pierce wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Raminder pointed out a simpler solution, at least for config files like applicationContext-security.xml.
We can have different optional configurations such as applicationContext-security-vanilla.xml,
applicationContext-security-openid.xml, etc, and then filter these in web.xml using a top
level pom property (ie web.xml has applicationContext-security-${securityFlavor}.xml, and
point resource filtering to include web.xml).
>
>
> Probably there are better solutions, but this seems better than using profiles in this
case.
Yes, that already is (a bit) better than using profiles.

In general I think we should stay away from "customizing" a build artifact 
during the build itself. If we would do that, the artifact itself (as deployed 
to a maven repository or otherwise downloadable release) becomes 
non-deterministic what features it actually contains or has configured.

For the time being (before our first release) this all isn't really critical 
yet, but we will have to come up with a good and reliable module/feature 
management and corresponding runtime configuration.

There are soo many ways to tackle this problem, each with its benefits and 
downsides, its difficult to say what will work well/best for us already right now.

For now I just want to bring up a few things I think are important to consider:

* externalize configurable/customizable "properties" or meta-data outside the 
web applications, either by loading/storing them on file system like under 
$CATALINA_BASE/conf or in an external database/repository (then should have a 
runtime/ui for maintenance)

* if feasible modules could be packaged/bundled as a self contained single 
archive (zip or jar) supporting a simple "drop in" (manually before startup) or 
through a runtime deployment service. This is the area where OSGi might actually 
be interesting to consider, although I'm not convinced (yet) if the technical 
and infrastructural overhead is worth it, yet. A simple "deploy" folder with a 
file/folder change listener might be good enough and is easy enough to write.

* for (low-level) feature/module configuration, e.g. spring configuration and 
DI, auto-wiring and auto-scanning (from module jar resource/classpath) might be 
feasible here too. Using Spring Annotations however I'm a bit concerned about as 
it is easy to write, but impossible/difficult to customize at integration time.

* Using Spring PropertyPlaceholderConfigurer with an externalized properties 
file should be very useful to allow for easy customizing specific bean properties.

* A good spring configuration customization pattern is to support "overriding" 
configuration definitions. Spring loads beans in sequence of processing, and if 
you redefine a bean from a later loaded configuration file it will simply 
"replace" the original bean definition. By predefining an (initially empty) 
extra/override folder (through a properties file, so its location itself isn't 
"fixed"), standard/default packaged and configured beans then can be easily 
overridden or customized.

* A more exotic but very powerful customization of Spring configuration loading 
could be to add actual runtime filtering capabilities to the configuration itself.
I wrote something like that a few years ago for the Jetspeed-2 portal project 
which uses a simple properties file of enabled "features" or categories/tags 
which are then at runtime used to filter out spring beans *before* they are 
loaded/seen by Spring itself.
This allowed us to package every portal feature (component) in a single build, 
and only selectively enable/disable those which are actually in use. And even 
allows for different variants and configurations for the same feature.
For end-users/integrators this then is really trivial to setup as they only need 
to modify one simple properties file to select the features to activate: no need 
to dive in complex Spring configuration customizations themselves (although they 
still can).
For this solution I leveraged custom <meta> tags within spring beans like this:

   <bean name="xmlPageManager"
         class="org.apache.jetspeed.page.psml.CastorXmlPageManager">
     <meta key="j2:cat" value="xmlPageManager or pageSerializer" />
     ...
   </bean>

This functionality for Jetspeed-2 is (partly) documented here:

   http://portals.apache.org/jetspeed-2/devguide/spring-config.html

Woonsan recently added a simpler but very similar solution to our Hippo 
site-toolkit framework leveraging embedded Jexl script evaluation, see:
   https://issues.onehippo.com/browse/HSTTWO-1023

I'm not proposing we should start using this type of solution though, but I 
thought it good to point out as one of the options.
There is also a downside to this solution which everyone should be aware of.
Spring is unaware of this conditional filtering. Something alike has often been 
requested but Springsource never found this interesting or appealing enough to 
do. And therefore, standard Spring (IDE) tools also won't see or recognize it, 
possibly making those less or even no longer capable to use.

HTH to get the discussion rolling :)

Regards,

Ate

>
>
> Marlon
>
>
> On 5/6/11 5:02 PM, Marlon Pierce wrote:
>> Using profiles would be one way to do it but would have limits.  We could use alternative
resource lists for minor configuration differences and alternative module lists for major
optional features, but we'd have to create a distinct profile for each combination of options.
This could get out of hand and also be fragile.
>>
>>
>>
>>
>> Marlon
>>
>>
>> On 5/6/11 4:50 PM, Franklin, Matthew B. wrote:
>>> What do we, as a team, want to do about specialized features?  OpenID
>>> support is a good thing to have, but is probably not the majority use
>>> case.  How should we handle multiple implementations within Rave?  Is it
>>> possible with maven to choose a set of implementations at build time via
>>> profiles?
>>
>>> -Matt
>>
>>> On 5/6/11 4:37 PM, "Raminderjeet Singh (JIRA)"<jira@apache.org>  wrote:
>>
>>>>
>>>>     [
>>>> https://issues.apache.org/jira/browse/RAVE-23?page=com.atlassian.jira.plug
>>>> in.system.issuetabpanels:comment-tabpanel&focusedCommentId=13030127#commen
>>>> t-13030127 ]
>>>>
>>>> Raminderjeet Singh commented on RAVE-23:
>>>> ----------------------------------------
>>>>
>>>> Added openid support. Currently you need to use
>>>> http://rave2011.myopenid.com/ as that is the only registered id in
>>>> initial_data.sql and for login to myopenid use rave2011. You can add more
>>>> URLs into the script. Registration of new openid should be handled in
>>>> user registration. We need to find how can we associate existing user
>>>> with openid URL. I used default view page for openid.
>>>>
>>>>> Implement OpenID authentication
>>>>> --------------------------------
>>>>>
>>>>>                  Key: RAVE-23
>>>>>                  URL: https://issues.apache.org/jira/browse/RAVE-23
>>>>>              Project: Rave
>>>>>           Issue Type: Sub-task
>>>>>             Reporter: Marlon Pierce
>>>>>             Assignee: Raminderjeet Singh
>>>>>
>>>>
>>>>
>>>> --
>>>> This message is automatically generated by JIRA.
>>>> For more information on JIRA, see: http://www.atlassian.com/software/jira
>>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.16 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQEcBAEBAgAGBQJNyq+JAAoJEEfVXEODPFIDLH0H/RehyIE6VkfaggmE5ewVKv2e
> sRG3jUL3kZ+Oth87M29/Y690acFXYr7EoiSpqOFomK4lsjFWLcVXQ8E0C+1VYSvn
> 3kjlB6f1vyVt/MxK0QPBsQXE79M61g5OXLaPtf0qnKbHd2Kf+/cZ3UwouYwo0Dte
> zZWWKtmq0x/TgCCwUzR/lDloCT+uBtEILNL46AGAZQRlmJyGh4KHT54l9GzjkLk/
> 5KCKuXIDjckp55dFnJhDNdF4wti0pkBTciR+/yCfi0ty1heOe9CxV/Yb23NkMfd5
> IhEAnDnslO2XBfEq2D37Q0L38ld4AMsJETIT+Y1gMR/kIqoVe75h0YUz3fHNydU=
> =KRir
> -----END PGP SIGNATURE-----


Mime
View raw message