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)"<[email protected]> 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-----
>
