You can use it to "partial" override attributes of config.properties
where for example karaf.auto.start=startup.properties
is configured.
Following "documentation" I found in the code:
// The auto-start property specifies a space-delimited list of
// bundle URLs to be automatically installed and started into each
// new profile; the start level to which the bundles are assigned
// is specified by appending a ".n" to the auto-start property name,
// where "n" is the desired start level for the list of bundles.
// The following code starts bundles in one pass, installing bundles
// for a given level, then starting them, then moving to the
next level.
so this is the property you need to "extend" by adding your own
system.properties file
Regards, Achim
> OK - will look into custom.properties. Actually I tried that a while
> back, trying to get my custom system properties configured that way
> but didn't succeed. Is custom.properties used for listing additional
> bundles to start (an extension to startup.properties) or is it used
> for defining system properties (an extension to system.properties)?
>
> /Bengt
>
>
> 2011/2/12 Guillaume Nodet <[email protected] <mailto:[email protected]>>
>
> 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 <[email protected]
> <mailto:[email protected]>> 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 <[email protected] <mailto:[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] <mailto:[email protected]>>
> >> Sender: [email protected] <mailto:[email protected]>
> >> Date: Sat, 12 Feb 2011 09:18:46 +0100
> >> To: <[email protected] <mailto:[email protected]>>
> >> ReplyTo: [email protected] <mailto:[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]
> <mailto:[email protected]>>
> >>>
> >>> On Sat, Feb 12, 2011 at 00:38, Bengt Rodehav
> <[email protected] <mailto:[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] <mailto:[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
>
>
