Re: Decanter log collector: flooding OSGI event bus?

[414n]

Hi Christian,

I finally found some spare time to perform some tests on the issue at 
hand. From the initial tests I managed to perform, It seems like the 
culprit bundle is decanter-appender-socket.

Hope this can be of help

Alan Alberghini
IOOOTA - a...@iooota.com <mailto:a...@iooota.com>
https://www.iooota.com
https://www.facebook.com/IOOOTA
On 18/10/2016 13:34, cschneider [via Karaf] wrote:
> Sounds like maybe an EventListener of decanter was blocking for too long.
>
> Can you try to stop the decanter bundles individually and check which 
> bundle causes the delivery.
>
> Christian
>
> 2016-10-18 13:13 GMT+02:00 414n <[hidden email] 
> >:
>
> Greetings,
>
> we recently had some issues that seem to relate to the decanter log
> collector component in our karaf-based environment.
> What we observed is that normal OSGI events are not delivered to our
> components until we shut down decanter-related bundles. As soon as
> those are
> shut down, a burst of OSGI events gets delivered all at once,
> making it look
> like they were being held in some kind of queue.
> Has this been observed before?
>
>
>
> --
> View this message in context:
> 
> http://karaf.922171.n3.nabble.com/Decanter-log-collector-flooding-OSGI-event-bus-tp4048415.html
> 
> <http://karaf.922171.n3.nabble.com/Decanter-log-collector-flooding-OSGI-event-bus-tp4048415.html>
> Sent from the Karaf - User mailing list archive at Nabble.com.
>
>
>
>
> -- 
> -- 
> Christian Schneider
> http://www.liquid-reality.de 
> <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46=http%3a%2f%2fwww.liquid-reality.de>
>
> Open Source Architect
> http://www.talend.com 
> <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46=http%3a%2f%2fwww.talend.com>
>
>
> 
> If you reply to this email, your message will be added to the 
> discussion below:
> http://karaf.922171.n3.nabble.com/Decanter-log-collector-flooding-OSGI-event-bus-tp4048415p4048417.html
>  
>
> To unsubscribe from Decanter log collector: flooding OSGI event bus?, 
> click here 
> <http://karaf.922171.n3.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code=4048415=YWxhbkBpb29vdGEuY29tfDQwNDg0MTV8NjExMjcwNjA2>.
> NAML 
> <http://karaf.922171.n3.nabble.com/template/NamlServlet.jtp?macro=macro_viewer=instant_html%21nabble%3Aemail.naml=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>  
>





--
View this message in context: 
http://karaf.922171.n3.nabble.com/Decanter-log-collector-flooding-OSGI-event-bus-tp4048415p4049035.html
Sent from the Karaf - User mailing list archive at Nabble.com.

Re: Decanter log collector: flooding OSGI event bus?

[414n]

Sounds like maybe an EventListener of decanter was blocking for too
long.

Can you try to stop the decanter bundles individually and check
which bundle causes the delivery.

Christian

Hello Christian,

I’ll try to perform this kind of test as soon as I can.

Hi,

what’s the Decanter version ?

Can you share the Decanter collectors you installed ?

By the way, I plan to release Decanter 1.3.0 later this week, so, if
it’s a bug, I would like to fix it for this release.

Thanks !
Regards
JB

Hello JB,

I’m using decanter-1.2.0 and I’ve deployed the log collector and the 
socket appender in the same karaf instance, to send logs to a remote 
host (which uses the decanter socket-collector).

Alan Alberghini
IOOOTA - a...@iooota.com 
https://www.iooota.com
https://www.facebook.com/IOOOTA





--
View this message in context: 
http://karaf.922171.n3.nabble.com/Decanter-log-collector-flooding-OSGI-event-bus-tp4048415p4048434.html
Sent from the Karaf - User mailing list archive at Nabble.com.

Decanter log collector: flooding OSGI event bus?

[414n]

Greetings,

we recently had some issues that seem to relate to the decanter log
collector component in our karaf-based environment.
What we observed is that normal OSGI events are not delivered to our
components until we shut down decanter-related bundles. As soon as those are
shut down, a burst of OSGI events gets delivered all at once, making it look
like they were being held in some kind of queue.
Has this been observed before?



--
View this message in context: 
http://karaf.922171.n3.nabble.com/Decanter-log-collector-flooding-OSGI-event-bus-tp4048415.html
Sent from the Karaf - User mailing list archive at Nabble.com.

Re: Decanter log appender properties

[414n]

Well, after some experiments with the MDC method, I found out that my
custom property is set only in log messages coming from specific threads
and not globally, which is what I’m after…
This seems to be due to different ThreadPools running, as noted in the logback
MDC documentation <http://logback.qos.ch/manual/mdc.html>.
I then tried setting the system property karaf.name inside one of my
bundles to the desired dynamic value and it seems to work ok as of now for
the current need of a global ID.
​

2016-10-04 9:54 GMT+02:00 Alan Alberghini <a...@iooota.com>:

> Thanks for the advice, JB.
>
> In the end, I just added this instruction to add the property to the MDC:
>
> MDC.put("customProp", "AAA");
>
> While searching for solutions, I also found someone’s advice to change the
> ${karaf.name} property from root to the desired value, so that too would
> be forwarded via decanter to the appenders. May I ask you if there’s a way
> to do it programmatically from inside a bundle?
>
> On 30/09/2016 09:59, jbonofre [via Karaf] wrote:
>
> I meant that:
>
> 1. If you add key=value in
> etc/org.apache.karaf.decanter.collector.log.cfg file, it will be added
> to the event. So you can provide those custom properties using
> ConfigAdmin (on the org.apache.karaf.decanter.collector.log pid), but it
> will trigger a restart of the collector as the configuration will change.
>
> 2. IMHO, MDC for dynamic property is probably the best way to go.
>
> Regards
> JB
>
> On 09/30/2016 09:48 AM, 414n wrote:
>
> > Hi JB,
> >
> > thanks for the reply.
> > I'm not sure I understood correctly, but do you mean that the code I
> posted
> > would be good for setting the custom property I'd like to set? Because,
> for
> > what I saw, it did nothing and Decanter never added the custom property
> to
> > the collected logs...
> >
> >
> >
> >
> > --
> > View this message in context: http://karaf.922171.n3.nabble.
> com/Decanter-log-appender-properties-tp4048206p4048210.html
> > Sent from the Karaf - User mailing list archive at Nabble.com.
> >
>
> --
> Jean-Baptiste Onofré
> [hidden email] <http:///user/SendEmail.jtp?type=node=4048212=0>
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
>
> --
> If you reply to this email, your message will be added to the discussion
> below:
> http://karaf.922171.n3.nabble.com/Decanter-log-appender-
> properties-tp4048206p4048212.html
> To unsubscribe from Decanter log appender properties, click here
> <http://karaf.922171.n3.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code=4048206=YWxhbkBpb29vdGEuY29tfDQwNDgyMDZ8NjExMjcwNjA2>
> .
> NAML
> <http://karaf.922171.n3.nabble.com/template/NamlServlet.jtp?macro=macro_viewer=instant_html%21nabble%3Aemail.naml=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>
> ​
>




--
View this message in context: 
http://karaf.922171.n3.nabble.com/Decanter-log-appender-properties-tp4048206p4048249.html
Sent from the Karaf - User mailing list archive at Nabble.com.

Re: Decanter log appender properties

[414n]

Thanks for the advice, JB.

In the end, I just added this instruction to add the property to the MDC:

|MDC.put("customProp", "AAA"); |

While searching for solutions, I also found someone’s advice to change 
the |${karaf.name}| property from |root| to the desired value, so that 
too would be forwarded via decanter to the appenders. May I ask you if 
there’s a way to do it programmatically from inside a bundle?

On 30/09/2016 09:59, jbonofre [via Karaf] wrote:

> I meant that:
>
> 1. If you add key=value in
> etc/org.apache.karaf.decanter.collector.log.cfg file, it will be added
> to the event. So you can provide those custom properties using
> ConfigAdmin (on the org.apache.karaf.decanter.collector.log pid), but it
> will trigger a restart of the collector as the configuration will change.
>
> 2. IMHO, MDC for dynamic property is probably the best way to go.
>
> Regards
> JB
>
> On 09/30/2016 09:48 AM, 414n wrote:
>
> > Hi JB,
> >
> > thanks for the reply.
> > I'm not sure I understood correctly, but do you mean that the code I 
> posted
> > would be good for setting the custom property I'd like to set? 
> Because, for
> > what I saw, it did nothing and Decanter never added the custom 
> property to
> > the collected logs...
> >
> >
> >
> >
> > --
> > View this message in context: 
> http://karaf.922171.n3.nabble.com/Decanter-log-appender-properties-tp4048206p4048210.html
> > Sent from the Karaf - User mailing list archive at Nabble.com.
> >
>
> -- 
> Jean-Baptiste Onofré
> [hidden email] 
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
>
> 
> If you reply to this email, your message will be added to the 
> discussion below:
> http://karaf.922171.n3.nabble.com/Decanter-log-appender-properties-tp4048206p4048212.html
>  
>
> To unsubscribe from Decanter log appender properties, click here 
> <http://karaf.922171.n3.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code=4048206=YWxhbkBpb29vdGEuY29tfDQwNDgyMDZ8NjExMjcwNjA2>.
> NAML 
> <http://karaf.922171.n3.nabble.com/template/NamlServlet.jtp?macro=macro_viewer=instant_html%21nabble%3Aemail.naml=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>  
>

​




--
View this message in context: 
http://karaf.922171.n3.nabble.com/Decanter-log-appender-properties-tp4048206p4048231.html
Sent from the Karaf - User mailing list archive at Nabble.com.

Re: Decanter log appender properties

[414n]

Hi JB,

thanks for the reply.
I'm not sure I understood correctly, but do you mean that the code I posted
would be good for setting the custom property I'd like to set? Because, for
what I saw, it did nothing and Decanter never added the custom property to
the collected logs...




--
View this message in context: 
http://karaf.922171.n3.nabble.com/Decanter-log-appender-properties-tp4048206p4048210.html
Sent from the Karaf - User mailing list archive at Nabble.com.

Decanter log appender properties

[414n]

Greetings,I'm currently testing out Decanter as a monitoring solution for
Karaf and so far so good.What I'd like to do is to append custom properties
to the data sent over from the collectors to the appender, but I didn't find
a reliable way to do it.Looking at the  log collector code

 
, I saw that if there are component properties defined these get sent too
alongside the "static ones" like timestamp, loggername, message etc.I tried
injecting the custom properties I would like to send programmatically using
the ConfigAdmin service to no avail. Only by setting a static property
inside the feature.xml of my bundles I was able to see it on the appender
side:However, the property I'm trying to send are dynamic in nature and
cannot be put in static configuration files.The way I'm using the
ConfigAdmin service is this:Can anybody please tell me what I'm doing wrong?



--
View this message in context: 
http://karaf.922171.n3.nabble.com/Decanter-log-appender-properties-tp4048206.html
Sent from the Karaf - User mailing list archive at Nabble.com.

karaf-maven-plugin 4.0.6: blacklistFeature error

[414n]

Greetings,

I'm trying to upgrade my karaf distribution to version 4.0.6 using the
same-versioned karaf-maven-plugin but I stumble upon an this error every
time I build my karaf-assembly project:


The 'aBlacklistedFeature' feature is blacklist like this in the pom.xml:


The same pom setting was fine both with the 4.0.4 and 4.0.5 versions of the
karaf-maven-plugin.
Could this be related to the changes in the features' service enforcement
code, as discussed  here

 
?



--
View this message in context: 
http://karaf.922171.n3.nabble.com/karaf-maven-plugin-4-0-6-blacklistFeature-error-tp4048098.html
Sent from the Karaf - User mailing list archive at Nabble.com.

Re: [Karaf-4.0.3] Problem Building Karaf with maven

[414n]

Ok, it seems like I found a workaround.

It seems like if one overrides the verify goal of the karaf-maven-plugin 
adding its own features, it then builds an assembly flawlessly.
Here's a link to the gist 
<https://gist.github.com/rocketraman/914c55ab8577c95d3408> I found where 
this workaround is implemented. Thanks to Raman Gupta for sharing it online.

Alan Alberghini
IOOOTA - a...@iooota.com <mailto:a...@iooota.com>
http://www.iooota.com
https://www.facebook.com/IOOOTA
On 08/03/2016 13:11, jbonofre [via Karaf] wrote:
> OK, let me update the pom with your comments and what you need, and I
> will get back to you.
>
> Regards
> JB
>
> On 03/08/2016 12:05 PM, 414n wrote:
>
> > Hi JB,
> >
> > thanks for your response and for your time.
> >
> > I tried your solution and I was able to finally create the package, but
> > there are still some issues:
> >
> >* removing the eventadmin feature causes again the same error, so I
> >  assume the missing org.slf4j dependency is indeed pulled in by 
> this
> >  feature instead of the "log" one inside the standard feature,
> >  although I kinda don't understand this;
> >* the distribution package created doesn't automatically start my 
> FOI
> >  (Feature Of Interest :-)) as expected, but moving it again to the
> >  startupFeatures breaks the build with the same "org.slf4j missing"
> >  error;
> >* having my feature both in the "bootFeatures" and "startupFeatures"
> >  sections makes me able to build the package, but then it doesn't
> >  start automatically nor it appears as installed when karaf is 
> started
> >* using the "standard" feature seems to work fine after the 
> dependency
> >  fixes you listed.
> >
> > My bundles are correctly installed inside the system/ folder, but then
> > karaf doesn't list them and gives me an error also when trying to 
> add my
> > feature to the feature-repos.
> > Am I missing something?
> >
> >
> > Alan Alberghini
> > IOOOTA - [hidden email] 
>  <mailto:[hidden 
> email] >
> > http://www.iooota.com
> > https://www.facebook.com/IOOOTA
> > On 08/03/2016 11:16, jbonofre [via Karaf] wrote:
> >> Hi,
> >>
> >> I fixed your pom (see later in this e-mail).
> >>
> >> Basically:
> >> 1. the scope of the framework kar was not correct (it should be 
> compile,
> >> not runtime)
> >> 2. the framework feature was missing (for eventadmin)
> >> 3. the scope of your feature and standard feature was not correct
> >>
> >> So, I changed the dependencies this way:
> >>
> >>   
> >>   
> >> org.apache.karaf.features
> >> framework
> >>   4.0.4
> >>   kar
> >>   
> >>   
> >> org.apache.karaf.features
> >> framework
> >>   4.0.4
> >> features
> >>   xml
> >>   runtime
> >>   
> >>   
> >> org.apache.karaf.features
> >> standard
> >>   4.0.4
> >> features
> >>   xml
> >>   
> >>   
> >> this.is.a.test
> >>   karaf-feature
> >> 0.0.1-SNAPSHOT
> >> features
> >>   xml
> >>   
> >>   
> >>
> >> And the karaf-maven-plugin configuration is:
> >>
> >>   
> >> org.apache.karaf.tooling
> >> karaf-maven-plugin
> >>   
> >>   
> >> wrapper
> >>   
> >>   
> >> eventadmin
> >>   
> >>   
> >> framework
> >> wrap
> >>   aries-blueprint
> >> shell
> >>   shell-compat
> >> feature
> >> jaas
> >> ssh
> >> management
> >> bundle
> >> config
> >> deployer
> >> diagnostic
> >> feature
> >> instance
> >> kar
> >> log
> >> package
> >> service
> >> system
> >>   karaf-feature
> >>   
> >>   
> >>   
> >>
> >>
> >> Regards
> >> JB
> >>
> >> On 03/08/2016 10:46 AM, 414n wrote:
> >>
> >>> I reproduced 

Re: [Karaf-4.0.3] Problem Building Karaf with maven

[414n]

Hi JB,

thanks for your response and for your time.

I tried your solution and I was able to finally create the package, but 
there are still some issues:

  * removing the eventadmin feature causes again the same error, so I
assume the missing org.slf4j dependency is indeed pulled in by this
feature instead of the "log" one inside the standard feature,
although I kinda don't understand this;
  * the distribution package created doesn't automatically start my FOI
(Feature Of Interest :-)) as expected, but moving it again to the
startupFeatures breaks the build with the same "org.slf4j missing"
error;
  * having my feature both in the "bootFeatures" and "startupFeatures"
sections makes me able to build the package, but then it doesn't
start automatically nor it appears as installed when karaf is started
  * using the "standard" feature seems to work fine after the dependency
fixes you listed.

My bundles are correctly installed inside the system/ folder, but then 
karaf doesn't list them and gives me an error also when trying to add my 
feature to the feature-repos.
Am I missing something?


Alan Alberghini
IOOOTA - a...@iooota.com <mailto:a...@iooota.com>
http://www.iooota.com
https://www.facebook.com/IOOOTA
On 08/03/2016 11:16, jbonofre [via Karaf] wrote:
> Hi,
>
> I fixed your pom (see later in this e-mail).
>
> Basically:
> 1. the scope of the framework kar was not correct (it should be compile,
> not runtime)
> 2. the framework feature was missing (for eventadmin)
> 3. the scope of your feature and standard feature was not correct
>
> So, I changed the dependencies this way:
>
>  
>  
>  org.apache.karaf.features
>  framework
>  4.0.4
>  kar
>  
>  
>  org.apache.karaf.features
>  framework
>  4.0.4
>  features
>  xml
>  runtime
>  
>  
>  org.apache.karaf.features
>  standard
>  4.0.4
>  features
>  xml
>  
>  
>  this.is.a.test
>  karaf-feature
>  0.0.1-SNAPSHOT
>  features
>  xml
>  
>  
>
> And the karaf-maven-plugin configuration is:
>
>  
>  org.apache.karaf.tooling
>  karaf-maven-plugin
>  
>  
>  wrapper
>  
>  
>  eventadmin
>  
>  
>  framework
>  wrap
>  aries-blueprint
>  shell
>  shell-compat
>  feature
>  jaas
>  ssh
>  management
>  bundle
>  config
>  deployer
>  diagnostic
>  feature
>  instance
>  kar
>  log
>  package
>  service
>  system
>  karaf-feature
>  
>  
>  
>
>
> Regards
> JB
>
> On 03/08/2016 10:46 AM, 414n wrote:
>
> > I reproduced the issue in a really slimmed down two-project setup.
> > I created a feature that wraps the commons-lang-2.2 library (which 
> is not a
> > native bundle) and tried to assembly it.
> > You can find the projects (plus a reactor pom) inside the attached 
> zip file:
> > karaf-assembly-test.zip
> > 
> <http://karaf.922171.n3.nabble.com/file/n4045724/karaf-assembly-test.zip>
> >
> >
> >
> > --
> > View this message in context: 
> http://karaf.922171.n3.nabble.com/Karaf-4-0-3-Problem-Building-Karaf-with-maven-tp4045152p4045724.html
> > Sent from the Karaf - User mailing list archive at Nabble.com.
> >
>
> -- 
> Jean-Baptiste Onofré
> [hidden email] 
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
>
> 
> If you reply to this email, your message will be added to the 
> discussion below:
> http://karaf.922171.n3.nabble.com/Karaf-4-0-3-Problem-Building-Karaf-with-maven-tp4045152p4045726.html
>  
>
> To unsubscribe from [Karaf-4.0.3] Problem Building Karaf with maven, 
> click here 
> <http://karaf.922171.n3.nabble.com/template/NamlServlet.jtp?macro=u

Re: [Karaf-4.0.3] Problem Building Karaf with maven

[414n]

I reproduced the issue in a really slimmed down two-project setup.
I created a feature that wraps the commons-lang-2.2 library (which is not a
native bundle) and tried to assembly it.
You can find the projects (plus a reactor pom) inside the attached zip file: 
karaf-assembly-test.zip
  



--
View this message in context: 
http://karaf.922171.n3.nabble.com/Karaf-4-0-3-Problem-Building-Karaf-with-maven-tp4045152p4045724.html
Sent from the Karaf - User mailing list archive at Nabble.com.

Re: [Karaf-4.0.3] Problem Building Karaf with maven

[414n]

HI JB,

as already stated in my previous message, the "standard" feature is 
indeed listed both as a maven dependency and as a "bootFeature" in my 
karaf-assembly POM.
I didn't mention it previously, but my POM originates from the 
karaf-assembly archetype and I did little to no changes to it.
Looking at the POM you linked to, I just tried adding the "eventadmin" 
startupFeature and moving my own feature to the "bootFeatures" section 
(as suggested by Mike) and a package is indeed produced, but my bundles 
are not automatically installed nor started then. Moving my feature back 
to the startupFeatures section from the bootFeatures break again the 
build with the aforementioned error message.
If it can be useful, I think I can provide two POMs to reproduce the issue.


Alan Alberghini
IOOOTA - a...@iooota.com <mailto:a...@iooota.com>
http://www.iooota.com
https://www.facebook.com/IOOOTA
On 08/03/2016 07:43, jbonofre [via Karaf] wrote:
> Hi,
>
> the log feature is probably missing in the pom.xml. Take a look on the
> default Karaf standard distribution:
>
> https://github.com/apache/karaf/blob/karaf-4.0.x/assemblies/apache-karaf/pom.xml
>
> You can see the default boot features containing log.
>
> For convenience, you can use the standard feature which is a wrap for
> all standard features.
>
> Regards
> JB
>
> On 03/07/2016 06:16 PM, 414n wrote:
>
> > Greetings,
> >
> > it seems I stumbled upon this error too but I cannot find a way out, 
> even
> > moving bundles to the bootFeatures section does not help.
> > As soon as at least one of the dependencies in my feature is not a 
> valid
> > bundle and the wrap feature is added, the build always fails with 
> the error
> > you reported:
> > [ERROR] Failed to execute goal
> > org.apache.karaf.tooling:karaf-maven-plugin:4.0.4:assembly
> > (default-assembly) on project karaf-assembly: Unable to build assembly:
> > Unable to resolve root: missing requirement [root] osgi.identity;
> > osgi.identity=wrap; type=karaf.feature; version=0;
> > filter:="(&(osgi.identity=wrap)(type=karaf.feature)(version>=0.0.0))"
> > [caused by: Unable to resolve wrap/0.0.0: missing requirement 
> [wrap/0.0.0]
> > osgi.identity; osgi.identity=org.ops4j.pax.url.wrap; type=osgi.bundle;
> > version="[2.4.5,2.4.5]"; resolution:=mandatory [caused by: Unable to 
> resolve
> > org.ops4j.pax.url.wrap/2.4.5: missing requirement
> > [org.ops4j.pax.url.wrap/2.4.5] osgi.wiring.package;
> > 
> filter:="(&(osgi.wiring.package=org.slf4j)(version>=1.6.0)(!(version>=2.0.0)))"]]
> >
> > As you can see, this happens with the latest stable (4.0.4) but also 
> with
> > the latest snapshot available (4.0.5-SNAPSHOT) as well:
> > [ERROR] Failed to execute goal
> > org.apache.karaf.tooling:karaf-maven-plugin:4.0.5-SNAPSHOT:assembly
> > (default-assembly) on project karaf-assembly: Unable to build assembly:
> > Unable to resolve root: missing requirement [root] osgi.identity;
> > osgi.identity=wrap; type=karaf.feature; version=0;
> > filter:="(&(osgi.identity=wrap)(type=karaf.feature)(version>=0.0.0))"
> > [caused by: Unable to resolve wrap/0.0.0: missing requirement 
> [wrap/0.0.0]
> > osgi.identity; osgi.identity=org.ops4j.pax.url.wrap; type=osgi.bundle;
> > version="[2.4.6,2.4.6]"; resolution:=mandatory [caused by: Unable to 
> resolve
> > org.ops4j.pax.url.wrap/2.4.6: missing requirement
> > [org.ops4j.pax.url.wrap/2.4.6] osgi.wiring.package;
> > 
> filter:="(&(osgi.wiring.package=org.slf4j)(version>=1.6.0)(!(version>=2.0.0)))"]]
> >
> > I thought this might be caused by pax-logging-api not being 
> included, but
> > AFAICT it's part of the "standard" feature which I indeed added to my
> > bootFeatures.
> > Shall we open a bug report about this?
> >
> >
> >
> >
> > --
> > View this message in context: 
> http://karaf.922171.n3.nabble.com/Karaf-4-0-3-Problem-Building-Karaf-with-maven-tp4045152p4045714.html
> > Sent from the Karaf - User mailing list archive at Nabble.com.
> >
>
> -- 
> Jean-Baptiste Onofré
> [hidden email] 
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
>
> 
> If you reply to this email, your message will be added to the 
> discussion below:
> http://karaf.922171.n3.nabble.com/Karaf-4-0-3-Problem-Building-Karaf-with-maven-tp4045152p4045719.html
>  
>
> To unsubscribe from [Karaf-4.0.3] Problem Building Karaf with maven, 
> click here 
> 

Re: [Karaf-4.0.3] Problem Building Karaf with maven

[414n]

Greetings,

it seems I stumbled upon this error too but I cannot find a way out, even
moving bundles to the bootFeatures section does not help.
As soon as at least one of the dependencies in my feature is not a valid
bundle and the wrap feature is added, the build always fails with the error
you reported:
[ERROR] Failed to execute goal
org.apache.karaf.tooling:karaf-maven-plugin:4.0.4:assembly
(default-assembly) on project karaf-assembly: Unable to build assembly:
Unable to resolve root: missing requirement [root] osgi.identity;
osgi.identity=wrap; type=karaf.feature; version=0;
filter:="(&(osgi.identity=wrap)(type=karaf.feature)(version>=0.0.0))"
[caused by: Unable to resolve wrap/0.0.0: missing requirement [wrap/0.0.0]
osgi.identity; osgi.identity=org.ops4j.pax.url.wrap; type=osgi.bundle;
version="[2.4.5,2.4.5]"; resolution:=mandatory [caused by: Unable to resolve
org.ops4j.pax.url.wrap/2.4.5: missing requirement
[org.ops4j.pax.url.wrap/2.4.5] osgi.wiring.package;
filter:="(&(osgi.wiring.package=org.slf4j)(version>=1.6.0)(!(version>=2.0.0)))"]]

As you can see, this happens with the latest stable (4.0.4) but also with
the latest snapshot available (4.0.5-SNAPSHOT) as well:
[ERROR] Failed to execute goal
org.apache.karaf.tooling:karaf-maven-plugin:4.0.5-SNAPSHOT:assembly
(default-assembly) on project karaf-assembly: Unable to build assembly:
Unable to resolve root: missing requirement [root] osgi.identity;
osgi.identity=wrap; type=karaf.feature; version=0;
filter:="(&(osgi.identity=wrap)(type=karaf.feature)(version>=0.0.0))"
[caused by: Unable to resolve wrap/0.0.0: missing requirement [wrap/0.0.0]
osgi.identity; osgi.identity=org.ops4j.pax.url.wrap; type=osgi.bundle;
version="[2.4.6,2.4.6]"; resolution:=mandatory [caused by: Unable to resolve
org.ops4j.pax.url.wrap/2.4.6: missing requirement
[org.ops4j.pax.url.wrap/2.4.6] osgi.wiring.package;
filter:="(&(osgi.wiring.package=org.slf4j)(version>=1.6.0)(!(version>=2.0.0)))"]]

I thought this might be caused by pax-logging-api not being included, but
AFAICT it's part of the "standard" feature which I indeed added to my
bootFeatures.
Shall we open a bug report about this?




--
View this message in context: 
http://karaf.922171.n3.nabble.com/Karaf-4-0-3-Problem-Building-Karaf-with-maven-tp4045152p4045714.html
Sent from the Karaf - User mailing list archive at Nabble.com.