Re: [PROPOSAL] Create integration (ServiceMix like) distribution in Karaf OSGi runtime

[Sobkowiak, Krzysztof]

+1 (binding)

I think, it's time to do this step. It's a difficult for me to say it 
after many years of contribution in this community. I think the idea of 
ServiceMix as oss integration platform was great but it is simply in a 
long agony actually. I think it has a chance to survive in the Karaf 
community.


When there are any features of current SMX distribution which will be 
not part of the integration distro (to not to make it too complicated) 
but are worth to survive, they can be simply described in a 
documentation as set of how-tos.


Best regards

Krzysztof


On 18.01.2023 13:44, Jean-Baptiste Onofré wrote:

Hi guys,

The ServiceMix community is discussing about moving most of the SMX
parts into Karaf (the useful parts ;) ).

As part of this move, the "main" ServiceMix distribution is mainly a
Karaf assembly.

Currently, we have two distributions: "standard"
(apache-karaf-x.x.x.tar.gz) and "minimal"
(apache-karaf-minimal-x.x.x.tar.gz).

I propose to add a new distribution (in assemblies):
apache-karaf-integration-x.x.x.tar.gz containing ready to go
Karaf/Camel/CXF/ActiveMQ smooth integration.
Concretely, it means:
- we will have integration features repository XML
- we will have a distribution based on this features repository
- we will have itest on this distribution with the best coverage we can

If there is no objection, I will create the Jira and create a PR (as I
have almost all ready :)).

Thoughts ?

Regards
JB

Re: ActiveMQ and Camel 2.17.x on Karaf

[Sobkowiak Krzysztof]

Btw, this trick with camel-cxf doesn't help with Camel 2.18.x. I think, there 
was a change in Camel 2.17.3 which helped with this problem (but not completely 
yet), but the change is not available in 2.18.x (I tried current snapshot and 
it didn't help too).

It looks like this change has helped in 2.17.3 
https://github.com/apache/camel/commit/284cc6780de1e32468ef2ae50ad357a444e79da1 
(CAMEL-10153), which introduces [3.2,5) as version range for spring in 
camel-cxf. In 2.18.x there is still used the version range [4.1,5)

Regards
Krzysztof

On 19.01.2017 01:17, Krzysztof Sobkowiak wrote:
> My mistake. This problem still happens in the sample steps below - the 
> exception still occurs after Karaf restart and broker doesn't start.
> But adding camel-cxf seems to fix this problem
>
> feature:install camel camel-blueprint camel-jms camel-cxf activemq-camel 
> activemq-broker-noweb activemq-blueprint
>
> Kindly regards
> Krzysztof
>
>
> On 14.01.2017 22:55, Krzysztof Sobkowiak wrote:
>> Hi
>>
>> I could successfully install Camel 2.17.3 and ActiveMQ 5.14.3 on Karaf 4.0.8 
>> (also 4.0.7):
>>
>>
>> __ __   
>>/ //_/ __ _/ __/ 
>>   / ,<  / __ `/ ___/ __ `/ /_   
>>  / /| |/ /_/ / /  / /_/ / __/   
>> /_/ |_|\__,_/_/   \__,_/_/
>>
>>   Apache Karaf (4.0.8)
>>
>> Hit '' for a list of available commands
>> and '[cmd] --help' for help on a specific command.
>> Hit '' or type 'system:shutdown' or 'logout' to shutdown Karaf.
>>
>> karaf@root()> feature:repo-add camel 2.17.3
>> Adding feature url 
>> mvn:org.apache.camel.karaf/apache-camel/2.17.3/xml/features
>> karaf@root()> feature:repo-add activemq 5.14.3
>> Adding feature url mvn:org.apache.activemq/activemq-karaf/5.14.3/xml/features
>> karaf@root()> feature:install camel camel-blueprint camel-jms activemq-camel 
>> activemq-broker-noweb activemq-blueprint
>> karaf@root()> activemq:list
>> brokerName = amq-broker
>>
>>
>> Kindly tegards
>> Krzysztof
>>
>> On 30.11.2016 14:11, IODB wrote:
>>> Can somebody refer me to the relevant Jira issue, so I can track its
>>> progress?
>>>
>>> Thanks
>>>
>>>
Krzysztof Sobkowiak

JEE & OSS Architect, Integration Architect
Apache Software Foundation Member (http://apache.org/)
Apache ServiceMix Committer & PMC Member (http://servicemix.apache.org/)
Senior Solution Architect @ Capgemini SSC (http://www.capgeminisoftware.pl/)

Re: axis2+servicemix

[Sobkowiak Krzysztof]

Hi

Please check the ServiceMix mailing list. I can remember at least one thread 
about Axis. There were no solutions, but probably you can ping the people and 
ask whether they have found the solution.

Regards
Krzysztof

On 17.05.2016 11:17, Jean-Baptiste Onofré wrote:
> You maybe should ask to Axis guys, they know better than us ;)
>
> Regards
> JB
>
> On 05/17/2016 11:08 AM, wuxinlong wrote:
>> Hello！
>>  Thank you for answering my questions！I tried to ues
>> 'org.apache.axis2.osgi.jar' to release axis2. If not, why do it ?
>> http://mvnrepository.com/artifact/org.apache.axis2/org.apache.axis2.osgi
>> http://mvnrepository.com/artifact/org.apache.axis2/axis2-webapp
>>
>>
>>
>> -- 
>> View this message in context: 
>> http://karaf.922171.n3.nabble.com/axis2-servicemix-tp4046648p4046650.html
>> Sent from the Karaf - Dev mailing list archive at Nabble.com.
>>
>

-- 
Krzysztof Sobkowiak

JEE & OSS Architect, Integration Architect
Apache Software Foundation Member (http://apache.org/)
Apache ServiceMix Committer & PMC Member (http://servicemix.apache.org/)
Senior Solution Architect @ Capgemini SSC (http://www.capgeminisoftware.pl/)

Re: [PROPOSAL] Karaf Boot roadmap

[Sobkowiak Krzysztof]

It's nice the boot theme goes forward. +1 for all points. Especially waiting 
for the new dev guide.  I think the guide should provide the both ways - the 
boot one and the non-boot way.

Regards
Krzysztof

On 11.05.2016 17:04, Jean-Baptiste Onofré wrote:
> Hi all,
>
> Karaf Boot code is now on the Apache Git:
>
> https://git.apache.org/karaf-boot.git/
>
> with the github mirror:
>
> https://github.com/apache/karaf-boot
>
> I created the component in Jira.
>
> I will update the website with karaf-boot description.
>
> I propose the following roadmap for karaf-boot, heading to the first 1.0 
> release:
>
> 1. Bootstrapping
> 
> As a reminder, karaf-boot has two goals:
> - simplify the way to create module and application for developers
> - simplify the bootstrapping as a "standalone" application (leveraging the 
> container feature)
>
> Currently, we mostly address the first point. Our starters provide 
> annotations allowing to easily create application. The 
> karaf-boot-maven-plugin "calls" the annotation processor in the starters, and 
> other plugins behind the hood to easily generate artifacts.
>
> Now, we have to address the second point: bootstrapping. I started a PoC on 
> that.
> I created new starters for bootstrapping:
> - karaf-boot-starter-feature creates a feature using the dependencies and 
> project artifact
> - karaf-boot-starter-distribution creates both zip and tar.gz Karaf custom 
> distribution embedding the current project artifact and dependencies
> - karaf-boot-starter-distribution-rjar is similar to distribution, but it's a 
> runnable jar (using a custom Main)
> - karaf-boot-starter-docker creates a docker image embedding the custom 
> distribution
>
> Now, the karaf-boot-maven-plugin is checking the dependencies to find one of 
> these bootstrap starter, and react accordingly.
> However, most of the logic is in the plugin, leveraging karaf-maven-plugin 
> (assembly and archive goals for instance).
> If this approach works (and is easy), I don't think it's the most elegant way.
> I think we should create a @bootstrap annotation on a Runnable class in the 
> bootstrap starters. The annotated class is responsible of the bootstrap 
> artifact creation. An abstract bootstrap starter provide an annotation 
> processor that look for @bootstrap annotation and run the class in a thread. 
> The karaf-boot-maven-plugin just delegates the bootstrapping to the starter.
>
> WDYT ?
>
> 2. New starters
> ---
> We have to extend the coverage of the starter to address more use cases. I'm 
> thinking about starters for test (both utest and itest leveraging pax-exam), 
> for jaas, for management/MBean, for eventadmin, for decanter, for camel, etc.
>
> 3. New samples
> --
> Related to 2, each new starter should have a corresponding sample. The 
> samples are really important as it's where the users start.
>
> We should also provide kind of full application use case, multi-module. I 
> started this showing how to use different starters in different modules (like 
> a Logo construction set).
>
> 4. Documentation and Karaf Dev Guide
> 
> The "new" Karaf Dev guide will be based mostly on karaf-boot. A second 
> section ("advanced") can still address non karaf-boot cases.
>
> Thoughts ?
>
> Regards
> JB

-- 
Krzysztof Sobkowiak

JEE & OSS Architect, Integration Architect
Apache Software Foundation Member (http://apache.org/)
Apache ServiceMix Committer & PMC Member (http://servicemix.apache.org/)
Senior Solution Architect @ Capgemini SSC (http://www.capgeminisoftware.pl/)

Re: [VOTE] Apache Karaf 4.0.5 release (take 2)

[Sobkowiak Krzysztof]

I prefer the option 2 as well

Regards
Krzysztof

On 06.04.2016 08:39, Jean-Baptiste Onofré wrote:
> Hi Cristiano,
>
> I don't think it's related, as the issue in about blueprint-ext namespace 
> (not even define). The problem is located in Aries Blueprint.
>
> I gonna deal with Guillaume.
>
> We can:
> 0. leave Karaf 4.0.5 as it is, but I think it's not acceptable: blueprint is 
> used by lot of users, and we can't allow a release without a working 
> blueprint layer.
> 1. downgrade Karaf to Aries Blueprint 1.5.x: unfortunately, we won't benefit 
> about some improvements implemented in blueprint
> 2. revert or fix the change in Aries: it means we would need a new Aries 
> Blueprint core release, so 3 days vote, meaning that we won't be able to 
> release Karaf before roughly 6 days.
>
> My preference is on 2 even if it delays Karaf 4.0.5 release.
>
> Thoughts ?
>
> I will add an Integration Test on blueprint to avoid such problem in the 
> future.
>
> Regards
> JB
>
> On 04/06/2016 08:14 AM, Cristiano Costantini wrote:
>> Hi JB and Krzysztof,
>>
>> I don't know if this can be have any impact on the problem you have
>> reported, but about 1 month ago I got into an issue with camel XSD schemas
>> for Camel namespaces, and the issue is that the URL of the latest XSD,
>> http://camel.apache.org/schema/blueprint/camel-blueprint.xsd
>> is not from latest version 2.16.2, but it is from version 2.15.0
>>
>> While upgrading to ServiceMix 7, I had to change manually the XML to
>> xsi:schemaLocation="http://camel.apache.org/schema/spring http://camel
>> .apache.org/schema/spring/camel-spring-2.16.1.xsd" in order to make it work
>> (note also that SMX 7 is based on camel 2.16.2, but this XSD is not
>> available)
>>
>> But in fact the only problem I had was that Eclipse validation and
>> autocompletion of the XML files was not working properly.
>>
>> if this is not relevant, please ignore this message ;-)
>>
>> Cristiano
>>
>>
>>
>>
>> Il giorno mar 5 apr 2016 alle ore 22:19 Jean-Baptiste Onofré <
>> j...@nanthrax.net> ha scritto:
>>
>>> I tried with Camel 2.16.2, camel-blueprint, and simple route in
>>> blueprint: it works fine.
>>>
>>> I tried with your XML, and actually I have the same problem.
>>>
>>> It sounds like a Aries Blueprint bug. Let me try if I downgrade to
>>> blueprint 1.5.x and check the change in aries blueprint (I know
>>> Guillaume did some enhancements & changes).
>>>
>>> Honestly, I would consider as a blocker for the release, so, I will
>>> probably revert my vote to -1. I just want to make more tests.
>>>
>>> Regards
>>> JB
>>>
>>> On 04/05/2016 09:46 PM, Krzysztof Sobkowiak wrote:
 Hi

 I tried to upgrade ServiceMix to the new version and have several
>>> problems with blueprint.

 2016-04-05 21:42:05,485 | INFO  | pool-46-thread-1 |
>>> FeaturesServiceImpl  | 9 - org.apache.karaf.features.core -
>>> 4.0.5 |   cxf-wsn-receive/7.0.0.SNAPSHOT
 2016-04-05 21:42:05,567 | ERROR | pool-46-thread-1 |
>>> BlueprintContainerImpl   | 28 - org.apache.aries.blueprint.core -
>>> 1.6.0 | Unable to start blueprint container for bundle
>>> cxf-wsn-receive/7.0.0.SNAPSHOT
 org.xml.sax.SAXParseException: src-import.3.1: The namespace attribute, '
>>> http://aries.apache.org/blueprint/xmlns/blueprint-ext/v1.0.0', of an
>>>  element information item must be identical to the targetNamespace
>>> attribute, 'http://camel.apache.org/schema/blueprint', of the imported
>>> document.
   at
>>> org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown
>>> Source)[:]
   at org.apache.xerces.util.ErrorHandlerWrapper.error(Unknown
>>> Source)[:]
   at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown
>>> Source)[:]
   at
>>> org.apache.xerces.impl.xs.traversers.XSDHandler.reportSchemaError(Unknown
>>> Source)[:]
   at
>>> org.apache.xerces.impl.xs.traversers.XSDHandler.reportSchemaError(Unknown
>>> Source)[:]
   at
>>> org.apache.xerces.impl.xs.traversers.XSDHandler.constructTrees(Unknown
>>> Source)[:]
   at
>>> org.apache.xerces.impl.xs.traversers.XSDHandler.constructTrees(Unknown
>>> Source)[:]
   at
>>> org.apache.xerces.impl.xs.traversers.XSDHandler.parseSchema(Unknown
>>> Source)[:]

 or


 2016-04-05 21:31:36,969 | ERROR | pool-42-thread-1 |
>>> BlueprintContainerImpl   | 28 - org.apache.aries.blueprint.core -
>>> 1.6.0 | Unable to start blueprint container for bundle
>>> drools-camel-cxf-server/7.0.0.SNAPSHOT
 org.xml.sax.SAXParseException: src-import.3.1: The namespace attribute, '
>>> http://cxf.apache.org/configuration/beans', of an  element
>>> information item must be identical to the targetNamespace attribute, '
>>> http://camel.apache.org/schema/blueprint', of the imported document.
   at
>>> org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown
>>> Source)[:]
   at 

Re: [VOTE] Apache Karaf 4.0.5 release (take 2)

[Sobkowiak Krzysztof]

Hi Cristiano

This problem happens on Karaf 4.0.5 with both 2.16.2 and 2.17.0 (I didn't test 
it with 2.15.x) but doesn't happen on Karaf 4.0.4, so I think it's rather 
caused by changes in Karaf (in this case Aries).
But I have also mentioned the validation problems in IDE last days, so I think, 
the xsd file in Camel should be corrected as well.

Regards
Krzysztof

On 06.04.2016 08:14, Cristiano Costantini wrote:
> Hi JB and Krzysztof,
>
> I don't know if this can be have any impact on the problem you have
> reported, but about 1 month ago I got into an issue with camel XSD schemas
> for Camel namespaces, and the issue is that the URL of the latest XSD,
> http://camel.apache.org/schema/blueprint/camel-blueprint.xsd
> is not from latest version 2.16.2, but it is from version 2.15.0
>
> While upgrading to ServiceMix 7, I had to change manually the XML to
> xsi:schemaLocation="http://camel.apache.org/schema/spring http://camel
> .apache.org/schema/spring/camel-spring-2.16.1.xsd" in order to make it work
> (note also that SMX 7 is based on camel 2.16.2, but this XSD is not
> available)
>
> But in fact the only problem I had was that Eclipse validation and
> autocompletion of the XML files was not working properly.
>
> if this is not relevant, please ignore this message ;-)
>
> Cristiano
>
>
>
>
> Il giorno mar 5 apr 2016 alle ore 22:19 Jean-Baptiste Onofré <
> j...@nanthrax.net> ha scritto:
>
>> I tried with Camel 2.16.2, camel-blueprint, and simple route in
>> blueprint: it works fine.
>>
>> I tried with your XML, and actually I have the same problem.
>>
>> It sounds like a Aries Blueprint bug. Let me try if I downgrade to
>> blueprint 1.5.x and check the change in aries blueprint (I know
>> Guillaume did some enhancements & changes).
>>
>> Honestly, I would consider as a blocker for the release, so, I will
>> probably revert my vote to -1. I just want to make more tests.
>>
>> Regards
>> JB
>>
>> On 04/05/2016 09:46 PM, Krzysztof Sobkowiak wrote:
>>> Hi
>>>
>>> I tried to upgrade ServiceMix to the new version and have several
>> problems with blueprint.
>>> 2016-04-05 21:42:05,485 | INFO  | pool-46-thread-1 |
>> FeaturesServiceImpl  | 9 - org.apache.karaf.features.core -
>> 4.0.5 |   cxf-wsn-receive/7.0.0.SNAPSHOT
>>> 2016-04-05 21:42:05,567 | ERROR | pool-46-thread-1 |
>> BlueprintContainerImpl   | 28 - org.apache.aries.blueprint.core -
>> 1.6.0 | Unable to start blueprint container for bundle
>> cxf-wsn-receive/7.0.0.SNAPSHOT
>>> org.xml.sax.SAXParseException: src-import.3.1: The namespace attribute, '
>> http://aries.apache.org/blueprint/xmlns/blueprint-ext/v1.0.0', of an
>>  element information item must be identical to the targetNamespace
>> attribute, 'http://camel.apache.org/schema/blueprint', of the imported
>> document.
>>>  at
>> org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown
>> Source)[:]
>>>  at org.apache.xerces.util.ErrorHandlerWrapper.error(Unknown
>> Source)[:]
>>>  at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown
>> Source)[:]
>>>  at
>> org.apache.xerces.impl.xs.traversers.XSDHandler.reportSchemaError(Unknown
>> Source)[:]
>>>  at
>> org.apache.xerces.impl.xs.traversers.XSDHandler.reportSchemaError(Unknown
>> Source)[:]
>>>  at
>> org.apache.xerces.impl.xs.traversers.XSDHandler.constructTrees(Unknown
>> Source)[:]
>>>  at
>> org.apache.xerces.impl.xs.traversers.XSDHandler.constructTrees(Unknown
>> Source)[:]
>>>  at
>> org.apache.xerces.impl.xs.traversers.XSDHandler.parseSchema(Unknown
>> Source)[:]
>>> or
>>>
>>>
>>> 2016-04-05 21:31:36,969 | ERROR | pool-42-thread-1 |
>> BlueprintContainerImpl   | 28 - org.apache.aries.blueprint.core -
>> 1.6.0 | Unable to start blueprint container for bundle
>> drools-camel-cxf-server/7.0.0.SNAPSHOT
>>> org.xml.sax.SAXParseException: src-import.3.1: The namespace attribute, '
>> http://cxf.apache.org/configuration/beans', of an  element
>> information item must be identical to the targetNamespace attribute, '
>> http://camel.apache.org/schema/blueprint', of the imported document.
>>>  at
>> org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown
>> Source)[:]
>>>  at org.apache.xerces.util.ErrorHandlerWrapper.error(Unknown
>> Source)[:]
>>>  at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown
>> Source)[:]
>>>  at
>> org.apache.xerces.impl.xs.traversers.XSDHandler.reportSchemaError(Unknown
>> Source)[:]
>>>  at
>> org.apache.xerces.impl.xs.traversers.XSDHandler.reportSchemaError(Unknown
>> Source)[:]
>>>  at
>> org.apache.xerces.impl.xs.traversers.XSDHandler.constructTrees(Unknown
>> Source)[:]
>>>  at
>> org.apache.xerces.impl.xs.traversers.XSDHandler.constructTrees(Unknown
>> Source)[:]
>>>
>>>
>>> Here my try to reproduce one of them in K405
>>>
>>> Assume you have following simple blueprint (I have reduced one of the
>> blueprints from the examples)
>>> 

Re: [PROPOSAL] Create karaf-boot project

[Sobkowiak Krzysztof]

+1 for subproject, as Karaf Boot is autonomous and can have own lifecycle

Regards
Krzysztof

On 21.03.2016 12:52, Jean-Baptiste Onofré wrote:
> Hi team,
>
> Regarding the discussion we had couple of months ago, karaf-boot PoC started 
> on my github.
>
> In order to give more visibility, and allow anyone to work on it, I propose 
> to donate this as a Karaf sub-project or a Karaf Container module.
>
> Right now, I will push some enhancements/new features that I did last week, 
> and I will update the README (markdown) to describe the purposes and 
> objectives of karaf-boot.
>
> For the donation, I see two ways:
>
> - a new subproject as Decanter, or Cellar, meaning karaf-boot will have its 
> own git repo.
> - a module in Karaf Container (so a folder named boot or karaf-boot in the 
> Karaf container git repo).
>
> Thoughts ?
>
> Thanks,
> Regards
> JB

-- 
Krzysztof Sobkowiak

JEE & OSS Architect, Integration Architect
Apache Software Foundation Member (http://apache.org/)
Apache ServiceMix Committer & PMC Member (http://servicemix.apache.org/)
Senior Solution Architect @ Capgemini SSC (http://www.capgeminisoftware.pl/)

Re: Karaf Cellar

[Sobkowiak Krzysztof]

Hi Cristiano

I think, this list is ok for Cellar because it's Karafs subproject

Regards
Krzysztof

On 26.02.2016 14:10, Cristiano Costantini wrote:
> Thank you JB!
>
> I'll so make some test to upgrade to ServiceMix 7.0.0.M1 and use Cellar 4,
> hopefully it will be released the final v7 in short time.
>
> Bye,
> Cristiano
>
> P.S. Do it exist a dedicated mailing list for Cellar or does it is ok
> discussing about it on this list?
>
> Il giorno ven 26 feb 2016 alle ore 13:21 Jean-Baptiste Onofré <
> j...@nanthrax.net> ha scritto:
>
>>
>> Hi
>> Cellar 2.3.x works with Karaf 2.x (2.3 and 2.4).Cellar 3.0.x works with
>> Karaf 3.x.Cellar 4.0.x works with Karaf 4.x.
>> If you plan an upgrade, latest one (4.x) makes sense imho.
>> Regards JB
>>
>>
>> Sent from my Samsung device
>>
>>  Original message 
>> From: Cristiano Costantini 
>> Date: 26/02/2016  10:06  (GMT+01:00)
>> To: dev@karaf.apache.org
>> Subject: Karaf Cellar
>>
>> Hello All,
>>
>> we are planning to start using Karaf-Cellar;
>> as we are still using Karaf 2.4.1 (in fact we use Servicemix 5.3.0) but we
>> have a chance to upgrade the version of the container,
>> can I ask you a suggestion on which version of Karaf is the better to start
>> using Cellar?
>> Do you recommend version 3.0.6 or version 4.0.4 or any other version?
>> Or does it is does make no difference?
>>
>> Thank you for the support!
>> Cristiano
>>

-- 
Krzysztof Sobkowiak

JEE & OSS Architect, Integration Architect
Apache Software Foundation Member (http://apache.org/)
Apache ServiceMix Committer & PMC Member (http://servicemix.apache.org/)
Senior Solution Architect @ Capgemini SSC (http://www.capgeminisoftware.pl/)

Re: [VOTE] Apache Karaf 3.0.6 release

[Sobkowiak Krzysztof]

+1 (non-binding)

Regards
Krzysztof

On 09.02.2016 17:19, Jean-Baptiste Onofré wrote:
> Hi all,
>
> I submit Apache Karaf 3.0.6 release to your vote.
>
> Release Notes:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12333641
>
> Staging Repository:
> https://repository.apache.org/content/repositories/orgapachekaraf-1057/
>
> Git tag:
> karaf-3.0.6
>
>
> Please vote to approve this release:
>
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)
>
> This vote will be open for at least 72 hours.
>
> Thanks,
> Regards
> JB

-- 
Krzysztof Sobkowiak

JEE & OSS Architect, Integration Architect
Apache Software Foundation Member (http://apache.org/)
Apache ServiceMix Committer & PMC Member (http://servicemix.apache.org/)
Senior Solution Architect @ Capgemini SSC (http://www.capgeminisoftware.pl/)

Re: Downloads...

[Sobkowiak Krzysztof]

Hi

Replacing all closer.cgi in closer.lua in your download links should fix the 
problem. I had to correct the ServiceMix site yesterday and the same fix helped.

Regards
Krzysztof

On 01.09.2015 13:13, James Carman wrote:
> I tried downloading karaf yesterday and it wasn't working. Apparently we
> need to fix our download scripts:
>
> https://reference.apache.org/pmc/mirror_scripts
>

-- 
Krzysztof Sobkowiak

JEE & OSS Architect, Integration Architect
Apache Software Foundation Member
Apache ServiceMix  Committer & PMC Member
Senior Solution Architect @ Capgemini SSC 

Re: [VOTE] Release Apache Karaf 4.0.0

[Sobkowiak Krzysztof]

+1 (non-binding)

I had problems with cxf and camel-cxf like described by Christian but it's not 
directly connected to Karaf release. For ServiceMix it would be nice to have it 
working
somewhere after summer holidays.

Good job!!
Regards
Krzysztof

On 24.06.2015 01:47, Jamie G. wrote:
 Hi,

 This release candidate represents a possible General Availability
 release of Karaf 4 line, as such it contains all of the enhancements,
 updates, and new features collected over the Karaf 4.0.0 technology
 preview period.

 We resolved 30 issues in this release:
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140version=12332045


 Staging repository:
 https://repository.apache.org/content/repositories/orgapachekaraf-1033/

 Git tag:
 karaf-4.0.0

 Please vote to approve this release:

 [ ] +1 Approve the release
 [ ] -1 Veto the release (please provide specific comments)

 This vote will be open for at least 72 hours.

-- 
Krzysztof Sobkowiak

JEE  OSS Architect
Apache Software Foundation Member
Apache ServiceMix http://servicemix.apache.org/ Committer  PMC
Senior Solution Architect @ Capgemini SSC http://www.pl.capgemini-sdm.com/en/

Re: [ANN] Switching to asciidoctor / new website look'n feel

[Sobkowiak Krzysztof]

Yes, of course :) I meant whether you plan to use any static site generator 
using asciidoctor,  like Awestruct or jekyll with the asciidoc plugin. We have 
not discussed yet
about this in ServiceMix. One of the solutions we could use is the Middleman,   
but I think it makes sense to have a common base and cooperate in the site 
migration.
Ascidoctor is a good idea and it makes sense to use it for the site because you 
use  the same technology for the documentation. If you need some 
help/cooperation/discussion
I'm ready to take part at this task too

regards
Krzysztof

On 21.04.2015 18:16, Jean-Baptiste Onofré wrote:
 asciidoctor as well.

 On 04/21/2015 05:24 PM, Sobkowiak Krzysztof wrote:
 Hi JB

 What are you going to use for the web site?

 Regards
 Krzysztof

 On 21.04.2015 11:28, Jean-Baptiste Onofré wrote:
 Hi all,

 After discussing with guys on IRC, I would like to push on two changes:

 1/ Manual (documentation) will switch from scalate to asciidoctor. I'm 
 double checking that scm-publish works fine for the website update. A 
 couple of guys will work on
 the asciidoctor conversion.
 2/ Website will also switch to asciidoctor with a new look'n feel. A first 
 proposal/mock up will be available soon.

 Thanks,
 Regards
 JB



-- 
Krzysztof Sobkowiak

JEE  OSS Architect
Apache Software Foundation Member
Apache ServiceMix http://servicemix.apache.org/ Committer  PMC
Senior Solution Architect @ Capgemini SSC http://www.pl.capgemini-sdm.com/en/

Re: [ANN] Switching to asciidoctor / new website look'n feel

[Sobkowiak Krzysztof]

Hi JB

What are you going to use for the web site?

Regards
Krzysztof

On 21.04.2015 11:28, Jean-Baptiste Onofré wrote:
 Hi all,

 After discussing with guys on IRC, I would like to push on two changes:

 1/ Manual (documentation) will switch from scalate to asciidoctor. I'm double 
 checking that scm-publish works fine for the website update. A couple of guys 
 will work on
 the asciidoctor conversion.
 2/ Website will also switch to asciidoctor with a new look'n feel. A first 
 proposal/mock up will be available soon.

 Thanks,
 Regards
 JB

-- 
Krzysztof Sobkowiak

JEE  OSS Architect
Apache Software Foundation Member
Apache ServiceMix http://servicemix.apache.org/ Committer  PMC
Senior Solution Architect @ Capgemini SSC http://www.pl.capgemini-sdm.com/en/

Re: [VOTE] Apache Karaf Cellar 2.3.3 release

[Sobkowiak, Krzysztof]

+1 (non-bindings)

regards
Krzysztof

On 12-Nov-2014 18:47, j...@nanthrax.net wrote:
 Hi,

 I submit Karaf Cellar 2.3.3 release to your vote.

 Release Notes:
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140version=12325269


 Staging repository:
 https://repository.apache.org/content/repositories/orgapachekaraf-1017/

 Git tag:
 cellar-2.3.3

 Please vote to approve this release:

 [ ] +1 Approve the release
 [ ] -1 Do not approve the release (please provide specific comments)

 This vote will be open for 72 hours.

 Thanks,
 Regards
 JB

-- 
Krzysztof Sobkowiak

JEE  OSS Architect | Technical Architect @ Capgemini | Committer @ ASF
Capgemini http://www.pl.capgemini.com/ | Software Solutions Center
http://www.pl.capgemini-sdm.com/ | Wroclaw
e-mail: krzys.sobkow...@gmail.com mailto:krzys.sobkow...@gmail.com |
Twitter: @KSobkowiak
Calendar: http://goo.gl/yvsebC

Re: [VOTE] Release Apache Karaf 4.0.0.M1 technology preview.

[Sobkowiak, Krzysztof]

+1 (non-binding)

Regards
Krzysztof


On 11.10.2014 23:10, Jamie G. wrote:
 Hi,

 We have 327 issues resolved on our way towards Apache Karaf 4.0.0 GA
 release. This is a technology preview, as such there will be features
 and other functionality not yet implemented. Please refrain from using
 this particular RC in production.
 https://svn.apache.org/repos/asf/karaf/site/trunk/src/main/webapp/index/community/download/karaf-4.0.0.M1-release.page

 Staging repository:
 https://repository.apache.org/content/repositories/orgapachekaraf-1013/

 Release git tags:
 4.0.0.M1

 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.

-- 
Krzysztof Sobkowiak

JEE  OSS Architect | Technical Architect @ Capgemini | Committer @ ASF
Capgemini http://www.pl.capgemini.com/ | Software Solutions Center
http://www.pl.capgemini-sdm.com/ | Wroclaw
e-mail: krzys.sobkow...@gmail.com mailto:krzys.sobkow...@gmail.com |
Twitter: @KSobkowiak
Calendar: http://goo.gl/yvsebC

Re: [PROPOSAL] Karaf release cycle

[Sobkowiak, Krzysztof]

+1 good idea

Regards
Krzysztof

On 08.10.2014 07:52, Jean-Baptiste Onofré wrote:
 Hi all,

 Users complained about the variable and long delays between Karaf
 releases. It's a fair comment and it's something that we have to improve.

 I propose the following new policy about the releases cycle:
 - for active branches (3.0.x and 2.4.x), I propose a release every 6
 weeks, with maximum extend to 8 weeks.
 - for eol and maintenance branches (2.2.x and 2.3.x), it's on
 demand, no strong cycle there.

 WDYT ?

 If everybody agrees, I will update the releases schedule page on the
 website.

 Regards
 JB

-- 
Krzysztof Sobkowiak

JEE  OSS Architect | Technical Architect @ Capgemini | Committer @ ASF
Capgemini http://www.pl.capgemini.com/ | Software Solutions Center
http://www.pl.capgemini-sdm.com/ | Wroclaw
e-mail: krzys.sobkow...@gmail.com mailto:krzys.sobkow...@gmail.com |
Twitter: @KSobkowiak
Calendar: http://goo.gl/yvsebC

Re: [VOTE] Release Apache Karaf 2.3.8

[Sobkowiak, Krzysztof]

+1 (non-binding)

Regards
Krzysztof

On 16.09.2014 09:56, Jamie G. wrote:
 Hi,

 We resolved 9 issues in this release:
 http://svn.apache.org/viewvc/karaf/site/trunk/src/main/webapp/index/community/download/karaf-2.3.8-release.page?view=markup

 Dependency changes can be reviewed here:
 http://svn.apache.org/viewvc/karaf/site/trunk/src/main/webapp/index/documentation/karaf-dependencies/karaf-deps-2.3.x.page?revision=1613719view=markup

 Staging repository:
 https://repository.apache.org/content/repositories/orgapachekaraf-1010/

 Git tag:
 karaf-2.3.8

 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.

-- 
Krzysztof Sobkowiak

JEE  OSS Architect | Technical Architect @ Capgemini | Committer @ ASF
Capgemini http://www.pl.capgemini.com/ | Software Solutions Center
http://www.pl.capgemini-sdm.com/ | Wroclaw
e-mail: krzys.sobkow...@gmail.com mailto:krzys.sobkow...@gmail.com |
Twitter: @KSobkowiak
Calendar: http://goo.gl/yvsebC

Re: Unexpected folder '${karaf.data}'

[Sobkowiak, Krzysztof]

https://issues.apache.org/jira/browse/KARAF-3212 - I have raised an issue 
yesterday

Best regards
Krzysztof





On 09.09.2014 15:01, Jean-Baptiste Onofré wrote:
 Hi Rodrigo,

 I'm checking that but I don't think I saw that.

 Regards
 JB

 On 09/09/2014 02:56 PM, Rodrigo Serra wrote:
 Hi,

 Latest karaf 3.0.2-SNAPSHOT create a folder with name ‘${karaf.data}’
 (without the quotes) in KARAF_HOME. Inside the folder exists another
 folder called pax-web-jsp. Some thing create the folder without
 convert the parameters values.

 Regards,
 Rodrigo



-- 
Krzysztof Sobkowiak

JEE  OSS Architect | Technical Architect @ Capgemini | Committer @ ASF
Capgemini http://www.pl.capgemini.com/ | Software Solutions Center
http://www.pl.capgemini-sdm.com/ | Wroclaw
e-mail: krzys.sobkow...@gmail.com mailto:krzys.sobkow...@gmail.com |
Twitter: @KSobkowiak
Calendar: http://goo.gl/yvsebC

Re: MissingResourceException in aries transaction

[Sobkowiak, Krzysztof]

Issue for tracking - https://issues.apache.org/jira/browse/KARAF-3211

Best regards
Krzysztof

On 08.09.2014 22:36, Rodrigo Serra wrote:
 it works!. I try with karaf transaction feature content.Thank!!!

 Regards,
 Rodrigo

 El 08/09/2014, a las 17:29, Krzysztof Sobkowiak krzys.sobkow...@gmail.com 
 escribió:

 I have just tested ServiceMix and the problem doesn't occur there. But
 here is one difference:

  * when you install transaction feature in Karaf, there is no file
org.apache.aries.transaction.cfg in etc directory.
  * ServiceMix has a predefined org.apache.aries.transaction.cfg with
following content:

aries.transaction.timeout=600
aries.transaction.howl.logFileDir=${karaf.data}/txlog/
aries.transaction.recoverable=true

  * after copying the file from ServiceMix into Karaf and deleting the
data directory, the problem seems to be fixed
  * I have copied the content of the Karaf transaction feature config
into the org.apache.aries.transaction.cfg file

aries.transaction.recoverable = true
aries.transaction.timeout = 600
aries.transaction.howl.logFileDir = ${karaf.data}/txlog
aries.transaction.howl.maxLogFiles = 2
aries.transaction.howl.maxBlocksPerFile = 512
aries.transaction.howl.bufferSizeKBytes = 4


It works too.


 It means, the problem is missing etc/org.apache.aries.transaction.cfg
 file. But I think this is a correct behavior (missing file), because the
 configuration is stored now in the cache, when defined in feature files
 using  config tag

 Best regards
 Krzysztof


 On 08.09.2014 22:03, Krzysztof Sobkowiak wrote:
 I can reproduce it on Karaf master too. Karaf 2.4 no problem.

 On 08.09.2014 21:05, Jean-Baptiste Onofré wrote:
 I don't have it on my machine. Let me check ;)

 Regards
 JB

 On 09/08/2014 08:10 PM, Krzysztof Sobkowiak wrote:
 I could reproduce this problem on my machine too

 On 08.09.2014 15:17, Rodrigo Serra wrote:
 Both of cases. When install feature i get this error (this is for
 clean data dir: rm -fr data):

 2014-09-08 10:11:35,275 | INFO  | FelixStartLevel  |
 RegionsPersistenceImpl   | 63 -
 org.apache.karaf.region.persist - 3.0.2.SNAPSHOT | Loading region
 digraph persistence
 2014-09-08 10:11:35,310 | INFO  | FelixStartLevel  |
 RegionsPersistenceImpl   | 63 -
 org.apache.karaf.region.persist - 3.0.2.SNAPSHOT | initializing
 region digraph from etc/regions-config.xml
 2014-09-08 10:11:35,467 | INFO  | FelixStartLevel  |
 BlueprintContainerImpl   | 15 -
 org.apache.aries.blueprint.core - 1.4.1 | Bundle
 org.apache.karaf.bundle.command is waiting for dependencies
 [(objectClass=org.apache.karaf.bundle.core.BundleWatcher),
 (objectClass=org.apache.karaf.bundle.core.BundleService)]
 2014-09-08 10:11:35,479 | INFO  | rint Extender: 3 |
 BlueprintContainerImpl   | 15 -
 org.apache.aries.blueprint.core - 1.4.1 | Bundle
 org.apache.karaf.bundle.command is waiting for dependencies
 [(objectClass=org.apache.karaf.bundle.core.BundleService)]
 2014-09-08 10:11:48,657 | INFO  | Local user karaf |
 FeaturesServiceImpl  | 20 -
 org.apache.karaf.features.core - 3.0.2.SNAPSHOT | Installing
 feature transaction 1.1.0
 2014-09-08 10:11:48,688 | INFO  | Local user karaf |
 BlueprintContainerImpl   | 15 -
 org.apache.aries.blueprint.core - 1.4.1 | Bundle
 org.apache.aries.transaction.blueprint is waiting for dependencies
 [(objectClass=javax.transaction.TransactionManager)]
 2014-09-08 10:11:48,722 | ERROR | es.transaction]) |
 configadmin  | 6 - org.apache.felix.configadmin
 - 1.8.0 | [org.osgi.service.cm.ManagedService, id=652,
 bundle=67/mvn:org.apache.aries.transaction/org.apache.aries.transaction.manager/1.1.0]:
 Unexpected problem updating configuration org.apache.aries.transaction
 java.lang.ExceptionInInitializerError
at
 org.apache.aries.transaction.internal.TransactionManagerService.init(TransactionManagerService.java:114)
at
 org.apache.aries.transaction.internal.Activator.updated(Activator.java:63)
at
 org.apache.felix.cm.impl.helper.ManagedServiceTracker.updateService(ManagedServiceTracker.java:148)[6:org.apache.felix.configadmin:1.8.0]
at
 org.apache.felix.cm.impl.helper.ManagedServiceTracker.provideConfiguration(ManagedServiceTracker.java:81)[6:org.apache.felix.configadmin:1.8.0]
at
 org.apache.felix.cm.impl.ConfigurationManager$ManagedServiceUpdate.provide(ConfigurationManager.java:1448)[6:org.apache.felix.configadmin:1.8.0]
at
 org.apache.felix.cm.impl.ConfigurationManager$ManagedServiceUpdate.run(ConfigurationManager.java:1404)[6:org.apache.felix.configadmin:1.8.0]
at
 org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:103)[6:org.apache.felix.configadmin:1.8.0]
at java.lang.Thread.run(Thread.java:745)[:1.7.0_67]
 Caused by: java.util.MissingResourceException: Can't find bundle
 for base name org.apache.aries.transaction.txManager, locale en_US
at
 

Re: Latest Karaf 3.0.2-SNAPSHOT build failure

[Sobkowiak, Krzysztof]

I'll check the ServiceMix build in the evening. Thanks for the fix

Best regards
Krzysztof

On 08.09.2014 08:42, Jean-Baptiste Onofré wrote:
 The build on Jenkins failed but for one itests failure, the assemblies
 and archetypes look ok now.

 Regards
 JB

 On 09/08/2014 04:12 AM, Rodrigo Serra wrote:
 Hello,

 Before commit 873fe82e25a146a3cd935a8e4662f42cca2b52c1 the
 compilation are broken. The first problem is the upgrade of pax web
 to  3.1.2-SNAPSHOT. I don’t have this jar in my m2, but c2eef4e fix
 the version but the current error emerge. Some thin in the middle of
 two commit broke the compilation to the current state.

 Regards,
 Rodrigo

 El 07/09/2014, a las 16:43, Jean-Baptiste Onofré j...@nanthrax.net
 escribió:

 Just adding dependency in the plugin section with wagon
 lightweight http should fix the problem. But:
 1/ I try to figure out why I don't have the issue on my machine
 2/ I already fixed that a while ago.

 I'm releasing ServiceMix Bundles, I will fix that just after
 (tomorrow morning probably).

 Regards
 JB

 On 09/07/2014 10:23 AM, Krzysztof Sobkowiak wrote:
 The Jenkins Build runs probably on a Linux machine. I use Linux
 (64bit)
 too. Could it be a problem on Linux?

 Best regards
 Krzysztof

 On 07.09.2014 09:36, Jean-Baptiste Onofré wrote:
 For now, I can't reproduce on my machine, I'm still investigating.

 I keep you posted.

 Regards
 JB

 On 09/07/2014 01:26 AM, Krzysztof Sobkowiak wrote:
 This problem has been probably introduced by KARAF-3191 (Upgrade
 to Pax
 Web 3.1.2). After this commit the problem occurs on Jenkins too
 (https://builds.apache.org/view/All/job/karaf-3.0.x/291/)


 On 07.09.2014 00:36, Krzysztof Sobkowiak wrote:
 This problem doesn't occur on master and 2.x which use pax-logging
 2.1.0 too

 On 07.09.2014 00:25, Krzysztof Sobkowiak wrote:
 I could build the Karaf Assemblies after removing the m2
 repository.
 But similar problem still occurs while building Assembly
 Archetype --
 warning about missing LightweightHttpWagon and following error

 [INFO] [ERROR] Failed to execute goal on project assembly:
 Could not
 resolve dependencies for project
 archetype.it:assembly:karaf-assembly:0.1-SNAPSHOT: Failed to
 collect
 dependencies for
 [org.apache.karaf.features:framework:kar:3.0.2-SNAPSHOT (compile),
 org.apache.karaf.features:standard:xml:features:3.0.2-SNAPSHOT
 (runtime)]: Failed to read artifact descriptor for
 org.apache.aries.blueprint:org.apache.aries.blueprint.core:jar:1.2.0:

 Could not transfer artifact
 org.apache.aries.blueprint:org.apache.aries.blueprint.core:pom:1.2.0

 from/to central (http://repo.maven.apache.org/maven2): No
 connector
 available to access repository central
 (http://repo.maven.apache.org/maven2) of type default using the
 available factories WagonRepositoryConnectorFactory - [Help 1]
 [INFO] org.apache.maven.lifecycle.LifecycleExecutionException:
 Failed
 to execute goal on project assembly: Could not resolve
 dependencies
 for project archetype.it:assembly:karaf-assembly:0.1-SNAPSHOT:
 Failed
 to collect dependencies for
 [org.apache.karaf.features:framework:kar:3.0.2-SNAPSHOT (compile),
 org.apache.karaf.features:standard:xml:features:3.0.2-SNAPSHOT
 (runtime)]
 [INFO] at
 org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies(LifecycleDependencyResolver.java:210)


 [INFO] at
 org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies(LifecycleDependencyResolver.java:117)


 [INFO] at
 org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved(MojoExecutor.java:258)


 [INFO] at
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:201)


 [INFO] at
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)


 [INFO] at
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)


 [INFO] at
 org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)


 [INFO] at
 org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)


 [INFO] at
 org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)


 [INFO] at
 org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)


 [INFO] at
 org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
 [INFO] at
 org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
 [INFO] at
 org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
 [INFO] at
 org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
 [INFO] at
 org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
 [INFO] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
 Method)
 [INFO] at
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)


 [INFO] at
 

Re: Latest Karaf 3.0.2-SNAPSHOT build failure

[Sobkowiak, Krzysztof]

Hi Rodrigo

You probably use Maven 3.1.x or 3.2.x. Try with Maven 3.0.x

Best regards
Krzysztof

On 08.09.2014 12:08, Rodrigo Serra wrote:
 Hello JB,

 Now the build failt with this error:

 [ERROR] Failed to execute goal 
 org.apache.karaf.tooling:karaf-maven-plugin:3.0.2-SNAPSHOT:features-generate-descriptor
  (compile) on project framework: Execution compile of goal 
 org.apache.karaf.tooling:karaf-maven-plugin:3.0.2-SNAPSHOT:features-generate-descriptor
  failed: A required class was missing while executing 
 org.apache.karaf.tooling:karaf-maven-plugin:3.0.2-SNAPSHOT:features-generate-descriptor:
  org/sonatype/aether/RepositorySystem

 in module Apache Karaf :: Assemblies :: Features :: Framework”

 Regards,
 Rodrigo

 El 08/09/2014, a las 03:42, Jean-Baptiste Onofré j...@nanthrax.net escribió:

 The build on Jenkins failed but for one itests failure, the assemblies and 
 archetypes look ok now.

 Regards
 JB

 On 09/08/2014 04:12 AM, Rodrigo Serra wrote:
 Hello,

 Before commit 873fe82e25a146a3cd935a8e4662f42cca2b52c1 the compilation are 
 broken. The first problem is the upgrade of pax web to  3.1.2-SNAPSHOT. I 
 don’t have this jar in my m2, but c2eef4e fix the version but the current 
 error emerge. Some thin in the middle of two commit broke the compilation 
 to the current state.

 Regards,
 Rodrigo

 El 07/09/2014, a las 16:43, Jean-Baptiste Onofré j...@nanthrax.net 
 escribió:

 Just adding dependency in the plugin section with wagon lightweight http 
 should fix the problem. But:
 1/ I try to figure out why I don't have the issue on my machine
 2/ I already fixed that a while ago.

 I'm releasing ServiceMix Bundles, I will fix that just after (tomorrow 
 morning probably).

 Regards
 JB

 On 09/07/2014 10:23 AM, Krzysztof Sobkowiak wrote:
 The Jenkins Build runs probably on a Linux machine. I use Linux (64bit)
 too. Could it be a problem on Linux?

 Best regards
 Krzysztof

 On 07.09.2014 09:36, Jean-Baptiste Onofré wrote:
 For now, I can't reproduce on my machine, I'm still investigating.

 I keep you posted.

 Regards
 JB

 On 09/07/2014 01:26 AM, Krzysztof Sobkowiak wrote:
 This problem has been probably introduced by KARAF-3191 (Upgrade to Pax
 Web 3.1.2). After this commit the problem occurs on Jenkins too
 (https://builds.apache.org/view/All/job/karaf-3.0.x/291/)


 On 07.09.2014 00:36, Krzysztof Sobkowiak wrote:
 This problem doesn't occur on master and 2.x which use pax-logging
 2.1.0 too

 On 07.09.2014 00:25, Krzysztof Sobkowiak wrote:
 I could build the Karaf Assemblies after removing the m2 repository.
 But similar problem still occurs while building Assembly Archetype --
 warning about missing LightweightHttpWagon and following error

 [INFO] [ERROR] Failed to execute goal on project assembly: Could not
 resolve dependencies for project
 archetype.it:assembly:karaf-assembly:0.1-SNAPSHOT: Failed to collect
 dependencies for
 [org.apache.karaf.features:framework:kar:3.0.2-SNAPSHOT (compile),
 org.apache.karaf.features:standard:xml:features:3.0.2-SNAPSHOT
 (runtime)]: Failed to read artifact descriptor for
 org.apache.aries.blueprint:org.apache.aries.blueprint.core:jar:1.2.0:
 Could not transfer artifact
 org.apache.aries.blueprint:org.apache.aries.blueprint.core:pom:1.2.0
 from/to central (http://repo.maven.apache.org/maven2): No connector
 available to access repository central
 (http://repo.maven.apache.org/maven2) of type default using the
 available factories WagonRepositoryConnectorFactory - [Help 1]
 [INFO] org.apache.maven.lifecycle.LifecycleExecutionException: Failed
 to execute goal on project assembly: Could not resolve dependencies
 for project archetype.it:assembly:karaf-assembly:0.1-SNAPSHOT: Failed
 to collect dependencies for
 [org.apache.karaf.features:framework:kar:3.0.2-SNAPSHOT (compile),
 org.apache.karaf.features:standard:xml:features:3.0.2-SNAPSHOT
 (runtime)]
 [INFO] at
 org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies(LifecycleDependencyResolver.java:210)

 [INFO] at
 org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies(LifecycleDependencyResolver.java:117)

 [INFO] at
 org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved(MojoExecutor.java:258)

 [INFO] at
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:201)

 [INFO] at
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)

 [INFO] at
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)

 [INFO] at
 org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)

 [INFO] at
 org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)

 [INFO] at
 org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)

 [INFO] at
 

Re: [PROPOSAL] Remove default ssh key

[Sobkowiak, Krzysztof]

+1 (non-binding) for removing
On 18.07.2014 08:40, Achim Nierbeck wrote:
 +1 for removing

 and also +1 for the idea of Matt Sicker, a script for easy generating of
 keys.

 regards, Achim


 2014-07-18 6:58 GMT+02:00 Jean-Baptiste Onofré j...@nanthrax.net:

 Hi Freeman,

 thanks for the update ;)

 Regards
 JB


 On 07/18/2014 02:38 AM, Freeman Fang wrote:

 +1 to comment out the default public key in keys.properties, it's really
 a security hole.

 And about specify the key to bin/client, I just added it weeks ago,
 please see KARAF-3059[1]

 [1]https://issues.apache.org/jira/browse/KARAF-3059


 －
 Freeman(Yue) Fang

 Red Hat, Inc.
 FuseSource is now part of Red Hat



 On 2014-7-18, at 上午3:44, Jean-Baptiste Onofré wrote:

  Hi all,
 Following a discussion that we had with Christian, I would like to raise
 a concern.

 Now, on Karaf 2.x/3.x/4.x, the JMX layer is secure using RBAC. The
 MBeanServerBuilder is enabled by default, meaning that it's not possible to
 locally connect to the MBean server.
 I think it's good and secure.

 However, on the other hand, we have a key enabled by default (in
 etc/keys.properties) and used by default by bin/client.
 So it means that any user that download a Karaf distribution can connect
 to any Karaf runtimes by default.
 On one hand we have a very secure JMX layer (even for local connection),
 but on the other hand, bin/client can connect to any Karaf running instance
 (so not very secure).

 I would like to propose the following:
 - in etc/keys.properties, we should comment out the default key. We can
 document how to enable it and how to change the keys.
 - in bin/client, we should be able to specify a key that we want to use.

 WDYT ?

 I already created some Jira about the keys:
 - KARAF-2786: I would change this one by comment out the default key
 - KARAF-2836 to allow to specify multiple keys for an user in
 etc/keys.properties
 - KARAF-2787 to allow to specify the key to bin/client

 Thanks,
 Regards
 JB
 --
 Jean-Baptiste Onofré
 jbono...@apache.org
 http://blog.nanthrax.net
 Talend - http://www.talend.com



 --
 Jean-Baptiste Onofré
 jbono...@apache.org
 http://blog.nanthrax.net
 Talend - http://www.talend.com




-- 
Krzysztof Sobkowiak

JEE  OSS Architect | Technical Architect @ Capgemini | Committer @ ASF
Capgemini http://www.pl.capgemini.com/ | Software Solutions Center
http://www.pl.capgemini-sdm.com/ | Wroclaw
e-mail: krzys.sobkow...@gmail.com mailto:krzys.sobkow...@gmail.com |
Twitter: @KSobkowiak
Calendar: http://goo.gl/yvsebC

Re: [PROPOSAL] Remove default ssh key

[Sobkowiak, Krzysztof]

+1 good idea

On 18.07.2014 09:04, Jean-Baptiste Onofré wrote:
 More than a script, I propose:

 karaf@root() ssh:key-gen
 karaf@root() ssh:key-add

 And in the same area:

 karaf@root() shell:passwd

 to change the password.

 WDYT ?

 Regards
 JB

 On 07/18/2014 08:40 AM, Achim Nierbeck wrote:
 +1 for removing

 and also +1 for the idea of Matt Sicker, a script for easy generating of
 keys.

 regards, Achim


 2014-07-18 6:58 GMT+02:00 Jean-Baptiste Onofré j...@nanthrax.net:

 Hi Freeman,

 thanks for the update ;)

 Regards
 JB


 On 07/18/2014 02:38 AM, Freeman Fang wrote:

 +1 to comment out the default public key in keys.properties, it's
 really
 a security hole.

 And about specify the key to bin/client, I just added it weeks ago,
 please see KARAF-3059[1]

 [1]https://issues.apache.org/jira/browse/KARAF-3059


 －
 Freeman(Yue) Fang

 Red Hat, Inc.
 FuseSource is now part of Red Hat



 On 2014-7-18, at 上午3:44, Jean-Baptiste Onofré wrote:

   Hi all,

 Following a discussion that we had with Christian, I would like to
 raise
 a concern.

 Now, on Karaf 2.x/3.x/4.x, the JMX layer is secure using RBAC. The
 MBeanServerBuilder is enabled by default, meaning that it's not
 possible to
 locally connect to the MBean server.
 I think it's good and secure.

 However, on the other hand, we have a key enabled by default (in
 etc/keys.properties) and used by default by bin/client.
 So it means that any user that download a Karaf distribution can
 connect
 to any Karaf runtimes by default.
 On one hand we have a very secure JMX layer (even for local
 connection),
 but on the other hand, bin/client can connect to any Karaf running
 instance
 (so not very secure).

 I would like to propose the following:
 - in etc/keys.properties, we should comment out the default key.
 We can
 document how to enable it and how to change the keys.
 - in bin/client, we should be able to specify a key that we want
 to use.

 WDYT ?

 I already created some Jira about the keys:
 - KARAF-2786: I would change this one by comment out the default key
 - KARAF-2836 to allow to specify multiple keys for an user in
 etc/keys.properties
 - KARAF-2787 to allow to specify the key to bin/client

 Thanks,
 Regards
 JB
 -- 
 Jean-Baptiste Onofré
 jbono...@apache.org
 http://blog.nanthrax.net
 Talend - http://www.talend.com




 -- 
 Jean-Baptiste Onofré
 jbono...@apache.org
 http://blog.nanthrax.net
 Talend - http://www.talend.com






-- 
Krzysztof Sobkowiak

JEE  OSS Architect | Technical Architect @ Capgemini | Committer @ ASF
Capgemini http://www.pl.capgemini.com/ | Software Solutions Center
http://www.pl.capgemini-sdm.com/ | Wroclaw
e-mail: krzys.sobkow...@gmail.com mailto:krzys.sobkow...@gmail.com |
Twitter: @KSobkowiak
Calendar: http://goo.gl/yvsebC

Re: [PROPOSAL] Apache Karaf 2.3.6 release

[Sobkowiak, Krzysztof]

+1  (non-bnding)
On 03.06.2014 14:22, Jean-Baptiste Onofré wrote:
 Hi all,

 I propose to cut off a maintenance release on the karaf-2.3.x branch.

 I'm reviewing the Jira. Especially yesterday I fixed an issue in the
 hibernate 3 feature.
 There are a couple of issues waited on the ServiceMix side.

 In term of schedule, I propose to submit 2.3.6 to vote beginning of
 the next week.

 WDYT ?

 Regards
 JB

-- 
Krzysztof Sobkowiak

JEE  OSS Architect | Technical Architect @ Capgemini
Capgemini http://www.pl.capgemini.com/ | Software Solutions Center
http://www.pl.capgemini-sdm.com/ | Wroclaw
e-mail: krzys.sobkow...@gmail.com mailto:krzys.sobkow...@gmail.com |
Twitter: @KSobkowiak
Calendar: http://goo.gl/yvsebC

Re: Karaf blueprint Failure while extending console

[Sobkowiak, Krzysztof]

Hi Sapna

Does your bundle contain OSGi manifest data (version, symbolic name, etc)?

Best regards
Krzysztof


On 30.05.2014 09:00, SapnaB wrote:
 Hi All,


 In continuation with the above post, in the log files, I see 

 2014-05-29 23:15:04,448 | ERROR | l Console Thread | BlueprintContainerImpl   

 | container.BlueprintContainerImpl  393 | 7 -
 org.apache.aries.blueprint.core - 1.1.0 | *Unable to start blueprint
 container for bundle null*

 Why is the bundle name null? Is there some configuration required in the
 blueprint.xml file to provide an id to the bundle?

 Any help will be greatly appreciated.

 Thanks,
 Sapna



 --
 View this message in context: 
 http://karaf.922171.n3.nabble.com/Karaf-blueprint-Failure-while-extending-console-tp4029372p4033340.html
 Sent from the Karaf - Dev mailing list archive at Nabble.com.

-- 
Krzysztof Sobkowiak

JEE  OSS Architect | Technical Architect @ Capgemini
Capgemini http://www.pl.capgemini.com/ | Software Solutions Center
http://www.pl.capgemini-sdm.com/ | Wroclaw
e-mail: krzys.sobkow...@gmail.com mailto:krzys.sobkow...@gmail.com |
Twitter: @KSobkowiak
Calendar: http://goo.gl/yvsebC