from:"CLEMENT Jean\-Philippe"

RE: Is there an upgrade process for Karaf 4.1.0 to 4.1.1?

2017-04-05 Thread CLEMENT Jean-Philippe

I guess you don't have several servers with load balancing. So, would it be 
possible to start a temporary server which will replace the main one, then 
upgrade the main one and replace back the temporary one?

JP

-Message d'origine-
De : mtod09 [mailto:m...@thetods.net] 
Envoyé : mercredi 5 avril 2017 15:22
À : user@karaf.apache.org
Objet : Re: Is there an upgrade process for Karaf 4.1.0 to 4.1.1?

That does not sound like a good approach for a production system. If I have to 
rebuild for every new version of Karaf it would cause a big disruption in 
production. I would have to stop all inbound messaging then drain all the 
persisted messages before I could cut over to a new system. Not to mention 
stopping all Camel routes and stopping any system connecting to them.

That could take a while across regions.

Is there any other approach that could ease the pain?

I may have to rethink the architecture.

Mike 



--
View this message in context: 
http://karaf.922171.n3.nabble.com/Is-there-an-upgrade-process-for-Karaf-4-1-0-to-4-1-1-tp4050010p4050041.html
Sent from the Karaf - User mailing list archive at Nabble.com.

RE: https://issues.apache.org/jira/browse/KARAF-4829

2017-04-04 Thread CLEMENT Jean-Philippe

Ok crystal clear, thank you for the detailed explanation.

As we need synchronization in order to remove the first launch bug in our apps,
we will have to use instead of . Inlining configuration in
the tag would not be handy; it would be really nice to have a “location”
option. I raised the KARAF-5082 JIRA for this.

Kind regards,
JP

De : Guillaume Nodet [mailto:gno...@apache.org]
Envoyé : mardi 4 avril 2017 15:44
À : user
Objet : Re: https://issues.apache.org/jira/browse/KARAF-4829

Configuration files for ConfigAdmin are supposed to be used with the
element.
The element has been designed to support non-configadmin files,
such as xml, binaries, or whatever.

In both cases, when they come from a feature, they will be installed to the
file system before the bundles listed in the features are started.
The problem is that if you're using instead of , the
configuration won't be pushed to ConfigAdmin by the features service. They
will only end up in ConfigAdmin through fileinstall, and that's an asynchronous
process.

In short, the current design is the following:
* when using , the configuration is written synchronously to the disk
and config admin
* when using , the file is written synchronously to the disk

Your use case about expecting a synchronous write to config admin when using
is not supported currently.

The standard way to use is to inline the configuration, see a very
simple example here:

https://github.com/apache/karaf/blob/master/assemblies/features/standard/src/main/feature/feature.xml#L876-L879
If you really need the location attribute on the element, please raise
a JIRA.

2017-04-04 14:39 GMT+02:00 CLEMENT Jean-Philippe
<jean-philippe.clem...@fr.thalesgroup.com<mailto:jean-philippe.clem...@fr.thalesgroup.com>>:
Hi Guillaume,

Sorry, I’m lost :)

At present time I guess we use “regular” .cfg files (key/value pairs in basic
string format) via configfile tags. The issue is that they are populated in the
/etc directory at the same time bundles start (during the very first start), so
bundles may - or may not - find configuration properties. Here is an example of
how we use configfile tags:

mvn:some.example/whatever/1.0.0/cfg

As far as I understand bundles start and copy of .cfg file to etc being in
parallel seems to be a nominal case and we should use the config tag instead of
configfile to get .cfg files in the /etc before bundles start. Ok, so now I
wonder how to use .cfg files with the config tag. I’m not complaining about
anything… just trying to find out how it works.

> When used properly, config files are pushed to ConfigAdmin before bundles
> are started

Something like mvn:some.example/whatever/1.0.0/cfg?

Regards,
JP

De : Guillaume Nodet [mailto:gno...@apache.org<mailto:gno...@apache.org>]
Envoyé : lundi 3 avril 2017 19:26
À : user
Objet : Re: https://issues.apache.org/jira/browse/KARAF-4829

Btw, I closed the jira because the initial problem is not a problem per se.
When used properly, config files are pushed to ConfigAdmin before bundles are
started. This only happen because of the use of those typed properties files
which aren't really supported yet.

2017-04-03 19:22 GMT+02:00 Guillaume Nodet
<gno...@apache.org<mailto:gno...@apache.org>>:
You can use a properties file. Afaik, there's no problem with them and they
are fully supported.
Config files with typed properties will be supported through
KARAF-5074<https://issues.apache.org/jira/browse/KARAF-5074> which is a new
feature.

For the location attribute, a new JIRA would be required. But if you're
planning to use typed config files and use that attribute as a work around,
that's a bad idea, as other parts of Karaf will not support it.

Btw, if you want to speed up things a bit, as you seem quite vocal, one way
would be to provide some patches.

2017-04-03 18:41 GMT+02:00 CLEMENT Jean-Philippe
<jean-philippe.clem...@fr.thalesgroup.com<mailto:jean-philippe.clem...@fr.thalesgroup.com>>:
Hi,

The issue KARAF-4829 was closed. I thought I could now use the config tag as
long with a location attribute, but I’m wrong!

How to configure a feature in order configuration files to be installed prior
to bundle startup?

Thanks!

Regards,
JP

De : Guillaume Nodet [mailto:gno...@apache.org<mailto:gno...@apache.org>]
Envoyé : lundi 3 avril 2017 18:18
À : user
Objet : Re: Blueprint fails instantiating bean with generic constructor

2017-04-03 17:03 GMT+02:00 CLEMENT Jean-Philippe
<jean-philippe.clem...@fr.thalesgroup.com<mailto:jean-philippe.clem...@fr.thalesgroup.com>>:
I understand your point and you’re right, it’s better to test things early than
let the system crash later on. To go further I guess the Blueprint spec would
have to be enhanced to fully support generics, for instance to be able to
instantiate an ArrayList bean, to expose and retrieve services with
generics signature etc.

That's

RE: https://issues.apache.org/jira/browse/KARAF-4829

2017-04-04 Thread CLEMENT Jean-Philippe

Hi Guillaume,

Sorry, I’m lost :)

mvn:some.example/whatever/1.0.0/cfg

Ø When used properly, config files are pushed to ConfigAdmin before bundles
are started

Something like mvn:some.example/whatever/1.0.0/cfg?

Regards,
JP

De : Guillaume Nodet [mailto:gno...@apache.org]
Envoyé : lundi 3 avril 2017 19:26
À : user
Objet : Re: https://issues.apache.org/jira/browse/KARAF-4829

Btw, if you want to speed up things a bit, as you seem quite vocal, one way
would be to provide some patches.

2017-04-03 18:41 GMT+02:00 CLEMENT Jean-Philippe
<jean-philippe.clem...@fr.thalesgroup.com<mailto:jean-philippe.clem...@fr.thalesgroup.com>>:
Hi,

The issue KARAF-4829 was closed. I thought I could now use the config tag as
long with a location attribute, but I’m wrong!

How to configure a feature in order configuration files to be installed prior
to bundle startup?

Thanks!

Regards,
JP

De : Guillaume Nodet [mailto:gno...@apache.org<mailto:gno...@apache.org>]
Envoyé : lundi 3 avril 2017 18:18
À : user
Objet : Re: Blueprint fails instantiating bean with generic constructor

That's what I did to some degree with my ARIES-960 branch:
https://github.com/gnodet/aries/tree/ARIES-960/blueprint/blueprint-core

That's why I'd like some people to look at it and see if their actual use case
works.
From that point:
* they work, and that's great
* they don't work and they should, and I'll work on fixing those
* they don't work because they require ARIES-1633 which I don't have the time
to implement in the short term
In the third case, I could look at adding a flag...

That said, a fallback strategy could also be welcome in the meantime. And it
would be more efficient than letting the system try to convert, fail, then
finally use the custom “erasure converter” defined in the Blueprint.

Would it be possible to get a nice generics defeat flag?

Please provide a test case for my ARIES-960 branch which falls into the third
category above.

Regards,
JP

De : Guillaume Nodet [mailto:gno...@apache.org<mailto:gno...@apache.org>]
Envoyé : lundi 3 avril 2017 16:30

À : user
Objet : Re: Blueprint fails instantiating bean with generic constructor

I still am not comfortable allowing casting List to List as we
perfectly know what will happen.
Blueprint is not a compiler, but if you look at CDI, those kind of problems
have been handled correctly for example, and CDI is not a compiler either, but
both blueprint and CDI are dependency injection framework, so there's no
technical reason to not be able to support the use cases correctly, instead of
allowing ClassCastException at a later time.

2017-04-03 15:46 GMT+02:00 CLEMENT Jean-Philippe
<jean-philippe.clem...@fr.thalesgroup.com<mailto:jean-philippe.clem...@fr.thalesgroup.com>>:
Hi Guillaume,

As already discussed, Blueprint is not a compiler but a runtime library. Once
compiled there is no more generics as Java is

https://issues.apache.org/jira/browse/KARAF-4829

2017-04-03 Thread CLEMENT Jean-Philippe

Hi,

The issue KARAF-4829 was closed. I thought I could now use the config tag as
long with a location attribute, but I’m wrong!

How to configure a feature in order configuration files to be installed prior
to bundle startup?

Thanks!

Regards,
JP

De : Guillaume Nodet [mailto:gno...@apache.org]
Envoyé : lundi 3 avril 2017 18:18
À : user
Objet : Re: Blueprint fails instantiating bean with generic constructor

That's what I did to some degree with my ARIES-960 branch:
https://github.com/gnodet/aries/tree/ARIES-960/blueprint/blueprint-core

Would it be possible to get a nice generics defeat flag?

Please provide a test case for my ARIES-960 branch which falls into the third
category above.

Regards,
JP

De : Guillaume Nodet [mailto:gno...@apache.org<mailto:gno...@apache.org>]
Envoyé : lundi 3 avril 2017 16:30

À : user
Objet : Re: Blueprint fails instantiating bean with generic constructor

2017-04-03 15:46 GMT+02:00 CLEMENT Jean-Philippe
<jean-philippe.clem...@fr.thalesgroup.com<mailto:jean-philippe.clem...@fr.thalesgroup.com>>:
Hi Guillaume,

As already discussed, Blueprint is not a compiler but a runtime library. Once
compiled there is no more generics as Java is a type erasure language.
Moreover, I’m not too sure how Blueprint may handle injection with things like
S getSomething() where in java you can write myinstance.
getSomething().

I still do have issues with injection and generics, so a global flag to defeat
Blueprint checking would be greatly appreciated :)

De : Guillaume Nodet [mailto:gno...@apache.org<mailto:gno...@apache.org>]
Envoyé : lundi 3 avril 2017 14:31
À : user
Objet : Re: Blueprint fails instantiating bean with generic constructor

There are 2 different issues.
One is type erasure, i.e. allow the invocation of a method taking a
List with a List for example. That's ARIES-1607, and I really
think that's a bad idea, unless someone show me a good example where it makes
sense. At least by default (well, it's against the blueprint spec anyway). A
flag to turn on such a behavior (on a bean or globally) could be an acceptable
way, though.

Another issue is ARIES-960 where the same thing written in java would work.
That's a problem of type assignability verification and I'm willing to fix
those. I think that's more your use case. There's a branch I created a while
ago with some changes. Could you check if your use case works with the code
there ?

In all cases, a workaround is always to provide a custom blueprint converter,
as this would allow converting whatever you want to whatever is needed.

2017-04-03 11:23 GMT+02:00 CLEMENT Jean-Philippe
<jean-philippe.clem...@fr.thalesgroup.com<mailto:jean-philippe.clem...@fr.thalesgroup.com>>:
Hi Setya,

It might be related to an issue I opened last year:
https://issues.apache.org/jira/browse/ARIES-1607

At that time I was told to add a custom converter as a workaround. No update on
the Jira since then; maybe you may vote for it :)

Regards,
JP

-Message d'origine-
De : Setya [mailto:jse...@gmail.com<mailto:jse...@gmail.com>]
Envoyé : vendredi 31 mars 2017 19:09
À : user@karaf.apache.org<mailto:user@karaf.apache.org>
Objet : Blueprint fails instantiating bean with generic constructor

Hi all,

Aries Blueprint fails to instantiate bean with the following constructors:

public AggregateAnnotationCommandHandler(Class aggregateType, Repository
reposit

RE: Blueprint fails instantiating bean with generic constructor

2017-04-03 Thread CLEMENT Jean-Philippe

I understand your point and you’re right, it’s better to test things early than
let the system crash later on. To go further I guess the Blueprint spec would
have to be enhanced to fully support generics, for instance to be able to
instantiate an ArrayList bean, to expose and retrieve services with
generics signature etc.

Would it be possible to get a nice generics defeat flag?

Regards,
JP

De : Guillaume Nodet [mailto:gno...@apache.org]
Envoyé : lundi 3 avril 2017 16:30
À : user
Objet : Re: Blueprint fails instantiating bean with generic constructor

2017-04-03 15:46 GMT+02:00 CLEMENT Jean-Philippe
<jean-philippe.clem...@fr.thalesgroup.com<mailto:jean-philippe.clem...@fr.thalesgroup.com>>:
Hi Guillaume,

I still do have issues with injection and generics, so a global flag to defeat
Blueprint checking would be greatly appreciated :)

De : Guillaume Nodet [mailto:gno...@apache.org<mailto:gno...@apache.org>]
Envoyé : lundi 3 avril 2017 14:31
À : user
Objet : Re: Blueprint fails instantiating bean with generic constructor

In all cases, a workaround is always to provide a custom blueprint converter,
as this would allow converting whatever you want to whatever is needed.

2017-04-03 11:23 GMT+02:00 CLEMENT Jean-Philippe
<jean-philippe.clem...@fr.thalesgroup.com<mailto:jean-philippe.clem...@fr.thalesgroup.com>>:
Hi Setya,

It might be related to an issue I opened last year:
https://issues.apache.org/jira/browse/ARIES-1607

At that time I was told to add a custom converter as a workaround. No update on
the Jira since then; maybe you may vote for it :)

Regards,
JP

Hi all,

Aries Blueprint fails to instantiate bean with the following constructors:

public AggregateAnnotationCommandHandler(Class aggregateType, Repository
repository) { }

It seems to have problems with the second argument since it contains generic
parameter.

While it successfully instantiates the following bean:

public EventSourcingRepository(AggregateFactory aggregateFactory, EventStore
eventStore) { }

I'm using Apache Karaf 4.0.8.

Any insight would be greatly appreciated.

Thanks & Regards,
Setya

--
View this message in context:
http://karaf.922171.n3.nabble.com/Blueprint-fails-instantiating-bean-with-generic-constructor-tp4049986.html
Sent from the Karaf - User mailing list archive at Nabble.com.

Guillaume Nodet

RE: Blueprint fails instantiating bean with generic constructor

2017-04-03 Thread CLEMENT Jean-Philippe

Hi Guillaume,

I still do have issues with injection and generics, so a global flag to defeat
Blueprint checking would be greatly appreciated :)

De : Guillaume Nodet [mailto:gno...@apache.org]
Envoyé : lundi 3 avril 2017 14:31
À : user
Objet : Re: Blueprint fails instantiating bean with generic constructor

In all cases, a workaround is always to provide a custom blueprint converter,
as this would allow converting whatever you want to whatever is needed.

2017-04-03 11:23 GMT+02:00 CLEMENT Jean-Philippe
<jean-philippe.clem...@fr.thalesgroup.com<mailto:jean-philippe.clem...@fr.thalesgroup.com>>:
Hi Setya,

It might be related to an issue I opened last year:
https://issues.apache.org/jira/browse/ARIES-1607

At that time I was told to add a custom converter as a workaround. No update on
the Jira since then; maybe you may vote for it :)

Regards,
JP

Hi all,

Aries Blueprint fails to instantiate bean with the following constructors:

public AggregateAnnotationCommandHandler(Class aggregateType, Repository
repository) { }

It seems to have problems with the second argument since it contains generic
parameter.

While it successfully instantiates the following bean:

public EventSourcingRepository(AggregateFactory aggregateFactory, EventStore
eventStore) { }

I'm using Apache Karaf 4.0.8.

Any insight would be greatly appreciated.

Thanks & Regards,
Setya

Guillaume Nodet

RE: Blueprint fails instantiating bean with generic constructor

2017-04-03 Thread CLEMENT Jean-Philippe

Hi Setya,

It might be related to an issue I opened last year: 
https://issues.apache.org/jira/browse/ARIES-1607

At that time I was told to add a custom converter as a workaround. No update on 
the Jira since then; maybe you may vote for it :)

Regards,
JP

-Message d'origine-
De : Setya [mailto:jse...@gmail.com] 
Envoyé : vendredi 31 mars 2017 19:09
À : user@karaf.apache.org
Objet : Blueprint fails instantiating bean with generic constructor

Hi all,

Aries Blueprint fails to instantiate bean with the following constructors:

public AggregateAnnotationCommandHandler(Class aggregateType, Repository 
repository) { }

It seems to have problems with the second argument since it contains generic 
parameter.

While it successfully instantiates the following bean:

public EventSourcingRepository(AggregateFactory aggregateFactory, EventStore 
eventStore) { }

I'm using Apache Karaf 4.0.8.

Any insight would be greatly appreciated.

Thanks & Regards,
Setya



--
View this message in context: 
http://karaf.922171.n3.nabble.com/Blueprint-fails-instantiating-bean-with-generic-constructor-tp4049986.html
Sent from the Karaf - User mailing list archive at Nabble.com.

RE: KARAF-4829 Make sure configFile in features makes config available early

2017-03-31 Thread CLEMENT Jean-Philippe

Hi,

> In the mean time, can't you provision the cfg file in the etc folder during 
> assembly ?

Do you mean putting the cfg files in the resources directory of the assembly 
bundle? ...via an option in the feature "configfile" tags? ...other?

Regards,
JP

-Message d'origine-
De : Jean-Baptiste Onofré [mailto:j...@nanthrax.net] 
Envoyé : jeudi 30 mars 2017 19:30
À : user@karaf.apache.org
Objet : Re: KARAF-4829 Make sure configFile in features makes config available 
early

Hi,

we did an improvement today around this.

In the mean time, can't you provision the cfg file in the etc folder during 
assembly ?

Regards
JB

On 03/30/2017 05:17 PM, CLEMENT Jean-Philippe wrote:
> We build our assembly with the plugin you mentioned. But the assembly itself, 
> the .tar.gz does not contains the cfg files in the /etc. These files are 
> populated in the /etc during the first startup. The problem is that the 
> bundles are also started in parallel during the same time. So using them may 
> fail.
>
> Is there an option to force the karaf-maven-plugin to put the cfg files in 
> the /etc folder inside the .tar.gz archive?
>
> Regards,
> JP
>
> -Message d'origine-
> De : Jean-Baptiste Onofré [mailto:j...@nanthrax.net] Envoyé : mercredi 
> 29 mars 2017 19:14 À : user@karaf.apache.org Objet : Re: KARAF-4829 
> Make sure configFile in features makes config available early
>
> Hi JP,
>
> yes, you can create your custom distribution with resource: the 
> karaf-maven-plugin will include it in the final archive.
>
> Regards
> JB
>
> On 03/29/2017 07:02 PM, CLEMENT Jean-Philippe wrote:
>> Hi,
>>
>> About the issue KARAF-4829 about config files which may be available after 
>> bundles start, I'm looking for a workaround.
>>
>> Is there a way to force cfg files to be copied to /etc during assembly?
>>
>> Thanks!
>>
>> Regards,
>> JP
>>
>
> --
> 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

RE: KARAF-4829 Make sure configFile in features makes config available early

2017-03-30 Thread CLEMENT Jean-Philippe

We build our assembly with the plugin you mentioned. But the assembly itself, 
the .tar.gz does not contains the cfg files in the /etc. These files are 
populated in the /etc during the first startup. The problem is that the bundles 
are also started in parallel during the same time. So using them may fail.

Is there an option to force the karaf-maven-plugin to put the cfg files in the 
/etc folder inside the .tar.gz archive?

Regards,
JP

-Message d'origine-
De : Jean-Baptiste Onofré [mailto:j...@nanthrax.net] 
Envoyé : mercredi 29 mars 2017 19:14
À : user@karaf.apache.org
Objet : Re: KARAF-4829 Make sure configFile in features makes config available 
early

Hi JP,

yes, you can create your custom distribution with resource: the 
karaf-maven-plugin will include it in the final archive.

Regards
JB

On 03/29/2017 07:02 PM, CLEMENT Jean-Philippe wrote:
> Hi,
>
> About the issue KARAF-4829 about config files which may be available after 
> bundles start, I'm looking for a workaround.
>
> Is there a way to force cfg files to be copied to /etc during assembly?
>
> Thanks!
>
> Regards,
> JP
>

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

KARAF-4829 Make sure configFile in features makes config available early

2017-03-29 Thread CLEMENT Jean-Philippe

Hi,

About the issue KARAF-4829 about config files which may be available after 
bundles start, I'm looking for a workaround.

Is there a way to force cfg files to be copied to /etc during assembly?

Thanks!

Regards,
JP

RE: Don't understand: missing requirement

2016-12-14 Thread CLEMENT Jean-Philippe

Ah ok, well.. right, we did change exported service from com.y.SomeAPI to 
com.y.WonderSomeAPI where WonderSomeAPI extends SomeAPI.

Cannot the system match WonderSomeAPI service requirement to SomeAPI? Is there 
a way to export WonderSomeAPI as both itself and its parent API SomeAPI?

Regards,
JP

De : Guillaume Nodet [mailto:gno...@apache.org]
Envoyé : mercredi 14 décembre 2016 18:27
À : user
Objet : Re: Don't understand: missing requirement

The bundle has a requirement on an OSGi service using the interface/class 
com.y.SomeAPI

2016-12-14 18:10 GMT+01:00 CLEMENT Jean-Philippe 
<jean-philippe.clem...@fr.thalesgroup.com<mailto:jean-philippe.clem...@fr.thalesgroup.com>>:
Hello,

We did a small change somewhere leading a Karaf freeze. Karaf (4.0.7) is 
assembled with our features.

The log contains:
[caused by: Unable to resolve com.X/1.0.5.SNAPSHOT: missing requirement 
[com.X/1.0.5.SNAPSHOT] osgi.service; effective:=active; 
filter:="(objectClass=com.y.SomeAPI)"]

I don't really catch - what does this message mean?

Thank you :)

Regards,
JP



--

Guillaume Nodet

Red Hat, Open Source Integration

Email: gno...@redhat.com<mailto:gno...@redhat.com>
Web: http://fusesource.com<http://fusesource.com/>
Blog: http://gnodet.blogspot.com/

RE: Karaf shutdown

2016-11-21 Thread CLEMENT Jean-Philippe

ð  Created the Jira KARAF-4826<https://issues.apache.org/jira/browse/KARAF-4826>

Thank you !

Regards,
JP

De : Guillaume Nodet [mailto:gno...@apache.org]
Envoyé : lundi 21 novembre 2016 10:57
À : user
Objet : Re: Karaf shutdown



2016-11-21 10:30 GMT+01:00 CLEMENT Jean-Philippe 
<jean-philippe.clem...@fr.thalesgroup.com<mailto:jean-philippe.clem...@fr.thalesgroup.com>>:
Would be great ! It would also be nice to be able to call it programmatically, 
or, at least have a default shutdown timeout.

May I open a Jira?

Yes please. We'll see that's doable.
The various commands can already be called programmatically by using the 
org.apache.karaf.system.SystemService
OSGi service.  We just need an additional parameter for the shutdown timeout.


Regards,
JP

-Message d'origine-
De : Jean-Baptiste Onofré [mailto:j...@nanthrax.net<mailto:j...@nanthrax.net>]
Envoyé : lundi 21 novembre 2016 10:27
À : user@karaf.apache.org<mailto:user@karaf.apache.org>
Objet : Re: Karaf shutdown

+1

Regards
JB

On 11/21/2016 10:25 AM, Guillaume Nodet wrote:
> We could easily add an option to the shutdown command for that.
>
> 2016-11-21 10:21 GMT+01:00 CLEMENT Jean-Philippe
> <jean-philippe.clem...@fr.thalesgroup.com<mailto:jean-philippe.clem...@fr.thalesgroup.com>
> <mailto:jean-philippe.clem...@fr.thalesgroup.com<mailto:jean-philippe.clem...@fr.thalesgroup.com>>>:
>
> Ok, things clear, thank you for the detailed explanation :)
>
> __ __
>
> In fact I just want to ensure Karaf to shut down within a given time
> limit. Is there a way to do so?
>
> __ __
>
> Regards,
>
> JP
>
> __ __
>
> *De :*Guillaume Nodet [mailto:gno...@apache.org<mailto:gno...@apache.org>
> <mailto:gno...@apache.org<mailto:gno...@apache.org>>]
> *Envoyé :* vendredi 18 novembre 2016 20:16
>
>
> *À :* user
> *Objet :* Re: Karaf shutdown
>
> __ __
>
> __ __
>
> __ __
>
> 2016-11-18 17:58 GMT+01:00 CLEMENT Jean-Philippe
> 
> <jean-philippe.clem...@fr.thalesgroup.com<mailto:jean-philippe.clem...@fr.thalesgroup.com>
> 
> <mailto:jean-philippe.clem...@fr.thalesgroup.com<mailto:jean-philippe.clem...@fr.thalesgroup.com>>>:
>
> Well, I’m not too sure to understand :)
>
>  
>
> I will only focus on bundle 0 and the stopping event I’m expecting
> from it. So, I put “that” bundle listener on the bundle 0 not on any
> other bundle. But, the way I get the bundle 0 is via a bundleContext
> which is injected via Blueprint.
>
>  
>
> That said, the spec says I should first get the event. Should not be
> tied to the actual stopping order, isn’t it (Blueprint or
> not)?
>
> __ __
>
> The STOPPING events are distributed to various listeners
> synchronously.  The blueprint extender will receive it before your
> own listener (because it's registered before), so the preemptive
> shutdown will take place before you can do anything.  This also
> means that your bundle containing the listener will be stopped
> before receiving the STOPPING event.
>
> Note that the purpose of this behavior is to avoid having blueprint
> bundles trying to call a missing mandatory dependency during
> shutdown, amongst other things.  If your bundle stuck waiting for a
> blueprint dependency or something else ?  There is certainly still
> some room for improvements in blueprint-core when shutting down
> bundles.
>
> __ __
>
>  
>
>  
>
> Regards,
>
> JP
>
>  
>
> *De :*Guillaume Nodet 
> [mailto:gno...@apache.org<mailto:gno...@apache.org>
> <mailto:gno...@apache.org<mailto:gno...@apache.org>>]
> *Envoyé :* vendredi 18 novembre 2016 17:04
>
>
> *À :* user
> *Objet :* Re: Karaf shutdown
>
>  
>
> You have 2 events for each bundle (but for the system bundle,
> the first event which is a STOPPING event).
>
> For each of those 2 events, the first one is a STOPPING, then
> the framework calls the activator stop, then fire a STOPPED
> event.
>
>  
>
> Are you sure you're using activators ? because the problem may
> be completely different if using a blueprint extender and a
> blueprint event that does not stop.
>
> In that case, what happens is that the blueprint extender
> intercepts the STOPPING event from the system bundle and
>

RE: Karaf shutdown

2016-11-21 Thread CLEMENT Jean-Philippe

Would be great ! It would also be nice to be able to call it programmatically, 
or, at least have a default shutdown timeout.

May I open a Jira?

Regards,
JP

-Message d'origine-
De : Jean-Baptiste Onofré [mailto:j...@nanthrax.net]
Envoyé : lundi 21 novembre 2016 10:27
À : user@karaf.apache.org
Objet : Re: Karaf shutdown

+1

Regards
JB

On 11/21/2016 10:25 AM, Guillaume Nodet wrote:
> We could easily add an option to the shutdown command for that.
>
> 2016-11-21 10:21 GMT+01:00 CLEMENT Jean-Philippe
> <jean-philippe.clem...@fr.thalesgroup.com
> <mailto:jean-philippe.clem...@fr.thalesgroup.com>>:
>
> Ok, things clear, thank you for the detailed explanation :)
>
> __ __
>
> In fact I just want to ensure Karaf to shut down within a given time
> limit. Is there a way to do so?
>
> __ __
>
> Regards,
>
> JP
>
> __ __
>
> *De :*Guillaume Nodet [mailto:gno...@apache.org
> <mailto:gno...@apache.org>]
> *Envoyé :* vendredi 18 novembre 2016 20:16
>
>
> *À :* user
> *Objet :* Re: Karaf shutdown____
>
> __ __
>
> __ __
>
> __ __
>
> 2016-11-18 17:58 GMT+01:00 CLEMENT Jean-Philippe
> <jean-philippe.clem...@fr.thalesgroup.com
> <mailto:jean-philippe.clem...@fr.thalesgroup.com>>:
>
> Well, I’m not too sure to understand :)
>
>  
>
> I will only focus on bundle 0 and the stopping event I’m expecting
> from it. So, I put “that” bundle listener on the bundle 0 not on any
> other bundle. But, the way I get the bundle 0 is via a bundleContext
> which is injected via Blueprint.
>
>  
>
> That said, the spec says I should first get the event. Should not be
> tied to the actual stopping order, isn’t it (Blueprint or
> not)?
>
> __ __
>
> The STOPPING events are distributed to various listeners
> synchronously.  The blueprint extender will receive it before your
> own listener (because it's registered before), so the preemptive
> shutdown will take place before you can do anything.  This also
> means that your bundle containing the listener will be stopped
> before receiving the STOPPING event.
>
> Note that the purpose of this behavior is to avoid having blueprint
> bundles trying to call a missing mandatory dependency during
> shutdown, amongst other things.  If your bundle stuck waiting for a
> blueprint dependency or something else ?  There is certainly still
> some room for improvements in blueprint-core when shutting down
> bundles.
>
> __ __
>
>  
>
>  
>
> Regards,
>
> JP
>
>  
>
> *De :*Guillaume Nodet [mailto:gno...@apache.org
> <mailto:gno...@apache.org>]
> *Envoyé :* vendredi 18 novembre 2016 17:04
>
>
> *À :* user
> *Objet :* Re: Karaf shutdown
>
>  
>
> You have 2 events for each bundle (but for the system bundle,
> the first event which is a STOPPING event).
>
> For each of those 2 events, the first one is a STOPPING, then
> the framework calls the activator stop, then fire a STOPPED
> event.
>
>  
>
> Are you sure you're using activators ? because the problem may
> be completely different if using a blueprint extender and a
> blueprint event that does not stop.
>
> In that case, what happens is that the blueprint extender
> intercepts the STOPPING event from the system bundle and
> preemptively shutdown all blueprint bundles in an orderly
> fashion.  This usually helps by choosing a better stopping order
> than the default one, depending on service used between
> bundles.  The problem is that given the extender stops the
> blueprint bundles preemptively, the bundles will be stopped
> before the framework has a change to send the STOPPING event for
> the bundle.  It's actually the same as if you would stop the
> blueprint extender in a running framework: all blueprint
> containers will be destroyed, but the lifecycle of the bundles
> would not be affected.  This behavior can be turned off by
> using
>
>   *org.apache.aries.blueprint.preemptiveShutdown=false*
>
> in the etc/config.properties file.
>
>  
>
> 2016-11-18 16:49 GMT+01:00 CLEMENT Jean-Philippe
> <jean-philippe.clem...@fr.thalesgroup.com
> <mailto:jean-phi

RE: Karaf shutdown

2016-11-21 Thread CLEMENT Jean-Philippe

Ok, things clear, thank you for the detailed explanation :)

In fact I just want to ensure Karaf to shut down within a given time limit. Is 
there a way to do so?

Regards,
JP

De : Guillaume Nodet [mailto:gno...@apache.org]
Envoyé : vendredi 18 novembre 2016 20:16
À : user
Objet : Re: Karaf shutdown



2016-11-18 17:58 GMT+01:00 CLEMENT Jean-Philippe 
<jean-philippe.clem...@fr.thalesgroup.com<mailto:jean-philippe.clem...@fr.thalesgroup.com>>:
Well, I’m not too sure to understand :)

I will only focus on bundle 0 and the stopping event I’m expecting from it. So, 
I put “that” bundle listener on the bundle 0 not on any other bundle. But, the 
way I get the bundle 0 is via a bundleContext which is injected via Blueprint.

That said, the spec says I should first get the event. Should not be tied to 
the actual stopping order, isn’t it (Blueprint or not)?

The STOPPING events are distributed to various listeners synchronously.  The 
blueprint extender will receive it before your own listener (because it's 
registered before), so the preemptive shutdown will take place before you can 
do anything.  This also means that your bundle containing the listener will be 
stopped before receiving the STOPPING event.
Note that the purpose of this behavior is to avoid having blueprint bundles 
trying to call a missing mandatory dependency during shutdown, amongst other 
things.  If your bundle stuck waiting for a blueprint dependency or something 
else ?  There is certainly still some room for improvements in blueprint-core 
when shutting down bundles.



Regards,
JP

De : Guillaume Nodet [mailto:gno...@apache.org<mailto:gno...@apache.org>]
Envoyé : vendredi 18 novembre 2016 17:04

À : user
Objet : Re: Karaf shutdown

You have 2 events for each bundle (but for the system bundle, the first event 
which is a STOPPING event).
For each of those 2 events, the first one is a STOPPING, then the framework 
calls the activator stop, then fire a STOPPED event.

Are you sure you're using activators ? because the problem may be completely 
different if using a blueprint extender and a blueprint event that does not 
stop.
In that case, what happens is that the blueprint extender intercepts the 
STOPPING event from the system bundle and preemptively shutdown all blueprint 
bundles in an orderly fashion.  This usually helps by choosing a better 
stopping order than the default one, depending on service used between bundles. 
 The problem is that given the extender stops the blueprint bundles 
preemptively, the bundles will be stopped before the framework has a change to 
send the STOPPING event for the bundle.  It's actually the same as if you would 
stop the blueprint extender in a running framework: all blueprint containers 
will be destroyed, but the lifecycle of the bundles would not be affected.  
This behavior can be turned off by using
  org.apache.aries.blueprint.preemptiveShutdown=false
in the etc/config.properties file.

2016-11-18 16:49 GMT+01:00 CLEMENT Jean-Philippe 
<jean-philippe.clem...@fr.thalesgroup.com<mailto:jean-philippe.clem...@fr.thalesgroup.com>>:
In fact I guess that’s the problem, the event seems not to be fired before 
stopping bundles.

When all bundles react normally, i.e. they stop, I get the stopping event. When 
at least one does not stop as expected, then I get no stopping event. Would you 
be kind enough to try again with a non-stopping-bundle and displaying the event 
type?

Regards,
JP

De : Guillaume Nodet [mailto:gno...@apache.org<mailto:gno...@apache.org>]
Envoyé : vendredi 18 novembre 2016 16:40

À : user
Objet : Re: Karaf shutdown



2016-11-18 15:01 GMT+01:00 CLEMENT Jean-Philippe 
<jean-philippe.clem...@fr.thalesgroup.com<mailto:jean-philippe.clem...@fr.thalesgroup.com>>:
Did you also add a bundle which prevents stopping ?

No, but the first event is sent before actually stopping any bundle.


PS: in your traces which event is the shutdown itself?

It's not, because I paste a wrong output.
Here's the full output, and the interesting event is the first one.  It's 
should be a STOPPING event.


karaf@root()> ($.context bundle 0) stop 1   

   
org.osgi.framework.BundleEvent[source=org.eclipse.osgi_3.10.101.v20150820-1432 
[0]]

org.osgi.framework.BundleEvent[source=org.jline_3.0.1 [34]]

org.osgi.framework.BundleEvent[source=org.jline_3.0.1 [34]]

org.osgi.framework.BundleEvent[source=org.fusesource.jansi_1.14.0 [33]]

org.osgi.framework.BundleEvent[source=org.fusesource.jansi_1.14.0 [33]]

org.osgi.framework.BundleEvent[source=org.apache.sshd.core_1.2.0 [32]]

org.osgi.framework.BundleEvent[source=org.apache.sshd.core_1.2.0 [32]]

org.osgi.framework.BundleEvent[source=org.apache.servicemix.bundles.not-yet-commons-ssl_0.3.11.1
 [31]]

org.osgi.framework.BundleEvent[source=org.apache.servicemix.bundle

RE: Karaf shutdown

2016-11-18 Thread CLEMENT Jean-Philippe

Well, I’m not too sure to understand :)

I will only focus on bundle 0 and the stopping event I’m expecting from it. So, 
I put “that” bundle listener on the bundle 0 not on any other bundle. But, the 
way I get the bundle 0 is via a bundleContext which is injected via Blueprint.

That said, the spec says I should first get the event. Should not be tied to 
the actual stopping order, isn’t it (Blueprint or not)?

Regards,
JP

De : Guillaume Nodet [mailto:gno...@apache.org]
Envoyé : vendredi 18 novembre 2016 17:04
À : user
Objet : Re: Karaf shutdown

You have 2 events for each bundle (but for the system bundle, the first event 
which is a STOPPING event).
For each of those 2 events, the first one is a STOPPING, then the framework 
calls the activator stop, then fire a STOPPED event.

Are you sure you're using activators ? because the problem may be completely 
different if using a blueprint extender and a blueprint event that does not 
stop.
In that case, what happens is that the blueprint extender intercepts the 
STOPPING event from the system bundle and preemptively shutdown all blueprint 
bundles in an orderly fashion.  This usually helps by choosing a better 
stopping order than the default one, depending on service used between bundles. 
 The problem is that given the extender stops the blueprint bundles 
preemptively, the bundles will be stopped before the framework has a change to 
send the STOPPING event for the bundle.  It's actually the same as if you would 
stop the blueprint extender in a running framework: all blueprint containers 
will be destroyed, but the lifecycle of the bundles would not be affected.  
This behavior can be turned off by using
  org.apache.aries.blueprint.preemptiveShutdown=false
in the etc/config.properties file.

2016-11-18 16:49 GMT+01:00 CLEMENT Jean-Philippe 
<jean-philippe.clem...@fr.thalesgroup.com<mailto:jean-philippe.clem...@fr.thalesgroup.com>>:
In fact I guess that’s the problem, the event seems not to be fired before 
stopping bundles.

When all bundles react normally, i.e. they stop, I get the stopping event. When 
at least one does not stop as expected, then I get no stopping event. Would you 
be kind enough to try again with a non-stopping-bundle and displaying the event 
type?

Regards,
JP

De : Guillaume Nodet [mailto:gno...@apache.org<mailto:gno...@apache.org>]
Envoyé : vendredi 18 novembre 2016 16:40

À : user
Objet : Re: Karaf shutdown



2016-11-18 15:01 GMT+01:00 CLEMENT Jean-Philippe 
<jean-philippe.clem...@fr.thalesgroup.com<mailto:jean-philippe.clem...@fr.thalesgroup.com>>:
Did you also add a bundle which prevents stopping ?

No, but the first event is sent before actually stopping any bundle.


PS: in your traces which event is the shutdown itself?

It's not, because I paste a wrong output.
Here's the full output, and the interesting event is the first one.  It's 
should be a STOPPING event.


karaf@root()> ($.context bundle 0) stop 1   

   
org.osgi.framework.BundleEvent[source=org.eclipse.osgi_3.10.101.v20150820-1432 
[0]]

org.osgi.framework.BundleEvent[source=org.jline_3.0.1 [34]]

org.osgi.framework.BundleEvent[source=org.jline_3.0.1 [34]]

org.osgi.framework.BundleEvent[source=org.fusesource.jansi_1.14.0 [33]]

org.osgi.framework.BundleEvent[source=org.fusesource.jansi_1.14.0 [33]]

org.osgi.framework.BundleEvent[source=org.apache.sshd.core_1.2.0 [32]]

org.osgi.framework.BundleEvent[source=org.apache.sshd.core_1.2.0 [32]]

org.osgi.framework.BundleEvent[source=org.apache.servicemix.bundles.not-yet-commons-ssl_0.3.11.1
 [31]]

org.osgi.framework.BundleEvent[source=org.apache.servicemix.bundles.not-yet-commons-ssl_0.3.11.1
 [31]]
...


Regards,
JP

De : Guillaume Nodet [mailto:gno...@apache.org<mailto:gno...@apache.org>]
Envoyé : vendredi 18 novembre 2016 14:26

À : user
Objet : Re: Karaf shutdown

You must be doing something wrong.
I added this small bit of code to one of karaf's activators:

bundleContext.getBundle(0).getBundleContext().addBundleListener(new 
SynchronousBundleListener() {
@Override
public void bundleChanged(BundleEvent event) {
System.out.println(event);
}
});



Here's the output when stopping under equinox:

karaf@root()> ($.context bundle 0) stop 1   
  
org.osgi.framework.BundleEvent[source=org.apache.karaf.shell.core_4.1.0.SNAPSHOT
 [28]]

org.osgi.framework.BundleEvent[source=org.apache.karaf.shell.commands_4.1.0.SNAPSHOT
 [27]]

org.osgi.framework.BundleEvent[source=org.apache.karaf.shell.commands_4.1.0.SNAPSHOT
 [27]]

org.osgi.framework.BundleEvent[source=org.apache.karaf.service.core_4.1.0.SNAPSHOT
 [26]]

org.osgi.framework.BundleEvent[source=org.apache.karaf.service.core_4.1.0.SNAPSHOT
 [26]]

org.osgi.framework.BundleEvent[source=org.apa

RE: Karaf shutdown

2016-11-18 Thread CLEMENT Jean-Philippe

In fact I guess that’s the problem, the event seems not to be fired before 
stopping bundles.

When all bundles react normally, i.e. they stop, I get the stopping event. When 
at least one does not stop as expected, then I get no stopping event. Would you 
be kind enough to try again with a non-stopping-bundle and displaying the event 
type?

Regards,
JP

De : Guillaume Nodet [mailto:gno...@apache.org]
Envoyé : vendredi 18 novembre 2016 16:40
À : user
Objet : Re: Karaf shutdown



2016-11-18 15:01 GMT+01:00 CLEMENT Jean-Philippe 
<jean-philippe.clem...@fr.thalesgroup.com<mailto:jean-philippe.clem...@fr.thalesgroup.com>>:
Did you also add a bundle which prevents stopping ?

No, but the first event is sent before actually stopping any bundle.


PS: in your traces which event is the shutdown itself?

It's not, because I paste a wrong output.
Here's the full output, and the interesting event is the first one.  It's 
should be a STOPPING event.


karaf@root()> ($.context bundle 0) stop 1   

   
org.osgi.framework.BundleEvent[source=org.eclipse.osgi_3.10.101.v20150820-1432 
[0]]

org.osgi.framework.BundleEvent[source=org.jline_3.0.1 [34]]

org.osgi.framework.BundleEvent[source=org.jline_3.0.1 [34]]

org.osgi.framework.BundleEvent[source=org.fusesource.jansi_1.14.0 [33]]

org.osgi.framework.BundleEvent[source=org.fusesource.jansi_1.14.0 [33]]

org.osgi.framework.BundleEvent[source=org.apache.sshd.core_1.2.0 [32]]

org.osgi.framework.BundleEvent[source=org.apache.sshd.core_1.2.0 [32]]

org.osgi.framework.BundleEvent[source=org.apache.servicemix.bundles.not-yet-commons-ssl_0.3.11.1
 [31]]

org.osgi.framework.BundleEvent[source=org.apache.servicemix.bundles.not-yet-commons-ssl_0.3.11.1
 [31]]
...


Regards,
JP

De : Guillaume Nodet [mailto:gno...@apache.org<mailto:gno...@apache.org>]
Envoyé : vendredi 18 novembre 2016 14:26

À : user
Objet : Re: Karaf shutdown

You must be doing something wrong.
I added this small bit of code to one of karaf's activators:

bundleContext.getBundle(0).getBundleContext().addBundleListener(new 
SynchronousBundleListener() {
@Override
public void bundleChanged(BundleEvent event) {
System.out.println(event);
}
});



Here's the output when stopping under equinox:

karaf@root()> ($.context bundle 0) stop 1   
  
org.osgi.framework.BundleEvent[source=org.apache.karaf.shell.core_4.1.0.SNAPSHOT
 [28]]

org.osgi.framework.BundleEvent[source=org.apache.karaf.shell.commands_4.1.0.SNAPSHOT
 [27]]

org.osgi.framework.BundleEvent[source=org.apache.karaf.shell.commands_4.1.0.SNAPSHOT
 [27]]

org.osgi.framework.BundleEvent[source=org.apache.karaf.service.core_4.1.0.SNAPSHOT
 [26]]

org.osgi.framework.BundleEvent[source=org.apache.karaf.service.core_4.1.0.SNAPSHOT
 [26]]

org.osgi.framework.BundleEvent[source=org.apache.karaf.package.core_4.1.0.SNAPSHOT
 [25]]

org.osgi.framework.BundleEvent[source=org.apache.karaf.package.core_4.1.0.SNAPSHOT
 [25]]

org.osgi.framework.BundleEvent[source=org.apache.karaf.management.server_4.1.0.SNAPSHOT
 [24]]

org.osgi.framework.BundleEvent[source=org.apache.karaf.management.server_4.1.0.SNAPSHOT
 [24]]

org.osgi.framework.BundleEvent[source=org.apache.karaf.log.core_4.1.0.SNAPSHOT 
[23]]

org.osgi.framework.BundleEvent[source=org.apache.karaf.log.core_4.1.0.SNAPSHOT 
[23]]

org.osgi.framework.BundleEvent[source=org.apache.karaf.kar.core_4.1.0.SNAPSHOT 
[22]]

org.osgi.framework.BundleEvent[source=org.apache.karaf.kar.core_4.1.0.SNAPSHOT 
[22]]

org.osgi.framework.BundleEvent[source=org.apache.karaf.jaas.modules_4.1.0.SNAPSHOT
 [21]]

org.osgi.framework.BundleEvent[source=org.apache.karaf.jaas.modules_4.1.0.SNAPSHOT
 [21]]

org.osgi.framework.BundleEvent[source=org.apache.karaf.jaas.config_4.1.0.SNAPSHOT
 [20]]

org.osgi.framework.BundleEvent[source=org.apache.karaf.jaas.config_4.1.0.SNAPSHOT
 [20]]

org.osgi.framework.BundleEvent[source=org.apache.karaf.jaas.command_4.1.0.SNAPSHOT
 [19]]

org.osgi.framework.BundleEvent[source=org.apache.karaf.jaas.command_4.1.0.SNAPSHOT
 [19]]

org.osgi.framework.BundleEvent[source=org.apache.karaf.instance.core_4.1.0.SNAPSHOT
 [18]]

org.osgi.framework.BundleEvent[source=org.apache.karaf.instance.core_4.1.0.SNAPSHOT
 [18]]

org.osgi.framework.BundleEvent[source=org.apache.karaf.features.command_4.1.0.SNAPSHOT
 [17]]

org.osgi.framework.BundleEvent[source=org.apache.karaf.features.command_4.1.0.SNAPSHOT
 [17]]

org.osgi.framework.BundleEvent[source=org.apache.karaf.diagnostic.core_4.1.0.SNAPSHOT
 [16]]

org.osgi.framework.BundleEvent[source=org.apache.karaf.diagnostic.core_4.1.0.SNAPSHOT
 [16]]

org.osgi.framework.BundleEvent[source=org.apache.karaf.config.core_4.1.0.SNAPSHOT
 [13]]

org.osgi.framework.BundleEvent[source=org.apache.karaf.config.core_4.1.0.SNAPSHOT
 [13]]

org.os

RE: Karaf shutdown

2016-11-18 Thread CLEMENT Jean-Philippe

rce=org.ops4j.pax.logging.pax-logging-log4j2_1.9.1
 [4]]

org.osgi.framework.BundleEvent[source=org.ops4j.pax.logging.pax-logging-api_1.9.1
 [3]]

org.osgi.framework.BundleEvent[source=org.ops4j.pax.logging.pax-logging-api_1.9.1
 [3]]

org.osgi.framework.BundleEvent[source=org.ops4j.pax.url.mvn_2.5.1 [2]]

org.osgi.framework.BundleEvent[source=org.ops4j.pax.url.mvn_2.5.1 [2]]

gnodet•apache-karaf-minimal/target/assembly(master⚡)»






2016-11-18 13:29 GMT+01:00 CLEMENT Jean-Philippe 
<jean-philippe.clem...@fr.thalesgroup.com<mailto:jean-philippe.clem...@fr.thalesgroup.com>>:
That’s exactly what I did. The listener is not called at all. Looking at 
bundles, some are Active, some Resolved, one Installed (OSGi System Bundle 
3.10.2.v20150203-1939) and one Waiting (one of mine).

public final class KarafStopper {
private static final Logger LOG = 
LogManager.getLogger(KarafStopper.class);
private static final long   TIMEOUT = 3 * 1000; 
  // in milliseconds

private final Bundlekaraf;

public KarafStopper(final BundleContext context) {
System.out.println("=> blabla");
karaf = context.getBundle(0);
karaf.getBundleContext().addBundleListener(new 
SynchronousBundleListener() {
@Override
public void bundleChanged(final BundleEvent event) {
System.out.println("Karaf: " + event.getType());
}
});
}

public void shutdown() {
try {
final Thread watchdog = new Thread(() -> {
try {
Thread.sleep(TIMEOUT);
// Karaf refuses to stop
LOG.error(() -> "Karaf did not stop gracefully");
System.exit(-1);
} catch (final InterruptedException e) {
// Karaf stopped normally
}
});

watchdog.setDaemon(true);
watchdog.start();
System.out.println("Bye bye");
karaf.stop(Bundle.STOP_TRANSIENT);
System.out.println("So long!");
} catch (final BundleException e) {
System.out.println("Oooops: " + e);
LOG.error(() -> "Issue while stopping karaf", e);
}
}
}

Regards,
JP

De : Guillaume Nodet [mailto:gno...@apache.org<mailto:gno...@apache.org>]
Envoyé : vendredi 18 novembre 2016 13:01

À : user
Objet : Re: Karaf shutdown

Can you write a simple SynchronousBundleListener that prints to stdout all 
received events and paste the output when stopping the framework for felix and 
equinox ?

2016-11-18 12:10 GMT+01:00 CLEMENT Jean-Philippe 
<jean-philippe.clem...@fr.thalesgroup.com<mailto:jean-philippe.clem...@fr.thalesgroup.com>>:
Well, that’s not the case when a bundle refuses to stop – I get no event. Ah I 
forgot to mention that Equinox is used instead of Felix.

May I open a bug for this?

Regards,
JP


De : Guillaume Nodet [mailto:gno...@apache.org<mailto:gno...@apache.org>]
Envoyé : vendredi 18 novembre 2016 11:52
À : user
Objet : Re: Karaf shutdown

The SynchronousBundleListener is the way to go.
You should receive a STOPPING event for the system bundle before any other 
bundle is actually stopped.

2016-11-18 11:38 GMT+01:00 CLEMENT Jean-Philippe 
<jean-philippe.clem...@fr.thalesgroup.com<mailto:jean-philippe.clem...@fr.thalesgroup.com>>:
Is there a way to get a shutdown event?

Regards,
JP

De : CLEMENT Jean-Philippe 
[mailto:jean-philippe.clem...@fr.thalesgroup.com<mailto:jean-philippe.clem...@fr.thalesgroup.com>]
Envoyé : jeudi 17 novembre 2016 17:03
À : user@karaf.apache.org<mailto:user@karaf.apache.org>
Objet : Karaf shutdown

Dear Karaf addicts :)

I would like Karaf to stop. This may fail to happen when (at least) a bundle 
does not end. So I added a watchdog which exits Java when a time limit has been 
exceeded (note: maybe there is already a way to do so - ?). The way I coded it 
does not work when the shutdown is made via the Karaf prompt, so I decided to 
enhance it.

Googling “Karaf shutdown hook”, I found an old thread talking about 
SynchronousBundleListener. The issue I’m facing is that I get no event when 
performing bundle0.stop(Bundle.STOP_TRANSIENT) and one of the bundles refuses 
to stop. The listener is registered via 
bundle0.getBundleContext().addBundleListener(new SynchronousBundleListener() { 
… }).

Is it normal? How to force Karaf to shutdown?

PS: Karaf version is 4.0.7

JP



--

Guillaume Nodet

Red Hat, Open Source Integration

Email: gno...@redhat.com<mailto:gno...@redhat.com>
Web: http://fusesource.com<http://fusesource.com/>
Blog: http://gnodet.blogspot.com/




--

Guillaume Nodet

Red Hat, Open Source Integration

Email: gno...@redhat.com&l

RE: Karaf shutdown

2016-11-18 Thread CLEMENT Jean-Philippe

PS : After calling shutdown() the output is :
Bye bye
So long!

De : CLEMENT Jean-Philippe
Envoyé : vendredi 18 novembre 2016 13:29
À : user
Objet : RE: Karaf shutdown

That’s exactly what I did. The listener is not called at all. Looking at 
bundles, some are Active, some Resolved, one Installed (OSGi System Bundle 
3.10.2.v20150203-1939) and one Waiting (one of mine).

public final class KarafStopper {
private static final Logger LOG = 
LogManager.getLogger(KarafStopper.class);
private static final long   TIMEOUT = 3 * 1000; 
  // in milliseconds

private final Bundlekaraf;

public KarafStopper(final BundleContext context) {
System.out.println("=> blabla");
karaf = context.getBundle(0);
karaf.getBundleContext().addBundleListener(new 
SynchronousBundleListener() {
@Override
public void bundleChanged(final BundleEvent event) {
System.out.println("Karaf: " + event.getType());
}
});
}

public void shutdown() {
try {
final Thread watchdog = new Thread(() -> {
try {
Thread.sleep(TIMEOUT);
// Karaf refuses to stop
LOG.error(() -> "Karaf did not stop gracefully");
System.exit(-1);
} catch (final InterruptedException e) {
// Karaf stopped normally
}
});

watchdog.setDaemon(true);
watchdog.start();
System.out.println("Bye bye");
karaf.stop(Bundle.STOP_TRANSIENT);
System.out.println("So long!");
} catch (final BundleException e) {
System.out.println("Oooops: " + e);
LOG.error(() -> "Issue while stopping karaf", e);
}
}
}

Regards,
JP

De : Guillaume Nodet [mailto:gno...@apache.org]
Envoyé : vendredi 18 novembre 2016 13:01
À : user
Objet : Re: Karaf shutdown

Can you write a simple SynchronousBundleListener that prints to stdout all 
received events and paste the output when stopping the framework for felix and 
equinox ?

2016-11-18 12:10 GMT+01:00 CLEMENT Jean-Philippe 
<jean-philippe.clem...@fr.thalesgroup.com<mailto:jean-philippe.clem...@fr.thalesgroup.com>>:
Well, that’s not the case when a bundle refuses to stop – I get no event. Ah I 
forgot to mention that Equinox is used instead of Felix.

May I open a bug for this?

Regards,
JP


De : Guillaume Nodet [mailto:gno...@apache.org<mailto:gno...@apache.org>]
Envoyé : vendredi 18 novembre 2016 11:52
À : user
Objet : Re: Karaf shutdown

The SynchronousBundleListener is the way to go.
You should receive a STOPPING event for the system bundle before any other 
bundle is actually stopped.

2016-11-18 11:38 GMT+01:00 CLEMENT Jean-Philippe 
<jean-philippe.clem...@fr.thalesgroup.com<mailto:jean-philippe.clem...@fr.thalesgroup.com>>:
Is there a way to get a shutdown event?

Regards,
JP

De : CLEMENT Jean-Philippe 
[mailto:jean-philippe.clem...@fr.thalesgroup.com<mailto:jean-philippe.clem...@fr.thalesgroup.com>]
Envoyé : jeudi 17 novembre 2016 17:03
À : user@karaf.apache.org<mailto:user@karaf.apache.org>
Objet : Karaf shutdown

Dear Karaf addicts :)

I would like Karaf to stop. This may fail to happen when (at least) a bundle 
does not end. So I added a watchdog which exits Java when a time limit has been 
exceeded (note: maybe there is already a way to do so - ?). The way I coded it 
does not work when the shutdown is made via the Karaf prompt, so I decided to 
enhance it.

Googling “Karaf shutdown hook”, I found an old thread talking about 
SynchronousBundleListener. The issue I’m facing is that I get no event when 
performing bundle0.stop(Bundle.STOP_TRANSIENT) and one of the bundles refuses 
to stop. The listener is registered via 
bundle0.getBundleContext().addBundleListener(new SynchronousBundleListener() { 
… }).

Is it normal? How to force Karaf to shutdown?

PS: Karaf version is 4.0.7

JP



--

Guillaume Nodet

Red Hat, Open Source Integration

Email: gno...@redhat.com<mailto:gno...@redhat.com>
Web: http://fusesource.com<http://fusesource.com/>
Blog: http://gnodet.blogspot.com/




--

Guillaume Nodet

Red Hat, Open Source Integration

Email: gno...@redhat.com<mailto:gno...@redhat.com>
Web: http://fusesource.com<http://fusesource.com/>
Blog: http://gnodet.blogspot.com/

RE: Karaf shutdown

2016-11-18 Thread CLEMENT Jean-Philippe

That’s exactly what I did. The listener is not called at all. Looking at 
bundles, some are Active, some Resolved, one Installed (OSGi System Bundle 
3.10.2.v20150203-1939) and one Waiting (one of mine).

public final class KarafStopper {
private static final Logger LOG = 
LogManager.getLogger(KarafStopper.class);
private static final long   TIMEOUT = 3 * 1000; 
  // in milliseconds

private final Bundlekaraf;

public KarafStopper(final BundleContext context) {
System.out.println("=> blabla");
karaf = context.getBundle(0);
karaf.getBundleContext().addBundleListener(new 
SynchronousBundleListener() {
@Override
public void bundleChanged(final BundleEvent event) {
System.out.println("Karaf: " + event.getType());
}
});
}

public void shutdown() {
try {
final Thread watchdog = new Thread(() -> {
try {
Thread.sleep(TIMEOUT);
// Karaf refuses to stop
LOG.error(() -> "Karaf did not stop gracefully");
System.exit(-1);
} catch (final InterruptedException e) {
// Karaf stopped normally
}
});

watchdog.setDaemon(true);
watchdog.start();
System.out.println("Bye bye");
karaf.stop(Bundle.STOP_TRANSIENT);
System.out.println("So long!");
} catch (final BundleException e) {
System.out.println("Oooops: " + e);
LOG.error(() -> "Issue while stopping karaf", e);
}
}
}

Regards,
JP

De : Guillaume Nodet [mailto:gno...@apache.org]
Envoyé : vendredi 18 novembre 2016 13:01
À : user
Objet : Re: Karaf shutdown

Can you write a simple SynchronousBundleListener that prints to stdout all 
received events and paste the output when stopping the framework for felix and 
equinox ?

2016-11-18 12:10 GMT+01:00 CLEMENT Jean-Philippe 
<jean-philippe.clem...@fr.thalesgroup.com<mailto:jean-philippe.clem...@fr.thalesgroup.com>>:
Well, that’s not the case when a bundle refuses to stop – I get no event. Ah I 
forgot to mention that Equinox is used instead of Felix.

May I open a bug for this?

Regards,
JP


De : Guillaume Nodet [mailto:gno...@apache.org<mailto:gno...@apache.org>]
Envoyé : vendredi 18 novembre 2016 11:52
À : user
Objet : Re: Karaf shutdown

The SynchronousBundleListener is the way to go.
You should receive a STOPPING event for the system bundle before any other 
bundle is actually stopped.

2016-11-18 11:38 GMT+01:00 CLEMENT Jean-Philippe 
<jean-philippe.clem...@fr.thalesgroup.com<mailto:jean-philippe.clem...@fr.thalesgroup.com>>:
Is there a way to get a shutdown event?

Regards,
JP

De : CLEMENT Jean-Philippe 
[mailto:jean-philippe.clem...@fr.thalesgroup.com<mailto:jean-philippe.clem...@fr.thalesgroup.com>]
Envoyé : jeudi 17 novembre 2016 17:03
À : user@karaf.apache.org<mailto:user@karaf.apache.org>
Objet : Karaf shutdown

Dear Karaf addicts :)

I would like Karaf to stop. This may fail to happen when (at least) a bundle 
does not end. So I added a watchdog which exits Java when a time limit has been 
exceeded (note: maybe there is already a way to do so - ?). The way I coded it 
does not work when the shutdown is made via the Karaf prompt, so I decided to 
enhance it.

Googling “Karaf shutdown hook”, I found an old thread talking about 
SynchronousBundleListener. The issue I’m facing is that I get no event when 
performing bundle0.stop(Bundle.STOP_TRANSIENT) and one of the bundles refuses 
to stop. The listener is registered via 
bundle0.getBundleContext().addBundleListener(new SynchronousBundleListener() { 
… }).

Is it normal? How to force Karaf to shutdown?

PS: Karaf version is 4.0.7

JP



--

Guillaume Nodet

Red Hat, Open Source Integration

Email: gno...@redhat.com<mailto:gno...@redhat.com>
Web: http://fusesource.com<http://fusesource.com/>
Blog: http://gnodet.blogspot.com/




--

Guillaume Nodet

Red Hat, Open Source Integration

Email: gno...@redhat.com<mailto:gno...@redhat.com>
Web: http://fusesource.com<http://fusesource.com/>
Blog: http://gnodet.blogspot.com/

RE: Karaf shutdown

2016-11-18 Thread CLEMENT Jean-Philippe

Well, that’s not the case when a bundle refuses to stop – I get no event. Ah I 
forgot to mention that Equinox is used instead of Felix.

May I open a bug for this?

Regards,
JP


De : Guillaume Nodet [mailto:gno...@apache.org]
Envoyé : vendredi 18 novembre 2016 11:52
À : user
Objet : Re: Karaf shutdown

The SynchronousBundleListener is the way to go.
You should receive a STOPPING event for the system bundle before any other 
bundle is actually stopped.

2016-11-18 11:38 GMT+01:00 CLEMENT Jean-Philippe 
<jean-philippe.clem...@fr.thalesgroup.com<mailto:jean-philippe.clem...@fr.thalesgroup.com>>:
Is there a way to get a shutdown event?

Regards,
JP

De : CLEMENT Jean-Philippe 
[mailto:jean-philippe.clem...@fr.thalesgroup.com<mailto:jean-philippe.clem...@fr.thalesgroup.com>]
Envoyé : jeudi 17 novembre 2016 17:03
À : user@karaf.apache.org<mailto:user@karaf.apache.org>
Objet : Karaf shutdown

Dear Karaf addicts :)

I would like Karaf to stop. This may fail to happen when (at least) a bundle 
does not end. So I added a watchdog which exits Java when a time limit has been 
exceeded (note: maybe there is already a way to do so - ?). The way I coded it 
does not work when the shutdown is made via the Karaf prompt, so I decided to 
enhance it.

Googling “Karaf shutdown hook”, I found an old thread talking about 
SynchronousBundleListener. The issue I’m facing is that I get no event when 
performing bundle0.stop(Bundle.STOP_TRANSIENT) and one of the bundles refuses 
to stop. The listener is registered via 
bundle0.getBundleContext().addBundleListener(new SynchronousBundleListener() { 
… }).

Is it normal? How to force Karaf to shutdown?

PS: Karaf version is 4.0.7

JP



--

Guillaume Nodet

Red Hat, Open Source Integration

Email: gno...@redhat.com<mailto:gno...@redhat.com>
Web: http://fusesource.com<http://fusesource.com/>
Blog: http://gnodet.blogspot.com/

RE: Karaf shutdown

2016-11-18 Thread CLEMENT Jean-Philippe

Is there a way to get a shutdown event?

Regards,
JP

De : CLEMENT Jean-Philippe [mailto:jean-philippe.clem...@fr.thalesgroup.com]
Envoyé : jeudi 17 novembre 2016 17:03
À : user@karaf.apache.org
Objet : Karaf shutdown

Dear Karaf addicts :)

I would like Karaf to stop. This may fail to happen when (at least) a bundle 
does not end. So I added a watchdog which exits Java when a time limit has been 
exceeded (note: maybe there is already a way to do so - ?). The way I coded it 
does not work when the shutdown is made via the Karaf prompt, so I decided to 
enhance it.

Googling “Karaf shutdown hook”, I found an old thread talking about 
SynchronousBundleListener. The issue I’m facing is that I get no event when 
performing bundle0.stop(Bundle.STOP_TRANSIENT) and one of the bundles refuses 
to stop. The listener is registered via 
bundle0.getBundleContext().addBundleListener(new SynchronousBundleListener() { 
… }).

Is it normal? How to force Karaf to shutdown?

PS: Karaf version is 4.0.7

JP

Karaf shutdown

2016-11-17 Thread CLEMENT Jean-Philippe

Dear Karaf addicts :)

I would like Karaf to stop. This may fail to happen when (at least) a bundle 
does not end. So I added a watchdog which exits Java when a time limit has been 
exceeded (note: maybe there is already a way to do so - ?). The way I coded it 
does not work when the shutdown is made via the Karaf prompt, so I decided to 
enhance it.

Googling “Karaf shutdown hook”, I found an old thread talking about 
SynchronousBundleListener. The issue I’m facing is that I get no event when 
performing bundle0.stop(Bundle.STOP_TRANSIENT) and one of the bundles refuses 
to stop. The listener is registered via 
bundle0.getBundleContext().addBundleListener(new SynchronousBundleListener() { 
… }).

Is it normal? How to force Karaf to shutdown?

PS: Karaf version is 4.0.7

JP

RE: Karaf 4.0.7 crashes with org.eclipse.birt.runtime resolution error

2016-10-07 Thread CLEMENT Jean-Philippe

…still did not find yet, but there are things unclear. For instance, when
something is missing Karaf reports that a package error, not a Maven artifact
error. Where the mvn URI comes from?

Moreover I did add birt. Karaf (assembly) starts. Then I uninstall the birt
bundle. When I restart Karaf, Karaf automatically reinstall birt :S

So I removed birt in the Karaf’s system directory, then restarted Karaf. Karaf
does not reinstall birt but does not complain about anything!

Strange strange. Well, maybe, if you may explain where the mvn URI comes from?

Thanks,
JP

De : CLEMENT Jean-Philippe [mailto:jean-philippe.clem...@fr.thalesgroup.com]
Envoyé : vendredi 7 octobre 2016 15:29
À : user@karaf.apache.org
Objet : RE: Karaf 4.0.7 crashes with org.eclipse.birt.runtime resolution error

Yep, good idea. Let’s investigate…

Thanks!

Regards,
JP

De : Guillaume Nodet [mailto:gno...@apache.org]
Envoyé : vendredi 7 octobre 2016 13:28
À : user
Objet : Re: Karaf 4.0.7 crashes with org.eclipse.birt.runtime resolution error

The reason the url has changed is that the birt artifact is not available on
central.
There's still a reference to the birt artifact I found, but it's only in the
web demo, so unless you use that one, it should not appear.
Maybe try grepping all the files in your distribution for "birt"...

2016-10-07 12:30 GMT+02:00 CLEMENT Jean-Philippe
<jean-philippe.clem...@fr.thalesgroup.com<mailto:jean-philippe.clem...@fr.thalesgroup.com>>:
Well again I’m not clear :)

The property I mentioned below is the one generated by Karaf assembly itself
not something I overloaded, i.e. I let Karaf generate the config.properties
file then I modify the generated file by changing “karaf.framework=equinox”.

I don’t know why Karaf does not birt anymore but still has a reference hidden
somewhere.

Regards,
JP

De : CLEMENT Jean-Philippe
[mailto:jean-philippe.clem...@fr.thalesgroup.com<mailto:jean-philippe.clem...@fr.thalesgroup.com>]
Envoyé : vendredi 7 octobre 2016 11:46
À : user@karaf.apache.org<mailto:user@karaf.apache.org>
Objet : RE: Karaf 4.0.7 crashes with org.eclipse.birt.runtime resolution error

Guillaume,

My description was not clear.

The property karaf.framework.equinox does not reference birt anymore but now:

mvn\:org.eclipse.tycho/org.eclipse.osgi/3.10.101.<http://3.10.101.>v20150820-1432

Don’t know why.

De : Guillaume Nodet [mailto:gno...@apache.org]
Envoyé : vendredi 7 octobre 2016 11:39
À : user
Objet : Re: Karaf 4.0.7 crashes with org.eclipse.birt.runtime resolution error

Check your etc/config.properties and look for karaf.framework.equinox

Guillaume

2016-10-07 11:02 GMT+02:00 CLEMENT Jean-Philippe
<jean-philippe.clem...@fr.thalesgroup.com<mailto:jean-philippe.clem...@fr.thalesgroup.com>>:
Dear Karaf Team,

We experience a strange bug using our custom distribution of Karaf 4.0.7 which
uses Equinox instead of Felix. Without Maven repository access, Karaf crashes
during startup with the error message:
Could not resolve
mvn:org.eclipse.birt.runtime/org.eclipse.osgi/3.10.2.<http://3.10.2.>v20150203-1939

Something strange, I did not find “birt” in the config.properties neither when
using a Maven repo and displaying all bundles with “list -t 0”. So I don’t know
where the dependency comes from.

When looking to Karaf 4.0.4 config.properties, the birt library was set as
karaf.framework.equinox but now it uses tycho instead.

Is there a workaround?

Regards,
JP

Guillaume Nodet

Red Hat, Open Source Integration

Email: gno...@redhat.com<mailto:gno...@redhat.com>
Web: http://fusesource.com<http://fusesource.com/>
Blog: http://gnodet.blogspot.com/

Guillaume Nodet

Red Hat, Open Source Integration

Email: gno...@redhat.com<mailto:gno...@redhat.com>
Web: http://fusesource.com<http://fusesource.com/>
Blog: http://gnodet.blogspot.com/

RE: Karaf 4.0.7 crashes with org.eclipse.birt.runtime resolution error

2016-10-07 Thread CLEMENT Jean-Philippe

Well again I’m not clear :)

The property I mentioned below is the one generated by Karaf assembly itself 
not something I overloaded, i.e. I let Karaf generate the config.properties 
file then I modify the generated file by changing “karaf.framework=equinox”.

I don’t know why Karaf does not birt anymore but still has a reference hidden 
somewhere.

Regards,
JP

De : CLEMENT Jean-Philippe [mailto:jean-philippe.clem...@fr.thalesgroup.com]
Envoyé : vendredi 7 octobre 2016 11:46
À : user@karaf.apache.org
Objet : RE: Karaf 4.0.7 crashes with org.eclipse.birt.runtime resolution error

Guillaume,

My description was not clear.

The property karaf.framework.equinox does not reference birt anymore but now:
mvn\:org.eclipse.tycho/org.eclipse.osgi/3.10.101.v20150820-1432

Don’t know why.

JP

De : Guillaume Nodet [mailto:gno...@apache.org]
Envoyé : vendredi 7 octobre 2016 11:39
À : user
Objet : Re: Karaf 4.0.7 crashes with org.eclipse.birt.runtime resolution error

Check your etc/config.properties and look for karaf.framework.equinox

Guillaume

2016-10-07 11:02 GMT+02:00 CLEMENT Jean-Philippe 
<jean-philippe.clem...@fr.thalesgroup.com<mailto:jean-philippe.clem...@fr.thalesgroup.com>>:
Dear Karaf Team,

We experience a strange bug using our custom distribution of Karaf 4.0.7 which 
uses Equinox instead of Felix. Without Maven repository access, Karaf crashes 
during startup with the error message:
Could not resolve 
mvn:org.eclipse.birt.runtime/org.eclipse.osgi/3.10.2.<http://3.10.2.>v20150203-1939

Something strange, I did not find “birt” in the config.properties neither when 
using a Maven repo and displaying all bundles with “list -t 0”. So I don’t know 
where the dependency comes from.

When looking to Karaf 4.0.4 config.properties, the birt library was set as 
karaf.framework.equinox but now it uses tycho instead.

Is there a workaround?

Regards,
JP



--

Guillaume Nodet

Red Hat, Open Source Integration

Email: gno...@redhat.com<mailto:gno...@redhat.com>
Web: http://fusesource.com<http://fusesource.com/>
Blog: http://gnodet.blogspot.com/

RE: Karaf 4.0.7 crashes with org.eclipse.birt.runtime resolution error

2016-10-07 Thread CLEMENT Jean-Philippe

Guillaume,

My description was not clear.

The property karaf.framework.equinox does not reference birt anymore but now:
mvn\:org.eclipse.tycho/org.eclipse.osgi/3.10.101.v20150820-1432

Don’t know why.

JP

De : Guillaume Nodet [mailto:gno...@apache.org]
Envoyé : vendredi 7 octobre 2016 11:39
À : user
Objet : Re: Karaf 4.0.7 crashes with org.eclipse.birt.runtime resolution error

Check your etc/config.properties and look for karaf.framework.equinox

Guillaume

2016-10-07 11:02 GMT+02:00 CLEMENT Jean-Philippe 
<jean-philippe.clem...@fr.thalesgroup.com<mailto:jean-philippe.clem...@fr.thalesgroup.com>>:
Dear Karaf Team,

We experience a strange bug using our custom distribution of Karaf 4.0.7 which 
uses Equinox instead of Felix. Without Maven repository access, Karaf crashes 
during startup with the error message:
Could not resolve 
mvn:org.eclipse.birt.runtime/org.eclipse.osgi/3.10.2.<http://3.10.2.>v20150203-1939

Something strange, I did not find “birt” in the config.properties neither when 
using a Maven repo and displaying all bundles with “list -t 0”. So I don’t know 
where the dependency comes from.

When looking to Karaf 4.0.4 config.properties, the birt library was set as 
karaf.framework.equinox but now it uses tycho instead.

Is there a workaround?

Regards,
JP



--

Guillaume Nodet

Red Hat, Open Source Integration

Email: gno...@redhat.com<mailto:gno...@redhat.com>
Web: http://fusesource.com<http://fusesource.com/>
Blog: http://gnodet.blogspot.com/

Karaf 4.0.7 crashes with org.eclipse.birt.runtime resolution error

2016-10-07 Thread CLEMENT Jean-Philippe

Dear Karaf Team,

We experience a strange bug using our custom distribution of Karaf 4.0.7 which 
uses Equinox instead of Felix. Without Maven repository access, Karaf crashes 
during startup with the error message:
Could not resolve 
mvn:org.eclipse.birt.runtime/org.eclipse.osgi/3.10.2.v20150203-1939

Something strange, I did not find “birt” in the config.properties neither when 
using a Maven repo and displaying all bundles with “list -t 0”. So I don’t know 
where the dependency comes from.

When looking to Karaf 4.0.4 config.properties, the birt library was set as 
karaf.framework.equinox but now it uses tycho instead.

Is there a workaround?

Regards,
JP

RE: Strange issue on strange use case

2016-10-06 Thread CLEMENT Jean-Philippe

Yes it's a kind of split package but I didn't define a merge policy (I don't 
know what a merge policy is).

Is it possible to do so with the maven-bundle-plugin?

Regards,
JP

-Message d'origine-
De : Jean-Baptiste Onofré [mailto:j...@nanthrax.net] 
Envoyé : jeudi 6 octobre 2016 15:42
À : user@karaf.apache.org
Objet : Re: Strange issue on strange use case

I think we are in the case of a split package. Did you define any merge policy ?

Regards
JB

On 10/06/2016 03:40 PM, CLEMENT Jean-Philippe wrote:
> I renamed the package of b.jar to something like "other.package". All is back 
> to normal even with BF.
>
> So it seems there is a bug somewhere. In OSGi, are several packages with the 
> same name (but with different content) allowed?
>
> JP
>
> -Message d'origine-
> De : CLEMENT Jean-Philippe 
> [mailto:jean-philippe.clem...@fr.thalesgroup.com]
> Envoyé : jeudi 6 octobre 2016 14:28
> À : user@karaf.apache.org
> Objet : Strange issue on strange use case
>
> Hello,
>
> I experience a strange issue on a strange use case using Karaf 4.0.7.
>
> I have:
> * a bundle A which wraps a jar "a.jar" and exposes a package 
> "some.package" (which is inside the "a.jar")
> * a bundle B which contains and use a jar "b.jar" which contains a 
> package "some.package" (same package as "a.jar" but inside the 
> "b.jar")
>
> Until then everything is fine. All works as expected.
>
> I add a bundle B fragment (BF). Then bundle B crashes with a 
> ClassNotFoundException on a class which is contained in the b.jar. When I 
> remove the FB fragment, everything goes back to normal.
>
> Any idea on what's going on?
>
> JP
>

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

RE: Strange issue on strange use case

2016-10-06 Thread CLEMENT Jean-Philippe

I renamed the package of b.jar to something like "other.package". All is back 
to normal even with BF.

So it seems there is a bug somewhere. In OSGi, are several packages with the 
same name (but with different content) allowed?

JP

-Message d'origine-
De : CLEMENT Jean-Philippe [mailto:jean-philippe.clem...@fr.thalesgroup.com] 
Envoyé : jeudi 6 octobre 2016 14:28
À : user@karaf.apache.org
Objet : Strange issue on strange use case

Hello,

I experience a strange issue on a strange use case using Karaf 4.0.7.

I have:
* a bundle A which wraps a jar "a.jar" and exposes a package "some.package" 
(which is inside the "a.jar")
* a bundle B which contains and use a jar "b.jar" which contains a package 
"some.package" (same package as "a.jar" but inside the "b.jar")

Until then everything is fine. All works as expected.

I add a bundle B fragment (BF). Then bundle B crashes with a 
ClassNotFoundException on a class which is contained in the b.jar. When I 
remove the FB fragment, everything goes back to normal.

Any idea on what's going on?

JP

Strange issue on strange use case

2016-10-06 Thread CLEMENT Jean-Philippe

Hello,

I experience a strange issue on a strange use case using Karaf 4.0.7.

I have:
* a bundle A which wraps a jar "a.jar" and exposes a package "some.package" 
(which is inside the "a.jar")
* a bundle B which contains and use a jar "b.jar" which contains a package 
"some.package" (same package as "a.jar" but inside the "b.jar")

Until then everything is fine. All works as expected.

I add a bundle B fragment (BF). Then bundle B crashes with a 
ClassNotFoundException on a class which is contained in the b.jar. When I 
remove the FB fragment, everything goes back to normal.

Any idea on what's going on?

JP

RE: Karaf assembly licences report

2016-09-26 Thread CLEMENT Jean-Philippe

I created the KARAF-4734 Jira for this. Hope the description is clear enough :)

Regards,
JP

-Message d'origine-
De : Jean-Baptiste Onofré [mailto:j...@nanthrax.net] 
Envoyé : lundi 26 septembre 2016 17:59
À : user@karaf.apache.org
Objet : Re: Karaf assembly licences report

Yes, please do. I will work on it.

Thanks,
Regards
JB

On 09/26/2016 05:51 PM, CLEMENT Jean-Philippe wrote:
> Yes, could be very nice and useful!
>
> May I open a Jira for this?
>
> Regards,
> JP
>
> -Message d'origine-
> De : Jean-Baptiste Onofré [mailto:j...@nanthrax.net] Envoyé : lundi 26 
> septembre 2016 15:11 À : user@karaf.apache.org Objet : Re: Karaf 
> assembly licences report
>
> Unfortunately, no, the existing plugins use the pom.xml as base.
>
> We can add a couple of goals in the karaf-maven-plugins to create a pom or 
> check the license based on a feature (like we do with the verify goal).
>
> Regards
> JB
>
> On 09/26/2016 03:08 PM, CLEMENT Jean-Philippe wrote:
>> Ok good thank you! (I'm currently trying license:third-party-report 
>> but I get ClassNotFound exceptions - I'm investigating)
>>
>> We were using project-info-reports:dependencies but it only handles pom 
>> files, not features, so a fake pom must be manually created from 
>> feature-related artifacts in order to get a report.
>>
>> "license" plugin also seems to be tied to pom files. Is there a plugin which 
>> analyses the assembly, i.e. all features of the assembly? ... else is there 
>> a tool to generate a pom from features?
>>
>> Regards,
>> JP
>>
>> -Message d'origine-
>> De : Jean-Baptiste Onofré [mailto:j...@nanthrax.net] Envoyé : lundi 26 
>> septembre 2016 14:08 À : user@karaf.apache.org Objet : Re: Karaf 
>> assembly licences report
>>
>> Hi JP,
>>
>> you can use the license plugin to check all dependencies license in your POM.
>>
>> http://www.mojohaus.org/license-maven-plugin/
>>
>> Regards
>> JB
>>
>> On 09/26/2016 02:04 PM, CLEMENT Jean-Philippe wrote:
>>> Hi,
>>>
>>> We are packing our app using the Karaf Maven plugin with our custom 
>>> features. Is there a way to check all used licenses of the assembled 
>>> application?
>>>
>>> Regards,
>>> JP
>>>
>>
>> --
>> 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
>

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

RE: Karaf assembly licences report

2016-09-26 Thread CLEMENT Jean-Philippe

Yes, could be very nice and useful!

May I open a Jira for this?

Regards,
JP

-Message d'origine-
De : Jean-Baptiste Onofré [mailto:j...@nanthrax.net] 
Envoyé : lundi 26 septembre 2016 15:11
À : user@karaf.apache.org
Objet : Re: Karaf assembly licences report

Unfortunately, no, the existing plugins use the pom.xml as base.

We can add a couple of goals in the karaf-maven-plugins to create a pom or 
check the license based on a feature (like we do with the verify goal).

Regards
JB

On 09/26/2016 03:08 PM, CLEMENT Jean-Philippe wrote:
> Ok good thank you! (I'm currently trying license:third-party-report 
> but I get ClassNotFound exceptions - I'm investigating)
>
> We were using project-info-reports:dependencies but it only handles pom 
> files, not features, so a fake pom must be manually created from 
> feature-related artifacts in order to get a report.
>
> "license" plugin also seems to be tied to pom files. Is there a plugin which 
> analyses the assembly, i.e. all features of the assembly? ... else is there a 
> tool to generate a pom from features?
>
> Regards,
> JP
>
> -Message d'origine-
> De : Jean-Baptiste Onofré [mailto:j...@nanthrax.net] Envoyé : lundi 26 
> septembre 2016 14:08 À : user@karaf.apache.org Objet : Re: Karaf 
> assembly licences report
>
> Hi JP,
>
> you can use the license plugin to check all dependencies license in your POM.
>
> http://www.mojohaus.org/license-maven-plugin/
>
> Regards
> JB
>
> On 09/26/2016 02:04 PM, CLEMENT Jean-Philippe wrote:
>> Hi,
>>
>> We are packing our app using the Karaf Maven plugin with our custom 
>> features. Is there a way to check all used licenses of the assembled 
>> application?
>>
>> Regards,
>> JP
>>
>
> --
> 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

RE: Karaf assembly licences report

2016-09-26 Thread CLEMENT Jean-Philippe

Ok good thank you! (I'm currently trying license:third-party-report but I get 
ClassNotFound exceptions - I'm investigating)

We were using project-info-reports:dependencies but it only handles pom files, 
not features, so a fake pom must be manually created from feature-related 
artifacts in order to get a report.

"license" plugin also seems to be tied to pom files. Is there a plugin which 
analyses the assembly, i.e. all features of the assembly? ... else is there a 
tool to generate a pom from features?

Regards,
JP

-Message d'origine-
De : Jean-Baptiste Onofré [mailto:j...@nanthrax.net] 
Envoyé : lundi 26 septembre 2016 14:08
À : user@karaf.apache.org
Objet : Re: Karaf assembly licences report

Hi JP,

you can use the license plugin to check all dependencies license in your POM.

http://www.mojohaus.org/license-maven-plugin/

Regards
JB

On 09/26/2016 02:04 PM, CLEMENT Jean-Philippe wrote:
> Hi,
>
> We are packing our app using the Karaf Maven plugin with our custom features. 
> Is there a way to check all used licenses of the assembled application?
>
> Regards,
> JP
>

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

Karaf assembly licences report

2016-09-26 Thread CLEMENT Jean-Philippe

Hi,

We are packing our app using the Karaf Maven plugin with our custom features. 
Is there a way to check all used licenses of the assembled application?

Regards,
JP

RE: Inject system property value via blueprint

2016-09-02 Thread CLEMENT Jean-Philippe

Ok... is there a way to use env variables other than via system variables?

Regards,
JP

-Message d'origine-
De : Jean-Baptiste Onofré [mailto:j...@nanthrax.net] 
Envoyé : vendredi 2 septembre 2016 16:19
À : user@karaf.apache.org
Objet : Re: Inject system property value via blueprint

Ha, ok understood.

So, it's about env variables more than system variables. System variables for 
me are passed using -D on the JVM.

Regards
JB

On 09/02/2016 03:41 PM, CLEMENT Jean-Philippe wrote:
> I'm not too sure it's the same need => at present time to get an environment 
> variable in a cfg I have to modify the setenv (export 
> KARAF_OPTS="-Dmy.variable=$MY_ENV_VARIABLE") then I may use it in a cfg 
> (SOME_KEY=${my.variable}).
>
> But I have to "declare" each variable in the setenv scripts... Could 
> be nice to get environment variables directly, for instance 
> SOME_KEY=$[MY_ENV_VARIABLE]
>
> Regards,
> JP
>
> -Message d'origine-
> De : Jean-Baptiste Onofré [mailto:j...@nanthrax.net] Envoyé : vendredi 2 
> septembre 2016 15:29 À : user@karaf.apache.org Objet : Re: Inject 
> system property value via blueprint
>
> OK, it sounds like this one then:
>
> https://issues.apache.org/jira/browse/KARAF-4609
>
> Regards
> JB
>
> On 09/02/2016 03:22 PM, CLEMENT Jean-Philippe wrote:
>> Ah, I mean more environment related such as "export MY_PROPERTY=something" 
>> the use it in Karaf via something like $[MY_PROPERTY].
>>
>> I think we already had this discussion but I did not succeed in 
>> finding a corresponding Jira (?)
>>
>> Regards,
>> JP
>>
>> -Message d'origine-
>> De : Jean-Baptiste Onofré [mailto:j...@nanthrax.net] Envoyé : vendredi 
>> 2 septembre 2016 14:36 À : user@karaf.apache.org Objet : Re: Inject 
>> system property value via blueprint
>>
>> You mean to be able to use ${sys.user.home} in a cfg file where user.home is 
>> the system property ?
>>
>> Maybe it's related to:
>> https://issues.apache.org/jira/browse/KARAF-4609
>> https://issues.apache.org/jira/browse/KARAF-3949
>>
>> Regards
>> JB
>>
>> On 09/02/2016 02:30 PM, CLEMENT Jean-Philippe wrote:
>>> Hi JB,
>>>
>>> Does it also work for .cfg files?
>>>
>>> Regards,
>>> JP
>>>
>>> -Message d'origine-
>>> De : Jean-Baptiste Onofré [mailto:j...@nanthrax.net] Envoyé : mercredi
>>> 31 août 2016 15:49 À : user@karaf.apache.org Objet : Re: Inject 
>>> system property value via blueprint
>>>
>>> Hi,
>>>
>>> you have to use the ext xmlns for that.
>>>
>>> Just add the following in your blueprint:
>>>
>>>  
>>> >> placeholder-suffix="]" />
>>>
>>> Then, you can use system properties with $[foo].
>>>
>>> Regards
>>> JB
>>>
>>> On 08/31/2016 03:46 PM, ellirael wrote:
>>>> I saw an example how to inject property values which are defined in 
>>>> config file.
>>>> It is some thing like this:
>>>>
>>>> >>>>
>>>> 
>>>>  
>>>>   >>> init-method="refresh"> >>> value="$\{title\}"> 
>>>>
>>>> How to do the same with the system property printed by 
>>>> system:property command output?
>>>> Or how to gain access to those system properties values?
>>>>
>>>>
>>>>
>>>> --
>>>> View this message in context:
>>>> http://karaf.922171.n3.nabble.com/Inject-system-property-value-via-
>>>> b l u eprint-tp4047779.html Sent from the Karaf - User mailing list 
>>>> archive at Nabble.com.
>>>>
>>>
>>> --
>>> 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
>>
>
> --
> 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

RE: Inject system property value via blueprint

2016-09-02 Thread CLEMENT Jean-Philippe

I'm not too sure it's the same need => at present time to get an environment 
variable in a cfg I have to modify the setenv (export 
KARAF_OPTS="-Dmy.variable=$MY_ENV_VARIABLE") then I may use it in a cfg 
(SOME_KEY=${my.variable}).

But I have to "declare" each variable in the setenv scripts... Could be nice to 
get environment variables directly, for instance SOME_KEY=$[MY_ENV_VARIABLE]

Regards,
JP

-Message d'origine-
De : Jean-Baptiste Onofré [mailto:j...@nanthrax.net] 
Envoyé : vendredi 2 septembre 2016 15:29
À : user@karaf.apache.org
Objet : Re: Inject system property value via blueprint

OK, it sounds like this one then:

https://issues.apache.org/jira/browse/KARAF-4609

Regards
JB

On 09/02/2016 03:22 PM, CLEMENT Jean-Philippe wrote:
> Ah, I mean more environment related such as "export MY_PROPERTY=something" 
> the use it in Karaf via something like $[MY_PROPERTY].
>
> I think we already had this discussion but I did not succeed in 
> finding a corresponding Jira (?)
>
> Regards,
> JP
>
> -Message d'origine-
> De : Jean-Baptiste Onofré [mailto:j...@nanthrax.net] Envoyé : vendredi 2 
> septembre 2016 14:36 À : user@karaf.apache.org Objet : Re: Inject 
> system property value via blueprint
>
> You mean to be able to use ${sys.user.home} in a cfg file where user.home is 
> the system property ?
>
> Maybe it's related to:
> https://issues.apache.org/jira/browse/KARAF-4609
> https://issues.apache.org/jira/browse/KARAF-3949
>
> Regards
> JB
>
> On 09/02/2016 02:30 PM, CLEMENT Jean-Philippe wrote:
>> Hi JB,
>>
>> Does it also work for .cfg files?
>>
>> Regards,
>> JP
>>
>> -Message d'origine-
>> De : Jean-Baptiste Onofré [mailto:j...@nanthrax.net] Envoyé : mercredi
>> 31 août 2016 15:49 À : user@karaf.apache.org Objet : Re: Inject 
>> system property value via blueprint
>>
>> Hi,
>>
>> you have to use the ext xmlns for that.
>>
>> Just add the following in your blueprint:
>>
>>  > placeholder-prefix="$[" placeholder-suffix="]" />
>>
>> Then, you can use system properties with $[foo].
>>
>> Regards
>> JB
>>
>> On 08/31/2016 03:46 PM, ellirael wrote:
>>> I saw an example how to inject property values which are defined in 
>>> config file.
>>> It is some thing like this:
>>>
>>> >>>
>>> 
>>>  
>>>   >> init-method="refresh"> >> value="$\{title\}"> 
>>>
>>> How to do the same with the system property printed by 
>>> system:property command output?
>>> Or how to gain access to those system properties values?
>>>
>>>
>>>
>>> --
>>> View this message in context:
>>> http://karaf.922171.n3.nabble.com/Inject-system-property-value-via-b
>>> l u eprint-tp4047779.html Sent from the Karaf - User mailing list 
>>> archive at Nabble.com.
>>>
>>
>> --
>> 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
>

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

RE: Inject system property value via blueprint

2016-09-02 Thread CLEMENT Jean-Philippe

Ah, I mean more environment related such as "export MY_PROPERTY=something" the 
use it in Karaf via something like $[MY_PROPERTY].

I think we already had this discussion but I did not succeed in finding a 
corresponding Jira (?)

Regards,
JP

-Message d'origine-
De : Jean-Baptiste Onofré [mailto:j...@nanthrax.net] 
Envoyé : vendredi 2 septembre 2016 14:36
À : user@karaf.apache.org
Objet : Re: Inject system property value via blueprint

You mean to be able to use ${sys.user.home} in a cfg file where user.home is 
the system property ?

Maybe it's related to:
https://issues.apache.org/jira/browse/KARAF-4609
https://issues.apache.org/jira/browse/KARAF-3949

Regards
JB

On 09/02/2016 02:30 PM, CLEMENT Jean-Philippe wrote:
> Hi JB,
>
> Does it also work for .cfg files?
>
> Regards,
> JP
>
> -Message d'origine-
> De : Jean-Baptiste Onofré [mailto:j...@nanthrax.net] Envoyé : mercredi 
> 31 août 2016 15:49 À : user@karaf.apache.org Objet : Re: Inject system 
> property value via blueprint
>
> Hi,
>
> you have to use the ext xmlns for that.
>
> Just add the following in your blueprint:
>
>   placeholder-prefix="$[" placeholder-suffix="]" />
>
> Then, you can use system properties with $[foo].
>
> Regards
> JB
>
> On 08/31/2016 03:46 PM, ellirael wrote:
>> I saw an example how to inject property values which are defined in 
>> config file.
>> It is some thing like this:
>>
>> >>
>> 
>>  
>>   > init-method="refresh"> > value="$\{title\}"> 
>>
>> How to do the same with the system property printed by 
>> system:property command output?
>> Or how to gain access to those system properties values?
>>
>>
>>
>> --
>> View this message in context:
>> http://karaf.922171.n3.nabble.com/Inject-system-property-value-via-bl
>> u eprint-tp4047779.html Sent from the Karaf - User mailing list 
>> archive at Nabble.com.
>>
>
> --
> 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

RE: Inject system property value via blueprint

2016-09-02 Thread CLEMENT Jean-Philippe

Hi JB,

Does it also work for .cfg files?

Regards,
JP

-Message d'origine-
De : Jean-Baptiste Onofré [mailto:j...@nanthrax.net] 
Envoyé : mercredi 31 août 2016 15:49
À : user@karaf.apache.org
Objet : Re: Inject system property value via blueprint

Hi,

you have to use the ext xmlns for that.

Just add the following in your blueprint:

 

Then, you can use system properties with $[foo].

Regards
JB

On 08/31/2016 03:46 PM, ellirael wrote:
> I saw an example how to inject property values which are defined in 
> config file.
> It is some thing like this:
>
> >
> 
>  
>init-method="refresh">  value="$\{title\}"> 
>
> How to do the same with the system property printed by system:property 
> command output?
> Or how to gain access to those system properties values?
>
>
>
> --
> View this message in context: 
> http://karaf.922171.n3.nabble.com/Inject-system-property-value-via-blu
> eprint-tp4047779.html Sent from the Karaf - User mailing list archive 
> at Nabble.com.
>

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

RE: importing and exporting same package in same bundle

2016-03-29 Thread CLEMENT Jean-Philippe

Hello,

For sure if the import is not necessary, then remove it :)

You may "ask" maven-bundle-plugin not to generate the import or you may put the 
dependency generating the import as optional.

JP

-Message d'origine-
De : asookazian2 [mailto:asookaz...@gmail.com] 
Envoyé : mardi 29 mars 2016 00:55
À : user@karaf.apache.org
Objet : importing and exporting same package in same bundle

what are the side-effects/consequences of importing and exporting same package 
in same bundle?  Is this normal or bad practice and if we are doing this in our 
manifest.mf, how do we correct this in the pom.xml and maven-bundle-plugin 
config/instructions?  thx.



--
View this message in context: 
http://karaf.922171.n3.nabble.com/importing-and-exporting-same-package-in-same-bundle-tp4046020.html
Sent from the Karaf - User mailing list archive at Nabble.com.

RE: Blueprint or DS or what to use?

2016-03-20 Thread CLEMENT Jean-Philippe

We use Blueprint mainly to have a code which makes use of services but without 
dealing with OSGi or annotations (as far as possible => few wappers). As long 
with the maven-bundle-plugin it is a kind of magic. I would say 
Blueprint+Maven+Karaf makes things really easy.

I would suggest to make a simple but representative example using CDI, DS, and 
Blueprint. Take time to have a full picture with you editor, plugins and 
compilation / assembly. See what is means in terms of effort to make, and think 
about what it would cost to enhance and maintain.

JP

-Message d'origine-
De : akuhtz [mailto:andreas.ku...@gmail.com] 
Envoyé : vendredi 18 mars 2016 11:24
À : user@karaf.apache.org
Objet : Blueprint or DS or what to use?

Hello,

I've an application running with spring-dm and because spring-dm is no longer 
developed I'm looking for a replacement.

Now I'm confused because there was a shift in karaf (core) from blueprint to DS 
and today I saw a post on the dev list, saying that DS does not support as much 
as blueprint does. 
As an end-user I would like to know what the proposed way to go is: DS or 
blueprint, both or what else?



--
View this message in context: 
http://karaf.922171.n3.nabble.com/Blueprint-or-DS-or-what-to-use-tp4045845.html
Sent from the Karaf - User mailing list archive at Nabble.com.

RE: Dynamic Config Loading in Camel Application Bundle in Karaf 3.0.5

2016-03-03 Thread CLEMENT Jean-Philippe

I'm not too sure whether this is the right place/thread to discuss about DS vs 
Blueprint, but IMHO DS offers less possibilities than Blueprint.

Anyway, as far as I know you can't. But you may deal with the 
ConfigurationAdmin, BundleContext and ManagedService. I've wrapped all this to 
make it easy (and to rely as less as possible on OSGi specific API) with a 
couple of beans and a whiteboard interface to deal with config updates. Now 
it's handy in Blueprint and it deals with config updates without restarting 
anything :)

I guess you have to do the same. Good luck,
JP

De : David Jencks [mailto:david_jen...@yahoo.com]
Envoyé : mercredi 2 mars 2016 18:20
À : user@karaf.apache.org
Objet : Re: Dynamic Config Loading in Camel Application Bundle in Karaf 3.0.5

It would be a big change, but you might consider switching your application to 
use declarative services rather than  blueprint.  IMO blueprint is sort of 
spring shoehorned to sort of vaguely work a little bit in OSGI whereas DS is 
actually designed from the start to take full advantage of osgi.

david jencks

On Mar 2, 2016, at 3:50 AM, Debraj Manna 
> wrote:


I have a simple Camel Application bundle which is to be deployed in Karaf 3.0.5 
under Apache Service Mix 6.1. The configuration file is placed in etc/ 
directory (let's say it is named as wf.cfg). I want to have the dynamic config 
change functionality in my application bundle. So that whenever something is 
changed in wf.cfg it is immediately available to bundle. For this I have added 
the following in my blueprint.xml





















The problem I am facing now is if the update-strategy is set to reload. Then it 
seems to be reloading the entire bean.
Can someone let me know is there a way I can reload only the configBean not the 
entire bundle? If I can achieve this then may be I can have some static 
reference to the config variables inside the configBean which my application 
bundle can then make use of?
The full blueprint.xml is placed 
here.

RE: PAX-WEB ServletMapping service sometimes starts before ServletContextListenerMapping

2016-03-03 Thread CLEMENT Jean-Philippe

May you share your Blueprint file(s)?

JP

-Message d'origine-
De : kuvalda [mailto:peha...@mail.ru] 
Envoyé : mercredi 2 mars 2016 21:56
À : user@karaf.apache.org
Objet : RE: PAX-WEB ServletMapping service sometimes starts before 
ServletContextListenerMapping

Hi JP and Achim

Thanks for your advice.
Unfortunately, it didn't help.
I've tried to put depends-on="listenerMapping" to ServletMapping service.
Just in case, tried to put depends-on to DefaultServletMapping bean and Servlet 
bean.

Also I've tried to register just a Listener service itself without 
ListenerMapping.
It didn't help too.

They start in random order, so when serlvet starts before listener, 
contextInitialized event isn't caught.


Pavel


CLEMENT Jean-Philippe wrote
> Hi,
> 
> Did you try to put a "depends-on" in your Blueprint service?
> 
> JP





-
Pavel
--
View this message in context: 
http://karaf.922171.n3.nabble.com/PAX-WEB-ServletMapping-service-sometimes-starts-before-ServletContextListenerMapping-tp4045660p4045667.html
Sent from the Karaf - User mailing list archive at Nabble.com.

RE: PAX-WEB ServletMapping service sometimes starts before ServletContextListenerMapping

2016-03-02 Thread CLEMENT Jean-Philippe

Hi,

Did you try to put a "depends-on" in your Blueprint service?

JP

-Message d'origine-
De : kuvalda [mailto:peha...@mail.ru] 
Envoyé : mardi 1 mars 2016 21:46
À : user@karaf.apache.org
Objet : PAX-WEB ServletMapping service sometimes starts before 
ServletContextListenerMapping

I'm trying to configure ServletContextListener for Servlet with whiteboard 
extender via blueprint in my bundle, karaf version 4.0.4.
ServletMapping and ListenerMapping are used.
The problem is that ServletMapping and ListenerMapping services are registered 
in random order, so when ServletMapping is registered before ListenerMapping, 
Listener does not catch contextInitialized event, because it's already happened 
earlier.

Any ideas, how to solve this problem?
May be, there is some way to set service registration order?



-
Pavel
--
View this message in context: 
http://karaf.922171.n3.nabble.com/PAX-WEB-ServletMapping-service-sometimes-starts-before-ServletContextListenerMapping-tp4045660.html
Sent from the Karaf - User mailing list archive at Nabble.com.

RE: Karaf logging in JSON format

2016-02-29 Thread CLEMENT Jean-Philippe

You may also export your JSON implementation as a PaxAppender service with the 
“org.ops4j.pax.logging.appender.name” property containing the desired 
identifier which will be used in the Log4J conf file.

JP

De : Achim Nierbeck [mailto:bcanh...@googlemail.com]
Envoyé : lundi 29 février 2016 08:48
À : user@karaf.apache.org
Objet : Re: Karaf logging in JSON format

Depends on if you have an appender that can do so.
If you have such an appender, make sure to attach it to pax-logging.
One known to work solution is to have a fragment bundle which attaches to the 
pax-logging service bundle (if it's a log4j 1.x bundle)

regards, Achim


2016-02-29 6:46 GMT+01:00 D 
>:
Is there a way we can make karaf log in JSON format?



--
View this message in context: 
http://karaf.922171.n3.nabble.com/Karaf-logging-in-JSON-format-tp4045607.html
Sent from the Karaf - User mailing list archive at Nabble.com.



--

Apache Member
Apache Karaf  Committer & PMC
OPS4J Pax Web  Committer & 
Project Lead
blog 
Co-Author of Apache Karaf Cookbook 

Software Architect / Project Manager / Scrum Master

Blueprint issue with generics

2016-02-10 Thread CLEMENT Jean-Philippe

Dear Karaf,

I have an issue with the way generics are handled in Blueprint. I get an 
exception claiming that the bean conversion is not possible, but it should.

Let's say I have a bean with the method setSomething(Something) called via 
blueprint with another bean implementing Something => exception. If I change 
the method signature without the generic type setSomething(Something), then it 
works as expected.

Until now I did workaround by changing the method signatures and logging a 
warning but now I'm blocked with a third-party API. So I have to find a real 
solution.

I don't catch why Blueprint cares for the generic type as Java is type erasure. 
So it seems to exceed Java spec. Is there a way to comply with Java type 
erasure, i.e. discard generic types when "converting" beans?

Regards,
JP

[@@ OPEN @@]

RE: [Karaf 4.0.4] Bundle exception : Unresolved requirement on first startup

2016-01-29 Thread CLEMENT Jean-Philippe

Does this problem only occur during the first launch of Karaf? In other words 
after a successful start did you try to launch Karaf with default fileinstall 
properties?

JP

-Message d'origine-
De : goku3989 [mailto:mattwhar...@msn.com] 
Envoyé : vendredi 29 janvier 2016 04:25
À : user@karaf.apache.org
Objet : Re: [Karaf 4.0.4] Bundle exception : Unresolved requirement on first 
startup

After playing around a bit more, it seems that there may be something timing 
related here. I changed the fileinstall properties to wait 3 seconds before 
trying to load any bundles in the deploy directory. Since I've done that, I've 
been able to do numerous successful clean starts (no cached bundles).

I wonder if there is some fundamental service/feature that needs a bit longer 
to fully start up before the "hot deploy" wrapping works properly?

Thanks,

-Matt



--
View this message in context: 
http://karaf.922171.n3.nabble.com/Karaf-4-0-4-Bundle-exception-Unresolved-requirement-on-first-startup-tp4045034p4045051.html
Sent from the Karaf - User mailing list archive at Nabble.com.

RE: Karaf 4.0.4-SNAPSHOT freeze

2016-01-05 Thread CLEMENT Jean-Philippe

Haha!

Seems I deleted that file for some reason (maybe a Chrismas aftereffect) :|

Works better now :)

Thank you!
JP

[@@ OPEN @@]


-Message d'origine-
De : Jean-Baptiste Onofré [mailto:j...@nanthrax.net] 
Envoyé : mardi 5 janvier 2016 17:29
À : user@karaf.apache.org
Objet : Re: Karaf 4.0.4-SNAPSHOT freeze

The problem is that tec.uom.se bundle requires javax.annotation package 
(version between 1.2 and 2.0). So take a look in etc/jre.properties for the 
javax.annotation package version.

Regards
JB

On 01/05/2016 05:23 PM, CLEMENT Jean-Philippe wrote:
> "It seems that you use felix framework, right ?" => we had to move to equinox 
> - the config.properties is overridden with "karaf.framework=equinox".
>
> As the config.properties file is overloaded in our assembly, I updated it 
> from the default Karaf one (which changed). It seems I forgot to put the 
> framework statement to equinox.
>
> So now it still freezes but with the right cause:
>
> 2016-01-05 17:18:00,278 | INFO  | pool-1-thread-1  | FeaturesServiceImpl  
> | 7 - org.apache.karaf.features.core - 4.0.4.SNAPSHOT | Adding 
> features: log/[4.0.4.SNAPSHOT,4.0.4.SNAPSHOT], hci-XXX/[0,0.0.0], 
> ssh/[4.0.4.SNAPSHOT,4.0.4.SNAPSHOT], 
> shell-compat/[4.0.4.SNAPSHOT,4.0.4.SNAPSHOT], 
> bundle/[4.0.4.SNAPSHOT,4.0.4.SNAPSHOT], 
> aries-blueprint/[4.0.4.SNAPSHOT,4.0.4.SNAPSHOT]
> 2016-01-05 17:18:00,783 | ERROR | pool-1-thread-1  | BootFeaturesInstaller
> | 7 - org.apache.karaf.features.core - 4.0.4.SNAPSHOT | Error 
> installing boot features
> org.osgi.service.resolver.ResolutionException: Unable to resolve root: 
> missing requirement [root] osgi.identity; osgi.identity=hci-XXX; 
> type=karaf.feature; version="[0,0.0.0]"; filter:="(&(osgi.id 
> entity=hci-XXX)(type=karaf.feature)(version>=0.0.0)(version<=0.0.0))" [caused 
> by: Unable to resolve hci-XXX/0.0.0: missing requirement [hci-XXX/0.0.0] 
> osgi.identity; osgi.identity=hci-XXX-base;
>   type=karaf.feature [caused by: Unable to resolve hci-XXX-base/0.0.0: 
> missing requirement [hci-XXX-base/0.0.0] osgi.identity; 
> osgi.identity=tec.uom.se; type=osgi.bundle; version="[0.8.0,0.8.0]"; 
> resolution:=mandatory [caused by: Unable to resolve tec.uom.se/0.8.0: 
> missing requirement [tec.uom.se/0.8.0] osgi.wiring.package; 
> filter:="(&(osgi.wiring.package=javax.annotation)(version>=1.2.0)(!(ve
> rsion>=2.0.0)))"]]]
>
> But I don't know where "tec.uom.se/0.8.0" comes from. We have:
>
>   
>   mvn:javax.measure/unit-api/0.8
>   mvn:tec.uom/uom-se/0.8
> ...
>   
>
> JP
>
> [@@ OPEN @@]
>
>
> -Message d'origine-
> De : Jean-Baptiste Onofré [mailto:j...@nanthrax.net] Envoyé : mardi 5 
> janvier 2016 16:59 À : user@karaf.apache.org Objet : Re: Karaf 
> 4.0.4-SNAPSHOT freeze
>
> By the way, you can use -t to simulate the installation and check the 
> resolution from the resolver.
>
> Can you paste the complete message (to find the missing requirement) ?
>
> Thanks
> Regards
> JB
>
> On 01/05/2016 04:54 PM, CLEMENT Jean-Philippe wrote:
>> 
>>   
>>   
>> mvn:org.eclipse.core/contenttype/3.4.200.v20140207-1251
>>   mvn:org.eclipse.core/jobs/3.6.0.v20140424-0053
>>   mvn:org.eclipse.core/runtime/3.10.0.v20140318-2214
>>   mvn:org.eclipse.equinox/app/1.3.200.v20130910-1609
>>   
>> mvn:org.eclipse.equinox/common/3.6.200.v20130402-1505
>>   
>> mvn:org.eclipse.equinox/preferences/3.5.200.v20140224-1527> undle>
>>
>> mvn:org.eclipse.equinox/registry/3.5.400.v20140428-1507> l
>> e>
>>
>>   mvn:com.google.guava/guava/15.0
>>   ...
>> 
>>
>> JP
>>
>> [@@ OPEN @@]
>>
>>
>> -Message d'origine-
>> De : Jean-Baptiste Onofré [mailto:j...@nanthrax.net] Envoyé : mardi 5 
>> janvier 2016 16:47 À : user@karaf.apache.org Objet : Re: Karaf 
>> 4.0.4-SNAPSHOT freeze
>>
>> Hi JP,
>>
>> it sounds like your feature requires XXX feature which is not found.
>>
>> Can you share your features XML ?
>>
>> Regards
>> JB
>>
>>
>> On 01/05/2016 04:34 PM, CLEMENT Jean-Philippe wrote:
>>> Dear Karaf Team,
>>>
>>> Happy New Year :)
>>>
>>> I just assembled Karaf 4.0.4-SNAPSHOT. It seems the snapshot content 
>>> changed as now it freezes at startup before displaying the branding.
>>>
>>> The log mentions a missing requirement on 
>>> org.eclipse.core.runtime/

RE: Karaf 4.0.4-SNAPSHOT freeze

2016-01-05 Thread CLEMENT Jean-Philippe

"It seems that you use felix framework, right ?" => we had to move to equinox - 
the config.properties is overridden with "karaf.framework=equinox".

As the config.properties file is overloaded in our assembly, I updated it from 
the default Karaf one (which changed). It seems I forgot to put the framework 
statement to equinox.

So now it still freezes but with the right cause:

2016-01-05 17:18:00,278 | INFO  | pool-1-thread-1  | FeaturesServiceImpl
  | 7 - org.apache.karaf.features.core - 4.0.4.SNAPSHOT | Adding features: 
log/[4.0.4.SNAPSHOT,4.0.4.SNAPSHOT], hci-XXX/[0,0.0.0], 
ssh/[4.0.4.SNAPSHOT,4.0.4.SNAPSHOT], 
shell-compat/[4.0.4.SNAPSHOT,4.0.4.SNAPSHOT], 
bundle/[4.0.4.SNAPSHOT,4.0.4.SNAPSHOT], 
aries-blueprint/[4.0.4.SNAPSHOT,4.0.4.SNAPSHOT]
2016-01-05 17:18:00,783 | ERROR | pool-1-thread-1  | BootFeaturesInstaller  
  | 7 - org.apache.karaf.features.core - 4.0.4.SNAPSHOT | Error installing 
boot features
org.osgi.service.resolver.ResolutionException: Unable to resolve root: missing 
requirement [root] osgi.identity; osgi.identity=hci-XXX; type=karaf.feature; 
version="[0,0.0.0]"; filter:="(&(osgi.id
entity=hci-XXX)(type=karaf.feature)(version>=0.0.0)(version<=0.0.0))" [caused 
by: Unable to resolve hci-XXX/0.0.0: missing requirement [hci-XXX/0.0.0] 
osgi.identity; osgi.identity=hci-XXX-base;
 type=karaf.feature [caused by: Unable to resolve hci-XXX-base/0.0.0: missing 
requirement [hci-XXX-base/0.0.0] osgi.identity; osgi.identity=tec.uom.se; 
type=osgi.bundle; version="[0.8.0,0.8.0]";
resolution:=mandatory [caused by: Unable to resolve tec.uom.se/0.8.0: missing 
requirement [tec.uom.se/0.8.0] osgi.wiring.package; 
filter:="(&(osgi.wiring.package=javax.annotation)(version>=1.2.0)(!(version>=2.0.0)))"]]]

But I don't know where "tec.uom.se/0.8.0" comes from. We have:


mvn:javax.measure/unit-api/0.8
mvn:tec.uom/uom-se/0.8
   ...


JP

[@@ OPEN @@]


-Message d'origine-
De : Jean-Baptiste Onofré [mailto:j...@nanthrax.net] 
Envoyé : mardi 5 janvier 2016 16:59
À : user@karaf.apache.org
Objet : Re: Karaf 4.0.4-SNAPSHOT freeze

By the way, you can use -t to simulate the installation and check the 
resolution from the resolver.

Can you paste the complete message (to find the missing requirement) ?

Thanks
Regards
JB

On 01/05/2016 04:54 PM, CLEMENT Jean-Philippe wrote:
> 
>  
>  
> mvn:org.eclipse.core/contenttype/3.4.200.v20140207-1251
>  mvn:org.eclipse.core/jobs/3.6.0.v20140424-0053
>  mvn:org.eclipse.core/runtime/3.10.0.v20140318-2214
>  mvn:org.eclipse.equinox/app/1.3.200.v20130910-1609
>  
> mvn:org.eclipse.equinox/common/3.6.200.v20130402-1505
>  
> mvn:org.eclipse.equinox/preferences/3.5.200.v20140224-1527
>  
> mvn:org.eclipse.equinox/registry/3.5.400.v20140428-1507 e>
>
>  mvn:com.google.guava/guava/15.0
>  ...
> 
>
> JP
>
> [@@ OPEN @@]
>
>
> -Message d'origine-
> De : Jean-Baptiste Onofré [mailto:j...@nanthrax.net] Envoyé : mardi 5 
> janvier 2016 16:47 À : user@karaf.apache.org Objet : Re: Karaf 
> 4.0.4-SNAPSHOT freeze
>
> Hi JP,
>
> it sounds like your feature requires XXX feature which is not found.
>
> Can you share your features XML ?
>
> Regards
> JB
>
>
> On 01/05/2016 04:34 PM, CLEMENT Jean-Philippe wrote:
>> Dear Karaf Team,
>>
>> Happy New Year :)
>>
>> I just assembled Karaf 4.0.4-SNAPSHOT. It seems the snapshot content changed 
>> as now it freezes at startup before displaying the branding.
>>
>> The log mentions a missing requirement on 
>> org.eclipse.core.runtime/3.10.0v20140318-2214 but the bundle is part of the 
>> feature:
>>
>> 2016-01-05 15:03:36,348 | ERROR | pool-6-thread-1  | BootFeaturesInstaller   
>>  | 7 - org.apache.karaf.features.core - 4.0.4.SNAPSHOT | Error 
>> installing boot features
>> org.osgi.service.resolver.ResolutionException: Unable to resolve root: 
>> missing requirement [root] osgi.identity; osgi.identity=XXX; 
>> type=karaf.feature; version=0 [caused by: Unable to resolve XXX/0.0.0: 
>> missing requirement [XXX/0.0.0] osgi.identity; 
>> osgi.identity=org.eclipse.core.runtime; type=osgi.bundle; 
>> version="[3.10.0.v20140318-2214,3.10.0.v20140318-2214]"; 
>> resolution:=mandatory [caused by: Unable to resolve 
>> org.eclipse.core.runtime/3.10.0.v20140318-2214: missing requirement 
>> [org.eclipse.core.runtime/3.10.0.v20140318-2214] osgi.wiring.bundle; 
>> osgi.wiring.bundle=org.eclipse.osgi; bundle-version="[3.7.0,4.0.0)"; 
>> visibilit

RE: Karaf 4.0.4-SNAPSHOT freeze

2016-01-05 Thread CLEMENT Jean-Philippe



mvn:org.eclipse.core/contenttype/3.4.200.v20140207-1251
mvn:org.eclipse.core/jobs/3.6.0.v20140424-0053
mvn:org.eclipse.core/runtime/3.10.0.v20140318-2214
mvn:org.eclipse.equinox/app/1.3.200.v20130910-1609
mvn:org.eclipse.equinox/common/3.6.200.v20130402-1505

mvn:org.eclipse.equinox/preferences/3.5.200.v20140224-1527
mvn:org.eclipse.equinox/registry/3.5.400.v20140428-1507

mvn:com.google.guava/guava/15.0
...


JP

[@@ OPEN @@]


-Message d'origine-
De : Jean-Baptiste Onofré [mailto:j...@nanthrax.net] 
Envoyé : mardi 5 janvier 2016 16:47
À : user@karaf.apache.org
Objet : Re: Karaf 4.0.4-SNAPSHOT freeze

Hi JP,

it sounds like your feature requires XXX feature which is not found.

Can you share your features XML ?

Regards
JB


On 01/05/2016 04:34 PM, CLEMENT Jean-Philippe wrote:
> Dear Karaf Team,
>
> Happy New Year :)
>
> I just assembled Karaf 4.0.4-SNAPSHOT. It seems the snapshot content changed 
> as now it freezes at startup before displaying the branding.
>
> The log mentions a missing requirement on 
> org.eclipse.core.runtime/3.10.0v20140318-2214 but the bundle is part of the 
> feature:
>
> 2016-01-05 15:03:36,348 | ERROR | pool-6-thread-1  | BootFeaturesInstaller
> | 7 - org.apache.karaf.features.core - 4.0.4.SNAPSHOT | Error 
> installing boot features
> org.osgi.service.resolver.ResolutionException: Unable to resolve root: 
> missing requirement [root] osgi.identity; osgi.identity=XXX; 
> type=karaf.feature; version=0 [caused by: Unable to resolve XXX/0.0.0: 
> missing requirement [XXX/0.0.0] osgi.identity; 
> osgi.identity=org.eclipse.core.runtime; type=osgi.bundle; 
> version="[3.10.0.v20140318-2214,3.10.0.v20140318-2214]"; 
> resolution:=mandatory [caused by: Unable to resolve 
> org.eclipse.core.runtime/3.10.0.v20140318-2214: missing requirement 
> [org.eclipse.core.runtime/3.10.0.v20140318-2214] osgi.wiring.bundle; 
> osgi.wiring.bundle=org.eclipse.osgi; bundle-version="[3.7.0,4.0.0)"; 
> visibility:=reexport; 
> filter:="(&(osgi.wiring.bundle=org.eclipse.osgi)(bundle-version>=3.7.0)(!(bundle-version>=4.0.0)))"]]
>  at 
> org.apache.felix.resolver.ResolutionError.toException(ResolutionError.java:42)[org.apache.felix.framework-5.4.0.jar:]
>  at 
> org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:235)[org.apache.felix.framework-5.4.0.jar:]
>  at 
> org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:158)[org.apache.felix.framework-5.4.0.jar:]
>  at 
> org.apache.karaf.features.internal.region.SubsystemResolver.resolve(SubsystemResolver.java:220)[7:org.apache.karaf.features.core:4.0.4.SNAPSHOT]
>  at 
> org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:263)[7:org.apache.karaf.features.core:4.0.4.SNAPSHOT]
>  at 
> org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1085)[7:org.apache.karaf.features.core:4.0.4.SNAPSHOT]
>  at 
> org.apache.karaf.features.internal.service.FeaturesServiceImpl$1.call(FeaturesServiceImpl.java:981)[7:org.apache.karaf.features.core:4.0.4.SNAPSHOT]
>  at 
> java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_72-ea]
>  at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_72-ea]
>  at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_72-ea]
>  at java.lang.Thread.run(Thread.java:745)[:1.8.0_72-ea]
>
> How to fix this?
>
> Regards,
> JP
>
> [@@ OPEN @@]
>

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

Karaf 4.0.4-SNAPSHOT freeze

2016-01-05 Thread CLEMENT Jean-Philippe

Dear Karaf Team,

Happy New Year :)

I just assembled Karaf 4.0.4-SNAPSHOT. It seems the snapshot content changed as 
now it freezes at startup before displaying the branding.

The log mentions a missing requirement on 
org.eclipse.core.runtime/3.10.0v20140318-2214 but the bundle is part of the 
feature:

2016-01-05 15:03:36,348 | ERROR | pool-6-thread-1  | BootFeaturesInstaller  
  | 7 - org.apache.karaf.features.core - 4.0.4.SNAPSHOT | Error installing 
boot features
org.osgi.service.resolver.ResolutionException: Unable to resolve root: missing 
requirement [root] osgi.identity; osgi.identity=XXX; type=karaf.feature; 
version=0 [caused by: Unable to resolve XXX/0.0.0: missing requirement 
[XXX/0.0.0] osgi.identity; osgi.identity=org.eclipse.core.runtime; 
type=osgi.bundle; version="[3.10.0.v20140318-2214,3.10.0.v20140318-2214]"; 
resolution:=mandatory [caused by: Unable to resolve 
org.eclipse.core.runtime/3.10.0.v20140318-2214: missing requirement 
[org.eclipse.core.runtime/3.10.0.v20140318-2214] osgi.wiring.bundle; 
osgi.wiring.bundle=org.eclipse.osgi; bundle-version="[3.7.0,4.0.0)"; 
visibility:=reexport; 
filter:="(&(osgi.wiring.bundle=org.eclipse.osgi)(bundle-version>=3.7.0)(!(bundle-version>=4.0.0)))"]]
at 
org.apache.felix.resolver.ResolutionError.toException(ResolutionError.java:42)[org.apache.felix.framework-5.4.0.jar:]
at 
org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:235)[org.apache.felix.framework-5.4.0.jar:]
at 
org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:158)[org.apache.felix.framework-5.4.0.jar:]
at 
org.apache.karaf.features.internal.region.SubsystemResolver.resolve(SubsystemResolver.java:220)[7:org.apache.karaf.features.core:4.0.4.SNAPSHOT]
at 
org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:263)[7:org.apache.karaf.features.core:4.0.4.SNAPSHOT]
at 
org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1085)[7:org.apache.karaf.features.core:4.0.4.SNAPSHOT]
at 
org.apache.karaf.features.internal.service.FeaturesServiceImpl$1.call(FeaturesServiceImpl.java:981)[7:org.apache.karaf.features.core:4.0.4.SNAPSHOT]
at 
java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_72-ea]
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_72-ea]
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_72-ea]
at java.lang.Thread.run(Thread.java:745)[:1.8.0_72-ea]

How to fix this?

Regards,
JP

[@@ OPEN @@]

RE: Karaf 4.0.4-SNAPSHOT freeze

2016-01-05 Thread CLEMENT Jean-Philippe

PS: "the bundle is part of the feature" => the bundle is part of my custom boot 
feature

[@@ OPEN @@]


-Message d'origine-
De : CLEMENT Jean-Philippe [mailto:jean-philippe.clem...@fr.thalesgroup.com] 
Envoyé : mardi 5 janvier 2016 16:34
À : user@karaf.apache.org
Objet : Karaf 4.0.4-SNAPSHOT freeze

Dear Karaf Team,

Happy New Year :)

I just assembled Karaf 4.0.4-SNAPSHOT. It seems the snapshot content changed as 
now it freezes at startup before displaying the branding.

The log mentions a missing requirement on 
org.eclipse.core.runtime/3.10.0v20140318-2214 but the bundle is part of the 
feature:

2016-01-05 15:03:36,348 | ERROR | pool-6-thread-1  | BootFeaturesInstaller  
  | 7 - org.apache.karaf.features.core - 4.0.4.SNAPSHOT | Error installing 
boot features
org.osgi.service.resolver.ResolutionException: Unable to resolve root: missing 
requirement [root] osgi.identity; osgi.identity=XXX; type=karaf.feature; 
version=0 [caused by: Unable to resolve XXX/0.0.0: missing requirement 
[XXX/0.0.0] osgi.identity; osgi.identity=org.eclipse.core.runtime; 
type=osgi.bundle; version="[3.10.0.v20140318-2214,3.10.0.v20140318-2214]"; 
resolution:=mandatory [caused by: Unable to resolve 
org.eclipse.core.runtime/3.10.0.v20140318-2214: missing requirement 
[org.eclipse.core.runtime/3.10.0.v20140318-2214] osgi.wiring.bundle; 
osgi.wiring.bundle=org.eclipse.osgi; bundle-version="[3.7.0,4.0.0)"; 
visibility:=reexport; 
filter:="(&(osgi.wiring.bundle=org.eclipse.osgi)(bundle-version>=3.7.0)(!(bundle-version>=4.0.0)))"]]
at 
org.apache.felix.resolver.ResolutionError.toException(ResolutionError.java:42)[org.apache.felix.framework-5.4.0.jar:]
at 
org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:235)[org.apache.felix.framework-5.4.0.jar:]
at 
org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:158)[org.apache.felix.framework-5.4.0.jar:]
at 
org.apache.karaf.features.internal.region.SubsystemResolver.resolve(SubsystemResolver.java:220)[7:org.apache.karaf.features.core:4.0.4.SNAPSHOT]
at 
org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:263)[7:org.apache.karaf.features.core:4.0.4.SNAPSHOT]
at 
org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1085)[7:org.apache.karaf.features.core:4.0.4.SNAPSHOT]
at 
org.apache.karaf.features.internal.service.FeaturesServiceImpl$1.call(FeaturesServiceImpl.java:981)[7:org.apache.karaf.features.core:4.0.4.SNAPSHOT]
at 
java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_72-ea]
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_72-ea]
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_72-ea]
at java.lang.Thread.run(Thread.java:745)[:1.8.0_72-ea]

How to fix this?

Regards,
JP

[@@ OPEN @@]

RE: Karaf 4.0.3: unexpected behavior on first startup

2015-12-01 Thread CLEMENT Jean-Philippe

May I open a new Jira?

JP

[@@ OPEN @@]


-Message d'origine-
De : CLEMENT Jean-Philippe [mailto:jean-philippe.clem...@fr.thalesgroup.com] 
Envoyé : jeudi 26 novembre 2015 15:37
À : user@karaf.apache.org
Objet : RE: Karaf 4.0.3: unexpected behavior on first startup

The "$(PARAM)" first-time-issue also happens with property-placeholder which 
uses the default update-strategy (none).

I suspect the user bundles to be started before the .cfg files are populated in 
the /etc directory.

Regards,
JP

[@@ OPEN @@]


-Message d'origine-
De : CLEMENT Jean-Philippe [mailto:jean-philippe.clem...@fr.thalesgroup.com]
Envoyé : jeudi 26 novembre 2015 14:45
À : user@karaf.apache.org
Objet : RE: Karaf 4.0.3: unexpected behavior on first startup

The default one (eager).

This behavior may happen only during the very first Karaf execution when the 
user config files are not yet in the /etc directory but still in the /system 
one with the .jar bundles.

During other executions, when the /etc directory is already filled with .cfg 
files, no issue.

Regards,
JP

[@@ OPEN @@]


-Message d'origine-
De : Jean-Baptiste Onofré [mailto:j...@nanthrax.net] Envoyé : jeudi 26 novembre 
2015 14:40 À : user@karaf.apache.org Objet : Re: Karaf 4.0.3: unexpected 
behavior on first startup

No, we mean that the "restart" (actually update() on the ManagedService) is 
normal.

Now, regarding the substitution, it's more related to blueprint. Do you use 
lazy or eager for the activation ?

Let me check the behavior.

Regards
JB

On 11/26/2015 02:23 PM, CLEMENT Jean-Philippe wrote:
> Do you mean it is really expected to get “$(PARAM)” instead of the 
> value coming from the configuration file?
>
> JP
>
> [@@ OPEN @@]
>
> *De :*Achim Nierbeck [mailto:bcanh...@googlemail.com] *Envoyé :* jeudi
> 26 novembre 2015 14:22 *À :* user@karaf.apache.org *Objet :* Re: Karaf
> 4.0.3: unexpected behavior on first startup
>
> Hi,
>
> yes I would even go further and say it's an expected behavior.
>
> so nothing to worry about.
>
> regards, Achim
>
> 2015-11-26 14:10 GMT+01:00 Jean-Baptiste Onofré <j...@nanthrax.net
> <mailto:j...@nanthrax.net>>:
>
> Hi JP,
>
> I don't think it's related to blueprint.
>
> It's more the way a ManagedService works.
>
> First the activator starts, and then it will react to the 
> ManagedService via the update() method.
>
> I guess it's what you see there.
>
> Regards
> JB
>
>
>
> On 11/26/2015 02:04 PM, CLEMENT Jean-Philippe wrote:
>
> Dear Karaf Team,
>
> I have a strange behavior with Karaf (*) when started for the first 
> time. A bean is started then stopped then re-started. This behavior is 
> not 100% reproducible but happens maybe one-half of the time.
>
> That bean is instantiated via Blueprint and uses a 
> property-placeholder with update-strategy=”reload”. The “Karaf 
> distribution” is made by a custom assembly which includes both bundles and 
> configuration files.
>
> During the first bundle start the only configuration variable (a
> String) is not substituted which is a first issue (1). Then the bundle 
> is stopped and restarted with the substituted string. This is a second 
> issue (2) as I expected the bundle to start only one time as the 
> configuration file did not really change.
>
> Is this problem already known? Is there a workaround?
>
> Kind regards,
>
> JP
>
> [@@ OPEN @@]
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org <mailto:jbono...@apache.org> 
> http://blog.nanthrax.net Talend - http://www.talend.com
>
>
>
> --
>
>
> Apache Member
>
> Apache Karaf <http://karaf.apache.org/> Committer & PMC OPS4J Pax Web 
> <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & Project 
> Lead blog <http://notizblog.nierbeck.de/>
>
> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>
> Software Architect / Project Manager / Scrum Master
>

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

Karaf 4.0.3: unexpected behavior on first startup

2015-11-26 Thread CLEMENT Jean-Philippe

Dear Karaf Team,

I have a strange behavior with Karaf (*) when started for the first time. A 
bean is started then stopped then re-started. This behavior is not 100% 
reproducible but happens maybe one-half of the time.

That bean is instantiated via Blueprint and uses a property-placeholder with 
update-strategy=”reload”. The “Karaf distribution” is made by a custom assembly 
which includes both bundles and configuration files.

During the first bundle start the only configuration variable (a String) is not 
substituted which is a first issue (1). Then the bundle is stopped and 
restarted with the substituted string. This is a second issue (2) as I expected 
the bundle to start only one time as the configuration file did not really 
change.

Is this problem already known? Is there a workaround?

Kind regards,
JP

[@@ OPEN @@]

RE: Karaf 4.0.3: unexpected behavior on first startup

2015-11-26 Thread CLEMENT Jean-Philippe

Do you mean it is really expected to get “$(PARAM)” instead of the value coming 
from the configuration file?

JP

[@@ OPEN @@]

De : Achim Nierbeck [mailto:bcanh...@googlemail.com]
Envoyé : jeudi 26 novembre 2015 14:22
À : user@karaf.apache.org
Objet : Re: Karaf 4.0.3: unexpected behavior on first startup

Hi,

yes I would even go further and say it's an expected behavior.
so nothing to worry about.

regards, Achim

2015-11-26 14:10 GMT+01:00 Jean-Baptiste Onofré 
<j...@nanthrax.net<mailto:j...@nanthrax.net>>:
Hi JP,

I don't think it's related to blueprint.

It's more the way a ManagedService works.

First the activator starts, and then it will react to the ManagedService via 
the update() method.

I guess it's what you see there.

Regards
JB


On 11/26/2015 02:04 PM, CLEMENT Jean-Philippe wrote:
Dear Karaf Team,

I have a strange behavior with Karaf (*) when started for the first
time. A bean is started then stopped then re-started. This behavior is
not 100% reproducible but happens maybe one-half of the time.

That bean is instantiated via Blueprint and uses a property-placeholder
with update-strategy=”reload”. The “Karaf distribution” is made by a
custom assembly which includes both bundles and configuration files.

During the first bundle start the only configuration variable (a String)
is not substituted which is a first issue (1). Then the bundle is
stopped and restarted with the substituted string. This is a second
issue (2) as I expected the bundle to start only one time as the
configuration file did not really change.

Is this problem already known? Is there a workaround?

Kind regards,

JP

[@@ OPEN @@]

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



--

Apache Member
Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & 
Project Lead
blog <http://notizblog.nierbeck.de/>
Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>

Software Architect / Project Manager / Scrum Master

RE: Karaf 4.0.3: unexpected behavior on first startup

2015-11-26 Thread CLEMENT Jean-Philippe

The default one (eager).

This behavior may happen only during the very first Karaf execution when the 
user config files are not yet in the /etc directory but still in the /system 
one with the .jar bundles.

During other executions, when the /etc directory is already filled with .cfg 
files, no issue.

Regards,
JP

[@@ OPEN @@]


-Message d'origine-
De : Jean-Baptiste Onofré [mailto:j...@nanthrax.net] 
Envoyé : jeudi 26 novembre 2015 14:40
À : user@karaf.apache.org
Objet : Re: Karaf 4.0.3: unexpected behavior on first startup

No, we mean that the "restart" (actually update() on the ManagedService) is 
normal.

Now, regarding the substitution, it's more related to blueprint. Do you use 
lazy or eager for the activation ?

Let me check the behavior.

Regards
JB

On 11/26/2015 02:23 PM, CLEMENT Jean-Philippe wrote:
> Do you mean it is really expected to get “$(PARAM)” instead of the 
> value coming from the configuration file?
>
> JP
>
> [@@ OPEN @@]
>
> *De :*Achim Nierbeck [mailto:bcanh...@googlemail.com] *Envoyé :* jeudi 
> 26 novembre 2015 14:22 *À :* user@karaf.apache.org *Objet :* Re: Karaf 
> 4.0.3: unexpected behavior on first startup
>
> Hi,
>
> yes I would even go further and say it's an expected behavior.
>
> so nothing to worry about.
>
> regards, Achim
>
> 2015-11-26 14:10 GMT+01:00 Jean-Baptiste Onofré <j...@nanthrax.net
> <mailto:j...@nanthrax.net>>:
>
> Hi JP,
>
> I don't think it's related to blueprint.
>
> It's more the way a ManagedService works.
>
> First the activator starts, and then it will react to the 
> ManagedService via the update() method.
>
> I guess it's what you see there.
>
> Regards
> JB
>
>
>
> On 11/26/2015 02:04 PM, CLEMENT Jean-Philippe wrote:
>
> Dear Karaf Team,
>
> I have a strange behavior with Karaf (*) when started for the first 
> time. A bean is started then stopped then re-started. This behavior is 
> not 100% reproducible but happens maybe one-half of the time.
>
> That bean is instantiated via Blueprint and uses a 
> property-placeholder with update-strategy=”reload”. The “Karaf 
> distribution” is made by a custom assembly which includes both bundles and 
> configuration files.
>
> During the first bundle start the only configuration variable (a 
> String) is not substituted which is a first issue (1). Then the bundle 
> is stopped and restarted with the substituted string. This is a second 
> issue (2) as I expected the bundle to start only one time as the 
> configuration file did not really change.
>
> Is this problem already known? Is there a workaround?
>
> Kind regards,
>
> JP
>
> [@@ OPEN @@]
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org <mailto:jbono...@apache.org> 
> http://blog.nanthrax.net Talend - http://www.talend.com
>
>
>
> --
>
>
> Apache Member
>
> Apache Karaf <http://karaf.apache.org/> Committer & PMC OPS4J Pax Web 
> <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & Project 
> Lead blog <http://notizblog.nierbeck.de/>
>
> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>
> Software Architect / Project Manager / Scrum Master
>

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

RE: Karaf 4.0.3: unexpected behavior on first startup

2015-11-26 Thread CLEMENT Jean-Philippe

The "$(PARAM)" first-time-issue also happens with property-placeholder which 
uses the default update-strategy (none).

I suspect the user bundles to be started before the .cfg files are populated in 
the /etc directory.

Regards,
JP

[@@ OPEN @@]


-Message d'origine-
De : CLEMENT Jean-Philippe [mailto:jean-philippe.clem...@fr.thalesgroup.com] 
Envoyé : jeudi 26 novembre 2015 14:45
À : user@karaf.apache.org
Objet : RE: Karaf 4.0.3: unexpected behavior on first startup

The default one (eager).

This behavior may happen only during the very first Karaf execution when the 
user config files are not yet in the /etc directory but still in the /system 
one with the .jar bundles.

During other executions, when the /etc directory is already filled with .cfg 
files, no issue.

Regards,
JP

[@@ OPEN @@]


-Message d'origine-
De : Jean-Baptiste Onofré [mailto:j...@nanthrax.net] Envoyé : jeudi 26 novembre 
2015 14:40 À : user@karaf.apache.org Objet : Re: Karaf 4.0.3: unexpected 
behavior on first startup

No, we mean that the "restart" (actually update() on the ManagedService) is 
normal.

Now, regarding the substitution, it's more related to blueprint. Do you use 
lazy or eager for the activation ?

Let me check the behavior.

Regards
JB

On 11/26/2015 02:23 PM, CLEMENT Jean-Philippe wrote:
> Do you mean it is really expected to get “$(PARAM)” instead of the 
> value coming from the configuration file?
>
> JP
>
> [@@ OPEN @@]
>
> *De :*Achim Nierbeck [mailto:bcanh...@googlemail.com] *Envoyé :* jeudi
> 26 novembre 2015 14:22 *À :* user@karaf.apache.org *Objet :* Re: Karaf
> 4.0.3: unexpected behavior on first startup
>
> Hi,
>
> yes I would even go further and say it's an expected behavior.
>
> so nothing to worry about.
>
> regards, Achim
>
> 2015-11-26 14:10 GMT+01:00 Jean-Baptiste Onofré <j...@nanthrax.net
> <mailto:j...@nanthrax.net>>:
>
> Hi JP,
>
> I don't think it's related to blueprint.
>
> It's more the way a ManagedService works.
>
> First the activator starts, and then it will react to the 
> ManagedService via the update() method.
>
> I guess it's what you see there.
>
> Regards
> JB
>
>
>
> On 11/26/2015 02:04 PM, CLEMENT Jean-Philippe wrote:
>
> Dear Karaf Team,
>
> I have a strange behavior with Karaf (*) when started for the first 
> time. A bean is started then stopped then re-started. This behavior is 
> not 100% reproducible but happens maybe one-half of the time.
>
> That bean is instantiated via Blueprint and uses a 
> property-placeholder with update-strategy=”reload”. The “Karaf 
> distribution” is made by a custom assembly which includes both bundles and 
> configuration files.
>
> During the first bundle start the only configuration variable (a
> String) is not substituted which is a first issue (1). Then the bundle 
> is stopped and restarted with the substituted string. This is a second 
> issue (2) as I expected the bundle to start only one time as the 
> configuration file did not really change.
>
> Is this problem already known? Is there a workaround?
>
> Kind regards,
>
> JP
>
> [@@ OPEN @@]
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org <mailto:jbono...@apache.org> 
> http://blog.nanthrax.net Talend - http://www.talend.com
>
>
>
> --
>
>
> Apache Member
>
> Apache Karaf <http://karaf.apache.org/> Committer & PMC OPS4J Pax Web 
> <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & Project 
> Lead blog <http://notizblog.nierbeck.de/>
>
> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>
> Software Architect / Project Manager / Scrum Master
>

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

RE: Karaf 4.0.3 - no custom shell commands

2015-11-16 Thread CLEMENT Jean-Philippe

Hi JB,

The bean does not implement any interface, so I guess from what you said is a 
"gogo" command.

JP

[@@ OPEN @@]


-Message d'origine-
De : Jean-Baptiste Onofré [mailto:j...@nanthrax.net] 
Envoyé : lundi 16 novembre 2015 18:15
À : user@karaf.apache.org
Objet : Re: Karaf 4.0.3 - no custom shell commands

Hi JP,

does your command bean implements
org.apache.karaf.shell.api.action.Action or is it a gogo command ?

Regards
JB

On 11/16/2015 06:05 PM, CLEMENT Jean-Philippe wrote:
> Dear Karaf addicts,
>
> I export custom Karaf shell commands using blueprint. It was ok with 
> Karaf 3.0.x, but not working (i.e. no custom command available in the
> shell) with 4.0.3.
>
> For instance:
>
> Java:
>
> public /*final*/ MySimulator { // No final as GOGO command
>
> public void sayHello() {
>
> System.out.println("hello");
>
> }
>
> }
>
> XML:
>
> 
>
> 
>
> 
>
>
>
>
>
> 
>
>  sayHello
>
> 
>
> 
>
> 
>
> 
>
> How to fix this and allow Karaf to handle my commands?
>
> PS: the assembly does include the following boot features:
> aries-blueprint, bundle, shell-compat, ssh
>
> Kind regards,
>
> Jean-Philippe
>
> [@@ OPEN @@]
>

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

Karaf 4.0.3 - no custom shell commands

2015-11-16 Thread CLEMENT Jean-Philippe

Dear Karaf addicts,

I export custom Karaf shell commands using blueprint. It was ok with Karaf 
3.0.x, but not working (i.e. no custom command available in the shell) with 
4.0.3.

For instance:
Java:

public /*final*/ MySimulator { // No final as GOGO command

public void sayHello() {

  System.out.println("hello");

}

}


XML:









  

  

   

sayHello

   

  





How to fix this and allow Karaf to handle my commands?

PS: the assembly does include the following boot features: aries-blueprint, 
bundle, shell-compat, ssh

Kind regards,
Jean-Philippe

[@@ OPEN @@]

RE: Karaf assembly version

2015-11-12 Thread CLEMENT Jean-Philippe

So I finally had time to look for a solution. I tried several thing and faced 
both a Karaf bug and a Maven bug which are not yet fixed. I finally found an 
easy solution using the Google replacer plugin to populate a cfg file and used 
the config admin to load it.

I created a simple "assembly.cfg" file under the filtered-resources/etc of my 
assembly containing:
version=%VERSION%
timestamp=%TIMESTAMP%

With the corresponding Maven conf:


com.google.code.maven-replacer-plugin
replacer
1.5.3


compile

replace





${basedir}/src/main/filtered-resources/etc/assembly.cfg

${basedir}/target/assembly/etc/assembly.cfg


%VERSION%

${project.version}



%TIMESTAMP%

${maven.build.timestamp}





JP

[@@ OPEN @@]


-Message d'origine-
De : CLEMENT Jean-Philippe [mailto:jean-philippe.clem...@fr.thalesgroup.com] 
Envoyé : mardi 6 octobre 2015 09:05
À : user@karaf.apache.org
Objet : RE: Karaf assembly version

Great, I will investigate in that direction(s).

I also thought about another solution which might be simpler. In the assembly 
we have a kind of main feature which does have a version. Is there a way to 
retrieve it programmatically?

Regards,
JP

[@@ OPEN @@]

-Message d'origine-
De : Jean-Baptiste Onofré [mailto:j...@nanthrax.net] Envoyé : lundi 5 octobre 
2015 17:15 À : user@karaf.apache.org Objet : Re: Karaf assembly version

You can do that with resources-plugin and Maven directly (and also the artifact 
build helper).

Regards
JB

On 10/05/2015 05:11 PM, CLEMENT Jean-Philippe wrote:
> ...and during the assembly, is there a way to write it to a file?
>
> JP
>
> [@@ OPEN @@]
>
>
> -Message d'origine-
> De : Jean-Baptiste Onofré [mailto:j...@nanthrax.net] Envoyé : lundi 5 
> octobre 2015 16:52 À : user@karaf.apache.org Objet : Re: Karaf 
> assembly version
>
> So basically the project.version.
>
> I don't see anything already there for that. Sorry.
>
> Regards
> JB
>
> On 10/05/2015 04:48 PM, CLEMENT Jean-Philippe wrote:
>> Hi JB,
>>
>> The info shows the Karaf version (for instance 3.0.2), but I would like the 
>> assembly one, i.e. the one used to name the assembly archives (both .tar.gz 
>> and .zip).
>>
>> I would need this information at runtime. Is there a way to retrieve it?
>>
>> JP
>>
>> [@@ OPEN @@]
>>
>>
>> -Message d'origine-
>> De : Jean-Baptiste Onofré [mailto:j...@nanthrax.net] Envoyé : lundi 5 
>> octobre 2015 16:06 À : user@karaf.apache.org Objet : Re: Karaf 
>> assembly version
>>
>> Hi JP,
>>
>> you mean the version that you have in shell:info for instance ?
>>
>> You have a System property at runtime about that. I guess you need at build 
>> time ?
>>
>> Regards
>> JB
>>
>> On 10/05/2015 03:46 PM, CLEMENT Jean-Philippe wrote:
>>> Dear Karaf,
>>>
>>> I would like to retrieve the version used by the karaf-maven-plugin during 
>>> the assembly (for instance sample-assembly-1.0.0-SNAPSHOT.tar.gz => 
>>> 1.0.0-SNAPSHOT). The goal is to show it inside the application (something 
>>> like the "about" box).
>>>
>>> Is there a simple way to do so?
>>>
>>> Kind regards,
>>> JP
>>>
>>> [@@ OPEN @@]
>>>
>>
>> --
>> 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
>

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

RE: [ANN] Apache Karaf 4.0.2 Released!

2015-11-10 Thread CLEMENT Jean-Philippe

.4.0.jar
[ERROR] urls[54] = 
file:/svolusers/usrhome/clement.jp/.m2/repository/org/ops4j/base/ops4j-base-lang/1.5.0/ops4j-base-lang-1.5.0.jar
[ERROR] urls[55] = 
file:/svolusers/usrhome/clement.jp/.m2/repository/org/ops4j/base/ops4j-base-monitors/1.4.0/ops4j-base-monitors-1.4.0.jar
[ERROR] urls[56] = 
file:/svolusers/usrhome/clement.jp/.m2/repository/org/ops4j/pax/swissbox/pax-swissbox-bnd/1.8.2/pax-swissbox-bnd-1.8.2.jar
[ERROR] urls[57] = 
file:/svolusers/usrhome/clement.jp/.m2/repository/biz/aQute/bnd/bndlib/2.4.0/bndlib-2.4.0.jar
[ERROR] urls[58] = 
file:/svolusers/usrhome/clement.jp/.m2/repository/org/ops4j/pax/url/pax-url-commons/2.4.3/pax-url-commons-2.4.3.jar
[ERROR] urls[59] = 
file:/svolusers/usrhome/clement.jp/.m2/repository/org/ops4j/pax/swissbox/pax-swissbox-property/1.8.2/pax-swissbox-property-1.8.2.jar
[ERROR] urls[60] = 
file:/svolusers/usrhome/clement.jp/.m2/repository/org/ops4j/base/ops4j-base-util-property/1.5.0/ops4j-base-util-property-1.5.0.jar
[ERROR] urls[61] = 
file:/svolusers/usrhome/clement.jp/.m2/repository/org/ops4j/pax/url/pax-url-aether/2.4.3/pax-url-aether-2.4.3.jar
[ERROR] urls[62] = 
file:/svolusers/usrhome/clement.jp/.m2/repository/org/slf4j/jcl-over-slf4j/1.7.12/jcl-over-slf4j-1.7.12.jar
[ERROR] urls[63] = 
file:/svolusers/usrhome/clement.jp/.m2/repository/org/ops4j/pax/url/pax-url-war/2.4.3/pax-url-war-2.4.3-uber.jar
[ERROR] urls[64] = 
file:/svolusers/usrhome/clement.jp/.m2/repository/org/ops4j/pax/swissbox/pax-swissbox-optional-jcl/1.8.2/pax-swissbox-optional-jcl-1.8.2.jar
[ERROR] urls[65] = 
file:/svolusers/usrhome/clement.jp/.m2/repository/org/apache/karaf/deployer/org.apache.karaf.deployer.spring/4.0.2/org.apache.karaf.deployer.spring-4.0.2.jar
[ERROR] urls[66] = 
file:/svolusers/usrhome/clement.jp/.m2/repository/org/apache/karaf/deployer/org.apache.karaf.deployer.blueprint/4.0.2/org.apache.karaf.deployer.blueprint-4.0.2.jar
[ERROR] urls[67] = 
file:/svolusers/usrhome/clement.jp/.m2/repository/org/apache/karaf/deployer/org.apache.karaf.deployer.features/4.0.2/org.apache.karaf.deployer.features-4.0.2.jar
[ERROR] urls[68] = 
file:/svolusers/usrhome/clement.jp/.m2/repository/org/apache/karaf/deployer/org.apache.karaf.deployer.kar/4.0.2/org.apache.karaf.deployer.kar-4.0.2.jar
[ERROR] urls[69] = 
file:/svolusers/usrhome/clement.jp/.m2/repository/org/apache/karaf/kar/org.apache.karaf.kar.core/4.0.2/org.apache.karaf.kar.core-4.0.2.jar
[ERROR] urls[70] = 
file:/svolusers/usrhome/clement.jp/.m2/repository/org/apache/karaf/shell/org.apache.karaf.shell.console/4.0.2/org.apache.karaf.shell.console-4.0.2.jar
[ERROR] urls[71] = 
file:/svolusers/usrhome/clement.jp/.m2/repository/jline/jline/2.13/jline-2.13.jar
[ERROR] urls[72] = 
file:/svolusers/usrhome/clement.jp/.m2/repository/org/apache/karaf/jaas/org.apache.karaf.jaas.modules/4.0.2/org.apache.karaf.jaas.modules-4.0.2.jar
[ERROR] urls[73] = 
file:/svolusers/usrhome/clement.jp/.m2/repository/org/apache/karaf/jaas/org.apache.karaf.jaas.config/4.0.2/org.apache.karaf.jaas.config-4.0.2.jar
[ERROR] urls[74] = 
file:/svolusers/usrhome/clement.jp/.m2/repository/org/apache/karaf/shell/org.apache.karaf.shell.core/4.0.2/org.apache.karaf.shell.core-4.0.2.jar
[ERROR] urls[75] = 
file:/svolusers/usrhome/clement.jp/.m2/repository/org/apache/sshd/sshd-core/0.14.0/sshd-core-0.14.0.jar
[ERROR] urls[76] = 
file:/svolusers/usrhome/clement.jp/.m2/repository/org/apache/commons/commons-compress/1.10/commons-compress-1.10.jar
[ERROR] urls[77] = 
file:/svolusers/usrhome/clement.jp/.m2/repository/org/osgi/org.osgi.core/6.0.0/org.osgi.core-6.0.0.jar
[ERROR] urls[78] = 
file:/svolusers/usrhome/clement.jp/.m2/repository/org/apache/xbean/xbean-finder-shaded/3.18/xbean-finder-shaded-3.18.jar
[ERROR] urls[79] = 
file:/svolusers/usrhome/clement.jp/.m2/repository/org/apache/xbean/xbean-asm5-shaded/3.18/xbean-asm5-shaded-3.18.jar
[ERROR] Number of foreign imports: 1
[ERROR] import: Entry[import  from realm ClassRealm[project>XXX:YYY:ZZZ, 
parent: ClassRealm[maven.api, parent: null]]]

Any idea what's wrong?

Regards,
JP

[@@ OPEN @@]

-Message d'origine-
De : Jean-Baptiste Onofré [mailto:j...@nanthrax.net]
Envoyé : mardi 10 novembre 2015 11:19
À : user@karaf.apache.org
Objet : Re: [ANN] Apache Karaf 4.0.2 Released!

Hi JP,

Karaf POM references bndlib 2.4.0 (not 3.0.0).

Doing a dependency:tree on the karaf-maven-plugin, we can see:

[INFO] +- org.apache.felix:maven-bundle-plugin:jar:3.0.0:compile
[INFO] |  +- biz.aQute.bnd:biz.aQute.bndlib:jar:3.0.0:compile
[INFO] |  +- org.apache.maven:maven-archiver:jar:2.5:compile


So, bndlib is not directly referenced by Karaf, but transitively from 
maven-bundle-plugin.

You need the additional repository to resolve bndlib 3.0.0, let me paste the 
full URL:

Regards
JB

On 11/10/2015 11:11 AM, CLEMENT Jean-Philippe wrote:
> Dear Karaf Team,
>
> I moved our assembly based on Karaf 3.0.2 to the 4.0.2 version. During the 
> build we have a missing dependency on bndlib.jar 3.0.0:
>   " Unresolveable b

RE: [ANN] Apache Karaf 4.0.2 Released!

2015-11-10 Thread CLEMENT Jean-Philippe

Dear Karaf Team,

I moved our assembly based on Karaf 3.0.2 to the 4.0.2 version. During the 
build we have a missing dependency on bndlib.jar 3.0.0:
 " Unresolveable build extension: Plugin 
org.apache.karaf.tooling:karaf-maven-plugin:4.0.2 or one of its dependencies 
could not be resolved: Failure to find biz.aQute.bnd:biz.aQute.bndlib:jar:3.0.0 
"

Going to Maven Central there is no jar for this version. I only found the pom 
file as long as its sources, but no .jar!

How did you build Karaf 4.0.2?

Regards,
JP

[@@ THALES GROUP INTERNAL @@]

-Message d'origine-
De : Jean-Baptiste Onofré [mailto:j...@nanthrax.net] 
Envoyé : mardi 13 octobre 2015 08:06
À : Karaf Dev; user
Objet : [ANN] Apache Karaf 4.0.2 Released!

The Karaf team is pleased to announce the release of Karaf version 4.0.2.

This is an update patch for Apache Karaf 4.0.x, containing many bug fixes, 
dependency updates, and improvements.

http://karaf.apache.org/

This release is available from
http://karaf.apache.org/index/community/download.html#Karaf4.0.2 and

Maven:

  
  org.apache.karaf
  apache-karaf
  4.0.2
  

Release Notes:

http://karaf.apache.org/index/community/download/karaf-4.0.2-release.html

Enjoy!

RE: [ANN] Apache Karaf 4.0.2 Released!

2015-11-10 Thread CLEMENT Jean-Philippe

=> Issue fixed with Maven 3.3.3

Thanks!

Regards,
JP

[@@ OPEN @@]


-Message d'origine-
De : Jean-Baptiste Onofré [mailto:j...@nanthrax.net]
Envoyé : mardi 10 novembre 2015 12:50
À : user@karaf.apache.org
Objet : Re: [ANN] Apache Karaf 4.0.2 Released!

I use Maven 3.3.3.

Regards
JB

On 11/10/2015 12:01 PM, CLEMENT Jean-Philippe wrote:
> Maven version is 3.0.3. I don't specify any wagon extension.
>
> Googling the error, I found "I could resolve this after I updated from maven 
> 3.0.3 to maven 3.0.5". Which version are you using?
>
> Regards,
> JP
>
> [@@ OPEN @@]
>
>
> -Message d'origine-
> De : Jean-Baptiste Onofré [mailto:j...@nanthrax.net] Envoyé : mardi 10
> novembre 2015 11:52 À : user@karaf.apache.org Objet : Re: [ANN] Apache
> Karaf 4.0.2 Released!
>
> What's your Maven version ?
>
> Don't you override the http wagon description in build extensions ?
>
> In Karaf, we have:
>
>   
>   org.apache.maven.wagon
>   wagon-http
>   2.8
>   
>
>
> Regards
> JB
>
> On 11/10/2015 11:36 AM, CLEMENT Jean-Philippe wrote:
>> Hi JB,
>>
>> I wasn't too clear. Our local repo does now have access to Maven Central. 
>> Going on Maven Central with a browser, finding bndlib and clicking on it 
>> does not show any ".jar". I guess that's why our repo did not automatically 
>> retrieve it. Strange thing, on the web page, just before clicking on the 
>> artifact details, there is a "jar" button which allows to manually download 
>> the file. So I added it to our 3rdparty repo.
>>
>> Now I face another issue:
>> Exception in thread "pool-2-thread-1" java.lang.NoSuchMethodError: 
>> org.apache.maven.wagon.providers.http.AbstractHttpClientWagon.getReadTimeout()I
>>   at 
>> org.apache.maven.wagon.providers.http.AbstractHttpClientWagon.execute(AbstractHttpClientWagon.java:798)
>>   at 
>> org.apache.maven.wagon.providers.http.AbstractHttpClientWagon.fillInputData(AbstractHttpClientWagon.java:1000)
>>   at 
>> org.apache.maven.wagon.providers.http.AbstractHttpClientWagon.fillInputData(AbstractHttpClientWagon.java:977)
>>   at 
>> org.apache.maven.wagon.StreamWagon.getInputStream(StreamWagon.java:116)
>>   at 
>> org.apache.maven.wagon.StreamWagon.getIfNewer(StreamWagon.java:88)
>>   at org.apache.maven.wagon.StreamWagon.get(StreamWagon.java:61)
>>   at 
>> org.sonatype.aether.connector.wagon.WagonRepositoryConnector$GetTask.run(WagonRepositoryConnector.java:608)
>>   at 
>> org.sonatype.aether.util.concurrency.RunnableErrorForwarder$1.run(RunnableErrorForwarder.java:64)
>>   at 
>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>>   at 
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>>   at java.lang.Thread.run(Thread.java:745)
>> [INFO] Final Memory: 31M/331M
>> [INFO]
>> -
>> -
>> -- [ERROR] Failed to execute goal
>> org.apache.karaf.tooling:karaf-maven-plugin:4.0.2:features-generate-d
>> e scriptor (default-features-generate-descriptor) on project
>> AAA-feature: Execution default-features-generate-descriptor of goal
>> org.apache.karaf.tooling:karaf-maven-plugin:4.0.2:features-generate-d
>> e scriptor failed: An API incompatibility was encountered while
>> executing
>> org.apache.karaf.tooling:karaf-maven-plugin:4.0.2:features-generate-d
>> e
>> scriptor: java.lang.NoSuchMethodError:
>> org.apache.maven.wagon.providers.http.AbstractHttpClientWagon.getRead
>> T
>> imeout()I [ERROR]
>> -
>> [ERROR] realm =plugin>org.apache.karaf.tooling:karaf-maven-plugin:4.0.2
>> [ERROR] strategy =
>> org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
>> [ERROR] urls[0] =
>> file:/svolusers/usrhome/clement.jp/.m2/repository/org/apache/karaf/to
>> o ling/karaf-maven-plugin/4.0.2/karaf-maven-plugin-4.0.2.jar
>> [ERROR] urls[1] =
>> file:/svolusers/usrhome/clement.jp/.m2/repository/org/sonatype/sisu/s
>> i su-inject-bean/2.1.1/sisu-inject-bean-2.1.1.jar
>> [ERROR] urls[2] =
>> file:/svolusers/usrhome/clement.jp/.m2/repository/org/sonatype/sisu/s
>> i su-guice/2.9.4/sisu-guice-2.9.4-no_aop.jar
>> [ERROR] urls[3] =
>> file:/svolusers/usrhome/clement.jp/.m2/repository/org/sonatype/aether
>> / aether-util/1.11/aether-util-1.11.jar
>> [ERROR] urls[4] =
>>

RE: Karaf instances and native libs

2015-10-08 Thread CLEMENT Jean-Philippe

I wish I could have more time to go deeper… did you take a glance at JNA?

[@@ OPEN @@]

De : craig niles [mailto:nile...@gmail.com]
Envoyé : mercredi 7 octobre 2015 17:09
À : user@karaf.apache.org
Objet : Re: Karaf instances and native libs

The primary problem I was having is that the JVM isn't able to load transitive
native dependencies--i.e., it isn't a monolithic native library. When loading
the library through the OSGi mechanism (Bundle-NativeCode) it can find the main
.so/.dll, but will fail because some other native dependency that is included
with it isn't available. Even when specifying all the dependencies manually
this way it fails. This is why I wanted to have the libs available through
LD_LIBRARY_PATH--its the only sure way I've found to get them to load. The
other problem is that the middle-ware may try to load the native library itself
If it were the guaranteed case that each middle-ware used one and only one
.so/.dll file, I wouldn't monkey around with LD_LIBRARY_PATH...but I can't get
that guarantee.

I can't have more than one implementation of the middle-ware available in a
process. To get around this I programattically start child karaf processes and
specify which middle-ware they should use with a karaf feature. Then, the
child karaf process communicates with the root using DOSGi to share information
made available through the middle-ware.

I also already have JNI bindings available to me as part of the middle-ware
spec, and they're implemented. I hear you about blueprint--but the spec for
the middle-ware already uses SPI (and its also used internally in our in-house
middle-ware) so I can't get away from SPI all together. I've used Aries SPIFly
to make them available as OSGi services, and that's working nicely with iPOJO
so far.
Just to give a little perspective, an example implementation of the middle-ware
is here (though we're not using this one, we have an in-house implementation
and also need to support one from another vendor):

https://github.com/openlvc/portico

The package hla.rti1516e is the public interface that is implemented:
https://github.com/openlvc/portico/tree/master/codebase/src/java/portico/hla/rti1516e

Thanks for the help so far, I appreciate it.

On Wed, Oct 7, 2015 at 9:13 AM, CLEMENT Jean-Philippe
<jean-philippe.clem...@fr.thalesgroup.com<mailto:jean-philippe.clem...@fr.thalesgroup.com>>
wrote:
I’m just wondering why you want to extract the native libraries. Karaf &
maven-bundle-plugin native support is really great IMHO.

But I’m not too sure what “simultaneously” means. I will assume you mean
several suppliers running in parallel inside a Karaf instance.

Let’s say you have a “compute” method with several native implementations. So
you may define a Java interface which contains the signature of this method.
Then implement this contract in several classes using a native call.

And then use the whiteboard pattern. As the implementations does have a common
contract, you may expose them as OSGi services as long with their
characteristics (provider name, type, accuracy… whatever). Then the consumer(s)
may retrieve all suppliers, or supplier(s) matching some characteristics.

PS: Both service publishing and retrieval can be made easy using blueprint

Again this is just a thought. Would it be applicable to your issue?

Regards,
JP

[@@ OPEN @@]

De : craig niles [mailto:nile...@gmail.com<mailto:nile...@gmail.com>]
Envoyé : mardi 6 octobre 2015 17:06
À : user@karaf.apache.org<mailto:user@karaf.apache.org>
Objet : Re: Karaf instances and native libs

Would you mind elaborating a bit on what you mean by this?

On Tue, Oct 6, 2015 at 9:21 AM, CLEMENT Jean-Philippe
<jean-philippe.clem...@fr.thalesgroup.com<mailto:jean-philippe.clem...@fr.thalesgroup.com>>
wrote:
Just a thought, why not wrapping the native libraries and expose them as a
regular OSGi service through an API?

[@@ OPEN @@]

De : craig niles [mailto:nile...@gmail.com<mailto:nile...@gmail.com>]
Envoyé : lundi 5 octobre 2015 20:39
À : user@karaf.apache.org<mailto:user@karaf.apache.org>
Objet : Karaf instances and native libs

Hi,
I have an important piece of middle-ware that depends on native libraries. I
have a requirement to support multiple implementation of this middle-ware
simultaneously. To accomplish this I want to start child karaf instances from
my main process.
I'm using an extender pattern to detect when a bundle is installed that
provides the middle-ware. When detected, it extracts the required native libs
from the bundle to the instance lib directory (e.g.
$KARAF_HOME/instances/foo-01/lib).
I've found an issue, however, with the way LD_LIBRARY_PATH is being set when
the instance is started using the instance's start script--the KARAF_BASE
variable isn't set to the instance's directory and consequentially
LD_LIBRARY_PATH doesn't include the instance's lib directory whe

RE: Karaf instances and native libs

2015-10-07 Thread CLEMENT Jean-Philippe

I’m just wondering why you want to extract the native libraries. Karaf &
maven-bundle-plugin native support is really great IMHO.

But I’m not too sure what “simultaneously” means. I will assume you mean
several suppliers running in parallel inside a Karaf instance.

PS: Both service publishing and retrieval can be made easy using blueprint

Again this is just a thought. Would it be applicable to your issue?

Regards,
JP

[@@ OPEN @@]

De : craig niles [mailto:nile...@gmail.com]
Envoyé : mardi 6 octobre 2015 17:06
À : user@karaf.apache.org
Objet : Re: Karaf instances and native libs

Would you mind elaborating a bit on what you mean by this?

[@@ OPEN @@]

RE: Karaf assembly version

2015-10-06 Thread CLEMENT Jean-Philippe

Great, I will investigate in that direction(s).

I also thought about another solution which might be simpler. In the assembly 
we have a kind of main feature which does have a version. Is there a way to 
retrieve it programmatically?

Regards,
JP

[@@ OPEN @@]

-Message d'origine-
De : Jean-Baptiste Onofré [mailto:j...@nanthrax.net] 
Envoyé : lundi 5 octobre 2015 17:15
À : user@karaf.apache.org
Objet : Re: Karaf assembly version

You can do that with resources-plugin and Maven directly (and also the artifact 
build helper).

Regards
JB

On 10/05/2015 05:11 PM, CLEMENT Jean-Philippe wrote:
> ...and during the assembly, is there a way to write it to a file?
>
> JP
>
> [@@ OPEN @@]
>
>
> -Message d'origine-
> De : Jean-Baptiste Onofré [mailto:j...@nanthrax.net] Envoyé : lundi 5 
> octobre 2015 16:52 À : user@karaf.apache.org Objet : Re: Karaf 
> assembly version
>
> So basically the project.version.
>
> I don't see anything already there for that. Sorry.
>
> Regards
> JB
>
> On 10/05/2015 04:48 PM, CLEMENT Jean-Philippe wrote:
>> Hi JB,
>>
>> The info shows the Karaf version (for instance 3.0.2), but I would like the 
>> assembly one, i.e. the one used to name the assembly archives (both .tar.gz 
>> and .zip).
>>
>> I would need this information at runtime. Is there a way to retrieve it?
>>
>> JP
>>
>> [@@ OPEN @@]
>>
>>
>> -Message d'origine-
>> De : Jean-Baptiste Onofré [mailto:j...@nanthrax.net] Envoyé : lundi 5 
>> octobre 2015 16:06 À : user@karaf.apache.org Objet : Re: Karaf 
>> assembly version
>>
>> Hi JP,
>>
>> you mean the version that you have in shell:info for instance ?
>>
>> You have a System property at runtime about that. I guess you need at build 
>> time ?
>>
>> Regards
>> JB
>>
>> On 10/05/2015 03:46 PM, CLEMENT Jean-Philippe wrote:
>>> Dear Karaf,
>>>
>>> I would like to retrieve the version used by the karaf-maven-plugin during 
>>> the assembly (for instance sample-assembly-1.0.0-SNAPSHOT.tar.gz => 
>>> 1.0.0-SNAPSHOT). The goal is to show it inside the application (something 
>>> like the "about" box).
>>>
>>> Is there a simple way to do so?
>>>
>>> Kind regards,
>>> JP
>>>
>>> [@@ OPEN @@]
>>>
>>
>> --
>> 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
>

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

RE: Karaf instances and native libs

2015-10-06 Thread CLEMENT Jean-Philippe

Just a thought, why not wrapping the native libraries and expose them as a 
regular OSGi service through an API?

JP

[@@ OPEN @@]

De : craig niles [mailto:nile...@gmail.com]
Envoyé : lundi 5 octobre 2015 20:39
À : user@karaf.apache.org
Objet : Karaf instances and native libs

Hi,
I have an important piece of middle-ware that depends on native libraries.  I 
have a requirement to support multiple implementation of this middle-ware 
simultaneously.  To accomplish this I want to start child karaf instances from 
my main process.
I'm using an extender pattern to detect when a bundle is installed that 
provides the middle-ware.  When detected, it extracts the required native libs 
from the bundle to the instance lib directory (e.g. 
$KARAF_HOME/instances/foo-01/lib).
I've found an issue, however, with the way LD_LIBRARY_PATH is being set when 
the instance is started using the instance's start script--the KARAF_BASE 
variable isn't set to the instance's directory and consequentially 
LD_LIBRARY_PATH doesn't include the instance's lib directory when ran.  This 
isn't a problem, however, when started with the instance's karaf script.
Does anyone have any ideas or guidance on how to handle this?

Karaf assembly version

2015-10-05 Thread CLEMENT Jean-Philippe

Dear Karaf,

I would like to retrieve the version used by the karaf-maven-plugin during the 
assembly (for instance sample-assembly-1.0.0-SNAPSHOT.tar.gz => 
1.0.0-SNAPSHOT). The goal is to show it inside the application (something like 
the "about" box).

Is there a simple way to do so?

Kind regards,
JP

[@@ OPEN @@]

RE: Karaf assembly version

2015-10-05 Thread CLEMENT Jean-Philippe

...and during the assembly, is there a way to write it to a file?

JP

[@@ OPEN @@]


-Message d'origine-
De : Jean-Baptiste Onofré [mailto:j...@nanthrax.net] 
Envoyé : lundi 5 octobre 2015 16:52
À : user@karaf.apache.org
Objet : Re: Karaf assembly version

So basically the project.version.

I don't see anything already there for that. Sorry.

Regards
JB

On 10/05/2015 04:48 PM, CLEMENT Jean-Philippe wrote:
> Hi JB,
>
> The info shows the Karaf version (for instance 3.0.2), but I would like the 
> assembly one, i.e. the one used to name the assembly archives (both .tar.gz 
> and .zip).
>
> I would need this information at runtime. Is there a way to retrieve it?
>
> JP
>
> [@@ OPEN @@]
>
>
> -Message d'origine-
> De : Jean-Baptiste Onofré [mailto:j...@nanthrax.net] Envoyé : lundi 5 
> octobre 2015 16:06 À : user@karaf.apache.org Objet : Re: Karaf 
> assembly version
>
> Hi JP,
>
> you mean the version that you have in shell:info for instance ?
>
> You have a System property at runtime about that. I guess you need at build 
> time ?
>
> Regards
> JB
>
> On 10/05/2015 03:46 PM, CLEMENT Jean-Philippe wrote:
>> Dear Karaf,
>>
>> I would like to retrieve the version used by the karaf-maven-plugin during 
>> the assembly (for instance sample-assembly-1.0.0-SNAPSHOT.tar.gz => 
>> 1.0.0-SNAPSHOT). The goal is to show it inside the application (something 
>> like the "about" box).
>>
>> Is there a simple way to do so?
>>
>> Kind regards,
>> JP
>>
>> [@@ OPEN @@]
>>
>
> --
> 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

RE: Karaf assembly version

2015-10-05 Thread CLEMENT Jean-Philippe

Hi JB,

The info shows the Karaf version (for instance 3.0.2), but I would like the 
assembly one, i.e. the one used to name the assembly archives (both .tar.gz and 
.zip).

I would need this information at runtime. Is there a way to retrieve it?

JP

[@@ OPEN @@]

-Message d'origine-
De : Jean-Baptiste Onofré [mailto:j...@nanthrax.net] 
Envoyé : lundi 5 octobre 2015 16:06
À : user@karaf.apache.org
Objet : Re: Karaf assembly version

Hi JP,

you mean the version that you have in shell:info for instance ?

You have a System property at runtime about that. I guess you need at build 
time ?

Regards
JB

On 10/05/2015 03:46 PM, CLEMENT Jean-Philippe wrote:
> Dear Karaf,
>
> I would like to retrieve the version used by the karaf-maven-plugin during 
> the assembly (for instance sample-assembly-1.0.0-SNAPSHOT.tar.gz => 
> 1.0.0-SNAPSHOT). The goal is to show it inside the application (something 
> like the "about" box).
>
> Is there a simple way to do so?
>
> Kind regards,
> JP
>
> [@@ OPEN @@]
>

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

RE: Best practices : Configuration shared between bundles

2015-09-25 Thread CLEMENT Jean-Philippe

Hi Arnaud,

I’m not too sure what you need. Wouldn’t two property placeholders be ok?




Regards,
JP

[@@ OPEN @@]

De : Arnaud Deprez [mailto:arnaudep...@gmail.com]
Envoyé : vendredi 25 septembre 2015 10:05
À : user@karaf.apache.org
Objet : Best practices : Configuration shared between bundles

Hi folks,

I would like to have your opinion about my needs.
I've several bundles which all need their custom configuration (own PID) but 
all of them depends on some common configuration depending on which environment 
(ie: test, production) my karaf instance is running.

I'm currently using apache blueprint. So I would like to do is for example, if 
I use [[env.name]] it will retrieve the config value from 
global configuration and if I use {{bundle.name}}.

So my questions is :
Is there a way to use common/global configuration with my current bundle 
configuration ?
If yes, is it possible with blueprint or do I have to change my tech stack ?
What are best practices ?
And icing on the cake, do you have example ?

Rgds,

Arnaud

RE: Karaf upgrade 3.0.2 -> 4.0.1 leads to ServiceUnavailableException

2015-09-18 Thread CLEMENT Jean-Philippe

Hi JB,

Service B does not register with the same interface (nor a subtype).

We still use Blueprint using the aries-blueprint feature.

What is strange is that A fails without waiting any grace period. The waited 
reference is used inside the Blueprint as an argument of a bean, which is used 
as a factory-ref for another bean, which is used as an argument for a "last" 
bean :S

Regards,
JP

[@@ THALES GROUP INTERNAL @@]

-Message d'origine-
De : Jean-Baptiste Onofré [mailto:j...@nanthrax.net] 
Envoyé : vendredi 18 septembre 2015 10:49
À : user@karaf.apache.org
Objet : Re: Karaf upgrade 3.0.2 -> 4.0.1 leads to ServiceUnavailableException

Hi JP,

Does Service B register the "higher services" with the same interface as A ?

Do you still use blueprint in Karaf 4 (and so proxies) or directly an Activator 
(extending BaseActivator) ?

Regards
JB

On 09/18/2015 10:38 AM, CLEMENT Jean-Philippe wrote:
> Dear Karaf,
>
> I upgraded Karaf version from 3.0.2 to 4.0.1 and obtained a 
> ServiceUnavailbleException from one of our bundles – which was working 
> fine with the former version of Karaf.
>
> I must first say that services registering/retrieval implied in this 
> issue are not made in a clean way as they imply kind of circular 
> dependencies. But it was working fine with Karaf 3.0.2. Those services 
> are registered and retrieved using Blueprint.
>
> We have a bundle A which exports base services which are used by a 
> bundle B. Bundle B will use those base services and will export higher 
> added value ones. One of B services are used by A. This service 
> reference (A) is set as optional.
>
> I don’t know whether Karaf 3.0.2 was accepting something wrong which 
> was corrected in 4.0.1, if it’s a 4.0.1 bug, or maybe just a behavior 
> difference which may be configured somewhere.
>
> Maybe first, is the starting scenario correct (even if not recommended)?
>
> Thank you,
>
> JP
>
> [@@ OPEN @@]
>

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

Karaf upgrade 3.0.2 -> 4.0.1 leads to ServiceUnavailableException

2015-09-18 Thread CLEMENT Jean-Philippe

Dear Karaf,

I upgraded Karaf version from 3.0.2 to 4.0.1 and obtained a 
ServiceUnavailbleException from one of our bundles – which was working fine 
with the former version of Karaf.

I must first say that services registering/retrieval implied in this issue are 
not made in a clean way as they imply kind of circular dependencies. But it was 
working fine with Karaf 3.0.2. Those services are registered and retrieved 
using Blueprint.

We have a bundle A which exports base services which are used by a bundle B. 
Bundle B will use those base services and will export higher added value ones. 
One of B services are used by A. This service reference (A) is set as optional.

I don’t know whether Karaf 3.0.2 was accepting something wrong which was 
corrected in 4.0.1, if it’s a 4.0.1 bug, or maybe just a behavior difference 
which may be configured somewhere.

Maybe first, is the starting scenario correct (even if not recommended)?

Thank you,
JP

[@@ OPEN @@]

RE: Karaf upgrade 3.0.2 -> 4.0.1 leads to ServiceUnavailableException

2015-09-18 Thread CLEMENT Jean-Philippe

Christian,

I did some further testing.

If I don’t use the reference then I get no error which is strange as I still 
declare it (and the activation is eager). Maybe this is due to some 
optimization?

If I give the reference to a simple test bean as argument or property then I 
get the same issue:

1.ServiceUnavailableException: No matching service for optional OSGi 
service reference

2.The bundle (A) is still NOT waiting for any “grace period” of any kind 
and directly fails to start

If I use a reference-listener then no issue but the availability still has to 
be optional in order not to go in grace period.

I did not succeed in getting a null object. Why isn’t the bundle (A) waiting 
before failing?

JP

[@@ OPEN @@]

De : Christian Schneider [mailto:cschneider...@gmail.com] De la part de 
Christian Schneider
Envoyé : vendredi 18 septembre 2015 12:49
À : user@karaf.apache.org
Objet : Re: Karaf upgrade 3.0.2 -> 4.0.1 leads to ServiceUnavailableException

I think what happens is that blueprint starts up, wires the optional refrence, 
then calls the factory which results in a NPE.
Maybe this error is then just not reported correctly.

Try to do a try catch in the factory that uses the reference to the service and 
log if there is an exception.

Christian
Am 18.09.2015 um 12:33 schrieb CLEMENT Jean-Philippe:
I understand. The problem is the bundle (A) is failing to start. I do not get a 
null object.

I don’t know why it was always working perfectly and now not working at all.

Regards,
JP

[@@ OPEN @@]

De : Christian Schneider [mailto:cschneider...@gmail.com] De la part de 
Christian Schneider
Envoyé : vendredi 18 septembre 2015 12:27
À : user@karaf.apache.org<mailto:user@karaf.apache.org>
Objet : Re: Karaf upgrade 3.0.2 -> 4.0.1 leads to ServiceUnavailableException

Blueprint does not do service damping on optional services. So if you refer the 
service in your bean you have to cope with it being null.
You might use the callback blueprint offers when the service gets registered.

Christian

On 18.09.2015 10:38, CLEMENT Jean-Philippe wrote:
Dear Karaf,

I upgraded Karaf version from 3.0.2 to 4.0.1 and obtained a 
ServiceUnavailbleException from one of our bundles – which was working fine 
with the former version of Karaf.

I must first say that services registering/retrieval implied in this issue are 
not made in a clean way as they imply kind of circular dependencies. But it was 
working fine with Karaf 3.0.2. Those services are registered and retrieved 
using Blueprint.

We have a bundle A which exports base services which are used by a bundle B. 
Bundle B will use those base services and will export higher added value ones. 
One of B services are used by A. This service reference (A) is set as optional.

I don’t know whether Karaf 3.0.2 was accepting something wrong which was 
corrected in 4.0.1, if it’s a 4.0.1 bug, or maybe just a behavior difference 
which may be configured somewhere.

Maybe first, is the starting scenario correct (even if not recommended)?

Thank you,
JP

[@@ OPEN @@]







--

Christian Schneider

http://www.liquid-reality.de



Open Source Architect

http://www.talend.com

RE: Karaf upgrade 3.0.2 -> 4.0.1 leads to ServiceUnavailableException

2015-09-18 Thread CLEMENT Jean-Philippe

I understand. The problem is the bundle (A) is failing to start. I do not get a 
null object.

I don’t know why it was always working perfectly and now not working at all.

Regards,
JP

[@@ OPEN @@]

De : Christian Schneider [mailto:cschneider...@gmail.com] De la part de 
Christian Schneider
Envoyé : vendredi 18 septembre 2015 12:27
À : user@karaf.apache.org
Objet : Re: Karaf upgrade 3.0.2 -> 4.0.1 leads to ServiceUnavailableException

Blueprint does not do service damping on optional services. So if you refer the 
service in your bean you have to cope with it being null.
You might use the callback blueprint offers when the service gets registered.

Christian

On 18.09.2015 10:38, CLEMENT Jean-Philippe wrote:
Dear Karaf,

I upgraded Karaf version from 3.0.2 to 4.0.1 and obtained a 
ServiceUnavailbleException from one of our bundles – which was working fine 
with the former version of Karaf.

I must first say that services registering/retrieval implied in this issue are 
not made in a clean way as they imply kind of circular dependencies. But it was 
working fine with Karaf 3.0.2. Those services are registered and retrieved 
using Blueprint.

We have a bundle A which exports base services which are used by a bundle B. 
Bundle B will use those base services and will export higher added value ones. 
One of B services are used by A. This service reference (A) is set as optional.

I don’t know whether Karaf 3.0.2 was accepting something wrong which was 
corrected in 4.0.1, if it’s a 4.0.1 bug, or maybe just a behavior difference 
which may be configured somewhere.

Maybe first, is the starting scenario correct (even if not recommended)?

Thank you,
JP

[@@ OPEN @@]






--

Christian Schneider

http://www.liquid-reality.de



Open Source Architect

http://www.talend.com

RE: Karaf upgrade 3.0.2 -> 4.0.1 leads to ServiceUnavailableException

2015-09-18 Thread CLEMENT Jean-Philippe

In that case it would mean that the Blueprint used in Karaf 3.0.2 was bugged… 
why not. But I don’t catch how the system determines that the service 
publishing/discovery has ended and then missing services are errors. I have the 
feeling that the starting phase ends too early for some reason.

Are there any Aries blueprint settings about parallelism or things like that?

JP

[@@ OPEN @@]

De : Christian Schneider [mailto:cschneider...@gmail.com] De la part de 
Christian Schneider
Envoyé : vendredi 18 septembre 2015 14:22
À : user@karaf.apache.org
Objet : Re: Karaf upgrade 3.0.2 -> 4.0.1 leads to ServiceUnavailableException

I think you are getting the expected result. I was wrong with the assumption 
that you get null.

Blueprint will always inject a service proxy. The reason is that it can inject 
the proxy only at the context start.
So the ServiceUnavailableException when you use the service is the way 
blueprint tells you that no service is present.

So if you access the service in the factory it will fail with this exception. 
If you do not refer to it blueprint will start normally but of course you could
still get the exception whenever you access the service and it is not there.

Christian

On 18.09.2015 14:13, CLEMENT Jean-Philippe wrote:
Christian,

I did some further testing.

If I don’t use the reference then I get no error which is strange as I still 
declare it (and the activation is eager). Maybe this is due to some 
optimization?

If I give the reference to a simple test bean as argument or property then I 
get the same issue:

1.  ServiceUnavailableException: No matching service for optional OSGi 
service reference

2.  The bundle (A) is still NOT waiting for any “grace period” of any kind 
and directly fails to start

If I use a reference-listener then no issue but the availability still has to 
be optional in order not to go in grace period.

I did not succeed in getting a null object. Why isn’t the bundle (A) waiting 
before failing?

JP




--

Christian Schneider

http://www.liquid-reality.de



Open Source Architect

http://www.talend.com

RE: Karaf upgrade 3.0.2 -> 4.0.1 leads to ServiceUnavailableException

2015-09-18 Thread CLEMENT Jean-Philippe

Gave it a try but it did not change anything. Yep, we were just lucky it was 
working with the Blueprint version of Karaf 3.0.2.

We just have to clean this :)

Thanks a lot!

JP

[@@ OPEN @@]

De : Christian Schneider [mailto:cschneider...@gmail.com] De la part de 
Christian Schneider
Envoyé : vendredi 18 septembre 2015 15:26
À : user@karaf.apache.org
Objet : Re: Karaf upgrade 3.0.2 -> 4.0.1 leads to ServiceUnavailableException

If blueprint has a mandatory service defined it goes into grace period until 
the service is up (time by default 5 minutes I think).
For optional services it does not wait at all. So if you bundle A offers 
services that B needs to come up then at the time A comes up B can not yet be 
up.
That means if you just inject the optional service provided by B and use it in 
a factory it will always fail.

For a setting see config.properties
org.apache.aries.blueprint.synchronous=true

So you could switch karaf do statup blueprint bundles asynchronously. Be aware 
though that this can cause timing and concurrency issues if your bundles are 
not designed very carefully.

Christian


On 18.09.2015 15:19, CLEMENT Jean-Philippe wrote:
In that case it would mean that the Blueprint used in Karaf 3.0.2 was bugged… 
why not. But I don’t catch how the system determines that the service 
publishing/discovery has ended and then missing services are errors. I have the 
feeling that the starting phase ends too early for some reason.

Are there any Aries blueprint settings about parallelism or things like that?

JP

[@@ OPEN @@]




--

Christian Schneider

http://www.liquid-reality.de



Open Source Architect

http://www.talend.com

RE: Karaf 4.0.0 - Assembly failure = org.eclipse.osgi = freeze

2015-06-29 Thread CLEMENT Jean-Philippe

Sure, which file do you need?

PS: Is there a doc describing build-in features?

Regards,
JP

[@@ OPEN @@]


-Message d'origine-
De : Jean-Baptiste Onofré [mailto:j...@nanthrax.net] 
Envoyé : lundi 29 juin 2015 15:00
À : user@karaf.apache.org
Objet : Re: Karaf 4.0.0 - Assembly failure = org.eclipse.osgi = freeze

Hi JP,

I guess that your commands use the old style (bluprint + Karaf shell 
annotations).

Anyway, it should work straight forward (for instance, it's the case in Cellar 
as well).

So, I would compare your cfg files with the distribution ones (diff).

Regards
JB

On 06/29/2015 02:36 PM, CLEMENT Jean-Philippe wrote:
 Ok good ! I added “aries-blueprint” as boot feature and now things get 
 better as all bundles seem to start :)

 I say “seem to” as the command line appears to be very basic. I did 
 not find any command to list bundles! Also, all our custom commands 
 are not available.

 Should I add other features to list/start/stop bundles and to get my 
 custom commands to work?

 Regards,

 JP

 [@@ OPEN @@]

 *De :*Achim Nierbeck [mailto:bcanh...@googlemail.com] *Envoyé :* lundi 
 29 juin 2015 14:22 *À :* user@karaf.apache.org *Objet :* Re: Karaf 
 4.0.0 - Assembly failure = org.eclipse.osgi = freeze

 Hi,

 no that one does add some web dependencies.

 You would need to use aries-blueprint [1] as blueprint is to generic, 
 as one might as well use gemini-blueprint.

 regards, Achim

 [1] -
 https://github.com/apache/karaf/blob/master/assemblies/features/standa
 rd/src/main/feature/feature.xml#L43

 2015-06-29 14:17 GMT+02:00 CLEMENT Jean-Philippe 
 jean-philippe.clem...@fr.thalesgroup.com
 mailto:jean-philippe.clem...@fr.thalesgroup.com:

 I mean, in the assembly pom, should I add “blueprint-web” as boot 
 feature in order to get blueprint?

 Regards,

 JP

 [@@ OPEN @@]

 *De :*Achim Nierbeck [mailto:bcanh...@googlemail.com 
 mailto:bcanh...@googlemail.com] *Envoyé :* lundi 29 juin 2015 14:14


 *À :* user@karaf.apache.org mailto:user@karaf.apache.org *Objet :* 
 Re: Karaf 4.0.0 - Assembly failure = org.eclipse.osgi = freeze

 Hi,

 no, with Karaf 4, you'll now have also a blueprint feature while in 
 3.x it's been part of the framework feature.

 regards, Achim

 2015-06-29 14:11 GMT+02:00 CLEMENT Jean-Philippe 
 jean-philippe.clem...@fr.thalesgroup.com
 mailto:jean-philippe.clem...@fr.thalesgroup.com:

 Right, I did not add the blueprint feature. I tried blueprint 
 without success. In the 3.0.2 assembly I found a blueprint-web 
 feature. Is it this one?

 Regards,
 JP

 [@@ OPEN @@]


 -Message d'origine-
 De : Jean-Baptiste Onofré [mailto:j...@nanthrax.net 
 mailto:j...@nanthrax.net] Envoyé : lundi 29 juin 2015 14:06 À : 
 user@karaf.apache.org mailto:user@karaf.apache.org Objet : Re: Karaf 
 4.0.0 - Assembly failure = org.eclipse.osgi = freeze


 Do you have blueprint feature defined in featuresBoot in 
 etc/org.apache.karaf.features.cfg ?

 If you upgrade from a previous version, please do a diff in the etc 
 folder as the cfg files have changed.

 Regards
 JB

 On 06/29/2015 01:27 PM, CLEMENT Jean-Philippe wrote:
   The error message is not crystal clear. I’m not too sure what is   
 missing. Seems to be “kernel” but it was assembled as a boot feature.
  
   JP
  
   [@@ OPEN @@]
  
   *De :*CLEMENT Jean-Philippe
   [mailto:jean-philippe.clem...@fr.thalesgroup.com
 mailto:jean-philippe.clem...@fr.thalesgroup.com]
   *Envoyé :* lundi 29 juin 2015 10:51   *À :* user@karaf.apache.org 
 mailto:user@karaf.apache.org   *Objet :* RE: Karaf 4.0.0 - Assembly 
 failure = org.eclipse.osgi =   freeze Please find attached 
 the log after a clean install and freeze.
  
   JP
  
   [@@ OPEN @@]
  
   *De :*Achim Nierbeck [mailto:bcanh...@googlemail.com 
 mailto:bcanh...@googlemail.com] *Envoyé :* lundi   29 juin 2015 
 10:34 *À :* user@karaf.apache.org mailto:user@karaf.apache.org   
 mailto:user@karaf.apache.org mailto:user@karaf.apache.org *Objet
 :* Re: Karaf 4.0.0 - Assembly
   failure = org.eclipse.osgi = freeze Hi, could you 
 show us a bit more about the strange trace?
  
   The . instead of - is expected as OSGi versions aren't allowed 
 to   have a - in it. So the maven-bundle plugin converts this to a dot.
  
   regards, Achim
  
   2015-06-29 10:30 GMT+02:00 CLEMENT Jean-Philippe   
 jean-philippe.clem...@fr.thalesgroup.com
 mailto:jean-philippe.clem...@fr.thalesgroup.com
   mailto:jean-philippe.clem...@fr.thalesgroup.com
 mailto:jean-philippe.clem...@fr.thalesgroup.com:
  
   Now the config.properties is fixed, Karaf starts then freezes. The 
 log   contains a strange trace complaining about a missing artifact.
  
   The trace is strange because of the artifact version which is looked at:
   0.0.3.SNAPSHOT instead of 0.0.3-SNAPSHOT as defined.
  
   Another strange thing is I found a .SNAPSHOT in the generated   
 MANIFEST.MF of the branding (under target/classes/META-INF):
   0.0.1.SNPASHOT instead of 0.0.1-SNAPSHOT.
  
   Please help :)
  
   JP

RE: Karaf 4.0.0 - Assembly failure = org.eclipse.osgi = freeze

2015-06-29 Thread CLEMENT Jean-Philippe

The error message is not crystal clear. I’m not too sure what is missing. Seems
to be “kernel” but it was assembled as a boot feature.

[@@ OPEN @@]

De : CLEMENT Jean-Philippe [mailto:jean-philippe.clem...@fr.thalesgroup.com]
Envoyé : lundi 29 juin 2015 10:51
À : user@karaf.apache.org
Objet : RE: Karaf 4.0.0 - Assembly failure = org.eclipse.osgi = freeze

Please find attached the log after a clean install and freeze.

[@@ OPEN @@]

De : Achim Nierbeck [mailto:bcanh...@googlemail.com]
Envoyé : lundi 29 juin 2015 10:34
À : user@karaf.apache.orgmailto:user@karaf.apache.org
Objet : Re: Karaf 4.0.0 - Assembly failure = org.eclipse.osgi = freeze

Hi,

could you show us a bit more about the strange trace?

The . instead of - is expected as OSGi versions aren't allowed to have a
- in it. So the maven-bundle plugin converts this to a dot.

regards, Achim

2015-06-29 10:30 GMT+02:00 CLEMENT Jean-Philippe
jean-philippe.clem...@fr.thalesgroup.commailto:jean-philippe.clem...@fr.thalesgroup.com:
Now the config.properties is fixed, Karaf starts then freezes. The log contains
a strange trace complaining about a missing artifact.

The trace is strange because of the artifact version which is looked at:
0.0.3.SNAPSHOT instead of 0.0.3-SNAPSHOT as defined.

Another strange thing is I found a .SNAPSHOT in the generated MANIFEST.MF of
the branding (under target/classes/META-INF): 0.0.1.SNPASHOT instead of
0.0.1-SNAPSHOT.

Please help :)

[@@ OPEN @@]

-Message d'origine-
De : CLEMENT Jean-Philippe
[mailto:jean-philippe.clem...@fr.thalesgroup.commailto:jean-philippe.clem...@fr.thalesgroup.com]
Envoyé : lundi 29 juin 2015 10:16
À : user@karaf.apache.orgmailto:user@karaf.apache.org
Objet : RE: Karaf 4.0.0 - Assembly failure = org.eclipse.osgi

Haha!

I did override the config.properties in the assembly in order to enable Equinox
instead of Felix. This file mentions the equinox version!

Thank you :)

[@@ OPEN @@]

-Message d'origine-
De : Christian Schneider
[mailto:cschneider...@gmail.commailto:cschneider...@gmail.com] De la part de
Christian Schneider Envoyé : lundi 29 juin 2015 10:03 À :
user@karaf.apache.orgmailto:user@karaf.apache.org Objet : Re: Karaf 4.0.0 -
Assembly failure = org.eclipse.osgi

org.eclipse.osgi is the equinox framework. You should not install this as a
bundle. Instead switch karaf to use equinox instead of felix in the
config.properties.

Christian

On 29.06.2015 09:56, CLEMENT Jean-Philippe wrote:
Found a thread which seems to suggest to remove standard from boot
features. What I did. Assembly leads to success but during the runtime Karaf
quickly fails with the message:
Could not resolve
mvn:org.eclipse/org.eclipse.osgi/3.8.2.v20130124-134944

Two things seem wrong. I don't catch why it did not complain during the
assembly as the assembly should embed it. Second is that this artifact is in
our local repository.

Help is welcome :)

Regards,
JP

[@@ OPEN @@]

-Message d'origine-
De : CLEMENT Jean-Philippe
[mailto:jean-philippe.clem...@fr.thalesgroup.commailto:jean-philippe.clem...@fr.thalesgroup.com]
Envoyé : lundi 29 juin 2015 09:27
À : user@karaf.apache.orgmailto:user@karaf.apache.org
Objet : Karaf 4.0.0 - Assembly failure

Hi Jamie and all at Karaf,

Glad to head Karaf 4.0.0 has been released!

I just gave it a try but Maven fails during the assembly.

The assembly was ok with Karaf 3.0.2, I just changed 3.0.2 versions to 4.0.0.
The message is:
[ERROR] Failed to execute goal
org.apache.karaf.tooling:karaf-maven-plugin:4.0.0:assembly
(default-assembly) on project my-assembly: Unable to build assembly:
Could not find matching feature for standard - [Help 1]

Do you have a clue why?

Thank you,
JP

[@@ OPEN @@]

-Message d'origine-
De : Jamie G.
[mailto:jamie.goody...@gmail.commailto:jamie.goody...@gmail.com] Envoyé :
samedi 27 juin 2015 03:20 À :
user@karaf.apache.orgmailto:user@karaf.apache.org Objet : [ANN] Apache
Karaf 4.0.0 Released!

The Karaf team is pleased to announce the release of Apache Karaf version
4.0.0.

Apache Karaf is a small OSGi distribution which provides a ready to use
container for server side applications.

Apache Karaf 4.0.0 is the first production ready version of the new
4.0.0 branch.
It's a major step forward, including a complete new features resolver, a
large set of new features, improvements, and bug fixes.

http://karaf.apache.org/

This release is available from
http://karaf.apache.org/index/community/download.html#Karaf4.0.0 and

Maven:

dependency
groupIdorg.apache.karaf/groupId
artifactIdapache-karaf/artifactId
version4.0.0/version
/dependency

Download Note:
Our mirrors are still syncing the new kits, if your primary mirror does not
have the kit please try another from the server mirror list.

Apache Karaf manuals will appear soon to the website, updates are underway.

Release Notes:
http://karaf.apache.org/index

RE: Karaf 4.0.0 - Assembly failure = org.eclipse.osgi = freeze

2015-06-29 Thread CLEMENT Jean-Philippe

I mean, in the assembly pom, should I add “blueprint-web” as boot feature in 
order to get blueprint?

Regards,
JP

[@@ OPEN @@]

De : Achim Nierbeck [mailto:bcanh...@googlemail.com]
Envoyé : lundi 29 juin 2015 14:14
À : user@karaf.apache.org
Objet : Re: Karaf 4.0.0 - Assembly failure = org.eclipse.osgi = freeze

Hi,

no, with Karaf 4, you'll now have also a blueprint feature while in 3.x it's 
been part of the framework feature.

regards, Achim


2015-06-29 14:11 GMT+02:00 CLEMENT Jean-Philippe 
jean-philippe.clem...@fr.thalesgroup.commailto:jean-philippe.clem...@fr.thalesgroup.com:
Right, I did not add the blueprint feature. I tried blueprint without 
success. In the 3.0.2 assembly I found a blueprint-web feature. Is it this 
one?

Regards,
JP

[@@ OPEN @@]


-Message d'origine-
De : Jean-Baptiste Onofré [mailto:j...@nanthrax.netmailto:j...@nanthrax.net]
Envoyé : lundi 29 juin 2015 14:06
À : user@karaf.apache.orgmailto:user@karaf.apache.org
Objet : Re: Karaf 4.0.0 - Assembly failure = org.eclipse.osgi = freeze

Do you have blueprint feature defined in featuresBoot in 
etc/org.apache.karaf.features.cfg ?

If you upgrade from a previous version, please do a diff in the etc folder as 
the cfg files have changed.

Regards
JB

On 06/29/2015 01:27 PM, CLEMENT Jean-Philippe wrote:
 The error message is not crystal clear. I’m not too sure what is
 missing. Seems to be “kernel” but it was assembled as a boot feature.

 JP

 [@@ OPEN @@]

 *De :*CLEMENT Jean-Philippe
 [mailto:jean-philippe.clem...@fr.thalesgroup.commailto:jean-philippe.clem...@fr.thalesgroup.com]
 *Envoyé :* lundi 29 juin 2015 10:51
 *À :* user@karaf.apache.orgmailto:user@karaf.apache.org
 *Objet :* RE: Karaf 4.0.0 - Assembly failure = org.eclipse.osgi =
 freeze

 Please find attached the log after a clean install and freeze.

 JP

 [@@ OPEN @@]

 *De :*Achim Nierbeck 
 [mailto:bcanh...@googlemail.commailto:bcanh...@googlemail.com] *Envoyé :* 
 lundi
 29 juin 2015 10:34 *À :* user@karaf.apache.orgmailto:user@karaf.apache.org
 mailto:user@karaf.apache.orgmailto:user@karaf.apache.org *Objet :* Re: 
 Karaf 4.0.0 - Assembly
 failure = org.eclipse.osgi = freeze

 Hi,

 could you show us a bit more about the strange trace?

 The . instead of - is expected as OSGi versions aren't allowed to
 have a - in it. So the maven-bundle plugin converts this to a dot.

 regards, Achim

 2015-06-29 10:30 GMT+02:00 CLEMENT Jean-Philippe
 jean-philippe.clem...@fr.thalesgroup.commailto:jean-philippe.clem...@fr.thalesgroup.com
 mailto:jean-philippe.clem...@fr.thalesgroup.commailto:jean-philippe.clem...@fr.thalesgroup.com:

 Now the config.properties is fixed, Karaf starts then freezes. The log
 contains a strange trace complaining about a missing artifact.

 The trace is strange because of the artifact version which is looked at:
 0.0.3.SNAPSHOT instead of 0.0.3-SNAPSHOT as defined.

 Another strange thing is I found a .SNAPSHOT in the generated
 MANIFEST.MF of the branding (under target/classes/META-INF):
 0.0.1.SNPASHOT instead of 0.0.1-SNAPSHOT.

 Please help :)

 JP

 [@@ OPEN @@]


 -Message d'origine-
 De : CLEMENT Jean-Philippe
 [mailto:jean-philippe.clem...@fr.thalesgroup.commailto:jean-philippe.clem...@fr.thalesgroup.com
 mailto:jean-philippe.clem...@fr.thalesgroup.commailto:jean-philippe.clem...@fr.thalesgroup.com]
 Envoyé : lundi 29 juin 2015 10:16
 À : user@karaf.apache.orgmailto:user@karaf.apache.org 
 mailto:user@karaf.apache.orgmailto:user@karaf.apache.org Objet : RE:
 Karaf 4.0.0 - Assembly failure = org.eclipse.osgi

 Haha!

 I did override the config.properties in the assembly in order to
 enable Equinox instead of Felix. This file mentions the equinox version!

 Thank you :)

 JP

 [@@ OPEN @@]


 -Message d'origine-
 De : Christian Schneider 
 [mailto:cschneider...@gmail.commailto:cschneider...@gmail.com
 mailto:cschneider...@gmail.commailto:cschneider...@gmail.com] De la part 
 de Christian Schneider
 Envoyé : lundi 29 juin 2015 10:03 À : 
 user@karaf.apache.orgmailto:user@karaf.apache.org
 mailto:user@karaf.apache.orgmailto:user@karaf.apache.org Objet : Re: 
 Karaf 4.0.0 - Assembly
 failure = org.eclipse.osgi

 org.eclipse.osgi is the equinox framework. You should not install this
 as a bundle. Instead switch karaf to use equinox instead of felix in
 the config.properties.

 Christian

 On 29.06.2015 09:56, CLEMENT Jean-Philippe wrote:
   Found a thread which seems to suggest to remove standard from
 boot features. What I did. Assembly leads to success but during the
 runtime Karaf quickly fails with the message:
   Could not resolve
   mvn:org.eclipse/org.eclipse.osgi/3.8.2.v20130124-134944
  
   Two things seem wrong. I don't catch why it did not complain during
 the assembly as the assembly should embed it. Second is that this
 artifact is in our local repository.
  
   Help is welcome :)
  
   Regards,
   JP
  
   [@@ OPEN @@]
  
  
   -Message d'origine-
   De : CLEMENT Jean-Philippe
   
 [mailto:jean

RE: Karaf 4.0.0 - Assembly failure = org.eclipse.osgi = freeze

2015-06-29 Thread CLEMENT Jean-Philippe

Right, I did not add the blueprint feature. I tried blueprint without 
success. In the 3.0.2 assembly I found a blueprint-web feature. Is it this 
one?

Regards,
JP

[@@ OPEN @@]


-Message d'origine-
De : Jean-Baptiste Onofré [mailto:j...@nanthrax.net] 
Envoyé : lundi 29 juin 2015 14:06
À : user@karaf.apache.org
Objet : Re: Karaf 4.0.0 - Assembly failure = org.eclipse.osgi = freeze

Do you have blueprint feature defined in featuresBoot in 
etc/org.apache.karaf.features.cfg ?

If you upgrade from a previous version, please do a diff in the etc folder as 
the cfg files have changed.

Regards
JB

On 06/29/2015 01:27 PM, CLEMENT Jean-Philippe wrote:
 The error message is not crystal clear. I’m not too sure what is 
 missing. Seems to be “kernel” but it was assembled as a boot feature.

 JP

 [@@ OPEN @@]

 *De :*CLEMENT Jean-Philippe
 [mailto:jean-philippe.clem...@fr.thalesgroup.com]
 *Envoyé :* lundi 29 juin 2015 10:51
 *À :* user@karaf.apache.org
 *Objet :* RE: Karaf 4.0.0 - Assembly failure = org.eclipse.osgi = 
 freeze

 Please find attached the log after a clean install and freeze.

 JP

 [@@ OPEN @@]

 *De :*Achim Nierbeck [mailto:bcanh...@googlemail.com] *Envoyé :* lundi 
 29 juin 2015 10:34 *À :* user@karaf.apache.org 
 mailto:user@karaf.apache.org *Objet :* Re: Karaf 4.0.0 - Assembly 
 failure = org.eclipse.osgi = freeze

 Hi,

 could you show us a bit more about the strange trace?

 The . instead of - is expected as OSGi versions aren't allowed to 
 have a - in it. So the maven-bundle plugin converts this to a dot.

 regards, Achim

 2015-06-29 10:30 GMT+02:00 CLEMENT Jean-Philippe 
 jean-philippe.clem...@fr.thalesgroup.com
 mailto:jean-philippe.clem...@fr.thalesgroup.com:

 Now the config.properties is fixed, Karaf starts then freezes. The log 
 contains a strange trace complaining about a missing artifact.

 The trace is strange because of the artifact version which is looked at:
 0.0.3.SNAPSHOT instead of 0.0.3-SNAPSHOT as defined.

 Another strange thing is I found a .SNAPSHOT in the generated 
 MANIFEST.MF of the branding (under target/classes/META-INF):
 0.0.1.SNPASHOT instead of 0.0.1-SNAPSHOT.

 Please help :)

 JP

 [@@ OPEN @@]


 -Message d'origine-
 De : CLEMENT Jean-Philippe
 [mailto:jean-philippe.clem...@fr.thalesgroup.com
 mailto:jean-philippe.clem...@fr.thalesgroup.com]
 Envoyé : lundi 29 juin 2015 10:16
 À : user@karaf.apache.org mailto:user@karaf.apache.org Objet : RE: 
 Karaf 4.0.0 - Assembly failure = org.eclipse.osgi

 Haha!

 I did override the config.properties in the assembly in order to 
 enable Equinox instead of Felix. This file mentions the equinox version!

 Thank you :)

 JP

 [@@ OPEN @@]


 -Message d'origine-
 De : Christian Schneider [mailto:cschneider...@gmail.com 
 mailto:cschneider...@gmail.com] De la part de Christian Schneider 
 Envoyé : lundi 29 juin 2015 10:03 À : user@karaf.apache.org 
 mailto:user@karaf.apache.org Objet : Re: Karaf 4.0.0 - Assembly 
 failure = org.eclipse.osgi

 org.eclipse.osgi is the equinox framework. You should not install this 
 as a bundle. Instead switch karaf to use equinox instead of felix in 
 the config.properties.

 Christian

 On 29.06.2015 09:56, CLEMENT Jean-Philippe wrote:
   Found a thread which seems to suggest to remove standard from 
 boot features. What I did. Assembly leads to success but during the 
 runtime Karaf quickly fails with the message:
   Could not resolve
   mvn:org.eclipse/org.eclipse.osgi/3.8.2.v20130124-134944
  
   Two things seem wrong. I don't catch why it did not complain during 
 the assembly as the assembly should embed it. Second is that this 
 artifact is in our local repository.
  
   Help is welcome :)
  
   Regards,
   JP
  
   [@@ OPEN @@]
  
  
   -Message d'origine-
   De : CLEMENT Jean-Philippe
   [mailto:jean-philippe.clem...@fr.thalesgroup.com
 mailto:jean-philippe.clem...@fr.thalesgroup.com]
   Envoyé : lundi 29 juin 2015 09:27
   À : user@karaf.apache.org mailto:user@karaf.apache.org   Objet : 
 Karaf 4.0.0 - Assembly failure Hi Jamie and all at Karaf, 
 Glad to head Karaf 4.0.0 has been released!
  
   I just gave it a try but Maven fails during the assembly.
  
   The assembly was ok with Karaf 3.0.2, I just changed 3.0.2 versions 
 to 4.0.0. The message is:
   [ERROR] Failed to execute goal
   org.apache.karaf.tooling:karaf-maven-plugin:4.0.0:assembly
   (default-assembly) on project my-assembly: Unable to build assembly:
   Could not find matching feature for standard - [Help 1] Do 
 you have a clue why?
  
   Thank you,
   JP
  
   [@@ OPEN @@]
  
  
   -Message d'origine-
   De : Jamie G. [mailto:jamie.goody...@gmail.com 
 mailto:jamie.goody...@gmail.com] Envoyé : samedi 27 juin 2015 03:20 
 À
 : user@karaf.apache.org mailto:user@karaf.apache.org Objet : [ANN] 
 Apache Karaf 4.0.0 Released!
  
   The Karaf team is pleased to announce the release of Apache Karaf 
 version 4.0.0.
  
   Apache Karaf is a small OSGi distribution

RE: build warnings: [WARNING] interval1: null, interval2: daily

2015-06-29 Thread CLEMENT Jean-Philippe

Hi JB,

I can see this traces during the build with mvn:
[INFO] Loading kar and features repositories dependencies
INFO: Unzipping kars
Jun 29, 2015 9:02:09 AM org.ops4j.pax.url.mvn.internal.AetherBasedResolver 
minUpdateInterval
WARNING: interval1: null, interval2: daily

The interval warning is displayed several times. I just updated from Karaf 
3.0.2 to 4.0.0 and my build fails at present time due to Could not find 
matching feature for standard. Don't know if it's related or not.

JP

[@@ OPEN @@]


-Message d'origine-
De : Jean-Baptiste Onofré [mailto:j...@nanthrax.net] 
Envoyé : lundi 29 juin 2015 07:21
À : user@karaf.apache.org
Objet : Re: build warnings: [WARNING] interval1: null, interval2: daily

Hi Rodrigo,

when do you see this message (in order to reproduce it) ?

Thanks,
Regards
JB

On 06/29/2015 12:26 AM, Rodrigo Serra wrote:
 Hello,

 I 'm doing some tests with karaf 4 and I found many of the following messages 
 in the log:

 WARN  | pool-30-thread-1 | AetherBasedResolver  | 1 - 
 org.ops4j.pax.logging.pax-logging-api - 1.8.3 | interval1: null, interval2: 
 daily

 What do they mean?

 Regards,
 Rodrigo


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

RE: Karaf 4.0.0 - Assembly failure = org.eclipse.osgi

2015-06-29 Thread CLEMENT Jean-Philippe

Haha!

I did override the config.properties in the assembly in order to enable Equinox 
instead of Felix. This file mentions the equinox version!

Thank you :)

JP

[@@ OPEN @@]


-Message d'origine-
De : Christian Schneider [mailto:cschneider...@gmail.com] De la part de 
Christian Schneider
Envoyé : lundi 29 juin 2015 10:03
À : user@karaf.apache.org
Objet : Re: Karaf 4.0.0 - Assembly failure = org.eclipse.osgi

org.eclipse.osgi is the equinox framework. You should not install this as a 
bundle. Instead switch karaf to use equinox instead of felix in the 
config.properties.

Christian

On 29.06.2015 09:56, CLEMENT Jean-Philippe wrote:
 Found a thread which seems to suggest to remove standard from boot 
 features. What I did. Assembly leads to success but during the runtime Karaf 
 quickly fails with the message:
 Could not resolve 
 mvn:org.eclipse/org.eclipse.osgi/3.8.2.v20130124-134944

 Two things seem wrong. I don't catch why it did not complain during the 
 assembly as the assembly should embed it. Second is that this artifact is in 
 our local repository.

 Help is welcome :)

 Regards,
 JP

 [@@ OPEN @@]


 -Message d'origine-
 De : CLEMENT Jean-Philippe 
 [mailto:jean-philippe.clem...@fr.thalesgroup.com]
 Envoyé : lundi 29 juin 2015 09:27
 À : user@karaf.apache.org
 Objet : Karaf 4.0.0 - Assembly failure

 Hi Jamie and all at Karaf,

 Glad to head Karaf 4.0.0 has been released!

 I just gave it a try but Maven fails during the assembly.

 The assembly was ok with Karaf 3.0.2, I just changed 3.0.2 versions to 4.0.0. 
 The message is:
 [ERROR] Failed to execute goal 
 org.apache.karaf.tooling:karaf-maven-plugin:4.0.0:assembly 
 (default-assembly) on project my-assembly: Unable to build assembly: 
 Could not find matching feature for standard - [Help 1]

 Do you have a clue why?

 Thank you,
 JP

 [@@ OPEN @@]


 -Message d'origine-
 De : Jamie G. [mailto:jamie.goody...@gmail.com] Envoyé : samedi 27 juin 2015 
 03:20 À : user@karaf.apache.org Objet : [ANN] Apache Karaf 4.0.0 Released!

 The Karaf team is pleased to announce the release of Apache Karaf version 
 4.0.0.

 Apache Karaf is a small OSGi distribution which provides a ready to use 
 container for server side applications.

 Apache Karaf 4.0.0 is the first production ready version of the new
 4.0.0 branch.
 It's a major step forward, including a complete new features resolver, a 
 large set of new features, improvements, and bug fixes.

 http://karaf.apache.org/

 This release is available from
 http://karaf.apache.org/index/community/download.html#Karaf4.0.0 and

 Maven:

   dependency
   groupIdorg.apache.karaf/groupId
   artifactIdapache-karaf/artifactId
   version4.0.0/version
   /dependency

 Download Note:
 Our mirrors are still syncing the new kits, if your primary mirror does not 
 have the kit please try another from the server mirror list.

 Apache Karaf manuals will appear soon to the website, updates are underway.

 Release Notes:
 http://karaf.apache.org/index/community/download/karaf-4.0.0-release.h
 tml

 Enjoy!


--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

RE: Karaf 4.0.0 - Assembly failure = org.eclipse.osgi = freeze

2015-06-29 Thread CLEMENT Jean-Philippe

Now the config.properties is fixed, Karaf starts then freezes. The log contains 
a strange trace complaining about a missing artifact.

The trace is strange because of the artifact version which is looked at: 
0.0.3.SNAPSHOT instead of 0.0.3-SNAPSHOT as defined.

Another strange thing is I found a .SNAPSHOT in the generated MANIFEST.MF of 
the branding (under target/classes/META-INF): 0.0.1.SNPASHOT instead of 
0.0.1-SNAPSHOT.

Please help :)

JP

[@@ OPEN @@]


-Message d'origine-
De : CLEMENT Jean-Philippe [mailto:jean-philippe.clem...@fr.thalesgroup.com] 
Envoyé : lundi 29 juin 2015 10:16
À : user@karaf.apache.org
Objet : RE: Karaf 4.0.0 - Assembly failure = org.eclipse.osgi

Haha!

I did override the config.properties in the assembly in order to enable Equinox 
instead of Felix. This file mentions the equinox version!

Thank you :)

JP

[@@ OPEN @@]


-Message d'origine-
De : Christian Schneider [mailto:cschneider...@gmail.com] De la part de 
Christian Schneider Envoyé : lundi 29 juin 2015 10:03 À : user@karaf.apache.org 
Objet : Re: Karaf 4.0.0 - Assembly failure = org.eclipse.osgi

org.eclipse.osgi is the equinox framework. You should not install this as a 
bundle. Instead switch karaf to use equinox instead of felix in the 
config.properties.

Christian

On 29.06.2015 09:56, CLEMENT Jean-Philippe wrote:
 Found a thread which seems to suggest to remove standard from boot 
 features. What I did. Assembly leads to success but during the runtime Karaf 
 quickly fails with the message:
 Could not resolve
 mvn:org.eclipse/org.eclipse.osgi/3.8.2.v20130124-134944

 Two things seem wrong. I don't catch why it did not complain during the 
 assembly as the assembly should embed it. Second is that this artifact is in 
 our local repository.

 Help is welcome :)

 Regards,
 JP

 [@@ OPEN @@]


 -Message d'origine-
 De : CLEMENT Jean-Philippe
 [mailto:jean-philippe.clem...@fr.thalesgroup.com]
 Envoyé : lundi 29 juin 2015 09:27
 À : user@karaf.apache.org
 Objet : Karaf 4.0.0 - Assembly failure

 Hi Jamie and all at Karaf,

 Glad to head Karaf 4.0.0 has been released!

 I just gave it a try but Maven fails during the assembly.

 The assembly was ok with Karaf 3.0.2, I just changed 3.0.2 versions to 4.0.0. 
 The message is:
 [ERROR] Failed to execute goal
 org.apache.karaf.tooling:karaf-maven-plugin:4.0.0:assembly
 (default-assembly) on project my-assembly: Unable to build assembly: 
 Could not find matching feature for standard - [Help 1]

 Do you have a clue why?

 Thank you,
 JP

 [@@ OPEN @@]


 -Message d'origine-
 De : Jamie G. [mailto:jamie.goody...@gmail.com] Envoyé : samedi 27 juin 2015 
 03:20 À : user@karaf.apache.org Objet : [ANN] Apache Karaf 4.0.0 Released!

 The Karaf team is pleased to announce the release of Apache Karaf version 
 4.0.0.

 Apache Karaf is a small OSGi distribution which provides a ready to use 
 container for server side applications.

 Apache Karaf 4.0.0 is the first production ready version of the new
 4.0.0 branch.
 It's a major step forward, including a complete new features resolver, a 
 large set of new features, improvements, and bug fixes.

 http://karaf.apache.org/

 This release is available from
 http://karaf.apache.org/index/community/download.html#Karaf4.0.0 and

 Maven:

   dependency
   groupIdorg.apache.karaf/groupId
   artifactIdapache-karaf/artifactId
   version4.0.0/version
   /dependency

 Download Note:
 Our mirrors are still syncing the new kits, if your primary mirror does not 
 have the kit please try another from the server mirror list.

 Apache Karaf manuals will appear soon to the website, updates are underway.

 Release Notes:
 http://karaf.apache.org/index/community/download/karaf-4.0.0-release.h
 tml

 Enjoy!


--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

RE: Karaf 4.0.0 - Assembly failure = org.eclipse.osgi

2015-06-29 Thread CLEMENT Jean-Philippe

Found a thread which seems to suggest to remove standard from boot features. 
What I did. Assembly leads to success but during the runtime Karaf quickly 
fails with the message:
Could not resolve mvn:org.eclipse/org.eclipse.osgi/3.8.2.v20130124-134944

Two things seem wrong. I don't catch why it did not complain during the 
assembly as the assembly should embed it. Second is that this artifact is in 
our local repository.

Help is welcome :)

Regards,
JP

[@@ OPEN @@]


-Message d'origine-
De : CLEMENT Jean-Philippe [mailto:jean-philippe.clem...@fr.thalesgroup.com] 
Envoyé : lundi 29 juin 2015 09:27
À : user@karaf.apache.org
Objet : Karaf 4.0.0 - Assembly failure

Hi Jamie and all at Karaf,

Glad to head Karaf 4.0.0 has been released!

I just gave it a try but Maven fails during the assembly.

The assembly was ok with Karaf 3.0.2, I just changed 3.0.2 versions to 4.0.0. 
The message is:
[ERROR] Failed to execute goal 
org.apache.karaf.tooling:karaf-maven-plugin:4.0.0:assembly (default-assembly) 
on project my-assembly: Unable to build assembly: Could not find matching 
feature for standard - [Help 1]

Do you have a clue why?

Thank you,
JP

[@@ OPEN @@]


-Message d'origine-
De : Jamie G. [mailto:jamie.goody...@gmail.com] Envoyé : samedi 27 juin 2015 
03:20 À : user@karaf.apache.org Objet : [ANN] Apache Karaf 4.0.0 Released!

The Karaf team is pleased to announce the release of Apache Karaf version 4.0.0.

Apache Karaf is a small OSGi distribution which provides a ready to use 
container for server side applications.

Apache Karaf 4.0.0 is the first production ready version of the new
4.0.0 branch.
It's a major step forward, including a complete new features resolver, a large 
set of new features, improvements, and bug fixes.

http://karaf.apache.org/

This release is available from
http://karaf.apache.org/index/community/download.html#Karaf4.0.0 and

Maven:

 dependency
 groupIdorg.apache.karaf/groupId
 artifactIdapache-karaf/artifactId
 version4.0.0/version
 /dependency

Download Note:
Our mirrors are still syncing the new kits, if your primary mirror does not 
have the kit please try another from the server mirror list.

Apache Karaf manuals will appear soon to the website, updates are underway.

Release Notes:
http://karaf.apache.org/index/community/download/karaf-4.0.0-release.html

Enjoy!

RE: Best way to access OSGi services from classes which object creation I cannot handle

2015-06-22 Thread CLEMENT Jean-Philippe

myJPAStuff can be a bean that you expose as an OSGi service. Then you can 
easily retrieve it from your dynamically loaded JPA listener.

JP

[@@ THALES GROUP INTERNAL @@]


-Message d'origine-
De : ellirael [mailto:ellir...@mail.ru] 
Envoyé : lundi 22 juin 2015 10:19
À : user@karaf.apache.org
Objet : RE: Best way to access OSGi services from classes which object creation 
I cannot handle

Jean-Philippe, you're reffering JPAStuff. What is it?
My JPA listener created by JPA engine, not by blueprint.

Is is possible to intercept myJPAStuff creation via blueprint?



--
View this message in context: 
http://karaf.922171.n3.nabble.com/Best-way-to-access-OSGi-services-from-classes-which-object-creation-I-cannot-handle-tp4040986p4041026.html
Sent from the Karaf - User mailing list archive at Nabble.com.

RE: Best way to access OSGi services from classes which object creation I cannot handle

2015-06-22 Thread CLEMENT Jean-Philippe

So Blueprint reference-list may be relevant:
 reference-list interface=MyCallbackContract availability=optional
  reference-listener ref=myJPAStuff bind-method=addCallback 
unbind-method=removeCallback /
 /reference-list

Where removeCallback method may be called with a null parameter at startup 
which means no service was found at that time.

JP

[@@ OPEN @@]

-Message d'origine-
De : ellirael [mailto:ellir...@mail.ru] 
Envoyé : vendredi 19 juin 2015 13:42
À : user@karaf.apache.org
Objet : RE: Best way to access OSGi services from classes which object creation 
I cannot handle

Jean-Philippe, dynamic change of services impl have many ways to use.
For example I can dynamically register calback methods, hot-update app version 
without needs of app stopping, implementing point of extension template.

In different cases there will be different requirements how to handle services 
change, removing and creating.

For now my task is to call special services if it exists. If it not exists then 
ignore. If it changes it must be no need of some sort of app stop. It must just 
to start call new services impl.




--
View this message in context: 
http://karaf.922171.n3.nabble.com/Best-way-to-access-OSGi-services-from-classes-which-object-creation-I-cannot-handle-tp4040986p4040995.html
Sent from the Karaf - User mailing list archive at Nabble.com.

RE: Best way to access OSGi services from classes which object creation I cannot handle

2015-06-19 Thread CLEMENT Jean-Philippe

OSGi fits your requirements, but I would say, do you really mean your service
implementation will change dynamically? And, if you get no service
implementation, what does it mean? Same question but if you get several
implementations... will you call all implementations... the best one? ...and
when that or those service(s) would be stopped/removed???

Some thoughts:
= If your JPA stuff really needs a service, then maybe you should only
instantiate it when that service is found
= If you want the best service implementation so you will have to handle that
case yourself (not basic OSGi afaik)
= I really appreciate Blueprint and use it as much as possible (i.e. when
relevant), maybe you can take a look to this spec

[@@ THALES GROUP INTERNAL @@]

-Message d'origine-
De : ellirael [mailto:ellir...@mail.ru]
Envoyé : jeudi 18 juin 2015 17:41
À : user@karaf.apache.org
Objet : Best way to access OSGi services from classes which object creation I
cannot handle

I'm looking for best solution to gain access to OSGi services in classes which
object creation I cannot handle.
For example I need to call some OSGi services in JPA event listener
@PostPersist callback method.
How to inject services to such objects?
How to refresh services links when their implementation change?
How to ensure that all resources are freed when I update or restart bundle with
services?
To save dynamism is a must for my tasks.

--
View this message in context:
http://karaf.922171.n3.nabble.com/Best-way-to-access-OSGi-services-from-classes-which-object-creation-I-cannot-handle-tp4040986.html
Sent from the Karaf - User mailing list archive at Nabble.com.

RE: Karaf installation to a read-only directory

2015-06-16 Thread CLEMENT Jean-Philippe

Great, thank you for your support :)

JP

[@@ OPEN @@]


-Message d'origine-
De : Jean-Baptiste Onofré [mailto:j...@nanthrax.net] 
Envoyé : mardi 16 juin 2015 13:52
À : user@karaf.apache.org
Objet : Re: Karaf installation to a read-only directory

By the way, I created the Jira and I gonna fix that (for instances): it will be 
included in next release cycle.

Regards
JB

On 06/16/2015 01:47 PM, CLEMENT Jean-Philippe wrote:
 Ok. So the most simple solution seems to set KARAF_BASE to a r/w directory 
 and to copy the /etc directory (before making it read-only) inside.

 With that scenario, Karaf only complains about the instances directory 
 which cannot be created BUT everything seems to work as expected.

 Does the instances failure can make any trouble?

 JP

 [@@ OPEN @@]


 -Message d'origine-
 De : Jean-Baptiste Onofré [mailto:j...@nanthrax.net] Envoyé : mardi 16 
 juin 2015 13:42 À : user@karaf.apache.org Objet : Re: Karaf 
 installation to a read-only directory

 It's in the way (I created the JIRA for instances location).

 It's already possible for lock.

 Regards
 JB

 On 06/16/2015 01:18 PM, maggu2810 wrote:
 I am using karaf in a read only installation.
 - data
 - instances
 - lock
 This directories / file are created.

 It would be nice, if ALL runtime data could be written elsewhere (not 
 only data, also instances and lock).



 --
 View this message in context:
 http://karaf.922171.n3.nabble.com/Karaf-installation-to-a-read-only-d
 i rectory-tp4040942p4040948.html Sent from the Karaf - User mailing 
 list archive at Nabble.com.


 --
 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

Karaf installation to a read-only directory

2015-06-16 Thread CLEMENT Jean-Philippe

Dear Karaf Team,

We would like to install Karaf in a directory which is read-only. By read-only 
I mean that no directory or file cannot be written at runtime inside the 
installation directory, so they must be located somewhere else.

What is the most simple way to achieve this?

Regards,
JP

PS: At present time we are using Karaf 3.0.2

[@@ OPEN @@]

RE: Karaf installation to a read-only directory

2015-06-16 Thread CLEMENT Jean-Philippe

I found there is a instances directory and a lock file which are created at 
runtime. On which base directory/env. variable are they created?

Regards,
JP

[@@ OPEN @@]


-Message d'origine-
De : Jean-Baptiste Onofré [mailto:j...@nanthrax.net] 
Envoyé : mardi 16 juin 2015 12:53
À : user@karaf.apache.org
Objet : Re: Karaf installation to a read-only directory

Hi JP,

1/ KARAF_DATA has to be writable
2/ etc/system.properties has to be writable as it's where the shutdown 
command is added at first startup (it's not fixed in the meaning that it 
doesn't prevent the bootstrap) 3/ if you want to support update of config file 
(when using ConfigMBean or config:* commands), KARAF_ETC has to be writable

So, just provide KARAF_DATA variable in bin/karaf to a directory where you can 
write and it will work (eventually KARAF_ETC too).

Regards
JB

On 06/16/2015 12:05 PM, CLEMENT Jean-Philippe wrote:
 Dear Karaf Team,

 We would like to install Karaf in a directory which is read-only. By 
 read-only I mean that no directory or file cannot be written at runtime 
 inside the installation directory, so they must be located somewhere else.

 What is the most simple way to achieve this?

 Regards,
 JP

 PS: At present time we are using Karaf 3.0.2

 [@@ OPEN @@]


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

RE: Karaf installation to a read-only directory

2015-06-16 Thread CLEMENT Jean-Philippe

Ok. So the most simple solution seems to set KARAF_BASE to a r/w directory and 
to copy the /etc directory (before making it read-only) inside.

With that scenario, Karaf only complains about the instances directory which 
cannot be created BUT everything seems to work as expected.

Does the instances failure can make any trouble?

JP

[@@ OPEN @@]


-Message d'origine-
De : Jean-Baptiste Onofré [mailto:j...@nanthrax.net] 
Envoyé : mardi 16 juin 2015 13:42
À : user@karaf.apache.org
Objet : Re: Karaf installation to a read-only directory

It's in the way (I created the JIRA for instances location).

It's already possible for lock.

Regards
JB

On 06/16/2015 01:18 PM, maggu2810 wrote:
 I am using karaf in a read only installation.
 - data
 - instances
 - lock
 This directories / file are created.

 It would be nice, if ALL runtime data could be written elsewhere (not 
 only data, also instances and lock).



 --
 View this message in context: 
 http://karaf.922171.n3.nabble.com/Karaf-installation-to-a-read-only-di
 rectory-tp4040942p4040948.html Sent from the Karaf - User mailing list 
 archive at Nabble.com.


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

RE: Remote shell connection

2015-04-15 Thread CLEMENT Jean-Philippe

...and the question :P

However I did try installing this bundle with the same result... the port is 
not opened. I guess the whole feature is needed.

What is the feature group+artifact IDs, version and type so I may add it to POM 
assembly dependencies?

JP

[@@ OPEN @@]


-Message d'origine-
De : Morgan Hautman [mailto:morgan.haut...@gmail.com] 
Envoyé : mercredi 15 avril 2015 14:49
À : user@karaf.apache.org
Objet : Re: Remote shell connection

JP ,

You really should read some doc first ;)

install mvn:org.apache.sshd/sshd-core/0.14.0


On 15/04/2015 14:47, CLEMENT Jean-Philippe wrote:
 :D

 ... I mean which group+artifact IDs, version and type?

 Regards,
 JP

 [@@ OPEN @@]


 -Message d'origine-
 De : Jean-Baptiste Onofré [mailto:j...@nanthrax.net] Envoyé : mercredi 
 15 avril 2015 14:43 À : user@karaf.apache.org Objet : Re: Remote shell 
 connection

 The ssh feature ;)

 Regards
 JB

 On 04/15/2015 02:38 PM, CLEMENT Jean-Philippe wrote:
 Hi JB,

 The SSH feature does not seem to be installed.

 We are assembling Karaf; which dependency should we add?

 Regards,
 JP

 [@@ OPEN @@]


 -Message d'origine-
 De : Jean-Baptiste Onofré [mailto:j...@nanthrax.net] Envoyé : mercredi
 15 avril 2015 14:18 À : user@karaf.apache.org Objet : Re: Remote 
 shell connection

 Hi JP,

 Is the ssh feature installed ?
 If so, then 8101 is bound by default (as setup in 
 etc/org.apache.karaf.shell.cfg).

 I just tried with Karaf 3.0.3 and it works fine.

 Which version are you using ?
 The 8101 port number is not already bound by another process ?

 Regards
 JB

 On 04/15/2015 02:11 PM, CLEMENT Jean-Philippe wrote:
 Dear Karaf,

 I would like to open a shell to a remote Karaf instance. The 8101 port does 
 not seem to be opened.

 How to configure Karaf in order to allow connections?

 Kind regards,
 JP

 [@@ OPEN @@]

 --
 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

Remote shell connection

2015-04-15 Thread CLEMENT Jean-Philippe

Dear Karaf,

I would like to open a shell to a remote Karaf instance. The 8101 port does not 
seem to be opened.

How to configure Karaf in order to allow connections?

Kind regards,
JP

[@@ OPEN @@]

RE: Remote shell connection

2015-04-15 Thread CLEMENT Jean-Philippe

:D

... I mean which group+artifact IDs, version and type?

Regards,
JP

[@@ OPEN @@]


-Message d'origine-
De : Jean-Baptiste Onofré [mailto:j...@nanthrax.net] 
Envoyé : mercredi 15 avril 2015 14:43
À : user@karaf.apache.org
Objet : Re: Remote shell connection

The ssh feature ;)

Regards
JB

On 04/15/2015 02:38 PM, CLEMENT Jean-Philippe wrote:
 Hi JB,

 The SSH feature does not seem to be installed.

 We are assembling Karaf; which dependency should we add?

 Regards,
 JP

 [@@ OPEN @@]


 -Message d'origine-
 De : Jean-Baptiste Onofré [mailto:j...@nanthrax.net] Envoyé : mercredi 
 15 avril 2015 14:18 À : user@karaf.apache.org Objet : Re: Remote shell 
 connection

 Hi JP,

 Is the ssh feature installed ?
 If so, then 8101 is bound by default (as setup in 
 etc/org.apache.karaf.shell.cfg).

 I just tried with Karaf 3.0.3 and it works fine.

 Which version are you using ?
 The 8101 port number is not already bound by another process ?

 Regards
 JB

 On 04/15/2015 02:11 PM, CLEMENT Jean-Philippe wrote:
 Dear Karaf,

 I would like to open a shell to a remote Karaf instance. The 8101 port does 
 not seem to be opened.

 How to configure Karaf in order to allow connections?

 Kind regards,
 JP

 [@@ OPEN @@]


 --
 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

RE: Remote shell connection

2015-04-15 Thread CLEMENT Jean-Philippe

Ok great,

And what to configure in order to install it during the assembly?

Regards,
JP

[@@ OPEN @@]


-Message d'origine-
De : Jean-Baptiste Onofré [mailto:j...@nanthrax.net] 
Envoyé : mercredi 15 avril 2015 15:22
À : user@karaf.apache.org
Objet : Re: Remote shell connection

The ssh feature is provided in the Karaf standard (corresponding to the Karaf 
version that you use).

So, simply feature:install ssh should work.

Regards
JB

On 04/15/2015 02:47 PM, CLEMENT Jean-Philippe wrote:
 :D

 ... I mean which group+artifact IDs, version and type?

 Regards,
 JP

 [@@ OPEN @@]


 -Message d'origine-
 De : Jean-Baptiste Onofré [mailto:j...@nanthrax.net] Envoyé : mercredi 
 15 avril 2015 14:43 À : user@karaf.apache.org Objet : Re: Remote shell 
 connection

 The ssh feature ;)

 Regards
 JB

 On 04/15/2015 02:38 PM, CLEMENT Jean-Philippe wrote:
 Hi JB,

 The SSH feature does not seem to be installed.

 We are assembling Karaf; which dependency should we add?

 Regards,
 JP

 [@@ OPEN @@]


 -Message d'origine-
 De : Jean-Baptiste Onofré [mailto:j...@nanthrax.net] Envoyé : mercredi
 15 avril 2015 14:18 À : user@karaf.apache.org Objet : Re: Remote 
 shell connection

 Hi JP,

 Is the ssh feature installed ?
 If so, then 8101 is bound by default (as setup in 
 etc/org.apache.karaf.shell.cfg).

 I just tried with Karaf 3.0.3 and it works fine.

 Which version are you using ?
 The 8101 port number is not already bound by another process ?

 Regards
 JB

 On 04/15/2015 02:11 PM, CLEMENT Jean-Philippe wrote:
 Dear Karaf,

 I would like to open a shell to a remote Karaf instance. The 8101 port does 
 not seem to be opened.

 How to configure Karaf in order to allow connections?

 Kind regards,
 JP

 [@@ OPEN @@]


 --
 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


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

RE: Remote shell connection

2015-04-15 Thread CLEMENT Jean-Philippe

Yes, we are using the karaf-maven-plugin but I don't see any install-kar goal. 
The POM is short with a part describing features dependencies and the 
karaf-maven-plugin configuration which has a bootFeatures section.

I will add ssh to the bootFeatures section :)

Thanks a lot!

Regards,
JP

[@@ OPEN @@]


-Message d'origine-
De : Jean-Baptiste Onofré [mailto:j...@nanthrax.net] 
Envoyé : mercredi 15 avril 2015 17:16
À : user@karaf.apache.org
Objet : Re: Remote shell connection

I guess that you use the karaf-maven-plugin with install-kar goal, right ?

In that case, add the ssh feature as a bootFeature.

Regards
JB

On 04/15/2015 05:13 PM, CLEMENT Jean-Philippe wrote:
 Ok great,

 And what to configure in order to install it during the assembly?

 Regards,
 JP

 [@@ OPEN @@]


 -Message d'origine-
 De : Jean-Baptiste Onofré [mailto:j...@nanthrax.net] Envoyé : mercredi 
 15 avril 2015 15:22 À : user@karaf.apache.org Objet : Re: Remote shell 
 connection

 The ssh feature is provided in the Karaf standard (corresponding to the Karaf 
 version that you use).

 So, simply feature:install ssh should work.

 Regards
 JB

 On 04/15/2015 02:47 PM, CLEMENT Jean-Philippe wrote:
 :D

 ... I mean which group+artifact IDs, version and type?

 Regards,
 JP

 [@@ OPEN @@]


 -Message d'origine-
 De : Jean-Baptiste Onofré [mailto:j...@nanthrax.net] Envoyé : mercredi
 15 avril 2015 14:43 À : user@karaf.apache.org Objet : Re: Remote 
 shell connection

 The ssh feature ;)

 Regards
 JB

 On 04/15/2015 02:38 PM, CLEMENT Jean-Philippe wrote:
 Hi JB,

 The SSH feature does not seem to be installed.

 We are assembling Karaf; which dependency should we add?

 Regards,
 JP

 [@@ OPEN @@]


 -Message d'origine-
 De : Jean-Baptiste Onofré [mailto:j...@nanthrax.net] Envoyé : mercredi
 15 avril 2015 14:18 À : user@karaf.apache.org Objet : Re: Remote 
 shell connection

 Hi JP,

 Is the ssh feature installed ?
 If so, then 8101 is bound by default (as setup in 
 etc/org.apache.karaf.shell.cfg).

 I just tried with Karaf 3.0.3 and it works fine.

 Which version are you using ?
 The 8101 port number is not already bound by another process ?

 Regards
 JB

 On 04/15/2015 02:11 PM, CLEMENT Jean-Philippe wrote:
 Dear Karaf,

 I would like to open a shell to a remote Karaf instance. The 8101 port 
 does not seem to be opened.

 How to configure Karaf in order to allow connections?

 Kind regards,
 JP

 [@@ OPEN @@]


 --
 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


 --
 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

RE: Environment variables and Blueprint

2015-04-13 Thread CLEMENT Jean-Philippe

Hi JB,

We did try with ext but it did not work: ${TOTO} to retrieve the $TOTO variable.

What is the naming convention?

JP

[@@ OPEN @@]


-Message d'origine-
De : Jean-Baptiste Onofré [mailto:j...@nanthrax.net] 
Envoyé : lundi 13 avril 2015 10:28
À : user@karaf.apache.org
Objet : Re: Environment variables and Blueprint

Hi JP,

you can use Aries blueprint-ext and directly use ${} where the key is the 
system variable.

Regards
JB

On 04/13/2015 10:14 AM, CLEMENT Jean-Philippe wrote:
 Dear Karaf-ers,

 I would like to retrieve environment variables via Blueprint.
 Placeholder “persistent-id” is mandatory so it must point to a 
 .properties file, so maybe it’s not through cm-placeholders.

 Also, is there a way to replace expressions in .properties files?

 Regards,

 JP

 [@@ OPEN @@]


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

RE: Environment variables and Blueprint

2015-04-13 Thread CLEMENT Jean-Philippe

I wasn't clear, sorry. I'm talking about Unix env variables.

Is there a way to get them?

JP

[@@ OPEN @@]


-Message d'origine-
De : Jean-Baptiste Onofré [mailto:j...@nanthrax.net] 
Envoyé : lundi 13 avril 2015 13:38
À : user@karaf.apache.org
Objet : Re: Environment variables and Blueprint

Did you try:

ext:property-placeholder placeholder-prefix=$[ placeholder-suffix=]/

?

By system variables, do you mean JVM -Dkey=value or directly Unix env variables 
?

When I talk about system variables, it's -D args to the JVM. The later is env 
variable.

Regards
JB

On 04/13/2015 01:17 PM, CLEMENT Jean-Philippe wrote:
 Hi JB,

 We did try with ext but it did not work: ${TOTO} to retrieve the $TOTO 
 variable.

 What is the naming convention?

 JP

 [@@ OPEN @@]


 -Message d'origine-
 De : Jean-Baptiste Onofré [mailto:j...@nanthrax.net] Envoyé : lundi 13 
 avril 2015 10:28 À : user@karaf.apache.org Objet : Re: Environment 
 variables and Blueprint

 Hi JP,

 you can use Aries blueprint-ext and directly use ${} where the key is the 
 system variable.

 Regards
 JB

 On 04/13/2015 10:14 AM, CLEMENT Jean-Philippe wrote:
 Dear Karaf-ers,

 I would like to retrieve environment variables via Blueprint.
 Placeholder “persistent-id” is mandatory so it must point to a 
 .properties file, so maybe it’s not through cm-placeholders.

 Also, is there a way to replace expressions in .properties files?

 Regards,

 JP

 [@@ OPEN @@]


 --
 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

RE: Environment variables and Blueprint

2015-04-13 Thread CLEMENT Jean-Philippe

Ext placeholder does not seem to resolve variables set in the custom.properties 
file.

Is there anything to configure?

PS: thank you all for your answers! :)

JP

[@@ OPEN @@]

De : Guillaume Nodet [mailto:gno...@apache.org]
Envoyé : lundi 13 avril 2015 15:21
À : user
Objet : Re: Environment variables and Blueprint

To use env variables in etc/custom.properties, you should be able to do

my.system.property = ${env:MY_ENV_VAR}

and then, you should be able to use ${my.system.property} in blueprint files.

2015-04-13 14:32 GMT+02:00 Jean-Baptiste Onofré 
j...@nanthrax.netmailto:j...@nanthrax.net:
In that case, you can also use etc/custom.properties

Regards
JB

On 04/13/2015 02:24 PM, Charlie Mordant wrote:
Hi Jean Philippe,

Just pass your Unix env variable as VM arguments when you start your
VM/Karaf!

./karaf -DmyVMKey=$MyUnixENVVar

There's also a Karaf file in the bin folder where you can put your VM
args (env file).

Regards,

2015-04-13 13:56 GMT+02:00 CLEMENT Jean-Philippe
jean-philippe.clem...@fr.thalesgroup.commailto:jean-philippe.clem...@fr.thalesgroup.com
mailto:jean-philippe.clem...@fr.thalesgroup.commailto:jean-philippe.clem...@fr.thalesgroup.com:

I wasn't clear, sorry. I'm talking about Unix env variables.

Is there a way to get them?

JP

[@@ OPEN @@]


-Message d'origine-
De : Jean-Baptiste Onofré 
[mailto:j...@nanthrax.netmailto:j...@nanthrax.net
mailto:j...@nanthrax.netmailto:j...@nanthrax.net]
Envoyé : lundi 13 avril 2015 13:38
À : user@karaf.apache.orgmailto:user@karaf.apache.org 
mailto:user@karaf.apache.orgmailto:user@karaf.apache.org
Objet : Re: Environment variables and Blueprint

Did you try:

ext:property-placeholder placeholder-prefix=$[
placeholder-suffix=]/

?

By system variables, do you mean JVM -Dkey=value or directly Unix
env variables ?

When I talk about system variables, it's -D args to the JVM. The
later is env variable.

Regards
JB

On 04/13/2015 01:17 PM, CLEMENT Jean-Philippe wrote:
  Hi JB,
 
  We did try with ext but it did not work: ${TOTO} to retrieve the
$TOTO variable.
 
  What is the naming convention?
 
  JP
 
  [@@ OPEN @@]
 
 
  -Message d'origine-
  De : Jean-Baptiste Onofré 
[mailto:j...@nanthrax.netmailto:j...@nanthrax.net
mailto:j...@nanthrax.netmailto:j...@nanthrax.net] Envoyé : lundi 13
  avril 2015 10:28 À : user@karaf.apache.orgmailto:user@karaf.apache.org
mailto:user@karaf.apache.orgmailto:user@karaf.apache.org Objet : Re: 
Environment
  variables and Blueprint
 
  Hi JP,
 
  you can use Aries blueprint-ext and directly use ${} where the
key is the system variable.
 
  Regards
  JB
 
  On 04/13/2015 10:14 AM, CLEMENT Jean-Philippe wrote:
  Dear Karaf-ers,
 
  I would like to retrieve environment variables via Blueprint.
  Placeholder “persistent-id” is mandatory so it must point to a
  .properties file, so maybe it’s not through cm-placeholders.
 
  Also, is there a way to replace expressions in .properties files?
 
  Regards,
 
  JP
 
  [@@ OPEN @@]
 
 
  --
  Jean-Baptiste Onofré
  jbono...@apache.orgmailto:jbono...@apache.org 
mailto:jbono...@apache.orgmailto:jbono...@apache.org
  http://blog.nanthrax.net
  Talend - http://www.talend.com
 

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




--
Charlie Mordant

Full OSGI/EE stack made with Karaf:
https://github.com/OsgiliathEnterprise/net.osgiliath.parent

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

RE: Blueprint GracePeriod issue

2015-02-13 Thread CLEMENT Jean-Philippe

If you want to reference a service which is exported in the same bundle, you 
have to put the optional flag.

Having said that I'm not too sure what you wanted to do in the blueprint below. 
The reference-list is intended to call a bean (or beans) when the desired 
services match and disappear. In other words it behaves as a kind of service 
tracker.

Here is a basic example:

bean id=myBean class=.../

reference-list interface=FULLJAVAINTERFACENAME availability=optional
reference-listener ref=myBean bind-method=serviceFound 
unbind-method=serviceLost/
/reference-list

Where myBean would contain two public methods serviceFound and serviceLost. 
Also note that serviceLost method would be called with a null service if no 
service was found during startup, as per enterprise spec section 121.7.12.

JP

[@@ OPEN @@]

De : Leschke, Scott [mailto:slesc...@medline.com]
Envoyé : jeudi 12 février 2015 23:20
À : user@karaf.apache.org
Objet : RE: Blueprint GracePeriod issue

OK, if I understand you correctly, and I think I do since my test seems to bear 
that out, the bundle was going into GRACEPERIOD because there wasn't a service 
defined that implemented the exported service interface, hence the service 
injection can't work (which is what's happening, well sort of).  That explains 
why it used to work but began not working, since I simply wasn't deploying 
everything.

What confuses me a bit is that in this case, the lines in the blueprint.xml 
that seems to be causing the issue is the following:

bean id=service-controller-impl
   class=com.medline.bam.MyTestServiceController

   !-- Service constructor args --
argument ref=service-list/
/bean

reference-list id=service-list
  member-type=service-object
  interface=com.medline.bam.MyTestService/

It confuses me since the injection is of type ListMyTestService.  Since this 
list is live in the sense that entries can come and go at any time, shouldn't 
the injection of the list still succeed, but the list is empty, wouldn't that 
have made sense?  Perhaps there's a good reason why Blueprint isn't defined 
this way, I'd be curious as to what that reason is.

Thanks,

Scott

From: Benjamin Debeerst [mailto:benjamin.debee...@younicos.com]
Sent: Thursday, February 12, 2015 1:06 PM
To: user@karaf.apache.orgmailto:user@karaf.apache.org
Subject: RE: Blueprint GracePeriod issue

Hi Scott,

I find that kind of diagnosis from Blueprint quite confusing as well, because 
Blueprint tends to mix up dependencies on the bundle layer and dependencies on 
the service layer.

The bundle is resolved and started, but the blueprint container/component is 
missing service dependencies, in particular it cannot find a service with the 
given interface in the OSGi service registry. This is why it cannot start the 
blueprint component/container and is in the grace period state.

Do you have some component exposing the interface in question as a service in 
the OSGi service registry?

Regards,
Benjamin

From: Leschke, Scott [mailto:slesc...@medline.com]
Sent: Donnerstag, 12. Februar 2015 19:14
To: user@karaf.apache.orgmailto:user@karaf.apache.org
Subject: Blueprint GracePeriod issue

I have a bundle going into GracePeriod state.  The bundle:diag command says 
Missing Dependencies and gives me the name of an interface that exists in the 
bundle itself.  Is this indicative of a particular type of condition? I find it 
odd that it's complaining about not finding an interface that exists locally.

FIXED: Karaf 3.0.2 refuses to run with Jdk8u40 b12 (32 64 bits)

2014-12-09 Thread CLEMENT Jean-Philippe

Hi Jean-Baptiste,

You are right, it was a JDK regression (seems to be related to bug id 8064288 / 
sun.management.Flag should loadLibrary()) which is fixed in the 8u40-b17 
version.

Regards,
JP

[@@ OPEN @@]
-Message d'origine-
De : Jean-Baptiste Onofré [mailto:j...@nanthrax.net] 
Envoyé : samedi 6 décembre 2014 21:53
À : user@karaf.apache.org
Objet : Re: Karaf 3.0.2 refuses to run with Jdk8u40  b12 (32  64 bits)

It's what I saw last week (I think I sent an e-mail). But, it sounds like a 
OpenJDK regression to me.

Anyway, in general case, we should simply remove the arg.

Regards
JB

On 12/05/2014 02:30 PM, CLEMENT Jean-Philippe wrote:
 Some news,

 The JDK 8u40-b16 was released and Karaf still refuses to run with it 
 on both 32 and 64 bits systems. After a quick investigation I found 
 that removing the –Dcom.sun.management.jmxremote command line argument 
 fixes the issue.

 I’m wondering whether it is a Java regression, or, whether the 
 “com.sun…” flag could have been changed :S

 JP

 [@@ OPEN @@]

 *De :*Jean-Baptiste Onofré [mailto:j...@nanthrax.net] *Envoyé :* 
 vendredi 28 novembre 2014 11:53 *À :* user@karaf.apache.org *Objet :* 
 RE: Karaf 3.0.2 refuses to run with Jdk8u40b15 (i586)

 Hi JP

 The problem occurs only with with openjdk (not with Oracle or IBM jvm).

 I'm still investigating but I suspect a regression in openjdk.

 Regards

 JB



  Original message 
 From: CLEMENT Jean-Philippe jean-philippe.clem...@fr.thalesgroup.com
 mailto:jean-philippe.clem...@fr.thalesgroup.com
 Date:28/11/2014 11:21 (GMT+01:00)
 To: user@karaf.apache.org mailto:user@karaf.apache.org
 Cc:
 Subject: RE: Karaf 3.0.2 refuses to run with Jdk8u40b15 (i586)

 Hi JB,

 I'm very thankful for your support.

 Did you have time to take a look at this issue?

 Regards,
 JP

 [@@ OPEN @@]
 -Message d'origine-
 De : Jean-Baptiste Onofré [mailto:j...@nanthrax.net] Envoyé : samedi 22 
 novembre 2014 07:03 À : user@karaf.apache.org 
 mailto:user@karaf.apache.org Objet : Re: Karaf 3.0.2 refuses to run 
 with Jdk8u40b15 (i586)

 Hi JP,

 an another user reported the same issue after the update.

 I will investigate this during the week end.

 Regards
 JB

 On 11/21/2014 06:35 PM, CLEMENT Jean-Philippe wrote:
   Dear Karaf-ers,
  
   I just updated Java to 8u40-b15. Karaf was ok with b12 but refuses 
 to   start with b15.
  
   Starting karaf just leads to a quick end of it without any message, 
 no   log at all (the file is not created), and no core dump.
  
   Where to start investigation?
  
   Kind regards,
  
   JP
  
   [@@ OPEN @@]
  

 --
 Jean-Baptiste Onofré
 jbono...@apache.org mailto: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

1 2 3 >

1 - 100 of 202 matches

Mail list logo