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)"<[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-----
