karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gert Vanthienen <gert.vanthie...@gmail.com>
Subject Re: Which config.properties and startup.properties with admin:create ?
Date Tue, 29 Oct 2013 10:51:02 GMT
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 <gert.vanthienen@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 <bcanhome@googlemail.com>
>>> wrote:
>>>>
>>>> Hi Gert,
>>>>
>>>> afaik we have clone for that.
>>>> It should clone the current instance.
>>>>
>>>> regards, Achim
>>>>
>>>>
>>>> 2013/10/25 Gert Vanthienen <gert.vanthienen@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

Mime
View raw message