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 <[email protected] <mailto:[email protected]>>
Thanks Bengt for your complete feedback. I'm gonna raise some Jiras
about that.
Regards
JB
------------------------------------------------------------------------
*From: * Bengt Rodehav <[email protected] <mailto:[email protected]>>
*Sender: * [email protected] <mailto:[email protected]>
*Date: *Sat, 12 Feb 2011 16:57:38 +0100
*To: *<[email protected] <mailto:[email protected]>>;
<[email protected] <mailto:[email protected]>>
*ReplyTo: * [email protected] <mailto:[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] <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
