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 discussions on this topic?
>> /Bengt
>>
>> 2011/2/12 Guillaume Nodet <gno...@gmail.com>
>>>
>>> On Sat, Feb 12, 2011 at 00:38, Bengt Rodehav <be...@rodehav.com> 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" <gno...@gmail.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

Reply via email to