Re: OSGi configuration lookup
Hi all, I would like to complete a patch for OAK-3022, but my work depends on the patch I submitted for OAK-3048. Can somebody review OAK-3048? Thanks, Francesco 2015-06-30 9:45 GMT+02:00 Bertrand Delacretaz bdelacre...@apache.org: On Tue, Jun 30, 2015 at 5:52 AM, Chetan Mehrotra chetan.mehro...@gmail.com wrote: ...if we need to do that for Segment also then we should use a similar namespacing... And that should IMO be done with a utility class instead of duplicating code. -Bertrand
Re: OSGi configuration lookup
On Tue, Jun 30, 2015 at 5:52 AM, Chetan Mehrotra chetan.mehro...@gmail.com wrote: ...if we need to do that for Segment also then we should use a similar namespacing... And that should IMO be done with a utility class instead of duplicating code. -Bertrand
Re: OSGi configuration lookup
I attached a patch in OAK-3048. Can someone review? 2015-06-30 9:02 GMT+02:00 Francesco Mari mari.france...@gmail.com: I created OAK-3048 to track the implementation of the framework-first-component-next strategy. I will attach a patch to this issue shortly. I also opened OAK-3049 as a reminder to address the uniformity issue when reading configuration. 2015-06-30 8:35 GMT+02:00 Chetan Mehrotra chetan.mehro...@gmail.com: On Tue, Jun 30, 2015 at 12:00 PM, Francesco Mari mari.france...@gmail.com wrote: I suggest to fix OAK-3022 maintaining exactly the same behaviour, and without changing the SegmentNodeStoreService Makes sense. They are two different issue Chetan Mehrotra
Re: OSGi configuration lookup
To keep things simple, I suggest to fix OAK-3022 maintaining exactly the same behaviour, and without changing the SegmentNodeStoreService. What do you think if we address the issue about different behaviours separately? 2015-06-30 5:52 GMT+02:00 Chetan Mehrotra chetan.mehro...@gmail.com: That can be done but some more details! When properties are read from framework properties then property names are prefixed with 'oak.documentstore.' kind of like namespaced as framework properties are flat and global. So if we need to do that for Segment also then we should use a similar namespaceing. For e.g. if the property name is 'cache' then when reading from fwk then 'oak.documentstore.cache' would be used oak.mongo.uri and oak.mongo.db are spacial cased though and not follow this rule. Chetan Mehrotra On Tue, Jun 30, 2015 at 2:55 AM, Francesco Mari mari.france...@gmail.com wrote: So we should probably adopt this strategy instead. This means that SegmentNodeStoreService is the one that should be modified. 2015-06-29 17:15 GMT+02:00 Chetan Mehrotra chetan.mehro...@gmail.com: Looking at code flow now yes it differs. The thought behind reading from framework property first was to provide a simple way to override the config which might be packaged by default. For e.g. while launching Oak via Sling one can provide the framework property at command line (using -Doak.mongo.uri) which would supercede the one packaged by default. This simplifies the testing. Chetan Mehrotra On Mon, Jun 29, 2015 at 7:01 PM, Davide Giannella dav...@apache.org wrote: On 29/06/2015 10:22, Francesco Mari wrote: ... Is it possible - or does it make sense - to make this behaviour uniform across components? I think it's a good idea to uniform this aspect. Maybe we could put it down as a guideline by setting up a new page on the doc site: code-conventions.md. Somewhere beside: http://jackrabbit.apache.org/oak/docs/dev_getting_started.html Personally I'd go for component first and bundle then, but I'm not too religious about it :) Anyone against it? Davide
Re: OSGi configuration lookup
On Tue, Jun 30, 2015 at 12:00 PM, Francesco Mari mari.france...@gmail.com wrote: I suggest to fix OAK-3022 maintaining exactly the same behaviour, and without changing the SegmentNodeStoreService Makes sense. They are two different issue Chetan Mehrotra
Re: OSGi configuration lookup
On 29/06/2015 10:22, Francesco Mari wrote: ... Is it possible - or does it make sense - to make this behaviour uniform across components? I think it's a good idea to uniform this aspect. Maybe we could put it down as a guideline by setting up a new page on the doc site: code-conventions.md. Somewhere beside: http://jackrabbit.apache.org/oak/docs/dev_getting_started.html Personally I'd go for component first and bundle then, but I'm not too religious about it :) Anyone against it? Davide
OSGi configuration lookup
Hi all, I'm developing a fix for OAK-3022 reusing the code written for OAK-2962. I figured out that there is a mismatch in how SegmentNodeStoreService and DocumentNodeStoreService read configuration values. The SegmentNodeStoreService reads from the component context first, and from the bundle context next. The DocumentNodeStoreService, instead, does the opposite. Is it possible - or does it make sense - to make this behaviour uniform across components? Thanks, Francesco
Re: OSGi configuration lookup
Looking at code flow now yes it differs. The thought behind reading from framework property first was to provide a simple way to override the config which might be packaged by default. For e.g. while launching Oak via Sling one can provide the framework property at command line (using -Doak.mongo.uri) which would supercede the one packaged by default. This simplifies the testing. Chetan Mehrotra On Mon, Jun 29, 2015 at 7:01 PM, Davide Giannella dav...@apache.org wrote: On 29/06/2015 10:22, Francesco Mari wrote: ... Is it possible - or does it make sense - to make this behaviour uniform across components? I think it's a good idea to uniform this aspect. Maybe we could put it down as a guideline by setting up a new page on the doc site: code-conventions.md. Somewhere beside: http://jackrabbit.apache.org/oak/docs/dev_getting_started.html Personally I'd go for component first and bundle then, but I'm not too religious about it :) Anyone against it? Davide
Re: OSGi configuration lookup
So we should probably adopt this strategy instead. This means that SegmentNodeStoreService is the one that should be modified. 2015-06-29 17:15 GMT+02:00 Chetan Mehrotra chetan.mehro...@gmail.com: Looking at code flow now yes it differs. The thought behind reading from framework property first was to provide a simple way to override the config which might be packaged by default. For e.g. while launching Oak via Sling one can provide the framework property at command line (using -Doak.mongo.uri) which would supercede the one packaged by default. This simplifies the testing. Chetan Mehrotra On Mon, Jun 29, 2015 at 7:01 PM, Davide Giannella dav...@apache.org wrote: On 29/06/2015 10:22, Francesco Mari wrote: ... Is it possible - or does it make sense - to make this behaviour uniform across components? I think it's a good idea to uniform this aspect. Maybe we could put it down as a guideline by setting up a new page on the doc site: code-conventions.md. Somewhere beside: http://jackrabbit.apache.org/oak/docs/dev_getting_started.html Personally I'd go for component first and bundle then, but I'm not too religious about it :) Anyone against it? Davide
Re: OSGi configuration lookup
That can be done but some more details! When properties are read from framework properties then property names are prefixed with 'oak.documentstore.' kind of like namespaced as framework properties are flat and global. So if we need to do that for Segment also then we should use a similar namespaceing. For e.g. if the property name is 'cache' then when reading from fwk then 'oak.documentstore.cache' would be used oak.mongo.uri and oak.mongo.db are spacial cased though and not follow this rule. Chetan Mehrotra On Tue, Jun 30, 2015 at 2:55 AM, Francesco Mari mari.france...@gmail.com wrote: So we should probably adopt this strategy instead. This means that SegmentNodeStoreService is the one that should be modified. 2015-06-29 17:15 GMT+02:00 Chetan Mehrotra chetan.mehro...@gmail.com: Looking at code flow now yes it differs. The thought behind reading from framework property first was to provide a simple way to override the config which might be packaged by default. For e.g. while launching Oak via Sling one can provide the framework property at command line (using -Doak.mongo.uri) which would supercede the one packaged by default. This simplifies the testing. Chetan Mehrotra On Mon, Jun 29, 2015 at 7:01 PM, Davide Giannella dav...@apache.org wrote: On 29/06/2015 10:22, Francesco Mari wrote: ... Is it possible - or does it make sense - to make this behaviour uniform across components? I think it's a good idea to uniform this aspect. Maybe we could put it down as a guideline by setting up a new page on the doc site: code-conventions.md. Somewhere beside: http://jackrabbit.apache.org/oak/docs/dev_getting_started.html Personally I'd go for component first and bundle then, but I'm not too religious about it :) Anyone against it? Davide
