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
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
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
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
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
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.
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
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
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
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
10 matches
Mail list logo
