Btw, that was https://issues.apache.org/jira/browse/KARAF-110 which has been fixed last year. There is certainly room for improvements though as maybe not all use cases are solved yet.
On Sun, Feb 13, 2011 at 10:02, Guillaume Nodet <[email protected]> wrote: > I'd like us to double check why the etc/custom.properties isn't > sufficient, as that was the exact goal, i.e. an empty placeholder > where one could easily define any overriden properties. So we may > want to improve / fix any problem there first > > On Sun, Feb 13, 2011 at 08:45, <[email protected]> wrote: >> Quick update regarding your latest e-mail. I propose to upgrade the karaf >> scripts (in the bin directory) to be able to read a file in the etc >> directory (for instance etc/karaf.rc) in which you can put several custom >> configuration (window title on windows, java options, karaf home, instances >> name, etc). I have to think deeper about that but defintely it makes sense. >> We already extended the branding.properties to allow users to customize the >> karaf prompt in addition of the welcome message, so it's the same area of >> customization. >> >> Regards >> JB >> ________________________________ >> From: Bengt Rodehav <[email protected]> >> Sender: [email protected] >> Date: Sat, 12 Feb 2011 20:11:45 +0100 >> To: <[email protected]>; <[email protected]> >> Subject: Re: Problems with features startlevel >> You're welcome. I think Karaf is an extremely versatile deployment platform >> and I gladly contribute. >> BTW, I haven't looked at exactly how ServiceMix customizes Karaf but I >> imagine they customize quite a lot. A good criteria for good customisation >> support might be when ServiceMix can use a new version of Karaf without >> changing any of the files packaged with Karaf... >> /Bengt >> >> 2011/2/12 <[email protected]> >>> >>> Thanks Bengt for your complete feedback. I'm gonna raise some Jiras about >>> that. >>> >>> Regards >>> JB >>> ________________________________ >>> From: Bengt Rodehav <[email protected]> >>> Sender: [email protected] >>> Date: Sat, 12 Feb 2011 16:57:38 +0100 >>> To: <[email protected]>; <[email protected]> >>> ReplyTo: [email protected] >>> Subject: Re: Problems with features startlevel >>> Hello JB and Andreas, >>> Just read the documentation about "custom distribution". Good >>> documentation. It is very close to the way I handle things today. What I >>> would like to avoid, however, is, e g having to edit >>> system.properties/startup.properties everytime I upgrade to a new version of >>> Karaf. I would prefer to keep them intact and instead put my custom system >>> properties in a "custom_system.properties" and my extra bundles in a >>> "custom_startup.properties", and so on. Why not one extra level of >>> indirection? Karaf could allow the user to specify (e g in >>> karaf-custom.cfg...) in what additional locations Karaf should look for >>> additional system properties, additional bundles to load at startup etc. >>> Then it's the actual launching of Karaf. Presently I have to customise >>> karaf.bat, karaf-service.bat and karaf-wrapper.conf. I would like those >>> existing files to be more customisable/brandable so that I don't have to >>> modify the Karaf distribution at all. In production, I use the wrapper >>> service which doesn't come "unpacked" with Karaf. When I download a new >>> version of Karaf I have to install it, start it and finally install the >>> wrapper service. Then I have a base for customisation since until then I >>> didn't even have access to the wrapper files bundled with Karaf. >>> In summary I think that the goal with a customised server should be that >>> all customisation (within reasonable limits) should be possible to do >>> without modifying any files that come with the Karaf distribution. My >>> customisation should solely exist of files that I add to Karaf and therefore >>> do normally not need to be updated with every new Karaf version. >>> Personally I need to customise the following ("my reasonable limits"?): >>> - Console title >>> - Windows service title/name/display name/description >>> - Memory requirements (-Xmx and -XX:MaxPermSize) >>> - Define system properties on the command line (-D) >>> - Probably need to customise the entire java command line since I might >>> want to override parameters that are set by the Karaf distribution (e g the >>> Derby data directory) >>> - KARAF_HOME/KARAF_BASE (when running as a service) >>> - Wrapper log configuration (the normal logging is specified >>> in org.ops4j.pax.logging.cfg in which case I use my own version) >>> - What features to install. I use my own org.apache.karaf.features.cfg >>> which is fine. >>> - What ports to use. The reason is that we must allow more than one Karaf >>> installation on the same server (e g production and test). Presently I >>> therefore modify org.apache.karaf.management.cfg, org.ops4j.pax.web.cfg >>> and org.apache.karaf.shell.cfg where I replace the ports with property >>> placeholders that I filter with maven-assembly-plugin. >>> - Additional bundles to load at startup (the reason why I started this >>> thread on the mailing list) which I now have to add in startup.properties. >>> /Bengt >>> >>> >>> >>> 2011/2/12 <[email protected]> >>>> >>>> Hi Bengt, >>>> >>>> I've added documentation about custom distriubtion yesterday. >>>> Anyway, there is an open discussion about Karaf profiles, still in >>>> brainstorming mode ;) >>>> >>>> Regards >>>> JB >>>> ________________________________ >>>> From: Bengt Rodehav <[email protected]> >>>> Sender: [email protected] >>>> Date: Sat, 12 Feb 2011 09:18:46 +0100 >>>> To: <[email protected]> >>>> ReplyTo: [email protected] >>>> Subject: Re: Problems with features startlevel >>>> Good morning Guillaume, >>>> Hope you got a few hours of sleep anyway. I'm also in GMT+1 (Stockholm) >>>> and sleep too little but I'm not quite in your class.. >>>> I've seen a conversation in the Karaf forums where you've discussed how >>>> to create custom servers more easily. That's a very interesting topic for >>>> me. Ideally I would like to take a standard Karaf installation without >>>> really having to modify any of the files but just add my custom >>>> configuration. That way it would be so much easier to upgrade Karaf >>>> versions. So, not wanting to edit startup.properties stem from that desire. >>>> Things I would like to customize (with extension points, not by modifying >>>> Karaf standard installation) are, among others: >>>> - All names that are visible: title, NT service title and description... >>>> - Memory requirements >>>> - Other java options, especially system properties >>>> - The use of environment variables to determine where I put my data (log, >>>> Derby, configuration, etc). I don't want to have this as part of the Karaf >>>> installation since it makes upgrades much harder. >>>> - Bundles to load at startup (startup.properties) >>>> - Features to install. Here I actually just >>>> overwrite org.apache.karaf.features.cfg with my own which I think is OK. >>>> There are probably a few more things that I customize that I can't recall >>>> just now. However, upgrading the Karaf version is a lot of work which is >>>> why >>>> I would really like it to be easier to customize the installation. Have you >>>> had any more discussions on this topic? >>>> /Bengt >>>> >>>> 2011/2/12 Guillaume Nodet <[email protected]> >>>>> >>>>> On Sat, Feb 12, 2011 at 00:38, Bengt Rodehav <[email protected]> wrote: >>>>> > Ok, thanks. Is there know way to avoid having to modify >>>>> > startup.properties >>>>> > then? >>>>> >>>>> Not really at startup. I think after a restart, things are different >>>>> as the cglib bundle is already installed and should be used by the >>>>> framework. >>>>> >>>>> > (Do you never sleep or are we in different time zones?) >>>>> >>>>> GMT +1, and not much / enough sleep unfortunately ;-) >>>>> >>>>> > Den 12 feb 2011 00.15 skrev "Guillaume Nodet" <[email protected]>: >>>>> > >>>>> >>>>> >>>>> >>>>> -- >>>>> Cheers, >>>>> Guillaume Nodet >>>>> ------------------------ >>>>> Blog: http://gnodet.blogspot.com/ >>>>> ------------------------ >>>>> Open Source SOA >>>>> http://fusesource.com >>>> >>> >> >> > > > > -- > Cheers, > Guillaume Nodet > ------------------------ > Blog: http://gnodet.blogspot.com/ > ------------------------ > Open Source SOA > http://fusesource.com > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
