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 <[email protected]> > +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 <[email protected]> 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 <[email protected]> > >> > >> 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 <[email protected]> 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 <[email protected]> > >> >> > >> >> 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 > > > > >
