jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Meschberger <fmesc...@gmail.com>
Subject Re: Component releases, proposed solution
Date Thu, 24 Jul 2008 06:53:37 GMT

Thomas Müller schrieb:
> Hi,
>> Major new developments -- the implementation of the foreseen JCR 2.0 ACL
>> functionality comes to mind -- should be done on development branches and
>> merged back into trunk as the developer(s) see fit aka ready for release.
>> Regular development still takes place on trunk, of course.
> If done correctly, major new development can be done in the trunk
> without risk.

Sure, if it only concerns a single location or limited set of locations. 
If it touches multiple places, this is not that easy.

> How to do that: Use a (static final boolean) constant to
> enable / disable a certain new feature or new code path. It is used in
> the DataStore implementation. At first, it was disabled (only enabled
> when I run tests), and now it is enabled by default:
> class InternalValue {
>    public static final boolean USE_DATA_STORE =
>         Boolean.valueOf(System.getProperty("org.jackrabbit.useDataStore",
> "true")).booleanValue();
> }
> and then, everywhere where it is required, do this:
>   // new code
> } else {
>   // old code
> }
> As an added advantage, it's easy to find out if this feature is
> responsible for a problem, by disabling the system property.

I basically like the idea but have my reservations with respect to 
system property use: It makes it difficult in embedded situations and 
even almost makes it impossible to use in app server or servlet 
container environments. For example: you want to have two repositories 
in the same Java VM, one with  and one without data store....

If is really just for testing, a "public" field is bad, because this 
quickly becomes (de-facto) API. And a branch may still be better suited.

Probably better -- also for visibility -- would be to have a 
functionality to provide this kind of setup as part of the Repository 
descriptors. (And yes, I cannot imagine how to implement this in the 
InternalValue class you presented. Maybe the use case is slightly wrong 
in that the InternalValue should just use a "store", which in turn 
either uses the new data store code or the old code and has to be setup 


View raw message