You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@karaf.apache.org by Gert Vanthienen <ge...@gmail.com> on 2013/10/25 15:39:25 UTC
Which config.properties and startup.properties with admin:create ?
L.S.,
The current implementation of the admin:create command uses copies
from the Karaf assembly of the config.properties and
startup.properties files when creating the instance.
If you're running a plain Karaf container, that's pretty much OK but
if you have something else built on top of Karaf (e.g. ServiceMix), it
would make a lot more sense to get those properties files out of your
current root instance instead. Unlike the settings files for
features, logging, ..., these files are used to bootstrap the
container, so by the time the child container has started, it's too
late to update them.
One example: in ServiceMix 5, we are using the startup.properties file
to ensure we have Features OBR support installed and that our Camel
instrumentation hook is being started as soon as possible to ensure
all our routes get instrumented. If you do an admin:create in
ServiceMix 5, you will have to manually go and edit the
startup.properties file before starting the child container to get the
same behavior.
The same probably goes for the config.properties. If I want to build
a product/project on top of Karaf that uses Equinox instead of Felix
by default, the admin:create command would still create a plain Karaf
container running Felix.
In my mind, it would make more sense for the admin:create command to
create a child instance with the same bootstrap settings as the root,
so if that's OK for everyone, I'll raise a JIRA and fix this.
Regards,
Gert Vanthienen
Re: Which config.properties and startup.properties with admin:create
?
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Yes, as Achim said we created the admin:clone command to duplicate a
complete root installation.
You can clone the root instance and inherit the files.
The only "issue" is that admin:clone manages the Karaf ports, not the
custom/additional one.
Regards
JB
On 10/25/2013 03:39 PM, Gert Vanthienen wrote:
> L.S.,
>
>
> The current implementation of the admin:create command uses copies
> from the Karaf assembly of the config.properties and
> startup.properties files when creating the instance.
>
> If you're running a plain Karaf container, that's pretty much OK but
> if you have something else built on top of Karaf (e.g. ServiceMix), it
> would make a lot more sense to get those properties files out of your
> current root instance instead. Unlike the settings files for
> features, logging, ..., these files are used to bootstrap the
> container, so by the time the child container has started, it's too
> late to update them.
>
> One example: in ServiceMix 5, we are using the startup.properties file
> to ensure we have Features OBR support installed and that our Camel
> instrumentation hook is being started as soon as possible to ensure
> all our routes get instrumented. If you do an admin:create in
> ServiceMix 5, you will have to manually go and edit the
> startup.properties file before starting the child container to get the
> same behavior.
>
> The same probably goes for the config.properties. If I want to build
> a product/project on top of Karaf that uses Equinox instead of Felix
> by default, the admin:create command would still create a plain Karaf
> container running Felix.
>
> In my mind, it would make more sense for the admin:create command to
> create a child instance with the same bootstrap settings as the root,
> so if that's OK for everyone, I'll raise a JIRA and fix this.
>
>
> Regards,
>
> Gert Vanthienen
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Which config.properties and startup.properties with admin:create ?
Posted by Ehsan Zaery Moghaddam <za...@gmail.com>.
Hi
I'm agree with branding too. It's more meaningful to have such options
there.
Regards
Ehsan
On Fri, Nov 1, 2013 at 1:58 PM, Achim Nierbeck <bc...@googlemail.com>wrote:
> Hi guys,
>
> Branding sounds like a good idea.
> I think it would solve all the issues we have with custom and std. Karaf.
>
> regards, Achim
>
> sent from mobile device
> Am 01.11.2013 08:10 schrieb "Jean-Baptiste Onofré" <jb...@nanthrax.net>:
>
> > Agree Gert.
> >
> > Why not using a kind of "branding" bundle that admin:create can use (it's
> > a step forward to the profile):
> > - if the custom distribution (ServiceMix) doesn't provide a "branding"
> > bundle, admin:create creates a fresh Karaf instance (as it does now)
> > - if the custom distribution provides a "branding" bundle, admin:create
> > can look for this "branding" bundle and use it to create the "fresh
> custom"
> > instance
> >
> > WDYT ?
> >
> > Regards
> > JB
> >
> > On 10/31/2013 11:08 PM, Gert Vanthienen wrote:
> >
> >> L.S.,
> >>
> >>
> >> In the case of ServiceMix, I would like the admin:create to create a
> >> fresh, empty ServiceMix instance instead of a fresh, empty Karaf
> >> instance. Adding an option to the command does not really fix the
> >> issue in my mind, as the user still has to be aware of the fact that
> >> ServiceMix has a modified startup.properties file to know he/she has
> >> to add the option.
> >>
> >> Personally, I would prefer to keep things as simple as possible until
> >> we work out the profiles solution and just add a flag to indicate that
> >> we want the startup/config properties file from the actual root
> >> container instead of the ones from Karaf (something like
> >> inheritStartupProperties=true and inheritConfigProperties=true). For
> >> Karaf, we can just leave out the config file and default to false to
> >> keep things as before.
> >>
> >> I agree this will break current behavior for users of ServiceMix that
> >> have been modifying their own startup/config.properties files, but
> >> those are pretty knowledgeable users anyway so we could just add that
> >> to the release notes or something. The current behavior of
> >> admin:create just doesn't work at all for anyone in the case of
> >> ServiceMix (or any other project out there that requires modifications
> >> to either of those two files) - they end up with a container they have
> >> to manually go and edit before they can start it.
> >>
> >>
> >> Regards,
> >>
> >> Gert Vanthienen
> >>
> >>
> >> On Thu, Oct 31, 2013 at 9:55 PM, Jean-Baptiste Onofré <jb...@nanthrax.net>
> >> wrote:
> >>
> >>> Gert,
> >>>
> >>> the only thing is that admin:create won't create a "fresh empty" Karaf
> >>> instance: if the user changed the startup.properties, admin:create will
> >>> create an instance already with these changes included. Currently,
> >>> admin:create creates a complete fresh instance, ignoring the changes
> from
> >>> the user in the root instance.
> >>>
> >>> Regards
> >>> JB
> >>>
> >>>
> >>> On 10/31/2013 09:20 PM, Gert Vanthienen wrote:
> >>>
> >>>>
> >>>> Jean-Baptiste, Ehsan,
> >>>>
> >>>>
> >>>> How about making that configurable instead of using the -c parameter?
> >>>> We could still leave the default to pick the original, embedded Karaf
> >>>> config/startup.properties, so for Karaf nothing would change.
> >>>>
> >>>> But at least that way, projects like ServiceMix could just have the
> >>>> admin:create command do the right thing for that particular project by
> >>>> simply adding the org.apache.karaf.admin.core.**cfg file to their etc
> >>>> directory, without the user having to be aware of the little bit of
> >>>> extra tweaking required to properly bootstrap the container?
> >>>>
> >>>>
> >>>> Regards,
> >>>>
> >>>> Gert
> >>>>
> >>>>
> >>>> On Thu, Oct 31, 2013 at 7:41 PM, Jean-Baptiste Onofré <
> jb@nanthrax.net>
> >>>> wrote:
> >>>>
> >>>>>
> >>>>> Good idea. I will do that.
> >>>>> The thing
> >>>>>
> >>>>> Regards
> >>>>> JB
> >>>>>
> >>>>>
> >>>>> On 10/31/2013 01:28 PM, zaerymoghaddam wrote:
> >>>>>
> >>>>>>
> >>>>>>
> >>>>>> Hi guys
> >>>>>>
> >>>>>> Isn't it possible having an option on admin:create to decide whether
> >>>>>> to
> >>>>>> create a new plain instance or use root instance configurations?
> >>>>>>
> >>>>>> For example: 'admin:create -c'.
> >>>>>> which '-c' could mean clone root instance's configuration.
> >>>>>>
> >>>>>> Regards
> >>>>>> Ehsan
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> -----
> >>>>>> E.Z.Moghaddam
> >>>>>> zaerymoghaddam@gmail.com
> >>>>>> --
> >>>>>> View this message in context:
> >>>>>>
> >>>>>> http://karaf.922171.n3.nabble.**com/Which-config-properties-**
> >>>>>> and-startup-properties-with-**admin-create-**tp4030050p4030137.html<
> http://karaf.922171.n3.nabble.com/Which-config-properties-and-startup-properties-with-admin-create-tp4030050p4030137.html
> >
> >>>>>> Sent from the Karaf - Dev mailing list archive at Nabble.com.
> >>>>>>
> >>>>>>
> >>>>> --
> >>>>> Jean-Baptiste Onofré
> >>>>> jbonofre@apache.org
> >>>>> http://blog.nanthrax.net
> >>>>> Talend - http://www.talend.com
> >>>>>
> >>>>
> >>>
> >>> --
> >>> Jean-Baptiste Onofré
> >>> jbonofre@apache.org
> >>> http://blog.nanthrax.net
> >>> Talend - http://www.talend.com
> >>>
> >>
> > --
> > Jean-Baptiste Onofré
> > jbonofre@apache.org
> > http://blog.nanthrax.net
> > Talend - http://www.talend.com
> >
>
Re: Which config.properties and startup.properties with admin:create ?
Posted by Achim Nierbeck <bc...@googlemail.com>.
Hi guys,
Branding sounds like a good idea.
I think it would solve all the issues we have with custom and std. Karaf.
regards, Achim
sent from mobile device
Am 01.11.2013 08:10 schrieb "Jean-Baptiste Onofré" <jb...@nanthrax.net>:
> Agree Gert.
>
> Why not using a kind of "branding" bundle that admin:create can use (it's
> a step forward to the profile):
> - if the custom distribution (ServiceMix) doesn't provide a "branding"
> bundle, admin:create creates a fresh Karaf instance (as it does now)
> - if the custom distribution provides a "branding" bundle, admin:create
> can look for this "branding" bundle and use it to create the "fresh custom"
> instance
>
> WDYT ?
>
> Regards
> JB
>
> On 10/31/2013 11:08 PM, Gert Vanthienen wrote:
>
>> L.S.,
>>
>>
>> In the case of ServiceMix, I would like the admin:create to create a
>> fresh, empty ServiceMix instance instead of a fresh, empty Karaf
>> instance. Adding an option to the command does not really fix the
>> issue in my mind, as the user still has to be aware of the fact that
>> ServiceMix has a modified startup.properties file to know he/she has
>> to add the option.
>>
>> Personally, I would prefer to keep things as simple as possible until
>> we work out the profiles solution and just add a flag to indicate that
>> we want the startup/config properties file from the actual root
>> container instead of the ones from Karaf (something like
>> inheritStartupProperties=true and inheritConfigProperties=true). For
>> Karaf, we can just leave out the config file and default to false to
>> keep things as before.
>>
>> I agree this will break current behavior for users of ServiceMix that
>> have been modifying their own startup/config.properties files, but
>> those are pretty knowledgeable users anyway so we could just add that
>> to the release notes or something. The current behavior of
>> admin:create just doesn't work at all for anyone in the case of
>> ServiceMix (or any other project out there that requires modifications
>> to either of those two files) - they end up with a container they have
>> to manually go and edit before they can start it.
>>
>>
>> Regards,
>>
>> Gert Vanthienen
>>
>>
>> On Thu, Oct 31, 2013 at 9:55 PM, Jean-Baptiste Onofré <jb...@nanthrax.net>
>> wrote:
>>
>>> Gert,
>>>
>>> the only thing is that admin:create won't create a "fresh empty" Karaf
>>> instance: if the user changed the startup.properties, admin:create will
>>> create an instance already with these changes included. Currently,
>>> admin:create creates a complete fresh instance, ignoring the changes from
>>> the user in the root instance.
>>>
>>> Regards
>>> JB
>>>
>>>
>>> On 10/31/2013 09:20 PM, Gert Vanthienen wrote:
>>>
>>>>
>>>> Jean-Baptiste, Ehsan,
>>>>
>>>>
>>>> How about making that configurable instead of using the -c parameter?
>>>> We could still leave the default to pick the original, embedded Karaf
>>>> config/startup.properties, so for Karaf nothing would change.
>>>>
>>>> But at least that way, projects like ServiceMix could just have the
>>>> admin:create command do the right thing for that particular project by
>>>> simply adding the org.apache.karaf.admin.core.**cfg file to their etc
>>>> directory, without the user having to be aware of the little bit of
>>>> extra tweaking required to properly bootstrap the container?
>>>>
>>>>
>>>> Regards,
>>>>
>>>> Gert
>>>>
>>>>
>>>> On Thu, Oct 31, 2013 at 7:41 PM, Jean-Baptiste Onofré <jb...@nanthrax.net>
>>>> wrote:
>>>>
>>>>>
>>>>> Good idea. I will do that.
>>>>> The thing
>>>>>
>>>>> Regards
>>>>> JB
>>>>>
>>>>>
>>>>> On 10/31/2013 01:28 PM, zaerymoghaddam wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> Hi guys
>>>>>>
>>>>>> Isn't it possible having an option on admin:create to decide whether
>>>>>> to
>>>>>> create a new plain instance or use root instance configurations?
>>>>>>
>>>>>> For example: 'admin:create -c'.
>>>>>> which '-c' could mean clone root instance's configuration.
>>>>>>
>>>>>> Regards
>>>>>> Ehsan
>>>>>>
>>>>>>
>>>>>>
>>>>>> -----
>>>>>> E.Z.Moghaddam
>>>>>> zaerymoghaddam@gmail.com
>>>>>> --
>>>>>> View this message in context:
>>>>>>
>>>>>> http://karaf.922171.n3.nabble.**com/Which-config-properties-**
>>>>>> and-startup-properties-with-**admin-create-**tp4030050p4030137.html<http://karaf.922171.n3.nabble.com/Which-config-properties-and-startup-properties-with-admin-create-tp4030050p4030137.html>
>>>>>> Sent from the Karaf - Dev mailing list archive at Nabble.com.
>>>>>>
>>>>>>
>>>>> --
>>>>> Jean-Baptiste Onofré
>>>>> jbonofre@apache.org
>>>>> http://blog.nanthrax.net
>>>>> Talend - http://www.talend.com
>>>>>
>>>>
>>>
>>> --
>>> Jean-Baptiste Onofré
>>> jbonofre@apache.org
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>>>
>>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
Re: Which config.properties and startup.properties with admin:create
?
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Agree Gert.
Why not using a kind of "branding" bundle that admin:create can use
(it's a step forward to the profile):
- if the custom distribution (ServiceMix) doesn't provide a "branding"
bundle, admin:create creates a fresh Karaf instance (as it does now)
- if the custom distribution provides a "branding" bundle, admin:create
can look for this "branding" bundle and use it to create the "fresh
custom" instance
WDYT ?
Regards
JB
On 10/31/2013 11:08 PM, Gert Vanthienen wrote:
> L.S.,
>
>
> In the case of ServiceMix, I would like the admin:create to create a
> fresh, empty ServiceMix instance instead of a fresh, empty Karaf
> instance. Adding an option to the command does not really fix the
> issue in my mind, as the user still has to be aware of the fact that
> ServiceMix has a modified startup.properties file to know he/she has
> to add the option.
>
> Personally, I would prefer to keep things as simple as possible until
> we work out the profiles solution and just add a flag to indicate that
> we want the startup/config properties file from the actual root
> container instead of the ones from Karaf (something like
> inheritStartupProperties=true and inheritConfigProperties=true). For
> Karaf, we can just leave out the config file and default to false to
> keep things as before.
>
> I agree this will break current behavior for users of ServiceMix that
> have been modifying their own startup/config.properties files, but
> those are pretty knowledgeable users anyway so we could just add that
> to the release notes or something. The current behavior of
> admin:create just doesn't work at all for anyone in the case of
> ServiceMix (or any other project out there that requires modifications
> to either of those two files) - they end up with a container they have
> to manually go and edit before they can start it.
>
>
> Regards,
>
> Gert Vanthienen
>
>
> On Thu, Oct 31, 2013 at 9:55 PM, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
>> Gert,
>>
>> the only thing is that admin:create won't create a "fresh empty" Karaf
>> instance: if the user changed the startup.properties, admin:create will
>> create an instance already with these changes included. Currently,
>> admin:create creates a complete fresh instance, ignoring the changes from
>> the user in the root instance.
>>
>> Regards
>> JB
>>
>>
>> On 10/31/2013 09:20 PM, Gert Vanthienen wrote:
>>>
>>> Jean-Baptiste, Ehsan,
>>>
>>>
>>> How about making that configurable instead of using the -c parameter?
>>> We could still leave the default to pick the original, embedded Karaf
>>> config/startup.properties, so for Karaf nothing would change.
>>>
>>> But at least that way, projects like ServiceMix could just have the
>>> admin:create command do the right thing for that particular project by
>>> simply adding the org.apache.karaf.admin.core.cfg file to their etc
>>> directory, without the user having to be aware of the little bit of
>>> extra tweaking required to properly bootstrap the container?
>>>
>>>
>>> Regards,
>>>
>>> Gert
>>>
>>>
>>> On Thu, Oct 31, 2013 at 7:41 PM, Jean-Baptiste Onofré <jb...@nanthrax.net>
>>> wrote:
>>>>
>>>> Good idea. I will do that.
>>>> The thing
>>>>
>>>> Regards
>>>> JB
>>>>
>>>>
>>>> On 10/31/2013 01:28 PM, zaerymoghaddam wrote:
>>>>>
>>>>>
>>>>> Hi guys
>>>>>
>>>>> Isn't it possible having an option on admin:create to decide whether to
>>>>> create a new plain instance or use root instance configurations?
>>>>>
>>>>> For example: 'admin:create -c'.
>>>>> which '-c' could mean clone root instance's configuration.
>>>>>
>>>>> Regards
>>>>> Ehsan
>>>>>
>>>>>
>>>>>
>>>>> -----
>>>>> E.Z.Moghaddam
>>>>> zaerymoghaddam@gmail.com
>>>>> --
>>>>> View this message in context:
>>>>>
>>>>> http://karaf.922171.n3.nabble.com/Which-config-properties-and-startup-properties-with-admin-create-tp4030050p4030137.html
>>>>> Sent from the Karaf - Dev mailing list archive at Nabble.com.
>>>>>
>>>>
>>>> --
>>>> Jean-Baptiste Onofré
>>>> jbonofre@apache.org
>>>> http://blog.nanthrax.net
>>>> Talend - http://www.talend.com
>>
>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Which config.properties and startup.properties with admin:create ?
Posted by Gert Vanthienen <ge...@gmail.com>.
L.S.,
In the case of ServiceMix, I would like the admin:create to create a
fresh, empty ServiceMix instance instead of a fresh, empty Karaf
instance. Adding an option to the command does not really fix the
issue in my mind, as the user still has to be aware of the fact that
ServiceMix has a modified startup.properties file to know he/she has
to add the option.
Personally, I would prefer to keep things as simple as possible until
we work out the profiles solution and just add a flag to indicate that
we want the startup/config properties file from the actual root
container instead of the ones from Karaf (something like
inheritStartupProperties=true and inheritConfigProperties=true). For
Karaf, we can just leave out the config file and default to false to
keep things as before.
I agree this will break current behavior for users of ServiceMix that
have been modifying their own startup/config.properties files, but
those are pretty knowledgeable users anyway so we could just add that
to the release notes or something. The current behavior of
admin:create just doesn't work at all for anyone in the case of
ServiceMix (or any other project out there that requires modifications
to either of those two files) - they end up with a container they have
to manually go and edit before they can start it.
Regards,
Gert Vanthienen
On Thu, Oct 31, 2013 at 9:55 PM, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
> Gert,
>
> the only thing is that admin:create won't create a "fresh empty" Karaf
> instance: if the user changed the startup.properties, admin:create will
> create an instance already with these changes included. Currently,
> admin:create creates a complete fresh instance, ignoring the changes from
> the user in the root instance.
>
> Regards
> JB
>
>
> On 10/31/2013 09:20 PM, Gert Vanthienen wrote:
>>
>> Jean-Baptiste, Ehsan,
>>
>>
>> How about making that configurable instead of using the -c parameter?
>> We could still leave the default to pick the original, embedded Karaf
>> config/startup.properties, so for Karaf nothing would change.
>>
>> But at least that way, projects like ServiceMix could just have the
>> admin:create command do the right thing for that particular project by
>> simply adding the org.apache.karaf.admin.core.cfg file to their etc
>> directory, without the user having to be aware of the little bit of
>> extra tweaking required to properly bootstrap the container?
>>
>>
>> Regards,
>>
>> Gert
>>
>>
>> On Thu, Oct 31, 2013 at 7:41 PM, Jean-Baptiste Onofré <jb...@nanthrax.net>
>> wrote:
>>>
>>> Good idea. I will do that.
>>> The thing
>>>
>>> Regards
>>> JB
>>>
>>>
>>> On 10/31/2013 01:28 PM, zaerymoghaddam wrote:
>>>>
>>>>
>>>> Hi guys
>>>>
>>>> Isn't it possible having an option on admin:create to decide whether to
>>>> create a new plain instance or use root instance configurations?
>>>>
>>>> For example: 'admin:create -c'.
>>>> which '-c' could mean clone root instance's configuration.
>>>>
>>>> Regards
>>>> Ehsan
>>>>
>>>>
>>>>
>>>> -----
>>>> E.Z.Moghaddam
>>>> zaerymoghaddam@gmail.com
>>>> --
>>>> View this message in context:
>>>>
>>>> http://karaf.922171.n3.nabble.com/Which-config-properties-and-startup-properties-with-admin-create-tp4030050p4030137.html
>>>> Sent from the Karaf - Dev mailing list archive at Nabble.com.
>>>>
>>>
>>> --
>>> Jean-Baptiste Onofré
>>> jbonofre@apache.org
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
Re: Which config.properties and startup.properties with admin:create ?
Posted by Ehsan Zaery Moghaddam <za...@gmail.com>.
Gert
What do you suppose to have in org.apache.karaf.admin.core.cfg?
If you mean having the address of the updated config/startup.properties,
then you can even create a new instance using completely different
configurations (maybe different from the one you're calling its
admin:create command).
Also I think the way 'admin:create' behave while creating a new instance is
an important aspect of its operation and having a dedicated option on this
command could be more consistent.
Regards
Ehsan
On Fri, Nov 1, 2013 at 12:25 AM, Jean-Baptiste Onofré <jb...@nanthrax.net>wrote:
> Gert,
>
> the only thing is that admin:create won't create a "fresh empty" Karaf
> instance: if the user changed the startup.properties, admin:create will
> create an instance already with these changes included. Currently,
> admin:create creates a complete fresh instance, ignoring the changes from
> the user in the root instance.
>
> Regards
> JB
>
>
> On 10/31/2013 09:20 PM, Gert Vanthienen wrote:
>
>> Jean-Baptiste, Ehsan,
>>
>>
>> How about making that configurable instead of using the -c parameter?
>> We could still leave the default to pick the original, embedded Karaf
>> config/startup.properties, so for Karaf nothing would change.
>>
>> But at least that way, projects like ServiceMix could just have the
>> admin:create command do the right thing for that particular project by
>> simply adding the org.apache.karaf.admin.core.**cfg file to their etc
>> directory, without the user having to be aware of the little bit of
>> extra tweaking required to properly bootstrap the container?
>>
>>
>> Regards,
>>
>> Gert
>>
>>
>> On Thu, Oct 31, 2013 at 7:41 PM, Jean-Baptiste Onofré <jb...@nanthrax.net>
>> wrote:
>>
>>> Good idea. I will do that.
>>> The thing
>>>
>>> Regards
>>> JB
>>>
>>>
>>> On 10/31/2013 01:28 PM, zaerymoghaddam wrote:
>>>
>>>>
>>>> Hi guys
>>>>
>>>> Isn't it possible having an option on admin:create to decide whether to
>>>> create a new plain instance or use root instance configurations?
>>>>
>>>> For example: 'admin:create -c'.
>>>> which '-c' could mean clone root instance's configuration.
>>>>
>>>> Regards
>>>> Ehsan
>>>>
>>>>
>>>>
>>>> -----
>>>> E.Z.Moghaddam
>>>> zaerymoghaddam@gmail.com
>>>> --
>>>> View this message in context:
>>>> http://karaf.922171.n3.nabble.**com/Which-config-properties-**
>>>> and-startup-properties-with-**admin-create-**tp4030050p4030137.html<http://karaf.922171.n3.nabble.com/Which-config-properties-and-startup-properties-with-admin-create-tp4030050p4030137.html>
>>>> Sent from the Karaf - Dev mailing list archive at Nabble.com.
>>>>
>>>>
>>> --
>>> Jean-Baptiste Onofré
>>> jbonofre@apache.org
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>>>
>>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
Re: Which config.properties and startup.properties with admin:create
?
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Gert,
the only thing is that admin:create won't create a "fresh empty" Karaf
instance: if the user changed the startup.properties, admin:create will
create an instance already with these changes included. Currently,
admin:create creates a complete fresh instance, ignoring the changes
from the user in the root instance.
Regards
JB
On 10/31/2013 09:20 PM, Gert Vanthienen wrote:
> Jean-Baptiste, Ehsan,
>
>
> How about making that configurable instead of using the -c parameter?
> We could still leave the default to pick the original, embedded Karaf
> config/startup.properties, so for Karaf nothing would change.
>
> But at least that way, projects like ServiceMix could just have the
> admin:create command do the right thing for that particular project by
> simply adding the org.apache.karaf.admin.core.cfg file to their etc
> directory, without the user having to be aware of the little bit of
> extra tweaking required to properly bootstrap the container?
>
>
> Regards,
>
> Gert
>
>
> On Thu, Oct 31, 2013 at 7:41 PM, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
>> Good idea. I will do that.
>>The thing
>> Regards
>> JB
>>
>>
>> On 10/31/2013 01:28 PM, zaerymoghaddam wrote:
>>>
>>> Hi guys
>>>
>>> Isn't it possible having an option on admin:create to decide whether to
>>> create a new plain instance or use root instance configurations?
>>>
>>> For example: 'admin:create -c'.
>>> which '-c' could mean clone root instance's configuration.
>>>
>>> Regards
>>> Ehsan
>>>
>>>
>>>
>>> -----
>>> E.Z.Moghaddam
>>> zaerymoghaddam@gmail.com
>>> --
>>> View this message in context:
>>> http://karaf.922171.n3.nabble.com/Which-config-properties-and-startup-properties-with-admin-create-tp4030050p4030137.html
>>> Sent from the Karaf - Dev mailing list archive at Nabble.com.
>>>
>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Which config.properties and startup.properties with admin:create ?
Posted by Gert Vanthienen <ge...@gmail.com>.
Jean-Baptiste, Ehsan,
How about making that configurable instead of using the -c parameter?
We could still leave the default to pick the original, embedded Karaf
config/startup.properties, so for Karaf nothing would change.
But at least that way, projects like ServiceMix could just have the
admin:create command do the right thing for that particular project by
simply adding the org.apache.karaf.admin.core.cfg file to their etc
directory, without the user having to be aware of the little bit of
extra tweaking required to properly bootstrap the container?
Regards,
Gert
On Thu, Oct 31, 2013 at 7:41 PM, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
> Good idea. I will do that.
>
> Regards
> JB
>
>
> On 10/31/2013 01:28 PM, zaerymoghaddam wrote:
>>
>> Hi guys
>>
>> Isn't it possible having an option on admin:create to decide whether to
>> create a new plain instance or use root instance configurations?
>>
>> For example: 'admin:create -c'.
>> which '-c' could mean clone root instance's configuration.
>>
>> Regards
>> Ehsan
>>
>>
>>
>> -----
>> E.Z.Moghaddam
>> zaerymoghaddam@gmail.com
>> --
>> View this message in context:
>> http://karaf.922171.n3.nabble.com/Which-config-properties-and-startup-properties-with-admin-create-tp4030050p4030137.html
>> Sent from the Karaf - Dev mailing list archive at Nabble.com.
>>
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
Re: Which config.properties and startup.properties with admin:create
?
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Good idea. I will do that.
Regards
JB
On 10/31/2013 01:28 PM, zaerymoghaddam wrote:
> Hi guys
>
> Isn't it possible having an option on admin:create to decide whether to
> create a new plain instance or use root instance configurations?
>
> For example: 'admin:create -c'.
> which '-c' could mean clone root instance's configuration.
>
> Regards
> Ehsan
>
>
>
> -----
> E.Z.Moghaddam
> zaerymoghaddam@gmail.com
> --
> View this message in context: http://karaf.922171.n3.nabble.com/Which-config-properties-and-startup-properties-with-admin-create-tp4030050p4030137.html
> Sent from the Karaf - Dev mailing list archive at Nabble.com.
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Which config.properties and startup.properties with
admin:create ?
Posted by zaerymoghaddam <za...@gmail.com>.
Hi guys
Isn't it possible having an option on admin:create to decide whether to
create a new plain instance or use root instance configurations?
For example: 'admin:create -c'.
which '-c' could mean clone root instance's configuration.
Regards
Ehsan
-----
E.Z.Moghaddam
zaerymoghaddam@gmail.com
--
View this message in context: http://karaf.922171.n3.nabble.com/Which-config-properties-and-startup-properties-with-admin-create-tp4030050p4030137.html
Sent from the Karaf - Dev mailing list archive at Nabble.com.
Re: Which config.properties and startup.properties with admin:create
?
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi guys,
it's not the case with clone:
- agree with you for admin:create: it should use startup.properties and
config.properties from the root instance (with caution)
- for admin:clone, it's a complete isolated instance
Regards
JB
On 10/29/2013 03:27 PM, Ioannis Canellos wrote:
> Conceptually, since parent and children share the same system folder,
> they should also share the same startup.properties and most probably
> config.properties too.
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Which config.properties and startup.properties with admin:create ?
Posted by Freeman Fang <fr...@gmail.com>.
yes, this makes a lot more sense to me as well.
+1
－－－－－－－－－－－－－
Freeman(Yue) Fang
Red Hat, Inc.
FuseSource is now part of Red Hat
Web: http://fusesource.com | http://www.redhat.com/
Twitter: freemanfang
Blog: http://freemanfang.blogspot.com
http://blog.sina.com.cn/u/1473905042
weibo: @Freeman小屋
On 2013-10-29, at 下午10:27, Ioannis Canellos wrote:
> Conceptually, since parent and children share the same system folder,
> they should also share the same startup.properties and most probably
> config.properties too.
>
> --
> Ioannis Canellos
Re: Which config.properties and startup.properties with admin:create ?
Posted by Ioannis Canellos <io...@gmail.com>.
Conceptually, since parent and children share the same system folder,
they should also share the same startup.properties and most probably
config.properties too.
--
Ioannis Canellos
Re: Which config.properties and startup.properties with admin:create ?
Posted by Gert Vanthienen <ge...@gmail.com>.
L.S.,
While it's great to see a more overall solution being developed in
future versions with profiles or something like that, it would be nice
to have a more short-term solution as well.
I still think using the instance config/startup.properties would be a
fair intermediate solution - for most users of Karaf, it wouldn't make
a difference and for people that are building something on top of
Karaf, it would at least bootstrap the child container properly.
However, I'm definitely open to any other suggestions on how to get
this working properly for Karaf 2.3.x.
Regards,
Gert Vanthienen
On Sun, Oct 27, 2013 at 6:05 PM, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
> Hi Lukasz,
>
> Yeah, I proposed the concept of profiles. I don't abandon the idea, but I
> didn't find time yet to prototype.
>
> Thanks for your reminder, I will prototype profiles and submit to you all ;)
>
> On my side, I used Kalumet to "configure" all Karaf properties/cfg files.
> So, I would like to mimic what I did in Kalumet (by configuration) directly
> in Karaf.
>
> I keep you posted.
>
> Regards
> JB
>
>
> On 10/27/2013 05:38 PM, Łukasz Dywicki wrote:
>>
>> Long, long time ago there was idea of profiles which could be integrated
>> into Karaf to integrate all things - starting from configuration and
>> environment properties up to installed bundles and features. Sadly this idea
>> did not come. Two separate things grown up - KARs and Cellar together with
>> Fabric. These days none from both manages instance configuration. However
>> idea of profiles was much deeper and one from plans was to manage it to work
>> at build time and runtime.
>>
>> For now I would preffer to go for fully working solution, maybe not for
>> Karaf 3.0 but for 3.1 which could integrate profiles. That's my 0.02 PLN.
>> ;-)
>>
>> Cheers,
>> Łukasz Dywicki
>> --
>> luke@code-house.org
>> Twitter: ldywicki
>> Blog: http://dywicki.pl
>> Code-House - http://code-house.org
>>
>> Wiadomość napisana przez Gert Vanthienen <ge...@gmail.com> w
>> dniu 25 paź 2013, o godz. 16:14:
>>
>>> Hey Achim and Jean-Baptiste,
>>>
>>>
>>> Yeah, we do have an admin:clone that does work fine, but that creates
>>> a full copy of the instance. That can be useful too occasionally, but
>>> I would also like to be able to actually use admin:create to create an
>>> empty instance. Right now, if my project requires any changes to
>>> either of these two bootstrap files, there's no real way to do that
>>> because the admin:create command would create an empty instance of
>>> Karaf instead of an empty instance of my own project.
>>>
>>> If there's another way to achieve this goal or if we can think of a
>>> better solution, that would be fine for me too.
>>>
>>>
>>> Regards,
>>>
>>> Gert Vanthienen
>>>
>>>
>>> On Fri, Oct 25, 2013 at 3:47 PM, Achim Nierbeck <bc...@googlemail.com>
>>> wrote:
>>>>
>>>> Hi Gert,
>>>>
>>>> afaik we have clone for that.
>>>> It should clone the current instance.
>>>>
>>>> regards, Achim
>>>>
>>>>
>>>> 2013/10/25 Gert Vanthienen <ge...@gmail.com>
>>>>
>>>>> L.S.,
>>>>>
>>>>>
>>>>> The current implementation of the admin:create command uses copies
>>>>> from the Karaf assembly of the config.properties and
>>>>> startup.properties files when creating the instance.
>>>>>
>>>>> If you're running a plain Karaf container, that's pretty much OK but
>>>>> if you have something else built on top of Karaf (e.g. ServiceMix), it
>>>>> would make a lot more sense to get those properties files out of your
>>>>> current root instance instead. Unlike the settings files for
>>>>> features, logging, ..., these files are used to bootstrap the
>>>>> container, so by the time the child container has started, it's too
>>>>> late to update them.
>>>>>
>>>>> One example: in ServiceMix 5, we are using the startup.properties file
>>>>> to ensure we have Features OBR support installed and that our Camel
>>>>> instrumentation hook is being started as soon as possible to ensure
>>>>> all our routes get instrumented. If you do an admin:create in
>>>>> ServiceMix 5, you will have to manually go and edit the
>>>>> startup.properties file before starting the child container to get the
>>>>> same behavior.
>>>>>
>>>>> The same probably goes for the config.properties. If I want to build
>>>>> a product/project on top of Karaf that uses Equinox instead of Felix
>>>>> by default, the admin:create command would still create a plain Karaf
>>>>> container running Felix.
>>>>>
>>>>> In my mind, it would make more sense for the admin:create command to
>>>>> create a child instance with the same bootstrap settings as the root,
>>>>> so if that's OK for everyone, I'll raise a JIRA and fix this.
>>>>>
>>>>>
>>>>> Regards,
>>>>>
>>>>> Gert Vanthienen
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>>>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer
>>>> &
>>>> Project Lead
>>>> OPS4J Pax for Vaadin <http://team.ops4j.org/wiki/display/PAXVAADIN/Home>
>>>> Commiter & Project Lead
>>>> blog <http://notizblog.nierbeck.de/>
>>
>>
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
Re: Which config.properties and startup.properties with admin:create
?
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Lukasz,
Yeah, I proposed the concept of profiles. I don't abandon the idea, but
I didn't find time yet to prototype.
Thanks for your reminder, I will prototype profiles and submit to you all ;)
On my side, I used Kalumet to "configure" all Karaf properties/cfg
files. So, I would like to mimic what I did in Kalumet (by
configuration) directly in Karaf.
I keep you posted.
Regards
JB
On 10/27/2013 05:38 PM, Łukasz Dywicki wrote:
> Long, long time ago there was idea of profiles which could be integrated into Karaf to integrate all things - starting from configuration and environment properties up to installed bundles and features. Sadly this idea did not come. Two separate things grown up - KARs and Cellar together with Fabric. These days none from both manages instance configuration. However idea of profiles was much deeper and one from plans was to manage it to work at build time and runtime.
>
> For now I would preffer to go for fully working solution, maybe not for Karaf 3.0 but for 3.1 which could integrate profiles. That's my 0.02 PLN. ;-)
>
> Cheers,
> Łukasz Dywicki
> --
> luke@code-house.org
> Twitter: ldywicki
> Blog: http://dywicki.pl
> Code-House - http://code-house.org
>
> Wiadomość napisana przez Gert Vanthienen <ge...@gmail.com> w dniu 25 paź 2013, o godz. 16:14:
>
>> Hey Achim and Jean-Baptiste,
>>
>>
>> Yeah, we do have an admin:clone that does work fine, but that creates
>> a full copy of the instance. That can be useful too occasionally, but
>> I would also like to be able to actually use admin:create to create an
>> empty instance. Right now, if my project requires any changes to
>> either of these two bootstrap files, there's no real way to do that
>> because the admin:create command would create an empty instance of
>> Karaf instead of an empty instance of my own project.
>>
>> If there's another way to achieve this goal or if we can think of a
>> better solution, that would be fine for me too.
>>
>>
>> Regards,
>>
>> Gert Vanthienen
>>
>>
>> On Fri, Oct 25, 2013 at 3:47 PM, Achim Nierbeck <bc...@googlemail.com> wrote:
>>> Hi Gert,
>>>
>>> afaik we have clone for that.
>>> It should clone the current instance.
>>>
>>> regards, Achim
>>>
>>>
>>> 2013/10/25 Gert Vanthienen <ge...@gmail.com>
>>>
>>>> L.S.,
>>>>
>>>>
>>>> The current implementation of the admin:create command uses copies
>>>> from the Karaf assembly of the config.properties and
>>>> startup.properties files when creating the instance.
>>>>
>>>> If you're running a plain Karaf container, that's pretty much OK but
>>>> if you have something else built on top of Karaf (e.g. ServiceMix), it
>>>> would make a lot more sense to get those properties files out of your
>>>> current root instance instead. Unlike the settings files for
>>>> features, logging, ..., these files are used to bootstrap the
>>>> container, so by the time the child container has started, it's too
>>>> late to update them.
>>>>
>>>> One example: in ServiceMix 5, we are using the startup.properties file
>>>> to ensure we have Features OBR support installed and that our Camel
>>>> instrumentation hook is being started as soon as possible to ensure
>>>> all our routes get instrumented. If you do an admin:create in
>>>> ServiceMix 5, you will have to manually go and edit the
>>>> startup.properties file before starting the child container to get the
>>>> same behavior.
>>>>
>>>> The same probably goes for the config.properties. If I want to build
>>>> a product/project on top of Karaf that uses Equinox instead of Felix
>>>> by default, the admin:create command would still create a plain Karaf
>>>> container running Felix.
>>>>
>>>> In my mind, it would make more sense for the admin:create command to
>>>> create a child instance with the same bootstrap settings as the root,
>>>> so if that's OK for everyone, I'll raise a JIRA and fix this.
>>>>
>>>>
>>>> Regards,
>>>>
>>>> Gert Vanthienen
>>>>
>>>
>>>
>>>
>>> --
>>>
>>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
>>> Project Lead
>>> OPS4J Pax for Vaadin <http://team.ops4j.org/wiki/display/PAXVAADIN/Home>
>>> Commiter & Project Lead
>>> blog <http://notizblog.nierbeck.de/>
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Which config.properties and startup.properties with admin:create ?
Posted by Łukasz Dywicki <lu...@code-house.org>.
Long, long time ago there was idea of profiles which could be integrated into Karaf to integrate all things - starting from configuration and environment properties up to installed bundles and features. Sadly this idea did not come. Two separate things grown up - KARs and Cellar together with Fabric. These days none from both manages instance configuration. However idea of profiles was much deeper and one from plans was to manage it to work at build time and runtime.
For now I would preffer to go for fully working solution, maybe not for Karaf 3.0 but for 3.1 which could integrate profiles. That's my 0.02 PLN. ;-)
Cheers,
Łukasz Dywicki
--
luke@code-house.org
Twitter: ldywicki
Blog: http://dywicki.pl
Code-House - http://code-house.org
Wiadomość napisana przez Gert Vanthienen <ge...@gmail.com> w dniu 25 paź 2013, o godz. 16:14:
> Hey Achim and Jean-Baptiste,
>
>
> Yeah, we do have an admin:clone that does work fine, but that creates
> a full copy of the instance. That can be useful too occasionally, but
> I would also like to be able to actually use admin:create to create an
> empty instance. Right now, if my project requires any changes to
> either of these two bootstrap files, there's no real way to do that
> because the admin:create command would create an empty instance of
> Karaf instead of an empty instance of my own project.
>
> If there's another way to achieve this goal or if we can think of a
> better solution, that would be fine for me too.
>
>
> Regards,
>
> Gert Vanthienen
>
>
> On Fri, Oct 25, 2013 at 3:47 PM, Achim Nierbeck <bc...@googlemail.com> wrote:
>> Hi Gert,
>>
>> afaik we have clone for that.
>> It should clone the current instance.
>>
>> regards, Achim
>>
>>
>> 2013/10/25 Gert Vanthienen <ge...@gmail.com>
>>
>>> L.S.,
>>>
>>>
>>> The current implementation of the admin:create command uses copies
>>> from the Karaf assembly of the config.properties and
>>> startup.properties files when creating the instance.
>>>
>>> If you're running a plain Karaf container, that's pretty much OK but
>>> if you have something else built on top of Karaf (e.g. ServiceMix), it
>>> would make a lot more sense to get those properties files out of your
>>> current root instance instead. Unlike the settings files for
>>> features, logging, ..., these files are used to bootstrap the
>>> container, so by the time the child container has started, it's too
>>> late to update them.
>>>
>>> One example: in ServiceMix 5, we are using the startup.properties file
>>> to ensure we have Features OBR support installed and that our Camel
>>> instrumentation hook is being started as soon as possible to ensure
>>> all our routes get instrumented. If you do an admin:create in
>>> ServiceMix 5, you will have to manually go and edit the
>>> startup.properties file before starting the child container to get the
>>> same behavior.
>>>
>>> The same probably goes for the config.properties. If I want to build
>>> a product/project on top of Karaf that uses Equinox instead of Felix
>>> by default, the admin:create command would still create a plain Karaf
>>> container running Felix.
>>>
>>> In my mind, it would make more sense for the admin:create command to
>>> create a child instance with the same bootstrap settings as the root,
>>> so if that's OK for everyone, I'll raise a JIRA and fix this.
>>>
>>>
>>> Regards,
>>>
>>> Gert Vanthienen
>>>
>>
>>
>>
>> --
>>
>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
>> Project Lead
>> OPS4J Pax for Vaadin <http://team.ops4j.org/wiki/display/PAXVAADIN/Home>
>> Commiter & Project Lead
>> blog <http://notizblog.nierbeck.de/>
Re: Which config.properties and startup.properties with admin:create ?
Posted by Gert Vanthienen <ge...@gmail.com>.
Hey Achim and Jean-Baptiste,
Yeah, we do have an admin:clone that does work fine, but that creates
a full copy of the instance. That can be useful too occasionally, but
I would also like to be able to actually use admin:create to create an
empty instance. Right now, if my project requires any changes to
either of these two bootstrap files, there's no real way to do that
because the admin:create command would create an empty instance of
Karaf instead of an empty instance of my own project.
If there's another way to achieve this goal or if we can think of a
better solution, that would be fine for me too.
Regards,
Gert Vanthienen
On Fri, Oct 25, 2013 at 3:47 PM, Achim Nierbeck <bc...@googlemail.com> wrote:
> Hi Gert,
>
> afaik we have clone for that.
> It should clone the current instance.
>
> regards, Achim
>
>
> 2013/10/25 Gert Vanthienen <ge...@gmail.com>
>
>> L.S.,
>>
>>
>> The current implementation of the admin:create command uses copies
>> from the Karaf assembly of the config.properties and
>> startup.properties files when creating the instance.
>>
>> If you're running a plain Karaf container, that's pretty much OK but
>> if you have something else built on top of Karaf (e.g. ServiceMix), it
>> would make a lot more sense to get those properties files out of your
>> current root instance instead. Unlike the settings files for
>> features, logging, ..., these files are used to bootstrap the
>> container, so by the time the child container has started, it's too
>> late to update them.
>>
>> One example: in ServiceMix 5, we are using the startup.properties file
>> to ensure we have Features OBR support installed and that our Camel
>> instrumentation hook is being started as soon as possible to ensure
>> all our routes get instrumented. If you do an admin:create in
>> ServiceMix 5, you will have to manually go and edit the
>> startup.properties file before starting the child container to get the
>> same behavior.
>>
>> The same probably goes for the config.properties. If I want to build
>> a product/project on top of Karaf that uses Equinox instead of Felix
>> by default, the admin:create command would still create a plain Karaf
>> container running Felix.
>>
>> In my mind, it would make more sense for the admin:create command to
>> create a child instance with the same bootstrap settings as the root,
>> so if that's OK for everyone, I'll raise a JIRA and fix this.
>>
>>
>> Regards,
>>
>> Gert Vanthienen
>>
>
>
>
> --
>
> Apache Karaf <http://karaf.apache.org/> Committer & PMC
> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
> Project Lead
> OPS4J Pax for Vaadin <http://team.ops4j.org/wiki/display/PAXVAADIN/Home>
> Commiter & Project Lead
> blog <http://notizblog.nierbeck.de/>
Re: Which config.properties and startup.properties with admin:create ?
Posted by Achim Nierbeck <bc...@googlemail.com>.
Hi Gert,
afaik we have clone for that.
It should clone the current instance.
regards, Achim
2013/10/25 Gert Vanthienen <ge...@gmail.com>
> L.S.,
>
>
> The current implementation of the admin:create command uses copies
> from the Karaf assembly of the config.properties and
> startup.properties files when creating the instance.
>
> If you're running a plain Karaf container, that's pretty much OK but
> if you have something else built on top of Karaf (e.g. ServiceMix), it
> would make a lot more sense to get those properties files out of your
> current root instance instead. Unlike the settings files for
> features, logging, ..., these files are used to bootstrap the
> container, so by the time the child container has started, it's too
> late to update them.
>
> One example: in ServiceMix 5, we are using the startup.properties file
> to ensure we have Features OBR support installed and that our Camel
> instrumentation hook is being started as soon as possible to ensure
> all our routes get instrumented. If you do an admin:create in
> ServiceMix 5, you will have to manually go and edit the
> startup.properties file before starting the child container to get the
> same behavior.
>
> The same probably goes for the config.properties. If I want to build
> a product/project on top of Karaf that uses Equinox instead of Felix
> by default, the admin:create command would still create a plain Karaf
> container running Felix.
>
> In my mind, it would make more sense for the admin:create command to
> create a child instance with the same bootstrap settings as the root,
> so if that's OK for everyone, I'll raise a JIRA and fix this.
>
>
> Regards,
>
> Gert Vanthienen
>
--
Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
Project Lead
OPS4J Pax for Vaadin <http://team.ops4j.org/wiki/display/PAXVAADIN/Home>
Commiter & Project Lead
blog <http://notizblog.nierbeck.de/>