You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@karaf.apache.org by jamie campbell <ja...@parit.ca> on 2011/02/16 18:56:53 UTC
possible for compositional startup.properties?
Hi,
I'm wondering if it's possible to have a compositional
etc/startup.properties in the same way one can have a compositional pom
(well, maybe pom is a bad comparison because I don't need repository
sync ability or any of the other fancy things a pom can do with regards
to composition). My use case is that I'd like to have a core set of
startup bits, and from that extensional startup bits that vary from one
scenario to another, so it would be sweet if I could do something like
------------
import base/base_startup.properties
org/specificUseCase/specificUseCase.jar=51
org/anothercase/another.jar=52
------------
-Jamie
Re: possible for compositional startup.properties?
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Thanks Bengt,
we will take a look.
Regards
JB
On 02/20/2011 10:51 PM, Bengt Rodehav wrote:
> I now created the following JIRA tickets:
>
> https://issues.apache.org/jira/browse/KARAF-474
> https://issues.apache.org/jira/browse/KARAF-475
>
> /Bengt
>
> 2011/2/19 Andreas Pieber <anpieber@gmail.com <ma...@gmail.com>>
>
> +1 for creating JIRA issues for your problems. At worst it's not a
> bug, but rather a new feature for karaf :) in addition JIRA's don't
> get "lost" (compared to mails in the lst).
>
> So IMHO +1 to go ahead and rais the issue(s).
>
> kind regards,
> andreas
>
> On Sat, Feb 19, 2011 at 9:34 AM, Bengt Rodehav <bengt@rodehav.com
> <ma...@rodehav.com>> wrote:
> > Hello Guillaume,
> > No I didn't raise a JIRA for this since I wasn't sure if this was
> already in
> > the works or not. Also, it wasn't clear to me whether there was
> bug in
> > custom.properties or if I had simply misunderstood the way it
> should work.
> > Do you think I should raise a JIRA?
> > /Bengt
> >
> > 2011/2/17 Guillaume Nodet <gnodet@gmail.com
> <ma...@gmail.com>>
> >>
> >> I think we all agree to simplify the creation of custom Karaf
> >> distribution.
> >> David Jenks has already done a lot of work in that direction, and
> >> that's definitely on the roadmap for 3.0.
> >> In the mean time, we can try to fix any bugs in the 2.2.x
> branch. Did
> >> you raise a JIRA about your problems with custom.properties ?
> >>
> >> On Thu, Feb 17, 2011 at 08:25, Bengt Rodehav <bengt@rodehav.com
> <ma...@rodehav.com>> wrote:
> >> > Jamie,
> >> > Yes, I also recommend using features for provisioning bundles
> (where
> >> > possible). However, it seems like you have the same problem
> like me when
> >> > it
> >> > comes to creating a custom Karaf server. I find myself having
> to modify
> >> > a
> >> > lot of files in the Karaf distribution every time I upgrade to
> a new
> >> > release
> >> > of Karaf (startup.properties is one of them).
> >> > I started a thread here about a week ago on this topic. You
> can read it
> >> > here:
> >> >
> http://mail-archives.apache.org/mod_mbox/karaf-user/201102.mbox/browser
> >> > It started on the user list but continued on the dev list, here:
> >> >
> http://mail-archives.apache.org/mod_mbox/karaf-dev/201102.mbox/browser
> >> > I've also been trying to use custom.properties but did not
> succeed. I
> >> > think
> >> > the goal should be that all customisation of Karaf should be done
> >> > outside of
> >> > Karaf - i e one should not have to modify files in the Karaf
> >> > distribution.
> >> > For that reason extension points are needed similar to what (I
> think)
> >> > the
> >> > intention with custom.properties is.
> >> > Any comments?
> >> > /Bengt
> >> >
> >> > 2011/2/17 jamie campbell <jamie@parit.ca <ma...@parit.ca>>
> >> >>
> >> >> On 11-02-16 03:05 PM, jamie campbell wrote:
> >> >>>
> >> >>> I've also considered that maybe Karaf doesn't do that
> because maybe
> >> >>> one
> >> >>> is supposed to take some other approach. I briefly thought
> maybe
> >> >>> something
> >> >>> using features:install would do it, but then noticed the
> features
> >> >>> stuff
> >> >>> doesn't seem to have a run level concept. The only place
> I've seen
> >> >>> the run
> >> >>> levels so far is the startup.properties.
> >> >>
> >> >> After Guillaume gave me another poke in the features
> direction I gave
> >> >> it
> >> >> another read through.. somehow I missed on first pass that it
> DOES have
> >> >> start level support, described on page 41, and the ability for
> >> >> automatic
> >> >> load on startup, as described on page 44. A case where I RTFMed
> >> >> (multiple
> >> >> times), just, somehow having blind spots to the specific
> sections that
> >> >> would
> >> >> have moved me forward. I think features is (are?) indeed the
> magic I
> >> >> seek...
> >> >>
> >> >> Thanks to everyone who gave me helpful pokes :)
> >> >>
> >> >> -Jamie
> >> >
> >> >
> >>
> >>
> >>
> >> --
> >> Cheers,
> >> Guillaume Nodet
> >> ------------------------
> >> Blog: http://gnodet.blogspot.com/
> >> ------------------------
> >> Open Source SOA
> >> http://fusesource.com
> >
> >
>
>
Re: possible for compositional startup.properties?
Posted by Bengt Rodehav <be...@rodehav.com>.
I now created the following JIRA tickets:
https://issues.apache.org/jira/browse/KARAF-474
https://issues.apache.org/jira/browse/KARAF-475
/Bengt
2011/2/19 Andreas Pieber <an...@gmail.com>
> +1 for creating JIRA issues for your problems. At worst it's not a
> bug, but rather a new feature for karaf :) in addition JIRA's don't
> get "lost" (compared to mails in the lst).
>
> So IMHO +1 to go ahead and rais the issue(s).
>
> kind regards,
> andreas
>
> On Sat, Feb 19, 2011 at 9:34 AM, Bengt Rodehav <be...@rodehav.com> wrote:
> > Hello Guillaume,
> > No I didn't raise a JIRA for this since I wasn't sure if this was already
> in
> > the works or not. Also, it wasn't clear to me whether there was bug in
> > custom.properties or if I had simply misunderstood the way it should
> work.
> > Do you think I should raise a JIRA?
> > /Bengt
> >
> > 2011/2/17 Guillaume Nodet <gn...@gmail.com>
> >>
> >> I think we all agree to simplify the creation of custom Karaf
> >> distribution.
> >> David Jenks has already done a lot of work in that direction, and
> >> that's definitely on the roadmap for 3.0.
> >> In the mean time, we can try to fix any bugs in the 2.2.x branch. Did
> >> you raise a JIRA about your problems with custom.properties ?
> >>
> >> On Thu, Feb 17, 2011 at 08:25, Bengt Rodehav <be...@rodehav.com> wrote:
> >> > Jamie,
> >> > Yes, I also recommend using features for provisioning bundles (where
> >> > possible). However, it seems like you have the same problem like me
> when
> >> > it
> >> > comes to creating a custom Karaf server. I find myself having to
> modify
> >> > a
> >> > lot of files in the Karaf distribution every time I upgrade to a new
> >> > release
> >> > of Karaf (startup.properties is one of them).
> >> > I started a thread here about a week ago on this topic. You can read
> it
> >> > here:
> >> >
> http://mail-archives.apache.org/mod_mbox/karaf-user/201102.mbox/browser
> >> > It started on the user list but continued on the dev list, here:
> >> >
> http://mail-archives.apache.org/mod_mbox/karaf-dev/201102.mbox/browser
> >> > I've also been trying to use custom.properties but did not succeed. I
> >> > think
> >> > the goal should be that all customisation of Karaf should be done
> >> > outside of
> >> > Karaf - i e one should not have to modify files in the Karaf
> >> > distribution.
> >> > For that reason extension points are needed similar to what (I think)
> >> > the
> >> > intention with custom.properties is.
> >> > Any comments?
> >> > /Bengt
> >> >
> >> > 2011/2/17 jamie campbell <ja...@parit.ca>
> >> >>
> >> >> On 11-02-16 03:05 PM, jamie campbell wrote:
> >> >>>
> >> >>> I've also considered that maybe Karaf doesn't do that because maybe
> >> >>> one
> >> >>> is supposed to take some other approach. I briefly thought maybe
> >> >>> something
> >> >>> using features:install would do it, but then noticed the features
> >> >>> stuff
> >> >>> doesn't seem to have a run level concept. The only place I've seen
> >> >>> the run
> >> >>> levels so far is the startup.properties.
> >> >>
> >> >> After Guillaume gave me another poke in the features direction I gave
> >> >> it
> >> >> another read through.. somehow I missed on first pass that it DOES
> have
> >> >> start level support, described on page 41, and the ability for
> >> >> automatic
> >> >> load on startup, as described on page 44. A case where I RTFMed
> >> >> (multiple
> >> >> times), just, somehow having blind spots to the specific sections
> that
> >> >> would
> >> >> have moved me forward. I think features is (are?) indeed the magic I
> >> >> seek...
> >> >>
> >> >> Thanks to everyone who gave me helpful pokes :)
> >> >>
> >> >> -Jamie
> >> >
> >> >
> >>
> >>
> >>
> >> --
> >> Cheers,
> >> Guillaume Nodet
> >> ------------------------
> >> Blog: http://gnodet.blogspot.com/
> >> ------------------------
> >> Open Source SOA
> >> http://fusesource.com
> >
> >
>
Re: possible for compositional startup.properties?
Posted by Andreas Pieber <an...@gmail.com>.
+1 for creating JIRA issues for your problems. At worst it's not a
bug, but rather a new feature for karaf :) in addition JIRA's don't
get "lost" (compared to mails in the lst).
So IMHO +1 to go ahead and rais the issue(s).
kind regards,
andreas
On Sat, Feb 19, 2011 at 9:34 AM, Bengt Rodehav <be...@rodehav.com> wrote:
> Hello Guillaume,
> No I didn't raise a JIRA for this since I wasn't sure if this was already in
> the works or not. Also, it wasn't clear to me whether there was bug in
> custom.properties or if I had simply misunderstood the way it should work.
> Do you think I should raise a JIRA?
> /Bengt
>
> 2011/2/17 Guillaume Nodet <gn...@gmail.com>
>>
>> I think we all agree to simplify the creation of custom Karaf
>> distribution.
>> David Jenks has already done a lot of work in that direction, and
>> that's definitely on the roadmap for 3.0.
>> In the mean time, we can try to fix any bugs in the 2.2.x branch. Did
>> you raise a JIRA about your problems with custom.properties ?
>>
>> On Thu, Feb 17, 2011 at 08:25, Bengt Rodehav <be...@rodehav.com> wrote:
>> > Jamie,
>> > Yes, I also recommend using features for provisioning bundles (where
>> > possible). However, it seems like you have the same problem like me when
>> > it
>> > comes to creating a custom Karaf server. I find myself having to modify
>> > a
>> > lot of files in the Karaf distribution every time I upgrade to a new
>> > release
>> > of Karaf (startup.properties is one of them).
>> > I started a thread here about a week ago on this topic. You can read it
>> > here:
>> > http://mail-archives.apache.org/mod_mbox/karaf-user/201102.mbox/browser
>> > It started on the user list but continued on the dev list, here:
>> > http://mail-archives.apache.org/mod_mbox/karaf-dev/201102.mbox/browser
>> > I've also been trying to use custom.properties but did not succeed. I
>> > think
>> > the goal should be that all customisation of Karaf should be done
>> > outside of
>> > Karaf - i e one should not have to modify files in the Karaf
>> > distribution.
>> > For that reason extension points are needed similar to what (I think)
>> > the
>> > intention with custom.properties is.
>> > Any comments?
>> > /Bengt
>> >
>> > 2011/2/17 jamie campbell <ja...@parit.ca>
>> >>
>> >> On 11-02-16 03:05 PM, jamie campbell wrote:
>> >>>
>> >>> I've also considered that maybe Karaf doesn't do that because maybe
>> >>> one
>> >>> is supposed to take some other approach. I briefly thought maybe
>> >>> something
>> >>> using features:install would do it, but then noticed the features
>> >>> stuff
>> >>> doesn't seem to have a run level concept. The only place I've seen
>> >>> the run
>> >>> levels so far is the startup.properties.
>> >>
>> >> After Guillaume gave me another poke in the features direction I gave
>> >> it
>> >> another read through.. somehow I missed on first pass that it DOES have
>> >> start level support, described on page 41, and the ability for
>> >> automatic
>> >> load on startup, as described on page 44. A case where I RTFMed
>> >> (multiple
>> >> times), just, somehow having blind spots to the specific sections that
>> >> would
>> >> have moved me forward. I think features is (are?) indeed the magic I
>> >> seek...
>> >>
>> >> Thanks to everyone who gave me helpful pokes :)
>> >>
>> >> -Jamie
>> >
>> >
>>
>>
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>
>
Re: possible for compositional startup.properties?
Posted by Bengt Rodehav <be...@rodehav.com>.
Hello Guillaume,
No I didn't raise a JIRA for this since I wasn't sure if this was already in
the works or not. Also, it wasn't clear to me whether there was bug in
custom.properties or if I had simply misunderstood the way it should work.
Do you think I should raise a JIRA?
/Bengt
2011/2/17 Guillaume Nodet <gn...@gmail.com>
> I think we all agree to simplify the creation of custom Karaf distribution.
> David Jenks has already done a lot of work in that direction, and
> that's definitely on the roadmap for 3.0.
> In the mean time, we can try to fix any bugs in the 2.2.x branch. Did
> you raise a JIRA about your problems with custom.properties ?
>
> On Thu, Feb 17, 2011 at 08:25, Bengt Rodehav <be...@rodehav.com> wrote:
> > Jamie,
> > Yes, I also recommend using features for provisioning bundles (where
> > possible). However, it seems like you have the same problem like me when
> it
> > comes to creating a custom Karaf server. I find myself having to modify a
> > lot of files in the Karaf distribution every time I upgrade to a new
> release
> > of Karaf (startup.properties is one of them).
> > I started a thread here about a week ago on this topic. You can read it
> > here:
> > http://mail-archives.apache.org/mod_mbox/karaf-user/201102.mbox/browser
> > It started on the user list but continued on the dev list, here:
> > http://mail-archives.apache.org/mod_mbox/karaf-dev/201102.mbox/browser
> > I've also been trying to use custom.properties but did not succeed. I
> think
> > the goal should be that all customisation of Karaf should be done outside
> of
> > Karaf - i e one should not have to modify files in the Karaf
> distribution.
> > For that reason extension points are needed similar to what (I think) the
> > intention with custom.properties is.
> > Any comments?
> > /Bengt
> >
> > 2011/2/17 jamie campbell <ja...@parit.ca>
> >>
> >> On 11-02-16 03:05 PM, jamie campbell wrote:
> >>>
> >>> I've also considered that maybe Karaf doesn't do that because maybe one
> >>> is supposed to take some other approach. I briefly thought maybe
> something
> >>> using features:install would do it, but then noticed the features stuff
> >>> doesn't seem to have a run level concept. The only place I've seen the
> run
> >>> levels so far is the startup.properties.
> >>
> >> After Guillaume gave me another poke in the features direction I gave it
> >> another read through.. somehow I missed on first pass that it DOES have
> >> start level support, described on page 41, and the ability for automatic
> >> load on startup, as described on page 44. A case where I RTFMed
> (multiple
> >> times), just, somehow having blind spots to the specific sections that
> would
> >> have moved me forward. I think features is (are?) indeed the magic I
> >> seek...
> >>
> >> Thanks to everyone who gave me helpful pokes :)
> >>
> >> -Jamie
> >
> >
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
Re: possible for compositional startup.properties?
Posted by Guillaume Nodet <gn...@gmail.com>.
I think we all agree to simplify the creation of custom Karaf distribution.
David Jenks has already done a lot of work in that direction, and
that's definitely on the roadmap for 3.0.
In the mean time, we can try to fix any bugs in the 2.2.x branch. Did
you raise a JIRA about your problems with custom.properties ?
On Thu, Feb 17, 2011 at 08:25, Bengt Rodehav <be...@rodehav.com> wrote:
> Jamie,
> Yes, I also recommend using features for provisioning bundles (where
> possible). However, it seems like you have the same problem like me when it
> comes to creating a custom Karaf server. I find myself having to modify a
> lot of files in the Karaf distribution every time I upgrade to a new release
> of Karaf (startup.properties is one of them).
> I started a thread here about a week ago on this topic. You can read it
> here:
> http://mail-archives.apache.org/mod_mbox/karaf-user/201102.mbox/browser
> It started on the user list but continued on the dev list, here:
> http://mail-archives.apache.org/mod_mbox/karaf-dev/201102.mbox/browser
> I've also been trying to use custom.properties but did not succeed. I think
> the goal should be that all customisation of Karaf should be done outside of
> Karaf - i e one should not have to modify files in the Karaf distribution.
> For that reason extension points are needed similar to what (I think) the
> intention with custom.properties is.
> Any comments?
> /Bengt
>
> 2011/2/17 jamie campbell <ja...@parit.ca>
>>
>> On 11-02-16 03:05 PM, jamie campbell wrote:
>>>
>>> I've also considered that maybe Karaf doesn't do that because maybe one
>>> is supposed to take some other approach. I briefly thought maybe something
>>> using features:install would do it, but then noticed the features stuff
>>> doesn't seem to have a run level concept. The only place I've seen the run
>>> levels so far is the startup.properties.
>>
>> After Guillaume gave me another poke in the features direction I gave it
>> another read through.. somehow I missed on first pass that it DOES have
>> start level support, described on page 41, and the ability for automatic
>> load on startup, as described on page 44. A case where I RTFMed (multiple
>> times), just, somehow having blind spots to the specific sections that would
>> have moved me forward. I think features is (are?) indeed the magic I
>> seek...
>>
>> Thanks to everyone who gave me helpful pokes :)
>>
>> -Jamie
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: possible for compositional startup.properties?
Posted by jamie campbell <ja...@parit.ca>.
On 11-02-17 01:25 AM, Bengt Rodehav wrote:
> Jamie,
>
> Yes, I also recommend using features for provisioning bundles (where
> possible). However, it seems like you have the same problem like me
> when it comes to creating a custom Karaf server. I find myself having
> to modify a lot of files in the Karaf distribution every time I
> upgrade to a new release of Karaf (startup.properties is one of them).
startup.properties and my pom.xml are the two that I have to change.. I
haven't customized any of the other files (although it looks like I'll
be customizing the features.cfg file now) so they haven't been an
issue. I don't think that in my case that's avoidable (for now) though
: my custom build has the somewhat unfortunate side effect of having a
different deploy structure, for instance karaf 2.1.3 has
system/org/apache/aries/blueprint/org.apache.aries.blueprint/0.2-incubating/org.apache.aries.blueprint-0.2-incubating.jar
where as mine would be
system/org.apache.aries.blueprint/org.apache.aries.blueprint/0.2-incubating/org.apache.aries.blueprint-0.2-incubating.jar
because my assembly bin file uses group id and artifact id. I have it
this way because it makes for a very simple bin file, and overriding the
convention makes it a much bigger creature, but I may change it in
future to help make upgrades easier. For now though, ease of
comprehension in bringing new developers on board is more important than
how much work I need to do behind the scenes for transitions. so a very
simple assembly bin (and other files also being simple) is important.
>
> I started a thread here about a week ago on this topic. You can read
> it here:
>
> http://mail-archives.apache.org/mod_mbox/karaf-user/201102.mbox/browser
>
> It started on the user list but continued on the dev list, here:
>
> http://mail-archives.apache.org/mod_mbox/karaf-dev/201102.mbox/browser
Seems like good ideas are flowing. JB mentioned that some JIRA posts
related to the thread will be added at some point, I look forward to
reading them.
>
> I've also been trying to use custom.properties but did not succeed. I
> think the goal should be that all customisation of Karaf should be
> done outside of Karaf - i e one should not have to modify files in the
> Karaf distribution. For that reason extension points are needed
> similar to what (I think) the intention with custom.properties is.
I join Andreas in agreeing :)
-Jamie
Re: possible for compositional startup.properties?
Posted by Bengt Rodehav <be...@rodehav.com>.
Jamie,
Yes, I also recommend using features for provisioning bundles (where
possible). However, it seems like you have the same problem like me when it
comes to creating a custom Karaf server. I find myself having to modify a
lot of files in the Karaf distribution every time I upgrade to a new release
of Karaf (startup.properties is one of them).
I started a thread here about a week ago on this topic. You can read it
here:
http://mail-archives.apache.org/mod_mbox/karaf-user/201102.mbox/browser
It started on the user list but continued on the dev list, here:
http://mail-archives.apache.org/mod_mbox/karaf-dev/201102.mbox/browser
I've also been trying to use custom.properties but did not succeed. I think
the goal should be that all customisation of Karaf should be done outside of
Karaf - i e one should not have to modify files in the Karaf distribution.
For that reason extension points are needed similar to what (I think) the
intention with custom.properties is.
Any comments?
/Bengt
2011/2/17 jamie campbell <ja...@parit.ca>
> On 11-02-16 03:05 PM, jamie campbell wrote:
>
>>
>> I've also considered that maybe Karaf doesn't do that because maybe one is
>> supposed to take some other approach. I briefly thought maybe something
>> using features:install would do it, but then noticed the features stuff
>> doesn't seem to have a run level concept. The only place I've seen the run
>> levels so far is the startup.properties.
>>
>
> After Guillaume gave me another poke in the features direction I gave it
> another read through.. somehow I missed on first pass that it DOES have
> start level support, described on page 41, and the ability for automatic
> load on startup, as described on page 44. A case where I RTFMed (multiple
> times), just, somehow having blind spots to the specific sections that would
> have moved me forward. I think features is (are?) indeed the magic I
> seek...
>
> Thanks to everyone who gave me helpful pokes :)
>
> -Jamie
>
Re: possible for compositional startup.properties?
Posted by jamie campbell <ja...@parit.ca>.
On 11-02-16 03:05 PM, jamie campbell wrote:
>
> I've also considered that maybe Karaf doesn't do that because maybe
> one is supposed to take some other approach. I briefly thought maybe
> something using features:install would do it, but then noticed the
> features stuff doesn't seem to have a run level concept. The only
> place I've seen the run levels so far is the startup.properties.
After Guillaume gave me another poke in the features direction I gave it
another read through.. somehow I missed on first pass that it DOES have
start level support, described on page 41, and the ability for automatic
load on startup, as described on page 44. A case where I RTFMed
(multiple times), just, somehow having blind spots to the specific
sections that would have moved me forward. I think features is (are?)
indeed the magic I seek...
Thanks to everyone who gave me helpful pokes :)
-Jamie
Re: possible for compositional startup.properties?
Posted by Guillaume Nodet <gn...@gmail.com>.
Why don't you use features in order to provision all those bundles ?
On Wed, Feb 16, 2011 at 23:34, jamie campbell <ja...@parit.ca> wrote:
> On 11-02-16 04:17 PM, David Jencks wrote:
>>
>> I could use more details.... and I'm not entirely sure of what karaf does
>> now either, and am thinking mostly about what I'd like it to do soon to
>> solve this kind of problem :-)
>
> Sure : I have my own build system creating what I've called karafcore, in
> conjunction with mvn assembly:assembly. It has the etc directory, which has
> startup.properties (and the other files such as config.properties,
> custom.properties, etc). The pom file has dependencies corresponding to all
> the stuff started in startup.properties.
>
> I have a subdirectory called alternateBuilds, which has one subdirectory for
> each "type" of system I'm constructing. One for poking around with jpa.
> One for poking around with configadmin. Etc etc. In general, each
> alternate build aims to be the simplest it can be, focusing on its small
> core purpose. Each of these subdirectories has a pom.xml, for the
> dependencies, and a startup.properties file, for the bundles to start.
> Refactoring the pom part is pretty clear, the startup.properties is the
> hard bit. Right now, all of the startup.properties files have 30 bundles
> worth of exact duplication, followed by startup at run-level > 50 for
> whatever sort of extension they're aiming at. The extension portion is
> usually a very small handful of bundles, although sometimes more.
>
> I could solve the problem with some sort of shell script to manually
> concatenate core bits to extension bits each time I swap between alternate
> systems, I was just hoping karaf (or osgi; or felix; or maven; or java
> itself; whichever level of technology makes the most sense) would have a
> better approach, particularly since a shell script based approach will grow
> increasingly complex as the alternate builds progress to a level where they
> are themselves composed of other alternate builds plus core (like, a build
> with configadmin functionality that also uses JPA and has some gui
> extensions, or some such).
>
> -Jamie
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: possible for compositional startup.properties?
Posted by jamie campbell <ja...@parit.ca>.
On 11-02-16 04:17 PM, David Jencks wrote:
> I could use more details.... and I'm not entirely sure of what karaf does now either, and am thinking mostly about what I'd like it to do soon to solve this kind of problem :-)
Sure : I have my own build system creating what I've called karafcore,
in conjunction with mvn assembly:assembly. It has the etc directory,
which has startup.properties (and the other files such as
config.properties, custom.properties, etc). The pom file has
dependencies corresponding to all the stuff started in startup.properties.
I have a subdirectory called alternateBuilds, which has one subdirectory
for each "type" of system I'm constructing. One for poking around with
jpa. One for poking around with configadmin. Etc etc. In general, each
alternate build aims to be the simplest it can be, focusing on its small
core purpose. Each of these subdirectories has a pom.xml, for the
dependencies, and a startup.properties file, for the bundles to start.
Refactoring the pom part is pretty clear, the startup.properties is the
hard bit. Right now, all of the startup.properties files have 30
bundles worth of exact duplication, followed by startup at run-level >
50 for whatever sort of extension they're aiming at. The extension
portion is usually a very small handful of bundles, although sometimes
more.
I could solve the problem with some sort of shell script to manually
concatenate core bits to extension bits each time I swap between
alternate systems, I was just hoping karaf (or osgi; or felix; or maven;
or java itself; whichever level of technology makes the most sense)
would have a better approach, particularly since a shell script based
approach will grow increasingly complex as the alternate builds progress
to a level where they are themselves composed of other alternate builds
plus core (like, a build with configadmin functionality that also uses
JPA and has some gui extensions, or some such).
-Jamie
Re: possible for compositional startup.properties?
Posted by David Jencks <da...@yahoo.com>.
I could use more details.... and I'm not entirely sure of what karaf does now either, and am thinking mostly about what I'd like it to do soon to solve this kind of problem :-)
On Feb 16, 2011, at 1:05 PM, jamie campbell wrote:
> On 11-02-16 02:20 PM, David Jencks wrote:
>> Do you need this in ability for different flavors in one karaf instance or would you be just as happy to assemble separate karaf instances for each purpose?
>>
>> thanks
>> david jencks
>
> Right now the approach is separate assemblage, which has been fine, I'm just getting discontent with the large amounts of replication. When core startup bundles change because I've upgraded something, it would be good to change just the core file rather than having to redo all core changes for every purpose.
My thinking about assemblies uses the stuff I added in trunk to put stuff in kar files and assemble the server out of kar files. (I don't think this process is complete in relation to how startup.properties might be assembled) Using this approach I'd the versions of the core bundles would be specified in single a kar project pom, and rebuilding that project and the karaf assembly projects would result in a complete set of upgraded servers. How does this relate to what you are doing?
>
> I've also considered that maybe Karaf doesn't do that because maybe one is supposed to take some other approach. I briefly thought maybe something using features:install would do it, but then noticed the features stuff doesn't seem to have a run level concept. The only place I've seen the run levels so far is the startup.properties.
I think you can now specify start level for bundles in a feature. I don't think the feature itself has a start level concept.
>
> I was peeking through the source code and thought I found the solution in a comment at org/apache/karaf/main/Main:545-551.. I thought I read that in config.properties I could specify multiple files (space separated) for the config.properties karaf.auto.start , but got array index out of bounds type exceptions when I tried to do so. Another read of the comment implied maybe it's actually talking about the bundles IN the auto.start specified file rather than the specifier line itself. If my interpretation had been correct, it would have been a fully acceptable solution, allowing modularity without requiring new syntax in the property files themselves.
>
> On that note, I realize now that the possible approach in my original post is kind of silly if karaf is using standard java property files, because I think they have to adhere to the format enumerated in http://download.oracle.com/javase/6/docs/api/java/util/Properties.html#load%28java.io.Reader%29 , which has no compositional support of the type I was mentioning.
>
> Still, despite the erroneous nature of the "possible solution" I mentioned, my original need remains :)
I don't think I fully understand what you actually need to do. A couple possibilities I can think of...
- have a really easy and completely non-redundant way to assemble a lot of custom karaf assemblies, each of which works for exactly one scenario (I hope the packaging stuff I did in trunk can be polished up to do this)
- have a single karaf server that can easily shifted from one purpose to another, perhaps by starting with a command line "profile name"
thanks
david jencks
>
> -Jamie
Re: possible for compositional startup.properties?
Posted by jamie campbell <ja...@parit.ca>.
On 11-02-16 02:20 PM, David Jencks wrote:
> Do you need this in ability for different flavors in one karaf instance or would you be just as happy to assemble separate karaf instances for each purpose?
>
> thanks
> david jencks
Right now the approach is separate assemblage, which has been fine, I'm
just getting discontent with the large amounts of replication. When
core startup bundles change because I've upgraded something, it would be
good to change just the core file rather than having to redo all core
changes for every purpose.
I've also considered that maybe Karaf doesn't do that because maybe one
is supposed to take some other approach. I briefly thought maybe
something using features:install would do it, but then noticed the
features stuff doesn't seem to have a run level concept. The only place
I've seen the run levels so far is the startup.properties.
I was peeking through the source code and thought I found the solution
in a comment at org/apache/karaf/main/Main:545-551.. I thought I read
that in config.properties I could specify multiple files (space
separated) for the config.properties karaf.auto.start , but got array
index out of bounds type exceptions when I tried to do so. Another read
of the comment implied maybe it's actually talking about the bundles IN
the auto.start specified file rather than the specifier line itself. If
my interpretation had been correct, it would have been a fully
acceptable solution, allowing modularity without requiring new syntax in
the property files themselves.
On that note, I realize now that the possible approach in my original
post is kind of silly if karaf is using standard java property files,
because I think they have to adhere to the format enumerated in
http://download.oracle.com/javase/6/docs/api/java/util/Properties.html#load%28java.io.Reader%29
, which has no compositional support of the type I was mentioning.
Still, despite the erroneous nature of the "possible solution" I
mentioned, my original need remains :)
-Jamie
Re: possible for compositional startup.properties?
Posted by David Jencks <da...@yahoo.com>.
Do you need this in ability for different flavors in one karaf instance or would you be just as happy to assemble separate karaf instances for each purpose?
thanks
david jencks
On Feb 16, 2011, at 9:56 AM, jamie campbell wrote:
> Hi,
>
> I'm wondering if it's possible to have a compositional etc/startup.properties in the same way one can have a compositional pom (well, maybe pom is a bad comparison because I don't need repository sync ability or any of the other fancy things a pom can do with regards to composition). My use case is that I'd like to have a core set of startup bits, and from that extensional startup bits that vary from one scenario to another, so it would be sweet if I could do something like
>
> ------------
> import base/base_startup.properties
>
> org/specificUseCase/specificUseCase.jar=51
> org/anothercase/another.jar=52
> ------------
>
> -Jamie
Re: possible for compositional startup.properties?
Posted by jamie campbell <ja...@parit.ca>.
On 11-02-16 03:01 PM, Jean-Baptiste Onofré wrote:
> Doesn't it look like a kind of profile ? :)
>
> Without joke, the fact to define a specific behavior for a given Karaf
> instance could be a profile.
I've been kind of letting the manual in the distribution itself guide
me, and the only reference I find there to profile is the verb rather
than the noun. Expanding my search further, to the Karaf site, still no
luck. I found reference in r4.core.pdf from the specifications site,
but, only very briefly, and I got the impression that it's used to mess
with the jvm itself. It also said that the bundle itself has to specify
profile, which would be the opposite direction from what I want. I also
looked at the r4 compendium and r4.enterprise, didn't find it there.
Then I peeked at maven, which does have the concept of profile, but
doesn't really help me : I have lots of techniques available for
composition and specification on the pom side, not just profiles but
also techniques of aggregation or inheritance, many of which would lead
to decent clean-ness on the dependency specification side. But the
problem is after that, specifying startup order...
Apologies if there's a karaf take on profile that I couldn't find. If
so, could you provide a link to The Fine Manual for me to Read? :)
>
> I planned to add a section in the roadmap wiki page to distinguish:
> - usage of features
> - usage of kar
> - the karaf profile background
>
I think I'm getting to the roadmap incorrectly too, I get a 404...
> Anyway Jamie, your proposal is interesting. Did you try to use the
> etc/custom.properties for that ? The custom.properties file has been
> introduced especially for custom configuration of a Karaf instance.
I peeked at it but from what I understand it's for overriding already
existing properties (since the system wouldn't know how to use unknown
properties), and I'm ok with startup.properties being, at least, one of
the files that is parsed to start bundles. Which means whether I set
the property in custom.properties or config.properties, the result is
the same..
-Jamie
Re: possible for compositional startup.properties?
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Doesn't it look like a kind of profile ? :)
Without joke, the fact to define a specific behavior for a given Karaf
instance could be a profile.
I planned to add a section in the roadmap wiki page to distinguish:
- usage of features
- usage of kar
- the karaf profile background
Anyway Jamie, your proposal is interesting. Did you try to use the
etc/custom.properties for that ? The custom.properties file has been
introduced especially for custom configuration of a Karaf instance.
Regards
JB
On 02/16/2011 06:56 PM, jamie campbell wrote:
> Hi,
>
> I'm wondering if it's possible to have a compositional
> etc/startup.properties in the same way one can have a compositional pom
> (well, maybe pom is a bad comparison because I don't need repository
> sync ability or any of the other fancy things a pom can do with regards
> to composition). My use case is that I'd like to have a core set of
> startup bits, and from that extensional startup bits that vary from one
> scenario to another, so it would be sweet if I could do something like
>
> ------------
> import base/base_startup.properties
>
> org/specificUseCase/specificUseCase.jar=51
> org/anothercase/another.jar=52
> ------------
>
> -Jamie