Re: [UPDATE] Karaf 2.2.x branch status
Is there anything left or should we start the release process asap ? On Tue, Feb 8, 2011 at 16:51, Jamie G. wrote: > Hi, > > Thanks for all your feedback. We've fixed multiple bugs/problems on > the release branch and will start building a release candidate > shortly. Thanks again for all your contributions. > > -The Karaf Team > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [PROPOSAL] Add Karaf to the new Apache Sonar
Did you had Karaf to Sonar ? I wanted to look but Sonar seems down now anyway ... On Mon, Feb 7, 2011 at 15:22, Jean-Baptiste Onofré wrote: > Hi all, > > A new Sonar instance is available at Apache: > http://sonar.apache.org > > Some projects are already registered such as Apache Camel: > http://sonar.apache.org/dashboard/index/37401 > > WDYT about adding Karaf to Sonar ? > > Regards > JB > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: Wrong reference to "Camel" on "Building" page of web site
Lol, thx ! I'll fix that asap. On Sun, Feb 13, 2011 at 17:51, Raj Saini wrote: > Hi, > > There is a reference to "Camel" in the opening paragraph of Building" page > (http://karaf.apache.org/index/developers/building.html). I think it should > "Karaf" instead. > > Thanks, > > Raj > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [VOTE] Release Karaf version 2.1.4
+1 -- Chris Custine FuseSource - Open Source Integration:: http://fusesource.com My Blog :: http://blog.organicelement.com On Sat, Feb 12, 2011 at 05:56, Jamie G. wrote: > Hi, > > We resolved 14 issues in this release (may take some time for cwiki to > update with this page): > https://cwiki.apache.org/confluence/display/KARAF/Karaf+2.1.4+Release > > Please note, the above release notes will have to be migrated to the > new Scalate based web site upon approval of this RC :) > > Staging repository: > https://repository.apache.org/content/repositories/orgapachekaraf-057/ > > Release tags: > http://svn.apache.org/repos/asf/karaf/tags/karaf-2.1.4/ > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] -1 Veto the release (please provide specific comments) > > This vote will be open for 72 hours. >
Wrong reference to "Camel" on "Building" page of web site
Hi, There is a reference to "Camel" in the opening paragraph of Building" page (http://karaf.apache.org/index/developers/building.html). I think it should "Karaf" instead. Thanks, Raj
Re: Problems with features startlevel
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 > 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, 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 > > Sender: bengt.rode...@gmail.com > > Date: Sat, 12 Feb 2011 20:11:45 +0100 > > To: ; > > 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 > >> > >> Thanks Bengt for your complete feedback. I'm gonna raise some Jiras > about > >> that. > >> > >> Regards > >> JB > >> > >> From: Bengt Rodehav > >> Sender: bengt.rode...@gmail.com > >> Date: Sat, 12 Feb 2011 16:57:38 +0100 > >> To: ; > >> ReplyTo: u...@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 >
Re: Problems with features startlevel
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 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, 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
>> Sender: bengt.rode...@gmail.com
>> Date: Sat, 12 Feb 2011 20:11:45 +0100
>> To: ;
>> 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
>>>
>>> Thanks Bengt for your complete feedback. I'm gonna raise some Jiras about
>>> that.
>>>
>>> Regards
>>> JB
>>>
>>> From: Bengt Rodehav
>>> Sender: bengt.rode...@gmail.com
>>> Date: Sat, 12 Feb 2011 16:57:38 +0100
>>> To: ;
>>> ReplyTo: u...@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) whic
Re: Problems with features startlevel
Agree I'm preparing some test cases.
-Original Message-
From: Guillaume Nodet
Date: Sun, 13 Feb 2011 10:02:27
To:
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, 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
> Sender: bengt.rode...@gmail.com
> Date: Sat, 12 Feb 2011 20:11:45 +0100
> To: ;
> 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
>>
>> Thanks Bengt for your complete feedback. I'm gonna raise some Jiras about
>> that.
>>
>> Regards
>> JB
>>
>> From: Bengt Rodehav
>> Sender: bengt.rode...@gmail.com
>> Date: Sat, 12 Feb 2011 16:57:38 +0100
>> To: ;
>> ReplyTo: u...@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
>>>
>>> Hi Bengt,
>>>
>>> I've added documentation about
Re: [INFO] New website and "old" wiki documentation
Ah, ok, I suppose we need to give google some time to update its search results. On Sun, Feb 13, 2011 at 10:09, Jean-Baptiste Onofré wrote: > Yeah, > > The "temporary" issue is when using the search on the left. Up to now, it > returns the "old" URL. > > Regards > JB > > On 02/13/2011 10:06 AM, Guillaume Nodet wrote: >> >> The url has changed a bit, but we could flatten it a bit if we want: >> >> http://karaf.apache.org/index/documentation/karaf-users-guide/5.-using-karaf/5.1.-troubleshooting-debugging-and-profiling.html >> >> Though, I think we'll soon point people to the new manual instead: >> http://karaf.apache.org/index/documentation.html >> http://karaf.apache.org/manual/2.1.99-SNAPSHOT/index.html >> >> On Sun, Feb 13, 2011 at 09:48, Jean-Baptiste Onofré >> wrote: >>> >>> Hi all, >>> >>> Just to keep you posted, with the new website upload, some "old" wiki >>> pages >>> are not available, especially for the previous documentation. >>> >>> For instance, if you try to access to: >>> http://karaf.apache.org/51-troubleshooting-debugging-and-profiling.html >>> >>> you will get a "Not Found" error. >>> >>> The workaround is to go to the wiki: >>> https://cwiki.apache.org/confluence/display/KARAF >>> >>> Regards >>> JB >>> >> >> >> > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [INFO] New website and "old" wiki documentation
Yeah, The "temporary" issue is when using the search on the left. Up to now, it returns the "old" URL. Regards JB On 02/13/2011 10:06 AM, Guillaume Nodet wrote: The url has changed a bit, but we could flatten it a bit if we want: http://karaf.apache.org/index/documentation/karaf-users-guide/5.-using-karaf/5.1.-troubleshooting-debugging-and-profiling.html Though, I think we'll soon point people to the new manual instead: http://karaf.apache.org/index/documentation.html http://karaf.apache.org/manual/2.1.99-SNAPSHOT/index.html On Sun, Feb 13, 2011 at 09:48, Jean-Baptiste Onofré wrote: Hi all, Just to keep you posted, with the new website upload, some "old" wiki pages are not available, especially for the previous documentation. For instance, if you try to access to: http://karaf.apache.org/51-troubleshooting-debugging-and-profiling.html you will get a "Not Found" error. The workaround is to go to the wiki: https://cwiki.apache.org/confluence/display/KARAF Regards JB
Re: [INFO] New website and "old" wiki documentation
The url has changed a bit, but we could flatten it a bit if we want: http://karaf.apache.org/index/documentation/karaf-users-guide/5.-using-karaf/5.1.-troubleshooting-debugging-and-profiling.html Though, I think we'll soon point people to the new manual instead: http://karaf.apache.org/index/documentation.html http://karaf.apache.org/manual/2.1.99-SNAPSHOT/index.html On Sun, Feb 13, 2011 at 09:48, Jean-Baptiste Onofré wrote: > Hi all, > > Just to keep you posted, with the new website upload, some "old" wiki pages > are not available, especially for the previous documentation. > > For instance, if you try to access to: > http://karaf.apache.org/51-troubleshooting-debugging-and-profiling.html > > you will get a "Not Found" error. > > The workaround is to go to the wiki: > https://cwiki.apache.org/confluence/display/KARAF > > Regards > JB > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
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, 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
> Sender: bengt.rode...@gmail.com
> Date: Sat, 12 Feb 2011 20:11:45 +0100
> To: ;
> 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
>>
>> Thanks Bengt for your complete feedback. I'm gonna raise some Jiras about
>> that.
>>
>> Regards
>> JB
>>
>> From: Bengt Rodehav
>> Sender: bengt.rode...@gmail.com
>> Date: Sat, 12 Feb 2011 16:57:38 +0100
>> To: ;
>> ReplyTo: u...@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
>>>
>>> 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: Beng
[INFO] New website and "old" wiki documentation
Hi all, Just to keep you posted, with the new website upload, some "old" wiki pages are not available, especially for the previous documentation. For instance, if you try to access to: http://karaf.apache.org/51-troubleshooting-debugging-and-profiling.html you will get a "Not Found" error. The workaround is to go to the wiki: https://cwiki.apache.org/confluence/display/KARAF Regards JB
