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é <[email protected]> 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é <[email protected]>
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
[email protected]
--
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é
[email protected]
http://blog.nanthrax.net
Talend - http://www.talend.com
--
Jean-Baptiste Onofré
[email protected]
http://blog.nanthrax.net
Talend - http://www.talend.com
--
Jean-Baptiste Onofré
[email protected]
http://blog.nanthrax.net
Talend - http://www.talend.com
