You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@karaf.apache.org by Bengt Rodehav <be...@rodehav.com> on 2011/02/11 23:07:09 UTC
Problems with features startlevel
I'm using Karaf 2.1.3 together with Aries (0.2-incubating). I get the
following exception:
*2011-02-11 22:55:54,787 | ERROR | rint Extender: 3 | ServiceRecipe
> | lueprint.container.ServiceRecipe 284 | Error retrieving
> service from ServiceRecipe[name='.component-2']
> org.osgi.service.blueprint.container.ComponentDefinitionException:
> Interceptors have been configured but neither asm nor cglib are available
> at
> org.apache.aries.blueprint.container.BeanRecipe.addInterceptors(BeanRecipe.java:694)
> at
> org.apache.aries.blueprint.container.BeanRecipe.internalCreate(BeanRecipe.java:748)
> at
> org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:64)
> at
> org.apache.aries.blueprint.di.RefRecipe.internalCreate(RefRecipe.java:60)
> at
> org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:64)
> at
> org.apache.aries.blueprint.container.BlueprintRepository.createInstances(BlueprintRepository.java:219)
> at
> org.apache.aries.blueprint.container.BlueprintRepository.createInstance(BlueprintRepository.java:198)
> at
> org.apache.aries.blueprint.container.BlueprintRepository.create(BlueprintRepository.java:137)
> at
> org.apache.aries.blueprint.container.ServiceRecipe.createRecipe(ServiceRecipe.java:352)[7:org.apache.aries.blueprint:0.2.0.incubating]
> at
> org.apache.aries.blueprint.container.ServiceRecipe.createService(ServiceRecipe.java:260)[7:org.apache.aries.blueprint:0.2.0.incubating]
> at
> org.apache.aries.blueprint.container.ServiceRecipe.internalGetService(ServiceRecipe.java:230)[7:org.apache.aries.blueprint:0.2.0.incubating]
> at
> org.apache.aries.blueprint.container.ServiceRecipe.getService(ServiceRecipe.java:309)[7:org.apache.aries.blueprint:0.2.0.incubating]
> at
> org.apache.aries.blueprint.container.ServiceRecipe$TriggerServiceFactory.getService(ServiceRecipe.java:367)
> at
> org.apache.felix.framework.ServiceRegistrationImpl.getFactoryUnchecked(ServiceRegistrationImpl.java:307)
> at
> org.apache.felix.framework.ServiceRegistrationImpl.getService(ServiceRegistrationImpl.java:221)
> at
> org.apache.felix.framework.ServiceRegistry.getService(ServiceRegistry.java:295)[org.apache.felix.framework-3.0.2.jar:]
> at
> org.apache.felix.framework.Felix.getService(Felix.java:3007)[org.apache.felix.framework-3.0.2.jar:]
> at
> org.apache.felix.framework.BundleContextImpl.getService(BundleContextImpl.java:329)[org.apache.felix.framework-3.0.2.jar:]
> at org.apache.felix.ipojo.IPojoContext.getService(IPojoContext.java:260)
> at org.apache.felix.ipojo.util.Tracker.getService(Tracker.java:441)
> at
> org.apache.felix.ipojo.util.DependencyModel.getService(DependencyModel.java:911)[46:org.apache.felix.ipojo:1.6.8]
> at
> org.apache.felix.ipojo.handlers.dependency.Dependency.createServiceObject(Dependency.java:638)
> at
> org.apache.felix.ipojo.handlers.dependency.Dependency.onGet(Dependency.java:609)
> at
> org.apache.felix.ipojo.InstanceManager.onGet(InstanceManager.java:960)[46:org.apache.felix.ipojo:1.6.8]
> ...*
Apparently cglib is resolved too late. When I get the above exception I use
the following in my features repo:
* <feature name="connect-aries" version="1.1.0-SNAPSHOT">
> <bundle
> start-level="40">mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.cglib/2.1_3_4</bundle>
> ...*
The "connect-aries" features is listed in my org.apache.karaf.features.cfg.
However, if I instead add the following line to the end of my
startup.properties file then it works perfectly:
*
> org/apache/servicemix/bundles/org.apache.servicemix.bundles.cglib/2.1_3_4/org.apache.servicemix.bundles.cglib-2.1_3_4.jar=40
> *
Why is there a diffence? I'm trying to get rid of the line in
startup.properties in order to mess as little as possible with the Karaf
standard installation.
/Bengt
Re: Problems with features startlevel
Posted by Andreas Pieber <an...@gmail.com>.
Hey Bengt,
On Sat, Feb 12, 2011 at 09:18:46AM +0100, Bengt Rodehav wrote:
> 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:
Absolutely +1
>
> - All names that are visible: title, NT service title and
> description...
You mean the branding at the startup?
> - Memory requirements
This is already possible for unix using system variable (export) but not for
windows and not for all possible memory settings; or do you mean by a config file?
(Maybe we can use something like source in our scripts?)
>
> - Other java options, especially system properties
This is possible for karaf-2.2.x and above via export KARAF_OPTS. Or again, do
you mean via a configuration file? (again something like source can be an option
here)
> - 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.
Typically you can easily adapt this via different configuration files in etc/.
I'm not sure if I can imagaine what you have in mind here
> - Bundles to load at startup (startup.properties)
AFAIK this is possible via a custom.properties file
> - Features to install. Here I actually just
> overwrite org.apache.karaf.features.cfg with my own which I think is
> OK.
I'm also of the opinion that this 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?
Not sure, but now we have ;)
kind regards
andreas
>
> /Bengt
> 2011/2/12 Guillaume Nodet <[1...@gmail.com>
>
> On Sat, Feb 12, 2011 at 00:38, Bengt Rodehav <[2...@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" <[3...@gmail.com>:
> >
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: [4]http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> [5]http://fusesource.com
>
> References
>
> 1. mailto:gnodet@gmail.com
> 2. mailto:bengt@rodehav.com
> 3. mailto:gnodet@gmail.com
> 4. http://gnodet.blogspot.com/
> 5. http://fusesource.com/
Re: Problems with features startlevel
Posted by Achim Nierbeck <bc...@googlemail.com>.
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 <gnodet@gmail.com <ma...@gmail.com>>
>
> 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 <bengt@rodehav.com
> <ma...@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 <jb@nanthrax.net <ma...@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 <bengt@rodehav.com <ma...@rodehav.com>>
> >> Sender: bengt.rodehav@gmail.com <ma...@gmail.com>
> >> Date: Sat, 12 Feb 2011 09:18:46 +0100
> >> To: <user@karaf.apache.org <ma...@karaf.apache.org>>
> >> ReplyTo: user@karaf.apache.org <ma...@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 <gnodet@gmail.com
> <ma...@gmail.com>>
> >>>
> >>> On Sat, Feb 12, 2011 at 00:38, Bengt Rodehav
> <bengt@rodehav.com <ma...@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"
> <gnodet@gmail.com <ma...@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
>
>
Re: Problems with features startlevel
Posted by Bengt Rodehav <be...@rodehav.com>.
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 <gn...@gmail.com>
> 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 <jb...@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.rodehav@gmail.com
> >> Date: Sat, 12 Feb 2011 09:18:46 +0100
> >> To: <us...@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 <gn...@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" <gn...@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
>
Re: Problems with features startlevel
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <jb...@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.rodehav@gmail.com
>> Date: Sat, 12 Feb 2011 09:18:46 +0100
>> To: <us...@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 <gn...@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" <gn...@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
Re: Problems with features startlevel
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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 <jb@nanthrax.net <ma...@nanthrax.net>>
>
> Thanks Bengt for your complete feedback. I'm gonna raise some Jiras
> about that.
>
>
> Regards
> JB
> ------------------------------------------------------------------------
> *From: * Bengt Rodehav <bengt@rodehav.com <ma...@rodehav.com>>
> *Sender: * bengt.rodehav@gmail.com <ma...@gmail.com>
> *Date: *Sat, 12 Feb 2011 16:57:38 +0100
> *To: *<user@karaf.apache.org <ma...@karaf.apache.org>>;
> <jb@nanthrax.net <ma...@nanthrax.net>>
> *ReplyTo: * user@karaf.apache.org <ma...@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 <jb@nanthrax.net <ma...@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 <bengt@rodehav.com
> <ma...@rodehav.com>>
> *Sender: * bengt.rodehav@gmail.com <ma...@gmail.com>
> *Date: *Sat, 12 Feb 2011 09:18:46 +0100
> *To: *<user@karaf.apache.org <ma...@karaf.apache.org>>
> *ReplyTo: * user@karaf.apache.org <ma...@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 <gnodet@gmail.com
> <ma...@gmail.com>>
>
> On Sat, Feb 12, 2011 at 00:38, Bengt Rodehav
> <bengt@rodehav.com <ma...@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"
> <gnodet@gmail.com <ma...@gmail.com>>:
> >
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
>
>
>
Re: Problems with features startlevel
Posted by jb...@nanthrax.net.
Agree I'm preparing some test cases.
-----Original Message-----
From: Guillaume Nodet <gn...@gmail.com>
Date: Sun, 13 Feb 2011 10:02:27
To: <de...@karaf.apache.org>
Reply-To: dev@karaf.apache.org
Subject: Re: Problems with features startlevel
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, <jb...@nanthrax.net> 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 <be...@rodehav.com>
> Sender: bengt.rodehav@gmail.com
> Date: Sat, 12 Feb 2011 20:11:45 +0100
> To: <us...@karaf.apache.org>; <jb...@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 <jb...@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.rodehav@gmail.com
>> Date: Sat, 12 Feb 2011 16:57:38 +0100
>> To: <us...@karaf.apache.org>; <jb...@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 <jb...@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.rodehav@gmail.com
>>> Date: Sat, 12 Feb 2011 09:18:46 +0100
>>> To: <us...@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 <gn...@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" <gn...@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
Re: Problems with features startlevel
Posted by Bengt Rodehav <be...@rodehav.com>.
At first sight it sounds like the custom.properties file should help me with
a lot of the stuff I need. However, I have troubles getting it to work. Two
questions:
1. Can I specify additional system properties somewhere? Or perhaps an
additional location (except for system.properties) where I can put my custom
system.properties without having to modify system.propereties?
2. I'm trying to add cglib as a bundle to start initially without modifying
startup.properties. I then created a custom.properties file where I put the
following line:
*
> karaf.auto.start.40=org/apache/servicemix/bundles/org.apache.servicemix.bundles.cglib/2.1_3_4/org.apache.servicemix.bundles.cglib-2.1_3_4.jar
> *
But it doesn't work. On startup I get the following error message:
*Error installing bundle
> org/apache/servicemix/bundles/org.apache.servicemix.bun
> dles.cglib/2.1_3_4/org.apache.servicemix.bundles.cglib-2.1_3_4.jar:
> java.lang.Ar
> rayIndexOutOfBoundsException: 1*
Also, the custom.properties that comes with Karaf is not empty. It contains
the following line:
*karaf.systemBundlesStartLevel=50*
If this is a default, then it shouldn't be in custom.properties. I think
custom.properties should be empty in the Karaf distribution. In fact one can
argue that the file shouldn't be included at all in the distribution and
that it should be created if any customisation is needed.
I think if I can avoid having to modify startup.properties and
system.properties and instead use custom.properties I can come a long way.
However, I can't presently see how that would solve the customisation of the
actual launching of Karaf/java (java options, console title etc). I think
also customisation of karaf-wrapper.conf is important since that's what I
really use and it contains a lot of things that Karaf needs mixed with stuff
that I need to customise.
/Bengt
2011/2/13 Guillaume Nodet <gn...@gmail.com>
> 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, <jb...@nanthrax.net> 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 <be...@rodehav.com>
> > Sender: bengt.rodehav@gmail.com
> > Date: Sat, 12 Feb 2011 20:11:45 +0100
> > To: <us...@karaf.apache.org>; <jb...@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 <jb...@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.rodehav@gmail.com
> >> Date: Sat, 12 Feb 2011 16:57:38 +0100
> >> To: <us...@karaf.apache.org>; <jb...@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 <jb...@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.rodehav@gmail.com
> >>> Date: Sat, 12 Feb 2011 09:18:46 +0100
> >>> To: <us...@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 <gn...@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" <gn...@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
>
Re: Problems with features startlevel
Posted by Guillaume Nodet <gn...@gmail.com>.
Btw, that was https://issues.apache.org/jira/browse/KARAF-110 which
has been fixed last year.
There is certainly room for improvements though as maybe not all use
cases are solved yet.
On Sun, Feb 13, 2011 at 10:02, Guillaume Nodet <gn...@gmail.com> wrote:
> 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, <jb...@nanthrax.net> 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 <be...@rodehav.com>
>> Sender: bengt.rodehav@gmail.com
>> Date: Sat, 12 Feb 2011 20:11:45 +0100
>> To: <us...@karaf.apache.org>; <jb...@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 <jb...@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.rodehav@gmail.com
>>> Date: Sat, 12 Feb 2011 16:57:38 +0100
>>> To: <us...@karaf.apache.org>; <jb...@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 <jb...@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.rodehav@gmail.com
>>>> Date: Sat, 12 Feb 2011 09:18:46 +0100
>>>> To: <us...@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 <gn...@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" <gn...@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
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: Problems with features startlevel
Posted by Guillaume Nodet <gn...@gmail.com>.
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, <jb...@nanthrax.net> 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 <be...@rodehav.com>
> Sender: bengt.rodehav@gmail.com
> Date: Sat, 12 Feb 2011 20:11:45 +0100
> To: <us...@karaf.apache.org>; <jb...@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 <jb...@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.rodehav@gmail.com
>> Date: Sat, 12 Feb 2011 16:57:38 +0100
>> To: <us...@karaf.apache.org>; <jb...@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 <jb...@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.rodehav@gmail.com
>>> Date: Sat, 12 Feb 2011 09:18:46 +0100
>>> To: <us...@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 <gn...@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" <gn...@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
Re: Problems with features startlevel
Posted by jb...@nanthrax.net.
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.rodehav@gmail.com
Date: Sat, 12 Feb 2011 20:11:45
To: <us...@karaf.apache.org>; <jb...@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 <jb...@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.rodehav@gmail.com
> *Date: *Sat, 12 Feb 2011 16:57:38 +0100
> *To: *<us...@karaf.apache.org>; <jb...@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 <jb...@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.rodehav@gmail.com
>> *Date: *Sat, 12 Feb 2011 09:18:46 +0100
>> *To: *<us...@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 <gn...@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" <gn...@gmail.com>:
>>> >
>>>
>>>
>>>
>>> --
>>> Cheers,
>>> Guillaume Nodet
>>> ------------------------
>>> Blog: http://gnodet.blogspot.com/
>>> ------------------------
>>> Open Source SOA
>>> http://fusesource.com
>>>
>>
>>
>
Re: Problems with features startlevel
Posted by Bengt Rodehav <be...@rodehav.com>.
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 <jb...@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.rodehav@gmail.com
> *Date: *Sat, 12 Feb 2011 16:57:38 +0100
> *To: *<us...@karaf.apache.org>; <jb...@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 <jb...@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.rodehav@gmail.com
>> *Date: *Sat, 12 Feb 2011 09:18:46 +0100
>> *To: *<us...@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 <gn...@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" <gn...@gmail.com>:
>>> >
>>>
>>>
>>>
>>> --
>>> Cheers,
>>> Guillaume Nodet
>>> ------------------------
>>> Blog: http://gnodet.blogspot.com/
>>> ------------------------
>>> Open Source SOA
>>> http://fusesource.com
>>>
>>
>>
>
Re: Problems with features startlevel
Posted by jb...@nanthrax.net.
Thanks Bengt for your complete feedback. I'm gonna raise some Jiras about that.
Regards
JB
-----Original Message-----
From: Bengt Rodehav <be...@rodehav.com>
Sender: bengt.rodehav@gmail.com
Date: Sat, 12 Feb 2011 16:57:38
To: <us...@karaf.apache.org>; <jb...@nanthrax.net>
Reply-To: 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 <jb...@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.rodehav@gmail.com
> *Date: *Sat, 12 Feb 2011 09:18:46 +0100
> *To: *<us...@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 <gn...@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" <gn...@gmail.com>:
>> >
>>
>>
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>>
>
>
Re: Problems with features startlevel
Posted by Bengt Rodehav <be...@rodehav.com>.
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 <jb...@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.rodehav@gmail.com
> *Date: *Sat, 12 Feb 2011 09:18:46 +0100
> *To: *<us...@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 <gn...@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" <gn...@gmail.com>:
>> >
>>
>>
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>>
>
>
Re: Problems with features startlevel
Posted by jb...@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
-----Original Message-----
From: Bengt Rodehav <be...@rodehav.com>
Sender: bengt.rodehav@gmail.com
Date: Sat, 12 Feb 2011 09:18:46
To: <us...@karaf.apache.org>
Reply-To: 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 <gn...@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" <gn...@gmail.com>:
> >
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
Re: Problems with features startlevel
Posted by Bengt Rodehav <be...@rodehav.com>.
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 <gn...@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" <gn...@gmail.com>:
> >
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
Re: Problems with features startlevel
Posted by Guillaume Nodet <gn...@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" <gn...@gmail.com>:
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: Problems with features startlevel
Posted by Bengt Rodehav <be...@rodehav.com>.
Ok, thanks. Is there know way to avoid having to modify startup.properties
then?
(Do you never sleep or are we in different time zones?)
Den 12 feb 2011 00.15 skrev "Guillaume Nodet" <gn...@gmail.com>:
Re: Problems with features startlevel
Posted by Guillaume Nodet <gn...@gmail.com>.
The different is that the files in the etc/startup.properties are
processed first, while the features service is started later.
So if you use etc/startup.properties, the blueprint extender will be
wired to the cglib bundle, whereas if you put it in the features
descriptor, it will be installed after all bundles in
etc/startup.properties are installed and resolved.
Note that the bundle leve in that case has no effect, has the cglib
bundle does not even have to be started (and the framework will
resolve it automatically as needed once it has been installed).
On Fri, Feb 11, 2011 at 23:07, Bengt Rodehav <be...@rodehav.com> wrote:
> I'm using Karaf 2.1.3 together with Aries (0.2-incubating). I get the
> following exception:
>>
>> 2011-02-11 22:55:54,787 | ERROR | rint Extender: 3 | ServiceRecipe
>> | lueprint.container.ServiceRecipe 284 | Error retrieving
>> service from ServiceRecipe[name='.component-2']
>> org.osgi.service.blueprint.container.ComponentDefinitionException:
>> Interceptors have been configured but neither asm nor cglib are available
>> at
>> org.apache.aries.blueprint.container.BeanRecipe.addInterceptors(BeanRecipe.java:694)
>> at
>> org.apache.aries.blueprint.container.BeanRecipe.internalCreate(BeanRecipe.java:748)
>> at
>> org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:64)
>> at
>> org.apache.aries.blueprint.di.RefRecipe.internalCreate(RefRecipe.java:60)
>> at
>> org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:64)
>> at
>> org.apache.aries.blueprint.container.BlueprintRepository.createInstances(BlueprintRepository.java:219)
>> at
>> org.apache.aries.blueprint.container.BlueprintRepository.createInstance(BlueprintRepository.java:198)
>> at
>> org.apache.aries.blueprint.container.BlueprintRepository.create(BlueprintRepository.java:137)
>> at
>> org.apache.aries.blueprint.container.ServiceRecipe.createRecipe(ServiceRecipe.java:352)[7:org.apache.aries.blueprint:0.2.0.incubating]
>> at
>> org.apache.aries.blueprint.container.ServiceRecipe.createService(ServiceRecipe.java:260)[7:org.apache.aries.blueprint:0.2.0.incubating]
>> at
>> org.apache.aries.blueprint.container.ServiceRecipe.internalGetService(ServiceRecipe.java:230)[7:org.apache.aries.blueprint:0.2.0.incubating]
>> at
>> org.apache.aries.blueprint.container.ServiceRecipe.getService(ServiceRecipe.java:309)[7:org.apache.aries.blueprint:0.2.0.incubating]
>> at
>> org.apache.aries.blueprint.container.ServiceRecipe$TriggerServiceFactory.getService(ServiceRecipe.java:367)
>> at
>> org.apache.felix.framework.ServiceRegistrationImpl.getFactoryUnchecked(ServiceRegistrationImpl.java:307)
>> at
>> org.apache.felix.framework.ServiceRegistrationImpl.getService(ServiceRegistrationImpl.java:221)
>> at
>> org.apache.felix.framework.ServiceRegistry.getService(ServiceRegistry.java:295)[org.apache.felix.framework-3.0.2.jar:]
>> at
>> org.apache.felix.framework.Felix.getService(Felix.java:3007)[org.apache.felix.framework-3.0.2.jar:]
>> at
>> org.apache.felix.framework.BundleContextImpl.getService(BundleContextImpl.java:329)[org.apache.felix.framework-3.0.2.jar:]
>> at org.apache.felix.ipojo.IPojoContext.getService(IPojoContext.java:260)
>> at org.apache.felix.ipojo.util.Tracker.getService(Tracker.java:441)
>> at
>> org.apache.felix.ipojo.util.DependencyModel.getService(DependencyModel.java:911)[46:org.apache.felix.ipojo:1.6.8]
>> at
>> org.apache.felix.ipojo.handlers.dependency.Dependency.createServiceObject(Dependency.java:638)
>> at
>> org.apache.felix.ipojo.handlers.dependency.Dependency.onGet(Dependency.java:609)
>> at
>> org.apache.felix.ipojo.InstanceManager.onGet(InstanceManager.java:960)[46:org.apache.felix.ipojo:1.6.8]
>> ...
>
> Apparently cglib is resolved too late. When I get the above exception I use
> the following in my features repo:
>>
>> <feature name="connect-aries" version="1.1.0-SNAPSHOT">
>> <bundle
>> start-level="40">mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.cglib/2.1_3_4</bundle>
>> ...
>
> The "connect-aries" features is listed in my org.apache.karaf.features.cfg.
> However, if I instead add the following line to the end of my
> startup.properties file then it works perfectly:
>>
>>
>> org/apache/servicemix/bundles/org.apache.servicemix.bundles.cglib/2.1_3_4/org.apache.servicemix.bundles.cglib-2.1_3_4.jar=40
>
> Why is there a diffence? I'm trying to get rid of the line in
> startup.properties in order to mess as little as possible with the Karaf
> standard installation.
> /Bengt
>
>
>
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com