rave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott Wilson <scott.bradley.wil...@gmail.com>
Subject Re: Modularized feature managment and configuration
Date Mon, 16 May 2011 14:31:58 GMT

On 13 May 2011, at 15:11, Ate Douma wrote:

> On 05/11/2011 05:47 PM, Marlon Pierce wrote:
>> 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.

Agreed, this could cause quite a few issues for anyone building on Rave.

> 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.

Definitely. Given that a significant interest in Rave is to use it as a base for building
more specialised products, a good extension system is needed.
> 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.

Its a tricky question. I'm similarly in two minds about OSGI.

Both Shindig and Wookie use XML-based feature loading systems, however these only inject client-side
scripting into widgets/gadgets. Server-side extensions are harder to manage, which is where
OSGI starts to look attractive.

> * 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
>>>>> 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
>> Version: GnuPG/MacGPG2 v2.0.16 (Darwin)
>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>> sRG3jUL3kZ+Oth87M29/Y690acFXYr7EoiSpqOFomK4lsjFWLcVXQ8E0C+1VYSvn
>> 3kjlB6f1vyVt/MxK0QPBsQXE79M61g5OXLaPtf0qnKbHd2Kf+/cZ3UwouYwo0Dte
>> zZWWKtmq0x/TgCCwUzR/lDloCT+uBtEILNL46AGAZQRlmJyGh4KHT54l9GzjkLk/
>> 5KCKuXIDjckp55dFnJhDNdF4wti0pkBTciR+/yCfi0ty1heOe9CxV/Yb23NkMfd5
>> IhEAnDnslO2XBfEq2D37Q0L38ld4AMsJETIT+Y1gMR/kIqoVe75h0YUz3fHNydU=
>> =KRir
>> -----END PGP SIGNATURE-----

View raw message