Re: Problems with features startlevel
The etc/custom.properties is empty and is a placeholder for any override you may need. Try using it to put all your custom properties and see how it goes. On Sat, Feb 12, 2011 at 16:57, Bengt Rodehav be...@rodehav.com wrote: 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 j...@nanthrax.net 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 be...@rodehav.com Sender: bengt.rode...@gmail.com Date: Sat, 12 Feb 2011 09:18:46 +0100 To: user@karaf.apache.org ReplyTo: user@karaf.apache.org 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
Re: Problems with features startlevel
Indeed, As mentioned in the Custom Distribution documentation chapter, I referenced some custom distribution examples, such as ServiceMix. Regards JB On 02/12/2011 08:11 PM, Bengt Rodehav wrote: 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 j...@nanthrax.net mailto:j...@nanthrax.net Thanks Bengt for your complete feedback. I'm gonna raise some Jiras about that. Regards JB *From: * Bengt Rodehav be...@rodehav.com mailto:be...@rodehav.com *Sender: * bengt.rode...@gmail.com mailto:bengt.rode...@gmail.com *Date: *Sat, 12 Feb 2011 16:57:38 +0100 *To: *user@karaf.apache.org mailto:user@karaf.apache.org; j...@nanthrax.net mailto:j...@nanthrax.net *ReplyTo: * user@karaf.apache.org mailto:user@karaf.apache.org *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 j...@nanthrax.net mailto:j...@nanthrax.net 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 be...@rodehav.com mailto:be...@rodehav.com *Sender: * bengt.rode...@gmail.com mailto:bengt.rode...@gmail.com *Date: *Sat, 12 Feb 2011 09:18:46 +0100 *To: *user@karaf.apache.org mailto:user@karaf.apache.org *ReplyTo: * user@karaf.apache.org mailto:user@karaf.apache.org *Subject: *Re: Problems with features startlevel
Re: Problems with features startlevel
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 -Original Message- From: Bengt Rodehav be...@rodehav.com Sender: bengt.rode...@gmail.com Date: Sat, 12 Feb 2011 20:11:45 To: user@karaf.apache.org; j...@nanthrax.net 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 j...@nanthrax.net Thanks Bengt for your complete feedback. I'm gonna raise some Jiras about that. Regards JB -- *From: * Bengt Rodehav be...@rodehav.com *Sender: * bengt.rode...@gmail.com *Date: *Sat, 12 Feb 2011 16:57:38 +0100 *To: *user@karaf.apache.org; j...@nanthrax.net *ReplyTo: * user@karaf.apache.org *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 j...@nanthrax.net 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 be...@rodehav.com *Sender: * bengt.rode...@gmail.com *Date: *Sat, 12 Feb 2011 09:18:46 +0100 *To: *user@karaf.apache.org *ReplyTo: * user@karaf.apache.org *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
