Re: Cellar version bound to Apache Karaf 4.0.8

[Cristiano Costantini]

Ignite?
... mmm ... is it an alternative to Hazelcast?
if yes, do you think it will replace Hazelcast as default IMDG
implementation in Cellar?

Il giorno lun 16 gen 2017 alle ore 10:58 Jean-Baptiste Onofré <
j...@nanthrax.net> ha scritto:

> By the way, I plan a Cellar 4.0.4 release pretty soon with bunch of
> improvement and Hazelcast update (and I plan to align with Camel as well).
>
> I also started the Ignite support (for Cellar 4.1.x).
>
> Regards
> JB
>
> On 01/16/2017 10:55 AM, Jean-Baptiste Onofré wrote:
> > Hi Cristiano,
> >
> > any Cellar 4.0.x version works with any Karaf 4.0.x version.
> >
> > So Cellar 4.0.3 can work with Karaf 4.0.8 for instance.
> >
> > Regards
> > JB
> >
> > On 01/16/2017 09:51 AM, Cristiano Costantini wrote:
> >> Hi All,
> >>
> >> quick question about Cellar Version:
> >>
> >> do you know which version of Cellar is bound to Apache Karaf 4.0.8?
> >> (...and which underlying version of Hazelcast?)
> >>
> >> Thanks,
> >> Cristiano
> >>
> >
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>

Cellar version bound to Apache Karaf 4.0.8

[Cristiano Costantini]

Hi All,

quick question about Cellar Version:

do you know which version of Cellar is bound to Apache Karaf 4.0.8?
(...and which underlying version of Hazelcast?)

Thanks,
Cristiano

Re: [HEADS UP] Preparing Karaf Cellar 4.0.2 and Karaf Container 4.0.7

[Cristiano Costantini]

Thank you very much JB!

Il giorno gio 1 set 2016 alle ore 07:48 Jean-Baptiste Onofré <
j...@nanthrax.net> ha scritto:

> Hi Cristiano,
>
> I plan to align the artifact and version with Camel (2.17.x), and use
> dependency flag on the features XML.
>
> It should be better (I will test).
>
> Regards
> JB
>
> On 09/01/2016 07:45 AM, Cristiano Costantini wrote:
> > Hello JB,
> > which version of Hazelcast will be used by Cellar 4.0.2?
> >
> > I'm happy of a new version for cellar,
> > I just want to remember that if you use camel-hazelcast inside Karaf it
> > will install its own bundle of hazelcast if it is not the same version
> used
> > by cellar and this caused me a lot of issues last time I tried Cellar
> 4.0.1
> > and I would be happier if in next releases this is addressed (anyway this
> > problem should probably be addressed in Camel project)
> >
> > Regards,
> > Cristiano
> >
> >
> >
> >
> >
> > Il giorno mer 31 ago 2016 alle ore 21:00 Grzegorz Grzybek <
> > gr.grzy...@gmail.com> ha scritto:
> >
> >> No problem for me. For my classloader leak fixes, I need new Jetty 9.2.x
> >> anyway, it should be ready next week.
> >> So if you still plan to release 4.2.9 of pax-web, you can check my
> >> https://github.com/ops4j/org.ops4j.pax.web/commits/ggrzybek-leak-fixes
> >> branch with fixes to:
> >>  - PAXWEB-1011: Leaked org.ops4j.pax.web.service.spi.ServerListener in
> >> HttpServiceStarted
> >>  - PAXWEB-1012: Filters are not unregistered correctly
> >>  - PAXWEB-1013: Incorrect reference counting for ServletContextInfo
> >>
> >> regards
> >> Grzegorz
> >>
> >> 2016-08-31 15:27 GMT+02:00 Jean-Baptiste Onofré <j...@nanthrax.net>:
> >>
> >>> Thanks Grzegorz
> >>>
> >>> I plan to release Pax Web 4.2.9 tomorrow.
> >>>
> >>> Let me know when it's OK by your side.
> >>>
> >>> Regards
> >>> JB
> >>>
> >>>
> >>> On 08/31/2016 03:20 PM, Grzegorz Grzybek wrote:
> >>>
> >>>> Hello
> >>>>
> >>>> I found several problems related to pax-web and I think I've finally
> >>>> fixed'em all (at least pax-web-extender-war doesn't leak
> >>>> HttpServiceContexts anymore). I'll try to fix in pax-web-4.2.x branch
> >>>> today
> >>>> and then Karaf 4.0.7 would include pax-web-4.2.9.
> >>>>
> >>>> regards
> >>>> Grzegorz Grzybek
> >>>>
> >>>> 2016-08-31 10:38 GMT+02:00 Jean-Baptiste Onofré <j...@nanthrax.net>:
> >>>>
> >>>> Hi guys,
> >>>>>
> >>>>> FYI, I started to prepare Cellar 4.0.2 release.
> >>>>> If you have some improvements or bugs for which we don't have a Jira,
> >>>>> please let me know.
> >>>>>
> >>>>> Once Cellar release will be on vote, I will start to prepare Karaf
> >> 4.0.7.
> >>>>>
> >>>>> 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
>

Re: [HEADS UP] Preparing Karaf Cellar 4.0.2 and Karaf Container 4.0.7

[Cristiano Costantini]

Hello JB,
which version of Hazelcast will be used by Cellar 4.0.2?

I'm happy of a new version for cellar,
I just want to remember that if you use camel-hazelcast inside Karaf it
will install its own bundle of hazelcast if it is not the same version used
by cellar and this caused me a lot of issues last time I tried Cellar 4.0.1
and I would be happier if in next releases this is addressed (anyway this
problem should probably be addressed in Camel project)

Regards,
Cristiano





Il giorno mer 31 ago 2016 alle ore 21:00 Grzegorz Grzybek <
gr.grzy...@gmail.com> ha scritto:

> No problem for me. For my classloader leak fixes, I need new Jetty 9.2.x
> anyway, it should be ready next week.
> So if you still plan to release 4.2.9 of pax-web, you can check my
> https://github.com/ops4j/org.ops4j.pax.web/commits/ggrzybek-leak-fixes
> branch with fixes to:
>  - PAXWEB-1011: Leaked org.ops4j.pax.web.service.spi.ServerListener in
> HttpServiceStarted
>  - PAXWEB-1012: Filters are not unregistered correctly
>  - PAXWEB-1013: Incorrect reference counting for ServletContextInfo
>
> regards
> Grzegorz
>
> 2016-08-31 15:27 GMT+02:00 Jean-Baptiste Onofré :
>
> > Thanks Grzegorz
> >
> > I plan to release Pax Web 4.2.9 tomorrow.
> >
> > Let me know when it's OK by your side.
> >
> > Regards
> > JB
> >
> >
> > On 08/31/2016 03:20 PM, Grzegorz Grzybek wrote:
> >
> >> Hello
> >>
> >> I found several problems related to pax-web and I think I've finally
> >> fixed'em all (at least pax-web-extender-war doesn't leak
> >> HttpServiceContexts anymore). I'll try to fix in pax-web-4.2.x branch
> >> today
> >> and then Karaf 4.0.7 would include pax-web-4.2.9.
> >>
> >> regards
> >> Grzegorz Grzybek
> >>
> >> 2016-08-31 10:38 GMT+02:00 Jean-Baptiste Onofré :
> >>
> >> Hi guys,
> >>>
> >>> FYI, I started to prepare Cellar 4.0.2 release.
> >>> If you have some improvements or bugs for which we don't have a Jira,
> >>> please let me know.
> >>>
> >>> Once Cellar release will be on vote, I will start to prepare Karaf
> 4.0.7.
> >>>
> >>> 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: [VOTE] Apache Karaf Cellar 4.0.1 release

[Cristiano Costantini]

Hi again,
at first I've tested my application with cellar 4.0.1 and everything seemed
to be working,
but after that, I'm having issues with FeatureServiceImpl and with felix
ResolverImpl and the container randomly fails to start.

After some investigation, I've discovered one potential cause in
camel-hazelcast:

The camel hazelcast feature installs the Hazelcast bundle with version
3.5.2:
karaf@root>feature:info camel-hazelcast
Feature camel-hazelcast 2.16.3
Feature has no configuration
Feature has no configuration files
Feature depends on:
  camel-core 2.16.3
  transaction 0.0.0
Feature contains followed bundles:

mvn:org.apache.servicemix.specs/org.apache.servicemix.specs.scripting-api-1.0/2.5.0
  mvn:com.eclipsesource.minimal-json/minimal-json/0.9.4
  mvn:com.hazelcast/hazelcast/3.5.2
  mvn:com.hazelcast/hazelcast-client/3.5.2
  mvn:org.apache.camel/camel-hazelcast/2.16.3
Feature has no conditionals.


Raising up the felix log level I've discovered that during installation of
the features, the ResolverImpl loops over this:

DEBUG: Candidate permutation failed due to a conflict between imports; will
try another if possible. (Uses constraint violation. Unable to resolve
resource org.apache.camel.camel-hazelcast
[org.apache.camel.camel-hazelcast/2.16.3] because it is exposed to package
'com.hazelcast.config' from resources com.hazelcast [com.hazelcast/3.5.2]
and com.hazelcast [com.hazelcast/3.6.4] via two dependency chains.

Chain 1:
  org.apache.camel.camel-hazelcast [org.apache.camel.camel-hazelcast/2.16.3]
import:
(&(osgi.wiring.package=com.hazelcast.config)(version>=3.2.0)(!(version>=4.0.0)))
 |
export: osgi.wiring.package: com.hazelcast.config
  com.hazelcast [com.hazelcast/3.5.2]

Chain 2:
  org.apache.camel.camel-hazelcast [org.apache.camel.camel-hazelcast/2.16.3]
import:
(&(osgi.wiring.package=com.hazelcast.config)(version>=3.2.0)(!(version>=4.0.0)))
 |
export: osgi.wiring.package=com.hazelcast.config;
uses:=com.hazelcast.core
  com.hazelcast [com.hazelcast/3.5.2]
import:
(&(osgi.wiring.package=com.hazelcast.core)(version>=3.6.0)(!(version>=4.0.0)))
 |
export: osgi.wiring.package=com.hazelcast.core; uses:=com.hazelcast.core
  com.hazelcast [com.hazelcast/3.6.4]
import:
(&(osgi.wiring.package=com.hazelcast.core)(version>=3.6.0)(!(version>=4.0.0)))
 |
export: osgi.wiring.package: com.hazelcast.core;
uses:=com.hazelcast.config
export: osgi.wiring.package=com.hazelcast.config
  com.hazelcast [com.hazelcast/3.6.4])



Anyway I'm still opting up for a +1 (non binding) vote,
and I'm thinking to fix locally the problem by substituting the original
camel-hazelcast feature, with one written by myself which instead of
installing directly the hazelcast bundle, it depends on the cellar's
hazelcast, I'll try with something like:


camel-core
transaction
hazelcast 

mvn:org.apache.servicemix.specs/org.apache.servicemix.specs.scripting-api-1.0/2.5.0
mvn:com.eclipsesource.minimal-json/minimal-json/0.9.4
mvn:org.apache.camel/camel-hazelcast/2.16.3



I'll let you know if the problems are resolved.

Thank you,
Cristiano


P.S. I don't think it is just a problem of an infinite loop caused by the
dependencies: it happen that it fails to start once every 2 launches
(features are loaded at bootstrap). I still believe that the
FeatureServiceImpl and the felix ResolverImpl have some kind of concurrency
problem, and managing the version of Hazelcast will only reduce the
probability of having a deadlock or livelock at startup, but it will not
fix it.







Il giorno mer 13 lug 2016 alle ore 12:13 Jamie G. <jamie.goody...@gmail.com>
ha scritto:

> +1 (binding)
>
> Cheers,
> Jamie
>
> On Wed, Jul 13, 2016 at 4:25 AM, Cristiano Costantini
> <cristiano.costant...@gmail.com> wrote:
> > +1 (non binding)
> >
> >
> >
> > Il giorno mar 12 lug 2016 alle ore 18:36 Christian Schneider <
> > ch...@die-schneider.net> ha scritto:
> >
> >> +1 (non binding)
> >>
> >> Christian
> >>
> >> 2016-07-11 22:27 GMT+02:00 Jean-Baptiste Onofré <j...@nanthrax.net>:
> >>
> >> > Hi all,
> >> >
> >> > I submit Apache Karaf Cellar 4.0.1 to your vote.
> >> >
> >> > Release Notes:
> >> >
> >> >
> >>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12334169
> >> >
> >> > Staging Repository:
> >> >
> https://repository.apache.org/content/repositories/orgapachekaraf-1067/
> >> >
> >> > Please vote to approve this release:
> >> >
> >> > [ ] +1 Approve the release
> >> > [ ] -1 Don't approve the release (please provide specific comments)
> >> >
> >> > This vote will b

Re: Karaf 4: Deadlocks and Livelocks when installing features

[Cristiano Costantini]

...while in a "LiveLock" condition, I have inspected with JVisualVM the
status of the JVM and I've taken the following screenshots that show where
more cpu time is spent:

http://imgur.com/vp6zJCl
http://imgur.com/FwIP8Ag
http://imgur.com/ld8QBf4





Il giorno mer 13 lug 2016 alle ore 17:15 Cristiano Costantini <
cristiano.costant...@gmail.com> ha scritto:

> Some more (hopefully) useful info:
>
> in one condition I have a Deadlock, the last log entry recorded is this:
>
> 2016-07-13 17:06:49,231 | INFO  | pool-7-thread-1  | FeaturesServiceImpl
>| 9 - org.apache.karaf.features.core - 4.0.5 | Adding features:
> instance/[4.0.5,4.0.5], ssh/[4.0.5,4.0.5], webconsole/[4.0.5,4.0.5],
> aries-blueprint/[4.0.5,4.0.5], cxf/[3.1.5,3.1.5], []
>
> I've inspected the thread "pool-7-thread-1" and it is in this status:
> "pool-7-thread-1" #81 prio=5 os_prio=31 tid=0x7fbafc0e6000 nid=0x910b
> waiting on condition [0x72ea]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for  <0x0007bbbdc608> (a
> java.util.concurrent.FutureTask)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at java.util.concurrent.FutureTask.awaitDone(FutureTask.java:429)
> at java.util.concurrent.FutureTask.get(FutureTask.java:191)
> at
> org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvisionInThread(FeaturesServiceImpl.java:1051)
> at
> org.apache.karaf.features.internal.service.FeaturesServiceImpl.installFeatures(FeaturesServiceImpl.java:927)
> at
> org.apache.karaf.features.internal.service.FeaturesServiceImpl.installFeatures(FeaturesServiceImpl.java:820)
> at
> org.apache.karaf.features.internal.service.BootFeaturesInstaller.installBootFeatures(BootFeaturesInstaller.java:112)
> at
> org.apache.karaf.features.internal.service.BootFeaturesInstaller.start(BootFeaturesInstaller.java:92)
> at
> org.apache.karaf.features.internal.osgi.Activator.doStart(Activator.java:259)
> at org.apache.karaf.util.tracker.BaseActivator.run(BaseActivator.java:233)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
>
>
> the thread stay in "parked" status for about 120 seconds then it
> terminates and Karaf does not respond to any command. I can only terminate
> it with CTRL-C (note: not CTRL-D to shut it down, exactly CTRL-C)
>
>
>
>
> Il giorno mer 13 lug 2016 alle ore 17:00 Cristiano Costantini <
> cristiano.costant...@gmail.com> ha scritto:
>
>> Hi all,
>>
>> Since I have updated to Karaf 4, sometime when I install a feature or
>> when Karaf starts with some specific combination of bootstrap features,
>> it happen that Karaf goes either in what it seems a Deadlock (Karaf hang
>> indefinitely and the feature is not installed) or a Livelock (same as
>> before but with CPU usage that jumps to 100%)
>>
>> I'm not able to debug exactly and the effect is not always repeatable,
>> some time it don't works, some other it works.
>>
>> Are there any current issue about the feature installation that may be
>> the cause of this behavior?
>>
>> thank you for the help!
>>
>> Cristiano
>>
>>
>> P.S. I define my features in a file with the namespace,
>> http://karaf.apache.org/xmlns/features/v1.4.0 so the I understand that
>> "feature resolver checks the service requirements/capabilities of bundles
>> for new features (xml schema >= 1.3.0) in order to automatically installs
>> the required bundles". What does this mean?
>>
>>
>>

Re: Karaf 4: Deadlocks and Livelocks when installing features

[Cristiano Costantini]

Some more (hopefully) useful info:

in one condition I have a Deadlock, the last log entry recorded is this:

2016-07-13 17:06:49,231 | INFO  | pool-7-thread-1  | FeaturesServiceImpl
   | 9 - org.apache.karaf.features.core - 4.0.5 | Adding features:
instance/[4.0.5,4.0.5], ssh/[4.0.5,4.0.5], webconsole/[4.0.5,4.0.5],
aries-blueprint/[4.0.5,4.0.5], cxf/[3.1.5,3.1.5], []

I've inspected the thread "pool-7-thread-1" and it is in this status:
"pool-7-thread-1" #81 prio=5 os_prio=31 tid=0x7fbafc0e6000 nid=0x910b
waiting on condition [0x72ea]
   java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for  <0x0007bbbdc608> (a
java.util.concurrent.FutureTask)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at java.util.concurrent.FutureTask.awaitDone(FutureTask.java:429)
at java.util.concurrent.FutureTask.get(FutureTask.java:191)
at
org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvisionInThread(FeaturesServiceImpl.java:1051)
at
org.apache.karaf.features.internal.service.FeaturesServiceImpl.installFeatures(FeaturesServiceImpl.java:927)
at
org.apache.karaf.features.internal.service.FeaturesServiceImpl.installFeatures(FeaturesServiceImpl.java:820)
at
org.apache.karaf.features.internal.service.BootFeaturesInstaller.installBootFeatures(BootFeaturesInstaller.java:112)
at
org.apache.karaf.features.internal.service.BootFeaturesInstaller.start(BootFeaturesInstaller.java:92)
at
org.apache.karaf.features.internal.osgi.Activator.doStart(Activator.java:259)
at org.apache.karaf.util.tracker.BaseActivator.run(BaseActivator.java:233)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)


the thread stay in "parked" status for about 120 seconds then it terminates
and Karaf does not respond to any command. I can only terminate it with
CTRL-C (note: not CTRL-D to shut it down, exactly CTRL-C)




Il giorno mer 13 lug 2016 alle ore 17:00 Cristiano Costantini <
cristiano.costant...@gmail.com> ha scritto:

> Hi all,
>
> Since I have updated to Karaf 4, sometime when I install a feature or when
> Karaf starts with some specific combination of bootstrap features,
> it happen that Karaf goes either in what it seems a Deadlock (Karaf hang
> indefinitely and the feature is not installed) or a Livelock (same as
> before but with CPU usage that jumps to 100%)
>
> I'm not able to debug exactly and the effect is not always repeatable,
> some time it don't works, some other it works.
>
> Are there any current issue about the feature installation that may be the
> cause of this behavior?
>
> thank you for the help!
>
> Cristiano
>
>
> P.S. I define my features in a file with the namespace,
> http://karaf.apache.org/xmlns/features/v1.4.0 so the I understand that
> "feature resolver checks the service requirements/capabilities of bundles
> for new features (xml schema >= 1.3.0) in order to automatically installs
> the required bundles". What does this mean?
>
>
>

Karaf 4: Deadlocks and Livelocks when installing features

[Cristiano Costantini]

Hi all,

Since I have updated to Karaf 4, sometime when I install a feature or when
Karaf starts with some specific combination of bootstrap features,
it happen that Karaf goes either in what it seems a Deadlock (Karaf hang
indefinitely and the feature is not installed) or a Livelock (same as
before but with CPU usage that jumps to 100%)

I'm not able to debug exactly and the effect is not always repeatable, some
time it don't works, some other it works.

Are there any current issue about the feature installation that may be the
cause of this behavior?

thank you for the help!

Cristiano


P.S. I define my features in a file with the namespace,
http://karaf.apache.org/xmlns/features/v1.4.0 so the I understand that
"feature resolver checks the service requirements/capabilities of bundles
for new features (xml schema >= 1.3.0) in order to automatically installs
the required bundles". What does this mean?

Re: [VOTE] Apache Karaf Cellar 4.0.1 release

[Cristiano Costantini]

+1 (non binding)



Il giorno mar 12 lug 2016 alle ore 18:36 Christian Schneider <
ch...@die-schneider.net> ha scritto:

> +1 (non binding)
>
> Christian
>
> 2016-07-11 22:27 GMT+02:00 Jean-Baptiste Onofré :
>
> > Hi all,
> >
> > I submit Apache Karaf Cellar 4.0.1 to your vote.
> >
> > Release Notes:
> >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12334169
> >
> > Staging Repository:
> > https://repository.apache.org/content/repositories/orgapachekaraf-1067/
> >
> > Please vote to approve this release:
> >
> > [ ] +1 Approve the release
> > [ ] -1 Don't approve the release (please provide specific comments)
> >
> > This vote will be open for at least 72 hours.
> >
> > Thanks,
> > Regards
> > JB
> > --
> > Jean-Baptiste Onofré
> > jbono...@apache.org
> > http://blog.nanthrax.net
> > Talend - http://www.talend.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
> >
>

Re: Start/Stop bundles commands on symbolic name

[Cristiano Costantini]

no problem and thanks!

Il giorno mer 18 mag 2016 alle ore 08:32 Jean-Baptiste Onofré <
j...@nanthrax.net> ha scritto:

> Yup ;)
>
> Let me do it for you ;)
>
> Sorry for the inconvenience.
>
> Regards
> JB
>
> On 05/18/2016 08:27 AM, Achim Nierbeck wrote:
> > @Crsitiano, @Andrea but I think JB can enable you again ;)
> >
> > regards, Achim
> >
> >
> > 2016-05-18 8:22 GMT+02:00 Andrea Cosentino <ancosen1...@yahoo.com.invalid
> >:
> >
> >> There was a spam attack on Apache JIRA platform.
> >>
> >> At the moment people in the 'jira-users' group are no longer allowed to
> >> 'Create' tickets and are no
> >> longer allowed to 'Comment' on any tickets.
> >>
> >> --
> >> Andrea Cosentino
> >> --
> >> Apache Camel PMC Member
> >> Apache Karaf Committer
> >> Apache Servicemix Committer
> >> Email: ancosen1...@yahoo.com
> >> Twitter: @oscerd2
> >> Github: oscerd
> >>
> >>
> >>
> >>
> >> On Wednesday, May 18, 2016 8:07 AM, Cristiano Costantini <
> >> cristiano.costant...@gmail.com> wrote:
> >> Hello all,
> >> am I missing that something has changed in the issue opening process,
> >> or do I've lost capability to open issues on ASF Jira?
> >>
> >> Anyone else has problem opening issues?
> >>
> >> Thanks,
> >> Cristiano
> >>
> >>
> >>
> >> Il giorno mar 17 mag 2016 alle ore 17:08 Cristiano Costantini <
> >> cristiano.costant...@gmail.com> ha scritto:
> >>
> >>
> >>> Yeah,
> >>> ok for the Jira Issue
> >>>
> >>> P.S. If you like to give some suggestions/indications on how to do it,
> I
> >>> can try to make it by myself and propose a pull request.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> Il giorno mar 17 mag 2016 alle ore 17:06 Jean-Baptiste Onofré <
> >>> j...@nanthrax.net> ha scritto:
> >>>
> >>>> Hi Cristiano,
> >>>>
> >>>> ok, I see your point on the completer now ;)
> >>>>
> >>>> So, yes, I can implement a completer similar to the one I did in
> Cellar.
> >>>>
> >>>> Do you mind to create a Jira about that ?
> >>>>
> >>>> Regards
> >>>> JB
> >>>>
> >>>> On 05/17/2016 03:36 PM, Cristiano Costantini wrote:
> >>>>> Hi JB,
> >>>>>
> >>>>> yeah you are right, you can use symbolic name also in bundle:*
> >> commands.
> >>>>> What is cool in cluster:bundle-* commands is the autocompletion for
> >>>>> symbolic name...  this is missing on the bundle:* commands. Isn't it?
> >>>>>
> >>>>> Regards,
> >>>>> Cristiano
> >>>>>
> >>>>> P.S: sorry I didn't reply before!
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> Il giorno gio 5 mag 2016 alle ore 17:25 Jean-Baptiste Onofré <
> >>>>> j...@nanthrax.net> ha scritto:
> >>>>>
> >>>>>> Hi Cristiano,
> >>>>>>
> >>>>>> it should be already the case (BundleSelector in Karaf).
> >>>>>>
> >>>>>> Regards
> >>>>>> JB
> >>>>>>
> >>>>>> On 05/05/2016 05:18 PM, Cristiano Costantini wrote:
> >>>>>>> Hello all,
> >>>>>>>
> >>>>>>> in cellar it is possible to start or stop bundles using their
> >> symbolic
> >>>>>> name:
> >>>>>>>
> >>>>>>>   karaf@root> cluster:bundle-stop default
> >> my-bundle-symbolic-name
> >>>>>>>
> >>>>>>> and also provide autocompletion for the symbolic name,
> >>>>>>> while in normal karaf start and stop work only on bundle ID.
> >>>>>>>
> >>>>>>>   karaf@root> list -s | grep my-bundle
> >>>>>>>   123 | Active   |  80 | 1.0.0.SNAPSHOT  |
> >> my-bundle-symbolic-name
> >>>>>>>   karaf@root> bundle:stop 123
> >>>>>>>
> >>>>>>> is it possible to extend the basic commands to use the symbolic
> name
> >>>> as
> >>>>>> in
> >>>>>>> cellar?
> >>>>>>> would it be hard?
> >>>>>>>
> >>>>>>> Bye,
> >>>>>>> Cristiano
> >>>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> 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: Start/Stop bundles commands on symbolic name

[Cristiano Costantini]

Thank you Andrea!
Do you know if capability to open issues for jira-users will be reprised?
Or do I have to ask permission to join some other group if I want to create
a new ticket?

Regards,
Cristiano

Il giorno mer 18 mag 2016 alle ore 08:23 Andrea Cosentino
<ancosen1...@yahoo.com.invalid> ha scritto:

> There was a spam attack on Apache JIRA platform.
>
> At the moment people in the 'jira-users' group are no longer allowed to
> 'Create' tickets and are no
> longer allowed to 'Comment' on any tickets.
>
> --
> Andrea Cosentino
> --
> Apache Camel PMC Member
> Apache Karaf Committer
> Apache Servicemix Committer
> Email: ancosen1...@yahoo.com
> Twitter: @oscerd2
> Github: oscerd
>
>
>
>
> On Wednesday, May 18, 2016 8:07 AM, Cristiano Costantini <
> cristiano.costant...@gmail.com> wrote:
> Hello all,
> am I missing that something has changed in the issue opening process,
> or do I've lost capability to open issues on ASF Jira?
>
> Anyone else has problem opening issues?
>
> Thanks,
> Cristiano
>
>
>
> Il giorno mar 17 mag 2016 alle ore 17:08 Cristiano Costantini <
> cristiano.costant...@gmail.com> ha scritto:
>
>
> > Yeah,
> > ok for the Jira Issue
> >
> > P.S. If you like to give some suggestions/indications on how to do it, I
> > can try to make it by myself and propose a pull request.
> >
> >
> >
> >
> >
> > Il giorno mar 17 mag 2016 alle ore 17:06 Jean-Baptiste Onofré <
> > j...@nanthrax.net> ha scritto:
> >
> >> Hi Cristiano,
> >>
> >> ok, I see your point on the completer now ;)
> >>
> >> So, yes, I can implement a completer similar to the one I did in Cellar.
> >>
> >> Do you mind to create a Jira about that ?
> >>
> >> Regards
> >> JB
> >>
> >> On 05/17/2016 03:36 PM, Cristiano Costantini wrote:
> >> > Hi JB,
> >> >
> >> > yeah you are right, you can use symbolic name also in bundle:*
> commands.
> >> > What is cool in cluster:bundle-* commands is the autocompletion for
> >> > symbolic name...  this is missing on the bundle:* commands. Isn't it?
> >> >
> >> > Regards,
> >> > Cristiano
> >> >
> >> > P.S: sorry I didn't reply before!
> >> >
> >> >
> >> >
> >> >
> >> > Il giorno gio 5 mag 2016 alle ore 17:25 Jean-Baptiste Onofré <
> >> > j...@nanthrax.net> ha scritto:
> >> >
> >> >> Hi Cristiano,
> >> >>
> >> >> it should be already the case (BundleSelector in Karaf).
> >> >>
> >> >> Regards
> >> >> JB
> >> >>
> >> >> On 05/05/2016 05:18 PM, Cristiano Costantini wrote:
> >> >>> Hello all,
> >> >>>
> >> >>> in cellar it is possible to start or stop bundles using their
> symbolic
> >> >> name:
> >> >>>
> >> >>>  karaf@root> cluster:bundle-stop default
> my-bundle-symbolic-name
> >> >>>
> >> >>> and also provide autocompletion for the symbolic name,
> >> >>> while in normal karaf start and stop work only on bundle ID.
> >> >>>
> >> >>>  karaf@root> list -s | grep my-bundle
> >> >>>  123 | Active   |  80 | 1.0.0.SNAPSHOT  |
> my-bundle-symbolic-name
> >> >>>  karaf@root> bundle:stop 123
> >> >>>
> >> >>> is it possible to extend the basic commands to use the symbolic name
> >> as
> >> >> in
> >> >>> cellar?
> >> >>> would it be hard?
> >> >>>
> >> >>> Bye,
> >> >>> Cristiano
> >> >>>
> >> >>
> >> >> --
> >> >> 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: Start/Stop bundles commands on symbolic name

[Cristiano Costantini]

Hello all,
am I missing that something has changed in the issue opening process,
or do I've lost capability to open issues on ASF Jira?

Anyone else has problem opening issues?

Thanks,
Cristiano



Il giorno mar 17 mag 2016 alle ore 17:08 Cristiano Costantini <
cristiano.costant...@gmail.com> ha scritto:

> Yeah,
> ok for the Jira Issue
>
> P.S. If you like to give some suggestions/indications on how to do it, I
> can try to make it by myself and propose a pull request.
>
>
>
>
>
> Il giorno mar 17 mag 2016 alle ore 17:06 Jean-Baptiste Onofré <
> j...@nanthrax.net> ha scritto:
>
>> Hi Cristiano,
>>
>> ok, I see your point on the completer now ;)
>>
>> So, yes, I can implement a completer similar to the one I did in Cellar.
>>
>> Do you mind to create a Jira about that ?
>>
>> Regards
>> JB
>>
>> On 05/17/2016 03:36 PM, Cristiano Costantini wrote:
>> > Hi JB,
>> >
>> > yeah you are right, you can use symbolic name also in bundle:* commands.
>> > What is cool in cluster:bundle-* commands is the autocompletion for
>> > symbolic name...  this is missing on the bundle:* commands. Isn't it?
>> >
>> > Regards,
>> > Cristiano
>> >
>> > P.S: sorry I didn't reply before!
>> >
>> >
>> >
>> >
>> > Il giorno gio 5 mag 2016 alle ore 17:25 Jean-Baptiste Onofré <
>> > j...@nanthrax.net> ha scritto:
>> >
>> >> Hi Cristiano,
>> >>
>> >> it should be already the case (BundleSelector in Karaf).
>> >>
>> >> Regards
>> >> JB
>> >>
>> >> On 05/05/2016 05:18 PM, Cristiano Costantini wrote:
>> >>> Hello all,
>> >>>
>> >>> in cellar it is possible to start or stop bundles using their symbolic
>> >> name:
>> >>>
>> >>>  karaf@root> cluster:bundle-stop default my-bundle-symbolic-name
>> >>>
>> >>> and also provide autocompletion for the symbolic name,
>> >>> while in normal karaf start and stop work only on bundle ID.
>> >>>
>> >>>  karaf@root> list -s | grep my-bundle
>> >>>  123 | Active   |  80 | 1.0.0.SNAPSHOT  | my-bundle-symbolic-name
>> >>>  karaf@root> bundle:stop 123
>> >>>
>> >>> is it possible to extend the basic commands to use the symbolic name
>> as
>> >> in
>> >>> cellar?
>> >>> would it be hard?
>> >>>
>> >>> Bye,
>> >>> Cristiano
>> >>>
>> >>
>> >> --
>> >> 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: Start/Stop bundles commands on symbolic name

[Cristiano Costantini]

Yeah,
ok for the Jira Issue

P.S. If you like to give some suggestions/indications on how to do it, I
can try to make it by myself and propose a pull request.





Il giorno mar 17 mag 2016 alle ore 17:06 Jean-Baptiste Onofré <
j...@nanthrax.net> ha scritto:

> Hi Cristiano,
>
> ok, I see your point on the completer now ;)
>
> So, yes, I can implement a completer similar to the one I did in Cellar.
>
> Do you mind to create a Jira about that ?
>
> Regards
> JB
>
> On 05/17/2016 03:36 PM, Cristiano Costantini wrote:
> > Hi JB,
> >
> > yeah you are right, you can use symbolic name also in bundle:* commands.
> > What is cool in cluster:bundle-* commands is the autocompletion for
> > symbolic name...  this is missing on the bundle:* commands. Isn't it?
> >
> > Regards,
> > Cristiano
> >
> > P.S: sorry I didn't reply before!
> >
> >
> >
> >
> > Il giorno gio 5 mag 2016 alle ore 17:25 Jean-Baptiste Onofré <
> > j...@nanthrax.net> ha scritto:
> >
> >> Hi Cristiano,
> >>
> >> it should be already the case (BundleSelector in Karaf).
> >>
> >> Regards
> >> JB
> >>
> >> On 05/05/2016 05:18 PM, Cristiano Costantini wrote:
> >>> Hello all,
> >>>
> >>> in cellar it is possible to start or stop bundles using their symbolic
> >> name:
> >>>
> >>>  karaf@root> cluster:bundle-stop default my-bundle-symbolic-name
> >>>
> >>> and also provide autocompletion for the symbolic name,
> >>> while in normal karaf start and stop work only on bundle ID.
> >>>
> >>>  karaf@root> list -s | grep my-bundle
> >>>  123 | Active   |  80 | 1.0.0.SNAPSHOT  | my-bundle-symbolic-name
> >>>  karaf@root> bundle:stop 123
> >>>
> >>> is it possible to extend the basic commands to use the symbolic name as
> >> in
> >>> cellar?
> >>> would it be hard?
> >>>
> >>> Bye,
> >>> Cristiano
> >>>
> >>
> >> --
> >> 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: Start/Stop bundles commands on symbolic name

[Cristiano Costantini]

Hi JB,

yeah you are right, you can use symbolic name also in bundle:* commands.
What is cool in cluster:bundle-* commands is the autocompletion for
symbolic name...  this is missing on the bundle:* commands. Isn't it?

Regards,
Cristiano

P.S: sorry I didn't reply before!




Il giorno gio 5 mag 2016 alle ore 17:25 Jean-Baptiste Onofré <
j...@nanthrax.net> ha scritto:

> Hi Cristiano,
>
> it should be already the case (BundleSelector in Karaf).
>
> Regards
> JB
>
> On 05/05/2016 05:18 PM, Cristiano Costantini wrote:
> > Hello all,
> >
> > in cellar it is possible to start or stop bundles using their symbolic
> name:
> >
> > karaf@root> cluster:bundle-stop default my-bundle-symbolic-name
> >
> > and also provide autocompletion for the symbolic name,
> > while in normal karaf start and stop work only on bundle ID.
> >
> > karaf@root> list -s | grep my-bundle
> > 123 | Active   |  80 | 1.0.0.SNAPSHOT  | my-bundle-symbolic-name
> > karaf@root> bundle:stop 123
> >
> > is it possible to extend the basic commands to use the symbolic name as
> in
> > cellar?
> > would it be hard?
> >
> > Bye,
> > Cristiano
> >
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>

Start/Stop bundles commands on symbolic name

[Cristiano Costantini]

Hello all,

in cellar it is possible to start or stop bundles using their symbolic name:

   karaf@root> cluster:bundle-stop default my-bundle-symbolic-name

and also provide autocompletion for the symbolic name,
while in normal karaf start and stop work only on bundle ID.

   karaf@root> list -s | grep my-bundle
   123 | Active   |  80 | 1.0.0.SNAPSHOT  | my-bundle-symbolic-name
   karaf@root> bundle:stop 123

is it possible to extend the basic commands to use the symbolic name as in
cellar?
would it be hard?

Bye,
Cristiano

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

[Cristiano Costantini]

ok, then ignore my message ;-)
yes I prefer too the option 2


Il giorno mer 6 apr 2016 alle ore 08:39 Jean-Baptiste Onofré <
j...@nanthrax.net> ha scritto:

> Hi Cristiano,
>
> I don't think it's related, as the issue in about blueprint-ext
> namespace (not even define). The problem is located in Aries Blueprint.
>
> I gonna deal with Guillaume.
>
> We can:
> 0. leave Karaf 4.0.5 as it is, but I think it's not acceptable:
> blueprint is used by lot of users, and we can't allow a release without
> a working blueprint layer.
> 1. downgrade Karaf to Aries Blueprint 1.5.x: unfortunately, we won't
> benefit about some improvements implemented in blueprint
> 2. revert or fix the change in Aries: it means we would need a new Aries
> Blueprint core release, so 3 days vote, meaning that we won't be able to
> release Karaf before roughly 6 days.
>
> My preference is on 2 even if it delays Karaf 4.0.5 release.
>
> Thoughts ?
>
> I will add an Integration Test on blueprint to avoid such problem in the
> future.
>
> Regards
> JB
>
> On 04/06/2016 08:14 AM, Cristiano Costantini wrote:
> > Hi JB and Krzysztof,
> >
> > I don't know if this can be have any impact on the problem you have
> > reported, but about 1 month ago I got into an issue with camel XSD
> schemas
> > for Camel namespaces, and the issue is that the URL of the latest XSD,
> > http://camel.apache.org/schema/blueprint/camel-blueprint.xsd
> > is not from latest version 2.16.2, but it is from version 2.15.0
> >
> > While upgrading to ServiceMix 7, I had to change manually the XML to
> > xsi:schemaLocation="http://camel.apache.org/schema/spring http://camel
> > .apache.org/schema/spring/camel-spring-2.16.1.xsd" in order to make it
> work
> > (note also that SMX 7 is based on camel 2.16.2, but this XSD is not
> > available)
> >
> > But in fact the only problem I had was that Eclipse validation and
> > autocompletion of the XML files was not working properly.
> >
> > if this is not relevant, please ignore this message ;-)
> >
> > Cristiano
> >
> >
> >
> >
> > Il giorno mar 5 apr 2016 alle ore 22:19 Jean-Baptiste Onofré <
> > j...@nanthrax.net> ha scritto:
> >
> >> I tried with Camel 2.16.2, camel-blueprint, and simple route in
> >> blueprint: it works fine.
> >>
> >> I tried with your XML, and actually I have the same problem.
> >>
> >> It sounds like a Aries Blueprint bug. Let me try if I downgrade to
> >> blueprint 1.5.x and check the change in aries blueprint (I know
> >> Guillaume did some enhancements & changes).
> >>
> >> Honestly, I would consider as a blocker for the release, so, I will
> >> probably revert my vote to -1. I just want to make more tests.
> >>
> >> Regards
> >> JB
> >>
> >> On 04/05/2016 09:46 PM, Krzysztof Sobkowiak wrote:
> >>> Hi
> >>>
> >>> I tried to upgrade ServiceMix to the new version and have several
> >> problems with blueprint.
> >>>
> >>> 2016-04-05 21:42:05,485 | INFO  | pool-46-thread-1 |
> >> FeaturesServiceImpl  | 9 - org.apache.karaf.features.core -
> >> 4.0.5 |   cxf-wsn-receive/7.0.0.SNAPSHOT
> >>> 2016-04-05 21:42:05,567 | ERROR | pool-46-thread-1 |
> >> BlueprintContainerImpl   | 28 - org.apache.aries.blueprint.core
> -
> >> 1.6.0 | Unable to start blueprint container for bundle
> >> cxf-wsn-receive/7.0.0.SNAPSHOT
> >>> org.xml.sax.SAXParseException: src-import.3.1: The namespace
> attribute, '
> >> http://aries.apache.org/blueprint/xmlns/blueprint-ext/v1.0.0', of an
> >>  element information item must be identical to the
> targetNamespace
> >> attribute, 'http://camel.apache.org/schema/blueprint', of the imported
> >> document.
> >>>   at
> >>
> org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown
> >> Source)[:]
> >>>   at org.apache.xerces.util.ErrorHandlerWrapper.error(Unknown
> >> Source)[:]
> >>>   at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown
> >> Source)[:]
> >>>   at
> >>
> org.apache.xerces.impl.xs.traversers.XSDHandler.reportSchemaError(Unknown
> >> Source)[:]
> >>>   at
> >>
> org.apache.xerces.impl.xs.traversers.XSDHandler.reportSchemaError(Unknown
> >> Source)[:]
> >>>   at
> >> org.apache.xerces.impl.xs.traversers.XSDHandler.constructTrees(Unknown
> >> So

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

[Cristiano Costantini]

Hi JB and Krzysztof,

I don't know if this can be have any impact on the problem you have
reported, but about 1 month ago I got into an issue with camel XSD schemas
for Camel namespaces, and the issue is that the URL of the latest XSD,
http://camel.apache.org/schema/blueprint/camel-blueprint.xsd
is not from latest version 2.16.2, but it is from version 2.15.0

While upgrading to ServiceMix 7, I had to change manually the XML to
xsi:schemaLocation="http://camel.apache.org/schema/spring http://camel
.apache.org/schema/spring/camel-spring-2.16.1.xsd" in order to make it work
(note also that SMX 7 is based on camel 2.16.2, but this XSD is not
available)

But in fact the only problem I had was that Eclipse validation and
autocompletion of the XML files was not working properly.

if this is not relevant, please ignore this message ;-)

Cristiano




Il giorno mar 5 apr 2016 alle ore 22:19 Jean-Baptiste Onofré <
j...@nanthrax.net> ha scritto:

> I tried with Camel 2.16.2, camel-blueprint, and simple route in
> blueprint: it works fine.
>
> I tried with your XML, and actually I have the same problem.
>
> It sounds like a Aries Blueprint bug. Let me try if I downgrade to
> blueprint 1.5.x and check the change in aries blueprint (I know
> Guillaume did some enhancements & changes).
>
> Honestly, I would consider as a blocker for the release, so, I will
> probably revert my vote to -1. I just want to make more tests.
>
> Regards
> JB
>
> On 04/05/2016 09:46 PM, Krzysztof Sobkowiak wrote:
> > Hi
> >
> > I tried to upgrade ServiceMix to the new version and have several
> problems with blueprint.
> >
> > 2016-04-05 21:42:05,485 | INFO  | pool-46-thread-1 |
> FeaturesServiceImpl  | 9 - org.apache.karaf.features.core -
> 4.0.5 |   cxf-wsn-receive/7.0.0.SNAPSHOT
> > 2016-04-05 21:42:05,567 | ERROR | pool-46-thread-1 |
> BlueprintContainerImpl   | 28 - org.apache.aries.blueprint.core -
> 1.6.0 | Unable to start blueprint container for bundle
> cxf-wsn-receive/7.0.0.SNAPSHOT
> > org.xml.sax.SAXParseException: src-import.3.1: The namespace attribute, '
> http://aries.apache.org/blueprint/xmlns/blueprint-ext/v1.0.0', of an
>  element information item must be identical to the targetNamespace
> attribute, 'http://camel.apache.org/schema/blueprint', of the imported
> document.
> >  at
> org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown
> Source)[:]
> >  at org.apache.xerces.util.ErrorHandlerWrapper.error(Unknown
> Source)[:]
> >  at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown
> Source)[:]
> >  at
> org.apache.xerces.impl.xs.traversers.XSDHandler.reportSchemaError(Unknown
> Source)[:]
> >  at
> org.apache.xerces.impl.xs.traversers.XSDHandler.reportSchemaError(Unknown
> Source)[:]
> >  at
> org.apache.xerces.impl.xs.traversers.XSDHandler.constructTrees(Unknown
> Source)[:]
> >  at
> org.apache.xerces.impl.xs.traversers.XSDHandler.constructTrees(Unknown
> Source)[:]
> >  at
> org.apache.xerces.impl.xs.traversers.XSDHandler.parseSchema(Unknown
> Source)[:]
> >
> > or
> >
> >
> > 2016-04-05 21:31:36,969 | ERROR | pool-42-thread-1 |
> BlueprintContainerImpl   | 28 - org.apache.aries.blueprint.core -
> 1.6.0 | Unable to start blueprint container for bundle
> drools-camel-cxf-server/7.0.0.SNAPSHOT
> > org.xml.sax.SAXParseException: src-import.3.1: The namespace attribute, '
> http://cxf.apache.org/configuration/beans', of an  element
> information item must be identical to the targetNamespace attribute, '
> http://camel.apache.org/schema/blueprint', of the imported document.
> >  at
> org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown
> Source)[:]
> >  at org.apache.xerces.util.ErrorHandlerWrapper.error(Unknown
> Source)[:]
> >  at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown
> Source)[:]
> >  at
> org.apache.xerces.impl.xs.traversers.XSDHandler.reportSchemaError(Unknown
> Source)[:]
> >  at
> org.apache.xerces.impl.xs.traversers.XSDHandler.reportSchemaError(Unknown
> Source)[:]
> >  at
> org.apache.xerces.impl.xs.traversers.XSDHandler.constructTrees(Unknown
> Source)[:]
> >  at
> org.apache.xerces.impl.xs.traversers.XSDHandler.constructTrees(Unknown
> Source)[:]
> >
> >
> >
> > Here my try to reproduce one of them in K405
> >
> > Assume you have following simple blueprint (I have reduced one of the
> blueprints from the examples)
> >
> > http://www.osgi.org/xmlns/blueprint/v1.0.0;
> > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> > xmlns:cm="
> http://aries.apache.org/blueprint/xmlns/blueprint-cm/v1.1.0;
> > xsi:schemaLocation="
> http://www.osgi.org/xmlns/blueprint/v1.0.0
> http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd;>
> >
> >  
> >   persistent-id="org.apache.servicemix.examples.cxf.receive"
> update-strategy="reload">
> >  
> >  http://localhost:12345/test/"/>
> >  
> >  

Re: Problems due to the endorsed java.lang.Exception

[Cristiano Costantini]

Ok,

so I've repeated the tests and I confirm that with @XmlTransient annotation
the enhanced logging capability is preserved and the CXF error on
exceptions is fixed.

I've opened a ticket, https://issues.apache.org/jira/browse/KARAF-4429 and
I hope it could be fixed before the next releases of Karaf and ServiceMix.

To ake the tests, I've cloned karaf git repo and compiled patched version
for some different version, I've tested the fix and confirm it work on
Karaf 4.0.4, ServiceMix 7.0.0.M1, ServiceMix 6.1.0 and ServiceMix 5.3.0.
You can see the console output of the logs for each of the above platforms
here: https://gist.github.com/cristcost/4a5c554ccbb9577c690e

I have a personal preference for a fix like this:
https://github.com/cristcost/karaf/commit/cf1dbaa714f763ce8ee5de9801c4f43fd2fddb22
and we can update pax-log to use the protected method anytime in the
future, but I would be happy even if the fix is limited to annotating the
method with @XmlTransient.

I have not published the test that confirm that CXF is working with this
fix, basically I have a simple bundle and I trigger a fault with SOAP
request, I've checked manually that with this patch the marshalling is
working. If you need more evidence on this test I can provide more support.

In the end, if anyone is having these CXF issues and is using a Karaf
version which has not been fixed, you can quickly fix the problem by
deleting the file org.apache.karaf.exception-X.X.X.jar inside the
"lib/endorsed/" folder you'll loose some info on the logs of exception, you
can see what you are going to lose between two logs here:
https://gist.github.com/cristcost/4a5c554ccbb9577c690e/revisions#diff-73f5d0d8b32831c350a6fcfe04f84659L50
but
everything else "should" work properly.


Thank you for all the support,
plese promote the issue or let me know how I can provide more support,

Cristiano


Il giorno lun 21 mar 2016 alle ore 10:43 Cristiano Costantini <
cristiano.costant...@gmail.com> ha scritto:

> Ok,
> I've repeated the test WITH the endorsed exception,
>
> I've updated the previous GIST and from looking at it is now crystal clear
> the effects and benefits of endorsing the exception:
>
> At this link it is shown the differences in the logs:
> https://gist.github.com/cristcost/4a5c554ccbb9577c690e/revisions
>
> I'll now patch the endorsed exception with @XmlTransient and after I'll
> confirm that full logging capability is still available
>
>
>
>
> Il giorno lun 21 mar 2016 alle ore 10:28 Guillaume Nodet <
> gno...@apache.org> ha scritto:
>
>> 2016-03-21 10:06 GMT+01:00 Cristiano Costantini <
>> cristiano.costant...@gmail.com>:
>>
>> > I've tested deleting the endorsed Jar on different clean installations
>> of
>> > Karaf and ServiceMix,
>> >
>> > I never get question marks [?:?] on the logs using the log:display
>> command,
>> > although some line in the printed stack trace does not include bundle
>> > information.
>> >
>>
>> Right. The behaviour I pasted earlier was on karaf master branch
>> (so with pax logging / log4j v2).  The pax logging / log4j v1 does not
>> print
>> anything when the information is not available.
>>
>>
>> >
>> > Here you can check what I've done and what has been logged out
>> > https://gist.github.com/cristcost/4a5c554ccbb9577c690e
>> >
>> >
>> > I'm going to repeat the tests with the endorsed Exception for comparing
>> the
>> > logs.
>> >
>> > Cristiano
>> >
>> >
>> > Il giorno lun 21 mar 2016 alle ore 09:42 Cristiano Costantini <
>> > cristiano.costant...@gmail.com> ha scritto:
>> >
>> > > 
>> > >
>> > > now it is getting very weird...
>> > > intrigued by the test with the protected method I have made another
>> test:
>> > > I have fully deleted the org.apache.karaf.exception-2.4.0.jar file
>> from
>> > the
>> > > endorsed folder.
>> > > And surprisingly, I still get the same logs information with the
>> > > log:display command !
>> > >
>> > > Please note that I am making this series of tests on ServiceMix 5.3.0,
>> > > which is based on Karaf 2.4.0.
>> > > This is the output of the test you have suggested:
>> > >
>> > > karaf@root> log:clear
>> > > karaf@root> install foo
>> > > Bundle IDs:
>> > > Error executing command: Error installing bundles:
>> > > Unable to install bundle foo
>> > > karaf@root> log:display
>> > > 2016-03-21 09:38:02,339 | ERROR | l Console Thread | Console
&

Re: Problems due to the endorsed java.lang.Exception

[Cristiano Costantini]

Ok,
I've repeated the test WITH the endorsed exception,

I've updated the previous GIST and from looking at it is now crystal clear
the effects and benefits of endorsing the exception:

At this link it is shown the differences in the logs:
https://gist.github.com/cristcost/4a5c554ccbb9577c690e/revisions

I'll now patch the endorsed exception with @XmlTransient and after I'll
confirm that full logging capability is still available




Il giorno lun 21 mar 2016 alle ore 10:28 Guillaume Nodet <gno...@apache.org>
ha scritto:

> 2016-03-21 10:06 GMT+01:00 Cristiano Costantini <
> cristiano.costant...@gmail.com>:
>
> > I've tested deleting the endorsed Jar on different clean installations of
> > Karaf and ServiceMix,
> >
> > I never get question marks [?:?] on the logs using the log:display
> command,
> > although some line in the printed stack trace does not include bundle
> > information.
> >
>
> Right. The behaviour I pasted earlier was on karaf master branch
> (so with pax logging / log4j v2).  The pax logging / log4j v1 does not
> print
> anything when the information is not available.
>
>
> >
> > Here you can check what I've done and what has been logged out
> > https://gist.github.com/cristcost/4a5c554ccbb9577c690e
> >
> >
> > I'm going to repeat the tests with the endorsed Exception for comparing
> the
> > logs.
> >
> > Cristiano
> >
> >
> > Il giorno lun 21 mar 2016 alle ore 09:42 Cristiano Costantini <
> > cristiano.costant...@gmail.com> ha scritto:
> >
> > > 
> > >
> > > now it is getting very weird...
> > > intrigued by the test with the protected method I have made another
> test:
> > > I have fully deleted the org.apache.karaf.exception-2.4.0.jar file from
> > the
> > > endorsed folder.
> > > And surprisingly, I still get the same logs information with the
> > > log:display command !
> > >
> > > Please note that I am making this series of tests on ServiceMix 5.3.0,
> > > which is based on Karaf 2.4.0.
> > > This is the output of the test you have suggested:
> > >
> > > karaf@root> log:clear
> > > karaf@root> install foo
> > > Bundle IDs:
> > > Error executing command: Error installing bundles:
> > > Unable to install bundle foo
> > > karaf@root> log:display
> > > 2016-03-21 09:38:02,339 | ERROR | l Console Thread | Console
> > >| ?   ? | 20 -
> > > org.apache.karaf.shell.console - 2.4.0 | Exception caught while
> executing
> > > command
> > > org.apache.karaf.shell.console.MultiException: Error installing
> bundles:
> > > Unable to install bundle foo
> > > at
> > >
> >
> org.apache.karaf.shell.console.MultiException.throwIf(MultiException.java:91)
> > > at
> > >
> >
> org.apache.karaf.shell.osgi.InstallBundle.doExecute(InstallBundle.java:70)
> > > at
> > >
> >
> org.apache.karaf.shell.console.OsgiCommandSupport.execute(OsgiCommandSupport.java:38)[20:org.apache.karaf.shell.console:2.4.0]
> > > at
> > >
> >
> org.apache.felix.gogo.commands.basic.AbstractCommand.execute(AbstractCommand.java:35)[20:org.apache.karaf.shell.console:2.4.0]
> > > at
> > >
> >
> org.apache.felix.gogo.runtime.CommandProxy.execute(CommandProxy.java:78)[20:org.apache.karaf.shell.console:2.4.0]
> > > at
> > >
> >
> org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:477)[20:org.apache.karaf.shell.console:2.4.0]
> > > at
> > >
> >
> org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:403)[20:org.apache.karaf.shell.console:2.4.0]
> > > at
> > >
> >
> org.apache.felix.gogo.runtime.Pipe.run(Pipe.java:108)[20:org.apache.karaf.shell.console:2.4.0]
> > > at
> > >
> >
> org.apache.felix.gogo.runtime.Closure.execute(Closure.java:183)[20:org.apache.karaf.shell.console:2.4.0]
> > > at
> > >
> >
> org.apache.felix.gogo.runtime.Closure.execute(Closure.java:120)[20:org.apache.karaf.shell.console:2.4.0]
> > > at
> > >
> >
> org.apache.felix.gogo.runtime.CommandSessionImpl.execute(CommandSessionImpl.java:92)[20:org.apache.karaf.shell.console:2.4.0]
> > > at
> > >
> >
> org.apache.karaf.shell.console.jline.Console.run(Console.java:196)[20:org.apache.karaf.shell.console:2.4.0]
> > > at
> > >
> >
> org.apache.karaf.shell.console.jline.DelayedStarted.run(DelayedStarted.java:79)[20:org.apache.karaf.shell.con

Re: Problems due to the endorsed java.lang.Exception

[Cristiano Costantini]

now it is getting very weird...
intrigued by the test with the protected method I have made another test: I
have fully deleted the org.apache.karaf.exception-2.4.0.jar file from the
endorsed folder.
And surprisingly, I still get the same logs information with the
log:display command !

Please note that I am making this series of tests on ServiceMix 5.3.0,
which is based on Karaf 2.4.0.
This is the output of the test you have suggested:

karaf@root> log:clear
karaf@root> install foo
Bundle IDs:
Error executing command: Error installing bundles:
Unable to install bundle foo
karaf@root> log:display
2016-03-21 09:38:02,339 | ERROR | l Console Thread | Console
   | ?   ? | 20 -
org.apache.karaf.shell.console - 2.4.0 | Exception caught while executing
command
org.apache.karaf.shell.console.MultiException: Error installing bundles:
Unable to install bundle foo
at
org.apache.karaf.shell.console.MultiException.throwIf(MultiException.java:91)
at
org.apache.karaf.shell.osgi.InstallBundle.doExecute(InstallBundle.java:70)
at
org.apache.karaf.shell.console.OsgiCommandSupport.execute(OsgiCommandSupport.java:38)[20:org.apache.karaf.shell.console:2.4.0]
at
org.apache.felix.gogo.commands.basic.AbstractCommand.execute(AbstractCommand.java:35)[20:org.apache.karaf.shell.console:2.4.0]
at
org.apache.felix.gogo.runtime.CommandProxy.execute(CommandProxy.java:78)[20:org.apache.karaf.shell.console:2.4.0]
at
org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:477)[20:org.apache.karaf.shell.console:2.4.0]
at
org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:403)[20:org.apache.karaf.shell.console:2.4.0]
at
org.apache.felix.gogo.runtime.Pipe.run(Pipe.java:108)[20:org.apache.karaf.shell.console:2.4.0]
at
org.apache.felix.gogo.runtime.Closure.execute(Closure.java:183)[20:org.apache.karaf.shell.console:2.4.0]
at
org.apache.felix.gogo.runtime.Closure.execute(Closure.java:120)[20:org.apache.karaf.shell.console:2.4.0]
at
org.apache.felix.gogo.runtime.CommandSessionImpl.execute(CommandSessionImpl.java:92)[20:org.apache.karaf.shell.console:2.4.0]
at
org.apache.karaf.shell.console.jline.Console.run(Console.java:196)[20:org.apache.karaf.shell.console:2.4.0]
at
org.apache.karaf.shell.console.jline.DelayedStarted.run(DelayedStarted.java:79)[20:org.apache.karaf.shell.console:2.4.0]
Caused by: java.lang.Exception: Unable to install bundle foo
at
org.apache.karaf.shell.osgi.InstallBundle.doExecute(InstallBundle.java:45)
... 11 more
Caused by: org.osgi.framework.BundleException: Unable to cache bundle: foo
at org.apache.felix.framework.Felix.installBundle(Felix.java:2878)
at
org.apache.felix.framework.BundleContextImpl.installBundle(BundleContextImpl.java:165)
at
org.apache.karaf.shell.osgi.InstallBundle.doExecute(InstallBundle.java:43)
... 11 more
Caused by: java.net.MalformedURLException: no protocol: foo
at java.net.URL.(URL.java:586)[:1.8.0_60]
at
org.apache.felix.framework.util.SecureAction.createURL(SecureAction.java:254)
at
org.apache.felix.framework.cache.JarRevision.initialize(JarRevision.java:148)
at org.apache.felix.framework.cache.JarRevision.(JarRevision.java:77)
at
org.apache.felix.framework.cache.BundleArchive.createRevisionFromLocation(BundleArchive.java:878)
at
org.apache.felix.framework.cache.BundleArchive.reviseInternal(BundleArchive.java:550)
at
org.apache.felix.framework.cache.BundleArchive.(BundleArchive.java:153)
at org.apache.felix.framework.cache.BundleCache.create(BundleCache.java:277)
at org.apache.felix.framework.Felix.installBundle(Felix.java:2874)
... 13 more

karaf@root>


I repeat that this output is given from a Servicemix 5.3.0 where I have
deleted the endorsed Jar.
Do you expected this kind of logs Guillaume?

I'll now make more tests with fully clean ServiceMix and fully clean Karaf
and let you know if the behavior persist.

Cristiano





Il giorno lun 21 mar 2016 alle ore 09:30 Guillaume Nodet <gno...@apache.org>
ha scritto:

> 2016-03-21 9:13 GMT+01:00 Cristiano Costantini <
> cristiano.costant...@gmail.com>:
>
> > Hi all,
> >
> > Guillaume, could it be that pax logging works also if using "protected"
> in
> > the getClassContext method?
>
>
> > In fact I'm testing and comparing the two options, but I see that also
> with
> > the solution of making the endorsed class method like this:
> > protected Class[] getClassContext() {
> > return classContext;
> > }
> >
> > I am still getting the same logs
> > with [bundleId:bundleSymbolicName:bundleVersion] information
> >
> >
> >
> I don't.  Try with
>   > bundle:install foo
>   > log:display
> I end up with lots of ~[?:?]  instead of the actual bundle informations
> when using a protected method.
> If the @XmlTransient annotation is sufficient, that's the easiest fix.
> But I agree it would be better to mov

Re: Problems due to the endorsed java.lang.Exception

[Cristiano Costantini]

Hi all,

Guillaume, could it be that pax logging works also if using "protected" in
the getClassContext method?

In fact I'm testing and comparing the two options, but I see that also with
the solution of making the endorsed class method like this:
protected Class[] getClassContext() {
return classContext;
}

I am still getting the same logs
with [bundleId:bundleSymbolicName:bundleVersion] information





Il giorno dom 20 mar 2016 alle ore 09:24 Jean-Baptiste Onofré <
j...@nanthrax.net> ha scritto:

> +1
>
> I think @XmlTransient is sufficient and limit the impacts.
>
> Regards
> JB
>
> On 03/20/2016 09:17 AM, Cristiano Costantini wrote:
> > Hello all,
> >
> > I like the idea of having "bundle id, symbolic name and version" in the
> > exception logs, I've used it a lot and I think we should find a solution
> > that is as clean as possible and works well by keep this enhanced logging
> > capability alive.
> >
> > The solution of marking the method with @XmlTransient is good and would
> > fully solve the CXF problem (I'll try this one tomorrow morning and give
> > you a confirmation about this approach).
> >
> > Also, JaxB sees it as a property because it is a getter, and try to
> > marshall it because JaxB default behavior is to marshall properties.
> > Then I propose also, for cleanliness to @Deprecate the getClassContext
> > method and create a new one called in a non property way, for example
> > simply classContext(), without the get.
> >
> > If Guillaume in pax-logging is using reflection and may be able to access
> > the method even if it is protected, then it should be "protected", again
> > for cleanliness.
> >
> >
> > I was thinking at what other problems could be caused by this endorsement
> > of the class:
> > the underlying classContext field is correctly marked as transient, so I
> > expect no problem due to serialization, even with third party libraries
> > (for example Kryo) which respect the transient modifier.
> > Except for JaxB, I don't know any other use case where exceptions may be
> > accessed with reflection in search for methods.
> >
> > So to summarize:
> >
> > @XmlTransient @Deprecated public getClassContext() { ... }
> > +
> > protected classContext() { ... }
> >
> > seems to me the best option.
> >
> >
> > What do you think?
> >
> > Cristiano
> >
> >
> >
> >
> >
> > Il giorno dom 20 mar 2016 alle ore 04:04 Matt Sicker <boa...@gmail.com>
> ha
> > scritto:
> >
> >> If there's a way to fix this in log4j, that would be better.
> >>
> >> On 19 March 2016 at 06:02, James Carman <ja...@carmanconsulting.com>
> >> wrote:
> >>
> >>> That's kind of a nasty trick just to get pretty stack traces.  Is this
> >>> really necessary?
> >>>
> >>> On Fri, Mar 18, 2016 at 3:05 PM Guillaume Nodet <gno...@apache.org>
> >> wrote:
> >>>
> >>>> I wrote that years ago and nobody complained about it, until today
> >>>> Adding the @XmlTransient should be a good and quick fix.
> >>>>
> >>>> The benefit of the custom Exception is that this information is stored
> >>>> along with the exception. This information is always lost when you
> need
> >>> it
> >>>> to render the exception, as the stack trace may be completely
> different
> >>> and
> >>>> even in a from different thread, which mean you loose the information.
> >> So
> >>>> ReflectionUtil.getCurrentStackTrace() works the same, but the
> >> information
> >>>> is the one of the calling code, not the one of the exception, and
> >> that's
> >>>> useless.
> >>>>
> >>>> If you look at a stack trace in Karaf, it looks like the following:
> >>>>
> >>>> org.apache.karaf.shell.support.MultiException: Error installing
> >> bundles:
> >>>>
> >>>> Unable to install bundle foo
> >>>>
> >>>> at
> >>>>
> >>>>
> >>>
> >>
> org.apache.karaf.shell.support.MultiException.throwIf(MultiException.java:61)
> >>>> ~[28:org.apache.karaf.shell.core:4.1.0.SNAPSHOT]
> >>>>
> >>>> at org.apache.karaf.bundle.command.Install.execute(Install.java:113)
> >>>> [12:org.apache.karaf.bundle.core:4.1.0.SNAPSHOT]
> >>&g

Re: Problems due to the endorsed java.lang.Exception

[Cristiano Costantini]

.felix.gogo.runtime.Pipe.call(Pipe.java:59)
> > > [28:org.apache.karaf.shell.core:4.1.0.SNAPSHOT]
> > >
> > > at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
> > >
> > > at
> > >
> > >
> >
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> > > [?:?]
> > >
> > > at
> > >
> > >
> >
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> > > [?:?]
> > >
> > > at java.lang.Thread.run(Thread.java:745) [?:?]
> > >
> > > The information in the brackets, at the end of each line, is actually
> > > accurate (bundle id, symbolic name, version).  Without the information
> > > stored in the Exception, I'm not aware of any way to do that
> > unfortunately.
> > >
> > > 2016-03-18 18:41 GMT+01:00 Matt Sicker <boa...@gmail.com>:
> > >
> > > > What's wrong with the class context from
> > > > ReflectionUtil.getCurrentStackTrace() that requires a custom
> > > implementation
> > > > of Exception?
> > > >
> > > > On 18 March 2016 at 12:11, Guillaume Nodet <gno...@apache.org>
> wrote:
> > > >
> > > > > The getClassContext() method is used in pax-logging to render the
> > > > exception
> > > > > in a nicer way.
> > > > > I don't have any problem moving the qualifier to protected or
> > whatever,
> > > > but
> > > > > we'd need to change the code in pax-logging
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/ops4j/org.ops4j.pax.logging/blob/master/pax-logging-log4j2/src/main/java/org/apache/logging/log4j/core/impl/ThrowableProxy.java#L136-L144
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/ops4j/org.ops4j.pax.logging/blob/master/pax-logging-service/src/main/java/org/apache/log4j/OsgiThrowableRenderer.java#L62-L67
> > > > >
> > > > > It should not be a big deal, but the current code expect the method
> > to
> > > be
> > > > > public unfortunately.
> > > > >
> > > > > Guillaume
> > > > >
> > > > >
> > > > > 2016-03-18 17:29 GMT+01:00 Jean-Baptiste Onofré <j...@nanthrax.net>:
> > > > >
> > > > > > Hi Cristiano,
> > > > > >
> > > > > > I think you are right, it's probably something existing for a
> > while.
> > > > I'm
> > > > > > just surprised that you encountered now.
> > > > > >
> > > > > > Let me check your detailed use case that you sent previously.
> > > > > >
> > > > > > Regards
> > > > > > JB
> > > > > >
> > > > > >
> > > > > > On 03/18/2016 05:14 PM, Cristiano Costantini wrote:
> > > > > >
> > > > > >> Hello all,
> > > > > >>
> > > > > >> it is some days I was having troubles using CXF services on
> > > ServiceMix
> > > > > >> (and
> > > > > >> it is some days I spam on the mailing list of ServiceMix, Camel
> > and
> > > > CXF
> > > > > >> :-D
> > > > > >> ) and I've finally come to the source of my issues which are due
> > to
> > > > the
> > > > > >> "endorsed" java.lang.Exception which is used by Karaf:
> > > > > >>
> > > > > >>
> > > > > >>
> > > > >
> > > >
> > >
> >
> https://github.com/apache/karaf/blob/master/exception/src/main/java/java/lang/Exception.java
> > > > > >>
> > > > > >> My problem is due to the fact that this class has a public
> > property,
> > > > > >> public Class[] getClassContext() {
> > > > > >>  return classContext;
> > > > > >> }
> > > > > >> which is seen by JaxB at runtime inside Karaf which cause it to
> > > > marshall
> > > > > >> the Exception in SOAP services with a wrong XML, an XML which
> > > include
> > > > > >>  tags.
> > > > > >>
> > > 

Problems due to the endorsed java.lang.Exception

[Cristiano Costantini]

Hello all,

it is some days I was having troubles using CXF services on ServiceMix (and
it is some days I spam on the mailing list of ServiceMix, Camel and CXF :-D
) and I've finally come to the source of my issues which are due to the
"endorsed" java.lang.Exception which is used by Karaf:

https://github.com/apache/karaf/blob/master/exception/src/main/java/java/lang/Exception.java

My problem is due to the fact that this class has a public property,
public Class[] getClassContext() {
return classContext;
}
which is seen by JaxB at runtime inside Karaf which cause it to marshall
the Exception in SOAP services with a wrong XML, an XML which include
 tags.

The class in Karaf has not changed since committed by Guillaume Nodet in
2010, so this issue with CXF has probably always been there.

In my opinion, this getter should be private or protected as I guess it is
only used on the nested class method's getThrowableContext (it is a
replacement for the JRE's class, I don't think there are external project
using this modification of the Exception class).


To confirm my thesis, I've hacked the org.apache.karaf.exception-2.4.0.jar
inside the lib/endorsed folder with a class compiled by myself where I've
changed the method to
private Class[] getClassContext() {
return classContext;
}
and with this hack, Karaf has continued to work (and my CXF service now
works properly).

Do you think there are potential side effects in this fix?
Do you need me to open an issue on Jira to handle the problem?
If it is confirmed that the fix of making this method private, do you think
it could be included soon on the next Karaf Release?

Thank you very much to all,
Cristiano

Re: Karaf Cellar

[Cristiano Costantini]

Thank you JB!

I'll so make some test to upgrade to ServiceMix 7.0.0.M1 and use Cellar 4,
hopefully it will be released the final v7 in short time.

Bye,
Cristiano

P.S. Do it exist a dedicated mailing list for Cellar or does it is ok
discussing about it on this list?

Il giorno ven 26 feb 2016 alle ore 13:21 Jean-Baptiste Onofré <
j...@nanthrax.net> ha scritto:

>
>
> Hi
> Cellar 2.3.x works with Karaf 2.x (2.3 and 2.4).Cellar 3.0.x works with
> Karaf 3.x.Cellar 4.0.x works with Karaf 4.x.
> If you plan an upgrade, latest one (4.x) makes sense imho.
> Regards JB
>
>
> Sent from my Samsung device
>
> ---- Original message 
> From: Cristiano Costantini <cristiano.costant...@gmail.com>
> Date: 26/02/2016  10:06  (GMT+01:00)
> To: dev@karaf.apache.org
> Subject: Karaf Cellar
>
> Hello All,
>
> we are planning to start using Karaf-Cellar;
> as we are still using Karaf 2.4.1 (in fact we use Servicemix 5.3.0) but we
> have a chance to upgrade the version of the container,
> can I ask you a suggestion on which version of Karaf is the better to start
> using Cellar?
> Do you recommend version 3.0.6 or version 4.0.4 or any other version?
> Or does it is does make no difference?
>
> Thank you for the support!
> Cristiano
>

Karaf Cellar

[Cristiano Costantini]

Hello All,

we are planning to start using Karaf-Cellar;
as we are still using Karaf 2.4.1 (in fact we use Servicemix 5.3.0) but we
have a chance to upgrade the version of the container,
can I ask you a suggestion on which version of Karaf is the better to start
using Cellar?
Do you recommend version 3.0.6 or version 4.0.4 or any other version?
Or does it is does make no difference?

Thank you for the support!
Cristiano

Re: [PROPOSAL] Retire Karaf WebConsole

[Cristiano Costantini]

Hi guys,
I use the webconsole very often, to diagnose problems and check the status
of the running instance.

I don't need more features from the webconsole, so it is ok as it is now,
and it could be enough that it is kept up to date with the dependencies,
but, for what it can count as I am not a binding member, for me is a

-1

;-)
regards,
Cristiano



Il giorno Fri Jan 30 2015 at 09:45:11 Achim Nierbeck 
bcanh...@googlemail.com ha scritto:

 Hi JB,

 +1

 regards, Achim


 2015-01-30 9:25 GMT+01:00 Jean-Baptiste Onofré j...@nanthrax.net:

  Hi all,
 
  as we don't have activity on Karaf WebConsole sub-project, and it seems
  that nobody wants to tackle/maintain it, I would propose to retire the
  sub-project.
 
  WDYT ?
 
  Regards
  JB
  --
  Jean-Baptiste Onofré
  jbono...@apache.org
  http://blog.nanthrax.net
  Talend - http://www.talend.com
 



 --

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

 Software Architect / Project Manager / Scrum Master

Spring Deployer

[Cristiano Costantini]

Hi all,

I've found a strange behaviour while trying to make spring deployer work on
Karaf 2.4.1:

I start Karaf with spring-dm and camel-spring features enabled at startup:
featuresBoot = karaf-framework, [...] ,spring-dm,camel-spring,webconsole


as a result, also spring feature is installed:
karaf@root features:list | grep spring | grep -v uninstalled
[installed  ] [1.2.1   ] spring-dm
spring-2.4.1Spring DM support
[installed  ] [3.2.11.RELEASE_1] spring
 spring-2.4.1Spring 3.2.x support
[installed  ] [3.2.11.RELEASE_1] spring-tx
spring-2.4.1Spring 3.2.x Transaction (TX) support
[installed  ] [2.13.2  ] camel-spring
 camel-2.13.2


but the deployer feature has not installed the spring deployer bundle (the
istallation of which installation is conditional to the presence of the
spring's feature which is available)

feature name=deployer description=Karaf Deployer
version=${project.version}
bundle start=true
start-level=26mvn:org.apache.karaf.deployer/org.apache.karaf.deployer.features/${project.version}/bundle
   [...]
conditional
conditionspring/condition
bundle start=true
start-level=24mvn:org.apache.karaf.deployer/org.apache.karaf.deployer.spring/${project.version}/bundle
/conditional
[...]
/feature


I thought it to be a bootstrap problem dependent on the order of how
features are loaded, but even if I uninstall and reinstall deployer
feature, the bundle org.apache.karaf.deployer.spring is not installed:

karaf@root features:uninstall deployer
karaf@root features:install deployer
karaf@root list -t 0
START LEVEL 100 , List Threshold: 0
   ID   State Blueprint  SpringLevel  Name
...
[ 113] [Active ] [Created ] [   ] [   26] Apache Karaf ::
Deployer :: Features (2.4.1)
[ 114] [Active ] [Created ] [   ] [   24] Apache Karaf ::
Deployer :: Blueprint (2.4.1)
karaf@root


if install the bundle org.apache.karaf.deployer.spring manually, then
everything seems to be working and the spring file I have copied on deploy
folder starts:


karaf@root install -s
mvn:org.apache.karaf.deployer/org.apache.karaf.deployer.spring/2.4.1
Bundle ID: 115
karaf@root list -t 0
START LEVEL 100 , List Threshold: 0
   ID   State Blueprint  SpringLevel  Name
...
[ 113] [Active ] [Created ] [   ] [   26] Apache Karaf ::
Deployer :: Features (2.4.1)
[ 114] [Active ] [Created ] [   ] [   24] Apache Karaf ::
Deployer :: Blueprint (2.4.1)
[ 115] [Active ] [Created ] [   ] [   80] Apache Karaf ::
Deployer :: Spring (2.4.1)
[ 116] [Active ] [] [Started] [   80] beans.xml (0.0.0)
karaf@root


I've also discovered that the deployer feature installs the spring deployer
bundle only if I install latest version of spring feature, 4.1.2.RELEASE_1,
which I want to avoid as I don't use yet spring 4.

Is this behaviour expected or should the spring deployer be installed also
with previous versions of spring?


Regards,
Cristiano

Re: Uninstall bundle and package dependency

[Cristiano Costantini]

I confirm too, I've tried full refresh (without Bundle ID) and it resolves
the import on the reinstalled bundle:

karaf@root list
START LEVEL 100 , List Threshold: 50
   ID   State Blueprint  Level  Name
[  92] [Active ] [] [   80] Sample Dependency Bundle
(1.0.0.SNAPSHOT)
[  93] [Active ] [] [   80] Sample Dependent Bundle
(1.0.0.SNAPSHOT)

karaf@root packages:imports 93
Sample Dependency Bundle (92): com.example.dependency;
version=1.0.0.SNAPSHOT

karaf@root uninstall 92
karaf@root packages:imports 93
Sample Dependency Bundle (92): com.example.dependency;
version=1.0.0.SNAPSHOT

karaf@root install -s mvn:com.example/sample-dependency/1.0.0-SNAPSHOT
Bundle ID: 94

karaf@root packages:imports 93
Sample Dependency Bundle (92): com.example.dependency;
version=1.0.0.SNAPSHOT

karaf@root refresh 93
karaf@root packages:imports 93
Sample Dependency Bundle (92): com.example.dependency;
version=1.0.0.SNAPSHOT

karaf@root refresh
karaf@root packages:imports 93
Sample Dependency Bundle (94): com.example.dependency;
version=1.0.0.SNAPSHOT



Note: I was unaware of the possibility to invoke refresh command without
a bundle ID because the help description states that the command do Refresh
a bundle; I assumed then it only works with a bundle ID :-)

Regards,
Cristiano

Il giorno Fri Jan 09 2015 at 10:57:45 Achim Nierbeck 
bcanh...@googlemail.com ha scritto:

 Looks like we got an issue with the refresh command, though it seems to be
 the other way round, compared to the issue we had with Karaf 3.0.x.

 regards, Achim


 2015-01-09 10:50 GMT+01:00 Giuseppe Gerla giuseppe.ge...@gmail.com:

  Thanks Achim
  if I do a global refresh bundle 88 goes in not resolved state.
 
  The same behavior if I use web console. Using Refresh packages button
  from specific bundle page don't update the bundle state. If I use the
  Refresh packages button from the /system/console/bundles page all works
  fine.
 
  I'd like to investigate what happen if I update a single bundle using
  Install/Update functionality of webconsole.
 
 
  Thanks
  Regards
  Giuseppe
 
 
  2015-01-09 9:46 GMT+01:00 Achim Nierbeck bcanh...@googlemail.com:
 
   Hi Giuseppe,
  
   this is rather strange that it works with features, but not with the
   refresh command.
   OTH we had an issue with it till Karaf 3.0.2, if you just do a refresh
   (without the id)
   it doesn't refresh the complete container as it's supposed to.
   Did you refresh the explicit bundle, or just call bundle:refresh?
  
   regards, Achim
  
  
   2015-01-08 22:04 GMT+01:00 Giuseppe Gerla giuseppe.ge...@gmail.com:
  
Hi Achim
thanks for your answers.
The problem is that after refresh 88, bundle is still in Active
 state.
   
I don't see bundle 87 in the list of bundles installed, but there is
   still
the data/cache/bundle87 folder. This folder disappears when I close
  karaf
with shutdown command.
   
I make also another test. I create a feature for Sample Dependency
   Bundle
and another for Sample Dependent Bundle that install also the other
feature.
In this case if I uninstall the Sample Dependency Bundle feature
  Karaf
remove the bundle from cache folder and refresh correctly the state
 of
Sample Dependent Bundle in not resolved.
   
   
Regards
Giuseppe
   
   
2015-01-08 20:27 GMT+01:00 Achim Nierbeck bcanh...@googlemail.com:
   
 Hi,

 actually I didn't look at it until now.
 I think there might be some sort of race on that actual procedure
   there.
 How about retrying with the following scenario.

 Install 87
 Install 88

 uninstall 87
 refresh 88, should be in non-resolved state after that

 install 89
 refresh 88, after that it should be wired to 89 again.

 regards, Achim






 2015-01-08 18:49 GMT+01:00 Cristiano Costantini 
 cristiano.costant...@gmail.com:

  Hi Achim,
 
  if you look at the file attached to Giuseppe's message, even if
 you
 refresh
  to bundle 88 ( karaf@root refresh 88 ) the bundle still
 resolves
   the
  package import on the old and uninstalled bundle 87 instead of
  bundle
89
  (anyhow please note that bundle 89  is the same bundle,
 uninstalled
   and
  installed again, the Jar is not recompiled).
 
  Shouldn't bundle 88 start using imports from bundle 89 after the
explicit
  refresh?
 
  Thank you and regards,
  Cristiano
 
 
 
  Il giorno Thu Jan 08 2015 at 18:18:21 Achim Nierbeck 
  bcanh...@googlemail.com ha scritto:
 
  Hi,
  
   this is the desired behavior as per OSGi - Spec. Until you do a
refresh
  of
   bundle 88 it will keep the references to the uninstalled
 bundle.
   The deploy folder is watched by the FileInstaller, which does
  call
   a
   refresh on the framework after the install/uninstall of
 bundles

Upgrade Equinox to 3.9.1-v20130814-1242 for Karaf 2.3.5

[Cristiano Costantini]

Hi all,
I have a severe allergy to maven projects that specify external
repositories.
To avoid them I use a local maven repo proxy (using Apache Archiva) as
mirror which is allowed to retrieve only artifact from Maven Central Repo
plus few others selected and trusted repos.

Today I tried to build Apache Karaf 2.3.5-SNAPSHOT, and I got sick
immediately when I got the error:
[WARNING] The POM for org.eclipse:osgi:jar:3.8.0.v20120529-1548 is missing,
no dependency information available

(and I see that also Karaf 3.0.1-SNAPSHOT depends on equinox 3.8.2)

So I did searched on search.maven.org, I saw that
version 3.9.1-v20130814-1242, tried it and everything compiled really fine!
And I now have version of Karaf I can use without using antihistamines.

So, is it possible that Karaf 2.3.5-SNAPSHOT and 3.0.1-SNAPSHOT update to
this version and remove external repo? Or are there other side effects I'm
not aware of?

I hope the community can evaluate this proposal and list pros and cons.


For building, I used the following patches:

diff --git a/pom.xml b/pom.xml
index 6b56968..2ce1e97 100644
--- a/pom.xml
+++ b/pom.xml
@@ -137,7 +137,7 @@
 geronimo.jta-spec.version1.1.1/geronimo.jta-spec.version
 geronimo.servlet.version1.2/geronimo.servlet.version
 easymock.version3.2/easymock.version
-equinox.version3.8.0.v20120529-1548/equinox.version
+equinox.version3.9.1-v20130814-1242/equinox.version

 felix.bundlerepository.version1.6.6/felix.bundlerepository.version
 felix.configadmin.version1.6.0/felix.configadmin.version
 felix.fileinstall.version3.2.8/felix.fileinstall.version
@@ -229,32 +229,6 @@

 bnd.version.policy[$(version;==;$(@)),$(version;+;$(@)))/bnd.version.policy
 /properties

-repositories
-!-- ServiceMix repo --
-repository
-idservicemix/id
-nameApache ServiceMix Repository/name
-urlhttp://svn.apache.org/repos/asf/servicemix/m2-repo/url
-releases
-enabledtrue/enabled
-/releases
-snapshots
-enabledfalse/enabled
-/snapshots
-/repository
-!-- OPS4J SNAPSHOT repository --
-repository
-idops4j.sonatype.snapshots.deploy/id
-nameOPS4J snapshot repository/name
-url
https://oss.sonatype.org/content/repositories/ops4j-snapshots//url
-releases
-enabledfalse/enabled
-/releases
-snapshots
-enabledtrue/enabled
-/snapshots
-/repository
-/repositories

 dependencyManagement
 dependencies


and it has built on my computer running successfully all the integration
tests:

[INFO] Apache Karaf .. SUCCESS [1.119s]
[INFO] Apache Karaf :: Util .. SUCCESS [1.333s]
[INFO] Apache Karaf :: Main .. SUCCESS [30.767s]
[INFO] Apache Karaf :: JAAS .. SUCCESS [0.067s]
[INFO] Apache Karaf :: JAAS :: Boot .. SUCCESS [0.822s]
[INFO] Apache Karaf :: JAAS :: Config  SUCCESS [2.382s]
[INFO] Apache Karaf :: JAAS :: Modules ... SUCCESS [1.203s]
[INFO] Apache Karaf :: Shell . SUCCESS [0.053s]
[INFO] Apache Karaf :: Shell :: Console .. SUCCESS [2.710s]
[INFO] Apache Karaf :: Shell :: OBR Commands . SUCCESS [1.016s]
[INFO] Apache Karaf :: Features .. SUCCESS [0.039s]
[INFO] Apache Karaf :: Features :: Core .. SUCCESS [6.582s]
[INFO] Apache Karaf :: Features :: Command ... SUCCESS [0.916s]
[INFO] Apache Karaf :: Management  SUCCESS [0.041s]
[INFO] Apache Karaf :: Management  SUCCESS [1.099s]
[INFO] Apache Karaf :: Features :: Management  SUCCESS [1.010s]
[INFO] Apache Karaf :: Features :: OBR Resolver .. SUCCESS [0.968s]
[INFO] Apache Karaf :: Admin . SUCCESS [0.036s]
[INFO] Apache Karaf :: Admin :: Core . SUCCESS [3.323s]
[INFO] Apache Karaf :: Admin :: Command .. SUCCESS [1.059s]
[INFO] Apache Karaf :: Admin :: Management ... SUCCESS [0.930s]
[INFO] Apache Karaf :: Deployer .. SUCCESS [0.032s]
[INFO] Apache Karaf :: Deployer :: Spring  SUCCESS [1.571s]
[INFO] Apache Karaf :: Deployer :: Blueprint . SUCCESS [1.080s]
[INFO] Apache Karaf :: Deployer :: Features .. SUCCESS [0.829s]
[INFO] Apache Karaf :: Deployer :: Karaf Archive (.kar) .. SUCCESS [1.107s]
[INFO] Apache Karaf :: Deployer :: Wrap Non OSGi Jar . SUCCESS [0.726s]
[INFO] Apache Karaf :: Shell :: Various Commands . SUCCESS [1.024s]
[INFO] Apache Karaf :: Shell :: ConfigAdmin Commands . SUCCESS [1.010s]
[INFO] Apache Karaf :: Shell :: Log 

Re: Upgrade Equinox to 3.9.1-v20130814-1242 for Karaf 2.3.5

[Cristiano Costantini]

Mmmm,
I'll give it a build on a clean maven repo.


2014-02-17 10:12 GMT+01:00 Achim Nierbeck bcanh...@googlemail.com:

 Hi,

 Just one note without trying. It won't work if you remove the snapshot repo
 for ops4j, the minute we have a snapshot dependency for either pax URL or
 web. Snapshots are not on maven central, releases are.

 Regards, achim

 sent from mobile device
 Am 17.02.2014 10:02 schrieb Cristiano Costantini 
 cristiano.costant...@gmail.com:

  Hi all,
  I have a severe allergy to maven projects that specify external
  repositories.
  To avoid them I use a local maven repo proxy (using Apache Archiva) as
  mirror which is allowed to retrieve only artifact from Maven Central Repo
  plus few others selected and trusted repos.
 
  Today I tried to build Apache Karaf 2.3.5-SNAPSHOT, and I got sick
  immediately when I got the error:
  [WARNING] The POM for org.eclipse:osgi:jar:3.8.0.v20120529-1548 is
 missing,
  no dependency information available
 
  (and I see that also Karaf 3.0.1-SNAPSHOT depends on equinox 3.8.2)
 
  So I did searched on search.maven.org, I saw that
  version 3.9.1-v20130814-1242, tried it and everything compiled really
 fine!
  And I now have version of Karaf I can use without using antihistamines.
 
  So, is it possible that Karaf 2.3.5-SNAPSHOT and 3.0.1-SNAPSHOT update to
  this version and remove external repo? Or are there other side effects
 I'm
  not aware of?
 
  I hope the community can evaluate this proposal and list pros and cons.
 
 
  For building, I used the following patches:
 
  diff --git a/pom.xml b/pom.xml
  index 6b56968..2ce1e97 100644
  --- a/pom.xml
  +++ b/pom.xml
  @@ -137,7 +137,7 @@
   geronimo.jta-spec.version1.1.1/geronimo.jta-spec.version
   geronimo.servlet.version1.2/geronimo.servlet.version
   easymock.version3.2/easymock.version
  -equinox.version3.8.0.v20120529-1548/equinox.version
  +equinox.version3.9.1-v20130814-1242/equinox.version
 
   felix.bundlerepository.version1.6.6/felix.bundlerepository.version
   felix.configadmin.version1.6.0/felix.configadmin.version
   felix.fileinstall.version3.2.8/felix.fileinstall.version
  @@ -229,32 +229,6 @@
 
 
 
  
 bnd.version.policy[$(version;==;$(@)),$(version;+;$(@)))/bnd.version.policy
   /properties
 
  -repositories
  -!-- ServiceMix repo --
  -repository
  -idservicemix/id
  -nameApache ServiceMix Repository/name
  -urlhttp://svn.apache.org/repos/asf/servicemix/m2-repo
 /url
  -releases
  -enabledtrue/enabled
  -/releases
  -snapshots
  -enabledfalse/enabled
  -/snapshots
  -/repository
  -!-- OPS4J SNAPSHOT repository --
  -repository
  -idops4j.sonatype.snapshots.deploy/id
  -nameOPS4J snapshot repository/name
  -url
  https://oss.sonatype.org/content/repositories/ops4j-snapshots//url
  -releases
  -enabledfalse/enabled
  -/releases
  -snapshots
  -enabledtrue/enabled
  -/snapshots
  -/repository
  -/repositories
 
   dependencyManagement
   dependencies
 
 
  and it has built on my computer running successfully all the integration
  tests:
 
  [INFO] Apache Karaf .. SUCCESS
 [1.119s]
  [INFO] Apache Karaf :: Util .. SUCCESS
 [1.333s]
  [INFO] Apache Karaf :: Main .. SUCCESS
  [30.767s]
  [INFO] Apache Karaf :: JAAS .. SUCCESS
 [0.067s]
  [INFO] Apache Karaf :: JAAS :: Boot .. SUCCESS
 [0.822s]
  [INFO] Apache Karaf :: JAAS :: Config  SUCCESS
 [2.382s]
  [INFO] Apache Karaf :: JAAS :: Modules ... SUCCESS
 [1.203s]
  [INFO] Apache Karaf :: Shell . SUCCESS
 [0.053s]
  [INFO] Apache Karaf :: Shell :: Console .. SUCCESS
 [2.710s]
  [INFO] Apache Karaf :: Shell :: OBR Commands . SUCCESS
 [1.016s]
  [INFO] Apache Karaf :: Features .. SUCCESS
 [0.039s]
  [INFO] Apache Karaf :: Features :: Core .. SUCCESS
 [6.582s]
  [INFO] Apache Karaf :: Features :: Command ... SUCCESS
 [0.916s]
  [INFO] Apache Karaf :: Management  SUCCESS
 [0.041s]
  [INFO] Apache Karaf :: Management  SUCCESS
 [1.099s]
  [INFO] Apache Karaf :: Features :: Management  SUCCESS
 [1.010s]
  [INFO] Apache Karaf :: Features :: OBR Resolver .. SUCCESS
 [0.968s]
  [INFO] Apache Karaf :: Admin . SUCCESS
 [0.036s]
  [INFO] Apache Karaf :: Admin :: Core . SUCCESS
 [3.323s]
  [INFO] Apache Karaf :: Admin :: Command .. SUCCESS
 [1.059s]
  [INFO] Apache Karaf :: Admin

Re: Upgrade Equinox to 3.9.1-v20130814-1242 for Karaf 2.3.5

[Cristiano Costantini]

One more word while I wait it to finish integration tests:
the problem with other repo is not when they are used for dependencies that
are required to build and then are included into the final artifact, like
it could be the case for ops4j.

But I found that problem while I was working on building next ServiceMix:
it means that org.eclipse:osgi is transitive to project using apache-karaf
dependency, and it is bad because version 3.8.0 and 3.8.2 are not available
on Maven Central Repo as it is the apache-karaf.






2014-02-17 10:17 GMT+01:00 Cristiano Costantini 
cristiano.costant...@gmail.com:

 Mmmm,
 I'll give it a build on a clean maven repo.


 2014-02-17 10:12 GMT+01:00 Achim Nierbeck bcanh...@googlemail.com:

 Hi,

 Just one note without trying. It won't work if you remove the snapshot
 repo
 for ops4j, the minute we have a snapshot dependency for either pax URL or
 web. Snapshots are not on maven central, releases are.

 Regards, achim

 sent from mobile device
 Am 17.02.2014 10:02 schrieb Cristiano Costantini 
 cristiano.costant...@gmail.com:

  Hi all,
  I have a severe allergy to maven projects that specify external
  repositories.
  To avoid them I use a local maven repo proxy (using Apache Archiva) as
  mirror which is allowed to retrieve only artifact from Maven Central
 Repo
  plus few others selected and trusted repos.
 
  Today I tried to build Apache Karaf 2.3.5-SNAPSHOT, and I got sick
  immediately when I got the error:
  [WARNING] The POM for org.eclipse:osgi:jar:3.8.0.v20120529-1548 is
 missing,
  no dependency information available
 
  (and I see that also Karaf 3.0.1-SNAPSHOT depends on equinox 3.8.2)
 
  So I did searched on search.maven.org, I saw that
  version 3.9.1-v20130814-1242, tried it and everything compiled really
 fine!
  And I now have version of Karaf I can use without using antihistamines.
 
  So, is it possible that Karaf 2.3.5-SNAPSHOT and 3.0.1-SNAPSHOT update
 to
  this version and remove external repo? Or are there other side effects
 I'm
  not aware of?
 
  I hope the community can evaluate this proposal and list pros and cons.
 
 
  For building, I used the following patches:
 
  diff --git a/pom.xml b/pom.xml
  index 6b56968..2ce1e97 100644
  --- a/pom.xml
  +++ b/pom.xml
  @@ -137,7 +137,7 @@
   geronimo.jta-spec.version1.1.1/geronimo.jta-spec.version
   geronimo.servlet.version1.2/geronimo.servlet.version
   easymock.version3.2/easymock.version
  -equinox.version3.8.0.v20120529-1548/equinox.version
  +equinox.version3.9.1-v20130814-1242/equinox.version
 
   felix.bundlerepository.version1.6.6/felix.bundlerepository.version
   felix.configadmin.version1.6.0/felix.configadmin.version
   felix.fileinstall.version3.2.8/felix.fileinstall.version
  @@ -229,32 +229,6 @@
 
 
 
  
 bnd.version.policy[$(version;==;$(@)),$(version;+;$(@)))/bnd.version.policy
   /properties
 
  -repositories
  -!-- ServiceMix repo --
  -repository
  -idservicemix/id
  -nameApache ServiceMix Repository/name
  -urlhttp://svn.apache.org/repos/asf/servicemix/m2-repo
 /url
  -releases
  -enabledtrue/enabled
  -/releases
  -snapshots
  -enabledfalse/enabled
  -/snapshots
  -/repository
  -!-- OPS4J SNAPSHOT repository --
  -repository
  -idops4j.sonatype.snapshots.deploy/id
  -nameOPS4J snapshot repository/name
  -url
  https://oss.sonatype.org/content/repositories/ops4j-snapshots//url
  -releases
  -enabledfalse/enabled
  -/releases
  -snapshots
  -enabledtrue/enabled
  -/snapshots
  -/repository
  -/repositories
 
   dependencyManagement
   dependencies
 
 
  and it has built on my computer running successfully all the integration
  tests:
 
  [INFO] Apache Karaf .. SUCCESS
 [1.119s]
  [INFO] Apache Karaf :: Util .. SUCCESS
 [1.333s]
  [INFO] Apache Karaf :: Main .. SUCCESS
  [30.767s]
  [INFO] Apache Karaf :: JAAS .. SUCCESS
 [0.067s]
  [INFO] Apache Karaf :: JAAS :: Boot .. SUCCESS
 [0.822s]
  [INFO] Apache Karaf :: JAAS :: Config  SUCCESS
 [2.382s]
  [INFO] Apache Karaf :: JAAS :: Modules ... SUCCESS
 [1.203s]
  [INFO] Apache Karaf :: Shell . SUCCESS
 [0.053s]
  [INFO] Apache Karaf :: Shell :: Console .. SUCCESS
 [2.710s]
  [INFO] Apache Karaf :: Shell :: OBR Commands . SUCCESS
 [1.016s]
  [INFO] Apache Karaf :: Features .. SUCCESS
 [0.039s]
  [INFO] Apache Karaf :: Features :: Core .. SUCCESS
 [6.582s]
  [INFO] Apache Karaf :: Features :: Command

Re: Upgrade Equinox to 3.9.1-v20130814-1242 for Karaf 2.3.5

[Cristiano Costantini]

Hi Achim,

I confirm it works on a clean maven local repo:

[...]
[INFO] Apache Karaf :: Archetypes :: Kar Archetype ... SUCCESS [2.392s]
[INFO] Apache Karaf :: Integration Tests . SUCCESS
[13:14.563s]
[INFO]

[INFO] BUILD SUCCESS
[INFO]

[INFO] Total time: 17:34.284s
[INFO] Finished at: Mon Feb 17 10:39:29 CET 2014
[INFO] Final Memory: 156M/603M
[INFO]

C:\dev\open-source\karaf

(this time I tested on Windows 7, previous build was on Mac OS X Mavericks)

after the build I have no snapshot of ops4j on my Maven local repo, here it
is the list of directories in /org/ops4j folder:
C:\DEV\MVN_REPOS\LOCAL\ORG\OPS4J
├───base
│   ├───1.2.2
│   ├───1.2.3
│   ├───1.3.0
│   ├───1.4.0
│   ├───ops4j-base-exec
│   │   └───1.3.0
│   ├───ops4j-base-io
│   │   ├───1.2.2
│   │   ├───1.2.3
│   │   ├───1.3.0
│   │   └───1.4.0
│   ├───ops4j-base-lang
│   │   └───1.4.0
│   ├───ops4j-base-monitors
│   │   ├───1.2.2
│   │   ├───1.2.3
│   │   ├───1.3.0
│   │   └───1.4.0
│   ├───ops4j-base-net
│   │   └───1.4.0
│   ├───ops4j-base-spi
│   │   └───1.3.0
│   ├───ops4j-base-store
│   │   ├───1.2.2
│   │   ├───1.2.3
│   │   └───1.4.0
│   ├───ops4j-base-util-collections
│   │   └───1.2.3
│   ├───ops4j-base-util-property
│   │   └───1.4.0
│   └───ops4j-base-util-xml
│   └───1.2.3
├───master
│   ├───1.0.4
│   ├───1.0.8
│   ├───2.0.0
│   ├───3.0.1
│   └───3.1.0
└───pax
├───cdi
│   └───pax-cdi-features
│   └───0.6.0
├───exam
│   ├───2.6.0
│   ├───pax-exam
│   │   └───2.6.0
│   ├───pax-exam-container-rbc
│   │   └───2.6.0
│   ├───pax-exam-container-rbc-client
│   │   └───2.6.0
│   ├───pax-exam-container-remote
│   │   └───2.6.0
│   ├───pax-exam-extender-service
│   │   └───2.6.0
│   ├───pax-exam-inject
│   │   └───2.6.0
│   ├───pax-exam-invoker-junit
│   │   └───2.6.0
│   ├───pax-exam-junit4
│   │   └───2.6.0
│   └───pax-exam-spi
│   └───2.6.0
├───exam-reactor
│   └───2.6.0
├───logging
│   ├───1.7.2
│   ├───pax-logging-api
│   │   └───1.7.2
│   └───pax-logging-service
│   └───1.7.2
├───master
│   └───3.1.3
├───swissbox
│   ├───1.3.2
│   ├───1.4.0
│   ├───1.5.1
│   ├───pax-swissbox-bnd
│   │   └───1.5.1
│   ├───pax-swissbox-core
│   │   ├───1.4.0
│   │   └───1.5.1
│   ├───pax-swissbox-extender
│   │   ├───1.4.0
│   │   └───1.5.1
│   ├───pax-swissbox-framework
│   │   └───1.5.1
│   ├───pax-swissbox-lifecycle
│   │   └───1.5.1
│   ├───pax-swissbox-optional-jcl
│   │   └───1.4.0
│   ├───pax-swissbox-tinybundles
│   │   └───1.3.2
│   └───pax-swissbox-tracker
│   └───1.5.1
├───tinybundles
│   └───tinybundles
│   └───1.0.0
├───url
│   ├───1.3.7
│   ├───pax-url-mvn
│   │   └───1.3.7
│   └───pax-url-wrap
│   └───1.3.7
└───web
├───1.1.16
├───pax-web-api
│   └───1.1.16
├───pax-web-deployer
│   └───1.1.16
├───pax-web-extender-war
│   └───1.1.16
├───pax-web-extender-whiteboard
│   └───1.1.16
├───pax-web-jetty
│   └───1.1.16
├───pax-web-jsp
│   └───1.1.16
├───pax-web-runtime
│   └───1.1.16
└───pax-web-spi
└───1.1.16





2014-02-17 10:34 GMT+01:00 Cristiano Costantini 
cristiano.costant...@gmail.com:

 One more word while I wait it to finish integration tests:
 the problem with other repo is not when they are used for dependencies
 that are required to build and then are included into the final artifact,
 like it could be the case for ops4j.

 But I found that problem while I was working on building next ServiceMix:
 it means that org.eclipse:osgi is transitive to project using apache-karaf
 dependency, and it is bad because version 3.8.0 and 3.8.2 are not available
 on Maven Central Repo as it is the apache-karaf.






 2014-02-17 10:17 GMT+01:00 Cristiano Costantini 
 cristiano.costant...@gmail.com:

 Mmmm,
 I'll give it a build on a clean maven repo.


 2014-02-17 10:12 GMT+01:00 Achim Nierbeck bcanh...@googlemail.com:

 Hi,

 Just one note without trying. It won't work if you remove the snapshot
 repo
 for ops4j, the minute we have a snapshot dependency for either pax URL or
 web. Snapshots are not on maven central, releases are.

 Regards, achim

 sent from mobile device
 Am 17.02.2014 10:02 schrieb Cristiano Costantini 
 cristiano.costant...@gmail.com:

  Hi all,
  I have a severe allergy to maven projects that specify external
  repositories.
  To avoid them I use a local maven repo proxy (using Apache Archiva) as
  mirror which is allowed to retrieve only artifact from Maven Central
 Repo