Re: Custom Distribution Hangs on Startup...

[James Carman]

To make my example, I copied the featuresBoot from a downloaded version of
Karaf 4.2.2:

featuresBoot = \
instance/4.2.2, \
package/4.2.2, \
log/4.2.2, \
ssh/4.2.2, \
framework/4.2.2, \
system/4.2.2, \
eventadmin/4.2.2, \
feature/4.2.2, \
shell/4.2.2, \
management/4.2.2, \
service/4.2.2, \
jaas/4.2.2, \
deployer/4.2.2, \
diagnostic/4.2.2, \
wrap/2.5.4, \
bundle/4.2.2, \
config/4.2.2, \
kar/4.2.2

It appears that when I add "framework" to the list of , it
causes this issue.  If I omit it, then the startup.properties file
generates properly.  I would imagine this is a common occurrence, for folks
to want to start with a "vanilla" setup and customize from there (seemed
logical to me).  It looks like the "framework" feature shouldn't be
included in the list, but would be added by the presence of its KAR file:

[INFO] Loading direct KAR and features XML dependencies
[INFO]Standard startup Karaf KAR found:
mvn:org.apache.karaf.features/framework/4.2.2/kar
[INFO]Feature framework will be added as a startup feature

Maybe we should provide some more docs (or perhaps I missed them) around
how these different frameworks are selected/installed when using this maven
plugin?

On Wed, Jan 9, 2019 at 1:22 AM Jean-Baptiste Onofré  wrote:

> No, as the example just works fine: the etc/startup.properties is
> populated and the distribution starts without problem.
>
> Regards
> JB
>
> On 09/01/2019 06:37, James Carman wrote:
> > We should likely update the example?
> >
> >
> https://github.com/apache/karaf/blob/master/examples/karaf-maven-example/karaf-maven-example-assembly/pom.xml
> >
> >
> > On Wed, Jan 9, 2019 at 12:02 AM Jean-Baptiste Onofré 
> > wrote:
> >
> >> Hi James,
> >>
> >> I wasn't clear sorry. You need the framework features (in addition of
> >> kar) with runtime scope.
> >>
> >> I also see that the install kar is not performed by the karaf-assembly.
> >>
> >> I created a PR on your project fixing the issues.
> >>
> >> Anyway, it confirms what I sent some weeks ago: creating a custom
> >> distribution is not as simple as it should. I will simplify this.
> >>
> >> Regards
> >> JB
> >>
> >> On 08/01/2019 20:50, James Carman wrote:
> >>> When I change the kar scope to "provided", I get:
> >>>
> >>> Failed to execute goal
> >>> org.apache.karaf.tooling:karaf-maven-plugin:4.2.2:assembly
> >>> (default-assembly) on project custom-karaf-example: Unable to build
> >>> assembly: Can't determine framework to use (framework,
> framework-logback,
> >>> static-framework, static-framework-logback, custom). Please specify
> valid
> >>> "framework" option or add Maven dependency with "kar" type and
> "compile"
> >>> scope for one of standard Karaf KARs.
> >>>
> >>> I have updated the example I linked above to reflect the change.  Did I
> >> do
> >>> something wrong?
> >>>
> >>> On Tue, Jan 8, 2019 at 2:24 PM Jean-Baptiste Onofré 
> >> wrote:
> >>>
> >>>> Exactly, the scope should be provided ;)
> >>>>
> >>>> Regards
> >>>> JB
> >>>>
> >>>> On 08/01/2019 19:11, James Carman wrote:
> >>>>> On Tue, Jan 8, 2019 at 12:59 PM Jean-Baptiste Onofré <
> j...@nanthrax.net>
> >>>>> wrote:
> >>>>>
> >>>>>> Hi James,
> >>>>>>
> >>>>>> no the startup.properties is generated by the plugin, using the
> scope.
> >>>>>> So, karaf framework kar is probably missing in your project.
> >>>>>>
> >>>>>>
> >>>>> You mean this?
> >>>>>
> >>>>>
> >>>>
> >>
> https://github.com/jwcarman/custom-karaf-example/blob/vanilla/pom.xml#L18
> >>>>>
> >>>>
> >>>> --
> >>>> 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: Custom Distribution Hangs on Startup...

[James Carman]

We should likely update the example?

https://github.com/apache/karaf/blob/master/examples/karaf-maven-example/karaf-maven-example-assembly/pom.xml


On Wed, Jan 9, 2019 at 12:02 AM Jean-Baptiste Onofré 
wrote:

> Hi James,
>
> I wasn't clear sorry. You need the framework features (in addition of
> kar) with runtime scope.
>
> I also see that the install kar is not performed by the karaf-assembly.
>
> I created a PR on your project fixing the issues.
>
> Anyway, it confirms what I sent some weeks ago: creating a custom
> distribution is not as simple as it should. I will simplify this.
>
> Regards
> JB
>
> On 08/01/2019 20:50, James Carman wrote:
> > When I change the kar scope to "provided", I get:
> >
> > Failed to execute goal
> > org.apache.karaf.tooling:karaf-maven-plugin:4.2.2:assembly
> > (default-assembly) on project custom-karaf-example: Unable to build
> > assembly: Can't determine framework to use (framework, framework-logback,
> > static-framework, static-framework-logback, custom). Please specify valid
> > "framework" option or add Maven dependency with "kar" type and "compile"
> > scope for one of standard Karaf KARs.
> >
> > I have updated the example I linked above to reflect the change.  Did I
> do
> > something wrong?
> >
> > On Tue, Jan 8, 2019 at 2:24 PM Jean-Baptiste Onofré 
> wrote:
> >
> >> Exactly, the scope should be provided ;)
> >>
> >> Regards
> >> JB
> >>
> >> On 08/01/2019 19:11, James Carman wrote:
> >>> On Tue, Jan 8, 2019 at 12:59 PM Jean-Baptiste Onofré 
> >>> wrote:
> >>>
> >>>> Hi James,
> >>>>
> >>>> no the startup.properties is generated by the plugin, using the scope.
> >>>> So, karaf framework kar is probably missing in your project.
> >>>>
> >>>>
> >>> You mean this?
> >>>
> >>>
> >>
> https://github.com/jwcarman/custom-karaf-example/blob/vanilla/pom.xml#L18
> >>>
> >>
> >> --
> >> 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: Custom Distribution Hangs on Startup...

[James Carman]

When I change the kar scope to "provided", I get:

Failed to execute goal
org.apache.karaf.tooling:karaf-maven-plugin:4.2.2:assembly
(default-assembly) on project custom-karaf-example: Unable to build
assembly: Can't determine framework to use (framework, framework-logback,
static-framework, static-framework-logback, custom). Please specify valid
"framework" option or add Maven dependency with "kar" type and "compile"
scope for one of standard Karaf KARs.

I have updated the example I linked above to reflect the change.  Did I do
something wrong?

On Tue, Jan 8, 2019 at 2:24 PM Jean-Baptiste Onofré  wrote:

> Exactly, the scope should be provided ;)
>
> Regards
> JB
>
> On 08/01/2019 19:11, James Carman wrote:
> > On Tue, Jan 8, 2019 at 12:59 PM Jean-Baptiste Onofré 
> > wrote:
> >
> >> Hi James,
> >>
> >> no the startup.properties is generated by the plugin, using the scope.
> >> So, karaf framework kar is probably missing in your project.
> >>
> >>
> > You mean this?
> >
> >
> https://github.com/jwcarman/custom-karaf-example/blob/vanilla/pom.xml#L18
> >
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>

Re: Custom Distribution Hangs on Startup...

[James Carman]

On Tue, Jan 8, 2019 at 12:59 PM Jean-Baptiste Onofré 
wrote:

> Hi James,
>
> no the startup.properties is generated by the plugin, using the scope.
> So, karaf framework kar is probably missing in your project.
>
>
You mean this?

https://github.com/jwcarman/custom-karaf-example/blob/vanilla/pom.xml#L18

Re: Custom Distribution Hangs on Startup...

[James Carman]

But, that begs the question, should we really have to do that?  Is
something wrong with the plugin that it isn't copying the "standard"
startup.properties file from the base distro?

On Tue, Jan 8, 2019 at 11:56 AM James Carman 
wrote:

> That got it working for me.  Thanks, Johan!
>
>
> On Tue, Jan 8, 2019 at 11:55 AM Johan Edstrom  wrote:
>
>> I compared to a 4.2.2,
>> it is missing startup.properties in the generation.
>>
>> Adding;
>>
>> # Bundles to be started on startup, with startlevel
>> mvn\:org.apache.karaf.features/org.apache.karaf.features.extension/4.2.2
>> = 1
>> mvn\:org.apache.felix/org.apache.felix.metatype/1.2.2 = 5
>> mvn\:org.apache.karaf.services/org.apache.karaf.services.eventadmin/4.2.2
>> = 5
>> mvn\:org.ops4j.pax.url/pax-url-aether/2.5.4 = 5
>> mvn\:org.fusesource.jansi/jansi/1.17.1 = 8
>> mvn\:org.ops4j.pax.logging/pax-logging-api/1.10.1 = 8
>> mvn\:org.ops4j.pax.logging/pax-logging-log4j2/1.10.1 = 8
>> mvn\:org.apache.felix/org.apache.felix.coordinator/1.0.2 = 9
>> mvn\:org.apache.felix/org.apache.felix.configadmin/1.9.10 = 10
>> mvn\:org.apache.felix/org.apache.felix.fileinstall/3.6.4 = 11
>> mvn\:org.apache.karaf.features/org.apache.karaf.features.core/4.2.2 = 15
>> mvn\:org.apache.servicemix.specs/org.apache.servicemix.specs.activation-api-1.1/2.5.0
>> = 30
>>
>> and it looks nicer.
>>
>>
>>
>> > On Jan 8, 2019, at 9:12 AM, James Carman 
>> wrote:
>> >
>> > I am trying to create a custom distribution:
>> >
>> > https://github.com/jwcarman/custom-karaf-example/tree/vanilla
>> >
>> > When I cd into the target/assembly directory and do:
>> >
>> > bin/karaf
>> >
>> > the logs stop after this:
>> >
>> > Jan 08, 2019 11:11:01 AM org.apache.karaf.main.Main launch
>> > INFO: Installing and starting initial bundles
>> > Jan 08, 2019 11:11:01 AM org.apache.karaf.main.Main launch
>> > INFO: All initial bundles installed and set to start
>> > Jan 08, 2019 11:11:01 AM org.apache.karaf.main.lock.SimpleFileLock lock
>> > INFO: Trying to lock
>> > /Users/jcarman/IdeaProjects/custom-karaf-example/target/assembly/lock
>> > Jan 08, 2019 11:11:01 AM org.apache.karaf.main.lock.SimpleFileLock lock
>> > INFO: Lock acquired
>> > Jan 08, 2019 11:11:01 AM org.apache.karaf.main.Main$KarafLockCallback
>> > lockAcquired
>> > INFO: Lock acquired. Setting startlevel to 100
>> >
>> >
>> > Am I missing something?
>> >
>> > Thanks,
>> >
>> > James
>>
>>

Re: Custom Distribution Hangs on Startup...

[James Carman]

That got it working for me.  Thanks, Johan!


On Tue, Jan 8, 2019 at 11:55 AM Johan Edstrom  wrote:

> I compared to a 4.2.2,
> it is missing startup.properties in the generation.
>
> Adding;
>
> # Bundles to be started on startup, with startlevel
> mvn\:org.apache.karaf.features/org.apache.karaf.features.extension/4.2.2 =
> 1
> mvn\:org.apache.felix/org.apache.felix.metatype/1.2.2 = 5
> mvn\:org.apache.karaf.services/org.apache.karaf.services.eventadmin/4.2.2
> = 5
> mvn\:org.ops4j.pax.url/pax-url-aether/2.5.4 = 5
> mvn\:org.fusesource.jansi/jansi/1.17.1 = 8
> mvn\:org.ops4j.pax.logging/pax-logging-api/1.10.1 = 8
> mvn\:org.ops4j.pax.logging/pax-logging-log4j2/1.10.1 = 8
> mvn\:org.apache.felix/org.apache.felix.coordinator/1.0.2 = 9
> mvn\:org.apache.felix/org.apache.felix.configadmin/1.9.10 = 10
> mvn\:org.apache.felix/org.apache.felix.fileinstall/3.6.4 = 11
> mvn\:org.apache.karaf.features/org.apache.karaf.features.core/4.2.2 = 15
> mvn\:org.apache.servicemix.specs/org.apache.servicemix.specs.activation-api-1.1/2.5.0
> = 30
>
> and it looks nicer.
>
>
>
> > On Jan 8, 2019, at 9:12 AM, James Carman 
> wrote:
> >
> > I am trying to create a custom distribution:
> >
> > https://github.com/jwcarman/custom-karaf-example/tree/vanilla
> >
> > When I cd into the target/assembly directory and do:
> >
> > bin/karaf
> >
> > the logs stop after this:
> >
> > Jan 08, 2019 11:11:01 AM org.apache.karaf.main.Main launch
> > INFO: Installing and starting initial bundles
> > Jan 08, 2019 11:11:01 AM org.apache.karaf.main.Main launch
> > INFO: All initial bundles installed and set to start
> > Jan 08, 2019 11:11:01 AM org.apache.karaf.main.lock.SimpleFileLock lock
> > INFO: Trying to lock
> > /Users/jcarman/IdeaProjects/custom-karaf-example/target/assembly/lock
> > Jan 08, 2019 11:11:01 AM org.apache.karaf.main.lock.SimpleFileLock lock
> > INFO: Lock acquired
> > Jan 08, 2019 11:11:01 AM org.apache.karaf.main.Main$KarafLockCallback
> > lockAcquired
> > INFO: Lock acquired. Setting startlevel to 100
> >
> >
> > Am I missing something?
> >
> > Thanks,
> >
> > James
>
>

Custom Distribution Hangs on Startup...

[James Carman]

I am trying to create a custom distribution:

https://github.com/jwcarman/custom-karaf-example/tree/vanilla

When I cd into the target/assembly directory and do:

bin/karaf

the logs stop after this:

Jan 08, 2019 11:11:01 AM org.apache.karaf.main.Main launch
INFO: Installing and starting initial bundles
Jan 08, 2019 11:11:01 AM org.apache.karaf.main.Main launch
INFO: All initial bundles installed and set to start
Jan 08, 2019 11:11:01 AM org.apache.karaf.main.lock.SimpleFileLock lock
INFO: Trying to lock
/Users/jcarman/IdeaProjects/custom-karaf-example/target/assembly/lock
Jan 08, 2019 11:11:01 AM org.apache.karaf.main.lock.SimpleFileLock lock
INFO: Lock acquired
Jan 08, 2019 11:11:01 AM org.apache.karaf.main.Main$KarafLockCallback
lockAcquired
INFO: Lock acquired. Setting startlevel to 100


Am I missing something?

Thanks,

James

Re: Enterprise Feature Repository Causing Invalid Custom Distribution...

[James Carman]

Oh, guess I have some reading to do! Thanks, JB!
On Tue, Jan 8, 2019 at 8:29 AM Jean-Baptiste Onofré  wrote:

> It's already possible via cap/req in features (as we do in Pax Web for
> instance).
>
> Regards
> JB
>
> On 08/01/2019 13:50, James Carman wrote:
> > I see the changes in the ActiveMQ to make it more “open” (didn’t know
> that
> > was what it’s called). I like that much better. Too bad we can’t declare
> a
> > requirement on another repository and not a full import. Perhaps we can
> > enhance the feature repository format to allow for that?
> > On Tue, Jan 8, 2019 at 7:37 AM Jean-Baptiste Onofré 
> wrote:
> >
> >> Hi James,
> >>
> >> I guess you mean "open" features (where features repo are used at
> >> runtime) compared to "close" features (where features repo uses inner
> >> ).
> >>
> >> The approach also depends of your deployment option. For instance:
> >>
> >> 1. when I'm using Karaf as a runtime, where I install several
> >> applications, most of the time I'm using "open" features (via Cave
> >> Feature Gateway or directly).
> >> 2. when I'm using Karaf more as an immutable "box" (like on Docker),
> >> "close" features or custom distribution is convenient.
> >>
> >> Generally speaking, I prefer "open" features repo, and eventually create
> >> my own custom distro (as the "kloud" one).
> >>
> >> Regards
> >> JB
> >>
> >> On 08/01/2019 12:42, James Carman wrote:
> >>> I’m really not a big fan of features files pulling in karaf feature
> >>> repository files. We avoid that at work and just have our features
> files
> >>> refer to other features by name only (no versions and no repositories).
> >>> That’s a more controlled environment, of course. What’s the “best
> >> practice”
> >>> for the more general care? It just seems dangerous for other folks to
> >> start
> >>> yanking in possibly incompatible feature repositories.
> >>> On Tue, Jan 8, 2019 at 1:59 AM Jean-Baptiste Onofré 
> >> wrote:
> >>>
> >>>> Hi,
> >>>>
> >>>> AFAIR, I already fixed ActiveMQ features XML.
> >>>>
> >>>> Let me try with ActiveMQ SNAPSHOT.
> >>>>
> >>>> Regards
> >>>> JB
> >>>>
> >>>> On 08/01/2019 07:35, Benjamin Graf wrote:
> >>>>> Hi JB,
> >>>>>
> >>>>> that's the error of the ActiveMQ feature file I reported last year.
> The
> >>>>> corrected feature file is not releases yet. It may also be a problem
> in
> >>>>> the resolvement algorithm used by involved components mainly outside
> >>>>> Karaf I think pax-url if I remember right.
> >>>>>
> >>>>> Regards
> >>>>> Benjamin
> >>>>>
> >>>>> Am 8. Januar 2019 06:09:10 MEZ schrieb "Jean-Baptiste Onofré"
> >>>>> :
> >>>>>
> >>>>> By the way, the enterprise features repo is used in the standard
> >>>> Karaf
> >>>>> distribution, so it's weird that it works here. It's maybe a
> >>>> combination
> >>>>> of features.
> >>>>>
> >>>>> For the tracking I created:
> >>>> https://issues.apache.org/jira/browse/KARAF-6075
> >>>>>
> >>>>> Regards
> >>>>> JB
> >>>>>
> >>>>> On 07/01/2019 22:16, James Carman wrote:
> >>>>>
> >>>>> We are trying to build our own custom Karaf 4.2.2
> distribution
> >>>> and
> >>>>> when we include the enterprise feature repository along with
> >> the
> >>>>> ActiveMQ 5.15.8 feature repository, we get an invalid
> >>>>> org.apache.karaf.features.cfg file which includes
> >> 4.2.3-SNAPSHOT
> >>>>> versions of some of the boot features. I have created an
> >> example
> >>>>> project here:
> >>>>>
> >>>>> https://github.com/jwcarman/custom-karaf-example
> >>>>>
> >>>>> If you build it as-is, you'll see the problem. If you comment
> >>>>> out the
> >>>>> enterprise feature repo, the problem goes away.
> >>>>>
> >>>>> Thanks,
> >>>>>
> >>>>> James
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
> >>>>
> >>>> --
> >>>> 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: Enterprise Feature Repository Causing Invalid Custom Distribution...

[James Carman]

I see the changes in the ActiveMQ to make it more “open” (didn’t know that
was what it’s called). I like that much better. Too bad we can’t declare a
requirement on another repository and not a full import. Perhaps we can
enhance the feature repository format to allow for that?
On Tue, Jan 8, 2019 at 7:37 AM Jean-Baptiste Onofré  wrote:

> Hi James,
>
> I guess you mean "open" features (where features repo are used at
> runtime) compared to "close" features (where features repo uses inner
> ).
>
> The approach also depends of your deployment option. For instance:
>
> 1. when I'm using Karaf as a runtime, where I install several
> applications, most of the time I'm using "open" features (via Cave
> Feature Gateway or directly).
> 2. when I'm using Karaf more as an immutable "box" (like on Docker),
> "close" features or custom distribution is convenient.
>
> Generally speaking, I prefer "open" features repo, and eventually create
> my own custom distro (as the "kloud" one).
>
> Regards
> JB
>
> On 08/01/2019 12:42, James Carman wrote:
> > I’m really not a big fan of features files pulling in karaf feature
> > repository files. We avoid that at work and just have our features files
> > refer to other features by name only (no versions and no repositories).
> > That’s a more controlled environment, of course. What’s the “best
> practice”
> > for the more general care? It just seems dangerous for other folks to
> start
> > yanking in possibly incompatible feature repositories.
> > On Tue, Jan 8, 2019 at 1:59 AM Jean-Baptiste Onofré 
> wrote:
> >
> >> Hi,
> >>
> >> AFAIR, I already fixed ActiveMQ features XML.
> >>
> >> Let me try with ActiveMQ SNAPSHOT.
> >>
> >> Regards
> >> JB
> >>
> >> On 08/01/2019 07:35, Benjamin Graf wrote:
> >>> Hi JB,
> >>>
> >>> that's the error of the ActiveMQ feature file I reported last year. The
> >>> corrected feature file is not releases yet. It may also be a problem in
> >>> the resolvement algorithm used by involved components mainly outside
> >>> Karaf I think pax-url if I remember right.
> >>>
> >>> Regards
> >>> Benjamin
> >>>
> >>> Am 8. Januar 2019 06:09:10 MEZ schrieb "Jean-Baptiste Onofré"
> >>> :
> >>>
> >>> By the way, the enterprise features repo is used in the standard
> >> Karaf
> >>> distribution, so it's weird that it works here. It's maybe a
> >> combination
> >>> of features.
> >>>
> >>> For the tracking I created:
> >> https://issues.apache.org/jira/browse/KARAF-6075
> >>>
> >>> Regards
> >>> JB
> >>>
> >>> On 07/01/2019 22:16, James Carman wrote:
> >>>
> >>> We are trying to build our own custom Karaf 4.2.2 distribution
> >> and
> >>> when we include the enterprise feature repository along with
> the
> >>> ActiveMQ 5.15.8 feature repository, we get an invalid
> >>> org.apache.karaf.features.cfg file which includes
> 4.2.3-SNAPSHOT
> >>> versions of some of the boot features. I have created an
> example
> >>> project here:
> >>>
> >>> https://github.com/jwcarman/custom-karaf-example
> >>>
> >>> If you build it as-is, you'll see the problem. If you comment
> >>> out the
> >>> enterprise feature repo, the problem goes away.
> >>>
> >>> Thanks,
> >>>
> >>> James
> >>>
> >>>
> >>> --
> >>> Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
> >>
> >> --
> >> 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: Enterprise Feature Repository Causing Invalid Custom Distribution...

[James Carman]

I’m really not a big fan of features files pulling in karaf feature
repository files. We avoid that at work and just have our features files
refer to other features by name only (no versions and no repositories).
That’s a more controlled environment, of course. What’s the “best practice”
for the more general care? It just seems dangerous for other folks to start
yanking in possibly incompatible feature repositories.
On Tue, Jan 8, 2019 at 1:59 AM Jean-Baptiste Onofré  wrote:

> Hi,
>
> AFAIR, I already fixed ActiveMQ features XML.
>
> Let me try with ActiveMQ SNAPSHOT.
>
> Regards
> JB
>
> On 08/01/2019 07:35, Benjamin Graf wrote:
> > Hi JB,
> >
> > that's the error of the ActiveMQ feature file I reported last year. The
> > corrected feature file is not releases yet. It may also be a problem in
> > the resolvement algorithm used by involved components mainly outside
> > Karaf I think pax-url if I remember right.
> >
> > Regards
> > Benjamin
> >
> > Am 8. Januar 2019 06:09:10 MEZ schrieb "Jean-Baptiste Onofré"
> > :
> >
> > By the way, the enterprise features repo is used in the standard
> Karaf
> > distribution, so it's weird that it works here. It's maybe a
> combination
> > of features.
> >
> > For the tracking I created:
> https://issues.apache.org/jira/browse/KARAF-6075
> >
> > Regards
> > JB
> >
> > On 07/01/2019 22:16, James Carman wrote:
> >
> > We are trying to build our own custom Karaf 4.2.2 distribution
> and
> > when we include the enterprise feature repository along with the
> > ActiveMQ 5.15.8 feature repository, we get an invalid
> > org.apache.karaf.features.cfg file which includes 4.2.3-SNAPSHOT
> > versions of some of the boot features. I have created an example
> > project here:
> >
> > https://github.com/jwcarman/custom-karaf-example
> >
> > If you build it as-is, you'll see the problem. If you comment
> > out the
> > enterprise feature repo, the problem goes away.
> >
> > Thanks,
> >
> > James
> >
> >
> > --
> > Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>

Enterprise Feature Repository Causing Invalid Custom Distribution...

[James Carman]

We are trying to build our own custom Karaf 4.2.2 distribution and
when we include the enterprise feature repository along with the
ActiveMQ 5.15.8 feature repository, we get an invalid
org.apache.karaf.features.cfg file which includes 4.2.3-SNAPSHOT
versions of some of the boot features.  I have created an example
project here:

https://github.com/jwcarman/custom-karaf-example

If you build it as-is, you'll see the problem. If you comment out the
enterprise feature repo, the problem goes away.

Thanks,

James

Re: Getting resources from other OSGi Bundle

[James Carman]

Oftentimes you can avoid it entirely.  What is your use case?

On Thu, Jun 22, 2017 at 6:07 AM Dominik Marciniszyn <
marciniszyn.domi...@gmail.com> wrote:

> Hi,
>
> I have two osgi bundles and I would like to get some resources files from
> one bundle to another. I've used BundleContext to get the second bundle by
> ID. Then I use getResource() method, pass the path parameter but always got
> null.
>
> Sample code I used:
> BundleContext context =
> FrameworkUtil.getBundle(MyClass.class).getBundleContext();
> context.getBundle(id_of_my_second_bundle).getResource("resource/res_file");
>
> Thank you for any advices or help,
> Dominik Marciniszyn
>
>
>
> --
> View this message in context:
> http://karaf.922171.n3.nabble.com/Getting-resources-from-other-OSGi-Bundle-tp4050852.html
> Sent from the Karaf - Dev mailing list archive at Nabble.com.
>

Re: Hitting up arrow while command is running not working...

[James Carman]

Nice! Thanks!
On Fri, Jun 2, 2017 at 7:30 AM Guillaume Nodet <gno...@apache.org> wrote:

> Actually, I just fixed it:
>   https://issues.apache.org/jira/browse/KARAF-5176
>
> 2017-05-23 15:00 GMT+02:00 James Carman <ja...@carmanconsulting.com>:
>
> > First of all, yes, I'm impatient! :)  Anyway, I used to be able to hit
> the
> > up arrow while a command was executing (say feature:install or something)
> > so that I could bring up the next command I was going to run.  Now, it
> just
> > starts printing "[A[A[A" characters to the console.  Is there some way to
> > resurrect the old behavior.  I'm using 4.1.1.
> >
>
>
>
> --
> 
> Guillaume Nodet
>

Re: [UPDATE] Remove org.json dependency

[James Carman]

I'm also cool with "dog-fooding" Apache Johnzon.  I just have a lot of
experience with GSON and have found it to be a breeze to work with (that's
why I use it in Microbule by default).


On Thu, May 25, 2017 at 12:56 PM Achim Nierbeck 
wrote:

> I'm not a friend of re-inventing the wheel a thousand time.
> Only use it if it really really matches.
> If it doesn't match our use-case, we should use johnzon
>
> regards, Achim
>
>
> 2017-05-25 18:50 GMT+02:00 Jean-Baptiste Onofré :
>
> > My preference for now is on the tiny Felix JSON parser (lighter than
> > johnzon).
> >
> > Regards
> > JB
> >
> >
> > On 05/25/2017 06:26 PM, Achim Nierbeck wrote:
> >
> >> hmm ... we do have a JSON Apache Library, before we A) start our own, we
> >> should B) prefer it over any other non-apache library.
> >> That would be apache johnzon ;)
> >>
> >> regards, Achim
> >>
> >>
> >> 2017-05-25 16:22 GMT+02:00 Jean-Baptiste Onofré :
> >>
> >> I'm evaluating GSON and the Felix "parser".
> >>>
> >>> Regards
> >>> JB
> >>>
> >>>
> >>> On 05/25/2017 04:18 PM, Matt Sicker wrote:
> >>>
> >>>   From what I understand, this only applies to the org.json dependency.
>  Most
>  people tend to use Jackson or Gson in my experience which are
>  appropriately
>  licensed.
> 
>  On 25 May 2017 at 08:41, Jean-Baptiste Onofré 
> wrote:
> 
>  Yeah, but we are using json for our "webconsole plugins". So, I'm
>  changing
> 
> > in our plugins.
> >
> > Regards
> > JB
> >
> >
> > On 05/25/2017 03:39 PM, Achim Nierbeck wrote:
> >
> > Hi JB,
> >
> >>
> >> I thought the felix team did some effort in replacing all that json
> >> stuff
> >> with internal handling.
> >> We should just update to the latest then ...
> >>
> >> regards, Achim
> >>
> >>
> >> 2017-05-25 15:38 GMT+02:00 Jean-Baptiste Onofré :
> >>
> >> Hi,
> >>
> >>
> >>> Chris Mattmann (new Legal VP) sent a reminder about json dependency
> >>> use:
> >>>
> >>> ---
> >>> As the new Legal VP, I am reminding everyone that the
> >>> grandfather exception for the JSON License and Apache projects
> >>> ended last month. As sent by Jim (our prior Legal VP) the relevant
> >>> text is below and I want to highlight the following statement:
> >>>
> >>> If you have been using it, and have done so in a *release*, AND
> there
> >>> has
> >>> been NO pushback from your community/eco-system, you have a
> temporary
> >>> exclusion from the Cat-X classification thru April 30, 2017. At
> that
> >>> point
> >>> in time,
> >>>
> >>> ANY and ALL usage of these JSON licensed artifacts are DISALLOWED.
> >>> ---
> >>>
> >>> We are using json (org.json/json) in the WebConsole. I created
> >>> KARAF-5148
> >>> to track this and I'm evaluating different alternatives.
> >>>
> >>> Regards
> >>> JB
> >>> --
> >>> Jean-Baptiste Onofré
> >>> jbono...@apache.org
> >>> http://blog.nanthrax.net
> >>> Talend - http://www.talend.com
> >>>
> >>>
> >>>
> >>>
> >>
> >> --
> >>
> > Jean-Baptiste Onofré
> > jbono...@apache.org
> > http://blog.nanthrax.net
> > Talend - http://www.talend.com
> >
> >
> >
> 
> 
>  --
> >>> 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
> >
>
>
>
> --
>
> 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
>

Re: [UPDATE] Remove org.json dependency

[James Carman]

+1 for GSON.
On Thu, May 25, 2017 at 10:18 AM Matt Sicker  wrote:

> From what I understand, this only applies to the org.json dependency. Most
> people tend to use Jackson or Gson in my experience which are appropriately
> licensed.
>
> On 25 May 2017 at 08:41, Jean-Baptiste Onofré  wrote:
>
> > Yeah, but we are using json for our "webconsole plugins". So, I'm
> changing
> > in our plugins.
> >
> > Regards
> > JB
> >
> >
> > On 05/25/2017 03:39 PM, Achim Nierbeck wrote:
> >
> >> Hi JB,
> >>
> >> I thought the felix team did some effort in replacing all that json
> stuff
> >> with internal handling.
> >> We should just update to the latest then ...
> >>
> >> regards, Achim
> >>
> >>
> >> 2017-05-25 15:38 GMT+02:00 Jean-Baptiste Onofré :
> >>
> >> Hi,
> >>>
> >>> Chris Mattmann (new Legal VP) sent a reminder about json dependency
> use:
> >>>
> >>> ---
> >>> As the new Legal VP, I am reminding everyone that the
> >>> grandfather exception for the JSON License and Apache projects
> >>> ended last month. As sent by Jim (our prior Legal VP) the relevant
> >>> text is below and I want to highlight the following statement:
> >>>
> >>> If you have been using it, and have done so in a *release*, AND there
> has
> >>> been NO pushback from your community/eco-system, you have a temporary
> >>> exclusion from the Cat-X classification thru April 30, 2017. At that
> >>> point
> >>> in time,
> >>>
> >>> ANY and ALL usage of these JSON licensed artifacts are DISALLOWED.
> >>> ---
> >>>
> >>> We are using json (org.json/json) in the WebConsole. I created
> KARAF-5148
> >>> to track this and I'm evaluating different alternatives.
> >>>
> >>> Regards
> >>> JB
> >>> --
> >>> Jean-Baptiste Onofré
> >>> jbono...@apache.org
> >>> http://blog.nanthrax.net
> >>> Talend - http://www.talend.com
> >>>
> >>>
> >>
> >>
> >>
> > --
> > Jean-Baptiste Onofré
> > jbono...@apache.org
> > http://blog.nanthrax.net
> > Talend - http://www.talend.com
> >
>
>
>
> --
> Matt Sicker 
>

Re: Using Custom Layout for Log4j2 in Karaf 4.1.x...

[James Carman]

I can try to help if you guys want.  Want me to tinker?  I think we will
want to update the docs too, since folks will need to generate those dat
files.
On Wed, May 24, 2017 at 8:31 PM Matt Sicker <boa...@gmail.com> wrote:

> Oh, well that certainly sounds like a problem! There's an activator in both
> log4j-api and log4j-core from what I recall, so pax-logging might need
> something custom as well.
>
> On 24 May 2017 at 17:41, James Carman <ja...@carmanconsulting.com> wrote:
>
> > So, I've done a bit of digging.  Log4j2 ships with an Activator that sets
> > up a BundleListener which scans (looks for Log4j2Plugins.dat files)
> bundles
> > for any plugins to be registered.  Since log4j itself is not loaded as a
> > bundle (it appears to be shaded into pax-logging-log4j2), that Activator
> > doesn't run.  Perhaps we should delegate to Log4j's internal Activator
> > during the start() method of the Pax Logging Activator
> > (org.ops4j.pax.logging.log4j2.internal.Activator)?  Do we cover this
> > behavior in some other way?
> >
> >
> > On Wed, May 24, 2017 at 3:32 PM James Carman <ja...@carmanconsulting.com
> >
> > wrote:
> >
> > > So, am I way off base with my approach or anything?  Should Karaf be
> > > installing pax-logging-service?  Or, is pax-logging-log4j2 taking its
> > place
> > > for Karaf?  Is there anything special we have to do to implement a
> custom
> > > Layout using pax-logging?  Is there a working example I can use to
> > install
> > > into karaf to see if it works for me?
> > >
> > >
> > > On Wed, May 24, 2017 at 3:20 PM Matt Sicker <boa...@gmail.com> wrote:
> > >
> > >> I mostly work on Log4j2, though I try to answer questions about it on
> > >> ops4j
> > >> and karaf due to pax-logging.
> > >>
> > >> On 24 May 2017 at 14:17, James Carman <ja...@carmanconsulting.com>
> > wrote:
> > >>
> > >> > I know. ;)  And I meant no slight to you.  I didn't know you were
> one
> > of
> > >> > the contributors these days.  I have checked out the code and I'm
> > going
> > >> to
> > >> > poke around a bit.
> > >> >
> > >> > On Wed, May 24, 2017 at 3:15 PM Matt Sicker <boa...@gmail.com>
> wrote:
> > >> >
> > >> > > That would be on the ops4j lists, though that's mostly the same
> > >> people as
> > >> > > here.
> > >> > >
> > >> > > On 24 May 2017 at 13:31, James Carman <ja...@carmanconsulting.com
> >
> > >> > wrote:
> > >> > >
> > >> > > > I think I must be doing something wrong.  Hopefully one of the
> PAX
> > >> > folks
> > >> > > > can help here.  I wonder if I should just reach out to them
> > >> directly or
> > >> > > if
> > >> > > > this is a karaf-specific issue with PAX?
> > >> > > >
> > >> > > > On Wed, May 24, 2017 at 2:29 PM Matt Sicker <boa...@gmail.com>
> > >> wrote:
> > >> > > >
> > >> > > > > At compile time, an annotation processor in log4j-core
> > generates a
> > >> > .dat
> > >> > > > > file containing some metadata about scanned plugins. These JAR
> > >> > resource
> > >> > > > > files are loaded at plugin scan time where reflection is used
> to
> > >> > > > > investigate the classes and instantiate plugins based on
> config
> > >> > files.
> > >> > > > > Alternatively, there's an option you can set to scan a
> > particular
> > >> > list
> > >> > > of
> > >> > > > > packages for additional plugins, though I think that uses the
> > >> context
> > >> > > > > ClassLoader which might not work properly in your scenario.
> > >> > > > >
> > >> > > > > On 24 May 2017 at 11:22, James Carman <
> > ja...@carmanconsulting.com
> > >> >
> > >> > > > wrote:
> > >> > > > >
> > >> > > > > > Any advice on how I might be able to fight my way through
> it?
> > >> How
> > >> > > does
> > >> > > > > > Log4j2 "discover" those @Plugin-annotated classes?  Does it
> > use
> >

Re: Using Custom Layout for Log4j2 in Karaf 4.1.x...

[James Carman]

So, I've done a bit of digging.  Log4j2 ships with an Activator that sets
up a BundleListener which scans (looks for Log4j2Plugins.dat files) bundles
for any plugins to be registered.  Since log4j itself is not loaded as a
bundle (it appears to be shaded into pax-logging-log4j2), that Activator
doesn't run.  Perhaps we should delegate to Log4j's internal Activator
during the start() method of the Pax Logging Activator
(org.ops4j.pax.logging.log4j2.internal.Activator)?  Do we cover this
behavior in some other way?


On Wed, May 24, 2017 at 3:32 PM James Carman <ja...@carmanconsulting.com>
wrote:

> So, am I way off base with my approach or anything?  Should Karaf be
> installing pax-logging-service?  Or, is pax-logging-log4j2 taking its place
> for Karaf?  Is there anything special we have to do to implement a custom
> Layout using pax-logging?  Is there a working example I can use to install
> into karaf to see if it works for me?
>
>
> On Wed, May 24, 2017 at 3:20 PM Matt Sicker <boa...@gmail.com> wrote:
>
>> I mostly work on Log4j2, though I try to answer questions about it on
>> ops4j
>> and karaf due to pax-logging.
>>
>> On 24 May 2017 at 14:17, James Carman <ja...@carmanconsulting.com> wrote:
>>
>> > I know. ;)  And I meant no slight to you.  I didn't know you were one of
>> > the contributors these days.  I have checked out the code and I'm going
>> to
>> > poke around a bit.
>> >
>> > On Wed, May 24, 2017 at 3:15 PM Matt Sicker <boa...@gmail.com> wrote:
>> >
>> > > That would be on the ops4j lists, though that's mostly the same
>> people as
>> > > here.
>> > >
>> > > On 24 May 2017 at 13:31, James Carman <ja...@carmanconsulting.com>
>> > wrote:
>> > >
>> > > > I think I must be doing something wrong.  Hopefully one of the PAX
>> > folks
>> > > > can help here.  I wonder if I should just reach out to them
>> directly or
>> > > if
>> > > > this is a karaf-specific issue with PAX?
>> > > >
>> > > > On Wed, May 24, 2017 at 2:29 PM Matt Sicker <boa...@gmail.com>
>> wrote:
>> > > >
>> > > > > At compile time, an annotation processor in log4j-core generates a
>> > .dat
>> > > > > file containing some metadata about scanned plugins. These JAR
>> > resource
>> > > > > files are loaded at plugin scan time where reflection is used to
>> > > > > investigate the classes and instantiate plugins based on config
>> > files.
>> > > > > Alternatively, there's an option you can set to scan a particular
>> > list
>> > > of
>> > > > > packages for additional plugins, though I think that uses the
>> context
>> > > > > ClassLoader which might not work properly in your scenario.
>> > > > >
>> > > > > On 24 May 2017 at 11:22, James Carman <ja...@carmanconsulting.com
>> >
>> > > > wrote:
>> > > > >
>> > > > > > Any advice on how I might be able to fight my way through it?
>> How
>> > > does
>> > > > > > Log4j2 "discover" those @Plugin-annotated classes?  Does it use
>> > some
>> > > > form
>> > > > > > of classpath scanning?  Is it scoped to certain packages only?
>> I'm
>> > > > > > thinking I might have to attach to the pax-logging-log4j2 bundle
>> > as a
>> > > > > host
>> > > > > > in order to augment its classpath so that it can see my stuff.
>> > > > > >
>> > > > > > On Wed, May 24, 2017 at 12:20 PM Matt Sicker <boa...@gmail.com>
>> > > wrote:
>> > > > > >
>> > > > > > > It could be a bug in log4j2 itself rather than pax-logging. I
>> > > worked
>> > > > on
>> > > > > > > some OSGi support in log4j2 a while back, and I'm not sure if
>> > this
>> > > > is a
>> > > > > > new
>> > > > > > > issue or an existing one.
>> > > > > > >
>> > > > > > > On 24 May 2017 at 05:43, James Carman <
>> > ja...@carmanconsulting.com>
>> > > > > > wrote:
>> > > > > > >
>> > > > > > > > I tried adding pax-logging-service to startup.properties
>> (after
>> > > > > putt

Re: Using Custom Layout for Log4j2 in Karaf 4.1.x...

[James Carman]

So, am I way off base with my approach or anything?  Should Karaf be
installing pax-logging-service?  Or, is pax-logging-log4j2 taking its place
for Karaf?  Is there anything special we have to do to implement a custom
Layout using pax-logging?  Is there a working example I can use to install
into karaf to see if it works for me?


On Wed, May 24, 2017 at 3:20 PM Matt Sicker <boa...@gmail.com> wrote:

> I mostly work on Log4j2, though I try to answer questions about it on ops4j
> and karaf due to pax-logging.
>
> On 24 May 2017 at 14:17, James Carman <ja...@carmanconsulting.com> wrote:
>
> > I know. ;)  And I meant no slight to you.  I didn't know you were one of
> > the contributors these days.  I have checked out the code and I'm going
> to
> > poke around a bit.
> >
> > On Wed, May 24, 2017 at 3:15 PM Matt Sicker <boa...@gmail.com> wrote:
> >
> > > That would be on the ops4j lists, though that's mostly the same people
> as
> > > here.
> > >
> > > On 24 May 2017 at 13:31, James Carman <ja...@carmanconsulting.com>
> > wrote:
> > >
> > > > I think I must be doing something wrong.  Hopefully one of the PAX
> > folks
> > > > can help here.  I wonder if I should just reach out to them directly
> or
> > > if
> > > > this is a karaf-specific issue with PAX?
> > > >
> > > > On Wed, May 24, 2017 at 2:29 PM Matt Sicker <boa...@gmail.com>
> wrote:
> > > >
> > > > > At compile time, an annotation processor in log4j-core generates a
> > .dat
> > > > > file containing some metadata about scanned plugins. These JAR
> > resource
> > > > > files are loaded at plugin scan time where reflection is used to
> > > > > investigate the classes and instantiate plugins based on config
> > files.
> > > > > Alternatively, there's an option you can set to scan a particular
> > list
> > > of
> > > > > packages for additional plugins, though I think that uses the
> context
> > > > > ClassLoader which might not work properly in your scenario.
> > > > >
> > > > > On 24 May 2017 at 11:22, James Carman <ja...@carmanconsulting.com>
> > > > wrote:
> > > > >
> > > > > > Any advice on how I might be able to fight my way through it?
> How
> > > does
> > > > > > Log4j2 "discover" those @Plugin-annotated classes?  Does it use
> > some
> > > > form
> > > > > > of classpath scanning?  Is it scoped to certain packages only?
> I'm
> > > > > > thinking I might have to attach to the pax-logging-log4j2 bundle
> > as a
> > > > > host
> > > > > > in order to augment its classpath so that it can see my stuff.
> > > > > >
> > > > > > On Wed, May 24, 2017 at 12:20 PM Matt Sicker <boa...@gmail.com>
> > > wrote:
> > > > > >
> > > > > > > It could be a bug in log4j2 itself rather than pax-logging. I
> > > worked
> > > > on
> > > > > > > some OSGi support in log4j2 a while back, and I'm not sure if
> > this
> > > > is a
> > > > > > new
> > > > > > > issue or an existing one.
> > > > > > >
> > > > > > > On 24 May 2017 at 05:43, James Carman <
> > ja...@carmanconsulting.com>
> > > > > > wrote:
> > > > > > >
> > > > > > > > I tried adding pax-logging-service to startup.properties
> (after
> > > > > putting
> > > > > > > it
> > > > > > > > into the system repo) and I still have the issue. So, the
> > > ultimate
> > > > > > issue
> > > > > > > > isn't the fragment host necessarily. My issue is that it
> can't
> > > fine
> > > > > my
> > > > > > > > custom layout class. I've tried using the name from the
> @Plugin
> > > > > > > annotation.
> > > > > > > > I've tried using the fully-qualified class name. Nothing
> seems
> > to
> > > > > work.
> > > > > > > > Here's the declaration of my layout:
> > > > > > > >
> > > > > > > > @Plugin(name = "MyJsonLayout", category = Node.CATEGORY,
> > > > elementType
> > > > > =
> > > > > > > &g

Re: Using Custom Layout for Log4j2 in Karaf 4.1.x...

[James Carman]

I think I must be doing something wrong.  Hopefully one of the PAX folks
can help here.  I wonder if I should just reach out to them directly or if
this is a karaf-specific issue with PAX?

On Wed, May 24, 2017 at 2:29 PM Matt Sicker <boa...@gmail.com> wrote:

> At compile time, an annotation processor in log4j-core generates a .dat
> file containing some metadata about scanned plugins. These JAR resource
> files are loaded at plugin scan time where reflection is used to
> investigate the classes and instantiate plugins based on config files.
> Alternatively, there's an option you can set to scan a particular list of
> packages for additional plugins, though I think that uses the context
> ClassLoader which might not work properly in your scenario.
>
> On 24 May 2017 at 11:22, James Carman <ja...@carmanconsulting.com> wrote:
>
> > Any advice on how I might be able to fight my way through it?  How does
> > Log4j2 "discover" those @Plugin-annotated classes?  Does it use some form
> > of classpath scanning?  Is it scoped to certain packages only?  I'm
> > thinking I might have to attach to the pax-logging-log4j2 bundle as a
> host
> > in order to augment its classpath so that it can see my stuff.
> >
> > On Wed, May 24, 2017 at 12:20 PM Matt Sicker <boa...@gmail.com> wrote:
> >
> > > It could be a bug in log4j2 itself rather than pax-logging. I worked on
> > > some OSGi support in log4j2 a while back, and I'm not sure if this is a
> > new
> > > issue or an existing one.
> > >
> > > On 24 May 2017 at 05:43, James Carman <ja...@carmanconsulting.com>
> > wrote:
> > >
> > > > I tried adding pax-logging-service to startup.properties (after
> putting
> > > it
> > > > into the system repo) and I still have the issue. So, the ultimate
> > issue
> > > > isn't the fragment host necessarily. My issue is that it can't fine
> my
> > > > custom layout class. I've tried using the name from the @Plugin
> > > annotation.
> > > > I've tried using the fully-qualified class name. Nothing seems to
> work.
> > > > Here's the declaration of my layout:
> > > >
> > > > @Plugin(name = "MyJsonLayout", category = Node.CATEGORY, elementType
> =
> > > > Layout.ELEMENT_TYPE, printObject = true)
> > > > public class MyJsonLayout extends AbstractStringLayout {
> > > > ...
> > > > }
> > > >
> > > > and here's what I've changed in the logging config file:
> > > >
> > > > log4j2.rootLogger.appenderRef.RollingFile.ref = RollingFile
> > > > # Rolling file appender
> > > > log4j2.appender.rolling.type = RollingRandomAccessFile
> > > > log4j2.appender.rolling.name = RollingFile
> > > > log4j2.appender.rolling.fileName = ${karaf.home}/log/aetos.log
> > > > log4j2.appender.rolling.filePattern = ${karaf.home}/log/aetos.log.%i
> > > > # uncomment to not force a disk flush
> > > > log4j2.appender.rolling.immediateFlush = false
> > > > log4j2.appender.rolling.append = true
> > > > log4j2.appender.rolling.layout.type =
> com.myco.log4j.json.MyJsonLayout
> > > > log4j2.appender.rolling.policies.type = Policies
> > > > log4j2.appender.rolling.policies.size.type =
> SizeBasedTriggeringPolicy
> > > > log4j2.appender.rolling.policies.size.size = 200MB
> > > >
> > > > As I said, I tried just using layout.type = MyJsonLayout, but that
> > > doesn't
> > > > work either.  Do we have an example where something like this works
> > that
> > > I
> > > > can reverse engineer?
> > > >
> > > > Thanks,
> > > >
> > > > James
> > > >
> > > > On Tue, May 23, 2017 at 7:03 PM James Carman <
> > ja...@carmanconsulting.com
> > > >
> > > > wrote:
> > > >
> > > > > I am trying to use a custom layout and I'm following the examples
> (I
> > > > > think).  We had one that worked in Karaf 3.0.x.  Anyway, I set up
> the
> > > > > fragment host like this:
> > > > >
> > > > > 
> > > > >   org.apache.felix
> > > > >   maven-bundle-plugin
> > > > >   3.3.0
> > > > >   true
> > > > >   true
> > > > >   
> > > > > 
> > > > >
> > > > >
> > >
> org.ops4j.pax.logging.pax-logging-service
> > > > > 
> > > > >   
> > > > > 
> > > > >
> > > > > However, my bundle will not resolve this way. I don't see that
> bundle
> > > > > being loaded in Karaf 4.1.1:
> > > > >  karaf@root()> list -t 0 -s | grep -i log 19:01:18
> > > > >  5 │ Active │ 8 │ 1.9.1 │ org.ops4j.pax.logging.pax-logging-api
> > > > >  6 │ Active │ 8 │ 1.9.1 │ org.ops4j.pax.logging.pax-logging-log4j2
> > > > > 36 │ Active │ 30 │ 4.1.1 │ org.apache.karaf.log.core
> > > > >
> > > > > I tried binding to "org.ops4j.pax.logging.pax-logging-api", but
> that
> > > > > didn't work either.  Did this process change for 4.1.x?
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Matt Sicker <boa...@gmail.com>
> > >
> >
>
>
>
> --
> Matt Sicker <boa...@gmail.com>
>

Re: Using Custom Layout for Log4j2 in Karaf 4.1.x...

[James Carman]

Any advice on how I might be able to fight my way through it?  How does
Log4j2 "discover" those @Plugin-annotated classes?  Does it use some form
of classpath scanning?  Is it scoped to certain packages only?  I'm
thinking I might have to attach to the pax-logging-log4j2 bundle as a host
in order to augment its classpath so that it can see my stuff.

On Wed, May 24, 2017 at 12:20 PM Matt Sicker <boa...@gmail.com> wrote:

> It could be a bug in log4j2 itself rather than pax-logging. I worked on
> some OSGi support in log4j2 a while back, and I'm not sure if this is a new
> issue or an existing one.
>
> On 24 May 2017 at 05:43, James Carman <ja...@carmanconsulting.com> wrote:
>
> > I tried adding pax-logging-service to startup.properties (after putting
> it
> > into the system repo) and I still have the issue. So, the ultimate issue
> > isn't the fragment host necessarily. My issue is that it can't fine my
> > custom layout class. I've tried using the name from the @Plugin
> annotation.
> > I've tried using the fully-qualified class name. Nothing seems to work.
> > Here's the declaration of my layout:
> >
> > @Plugin(name = "MyJsonLayout", category = Node.CATEGORY, elementType =
> > Layout.ELEMENT_TYPE, printObject = true)
> > public class MyJsonLayout extends AbstractStringLayout {
> > ...
> > }
> >
> > and here's what I've changed in the logging config file:
> >
> > log4j2.rootLogger.appenderRef.RollingFile.ref = RollingFile
> > # Rolling file appender
> > log4j2.appender.rolling.type = RollingRandomAccessFile
> > log4j2.appender.rolling.name = RollingFile
> > log4j2.appender.rolling.fileName = ${karaf.home}/log/aetos.log
> > log4j2.appender.rolling.filePattern = ${karaf.home}/log/aetos.log.%i
> > # uncomment to not force a disk flush
> > log4j2.appender.rolling.immediateFlush = false
> > log4j2.appender.rolling.append = true
> > log4j2.appender.rolling.layout.type = com.myco.log4j.json.MyJsonLayout
> > log4j2.appender.rolling.policies.type = Policies
> > log4j2.appender.rolling.policies.size.type = SizeBasedTriggeringPolicy
> > log4j2.appender.rolling.policies.size.size = 200MB
> >
> > As I said, I tried just using layout.type = MyJsonLayout, but that
> doesn't
> > work either.  Do we have an example where something like this works that
> I
> > can reverse engineer?
> >
> > Thanks,
> >
> > James
> >
> > On Tue, May 23, 2017 at 7:03 PM James Carman <ja...@carmanconsulting.com
> >
> > wrote:
> >
> > > I am trying to use a custom layout and I'm following the examples (I
> > > think).  We had one that worked in Karaf 3.0.x.  Anyway, I set up the
> > > fragment host like this:
> > >
> > > 
> > >   org.apache.felix
> > >   maven-bundle-plugin
> > >   3.3.0
> > >   true
> > >   true
> > >   
> > > 
> > >
> > >
> org.ops4j.pax.logging.pax-logging-service
> > > 
> > >   
> > > 
> > >
> > > However, my bundle will not resolve this way. I don't see that bundle
> > > being loaded in Karaf 4.1.1:
> > >  karaf@root()> list -t 0 -s | grep -i log 19:01:18
> > >  5 │ Active │ 8 │ 1.9.1 │ org.ops4j.pax.logging.pax-logging-api
> > >  6 │ Active │ 8 │ 1.9.1 │ org.ops4j.pax.logging.pax-logging-log4j2
> > > 36 │ Active │ 30 │ 4.1.1 │ org.apache.karaf.log.core
> > >
> > > I tried binding to "org.ops4j.pax.logging.pax-logging-api", but that
> > > didn't work either.  Did this process change for 4.1.x?
> > >
> >
>
>
>
> --
> Matt Sicker <boa...@gmail.com>
>

Re: Using Custom Layout for Log4j2 in Karaf 4.1.x...

[James Carman]

I tried adding pax-logging-service to startup.properties (after putting it
into the system repo) and I still have the issue. So, the ultimate issue
isn't the fragment host necessarily. My issue is that it can't fine my
custom layout class. I've tried using the name from the @Plugin annotation.
I've tried using the fully-qualified class name. Nothing seems to work.
Here's the declaration of my layout:

@Plugin(name = "MyJsonLayout", category = Node.CATEGORY, elementType =
Layout.ELEMENT_TYPE, printObject = true)
public class MyJsonLayout extends AbstractStringLayout {
...
}

and here's what I've changed in the logging config file:

log4j2.rootLogger.appenderRef.RollingFile.ref = RollingFile
# Rolling file appender
log4j2.appender.rolling.type = RollingRandomAccessFile
log4j2.appender.rolling.name = RollingFile
log4j2.appender.rolling.fileName = ${karaf.home}/log/aetos.log
log4j2.appender.rolling.filePattern = ${karaf.home}/log/aetos.log.%i
# uncomment to not force a disk flush
log4j2.appender.rolling.immediateFlush = false
log4j2.appender.rolling.append = true
log4j2.appender.rolling.layout.type = com.myco.log4j.json.MyJsonLayout
log4j2.appender.rolling.policies.type = Policies
log4j2.appender.rolling.policies.size.type = SizeBasedTriggeringPolicy
log4j2.appender.rolling.policies.size.size = 200MB

As I said, I tried just using layout.type = MyJsonLayout, but that doesn't
work either.  Do we have an example where something like this works that I
can reverse engineer?

Thanks,

James

On Tue, May 23, 2017 at 7:03 PM James Carman <ja...@carmanconsulting.com>
wrote:

> I am trying to use a custom layout and I'm following the examples (I
> think).  We had one that worked in Karaf 3.0.x.  Anyway, I set up the
> fragment host like this:
>
> 
>   org.apache.felix
>   maven-bundle-plugin
>   3.3.0
>   true
>   true
>   
> 
>
> org.ops4j.pax.logging.pax-logging-service
> 
>   
> 
>
> However, my bundle will not resolve this way. I don't see that bundle
> being loaded in Karaf 4.1.1:
>  karaf@root()> list -t 0 -s | grep -i log 19:01:18
>  5 │ Active │ 8 │ 1.9.1 │ org.ops4j.pax.logging.pax-logging-api
>  6 │ Active │ 8 │ 1.9.1 │ org.ops4j.pax.logging.pax-logging-log4j2
> 36 │ Active │ 30 │ 4.1.1 │ org.apache.karaf.log.core
>
> I tried binding to "org.ops4j.pax.logging.pax-logging-api", but that
> didn't work either.  Did this process change for 4.1.x?
>

Using Custom Layout for Log4j2 in Karaf 4.1.x...

[James Carman]

I am trying to use a custom layout and I'm following the examples (I
think).  We had one that worked in Karaf 3.0.x.  Anyway, I set up the
fragment host like this:


  org.apache.felix
  maven-bundle-plugin
  3.3.0
  true
  true
  


org.ops4j.pax.logging.pax-logging-service

  


However, my bundle will not resolve this way. I don't see that bundle being
loaded in Karaf 4.1.1:
 karaf@root()> list -t 0 -s | grep -i log 19:01:18
 5 │ Active │ 8 │ 1.9.1 │ org.ops4j.pax.logging.pax-logging-api
 6 │ Active │ 8 │ 1.9.1 │ org.ops4j.pax.logging.pax-logging-log4j2
36 │ Active │ 30 │ 4.1.1 │ org.apache.karaf.log.core

I tried binding to "org.ops4j.pax.logging.pax-logging-api", but that didn't
work either.  Did this process change for 4.1.x?

Hitting up arrow while command is running not working...

[James Carman]

First of all, yes, I'm impatient! :)  Anyway, I used to be able to hit the
up arrow while a command was executing (say feature:install or something)
so that I could bring up the next command I was going to run.  Now, it just
starts printing "[A[A[A" characters to the console.  Is there some way to
resurrect the old behavior.  I'm using 4.1.1.

Re: Generating custom assembly including "disruptor" in startup.properties ...

[James Carman]

Renaming subject.  By the way, I tried adding disruptor as a compile-scoped
dependency (after looking at the AssemblyMojo code) and it appears to do
the same thing.

On Thu, May 18, 2017 at 12:24 PM James Carman <ja...@carmanconsulting.com>
wrote:

> I'm trying to automatically enable asynchronous logging by default and the
> config file says:
>
> # uncomment to use asynchronous loggers, which require
> mvn:com.lmax/disruptor/3.3.2 library
> log4j2.rootLogger.type = asyncRoot
>
>
> So, I uncommented it (as you can see), but "disruptor" isn't visible at
> boot time, because it's not in the startup.properties. So, I figured I'd
> try to add it:
>
> 
>   mvn:com.lmax/disruptor/3.3.2
> 
>
> Now, I get a funky features.cfg file:
>
> #
> # Comma separated list of features repositories to register by default
> #
> featuresRepositories =
> file:${karaf.home}/etc/8dbd154a-fce6-435a-a7cd-67dc546b2ddf.xml
>
> #
> # Comma separated list of features to install at startup
> #
> featuresBoot = 9088a7fb-b327-44eb-ba3f-24382526981b
>
> With a new feature repository file in etc:
>
> 
> http://karaf.apache.org/xmlns/features/v1.4.0;
> name="8dbd154a-fce6-435a-a7cd-67dc546b2ddf">
>
> mvn:org.apache.karaf.features/framework/4.1.1/xml/features
>
> mvn:org.apache.karaf.features/spring/4.1.1/xml/features
>
> mvn:org.apache.karaf.features/standard/4.1.1/xml/features
>
> mvn:org.apache.karaf.features/enterprise/4.1.1/xml/features
>
> mvn:org.apache.cxf.karaf/apache-cxf/3.1.11/xml/features
>
> mvn:org.apache.camel.karaf/apache-camel/2.19.0/xml/features
>
> mvn:org.apache.activemq/activemq-karaf/5.14.5/xml/features
>
> mvn:com.savoirtech.aetos/features/4.1.1.0-SNAPSHOT/xml/features
> 
>  dependency="false">framework
>  dependency="false">aries-blueprint
> bundle
> config
> deployer
>  dependency="false">diagnostic
> feature
> instance
> jaas
> kar
> log
>  dependency="false">management
> package
> service
> shell
>  dependency="false">shell-compat
> ssh
> system
> wrap
>  dependency="false">aetos-core
> mvn:com.lmax/disruptor/3.3.2
> 
> 
>
> Notice it added "disruptor" to the bottom of that feature.  However, I
> didn't want it in a boot feature.  I wanted it in the startup.properties,
> so let's take a look there:
>
> # Bundles to be started on startup, with startlevel
> mvn\:org.apache.karaf.features/org.apache.karaf.features.extension/4.1.1 =
> 1
> mvn\:org.ops4j.pax.url/pax-url-aether/2.5.2 = 5
> mvn\:org.ops4j.pax.logging/pax-logging-api/1.9.1 = 8
> mvn\:org.ops4j.pax.logging/pax-logging-log4j2/1.9.1 = 8
> mvn\:org.apache.felix/org.apache.felix.configadmin/1.8.14 = 10
> mvn\:org.apache.felix/org.apache.felix.fileinstall/3.5.8 = 11
> mvn\:org.apache.karaf.features/org.apache.karaf.features.core/4.1.1 = 15
> mvn\:com.lmax/disruptor/3.3.2 = 50
>
> It added it!  So, why is it adding it in both places?  Everything seems to
> start up just fine in this case, but I really don't like this crazy
> auto-generated features file.  Is there a way to avoid it and just add that
> bundle to startup.properties?
>
> Thanks,
>
> James
>

Generating custom bundle including "disruptor" in startup.properties...

[James Carman]

I'm trying to automatically enable asynchronous logging by default and the
config file says:

# uncomment to use asynchronous loggers, which require
mvn:com.lmax/disruptor/3.3.2 library
log4j2.rootLogger.type = asyncRoot


So, I uncommented it (as you can see), but "disruptor" isn't visible at
boot time, because it's not in the startup.properties. So, I figured I'd
try to add it:


  mvn:com.lmax/disruptor/3.3.2


Now, I get a funky features.cfg file:

#
# Comma separated list of features repositories to register by default
#
featuresRepositories =
file:${karaf.home}/etc/8dbd154a-fce6-435a-a7cd-67dc546b2ddf.xml

#
# Comma separated list of features to install at startup
#
featuresBoot = 9088a7fb-b327-44eb-ba3f-24382526981b

With a new feature repository file in etc:


http://karaf.apache.org/xmlns/features/v1.4.0;
name="8dbd154a-fce6-435a-a7cd-67dc546b2ddf">

mvn:org.apache.karaf.features/framework/4.1.1/xml/features

mvn:org.apache.karaf.features/spring/4.1.1/xml/features

mvn:org.apache.karaf.features/standard/4.1.1/xml/features

mvn:org.apache.karaf.features/enterprise/4.1.1/xml/features

mvn:org.apache.cxf.karaf/apache-cxf/3.1.11/xml/features

mvn:org.apache.camel.karaf/apache-camel/2.19.0/xml/features

mvn:org.apache.activemq/activemq-karaf/5.14.5/xml/features

mvn:com.savoirtech.aetos/features/4.1.1.0-SNAPSHOT/xml/features

framework
aries-blueprint
bundle
config
deployer
diagnostic
feature
instance
jaas
kar
log
management
package
service
shell
shell-compat
ssh
system
wrap
aetos-core
mvn:com.lmax/disruptor/3.3.2



Notice it added "disruptor" to the bottom of that feature.  However, I
didn't want it in a boot feature.  I wanted it in the startup.properties,
so let's take a look there:

# Bundles to be started on startup, with startlevel
mvn\:org.apache.karaf.features/org.apache.karaf.features.extension/4.1.1 = 1
mvn\:org.ops4j.pax.url/pax-url-aether/2.5.2 = 5
mvn\:org.ops4j.pax.logging/pax-logging-api/1.9.1 = 8
mvn\:org.ops4j.pax.logging/pax-logging-log4j2/1.9.1 = 8
mvn\:org.apache.felix/org.apache.felix.configadmin/1.8.14 = 10
mvn\:org.apache.felix/org.apache.felix.fileinstall/3.5.8 = 11
mvn\:org.apache.karaf.features/org.apache.karaf.features.core/4.1.1 = 15
mvn\:com.lmax/disruptor/3.3.2 = 50

It added it!  So, why is it adding it in both places?  Everything seems to
start up just fine in this case, but I really don't like this crazy
auto-generated features file.  Is there a way to avoid it and just add that
bundle to startup.properties?

Thanks,

James

Re: JB off for 2 weeks

[James Carman]

Well, I'm sure someone can jump in and help so that you can enjoy your time
off if need be.  Have a great time!  You deserve some R!

On Thu, Feb 2, 2017 at 9:28 AM Jean-Baptiste Onofré <j...@nanthrax.net> wrote:

> Hi James,
>
> I think we are pretty good for the release. As soon as the vote period
> is complete and we have 3 binding votes, I will promote the artifacts,
> and update Jira. I will do that, no worries.
>
> If (for any reason), I'm not able to do it from the hotel, I will let
> you know.
>
> Thanks,
> Regards
> JB
>
> On 02/02/2017 03:25 PM, James Carman wrote:
> > What blood type are you in case we need to donate to get you back in
> shape
> > in two weeks? ;). Have a great vacation.  Is there anything any of us can
> > do to help with the release stuff so you can continue with the tequila
> > without distractions?
> >
> > On Thu, Feb 2, 2017 at 9:20 AM Jean-Baptiste Onofré <j...@nanthrax.net>
> wrote:
> >
> >> Hi guys,
> >>
> >> I'm in vacation tonight for 2 weeks.
> >>
> >> I will have access to my e-mail and I will complete the 4.1.0 release.
> >>
> >> However, I can have some delay in my replies depending the tequila I
> >> will have in my blood ;)
> >>
> >> See you soon guys !
> >> Regards
> >> JB
> >> --
> >> Jean-Baptiste Onofré
> >> jbono...@apache.org
> >> http://blog.nanthrax.net
> >> Talend - http://www.talend.com
> >>
> >
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>

Re: JB off for 2 weeks

[James Carman]

What blood type are you in case we need to donate to get you back in shape
in two weeks? ;). Have a great vacation.  Is there anything any of us can
do to help with the release stuff so you can continue with the tequila
without distractions?

On Thu, Feb 2, 2017 at 9:20 AM Jean-Baptiste Onofré  wrote:

> Hi guys,
>
> I'm in vacation tonight for 2 weeks.
>
> I will have access to my e-mail and I will complete the 4.1.0 release.
>
> However, I can have some delay in my replies depending the tequila I
> will have in my blood ;)
>
> See you soon guys !
> Regards
> JB
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>

Re: [HEADS UP] Karaf Container 4.0.8 today

[James Carman]

Well, what are you waiting for! ;) My bad, I thought it was already there.
Never mind me! :)


On Mon, Dec 12, 2016 at 11:05 AM Jean-Baptiste Onofré <j...@nanthrax.net>
wrote:

> Correct, but the fix is not yet there ;)
>
> Regards
> JB
>
> On 12/12/2016 04:24 PM, James Carman wrote:
> > You can run the SNAPSHOT to try it out, right?
> >
> >
> https://repository.apache.org/content/groups/snapshots/org/apache/karaf/apache-karaf/4.0.8-SNAPSHOT/
> >
> >
> > On Mon, Dec 12, 2016 at 9:56 AM Kai Kreuzer <k...@openhab.org> wrote:
> >
> >> Hi JB,
> >>
> >> Sounds great - are you confident enough that the ARM support fix will be
> >> successful this time or shall we do a quick test before you do the
> release
> >> (assuming you are still lacking the hardware to test)? If so, please
> drop a
> >> note!
> >>
> >> Regards,
> >> Kai
> >>
> >>
> >>
> >> --
> >> View this message in context:
> >>
> http://karaf.922171.n3.nabble.com/HEADS-UP-Karaf-Container-4-0-8-today-tp4048976p4048981.html
> >> Sent from the Karaf - Dev mailing list archive at Nabble.com.
> >>
> >
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>

Re: [HEADS UP] Karaf Container 4.0.8 today

[James Carman]

You can run the SNAPSHOT to try it out, right?

https://repository.apache.org/content/groups/snapshots/org/apache/karaf/apache-karaf/4.0.8-SNAPSHOT/


On Mon, Dec 12, 2016 at 9:56 AM Kai Kreuzer  wrote:

> Hi JB,
>
> Sounds great - are you confident enough that the ARM support fix will be
> successful this time or shall we do a quick test before you do the release
> (assuming you are still lacking the hardware to test)? If so, please drop a
> note!
>
> Regards,
> Kai
>
>
>
> --
> View this message in context:
> http://karaf.922171.n3.nabble.com/HEADS-UP-Karaf-Container-4-0-8-today-tp4048976p4048981.html
> Sent from the Karaf - Dev mailing list archive at Nabble.com.
>

Re: [ANNOUNCE] Introducing Microbule...

[James Carman]

FYI, Microbule has now moved:

https://microbule.github.io/microbule/



On Mon, Nov 21, 2016 at 1:03 PM James Carman <ja...@carmanconsulting.com>
wrote:

> We've been working on a Microservices framework called "Microbule" which
> leverages CXF and Karaf (hence the cross-post):
>
> https://github.com/jwcarman/microbule
>
> The idea is to make writing Microservices easy and fun, by providing many
> of the oft-requested features for you out-of-the-box (CORS, Caching, JSON
> transformation, validation, etc.).  There's a README page that explains how
> to install/run Microbule in Karaf and how to write your own services.  If
> you're interested, take it for a spin and let us know what you think.
>
> Thanks,
>
> James
>

Re: [DISCUSS] Predictable Boot Feature Startup Order...

[James Carman]

Guillaume, I like what you did there, using the wiring to help you decide
what depends on what to control the order!  This is the type of thing I'm
looking for.  We should try to put dependencies first, if possible in the
ordering.  This allows folks to be more wishy-washy when writing features,
so they don't have to worry about ordering, which I like.  I put a comment
on the issue.  I'm going to try cloning your repo and using your branch to
build Karaf, then installing Microbule (if you don't get to it before me)
to see if it solves my issue I'm seeing.

The only thing I'm wondering is how this plays out in a situation where
multiple bundles can satisfy the same requirement.  Let's take, for
example, two bundles:

A imports package com.foo versions [1.0.0,2.0.0)
B imports package com.foo versions [1.1.0,2.2.0)

Now, A uses B and com.foo is exposed on the public API of B, so they need
to be on the same page.  Let's assume we have two bundles D1 and D2 which
export the com.foo package with versions 1.0.0 and 1.1.0 respectively.
Suppose we have a feature "feature-a" which installs A and D1 (since that's
the version it needs) and we have "feature-b" which installs "feature-a"
and D2 (because that's what it needs).  It would be great if both A and B
are wired to D2, since it's the greater version of com.foo and satisfies
both needs.  However, when installing "feature-a", you might not even know
that D2 is going to be available.  Perhaps I'm misunderstanding how all
this wiring mumbojumbo works, but could this cause issues?  If so, is there
any way to address it?  Should we even try to address it, or would we just
say "you're doing it wrong, dummy"?

On Fri, Nov 18, 2016 at 3:33 PM Guillaume Nodet <gno...@apache.org> wrote:

> I've raised KARAF-4825 with a proposal for a fix, let me know what you
> think.
>
> 2016-11-18 17:41 GMT+01:00 James Carman <ja...@carmanconsulting.com>:
>
> > This was when using the features:install after getting into the console.
> > It really seems funny that it would pick that install order.  Seems very
> > counter-intuitive.  Perhaps there's some room for improvement here.
> >
> > On Fri, Nov 18, 2016 at 11:39 AM Guillaume Nodet <gno...@apache.org>
> > wrote:
> >
> > > The resolver gives a list of bundles without any particular order.
> Karaf
> > > just sort them in alphabetic order, so "core" < "spi".
> > > We could sort them based on the wiring so that importers come after
> > > exporters (keeping in mind we need to get a list out of a graph).
> > > Note than this is no effect at all at the time the features are
> installed
> > >  because the wiring is imposed to the framework.  If the problem you
> saw
> > > was mainly during a subsequent reboot, then that's the one I fixed in
> > 4.1.
> > > The bundle used to fix the problem is actually not much tied to karaf
> and
> > > could be reused in 3.x I think.
> > >
> > > 2016-11-18 17:33 GMT+01:00 James Carman <ja...@carmanconsulting.com>:
> > >
> > > > Another issue I'm seeing with 4.0.7 right now is that the install
> order
> > > > doesn't really seem to make sense.  For example, I've got a "core"
> > bundle
> > > > that requires the "spi" (service provider/plugin interfaces) bundle.
> > My
> > > > feature lists the "spi" bundle before the "core" bundle, but for some
> > > > reason, Karaf is installing "core" first and then installing "spi"
> much
> > > > later.  Is that expected behavior?  It seems strange to me.
> > > >
> > > > On Fri, Nov 18, 2016 at 11:30 AM James Carman <
> > > ja...@carmanconsulting.com>
> > > > wrote:
> > > >
> > > > > The main issue I faced was when different features install
> different
> > > > > versions of the same bundle (my particular problem child was GSON I
> > > > think).
> > > > >   The main issue that we saw was when the lower version
> > > installed/started
> > > > > earlier than the higher version.  So, some bundles would bind to
> the
> > > > lower
> > > > > version and later bundles which require a higher minor version,
> would
> > > > bind
> > > > > to the higher version.  Hopefully that makes sense :)
> > > > >
> > > > >
> > > > > On Fri, Nov 18, 2016 at 11:23 AM Guillaume Nodet <
> gno...@apache.org>
> > > > > wrote:
> > > > >
> > > > > Here's the  3.x code
> 

Re: [ANNOUNCE] Introducing Microbule...

[James Carman]

Small update.  Microbule 0.1.0 release has been cut and will soon be
available in Maven Central (awaiting sync from Nexus OSS).  Enjoy, folks!

On Mon, Nov 21, 2016 at 1:03 PM James Carman <ja...@carmanconsulting.com>
wrote:

> We've been working on a Microservices framework called "Microbule" which
> leverages CXF and Karaf (hence the cross-post):
>
> https://github.com/jwcarman/microbule
>
> The idea is to make writing Microservices easy and fun, by providing many
> of the oft-requested features for you out-of-the-box (CORS, Caching, JSON
> transformation, validation, etc.).  There's a README page that explains how
> to install/run Microbule in Karaf and how to write your own services.  If
> you're interested, take it for a spin and let us know what you think.
>
> Thanks,
>
> James
>

Re: [ANNOUNCE] Introducing Microbule...

[James Carman]

Very cool, Mark!  I will check it out.  Looks like it's focusing on Tomcat
mostly at first glance.  Is that right?

On Mon, Nov 21, 2016 at 4:49 PM Mark Struberg <strub...@yahoo.de> wrote:

> https://svn.apache.org/repos/asf/openwebbeans/meecrowave/trunk/
>
>
> Currently you need to manually compile the CXF 3.1.x-fixes branch first.
>
>
> Usage: just write an Appliaction and @ApplicationScoped @Path bean and add
> the meecrowave-maven-plugin
>
> 
> 
> 
> org.apache.meecrowave
> meecrowave-maven-plugin
> ${meecrowave.version}
> 
> 
> 
>
> Then start with
>
> $> mvn clean install meecrowave:run
>
> Will push a sample project soon.
>
> LieGrue,
> strub
>
> > Am 21.11.2016 um 22:41 schrieb James Carman <ja...@carmanconsulting.com
> >:
> >
> > I couldn't find anything on Meecrowave, but I would be interested in
> seeing the code.  Where does it live?  I tried googling
> >
> > On Mon, Nov 21, 2016 at 4:39 PM Sergey Beryozkin <sberyoz...@gmail.com>
> wrote:
> > Hi James
> >
> > Looks very promising, and I found the answer to the question I was about
> > to ask in a "What's in a Name" section at the end :-)
> >
> > Microbule, Meecrowave - the massive wave is coming :-)
> >
> > Cheers, Sergey
> >
> >
> > On 21/11/16 18:11, James Carman wrote:
> > > The header names are configurable, so you can use whatever you want.
> You
> > > just need to set up an etc/org.microbule.decorator.tracer.cfg file:
> > >
> > > traceIdHeader=My-Trace-ID
> > > requestIdHeader=My-Request-ID
> > >
> > >
> > >
> > > On Mon, Nov 21, 2016 at 1:09 PM Romain Manni-Bucau <
> rmannibu...@gmail.com>
> > > wrote:
> > >
> > >> Hi James,
> > >>
> > >> Would it be an option to extract the tracer - at least the names of
> the
> > >> headers - to a "portable" module? With Mark we were on that area as
> well
> > >> for meecrowave (a microprofile server based on CXF too and hosted
> > >> @openwebbeans) and was thinking to add it to sirona since it is the
> > >> monitoring related ASF project. Would be great to make the
> names/format
> > >> uniform accross impl otherwise inteoperability is hard and this
> feature
> > >> loose some of its strength.
> > >>
> > >> wdyt?
> > >>
> > >> PS: sure we can share more but this would at least enable a
> > >> microbule-meecrowave cluster to speak the same language ;)
> > >>
> > >>
> > >>
> > >> Romain Manni-Bucau
> > >> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > >> <https://blog-rmannibucau.rhcloud.com> | Old Blog
> > >> <http://rmannibucau.wordpress.com> | Github <
> > >> https://github.com/rmannibucau> |
> > >> LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> > >> <https://javaeefactory-rmannibucau.rhcloud.com>
> > >>
> > >> 2016-11-21 19:03 GMT+01:00 James Carman <ja...@carmanconsulting.com>:
> > >>
> > >>> We've been working on a Microservices framework called "Microbule"
> which
> > >>> leverages CXF and Karaf (hence the cross-post):
> > >>>
> > >>> https://github.com/jwcarman/microbule
> > >>>
> > >>> The idea is to make writing Microservices easy and fun, by providing
> many
> > >>> of the oft-requested features for you out-of-the-box (CORS, Caching,
> JSON
> > >>> transformation, validation, etc.).  There's a README page that
> explains
> > >> how
> > >>> to install/run Microbule in Karaf and how to write your own
> services.  If
> > >>> you're interested, take it for a spin and let us know what you think.
> > >>>
> > >>> Thanks,
> > >>>
> > >>> James
> > >>>
> > >>
> > >
> >
>
>

Re: [ANNOUNCE] Introducing Microbule...

[James Carman]

I couldn't find anything on Meecrowave, but I would be interested in seeing
the code. Where does it live? I tried googling

On Mon, Nov 21, 2016 at 4:39 PM Sergey Beryozkin <sberyoz...@gmail.com>
wrote:

> Hi James
>
> Looks very promising, and I found the answer to the question I was about
> to ask in a "What's in a Name" section at the end :-)
>
> Microbule, Meecrowave - the massive wave is coming :-)
>
> Cheers, Sergey
>
>
> On 21/11/16 18:11, James Carman wrote:
> > The header names are configurable, so you can use whatever you want.  You
> > just need to set up an etc/org.microbule.decorator.tracer.cfg file:
> >
> > traceIdHeader=My-Trace-ID
> > requestIdHeader=My-Request-ID
> >
> >
> >
> > On Mon, Nov 21, 2016 at 1:09 PM Romain Manni-Bucau <
> rmannibu...@gmail.com>
> > wrote:
> >
> >> Hi James,
> >>
> >> Would it be an option to extract the tracer - at least the names of the
> >> headers - to a "portable" module? With Mark we were on that area as well
> >> for meecrowave (a microprofile server based on CXF too and hosted
> >> @openwebbeans) and was thinking to add it to sirona since it is the
> >> monitoring related ASF project. Would be great to make the names/format
> >> uniform accross impl otherwise inteoperability is hard and this feature
> >> loose some of its strength.
> >>
> >> wdyt?
> >>
> >> PS: sure we can share more but this would at least enable a
> >> microbule-meecrowave cluster to speak the same language ;)
> >>
> >>
> >>
> >> Romain Manni-Bucau
> >> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> >> <https://blog-rmannibucau.rhcloud.com> | Old Blog
> >> <http://rmannibucau.wordpress.com> | Github <
> >> https://github.com/rmannibucau> |
> >> LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> >> <https://javaeefactory-rmannibucau.rhcloud.com>
> >>
> >> 2016-11-21 19:03 GMT+01:00 James Carman <ja...@carmanconsulting.com>:
> >>
> >>> We've been working on a Microservices framework called "Microbule"
> which
> >>> leverages CXF and Karaf (hence the cross-post):
> >>>
> >>> https://github.com/jwcarman/microbule
> >>>
> >>> The idea is to make writing Microservices easy and fun, by providing
> many
> >>> of the oft-requested features for you out-of-the-box (CORS, Caching,
> JSON
> >>> transformation, validation, etc.).  There's a README page that explains
> >> how
> >>> to install/run Microbule in Karaf and how to write your own services.
> If
> >>> you're interested, take it for a spin and let us know what you think.
> >>>
> >>> Thanks,
> >>>
> >>> James
> >>>
> >>
> >
>
>

Re: [ANNOUNCE] Introducing Microbule...

[James Carman]

By the way, I should give credit to Benson Margulies for giving me the
"secret sauce" of creating CXF servers on-the-fly!  Thanks, Benson!


On Mon, Nov 21, 2016 at 1:03 PM James Carman <ja...@carmanconsulting.com>
wrote:

> We've been working on a Microservices framework called "Microbule" which
> leverages CXF and Karaf (hence the cross-post):
>
> https://github.com/jwcarman/microbule
>
> The idea is to make writing Microservices easy and fun, by providing many
> of the oft-requested features for you out-of-the-box (CORS, Caching, JSON
> transformation, validation, etc.).  There's a README page that explains how
> to install/run Microbule in Karaf and how to write your own services.  If
> you're interested, take it for a spin and let us know what you think.
>
> Thanks,
>
> James
>

Re: [ANNOUNCE] Introducing Microbule...

[James Carman]

The header names are configurable, so you can use whatever you want.  You
just need to set up an etc/org.microbule.decorator.tracer.cfg file:

traceIdHeader=My-Trace-ID
requestIdHeader=My-Request-ID



On Mon, Nov 21, 2016 at 1:09 PM Romain Manni-Bucau <rmannibu...@gmail.com>
wrote:

> Hi James,
>
> Would it be an option to extract the tracer - at least the names of the
> headers - to a "portable" module? With Mark we were on that area as well
> for meecrowave (a microprofile server based on CXF too and hosted
> @openwebbeans) and was thinking to add it to sirona since it is the
> monitoring related ASF project. Would be great to make the names/format
> uniform accross impl otherwise inteoperability is hard and this feature
> loose some of its strength.
>
> wdyt?
>
> PS: sure we can share more but this would at least enable a
> microbule-meecrowave cluster to speak the same language ;)
>
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://blog-rmannibucau.rhcloud.com> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> <https://javaeefactory-rmannibucau.rhcloud.com>
>
> 2016-11-21 19:03 GMT+01:00 James Carman <ja...@carmanconsulting.com>:
>
> > We've been working on a Microservices framework called "Microbule" which
> > leverages CXF and Karaf (hence the cross-post):
> >
> > https://github.com/jwcarman/microbule
> >
> > The idea is to make writing Microservices easy and fun, by providing many
> > of the oft-requested features for you out-of-the-box (CORS, Caching, JSON
> > transformation, validation, etc.).  There's a README page that explains
> how
> > to install/run Microbule in Karaf and how to write your own services.  If
> > you're interested, take it for a spin and let us know what you think.
> >
> > Thanks,
> >
> > James
> >
>

[ANNOUNCE] Introducing Microbule...

[James Carman]

We've been working on a Microservices framework called "Microbule" which
leverages CXF and Karaf (hence the cross-post):

https://github.com/jwcarman/microbule

The idea is to make writing Microservices easy and fun, by providing many
of the oft-requested features for you out-of-the-box (CORS, Caching, JSON
transformation, validation, etc.).  There's a README page that explains how
to install/run Microbule in Karaf and how to write your own services.  If
you're interested, take it for a spin and let us know what you think.

Thanks,

James

Re: [DISCUSS] Predictable Boot Feature Startup Order...

[James Carman]

Oh, cool!  Thanks, Guillaume!  I'll take a look when I get some cycles
(hopefully soon).


On Fri, Nov 18, 2016 at 3:33 PM Guillaume Nodet <gno...@apache.org> wrote:

> I've raised KARAF-4825 with a proposal for a fix, let me know what you
> think.
>
> 2016-11-18 17:41 GMT+01:00 James Carman <ja...@carmanconsulting.com>:
>
> > This was when using the features:install after getting into the console.
> > It really seems funny that it would pick that install order.  Seems very
> > counter-intuitive.  Perhaps there's some room for improvement here.
> >
> > On Fri, Nov 18, 2016 at 11:39 AM Guillaume Nodet <gno...@apache.org>
> > wrote:
> >
> > > The resolver gives a list of bundles without any particular order.
> Karaf
> > > just sort them in alphabetic order, so "core" < "spi".
> > > We could sort them based on the wiring so that importers come after
> > > exporters (keeping in mind we need to get a list out of a graph).
> > > Note than this is no effect at all at the time the features are
> installed
> > >  because the wiring is imposed to the framework.  If the problem you
> saw
> > > was mainly during a subsequent reboot, then that's the one I fixed in
> > 4.1.
> > > The bundle used to fix the problem is actually not much tied to karaf
> and
> > > could be reused in 3.x I think.
> > >
> > > 2016-11-18 17:33 GMT+01:00 James Carman <ja...@carmanconsulting.com>:
> > >
> > > > Another issue I'm seeing with 4.0.7 right now is that the install
> order
> > > > doesn't really seem to make sense.  For example, I've got a "core"
> > bundle
> > > > that requires the "spi" (service provider/plugin interfaces) bundle.
> > My
> > > > feature lists the "spi" bundle before the "core" bundle, but for some
> > > > reason, Karaf is installing "core" first and then installing "spi"
> much
> > > > later.  Is that expected behavior?  It seems strange to me.
> > > >
> > > > On Fri, Nov 18, 2016 at 11:30 AM James Carman <
> > > ja...@carmanconsulting.com>
> > > > wrote:
> > > >
> > > > > The main issue I faced was when different features install
> different
> > > > > versions of the same bundle (my particular problem child was GSON I
> > > > think).
> > > > >   The main issue that we saw was when the lower version
> > > installed/started
> > > > > earlier than the higher version.  So, some bundles would bind to
> the
> > > > lower
> > > > > version and later bundles which require a higher minor version,
> would
> > > > bind
> > > > > to the higher version.  Hopefully that makes sense :)
> > > > >
> > > > >
> > > > > On Fri, Nov 18, 2016 at 11:23 AM Guillaume Nodet <
> gno...@apache.org>
> > > > > wrote:
> > > > >
> > > > > Here's the  3.x code
> > > > > for (Set features : stagedFeatures) {
> > > > > features.removeAll(installedFeatures);
> > > > > featuresService.installFeatures(features,
> > > > > EnumSet.of(Option.NoAutoRefreshBundles, Option.NoCleanIfFailure,
> > > > > Option.ContinueBatchOnFailure));
> > > > > }
> > > > >
> > > > > The 3.x features service will install the features one by one in a
> > > given
> > > > > set however.
> > > > > The difference may come from the Option.NoAutoRefreshBundles, but
> > > that's
> > > > > the benefit of using the osgi resolver, i.e. the features are
> > > considered
> > > > as
> > > > > a whole ;-)
> > > > >
> > > > > Just to refresh my memory, what's the actual use case : is it a
> > bundle
> > > > > startup order or a bundle installation order (which has an impact
> on
> > > > > resolution when choosing between the same package exported by
> > multiple
> > > > > bundles).
> > > > > Note that the bundle startup order will be different when
> rebooting,
> > > > > whereas when using a single stage, the order should be the same.
> If
> > > the
> > > > > problem is a wiring problem because you have packages exported by
> > > > multiple
> > >

Re: [DISCUSS] Predictable Boot Feature Startup Order...

[James Carman]

This was when using the features:install after getting into the console.
It really seems funny that it would pick that install order.  Seems very
counter-intuitive.  Perhaps there's some room for improvement here.

On Fri, Nov 18, 2016 at 11:39 AM Guillaume Nodet <gno...@apache.org> wrote:

> The resolver gives a list of bundles without any particular order.  Karaf
> just sort them in alphabetic order, so "core" < "spi".
> We could sort them based on the wiring so that importers come after
> exporters (keeping in mind we need to get a list out of a graph).
> Note than this is no effect at all at the time the features are installed
>  because the wiring is imposed to the framework.  If the problem you  saw
> was mainly during a subsequent reboot, then that's the one I fixed in 4.1.
> The bundle used to fix the problem is actually not much tied to karaf and
> could be reused in 3.x I think.
>
> 2016-11-18 17:33 GMT+01:00 James Carman <ja...@carmanconsulting.com>:
>
> > Another issue I'm seeing with 4.0.7 right now is that the install order
> > doesn't really seem to make sense.  For example, I've got a "core" bundle
> > that requires the "spi" (service provider/plugin interfaces) bundle.  My
> > feature lists the "spi" bundle before the "core" bundle, but for some
> > reason, Karaf is installing "core" first and then installing "spi" much
> > later.  Is that expected behavior?  It seems strange to me.
> >
> > On Fri, Nov 18, 2016 at 11:30 AM James Carman <
> ja...@carmanconsulting.com>
> > wrote:
> >
> > > The main issue I faced was when different features install different
> > > versions of the same bundle (my particular problem child was GSON I
> > think).
> > >   The main issue that we saw was when the lower version
> installed/started
> > > earlier than the higher version.  So, some bundles would bind to the
> > lower
> > > version and later bundles which require a higher minor version, would
> > bind
> > > to the higher version.  Hopefully that makes sense :)
> > >
> > >
> > > On Fri, Nov 18, 2016 at 11:23 AM Guillaume Nodet <gno...@apache.org>
> > > wrote:
> > >
> > > Here's the  3.x code
> > > for (Set features : stagedFeatures) {
> > > features.removeAll(installedFeatures);
> > > featuresService.installFeatures(features,
> > > EnumSet.of(Option.NoAutoRefreshBundles, Option.NoCleanIfFailure,
> > > Option.ContinueBatchOnFailure));
> > > }
> > >
> > > The 3.x features service will install the features one by one in a
> given
> > > set however.
> > > The difference may come from the Option.NoAutoRefreshBundles, but
> that's
> > > the benefit of using the osgi resolver, i.e. the features are
> considered
> > as
> > > a whole ;-)
> > >
> > > Just to refresh my memory, what's the actual use case : is it a bundle
> > > startup order or a bundle installation order (which has an impact on
> > > resolution when choosing between the same package exported by multiple
> > > bundles).
> > > Note that the bundle startup order will be different when rebooting,
> > > whereas when using a single stage, the order should be the same.  If
> the
> > > problem is a wiring problem because you have packages exported by
> > multiple
> > > bundles, I've tried to fix some of this problem in 4.1 by ensuring that
> > the
> > > same wiring is reused after a reboot.
> > >
> > > 2016-11-18 17:13 GMT+01:00 James Carman <ja...@carmanconsulting.com>:
> > >
> > > > I know.  I looked at the code.  That's why I was surprised when I had
> > > > issues when trying it that way.  It could be I'm doing something
> > strange
> > > > with CXF, but it works in a non-staged setup.  If I get some cycles,
> > > > perhaps I can try it again and record the error.
> > > >
> > > >
> > > > On Fri, Nov 18, 2016 at 11:11 AM Guillaume Nodet <gno...@apache.org>
> > > > wrote:
> > > >
> > > > > Using staged features with one feature per set will have the exact
> > same
> > > > > behavior than installing the features one by one.
> > > > >
> > > > > Here's the BootFeaturesInstaller code:
> > > > >
> > > > > List<Set> stagedFeatures = parseBootFeatures(features);
> > > > >

Re: [DISCUSS] Predictable Boot Feature Startup Order...

[James Carman]

Another issue I'm seeing with 4.0.7 right now is that the install order
doesn't really seem to make sense.  For example, I've got a "core" bundle
that requires the "spi" (service provider/plugin interfaces) bundle.  My
feature lists the "spi" bundle before the "core" bundle, but for some
reason, Karaf is installing "core" first and then installing "spi" much
later.  Is that expected behavior?  It seems strange to me.

On Fri, Nov 18, 2016 at 11:30 AM James Carman <ja...@carmanconsulting.com>
wrote:

> The main issue I faced was when different features install different
> versions of the same bundle (my particular problem child was GSON I think).
>   The main issue that we saw was when the lower version installed/started
> earlier than the higher version.  So, some bundles would bind to the lower
> version and later bundles which require a higher minor version, would bind
> to the higher version.  Hopefully that makes sense :)
>
>
> On Fri, Nov 18, 2016 at 11:23 AM Guillaume Nodet <gno...@apache.org>
> wrote:
>
> Here's the  3.x code
> for (Set features : stagedFeatures) {
> features.removeAll(installedFeatures);
> featuresService.installFeatures(features,
> EnumSet.of(Option.NoAutoRefreshBundles, Option.NoCleanIfFailure,
> Option.ContinueBatchOnFailure));
> }
>
> The 3.x features service will install the features one by one in a given
> set however.
> The difference may come from the Option.NoAutoRefreshBundles, but that's
> the benefit of using the osgi resolver, i.e. the features are considered as
> a whole ;-)
>
> Just to refresh my memory, what's the actual use case : is it a bundle
> startup order or a bundle installation order (which has an impact on
> resolution when choosing between the same package exported by multiple
> bundles).
> Note that the bundle startup order will be different when rebooting,
> whereas when using a single stage, the order should be the same.  If the
> problem is a wiring problem because you have packages exported by multiple
> bundles, I've tried to fix some of this problem in 4.1 by ensuring that the
> same wiring is reused after a reboot.
>
> 2016-11-18 17:13 GMT+01:00 James Carman <ja...@carmanconsulting.com>:
>
> > I know.  I looked at the code.  That's why I was surprised when I had
> > issues when trying it that way.  It could be I'm doing something strange
> > with CXF, but it works in a non-staged setup.  If I get some cycles,
> > perhaps I can try it again and record the error.
> >
> >
> > On Fri, Nov 18, 2016 at 11:11 AM Guillaume Nodet <gno...@apache.org>
> > wrote:
> >
> > > Using staged features with one feature per set will have the exact same
> > > behavior than installing the features one by one.
> > >
> > > Here's the BootFeaturesInstaller code:
> > >
> > > List<Set> stagedFeatures = parseBootFeatures(features);
> > > for (Set features : stagedFeatures) {
> > > featuresService.installFeatures(features,
> > > EnumSet.of(FeaturesService.Option.NoFailOnFeatureNotFound));
> > > }
> > > featuresService.bootDone();
> > >
> > >
> > >
> > > 2016-11-18 17:03 GMT+01:00 James Carman <ja...@carmanconsulting.com>:
> > >
> > > > Yes, I've tried using staged boot, but in 3.0.x it caused some
> > classpath
> > > > issues with CXF.  It would be great if we could just set up our
> > features
> > > so
> > > > that they're just installed in the order they're defined.
> > > >
> > > > On Fri, Nov 18, 2016 at 10:56 AM Guillaume Nodet <gno...@apache.org>
> > > > wrote:
> > > >
> > > > > You mean installing the features one by one instead of all in one
> go
> > ?
> > > > > Have you tried using
> > > > >   (myfeature1,myfeature2),(myfeature3,myfeature4)
> > > > > so that you end up with 2 stages ?
> > > > > Ultimately, you can use
> > > > >   (myfeature1),(myfeature2),(myfeature3),(myfeature4)
> > > > >
> > > > > 2016-11-18 16:44 GMT+01:00 James Carman <
> ja...@carmanconsulting.com
> > >:
> > > > >
> > > > > > Karaf 3.0.8+ now provides predictable boot feature startup order,
> > but
> > > > the
> > > > > > 4.0.x line does not provide that guarantee.  It apparently tries
> to
> > > be
> > > > > > smart and figure out what you need, but sometimes it just works
> > > bet

Re: [DISCUSS] Predictable Boot Feature Startup Order...

[James Carman]

The main issue I faced was when different features install different
versions of the same bundle (my particular problem child was GSON I think).
  The main issue that we saw was when the lower version installed/started
earlier than the higher version.  So, some bundles would bind to the lower
version and later bundles which require a higher minor version, would bind
to the higher version.  Hopefully that makes sense :)


On Fri, Nov 18, 2016 at 11:23 AM Guillaume Nodet <gno...@apache.org> wrote:

> Here's the  3.x code
> for (Set features : stagedFeatures) {
> features.removeAll(installedFeatures);
> featuresService.installFeatures(features,
> EnumSet.of(Option.NoAutoRefreshBundles, Option.NoCleanIfFailure,
> Option.ContinueBatchOnFailure));
> }
>
> The 3.x features service will install the features one by one in a given
> set however.
> The difference may come from the Option.NoAutoRefreshBundles, but that's
> the benefit of using the osgi resolver, i.e. the features are considered as
> a whole ;-)
>
> Just to refresh my memory, what's the actual use case : is it a bundle
> startup order or a bundle installation order (which has an impact on
> resolution when choosing between the same package exported by multiple
> bundles).
> Note that the bundle startup order will be different when rebooting,
> whereas when using a single stage, the order should be the same.  If the
> problem is a wiring problem because you have packages exported by multiple
> bundles, I've tried to fix some of this problem in 4.1 by ensuring that the
> same wiring is reused after a reboot.
>
> 2016-11-18 17:13 GMT+01:00 James Carman <ja...@carmanconsulting.com>:
>
> > I know.  I looked at the code.  That's why I was surprised when I had
> > issues when trying it that way.  It could be I'm doing something strange
> > with CXF, but it works in a non-staged setup.  If I get some cycles,
> > perhaps I can try it again and record the error.
> >
> >
> > On Fri, Nov 18, 2016 at 11:11 AM Guillaume Nodet <gno...@apache.org>
> > wrote:
> >
> > > Using staged features with one feature per set will have the exact same
> > > behavior than installing the features one by one.
> > >
> > > Here's the BootFeaturesInstaller code:
> > >
> > > List<Set> stagedFeatures = parseBootFeatures(features);
> > > for (Set features : stagedFeatures) {
> > > featuresService.installFeatures(features,
> > > EnumSet.of(FeaturesService.Option.NoFailOnFeatureNotFound));
> > > }
> > > featuresService.bootDone();
> > >
> > >
> > >
> > > 2016-11-18 17:03 GMT+01:00 James Carman <ja...@carmanconsulting.com>:
> > >
> > > > Yes, I've tried using staged boot, but in 3.0.x it caused some
> > classpath
> > > > issues with CXF.  It would be great if we could just set up our
> > features
> > > so
> > > > that they're just installed in the order they're defined.
> > > >
> > > > On Fri, Nov 18, 2016 at 10:56 AM Guillaume Nodet <gno...@apache.org>
> > > > wrote:
> > > >
> > > > > You mean installing the features one by one instead of all in one
> go
> > ?
> > > > > Have you tried using
> > > > >   (myfeature1,myfeature2),(myfeature3,myfeature4)
> > > > > so that you end up with 2 stages ?
> > > > > Ultimately, you can use
> > > > >   (myfeature1),(myfeature2),(myfeature3),(myfeature4)
> > > > >
> > > > > 2016-11-18 16:44 GMT+01:00 James Carman <
> ja...@carmanconsulting.com
> > >:
> > > > >
> > > > > > Karaf 3.0.8+ now provides predictable boot feature startup order,
> > but
> > > > the
> > > > > > 4.0.x line does not provide that guarantee.  It apparently tries
> to
> > > be
> > > > > > smart and figure out what you need, but sometimes it just works
> > > better
> > > > if
> > > > > > we can let the user control things explicitly.  Is there,
> perhaps,
> > a
> > > > > > compromise here?  Could we perhaps have a switch in the
> > > > > > org.apache.karaf.features.cfg file that allows you to turn on
> > manual
> > > > > > control of the startup order?  I'm not the only one who has
> > > encountered
> > > > > > this issue.  There have been emails recently where other folks
> have
> > > > > > observed it.  Thoughts?
> > 

Re: [DISCUSS] Predictable Boot Feature Startup Order...

[James Carman]

I know.  I looked at the code.  That's why I was surprised when I had
issues when trying it that way.  It could be I'm doing something strange
with CXF, but it works in a non-staged setup.  If I get some cycles,
perhaps I can try it again and record the error.


On Fri, Nov 18, 2016 at 11:11 AM Guillaume Nodet <gno...@apache.org> wrote:

> Using staged features with one feature per set will have the exact same
> behavior than installing the features one by one.
>
> Here's the BootFeaturesInstaller code:
>
> List<Set> stagedFeatures = parseBootFeatures(features);
> for (Set features : stagedFeatures) {
> featuresService.installFeatures(features,
> EnumSet.of(FeaturesService.Option.NoFailOnFeatureNotFound));
> }
> featuresService.bootDone();
>
>
>
> 2016-11-18 17:03 GMT+01:00 James Carman <ja...@carmanconsulting.com>:
>
> > Yes, I've tried using staged boot, but in 3.0.x it caused some classpath
> > issues with CXF.  It would be great if we could just set up our features
> so
> > that they're just installed in the order they're defined.
> >
> > On Fri, Nov 18, 2016 at 10:56 AM Guillaume Nodet <gno...@apache.org>
> > wrote:
> >
> > > You mean installing the features one by one instead of all in one go ?
> > > Have you tried using
> > >   (myfeature1,myfeature2),(myfeature3,myfeature4)
> > > so that you end up with 2 stages ?
> > > Ultimately, you can use
> > >   (myfeature1),(myfeature2),(myfeature3),(myfeature4)
> > >
> > > 2016-11-18 16:44 GMT+01:00 James Carman <ja...@carmanconsulting.com>:
> > >
> > > > Karaf 3.0.8+ now provides predictable boot feature startup order, but
> > the
> > > > 4.0.x line does not provide that guarantee.  It apparently tries to
> be
> > > > smart and figure out what you need, but sometimes it just works
> better
> > if
> > > > we can let the user control things explicitly.  Is there, perhaps, a
> > > > compromise here?  Could we perhaps have a switch in the
> > > > org.apache.karaf.features.cfg file that allows you to turn on manual
> > > > control of the startup order?  I'm not the only one who has
> encountered
> > > > this issue.  There have been emails recently where other folks have
> > > > observed it.  Thoughts?
> > > >
> > > > James
> > > >
> > >
> > >
> > >
> > > --
> > > 
> > > Guillaume Nodet
> > > 
> > > Red Hat, Open Source Integration
> > >
> > > Email: gno...@redhat.com
> > > Web: http://fusesource.com
> > > Blog: http://gnodet.blogspot.com/
> > >
> >
>
>
>
> --
> 
> Guillaume Nodet
> 
> Red Hat, Open Source Integration
>
> Email: gno...@redhat.com
> Web: http://fusesource.com
> Blog: http://gnodet.blogspot.com/
>

Re: [DISCUSS] Predictable Boot Feature Startup Order...

[James Carman]

Yes, I've tried using staged boot, but in 3.0.x it caused some classpath
issues with CXF.  It would be great if we could just set up our features so
that they're just installed in the order they're defined.

On Fri, Nov 18, 2016 at 10:56 AM Guillaume Nodet <gno...@apache.org> wrote:

> You mean installing the features one by one instead of all in one go ?
> Have you tried using
>   (myfeature1,myfeature2),(myfeature3,myfeature4)
> so that you end up with 2 stages ?
> Ultimately, you can use
>   (myfeature1),(myfeature2),(myfeature3),(myfeature4)
>
> 2016-11-18 16:44 GMT+01:00 James Carman <ja...@carmanconsulting.com>:
>
> > Karaf 3.0.8+ now provides predictable boot feature startup order, but the
> > 4.0.x line does not provide that guarantee.  It apparently tries to be
> > smart and figure out what you need, but sometimes it just works better if
> > we can let the user control things explicitly.  Is there, perhaps, a
> > compromise here?  Could we perhaps have a switch in the
> > org.apache.karaf.features.cfg file that allows you to turn on manual
> > control of the startup order?  I'm not the only one who has encountered
> > this issue.  There have been emails recently where other folks have
> > observed it.  Thoughts?
> >
> > James
> >
>
>
>
> --
> 
> Guillaume Nodet
> 
> Red Hat, Open Source Integration
>
> Email: gno...@redhat.com
> Web: http://fusesource.com
> Blog: http://gnodet.blogspot.com/
>

[DISCUSS] Predictable Boot Feature Startup Order...

[James Carman]

Karaf 3.0.8+ now provides predictable boot feature startup order, but the
4.0.x line does not provide that guarantee.  It apparently tries to be
smart and figure out what you need, but sometimes it just works better if
we can let the user control things explicitly.  Is there, perhaps, a
compromise here?  Could we perhaps have a switch in the
org.apache.karaf.features.cfg file that allows you to turn on manual
control of the startup order?  I'm not the only one who has encountered
this issue.  There have been emails recently where other folks have
observed it.  Thoughts?

James

Re: [DISCUSS] Feature package, feature generation and validation

[James Carman]

I am +1 on removing it, especially if nobody wants to maintain it.  I tried
to use it at one point and it just never really worked well.  Hand-crafted
features files are always the best option, IMHO.  It might be nice to have
a Maven archetype or something that would generate a "features module" from
scratch, to give folks a starting point.

On Thu, Oct 13, 2016 at 5:08 AM Guillaume Nodet  wrote:

> The feature packaging is a nice thing, as it allows automatic attachment of
> the feature file.
> However, it always use the feature-generate-descriptor, which produces a
> lot of weird results.
> Afaik, the feature packaging is not much used and all projects i've seen,
> such as pax projects, camel, cxf, and even karaf itself (including
> decanter, cellar, karaf container...).
>
> I think part of the problem comes from the feature descriptor generation,
> which is difficult to control.  I have always found much easier to simply
> write the feature manually.
> Although the generation process rewrites the xml entirely, so that any xml
> comments or license header is lost.
>
> Overall, I'm not sure that it makes our users life really easier.
>
> So I'd like to propose to get rid of the feature-generate-descriptor from
> inside the feature packaging and replace it with the verify goal to
> validate the hand-written features instead.
>
> Thoughts ?
>
> --
> 
> Guillaume Nodet
> 
> Red Hat, Open Source Integration
>
> Email: gno...@redhat.com
> Web: http://fusesource.com
> Blog: http://gnodet.blogspot.com/
>

Re: Managed Service & Managed Service factory

[James Carman]

We have a little library we use called Eos to do ManagedServiceFactories
(ManagedService is a bit easier):

https://github.com/savoirtech/eos

The "itest" module(s) have an example of how to wire it up using Blueprint:

https://github.com/savoirtech/eos/blob/master/itest/bundle/src/main/resources/OSGI-INF/blueprint/itest-bundle.xml

It's not well-documented at the moment, but it is in Maven Central, so
you're definitely welcome to it.  There are also some nice superclasses for
dealing with the "whiteboard pattern" in there that we use all over the
place.

Thanks,

James



On Sun, Oct 16, 2016 at 7:03 PM Krzysztof Sobkowiak <
krzys.sobkow...@gmail.com> wrote:

> Hi
>
> Are there any samples how to implement correctly the Managed Service and
> Managed Service Factory / Component Factory using the OSGi Declarative
> Services Annotations? Something like in
> https://github.com/apache/karaf/tree/master/scr/examples/managed-service
> and
> https://github.com/apache/karaf/tree/master/scr/examples/component-factory
> but using the org.osgi.service.component.annotations annotations.
>
> Btw. are there any samples how to do this correctly with Blueprint?
>
> Kindly regards
> Krzysztof
>
>
>
>
> --
> Krzysztof Sobkowiak (@ksobkowiak)
>
> JEE & OSS Architect, Integration Architect
> Apache Software Foundation Member (http://apache.org/)
> Apache ServiceMix Committer & PMC Member (http://servicemix.apache.org/)
> Senior Solution Architect @ Capgemini SSC (
> http://www.capgeminisoftware.pl/)
>

Re: [VOTE] Apache Karaf (Container) 3.0.8 release

[James Carman]

Are we past the 72 hours on this one?

On Mon, Aug 8, 2016 at 3:59 AM Jean-Baptiste Onofré  wrote:

> Hi all,
>
> I submit Karaf Container 3.0.8 release to your vote.
>
> Release Notes:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12335948
>
> Staging Repository:
> https://repository.apache.org/content/repositories/orgapachekaraf-1069/
>
> Git Tag:
> karaf-3.0.8
>
> Please vote to approve this release:
>
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)
>
> This vote will be open for at least 72 hours.
>
> Thanks,
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>

Re: [VOTE] Apache Karaf (Container) 3.0.8 release

[James Carman]

+1 (non-binding)

Tested by installing some of our current applications and everything
appears to be working properly.  Nice work!  Thanks for getting this out so
quickly, JB.


On Mon, Aug 8, 2016 at 3:59 AM Jean-Baptiste Onofré  wrote:

> Hi all,
>
> I submit Karaf Container 3.0.8 release to your vote.
>
> Release Notes:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12335948
>
> Staging Repository:
> https://repository.apache.org/content/repositories/orgapachekaraf-1069/
>
> Git Tag:
> karaf-3.0.8
>
> Please vote to approve this release:
>
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)
>
> This vote will be open for at least 72 hours.
>
> Thanks,
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>

Re: [DISCUSSS] Duplicate persistent-id usage can cause bundle restart loop...

[James Carman]

Agreed.  Karaf just seems to be suffering from the bug, though.  We should
work with the Aries team to resolve the issue.  Karaf goes into a crazy
looping state (which eventually seems to settle down), so I would think
we'd want to get it fixed.

On Wed, Aug 3, 2016 at 8:02 AM Jean-Baptiste Onofré <j...@nanthrax.net> wrote:

> IMHO, it's not a Karaf issue but more a blueprint-cm issue.
>
> Regards
> JB
>
> On 08/03/2016 12:48 PM, James Carman wrote:
> > Right, what I'm saying is that Karaf doesn't behave very nicely when two
> > ManagedService's try to use the same service.pid. I want it to barf on
> the
> > second one and not go into its crazy loop that it does.
> >
> > On Wed, Aug 3, 2016 at 12:53 AM Jean-Baptiste Onofré <j...@nanthrax.net>
> > wrote:
> >
> >> Hi James,
> >>
> >> you are right only for the ManagedService. If several bundles directly
> >> read the configuration with ConfigAdmin (using directly the service),
> >> than there is no problem.
> >>
> >> The problem occurs only when you have several ManagedService on the same
> >> config (called when the configuration change especially).
> >>
> >> Regards
> >> JB
> >>
> >> On 08/02/2016 09:53 PM, James Carman wrote:
> >>> When two different bundles use the same configuration pid, you can get
> >> into
> >>> a very weird restart loop (at least with blueprint).  It violates the
> >>> specification for two bundles to try to use the same configuration.
> >>> Shouldn't we just fail to start the second bundle if the pid is already
> >>> "claimed"?
> >>>
> >>> James
> >>>
> >>
> >> --
> >> 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: [DISCUSSS] Duplicate persistent-id usage can cause bundle restart loop...

[James Carman]

This appears to just be a Blueprint thing.  I tried replicating the looping
issue with simple ManagedServices and that worked just fine.  I got an
ERROR log:

07:19:21,467 | ERROR | CM Configuration Updater (Update:
pid=com.carmanconsulting.karaf.whiteboard) | ?
  ? | 6 - org.apache.felix.configadmin - 1.8.4 |  | Cannot use
configuration com.carmanconsulting.karaf.whiteboard for
[org.osgi.service.cm.ManagedService, id=1013,
bundle=289/mvn:com.carmanconsulting.karaf/karaf-whiteboard-bundle2/1.0.0-SNAPSHOT]:
No visibility to configuration bound to
mvn:com.carmanconsulting.karaf/karaf-whiteboard-bundle1/1.0.0-SNAPSHOT

However, when you use blueprint and the "property-placeholder" (with
update-strategy="reload"), it's a whole different story.  I have checked in
a small project (with a couple other modules in it) that exhibits the issue:

https://github.com/jwcarman/karaf-whiteboard

The README shows how to install it.  Now, keep in mind that this behavior
isn't consistent.  But, try it a few times and you will see the looping it
does in the logs.

On Wed, Aug 3, 2016 at 6:48 AM James Carman <ja...@carmanconsulting.com>
wrote:

> Right, what I'm saying is that Karaf doesn't behave very nicely when two
> ManagedService's try to use the same service.pid. I want it to barf on the
> second one and not go into its crazy loop that it does.
>
> On Wed, Aug 3, 2016 at 12:53 AM Jean-Baptiste Onofré <j...@nanthrax.net>
> wrote:
>
>> Hi James,
>>
>> you are right only for the ManagedService. If several bundles directly
>> read the configuration with ConfigAdmin (using directly the service),
>> than there is no problem.
>>
>> The problem occurs only when you have several ManagedService on the same
>> config (called when the configuration change especially).
>>
>> Regards
>> JB
>>
>> On 08/02/2016 09:53 PM, James Carman wrote:
>> > When two different bundles use the same configuration pid, you can get
>> into
>> > a very weird restart loop (at least with blueprint).  It violates the
>> > specification for two bundles to try to use the same configuration.
>> > Shouldn't we just fail to start the second bundle if the pid is already
>> > "claimed"?
>> >
>> > James
>> >
>>
>> --
>> Jean-Baptiste Onofré
>> jbono...@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>

Re: [DISCUSSS] Duplicate persistent-id usage can cause bundle restart loop...

[James Carman]

Right, what I'm saying is that Karaf doesn't behave very nicely when two
ManagedService's try to use the same service.pid. I want it to barf on the
second one and not go into its crazy loop that it does.

On Wed, Aug 3, 2016 at 12:53 AM Jean-Baptiste Onofré <j...@nanthrax.net>
wrote:

> Hi James,
>
> you are right only for the ManagedService. If several bundles directly
> read the configuration with ConfigAdmin (using directly the service),
> than there is no problem.
>
> The problem occurs only when you have several ManagedService on the same
> config (called when the configuration change especially).
>
> Regards
> JB
>
> On 08/02/2016 09:53 PM, James Carman wrote:
> > When two different bundles use the same configuration pid, you can get
> into
> > a very weird restart loop (at least with blueprint).  It violates the
> > specification for two bundles to try to use the same configuration.
> > Shouldn't we just fail to start the second bundle if the pid is already
> > "claimed"?
> >
> > James
> >
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>

[DISCUSSS] Duplicate persistent-id usage can cause bundle restart loop...

[James Carman]

When two different bundles use the same configuration pid, you can get into
a very weird restart loop (at least with blueprint).  It violates the
specification for two bundles to try to use the same configuration.
Shouldn't we just fail to start the second bundle if the pid is already
"claimed"?

James

Karaf 4.0.x branch failing on CXF 3.1.7-SNAPSHOT dependency...

[James Carman]

When Jenkins tried to merge in my patch, it failed the build:

https://builds.apache.org/job/karaf-pr/327/console

Why are we depending upon a SNAPSHOT of CXF in Karaf?

James

[PROPOSAL] Changing the FeaturesService.installFeatures() API...

[James Carman]

When implementing the fix for KARAF-4642, I noticed that the
FeaturesService's installFeatures() method takes a Set
(Set in 3.0.x).  I propose we change that when we can to
Iterable to indicate that we will iterate through what they give us
and install them *in order*.  It would be a source compatible change, but
not a binary compatible change (existing folks will need to rebuild their
code).  This will allow the BootFeaturesInstaller to pass in a List
instead of Set.  The main issue here is that order is definitely
important when installing features.  What do you guys think?

James

Re: Enabling compression of HTTP responses when using osgi-jax-rs-connector

[James Carman]

On Fri, Jul 8, 2016 at 2:35 PM Marc Durand  wrote:

> I am not sure how a CXF annotation can work in my case - I am not using CXF
> at all.  I am using Jersey and OSGI-JAX-RS-Connector.
>
>
Oh, then my suggestion won't work either.  Sorry. :(

Re: Enabling compression of HTTP responses when using osgi-jax-rs-connector

[James Carman]

You can also just add the GZIPFeature to your JAX-RS server.

On Fri, Jul 8, 2016 at 1:46 PM Benson Margulies 
wrote:

> @GZIP on the resource class works for me.
>
>
> On Fri, Jul 8, 2016 at 1:44 PM, Marc Durand  wrote:
> > I have successfully added a gzip filter to the default web container in
> Karaf
> > and responses coming from regular servlets are compressed.  This filter
> does
> > not seem to apply to REST responses that are produced through the
> > osgi-jax-rs-connector bundle.  How can I enable compression of REST
> > responses in Karaf?
> >
> > Thanks in advance!
> > Marc
> >
> >
> >
> > --
> > View this message in context:
> http://karaf.922171.n3.nabble.com/Enabling-compression-of-HTTP-responses-when-using-osgi-jax-rs-connector-tp4047174.html
> > Sent from the Karaf - Dev mailing list archive at Nabble.com.
>

Re: Karaf 4.0.x Custom distribution

[James Carman]

Here is our custom Karaf build against 4.0.x and it is working. I know we
faced some issues also, but they are resolved now. I do not remember the
details.

https://github.com/savoirtech/aetos/tree/4.0.x?files=1
On Mon, Jun 20, 2016 at 6:48 AM Roedl Lukas  wrote:

> Hi!
>
> I'm currently trying to upgrade our custom distribution to the Karaf 4 way
> of doing things.
> Unfortunately I'm experiencing some problems when compiling the assembly
> when the karaf-maven-plugin tries to "Resolving features". The errors look
> like the following:
>
> Failed to execute goal
> org.apache.karaf.tooling:karaf-maven-plugin:4.0.5:assembly
> (default-assembly) on project asse
> mbly: Unable to build assembly: Unable to resolve root: missing
> requirement [root] osgi.identity; osgi.identity=home
> r-core-minimal; type=karaf.feature; version=1.2.31.SNAPSHOT;
> filter:="(&(osgi.identity=homer-core-minimal)(type=kara
> f.feature)(version>=1.2.31.SNAPSHOT))" [caused by: Unable to resolve
> homer-core-minimal/1.2.31.SNAPSHOT: missing req
> uirement [homer-core-minimal/1.2.31.SNAPSHOT] osgi.identity;
> osgi.identity=aries-blueprint; type=karaf.feature] -> [
> Help 1]
>
> It seems to be caused by my features linking to features out of the Karaf
> "standard" or "enterprise" features set. It's not only affecting
> "aries-blueprint" but also "log" or "eventadmin".
> I setup a little test-project under [1] with the features file [2] and
> further maven configuration to reproduce the errors.
>
> Did anyone also experience such errors and knows how to solve them?
> Can I overcome this issue using the "prerequisite" or "dependency"
> attribute for the linked feature?
> Is it ok to link against Karaf features or can/must I assume that the
> framework is properly configured beforehand?
>
> Thanks in advance,
> Lukas
>
> [1] https://github.com/roedll/homer-karaf4-assembly-test
> [2]
> https://github.com/roedll/homer-karaf4-assembly-test/blob/master/feature/src/main/feature/feature.xml
>

Downloads...

[James Carman]

I tried downloading karaf yesterday and it wasn't working. Apparently we
need to fix our download scripts:

https://reference.apache.org/pmc/mirror_scripts

Re: [VOTE] Release Apache Karaf 2.4.3

[James Carman]

I didn't see Achim's vote either. I still don't.

On Sun, Jul 12, 2015 at 7:34 AM Jamie G. jamie.goody...@gmail.com wrote:

 Yes, 3 binding votes is the minimum - that being said, somehow your
 vote got caught in my gmail spam filter?! Didn't see it until I was
 processing through that folder this morning.

 Cheers,
 Jamie

 On Sat, Jul 11, 2015 at 7:50 PM, Achim Nierbeck bcanh...@googlemail.com
 wrote:
  afaik 3 should be enough, shouldn't it?
 
  regards, Achim
 
  2015-07-11 23:51 GMT+02:00 Jamie G. jamie.goody...@gmail.com:
 
  Hi All,
 
  Just want to gently remind the list that we need more binding votes.
 
  I'm going to extend the vote by another 24 hours given its the weekend.
 
  Cheers,
  Jamie
 
  On Sat, Jul 11, 2015 at 4:27 PM, Johan Edstrom
  johan.edst...@acj-consulting.com wrote:
   +1 non binding, tested with build kit and distribution module.
  
   On Jul 11, 2015, at 12:28 PM, Jamie G. jamie.goody...@gmail.com
  wrote:
  
   +1
  
   Cheers,
   Jamie
  
   On Thu, Jul 9, 2015 at 6:47 AM, Krzysztof Sobkowiak
   krzys.sobkow...@gmail.com wrote:
   +1 (non-binding)
  
   I have built ServiceMix 5.4.x and tested it. Looks ok
  
   Regards
   Krzysztof
  
   On 09.07.2015 01:21, Jamie G. wrote:
   Hi,
  
   We resolved 23 issues in this release:
  
 
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140version=12332072
  
   Staging repository:
  
  https://repository.apache.org/content/repositories/orgapachekaraf-1036/
  
   Git tag:
   karaf-2.4.3
  
   Please vote to approve this release:
  
   [ ] +1 Approve the release
   [ ] -1 Veto the release (please provide specific comments)
  
   This vote will be open for at least 72 hours.
  
   --
   Krzysztof Sobkowiak
  
   JEE  OSS Architect
   Apache Software Foundation Member
   Apache ServiceMix http://servicemix.apache.org/ Committer  PMC
   Senior Solution Architect @ Capgemini SSC 
  http://www.pl.capgemini-sdm.com/en/
  
 
 
 
 
  --
 
  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: [VOTE] Release Apache Karaf 3.0.4

[James Carman]

+1 (non-binding) tested on some of our current apps in a custom
distribution built using the maven plugin. We're all fine here. Although
I'd like to see the region jar fiasco fixed in 3.0.x. Perhaps I'll provide
a patch.

On Tue, Jun 30, 2015 at 2:25 AM Morgan Hautman morgan.haut...@gmail.com
wrote:

 +1 (non-binding)

 On 29/06/2015 22:59, Jamie G. wrote:
  Hi,
 
  We resolved 103 issues in this release:
 
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140version=12329179
 
 
  Staging repository:
  https://repository.apache.org/content/repositories/orgapachekaraf-1034/
 
  Git tag:
  karaf-3.0.4
 
  Please vote to approve this release:
 
  [ ] +1 Approve the release
  [ ] -1 Veto the release (please provide specific comments)
 
  This vote will be open for 72 hours.

Re: [VOTE] Release Apache Karaf 3.0.4

[James Carman]

The jar needs to be upgraded to come from central at least.
On Tue, Jun 30, 2015 at 7:29 AM Jean-Baptiste Onofré j...@nanthrax.net
wrote:

 Hi James,

 I worked on a fix about region/bundle cache corruption, but I postponed
 to 3.0.5.

 Regards
 JB

 On 06/30/2015 01:24 PM, James Carman wrote:
  +1 (non-binding) tested on some of our current apps in a custom
  distribution built using the maven plugin. We're all fine here. Although
  I'd like to see the region jar fiasco fixed in 3.0.x. Perhaps I'll
 provide
  a patch.
 
  On Tue, Jun 30, 2015 at 2:25 AM Morgan Hautman morgan.haut...@gmail.com
 
  wrote:
 
  +1 (non-binding)
 
  On 29/06/2015 22:59, Jamie G. wrote:
  Hi,
 
  We resolved 103 issues in this release:
 
 
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140version=12329179
 
 
  Staging repository:
 
 https://repository.apache.org/content/repositories/orgapachekaraf-1034/
 
  Git tag:
  karaf-3.0.4
 
  Please vote to approve this release:
 
  [ ] +1 Approve the release
  [ ] -1 Veto the release (please provide specific comments)
 
  This vote will be open for 72 hours.
 
 
 

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

Re: [VOTE] Release Apache Karaf 3.0.4

[James Carman]

There is a newer version in central and master branch uses that right?
On Tue, Jun 30, 2015 at 7:33 AM Jean-Baptiste Onofré j...@nanthrax.net
wrote:

 The region jar comes from SMX m2-repo. We can push on oss (Central is a
 different story).

 Regards
 JB

 On 06/30/2015 01:30 PM, James Carman wrote:
  The jar needs to be upgraded to come from central at least.
  On Tue, Jun 30, 2015 at 7:29 AM Jean-Baptiste Onofré j...@nanthrax.net
  wrote:
 
  Hi James,
 
  I worked on a fix about region/bundle cache corruption, but I postponed
  to 3.0.5.
 
  Regards
  JB
 
  On 06/30/2015 01:24 PM, James Carman wrote:
  +1 (non-binding) tested on some of our current apps in a custom
  distribution built using the maven plugin. We're all fine here.
 Although
  I'd like to see the region jar fiasco fixed in 3.0.x. Perhaps I'll
  provide
  a patch.
 
  On Tue, Jun 30, 2015 at 2:25 AM Morgan Hautman 
 morgan.haut...@gmail.com
 
  wrote:
 
  +1 (non-binding)
 
  On 29/06/2015 22:59, Jamie G. wrote:
  Hi,
 
  We resolved 103 issues in this release:
 
 
 
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140version=12329179
 
 
  Staging repository:
 
  https://repository.apache.org/content/repositories/orgapachekaraf-1034/
 
  Git tag:
  karaf-3.0.4
 
  Please vote to approve this release:
 
  [ ] +1 Approve the release
  [ ] -1 Veto the release (please provide specific comments)
 
  This vote will be open for 72 hours.
 
 
 
 
  --
  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: [PROPOSAL] Releases for this week

[James Carman]

No Karaf 3.0.4?
On Sun, May 31, 2015 at 12:06 PM Jamie G. jamie.goody...@gmail.com wrote:

 Sounds good :)

 On Sun, May 31, 2015 at 1:16 PM, Jean-Baptiste Onofré j...@nanthrax.net
 wrote:
  Hi guys,
 
  sorry, I was very busy this week with a customer in the US, and I'm a bit
  late with the schedule.
 
  Tonight and tomorrow, I'm fixing issues on both master and karaf-3.0.x
  branches.
  Tomorrow afternoon, I would like to discuss with Guillaume about some
  behaviors in the new features resolver.
 
  The plan is to submit Karaf 3.0.4 and 4.0.0.M3 to vote end of this week.
 
  I will focus on it and deal with you guys (Guillaume for the resolver,
 Jamie
  for the releases preparation, etc).
 
  Thanks !
  Regards
  JB
 
 
  On 05/04/2015 10:55 AM, Jean-Baptiste Onofré wrote:
 
  Hi all,
 
  I would like to propose to you the following plan for the releases this
  week:
  - Tomorrow (Tuesday 05/05): Cellar 4.0.0.M1, Cellar 3.0.3, Cellar 2.3.6
  For Cellar, I have a couple of issues to address this afternoon and
  tonight.
  - Wednesday 05/06): Cave 4.0.0.M1
 I will update Cave master to run on K4 (as I did for Cellar).
 Guillaume did changes on Cave and I think we can release a first
  4.0.0.M1 to give some visibility.
  - Friday (05/08): Karaf 4.0.0
  I'm not sure if it makes sense to do a 4.0.0.M3. WDYT ?
  The Felix Framework is an important one but finally only when you
  use Dynamic-ImportPackage. So, I think we can deal with that.
  The blocking issue that I will address tonight and tomorrow is the
  local JMX security.
  I will also tackle some updates (I'm releasing a new set of SMX
  bundles).
  - Sunday (05/09): Decanter 1.0.0.M1
 I will update to Elasticsearch 1.5.2 and merge a first dashboard with
  Kibana4. I think a M1 make sense to give visibility.
I will update the website to give some place to decanter
 
  WDYT ?
 
  Regards
  JB
 
 
  --
  Jean-Baptiste Onofré
  jbono...@apache.org
  http://blog.nanthrax.net
  Talend - http://www.talend.com

Re: [PROPOSAL] Releases for this week

[James Carman]

Okay great! Sorry, I was reading on my phone and did not see the previous
message

On Sun, May 31, 2015 at 12:11 PM Jean-Baptiste Onofré j...@nanthrax.net
wrote:

 Hey James,

 see my previous e-mail:


  The plan is to submit Karaf 3.0.4 and 4.0.0.M3 to vote end of this week.

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

Re: Karaf Maven Plugin Not Filtering Resources...

[James Carman]

For illustrative purposes, please refer to this github example:

https://github.com/jwcarman/karaf-assembly-example



On Wed, May 13, 2015 at 3:43 PM James Carman ja...@carmanconsulting.com
wrote:

 I'm trying to use filtered resources to create a custom distro.
 Unfortunately, no matter what I do, the resources seem to get bundled into
 the distro unfiltered.  Is there an example somewhere that shows how to use
 filtered resources (yes, I'm following the instructions on the docs page).

Re: Karaf Maven Plugin Not Filtering Resources...

[James Carman]

I figured it out.  It was indeed not going after the filtered resources.  I
created a pull request against 3.0.x and I can whip something up against
master if you want also:

https://github.com/apache/karaf/pull/61

Please let me know.


On Wed, May 13, 2015 at 4:10 PM James Carman ja...@carmanconsulting.com
wrote:

 For illustrative purposes, please refer to this github example:

 https://github.com/jwcarman/karaf-assembly-example



 On Wed, May 13, 2015 at 3:43 PM James Carman ja...@carmanconsulting.com
 wrote:

 I'm trying to use filtered resources to create a custom distro.
 Unfortunately, no matter what I do, the resources seem to get bundled into
 the distro unfiltered.  Is there an example somewhere that shows how to use
 filtered resources (yes, I'm following the instructions on the docs page).

Re: [DISCUSS] Change in the lib directory

[James Carman]

Yes, I reported that one.  That was quite a nasty one to figure out.

On Thu, Feb 19, 2015 at 5:49 AM, Achim Nierbeck bcanh...@googlemail.com wrote:
 Hi,

 I've found the issue.
 https://issues.apache.org/jira/browse/KARAF-1545

 regards, Achim

 2015-02-19 11:44 GMT+01:00 Guillaume Nodet gno...@apache.org:

 2015-02-19 11:28 GMT+01:00 Stuart McCulloch mccu...@gmail.com:

  On 19 Feb 2015 10:09, Guillaume Nodet gno...@apache.org wrote:
  
   2015-02-19 11:01 GMT+01:00 Fabian Lange fabian.la...@codecentric.de:
  
Hi Guillaume,
   
as somebody who put stuff to lib, I discovered that karaf* magic
  myself.
   
I think lib/system is more explicit. But then I would prefer if all
jars there are added to the JVM classpath, not only karaf*.
   
  
   Yes, definitely, sorry to not have been more clear, but that was
  definitely
   the idea.  So instead of having special karaf* jars, it would simply
 load
   all jars in lib/system.
 
  lib/boot might make more sense, to avoid confusion with the existing
  top-level system directory
 

 Agreed, it would be less confusing.


 
   
Also worth noting: I have not found a nice way to include the JVM
tools.jar (pre Java 9) onto the classpath without patching the
karaf.sh. Not sure if this is a karaf use-case and it could be
 simpler
(tools.jar is tricky and actually going away with 9)
   
  
   I'm sure we can find a solution, but it seems to me that there are
 still
  a
   lot
   of stuff that is missing or bound to change in Java 9 ...
  
  
   
Fabian
   
On Thu, Feb 19, 2015 at 9:38 AM, Guillaume Nodet gno...@gmail.com
  wrote:
 I'm thinking about slightly changing the way the lib folder is
  organised
in
 Karaf 4.
 With all previous versions, the lib folder can contains jar with 2
 different set of jars:
   - karaf*.jar will be loaded when the JVM is started (they are
  appended
to
 the class path of the java command)
   - other jars are loaded by the Main class along with the osgi
  framework
 jar

 The convention that jars named karaf*.jar are loaded and available
 to
  the
 Main class (for example for jdbc lock access) is not really
 explicit
enough
 imho.

 I wonder if it would make sense to set up a separate lib/system
  directory
 which would contain those karaf*.jar files (thus avoiding the need
 to
 rename them).
 We could keep the lib/ folder for jars that will be loaded by the
  Main
 class, or even move them to a separate directory such as lib/app,
 but
  I'm
 not really sure it brings anything.

 Thoughts ?

 Guillaume

 --
 
 Guillaume Nodet
 
 Red Hat, Open Source Integration

 Email: gno...@redhat.com
 Web: http://fusesource.com
 Blog: http://gnodet.blogspot.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: [DISCUSS] Migration to SCR

[James Carman]

So, start 4.x now!  :)  Release early, release often.


On Mon, Feb 3, 2014 at 12:09 PM,  j...@nanthrax.net wrote:
 Good points Ioannis,

 my point is just about the message for we send to the users and community.

 You are right, it took long time to release Karaf 3.0.0, but it doesn't mean
 that it would be the same for 4.0.0.

 My point is just to send a message for users/community like: hey, we did
 deep changes ;)

 Regards
 JB


 On 2014-02-03 16:24, Ioannis Canellos wrote:

 I would plan this for Karaf 4.0.0, even if it's internal.


 While I don't have a strong objection on having it as part of a 4.x
 release, that would mean that it will get pushed back way into the
 future.
 3.x release took us almost 3 years to get out and we stalled 2.3.x for
 1.5 year in favour of 3.x.

 What I take from that experience, is that its not a good idea to push
 stuff to major releases, when they are candidates for a major release.

 It's an important jump internally in Karaf, and should be addressed in a
 major release.


 I agree that this is an important change. Semantic versioning doesn't
 force us to push important changes to major releases. Since we are
 talking about a change that is transparent to the user, the importance
 of the change is a good reason to deliver it asap :-)

 We just release Karaf 3.0.0, and we have to let people and other projects
 to
 move smoothly (even if as you said, you should not have impact).


 This is another good reason, for not rushing a 4.x release.

Re: Build failure on Karaf trunk...

[James Carman]

Stack trace?

On Friday, October 25, 2013, David Bosschaert wrote:

 Just rebuilt using a fresh new .m2 on OSX, but am still getting the
 same error. Although the NoSuchMethodError reports being on
 org.codehaus.plexus.util.cli.CommandLineUtils I wonder could it have
 something to do that I'm using Java 1.6 on OSX? My successful build on
 Linux was with 1.7...

 Cheers,

 David

 On 25 October 2013 17:06, David Bosschaert 
 david.bosscha...@gmail.comjavascript:;
 wrote:
  Hmmm... I just tried mvn 3.0.5 on both OSX as well as on a fresh Linux
  (Fedora) machine.
  Linux passes OSX fails... Time to whack the .m2 directory ...
 
  On 25 October 2013 16:59, Andreas Pieber anpie...@gmail.comjavascript:;
 wrote:
  3.1.x does not work by now. Since the karaf plugin does not use the
  abstraction layer this terribly fails with the new maven version --
 3.0.x
  should work
 
  Kind regards,
  Andreas
 
 
  On Fri, Oct 25, 2013 at 5:37 PM, David Bosschaert 
  david.bosscha...@gmail.com javascript:; wrote:
 
  I was actually using the default mvn install on my system which is
 3.0.3.
  I just tried with 3.1.1 which gives me a slightly similar error
 (below).
 
  What Maven version should work?
 
  Cheers,
 
  David
 
  The error with maven 3.1.1:
  [ERROR] Failed to execute goal
 
 
 org.apache.karaf.tooling:karaf-maven-plugin:3.0.0-SNAPSHOT:features-generate-descriptor
  (compile) on project framework: Execution compile of goal
 
 
 org.apache.karaf.tooling:karaf-maven-plugin:3.0.0-SNAPSHOT:features-generate-descriptor
  failed: Unable to load the mojo 'features-generate-descriptor' (or one
  of its required components) from the plugin
  'org.apache.karaf.tooling:karaf-maven-plugin:3.0.0-SNAPSHOT':
  com.google.inject.ProvisionException: Guice provision errors:
  [ERROR]
  [ERROR] 1) No implementation for org.sonatype.aether.RepositorySystem
 was
  bound.
  [ERROR] while locating
  org.apache.karaf.tooling.features.GenerateDescriptorMojo
  [ERROR] at
 
 ClassRealm[pluginorg.apache.karaf.tooling:karaf-maven-plugin:3.0.0-SNAPSHOT,
  parent: sun.misc.Launcher$AppClassLoader@7987aeca]
  [ERROR] while locating org.apache.maven.plugin.Mojo annotated with
 
 
 @com.google.inject.name.Named(value=org.apache.karaf.tooling:karaf-maven-plugin:3.0.0-SNAPSHOT:features-generate-descriptor)
  [ERROR]
  [ERROR] 1 error
  [ERROR] role: org.apache.maven.plugin.Mojo
  [ERROR] roleHint:
 
 
 org.apache.karaf.tooling:karaf-maven-plugin:3.0.0-SNAPSHOT:features-generate-descriptor
 
  On 25 October 2013 16:27, nseb seb_nicoul...@hotmail.comjavascript:;
 wrote:
   You use maven 3.1.0 ?
  
  
  
   --
   View this message in context:
 
 http://karaf.922171.n3.nabble.com/Build-failure-on-Karaf-trunk-tp4030054p4030055.html
   Sent from the Karaf - Dev mailing list archive at Nabble.com.