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...@adobe.com> on 2014/02/12 08:56:00 UTC
Installation and start order for logging (was: [jira] [Commented]
(SLING-3386) Enable support starting bundle in custom oreder at start level
1)
Hi
Lets take this to the list for a moment ..
Am 12.02.2014 um 05:40 schrieb Chetan Mehrotra (JIRA) <ji...@apache.org>:
> Chetan Mehrotra commented on SLING-3386:
> ----------------------------------------
>
> bq. treat logging specially in that we define a new "folder" which is handled first by the bootstrap installer
>
> The patch takes a bit different route but aim is same i.e. enable influencing the order in which bootstrap installer would install bundle files
To a hammer (setting installation order) everything is a nail (all bundles). I would prefer to solve the actual problem at hand with functionality we have instead of inventing a non-standard wheel which is simulates something we can barely guarantee and which at the end depends on a concrete implementation of the framework as of 2014.
>
> bq. move all non-logging bundles from startlevel 1 to startlevel 2
>
> That would be the proper and stable fix. However it would cause issue in case of upgrades as we would have to change the bundle start levels. Such a change would require lot more effort and we would need to ensure that all cases are handled properly. Thats the reason I am taking the proposed approach as it is a small change in current startup process. And yes this fix would also not handle the upgrade scenario
Lets target the proper fix and sort the start levels correctly.
As for updates: The last release of Sling was Sling 6 which just had logging in start level 1 [1]. So, there is nothing going on in upgrading from a previous Sling 6 release.
As for updating from self-cut intermediate builds: Yes, this might be a problem, but here you have an update situation where you will have zero to no control whatsoever what goes on.
Hence, I would really prefer to get our start levels straight and reserve 1 to logging and move the install stuff to 2.
Regards
Felix
[1] http://central.maven.org/maven2/org/apache/sling/org.apache.sling.launchpad/6/org.apache.sling.launchpad-6-bundlelist.xml
>
> bq. The BundleStartLevelSorter.parseStartOrder may throw an exception if the header happens to not be an Integer.
>
> I thought about that but then I preferred to have a fail fast approach where if there is a problem in value then it gets noticed right away.
>
> bq. Also every reference to start order (or even start level in that method) would have to be rephrased to install order. Also, I would call the header "X-Sling-Bootstrap-Install-Order" to indicate it is just the bootstrap installer respecting this as the installation order.
>
> Ack. Would change that.
>
>
>
>
>
>> Enable support starting bundle in custom oreder at start level 1
>> ----------------------------------------------------------------
>>
>> Key: SLING-3386
>> URL: https://issues.apache.org/jira/browse/SLING-3386
>> Project: Sling
>> Issue Type: Improvement
>> Components: Launchpad
>> Affects Versions: Launchpad Base 2.5.0
>> Reporter: Chetan Mehrotra
>> Priority: Minor
>> Attachments: SLING-3386.patch
>>
>>
>> By default OSGi framework does not define the order in which bundles would be started in a given start level. The only way is to use to use start level.
>> However in case of bundle like Logging its desriable that Log bundle is the first bundle to start in the system such that it does not miss any log message. The problem is described in more details at SLING-3340.
>> As Sling uses Felix framework by default it is possible to control the start order by controlling the order in which bundles are installed on the framework. As per current Felix Framework implementation [1] bundle within same start level are started in the order of bundleId.
>> The way patch works is
>> 1. Bundle which start at start level 1 can define a header 'X-Sling-Start-Order' to provide a start order hint. Lower the level then earlier the bundle would be started
>> 2. BootstrapInstaller would sort the files obtained from directly listing based on this header.
>> 3. Sorted list would be used to install the bundles
>> I understand that this is a very much implementation specific fix and might not work if Felix changes the internal logic. But then the feature is meant to be used in best effort basis!!.
>> [1] https://github.com/apache/felix/blob/trunk/framework/src/main/java/org/apache/felix/framework/Felix.java#L4873
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.1.5#6160)
Re: Installation and start order for logging (was: [jira] [Commented]
(SLING-3386) Enable support starting bundle in custom oreder at start level 1)
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Mon, Feb 17, 2014 at 2:55 PM, Carsten Ziegeler <cz...@apache.org> wrote:
> ...I don't think we need 2 if we have 3. If we have support in
> list.xml for different boot start levels (that's actually the hard part),
> then the implementation can just adjust the start level of available
> bundles according to the new info - this is what the installer does and
> works quiet well....
If this path is chosen I'd suggest logging any changes to bundle start
levels at the WARN level (assuming the logging is available when that
happens, or maybe store + defer logging of those actions) if that
happens, to make sure people are aware of what we are doing to their
system. Or at least have WARN that some start levels have been changed
at startup.
-Bertrand
Re: Installation and start order for logging (was: [jira] [Commented]
(SLING-3386) Enable support starting bundle in custom oreder at start level 1)
Posted by Carsten Ziegeler <cz...@apache.org>.
Thanks, I don't think we need 2 if we have 3. If we have support in
list.xml for different boot start levels (that's actually the hard part),
then the implementation can just adjust the start level of available
bundles according to the new info - this is what the installer does and
works quiet well.
Carsten
2014-02-17 13:54 GMT+01:00 Chetan Mehrotra <ch...@gmail.com>:
> Hi Carsten,
>
> To summarize.
>
> 1. Need to clear the start level 1 and keep only logging related
> bundles and framework fragments at that level. Move all other bundles
> to Start Level 2
> 2. For upgraded system we implement a new Bootstrap command say
> ChangeStartLevelCommand. This would change the start level of bundle
> from a to b. This would then be used to implement #1
> 3. For new system the list.xml needs to be updated
>
> I would be trying out #2 and come back to the list on how it works in
> practice. It might take some time given some other work in progress
>
> Chetan Mehrotra
>
>
> On Mon, Feb 17, 2014 at 5:37 PM, Carsten Ziegeler <cz...@apache.org>
> wrote:
> > Can someone please summarize what exactly is proposed, especially for
> > SLING-3388 ?
> >
> > Thanks
> > Carsten
> >
> >
> > 2014-02-12 11:14 GMT+01:00 Felix Meschberger <fm...@adobe.com>:
> >
> >>
> >> Am 12.02.2014 um 11:01 schrieb Chetan Mehrotra <
> chetan.mehrotra@gmail.com
> >> >:
> >>
> >> > For now I think we can keep the implementation simple. For example in
> >> > current case we do not have to change start level for Fragments and
> >> > Slf4j related bundle. So need to change start level of some listed
> >> > bundles only
> >> >
> >> >> startlevel 20 40
> >> > Do not see a requirement to move all existing bundle to different
> level
> >>
> >> ok
> >>
> >> >
> >> >> startlevel .* 2
> >> >> startlevel .*\.installer\..* 2
> >> >
> >> > For now would like to keep it simple to
> >> >
> >> > changestartlevel <symbolic name:version?> <target level>
> >>
> >> I still would suggest to support a version range, though.
> >>
> >> >
> >> > If need arises for more advance usecase then they can be added later
> >> >
> >> > Created SLING-3388 for the same.
> >>
> >> Thanks
> >> Felix
> >>
> >> > Chetan Mehrotra
> >> >
> >> >
> >> > On Wed, Feb 12, 2014 at 2:58 PM, Felix Meschberger <
> fmeschbe@adobe.com>
> >> wrote:
> >> >> Hi
> >> >>
> >> >> Am 12.02.2014 um 09:58 schrieb Felix Meschberger <fmeschbe@adobe.com
> >:
> >> >>
> >> >>> Hi
> >> >>>
> >> >>> Am 12.02.2014 um 09:22 schrieb Chetan Mehrotra <
> >> chetan.mehrotra@gmail.com>:
> >> >>>
> >> >>>> On Wed, Feb 12, 2014 at 1:26 PM, Felix Meschberger <
> >> fmeschbe@adobe.com> wrote:
> >> >>>>> Hence, I would really prefer to get our start levels straight and
> >> reserve 1 to logging and move the install stuff to 2.
> >> >>>>
> >> >>>> You never allow to take the short cut :)
> >> >>>
> >> >>> I fight special cases as long as possible, yes :-)
> >> >>>
> >> >>>>
> >> >>>> Okie thinking about tackling the real problem of moving existing
> >> >>>> bundle to start level > 1 I can think of following approach
> >> >>>>
> >> >>>> 1. Currently we are not using startlevel 2,3,4
> >> >>>
> >> >>> Yes.
> >> >>>
> >> >>>>
> >> >>>> 2. Introduce a new command ChangeStartLevelCommand which would use
> the
> >> >>>> StartLevel service to change the start level of non fragment bundle
> >> >>>> having existing level 1. or it can be generic to change the level
> from
> >> >>>> a -> b.
> >> >>>>
> >> >>>> One thing to decide at this step is that command should work on
> >> >>>> explicit parameters e.g. change start level only for list bundles
> >> >>>> OR Is an automatic one where it would find all bundles at 1 and
> change
> >> >>>> levels for non fragment and non logging related bundle
> >> >>>
> >> >>> You mean a command for bootstrap.txt like uninstall ? Sounds good.
> >> >>>
> >> >>> This command could take a regular expression for symbolic names and
> >> optionally a version range to select bundles and then a target start
> level.
> >> Optionally it could take a source start level and a target start level
> to
> >> move all bundles with the source start level to the target start level
> >> >>
> >> >> EBND definition:
> >> >>
> >> >> StartLevelCommand = "startlevel" Source TargetStartLevel .
> >> >> Source = SourceStartLevel
> >> >> | Bundle .
> >> >> SourceStartLevel = numeric startlevel value > 0 .
> >> >> TargetStartLevel = numeric startlevel value > 0 .
> >> >> Bundle = BundleSymbolicName VersionRange .
> >> >> BundleSymbolicName = regular expression match for bundle symbolic
> name
> >> .
> >> >> VersionRange = OSGi version range to match bundles .
> >> >>
> >> >> Examples:
> >> >>
> >> >> # move all bundles currently set to startlevel 20 to startlevel 40
> >> >> startlevel 20 40
> >> >>
> >> >> # move all bundles to startlevel 2
> >> >> startlevel .* 2
> >> >>
> >> >> # move installer bundles to startlevel 2
> >> >> startlevel .*\.installer\..* 2
> >> >>
> >> >> Regards
> >> >> Felix
> >> >>
> >> >>>
> >> >>> +1
> >> >>>
> >> >>>>
> >> >>>> 3. Change the list.xml and move non fragment bundle (except
> loggging
> >> >>>> related) to level 2
> >> >>>
> >> >>> +1
> >> >>>
> >> >>>>
> >> >>>> Would this work or is something missing here?
> >> >>>
> >> >>> Sounds good to me.
> >> >>>
> >> >>> Regards
> >> >>> Felix
> >> >>>
> >> >>>>
> >> >>>> Chetan Mehrotra
> >> >>>
> >> >>
> >>
> >>
> >
> >
> > --
> > Carsten Ziegeler
> > cziegeler@apache.org
>
--
Carsten Ziegeler
cziegeler@apache.org
Re: Installation and start order for logging (was: [jira] [Commented]
(SLING-3386) Enable support starting bundle in custom oreder at start level 1)
Posted by Chetan Mehrotra <ch...@gmail.com>.
Hi Carsten,
To summarize.
1. Need to clear the start level 1 and keep only logging related
bundles and framework fragments at that level. Move all other bundles
to Start Level 2
2. For upgraded system we implement a new Bootstrap command say
ChangeStartLevelCommand. This would change the start level of bundle
from a to b. This would then be used to implement #1
3. For new system the list.xml needs to be updated
I would be trying out #2 and come back to the list on how it works in
practice. It might take some time given some other work in progress
Chetan Mehrotra
On Mon, Feb 17, 2014 at 5:37 PM, Carsten Ziegeler <cz...@apache.org> wrote:
> Can someone please summarize what exactly is proposed, especially for
> SLING-3388 ?
>
> Thanks
> Carsten
>
>
> 2014-02-12 11:14 GMT+01:00 Felix Meschberger <fm...@adobe.com>:
>
>>
>> Am 12.02.2014 um 11:01 schrieb Chetan Mehrotra <chetan.mehrotra@gmail.com
>> >:
>>
>> > For now I think we can keep the implementation simple. For example in
>> > current case we do not have to change start level for Fragments and
>> > Slf4j related bundle. So need to change start level of some listed
>> > bundles only
>> >
>> >> startlevel 20 40
>> > Do not see a requirement to move all existing bundle to different level
>>
>> ok
>>
>> >
>> >> startlevel .* 2
>> >> startlevel .*\.installer\..* 2
>> >
>> > For now would like to keep it simple to
>> >
>> > changestartlevel <symbolic name:version?> <target level>
>>
>> I still would suggest to support a version range, though.
>>
>> >
>> > If need arises for more advance usecase then they can be added later
>> >
>> > Created SLING-3388 for the same.
>>
>> Thanks
>> Felix
>>
>> > Chetan Mehrotra
>> >
>> >
>> > On Wed, Feb 12, 2014 at 2:58 PM, Felix Meschberger <fm...@adobe.com>
>> wrote:
>> >> Hi
>> >>
>> >> Am 12.02.2014 um 09:58 schrieb Felix Meschberger <fm...@adobe.com>:
>> >>
>> >>> Hi
>> >>>
>> >>> Am 12.02.2014 um 09:22 schrieb Chetan Mehrotra <
>> chetan.mehrotra@gmail.com>:
>> >>>
>> >>>> On Wed, Feb 12, 2014 at 1:26 PM, Felix Meschberger <
>> fmeschbe@adobe.com> wrote:
>> >>>>> Hence, I would really prefer to get our start levels straight and
>> reserve 1 to logging and move the install stuff to 2.
>> >>>>
>> >>>> You never allow to take the short cut :)
>> >>>
>> >>> I fight special cases as long as possible, yes :-)
>> >>>
>> >>>>
>> >>>> Okie thinking about tackling the real problem of moving existing
>> >>>> bundle to start level > 1 I can think of following approach
>> >>>>
>> >>>> 1. Currently we are not using startlevel 2,3,4
>> >>>
>> >>> Yes.
>> >>>
>> >>>>
>> >>>> 2. Introduce a new command ChangeStartLevelCommand which would use the
>> >>>> StartLevel service to change the start level of non fragment bundle
>> >>>> having existing level 1. or it can be generic to change the level from
>> >>>> a -> b.
>> >>>>
>> >>>> One thing to decide at this step is that command should work on
>> >>>> explicit parameters e.g. change start level only for list bundles
>> >>>> OR Is an automatic one where it would find all bundles at 1 and change
>> >>>> levels for non fragment and non logging related bundle
>> >>>
>> >>> You mean a command for bootstrap.txt like uninstall ? Sounds good.
>> >>>
>> >>> This command could take a regular expression for symbolic names and
>> optionally a version range to select bundles and then a target start level.
>> Optionally it could take a source start level and a target start level to
>> move all bundles with the source start level to the target start level
>> >>
>> >> EBND definition:
>> >>
>> >> StartLevelCommand = "startlevel" Source TargetStartLevel .
>> >> Source = SourceStartLevel
>> >> | Bundle .
>> >> SourceStartLevel = numeric startlevel value > 0 .
>> >> TargetStartLevel = numeric startlevel value > 0 .
>> >> Bundle = BundleSymbolicName VersionRange .
>> >> BundleSymbolicName = regular expression match for bundle symbolic name
>> .
>> >> VersionRange = OSGi version range to match bundles .
>> >>
>> >> Examples:
>> >>
>> >> # move all bundles currently set to startlevel 20 to startlevel 40
>> >> startlevel 20 40
>> >>
>> >> # move all bundles to startlevel 2
>> >> startlevel .* 2
>> >>
>> >> # move installer bundles to startlevel 2
>> >> startlevel .*\.installer\..* 2
>> >>
>> >> Regards
>> >> Felix
>> >>
>> >>>
>> >>> +1
>> >>>
>> >>>>
>> >>>> 3. Change the list.xml and move non fragment bundle (except loggging
>> >>>> related) to level 2
>> >>>
>> >>> +1
>> >>>
>> >>>>
>> >>>> Would this work or is something missing here?
>> >>>
>> >>> Sounds good to me.
>> >>>
>> >>> Regards
>> >>> Felix
>> >>>
>> >>>>
>> >>>> Chetan Mehrotra
>> >>>
>> >>
>>
>>
>
>
> --
> Carsten Ziegeler
> cziegeler@apache.org
Re: Installation and start order for logging (was: [jira] [Commented]
(SLING-3386) Enable support starting bundle in custom oreder at start level 1)
Posted by Carsten Ziegeler <cz...@apache.org>.
Can someone please summarize what exactly is proposed, especially for
SLING-3388 ?
Thanks
Carsten
2014-02-12 11:14 GMT+01:00 Felix Meschberger <fm...@adobe.com>:
>
> Am 12.02.2014 um 11:01 schrieb Chetan Mehrotra <chetan.mehrotra@gmail.com
> >:
>
> > For now I think we can keep the implementation simple. For example in
> > current case we do not have to change start level for Fragments and
> > Slf4j related bundle. So need to change start level of some listed
> > bundles only
> >
> >> startlevel 20 40
> > Do not see a requirement to move all existing bundle to different level
>
> ok
>
> >
> >> startlevel .* 2
> >> startlevel .*\.installer\..* 2
> >
> > For now would like to keep it simple to
> >
> > changestartlevel <symbolic name:version?> <target level>
>
> I still would suggest to support a version range, though.
>
> >
> > If need arises for more advance usecase then they can be added later
> >
> > Created SLING-3388 for the same.
>
> Thanks
> Felix
>
> > Chetan Mehrotra
> >
> >
> > On Wed, Feb 12, 2014 at 2:58 PM, Felix Meschberger <fm...@adobe.com>
> wrote:
> >> Hi
> >>
> >> Am 12.02.2014 um 09:58 schrieb Felix Meschberger <fm...@adobe.com>:
> >>
> >>> Hi
> >>>
> >>> Am 12.02.2014 um 09:22 schrieb Chetan Mehrotra <
> chetan.mehrotra@gmail.com>:
> >>>
> >>>> On Wed, Feb 12, 2014 at 1:26 PM, Felix Meschberger <
> fmeschbe@adobe.com> wrote:
> >>>>> Hence, I would really prefer to get our start levels straight and
> reserve 1 to logging and move the install stuff to 2.
> >>>>
> >>>> You never allow to take the short cut :)
> >>>
> >>> I fight special cases as long as possible, yes :-)
> >>>
> >>>>
> >>>> Okie thinking about tackling the real problem of moving existing
> >>>> bundle to start level > 1 I can think of following approach
> >>>>
> >>>> 1. Currently we are not using startlevel 2,3,4
> >>>
> >>> Yes.
> >>>
> >>>>
> >>>> 2. Introduce a new command ChangeStartLevelCommand which would use the
> >>>> StartLevel service to change the start level of non fragment bundle
> >>>> having existing level 1. or it can be generic to change the level from
> >>>> a -> b.
> >>>>
> >>>> One thing to decide at this step is that command should work on
> >>>> explicit parameters e.g. change start level only for list bundles
> >>>> OR Is an automatic one where it would find all bundles at 1 and change
> >>>> levels for non fragment and non logging related bundle
> >>>
> >>> You mean a command for bootstrap.txt like uninstall ? Sounds good.
> >>>
> >>> This command could take a regular expression for symbolic names and
> optionally a version range to select bundles and then a target start level.
> Optionally it could take a source start level and a target start level to
> move all bundles with the source start level to the target start level
> >>
> >> EBND definition:
> >>
> >> StartLevelCommand = "startlevel" Source TargetStartLevel .
> >> Source = SourceStartLevel
> >> | Bundle .
> >> SourceStartLevel = numeric startlevel value > 0 .
> >> TargetStartLevel = numeric startlevel value > 0 .
> >> Bundle = BundleSymbolicName VersionRange .
> >> BundleSymbolicName = regular expression match for bundle symbolic name
> .
> >> VersionRange = OSGi version range to match bundles .
> >>
> >> Examples:
> >>
> >> # move all bundles currently set to startlevel 20 to startlevel 40
> >> startlevel 20 40
> >>
> >> # move all bundles to startlevel 2
> >> startlevel .* 2
> >>
> >> # move installer bundles to startlevel 2
> >> startlevel .*\.installer\..* 2
> >>
> >> Regards
> >> Felix
> >>
> >>>
> >>> +1
> >>>
> >>>>
> >>>> 3. Change the list.xml and move non fragment bundle (except loggging
> >>>> related) to level 2
> >>>
> >>> +1
> >>>
> >>>>
> >>>> Would this work or is something missing here?
> >>>
> >>> Sounds good to me.
> >>>
> >>> Regards
> >>> Felix
> >>>
> >>>>
> >>>> Chetan Mehrotra
> >>>
> >>
>
>
--
Carsten Ziegeler
cziegeler@apache.org
Re: Installation and start order for logging (was: [jira]
[Commented] (SLING-3386) Enable support starting bundle in custom oreder at
start level 1)
Posted by Felix Meschberger <fm...@adobe.com>.
Am 12.02.2014 um 11:01 schrieb Chetan Mehrotra <ch...@gmail.com>:
> For now I think we can keep the implementation simple. For example in
> current case we do not have to change start level for Fragments and
> Slf4j related bundle. So need to change start level of some listed
> bundles only
>
>> startlevel 20 40
> Do not see a requirement to move all existing bundle to different level
ok
>
>> startlevel .* 2
>> startlevel .*\.installer\..* 2
>
> For now would like to keep it simple to
>
> changestartlevel <symbolic name:version?> <target level>
I still would suggest to support a version range, though.
>
> If need arises for more advance usecase then they can be added later
>
> Created SLING-3388 for the same.
Thanks
Felix
> Chetan Mehrotra
>
>
> On Wed, Feb 12, 2014 at 2:58 PM, Felix Meschberger <fm...@adobe.com> wrote:
>> Hi
>>
>> Am 12.02.2014 um 09:58 schrieb Felix Meschberger <fm...@adobe.com>:
>>
>>> Hi
>>>
>>> Am 12.02.2014 um 09:22 schrieb Chetan Mehrotra <ch...@gmail.com>:
>>>
>>>> On Wed, Feb 12, 2014 at 1:26 PM, Felix Meschberger <fm...@adobe.com> wrote:
>>>>> Hence, I would really prefer to get our start levels straight and reserve 1 to logging and move the install stuff to 2.
>>>>
>>>> You never allow to take the short cut :)
>>>
>>> I fight special cases as long as possible, yes :-)
>>>
>>>>
>>>> Okie thinking about tackling the real problem of moving existing
>>>> bundle to start level > 1 I can think of following approach
>>>>
>>>> 1. Currently we are not using startlevel 2,3,4
>>>
>>> Yes.
>>>
>>>>
>>>> 2. Introduce a new command ChangeStartLevelCommand which would use the
>>>> StartLevel service to change the start level of non fragment bundle
>>>> having existing level 1. or it can be generic to change the level from
>>>> a -> b.
>>>>
>>>> One thing to decide at this step is that command should work on
>>>> explicit parameters e.g. change start level only for list bundles
>>>> OR Is an automatic one where it would find all bundles at 1 and change
>>>> levels for non fragment and non logging related bundle
>>>
>>> You mean a command for bootstrap.txt like uninstall ? Sounds good.
>>>
>>> This command could take a regular expression for symbolic names and optionally a version range to select bundles and then a target start level. Optionally it could take a source start level and a target start level to move all bundles with the source start level to the target start level
>>
>> EBND definition:
>>
>> StartLevelCommand = "startlevel" Source TargetStartLevel .
>> Source = SourceStartLevel
>> | Bundle .
>> SourceStartLevel = numeric startlevel value > 0 .
>> TargetStartLevel = numeric startlevel value > 0 .
>> Bundle = BundleSymbolicName VersionRange .
>> BundleSymbolicName = regular expression match for bundle symbolic name .
>> VersionRange = OSGi version range to match bundles .
>>
>> Examples:
>>
>> # move all bundles currently set to startlevel 20 to startlevel 40
>> startlevel 20 40
>>
>> # move all bundles to startlevel 2
>> startlevel .* 2
>>
>> # move installer bundles to startlevel 2
>> startlevel .*\.installer\..* 2
>>
>> Regards
>> Felix
>>
>>>
>>> +1
>>>
>>>>
>>>> 3. Change the list.xml and move non fragment bundle (except loggging
>>>> related) to level 2
>>>
>>> +1
>>>
>>>>
>>>> Would this work or is something missing here?
>>>
>>> Sounds good to me.
>>>
>>> Regards
>>> Felix
>>>
>>>>
>>>> Chetan Mehrotra
>>>
>>
Re: Installation and start order for logging (was: [jira] [Commented]
(SLING-3386) Enable support starting bundle in custom oreder at start level 1)
Posted by Chetan Mehrotra <ch...@gmail.com>.
For now I think we can keep the implementation simple. For example in
current case we do not have to change start level for Fragments and
Slf4j related bundle. So need to change start level of some listed
bundles only
> startlevel 20 40
Do not see a requirement to move all existing bundle to different level
> startlevel .* 2
> startlevel .*\.installer\..* 2
For now would like to keep it simple to
changestartlevel <symbolic name:version?> <target level>
If need arises for more advance usecase then they can be added later
Created SLING-3388 for the same.
Chetan Mehrotra
On Wed, Feb 12, 2014 at 2:58 PM, Felix Meschberger <fm...@adobe.com> wrote:
> Hi
>
> Am 12.02.2014 um 09:58 schrieb Felix Meschberger <fm...@adobe.com>:
>
>> Hi
>>
>> Am 12.02.2014 um 09:22 schrieb Chetan Mehrotra <ch...@gmail.com>:
>>
>>> On Wed, Feb 12, 2014 at 1:26 PM, Felix Meschberger <fm...@adobe.com> wrote:
>>>> Hence, I would really prefer to get our start levels straight and reserve 1 to logging and move the install stuff to 2.
>>>
>>> You never allow to take the short cut :)
>>
>> I fight special cases as long as possible, yes :-)
>>
>>>
>>> Okie thinking about tackling the real problem of moving existing
>>> bundle to start level > 1 I can think of following approach
>>>
>>> 1. Currently we are not using startlevel 2,3,4
>>
>> Yes.
>>
>>>
>>> 2. Introduce a new command ChangeStartLevelCommand which would use the
>>> StartLevel service to change the start level of non fragment bundle
>>> having existing level 1. or it can be generic to change the level from
>>> a -> b.
>>>
>>> One thing to decide at this step is that command should work on
>>> explicit parameters e.g. change start level only for list bundles
>>> OR Is an automatic one where it would find all bundles at 1 and change
>>> levels for non fragment and non logging related bundle
>>
>> You mean a command for bootstrap.txt like uninstall ? Sounds good.
>>
>> This command could take a regular expression for symbolic names and optionally a version range to select bundles and then a target start level. Optionally it could take a source start level and a target start level to move all bundles with the source start level to the target start level
>
> EBND definition:
>
> StartLevelCommand = "startlevel" Source TargetStartLevel .
> Source = SourceStartLevel
> | Bundle .
> SourceStartLevel = numeric startlevel value > 0 .
> TargetStartLevel = numeric startlevel value > 0 .
> Bundle = BundleSymbolicName VersionRange .
> BundleSymbolicName = regular expression match for bundle symbolic name .
> VersionRange = OSGi version range to match bundles .
>
> Examples:
>
> # move all bundles currently set to startlevel 20 to startlevel 40
> startlevel 20 40
>
> # move all bundles to startlevel 2
> startlevel .* 2
>
> # move installer bundles to startlevel 2
> startlevel .*\.installer\..* 2
>
> Regards
> Felix
>
>>
>> +1
>>
>>>
>>> 3. Change the list.xml and move non fragment bundle (except loggging
>>> related) to level 2
>>
>> +1
>>
>>>
>>> Would this work or is something missing here?
>>
>> Sounds good to me.
>>
>> Regards
>> Felix
>>
>>>
>>> Chetan Mehrotra
>>
>
Re: Installation and start order for logging (was: [jira]
[Commented] (SLING-3386) Enable support starting bundle in custom oreder at
start level 1)
Posted by Felix Meschberger <fm...@adobe.com>.
Hi
Am 12.02.2014 um 09:58 schrieb Felix Meschberger <fm...@adobe.com>:
> Hi
>
> Am 12.02.2014 um 09:22 schrieb Chetan Mehrotra <ch...@gmail.com>:
>
>> On Wed, Feb 12, 2014 at 1:26 PM, Felix Meschberger <fm...@adobe.com> wrote:
>>> Hence, I would really prefer to get our start levels straight and reserve 1 to logging and move the install stuff to 2.
>>
>> You never allow to take the short cut :)
>
> I fight special cases as long as possible, yes :-)
>
>>
>> Okie thinking about tackling the real problem of moving existing
>> bundle to start level > 1 I can think of following approach
>>
>> 1. Currently we are not using startlevel 2,3,4
>
> Yes.
>
>>
>> 2. Introduce a new command ChangeStartLevelCommand which would use the
>> StartLevel service to change the start level of non fragment bundle
>> having existing level 1. or it can be generic to change the level from
>> a -> b.
>>
>> One thing to decide at this step is that command should work on
>> explicit parameters e.g. change start level only for list bundles
>> OR Is an automatic one where it would find all bundles at 1 and change
>> levels for non fragment and non logging related bundle
>
> You mean a command for bootstrap.txt like uninstall ? Sounds good.
>
> This command could take a regular expression for symbolic names and optionally a version range to select bundles and then a target start level. Optionally it could take a source start level and a target start level to move all bundles with the source start level to the target start level
EBND definition:
StartLevelCommand = "startlevel" Source TargetStartLevel .
Source = SourceStartLevel
| Bundle .
SourceStartLevel = numeric startlevel value > 0 .
TargetStartLevel = numeric startlevel value > 0 .
Bundle = BundleSymbolicName VersionRange .
BundleSymbolicName = regular expression match for bundle symbolic name .
VersionRange = OSGi version range to match bundles .
Examples:
# move all bundles currently set to startlevel 20 to startlevel 40
startlevel 20 40
# move all bundles to startlevel 2
startlevel .* 2
# move installer bundles to startlevel 2
startlevel .*\.installer\..* 2
Regards
Felix
>
> +1
>
>>
>> 3. Change the list.xml and move non fragment bundle (except loggging
>> related) to level 2
>
> +1
>
>>
>> Would this work or is something missing here?
>
> Sounds good to me.
>
> Regards
> Felix
>
>>
>> Chetan Mehrotra
>
Re: Installation and start order for logging (was: [jira]
[Commented] (SLING-3386) Enable support starting bundle in custom oreder at
start level 1)
Posted by Felix Meschberger <fm...@adobe.com>.
Hi
Am 12.02.2014 um 09:22 schrieb Chetan Mehrotra <ch...@gmail.com>:
> On Wed, Feb 12, 2014 at 1:26 PM, Felix Meschberger <fm...@adobe.com> wrote:
>> Hence, I would really prefer to get our start levels straight and reserve 1 to logging and move the install stuff to 2.
>
> You never allow to take the short cut :)
I fight special cases as long as possible, yes :-)
>
> Okie thinking about tackling the real problem of moving existing
> bundle to start level > 1 I can think of following approach
>
> 1. Currently we are not using startlevel 2,3,4
Yes.
>
> 2. Introduce a new command ChangeStartLevelCommand which would use the
> StartLevel service to change the start level of non fragment bundle
> having existing level 1. or it can be generic to change the level from
> a -> b.
>
> One thing to decide at this step is that command should work on
> explicit parameters e.g. change start level only for list bundles
> OR Is an automatic one where it would find all bundles at 1 and change
> levels for non fragment and non logging related bundle
You mean a command for bootstrap.txt like uninstall ? Sounds good.
This command could take a regular expression for symbolic names and optionally a version range to select bundles and then a target start level. Optionally it could take a source start level and a target start level to move all bundles with the source start level to the target start level
+1
>
> 3. Change the list.xml and move non fragment bundle (except loggging
> related) to level 2
+1
>
> Would this work or is something missing here?
Sounds good to me.
Regards
Felix
>
> Chetan Mehrotra
Re: Installation and start order for logging (was: [jira] [Commented]
(SLING-3386) Enable support starting bundle in custom oreder at start level 1)
Posted by Chetan Mehrotra <ch...@gmail.com>.
On Wed, Feb 12, 2014 at 1:26 PM, Felix Meschberger <fm...@adobe.com> wrote:
> Hence, I would really prefer to get our start levels straight and reserve 1 to logging and move the install stuff to 2.
You never allow to take the short cut :)
Okie thinking about tackling the real problem of moving existing
bundle to start level > 1 I can think of following approach
1. Currently we are not using startlevel 2,3,4
2. Introduce a new command ChangeStartLevelCommand which would use the
StartLevel service to change the start level of non fragment bundle
having existing level 1. or it can be generic to change the level from
a -> b.
One thing to decide at this step is that command should work on
explicit parameters e.g. change start level only for list bundles
OR Is an automatic one where it would find all bundles at 1 and change
levels for non fragment and non logging related bundle
3. Change the list.xml and move non fragment bundle (except loggging
related) to level 2
Would this work or is something missing here?
Chetan Mehrotra