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
