You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Felix Meschberger <fm...@gmail.com> on 2009/12/10 11:13:36 UTC
Runmode support for /etc/map configuration
Hi all,
In our commercial CMS application we have a mechanism where we separate
authoring instances (where content authors fill in content) from
publishing instances (where internet surfers hit). Content authors can
validate the content before publishing it to the publishing instances.
This all works well, except for configuration stored in the /etc/map
structure to configure the URL to Resource mapping of the Resource Resolver.
The problem is that we cannot prepare this configuration on the
authoring instance without affecting the operation of the authoring
instance. The reason for this is that the /etc/map location is currently
fixed and cannot be configured.
To overcome this limitation two options come to my mind:
(O1) Make /etc/map location configurable
This enables us to configure the /etc/map location and configure a
publishing instance specific structure on the author instance.
(O2) Add support for RunModes
Our CMS system leverages the RunMode service from
contrib/extensions/runmode to detect whether the system is running as an
authoring or a publishing instance.
So, we could enhance the entries in the /etc/map structure to optionally
provide a sling:runmode property (single- or multi-value string type).
If such a property is set, the entry is only used if the
RunMode.isActive(String[]) returns true.
WDYT of such extensions ?
Regards
Felix
Re: Runmode support for /etc/map configuration
Posted by Felix Meschberger <fm...@gmail.com>.
Hi Ian,
In share your concerns with backwards compatibility.
These are taken care of as follows:
(O1) Make /etc/map location configurable
The default location remains /etc/map. Thus if there is no
configuration, the /etc/map structure is still read.
(O2) Add support for RunModes
The sling:runmode properties are optional. If a configuration entry
doesn't have this property set, the entry is always used.
Hope this helps.
Regards
Felix
Ian Boston schrieb:
> On 10 Dec 2009, at 10:13, Felix Meschberger wrote:
>
>> Hi all,
>>
>> In our commercial CMS application we have a mechanism where we separate
>> authoring instances (where content authors fill in content) from
>> publishing instances (where internet surfers hit). Content authors can
>> validate the content before publishing it to the publishing instances.
>>
>> This all works well, except for configuration stored in the /etc/map
>> structure to configure the URL to Resource mapping of the Resource Resolver.
>>
>> The problem is that we cannot prepare this configuration on the
>> authoring instance without affecting the operation of the authoring
>> instance. The reason for this is that the /etc/map location is currently
>> fixed and cannot be configured.
>>
>> To overcome this limitation two options come to my mind:
>>
>> (O1) Make /etc/map location configurable
>>
>> This enables us to configure the /etc/map location and configure a
>> publishing instance specific structure on the author instance.
>>
>>
>> (O2) Add support for RunModes
>>
>> Our CMS system leverages the RunMode service from
>> contrib/extensions/runmode to detect whether the system is running as an
>> authoring or a publishing instance.
>>
>> So, we could enhance the entries in the /etc/map structure to optionally
>> provide a sling:runmode property (single- or multi-value string type).
>> If such a property is set, the entry is only used if the
>> RunMode.isActive(String[]) returns true.
>>
>>
>> WDYT of such extensions ?
>
>
> I would be interested to know the differences between in the operation of Sling in the different runmodes. As you know we are using Sling in a mode where everyone is an author, so I would be concerned to see optimisations to a published mode, that explicitly disadvantaged an authoring mode over where it is now.
>
> I see no problem in making optimisations based on run mode that only create an advantage for that runmode (eg change in cache expiry policy, assuming no content modification etc)
>
> So in general, provided the extensions are not intrusive then I am supportive.
>
>
> Ian
>
>
>
>
>
>
>> Regards
>> Felix
>
>
Re: Runmode support for /etc/map configuration
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Thu, Dec 10, 2009 at 11:25 AM, Ian Boston <ie...@tfd.co.uk> wrote:
> ...I would be interested to know the differences between in the operation of Sling
> in the different runmodes....
Currently the Sling code is absolutely unaware of runmodes, except
jcrinstall which can select bundles and configurations to install
based on runmodes [1].
If you need optimizations based on runmodes, I'd suggest basing them
on configurations and/or optional bundles.
-Bertrand
[1] http://sling.apache.org/site/jcr-installer-jcrjcrinstall-and-osgiinstaller.html
Re: Runmode support for /etc/map configuration
Posted by Ian Boston <ie...@tfd.co.uk>.
On 10 Dec 2009, at 10:13, Felix Meschberger wrote:
> Hi all,
>
> In our commercial CMS application we have a mechanism where we separate
> authoring instances (where content authors fill in content) from
> publishing instances (where internet surfers hit). Content authors can
> validate the content before publishing it to the publishing instances.
>
> This all works well, except for configuration stored in the /etc/map
> structure to configure the URL to Resource mapping of the Resource Resolver.
>
> The problem is that we cannot prepare this configuration on the
> authoring instance without affecting the operation of the authoring
> instance. The reason for this is that the /etc/map location is currently
> fixed and cannot be configured.
>
> To overcome this limitation two options come to my mind:
>
> (O1) Make /etc/map location configurable
>
> This enables us to configure the /etc/map location and configure a
> publishing instance specific structure on the author instance.
>
>
> (O2) Add support for RunModes
>
> Our CMS system leverages the RunMode service from
> contrib/extensions/runmode to detect whether the system is running as an
> authoring or a publishing instance.
>
> So, we could enhance the entries in the /etc/map structure to optionally
> provide a sling:runmode property (single- or multi-value string type).
> If such a property is set, the entry is only used if the
> RunMode.isActive(String[]) returns true.
>
>
> WDYT of such extensions ?
I would be interested to know the differences between in the operation of Sling in the different runmodes. As you know we are using Sling in a mode where everyone is an author, so I would be concerned to see optimisations to a published mode, that explicitly disadvantaged an authoring mode over where it is now.
I see no problem in making optimisations based on run mode that only create an advantage for that runmode (eg change in cache expiry policy, assuming no content modification etc)
So in general, provided the extensions are not intrusive then I am supportive.
Ian
>
> Regards
> Felix
Re: Runmode support for /etc/map configuration
Posted by Carsten Ziegeler <cz...@apache.org>.
What about building support for this completly into jcrinstall (or a
plugin for jcr install)? Let's call this piece RunModeProvider.
(This is just a wild idea....)
We don't change the jcr resource module, it always picks up everything
at /etc/maps.
The RunModeProvider works like the stuff we have in jcr install for
bundles and configurations, but acts on mapping nodes. It just copies
them depending on the run mode to /etc/maps.
Or it registers a resource provider at /etc/maps
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: Runmode support for /etc/map configuration
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Carsten Ziegeler schrieb:
> Felix Meschberger wrote:
>> Hi all,
>>
>> In our commercial CMS application we have a mechanism where we separate
>> authoring instances (where content authors fill in content) from
>> publishing instances (where internet surfers hit). Content authors can
>> validate the content before publishing it to the publishing instances.
>>
>> This all works well, except for configuration stored in the /etc/map
>> structure to configure the URL to Resource mapping of the Resource Resolver.
>>
>> The problem is that we cannot prepare this configuration on the
>> authoring instance without affecting the operation of the authoring
>> instance. The reason for this is that the /etc/map location is currently
>> fixed and cannot be configured.
>>
>> To overcome this limitation two options come to my mind:
>>
>> (O1) Make /etc/map location configurable
>>
>> This enables us to configure the /etc/map location and configure a
>> publishing instance specific structure on the author instance.
>>
>>
>> (O2) Add support for RunModes
>>
>> Our CMS system leverages the RunMode service from
>> contrib/extensions/runmode to detect whether the system is running as an
>> authoring or a publishing instance.
>>
>> So, we could enhance the entries in the /etc/map structure to optionally
>> provide a sling:runmode property (single- or multi-value string type).
>> If such a property is set, the entry is only used if the
>> RunMode.isActive(String[]) returns true.
>>
>>
>> WDYT of such extensions ?
>
> It would be nice if we can find a solution which does not add a
> dependency from the jcr resource module to the run modes - run modes
> should really be an optional thing.
>
> I don't have a very good idea atm, but I think some IoC solution could
> solve this. Instead letting the resolver look for the configurations,
> they should be provided by someone.
The dependency on the RunMode would be optional. If the RunMode service
would not be present the entries with a sling:runmode property could be
ignored completely (assuming that Sling is running in no RunMode at all).
But I agree, it somewhat is running on the edge ...
Regards
Felix
>
> Carsten
>
Re: Runmode support for /etc/map configuration
Posted by Carsten Ziegeler <cz...@apache.org>.
Felix Meschberger wrote:
> Hi all,
>
> In our commercial CMS application we have a mechanism where we separate
> authoring instances (where content authors fill in content) from
> publishing instances (where internet surfers hit). Content authors can
> validate the content before publishing it to the publishing instances.
>
> This all works well, except for configuration stored in the /etc/map
> structure to configure the URL to Resource mapping of the Resource Resolver.
>
> The problem is that we cannot prepare this configuration on the
> authoring instance without affecting the operation of the authoring
> instance. The reason for this is that the /etc/map location is currently
> fixed and cannot be configured.
>
> To overcome this limitation two options come to my mind:
>
> (O1) Make /etc/map location configurable
>
> This enables us to configure the /etc/map location and configure a
> publishing instance specific structure on the author instance.
>
>
> (O2) Add support for RunModes
>
> Our CMS system leverages the RunMode service from
> contrib/extensions/runmode to detect whether the system is running as an
> authoring or a publishing instance.
>
> So, we could enhance the entries in the /etc/map structure to optionally
> provide a sling:runmode property (single- or multi-value string type).
> If such a property is set, the entry is only used if the
> RunMode.isActive(String[]) returns true.
>
>
> WDYT of such extensions ?
It would be nice if we can find a solution which does not add a
dependency from the jcr resource module to the run modes - run modes
should really be an optional thing.
I don't have a very good idea atm, but I think some IoC solution could
solve this. Instead letting the resolver look for the configurations,
they should be provided by someone.
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: Runmode support for /etc/map configuration
Posted by Alexander Klimetschek <ak...@day.com>.
On Thu, Dec 10, 2009 at 11:31, Alexander Klimetschek <ak...@day.com> wrote:
> Might be clearer. It doesn't allow for mapping a mapping config node
> to multiple folders,
I meant "to multiple runmodes" of course ;-)
Alex
--
Alexander Klimetschek
alexander.klimetschek@day.com
Re: Runmode support for /etc/map configuration
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Thu, Dec 10, 2009 at 5:35 PM, Alexander Klimetschek <ak...@day.com> wrote:
> On Thu, Dec 10, 2009 at 17:06, Bertrand Delacretaz
> <bd...@apache.org> wrote:
>> On Thu, Dec 10, 2009 at 4:53 PM, Felix Meschberger <fm...@gmail.com> wrote:
>>> ...So, I will go for option (1): make the /etc/map location configurable....
>>
>> Note that it would be good to be able to find the actual value used
>> easily, for example via a console plugin and/or INFO log messages.
>
> There already exists such a web console plugin at
> /system/console/jcrresolver which would just have to display this
> path.
right, sounds like the right place to display that.
-Bertrand
Re: Runmode support for /etc/map configuration
Posted by Alexander Klimetschek <ak...@day.com>.
On Thu, Dec 10, 2009 at 17:06, Bertrand Delacretaz
<bd...@apache.org> wrote:
> On Thu, Dec 10, 2009 at 4:53 PM, Felix Meschberger <fm...@gmail.com> wrote:
>> ...So, I will go for option (1): make the /etc/map location configurable....
>
> Note that it would be good to be able to find the actual value used
> easily, for example via a console plugin and/or INFO log messages.
There already exists such a web console plugin at
/system/console/jcrresolver which would just have to display this
path.
Regards,
Alex
--
Alexander Klimetschek
alexander.klimetschek@day.com
Re: Runmode support for /etc/map configuration
Posted by David Nuescheler <un...@day.com>.
here is my take on the exact use case that we have with the runmode
aware /etc/map it is probably seldomly the case that we actually have
different
mappings it is just that hostname get into our way.
in the classic wcm authoring or development environment one would still like
to see urls that are as close as the ones that we have in production but of
course we would not like the links to be rewritten to go fully qualified urls
with a domain name...
so generally i think the /etc/map tree will look very similar from
runmode to runmode but in one every other runmode other than production
i would probably either want to put the domain name somewhere in to the
url that indicates to the user that this would be a link that would go
to http://www.example.org/test in production. so probably could be
resolved to something like http://mydev/www.example.org/test .
keep in mind though that usually there are only going to be very few
link where that would actually make a difference since this assumes
that an application has cross domain links under management within
one sling instance.
to be perfectly honest, for our commercial solution, i think
we can do perfectly without the runmode aware /etc/map
regards,
david
On Thu, Dec 10, 2009 at 9:05 PM, Felix Meschberger <fm...@gmail.com> wrote:
> Hi,
>
> Bertrand Delacretaz schrieb:
>> On Thu, Dec 10, 2009 at 4:53 PM, Felix Meschberger <fm...@gmail.com> wrote:
>>> ...So, I will go for option (1): make the /etc/map location configurable....
>>
>> Note that it would be good to be able to find the actual value used
>> easily, for example via a console plugin and/or INFO log messages.
>
> Yes, makes sense.
>
> Regards
> Felix
>
>>
>> -Bertrand
>>
>
--
David Nuescheler
Chief Technology Officer
mailto: david.nuescheler@day.com
web: http://www.day.com/ http://dev.day.com
twitter: @daysoftware
Re: Runmode support for /etc/map configuration
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Bertrand Delacretaz schrieb:
> On Thu, Dec 10, 2009 at 4:53 PM, Felix Meschberger <fm...@gmail.com> wrote:
>> ...So, I will go for option (1): make the /etc/map location configurable....
>
> Note that it would be good to be able to find the actual value used
> easily, for example via a console plugin and/or INFO log messages.
Yes, makes sense.
Regards
Felix
>
> -Bertrand
>
Re: Runmode support for /etc/map configuration
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Thu, Dec 10, 2009 at 4:53 PM, Felix Meschberger <fm...@gmail.com> wrote:
> ...So, I will go for option (1): make the /etc/map location configurable....
Note that it would be good to be able to find the actual value used
easily, for example via a console plugin and/or INFO log messages.
-Bertrand
Re: Runmode support for /etc/map configuration
Posted by Alexander Klimetschek <ak...@day.com>.
On Thu, Dec 10, 2009 at 16:05, Carsten Ziegeler <cz...@apache.org> wrote:
> Rethinking the whole stuff, I'm against adding anything runmode specific
> to the resolution module.
>
> If you look at the current run mode support:
> - Bundles - nothing has been added to the framework - this is managed
> outside by jcr install
> - Configs - config admin does not know about run modes - again jcr install
>
> And we should continue this route.
You are right, adding such a new dependency creates probably more
issues than having to explicitly configure that for various runmodes.
Regards,
Alex
--
Alexander Klimetschek
alexander.klimetschek@day.com
Re: Runmode support for /etc/map configuration
Posted by Felix Meschberger <fm...@gmail.com>.
Hi Carsten
Rethinking the whole thing, I finally come to the same conclusion ...
So, I will go for option (1): make the /etc/map location configurable.
We may still reconsider a modified option (2) in the future. This may be
something like an enablement property which enables (or disables) a
certain entry in the /etc/map tree based on Resource Resolver
configuration. Thus not adding a RunMode dependency to the Resource
Resolver.
So, thanks for the feedback.
Regards
Felix
Carsten Ziegeler schrieb:
> Rethinking the whole stuff, I'm against adding anything runmode specific
> to the resolution module.
>
> If you look at the current run mode support:
> - Bundles - nothing has been added to the framework - this is managed
> outside by jcr install
> - Configs - config admin does not know about run modes - again jcr install
>
> And we should continue this route.
>
> So either we go with O1 and simply make the path configurable (which I
> think we should do anyway) or we find a solution outside of the jcr
> resource module.
>
> Carsten
>
Re: Runmode support for /etc/map configuration
Posted by Carsten Ziegeler <cz...@apache.org>.
Rethinking the whole stuff, I'm against adding anything runmode specific
to the resolution module.
If you look at the current run mode support:
- Bundles - nothing has been added to the framework - this is managed
outside by jcr install
- Configs - config admin does not know about run modes - again jcr install
And we should continue this route.
So either we go with O1 and simply make the path configurable (which I
think we should do anyway) or we find a solution outside of the jcr
resource module.
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: Runmode support for /etc/map configuration
Posted by Alexander Klimetschek <ak...@day.com>.
On Thu, Dec 10, 2009 at 14:47, Felix Meschberger <fm...@gmail.com> wrote:
> Ehrm, this is exactly, what I am proposing as Option 2 ... (more or less).
Yes, as I pointed out, the only difference are the "empty" folders, at
the top level, right below /etc/map.
Regards,
Alex
--
Alexander Klimetschek
alexander.klimetschek@day.com
Re: Runmode support for /etc/map configuration
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Alexander Klimetschek schrieb:
> On Thu, Dec 10, 2009 at 12:27, Felix Meschberger <fm...@gmail.com> wrote:
>> Alexander Klimetschek schrieb:
>>> I also think that the merging for my proposed case isn't that
>>> difficult: you just walk the tree below /etc/map as it is done now and
>>> apply things for the runmode they are in (defined by the ancestor).
>>> First come, first served for duplicate mappings. That is the same as
>>> for implementing O2. The only difference are those "empty" folders
>>> that don't add to the mapping config, but just specify the runmode(s).
>> It is more involved...
>
> AFAICS the /etc/map tree is traversed from top to bottom while the
> config is built up, so on each step, before the traversal goes deeper
> and/or creates a final map entry config, it could simply check for the
> runmodes property and/or if this is an "empty" folder (this could eg.
> be marked by the property being present or by a mixin). If the
> runmode(s) don't match, it won't traverse deeper.
Ehrm, this is exactly, what I am proposing as Option 2 ... (more or less).
Aren't we talking about multiple subtrees of /etc/map to be merged into
a single configuration ?
Regards
Felix
>
> What am I missing?
>
> Regards,
> Alex
>
Re: Runmode support for /etc/map configuration
Posted by Alexander Klimetschek <ak...@day.com>.
On Thu, Dec 10, 2009 at 12:27, Felix Meschberger <fm...@gmail.com> wrote:
> Alexander Klimetschek schrieb:
>> I also think that the merging for my proposed case isn't that
>> difficult: you just walk the tree below /etc/map as it is done now and
>> apply things for the runmode they are in (defined by the ancestor).
>> First come, first served for duplicate mappings. That is the same as
>> for implementing O2. The only difference are those "empty" folders
>> that don't add to the mapping config, but just specify the runmode(s).
>
> It is more involved...
AFAICS the /etc/map tree is traversed from top to bottom while the
config is built up, so on each step, before the traversal goes deeper
and/or creates a final map entry config, it could simply check for the
runmodes property and/or if this is an "empty" folder (this could eg.
be marked by the property being present or by a mixin). If the
runmode(s) don't match, it won't traverse deeper.
What am I missing?
Regards,
Alex
--
Alexander Klimetschek
alexander.klimetschek@day.com
Re: Runmode support for /etc/map configuration
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Alexander Klimetschek schrieb:
> On Thu, Dec 10, 2009 at 12:04, Felix Meschberger <fm...@gmail.com> wrote:
>>> The same merging has to be done for O2. Maybe if we would use approach
>>> O2 with the properties, but allow for additional folders in between
>>> that are not seen as config, we could achieve the same. And the node
>>> name of those additional runmode folders would be free to chose.
>> That's not correct ;-)
>>
>> O2 has a single tree (whether fixed at /etc/map or not). Of this tree of
>> entries the entries with a sling:runmode setting not matching the
>> current RunMode are ignored.
>>
>> Thus there is no merging here.
>
> If you have a sling:runmode property deep down, you need some merging as well:
>
> /etc/map/http/localhost1/app1/@sling:runmode
>
> => http/localhost1 for all modes
> => http/localhost1/app1 only for the modes specified
Yes, but this is no different than today ;-)
>
> I also think that the merging for my proposed case isn't that
> difficult: you just walk the tree below /etc/map as it is done now and
> apply things for the runmode they are in (defined by the ancestor).
> First come, first served for duplicate mappings. That is the same as
> for implementing O2. The only difference are those "empty" folders
> that don't add to the mapping config, but just specify the runmode(s).
It is more involved...
Regards
Felix
>
> Regards,
> Alex
>
Re: Runmode support for /etc/map configuration
Posted by Alexander Klimetschek <ak...@day.com>.
On Thu, Dec 10, 2009 at 12:04, Felix Meschberger <fm...@gmail.com> wrote:
>> The same merging has to be done for O2. Maybe if we would use approach
>> O2 with the properties, but allow for additional folders in between
>> that are not seen as config, we could achieve the same. And the node
>> name of those additional runmode folders would be free to chose.
>
> That's not correct ;-)
>
> O2 has a single tree (whether fixed at /etc/map or not). Of this tree of
> entries the entries with a sling:runmode setting not matching the
> current RunMode are ignored.
>
> Thus there is no merging here.
If you have a sling:runmode property deep down, you need some merging as well:
/etc/map/http/localhost1/app1/@sling:runmode
=> http/localhost1 for all modes
=> http/localhost1/app1 only for the modes specified
I also think that the merging for my proposed case isn't that
difficult: you just walk the tree below /etc/map as it is done now and
apply things for the runmode they are in (defined by the ancestor).
First come, first served for duplicate mappings. That is the same as
for implementing O2. The only difference are those "empty" folders
that don't add to the mapping config, but just specify the runmode(s).
Regards,
Alex
--
Alexander Klimetschek
alexander.klimetschek@day.com
Re: Runmode support for /etc/map configuration
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Alexander Klimetschek schrieb:
>> I don't like this option, because it creates issues:
>>
>> * copy-paste is always problematic (yes, my option O1 has then
>> same issues)
>
> If Bertrand's proposal of using multiple runmodes in the folder name....
Well, this makes things a little bit more complicated ...
and since a system may be running in more than a single RunMode, you
could devise a special runmode used to select common /etc/map setups.
>
>> * merging two tree structures creates additional issues with
>> respect to ordering and expected behaviour (rember that a
>> system may be running with more than one run-mode, so this
>> merge is required)
>
> The same merging has to be done for O2. Maybe if we would use approach
> O2 with the properties, but allow for additional folders in between
> that are not seen as config, we could achieve the same. And the node
> name of those additional runmode folders would be free to chose.
That's not correct ;-)
O2 has a single tree (whether fixed at /etc/map or not). Of this tree of
entries the entries with a sling:runmode setting not matching the
current RunMode are ignored.
Thus there is no merging here.
>
>> * Other than merging this is more or less the same as my
>> option O1 (ok, that's not really a reason for dislike but ;-) )
>
> Then you end up with a bunch of configs (eg. via jcrinstall) like
>
> config.runmode1 => mapping.location = /etc/map/runmode1
> config.runmode2 => mapping.location = /etc/map/runmode2
> etc.
>
> that cry for automation ;-)
Well, yes ;-) So if you expect "tons of RunModes", O2 may be better ...
Regards
Felix
Re: Runmode support for /etc/map configuration
Posted by Alexander Klimetschek <ak...@day.com>.
> I don't like this option, because it creates issues:
>
> * copy-paste is always problematic (yes, my option O1 has then
> same issues)
If Bertrand's proposal of using multiple runmodes in the folder name....
> * merging two tree structures creates additional issues with
> respect to ordering and expected behaviour (rember that a
> system may be running with more than one run-mode, so this
> merge is required)
The same merging has to be done for O2. Maybe if we would use approach
O2 with the properties, but allow for additional folders in between
that are not seen as config, we could achieve the same. And the node
name of those additional runmode folders would be free to chose.
> * Other than merging this is more or less the same as my
> option O1 (ok, that's not really a reason for dislike but ;-) )
Then you end up with a bunch of configs (eg. via jcrinstall) like
config.runmode1 => mapping.location = /etc/map/runmode1
config.runmode2 => mapping.location = /etc/map/runmode2
etc.
that cry for automation ;-)
Regards,
Alex
--
Alexander Klimetschek
alexander.klimetschek@day.com
Re: Runmode support for /etc/map configuration
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Alexander Klimetschek schrieb:
> On Thu, Dec 10, 2009 at 11:13, Felix Meschberger <fm...@gmail.com> wrote:
>> (O2) Add support for RunModes
>>
>> Our CMS system leverages the RunMode service from
>> contrib/extensions/runmode to detect whether the system is running as an
>> authoring or a publishing instance.
>>
>> So, we could enhance the entries in the /etc/map structure to optionally
>> provide a sling:runmode property (single- or multi-value string type).
>> If such a property is set, the entry is only used if the
>> RunMode.isActive(String[]) returns true.
>
> I could also think of a structure with a subfolder per runmode, as it
> is done by jcrinstall for install and config folders. Eg.
>
> /etc/map
> + runmode1
> +http
> + server.com
> ....
> + runmode2
> +http
> + server2.com
> ....
>
> Might be clearer. It doesn't allow for mapping a mapping config node
> to multiple folders, but one could easily copy the config to multiple
> locations.
>
> If the runmode bundle is considered optional, this could also be an
> optional feature, ie. if no runmode bundle is present, the differences
> are ignored and all configs are applied. The question is if that is
> breaking backwards-compatibility in some way? I think if the runmode
> folders are marked, eg. by a special node type, one could easily
> separate between a config with runmode folders "in between" or a plain
> existing one.
I don't like this option, because it creates issues:
* copy-paste is always problematic (yes, my option O1 has then
same issues)
* merging two tree structures creates additional issues with
respect to ordering and expected behaviour (rember that a
system may be running with more than one run-mode, so this
merge is required)
* Other than merging this is more or less the same as my
option O1 (ok, that's not really a reason for dislike but ;-) )
Regards
Felix
Re: Runmode support for /etc/map configuration
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Thu, Dec 10, 2009 at 11:31 AM, Alexander Klimetschek
<ak...@day.com> wrote:
> ...I could also think of a structure with a subfolder per runmode, as it
> is done by jcrinstall for install and config folders. Eg.
>
> /etc/map
> + runmode1
> +http
> + server.com
> ....
> + runmode2
> +http
> + server2.com
> ....
>
> Might be clearer....
I like this as well, it's easier to see what's configured based on the
node structure only.
> ...It doesn't allow for mapping a mapping config node
> to multiple folders, but one could easily copy the config to multiple
> locations....
jcrinstall uses folder names like "config.foo.bar" for things that
must be active in either foo or bar runmodes, we could probably use
the same convention here.
-Bertrand
Re: Runmode support for /etc/map configuration
Posted by Alexander Klimetschek <ak...@day.com>.
On Thu, Dec 10, 2009 at 11:13, Felix Meschberger <fm...@gmail.com> wrote:
> (O2) Add support for RunModes
>
> Our CMS system leverages the RunMode service from
> contrib/extensions/runmode to detect whether the system is running as an
> authoring or a publishing instance.
>
> So, we could enhance the entries in the /etc/map structure to optionally
> provide a sling:runmode property (single- or multi-value string type).
> If such a property is set, the entry is only used if the
> RunMode.isActive(String[]) returns true.
I could also think of a structure with a subfolder per runmode, as it
is done by jcrinstall for install and config folders. Eg.
/etc/map
+ runmode1
+http
+ server.com
....
+ runmode2
+http
+ server2.com
....
Might be clearer. It doesn't allow for mapping a mapping config node
to multiple folders, but one could easily copy the config to multiple
locations.
If the runmode bundle is considered optional, this could also be an
optional feature, ie. if no runmode bundle is present, the differences
are ignored and all configs are applied. The question is if that is
breaking backwards-compatibility in some way? I think if the runmode
folders are marked, eg. by a special node type, one could easily
separate between a config with runmode folders "in between" or a plain
existing one.
Regards,
Alex
--
Alexander Klimetschek
alexander.klimetschek@day.com
Re: Runmode support for /etc/map configuration
Posted by Vidar Ramdal <vi...@idium.no>.
On Thu, Dec 10, 2009 at 11:13 AM, Felix Meschberger <fm...@gmail.com> wrote:
> [...]
> The problem is that we cannot prepare this configuration on the
> authoring instance without affecting the operation of the authoring
> instance. The reason for this is that the /etc/map location is currently
> fixed and cannot be configured.
>
> To overcome this limitation two options come to my mind:
>
> (O1) Make /etc/map location configurable
I support this option. I fear that adding runmodes to the /etc/map
structure will make it harder to maintain. Also, a /etc/map will often
be server-specific, so replicating it between instances will cause a
lot of unused map entries on each instance.
I haven't tried, but I suppose /etc/map entries can be provided as
initial-content and/or picked up by JCRInstall? If so, creating map
entries from other instances can be done by putting the desired nodes
into an install folder, if you don't want to replicate /etc/map
between instances.
--
Vidar S. Ramdal <vi...@idium.no> - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 21 531941, ext 2070