You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@rave.apache.org by Ate Douma <at...@douma.nu> on 2011/05/13 16:11:58 UTC
Modularized feature managment and configuration
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)"<ji...@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-----
Re: Modularized feature managment and configuration
Posted by "Franklin, Matthew B." <mf...@mitre.org>.
On 5/16/11 10:31 AM, "Scott Wilson" <sc...@gmail.com> wrote:
>
>>
>> * 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.
IMHO, OSGI would vastly overcomplicate the solution. I think we can all
agree the features that we are looking for are tied to the dynamic
modules. OSGI in my experience, ends up polluting the code base and
creates a much more complex system than I would want to see.
We can override pretty much everything in the Spring application context
by adding beans that are marked primary to the scanned classpath...
Re: Modularized feature managment and configuration
Posted by Scott Wilson <sc...@gmail.com>.
On 13 May 2011, at 15:11, Ate Douma wrote:
> 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.
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)"<ji...@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-----
>