You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@karaf.apache.org by Benson Margulies <be...@basistech.com> on 2015/08/28 14:12:33 UTC
Lessons learned from my first attempt to use the pax-exam test container
In penance for my many emails, I am hoping that this message is
googleable for others, or can be adapted to documentation.
1: Beware of 'wrap'
-- or -- undefined protocol 'wrap:'
The karaf-maven-plugin will cheerfully create wrap urls, but does not
add a feature dependency for the wrap feature. This is fine in
production, where 'wrap' is boot and your feature is not. It's not so
good with pax-exam, where they are all boot features. Adding a
<feature prerequisite="true" dependency="true">wrap</feature>
to src/main/feature/feature.xml should fix this, but I chose to embed
my would-be wrapped dependencies instead.
2: Don't forget '<includeProjectArtifact>true</includeProjectArtifact>'
-- or -- missing package for your probe bundle, or elsewhere.
My feature consisted one one bundle of mine, plus its dependencies.
So, I added the feature descriptor as a plugin execution instead of
having a separate feature project. Turns out that the default is not
to include the current project's artifact.
3: Watch out for slf4j-api
-- or -- wiring errors with org.slf4j
You don't want slf4j-api in your feature(s) -- karaf supplies slf4j
via pax-logging. If you accidently include it, the result is a wiring
error.
4: Karaf does not do maven mirrors
If your standard maven settings include a * mirror, Karaf will hang,
due to Aether's desire to match up the metadata, even if you add your
mirror as an additional repo. I cured this with:
editConfigurationFilePut("etc/org.ops4j.pax.url.mvn.cfg",
"org.ops4j.pax.url.mvn.repositories", "http:/MY-MIRROR-URL"),
editConfigurationFilePut("etc/org.ops4j.pax.url.mvn.cfg",
"org.ops4j.pax.url.mvn.defaultLocalRepoAsRemote", "true"),
Re: Lessons learned from my first attempt to use the pax-exam test container
Posted by Achim Nierbeck <bc...@googlemail.com>.
Yeah as with spring it's better to use init methods.
Regards, Achim
sent from mobile device
Am 29.08.2015 2:02 nachm. schrieb "Benson Margulies" <be...@basistech.com>:
> I seem to have found a solution, though I am stumped by the lack of my
> own code in the stacktraces. I have a blueprint service. I had coded
> some substantive initialization in the constructor of the bean. I
> moved it to an init-method, and then problems all stopped.
>
> On Sat, Aug 29, 2015 at 7:46 AM, Benson Margulies <be...@basistech.com>
> wrote:
> > I turned the logging level to DEBUG all around:
> >
> > It hangs, but how it hangs is not simply repeatable. The next time I
> > ran it, no backtrace, just 'fileinstall' STOPPING and no further
> > progress. Below you'll see an exception. It looks as if all of this is
> > felix with a locking problem, but then why does it work in my office?
> >
> > kill -3 shows some things:
> >
> > pool-2-thread-1" #34 prio=5 os_prio=31 tid=0x00007febe31f0800
> > nid=0x8503 in Object.wait() [0x000000012d39c000]
> > java.lang.Thread.State: WAITING (on object monitor)
> > at java.lang.Object.wait(Native Method)
> > at java.lang.Object.wait(Object.java:502)
> > at org.apache.felix.framework.Felix.acquireGlobalLock(Felix.java:5332)
> > - locked <0x00000006c00dc780> (a [Ljava.lang.Object;)
> > at org.apache.felix.framework.Felix.installBundle(Felix.java:2990)
> > at
> org.apache.felix.framework.BundleContextImpl.installBundle(BundleContextImpl.java:167)
> > at
> org.eclipse.equinox.internal.region.BundleIdBasedRegion.installBundle0(BundleIdBasedRegion.java:117)
> > at
> org.eclipse.equinox.internal.region.BundleIdBasedRegion.installBundleAtLocation(BundleIdBasedRegion.java:97)
> > at
> org.apache.karaf.features.internal.service.FeaturesServiceImpl.installBundle(FeaturesServiceImpl.java:1164)
> > at
> org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:720)
> > at
> org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1079)
> > at
> org.apache.karaf.features.internal.service.FeaturesServiceImpl$1.call(FeaturesServiceImpl.java:975)
> > 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)
> >
> > "pool-1-thread-1" #33 prio=5 os_prio=31 tid=0x00007febe518e800
> > nid=0x8303 waiting on condition [0x000000012c900000]
> > java.lang.Thread.State: WAITING (parking)
> > at sun.misc.Unsafe.park(Native Method)
> > - parking to wait for <0x00000006c09d0c30> (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:972)
> > at
> org.apache.karaf.features.internal.service.FeaturesServiceImpl.installFeatures(FeaturesServiceImpl.java:854)
> > at
> org.apache.karaf.features.internal.service.FeaturesServiceImpl.installFeatures(FeaturesServiceImpl.java:771)
> > at
> org.apache.karaf.features.internal.service.BootFeaturesInstaller.installBootFeatures(BootFeaturesInstaller.java:95)
> > at
> org.apache.karaf.features.internal.service.BootFeaturesInstaller.start(BootFeaturesInstaller.java:76)
> > at
> org.apache.karaf.features.internal.osgi.Activator.doStart(Activator.java:257)
> > 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)
> >
> > Here's the less boring tail of a log:
> >
> > That geronimo bundle is not in my features.
> >
> > 2015-08-29 07:35:24,663 | ERROR | pool-1-thread-1 |
> > BootFeaturesInstaller | 8 - org.apache.karaf.features.core
> > - 4.0.1 | Error installing boot features
> > org.osgi.framework.BundleException: Bundle symbolic name and version
> > are not unique:
> > org.apache.geronimo.specs.geronimo-atinject_1.0_spec:1.0.0
> > at
> org.apache.felix.framework.BundleImpl.createRevision(BundleImpl.java:1313)[org.apache.felix.framework-5.0.1.jar:]
> > at
> org.apache.felix.framework.BundleImpl.<init>(BundleImpl.java:113)[org.apache.felix.framework-5.0.1.jar:]
> > at
> org.apache.felix.framework.Felix.installBundle(Felix.java:2998)[org.apache.felix.framework-5.0.1.jar:]
> > at
> org.apache.felix.framework.BundleContextImpl.installBundle(BundleContextImpl.java:167)[org.apache.felix.framework-5.0.1.jar:]
> > at
> org.eclipse.equinox.internal.region.BundleIdBasedRegion.installBundle0(BundleIdBasedRegion.java:117)[8:org.apache.karaf.features.core:4.0.1]
> > at
> org.eclipse.equinox.internal.region.BundleIdBasedRegion.installBundleAtLocation(BundleIdBasedRegion.java:97)[8:org.apache.karaf.features.core:4.0.1]
> > at
> org.apache.karaf.features.internal.service.FeaturesServiceImpl.installBundle(FeaturesServiceImpl.java:1164)[8:org.apache.karaf.features.core:4.0.1]
> > at
> org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:720)[8:org.apache.karaf.features.core:4.0.1]
> > at
> org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1079)[8:org.apache.karaf.features.core:4.0.1]
> > at
> org.apache.karaf.features.internal.service.FeaturesServiceImpl$1.call(FeaturesServiceImpl.java:975)[8:org.apache.karaf.features.core:4.0.1]
> > at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_05]
> > at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_05]
> > at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_05]
> > at java.lang.Thread.run(Thread.java:745)[:1.8.0_05]
> > 2015-08-29 07:35:24,666 | DEBUG | xFrameworkWiring | metatype
> > | 5 - org.apache.felix.metatype - 1.0.12 | BundleEvent
> > STOPPING - org.apache.felix.metatype
> > 2015-08-29 07:35:24,667 | DEBUG | pool-1-thread-1 | core
> > | 8 - org.apache.karaf.features.core - 4.0.1 |
> > ServiceEvent REGISTERED - [javax.management.MBeanRegistration,
> > org.apache.karaf.features.management.FeaturesServiceMBean,
> > javax.management.NotificationEmitter,
> > javax.management.NotificationBroadcaster,
> > javax.management.DynamicMBean, javax.management.MBeanRegistration] -
> > org.apache.karaf.features.core
> > 2015-08-29 07:35:24,667 | DEBUG | xFrameworkWiring | metatype
> > | 5 - org.apache.felix.metatype - 1.0.12 | ServiceEvent
> > UNREGISTERING - [org.osgi.service.metatype.MetaTypeService] -
> > org.apache.felix.metatype
> > 2015-08-29 07:35:24,668 | DEBUG | xFrameworkWiring | metatype
> > | 5 - org.apache.felix.metatype - 1.0.12 | BundleEvent
> > STOPPED - org.apache.felix.metatype
> > 2015-08-29 07:35:24,668 | DEBUG | xFrameworkWiring |
> > jackson-datatype-guava | 20 -
> > com.fasterxml.jackson.datatype.jackson-datatype-guava - 2.4.7.SNAPSHOT
> > | BundleEvent STOPPING -
> > com.fasterxml.jackson.datatype.jackson-datatype-guava
> > 2015-08-29 07:35:24,668 | DEBUG | xFrameworkWiring |
> > jackson-datatype-guava | 20 -
> > com.fasterxml.jackson.datatype.jackson-datatype-guava - 2.4.7.SNAPSHOT
> > | BundleEvent STOPPED -
> > com.fasterxml.jackson.datatype.jackson-datatype-guava
> > 2015-08-29 07:35:24,668 | DEBUG | xFrameworkWiring | core
> > | 9 - org.apache.karaf.log.core - 4.0.1 | BundleEvent
> > STOPPING - org.apache.karaf.log.core
> > 2015-08-29 07:35:24,668 | DEBUG | xFrameworkWiring | core
> > | 9 - org.apache.karaf.log.core - 4.0.1 | ServiceEvent
> > UNREGISTERING - [org.osgi.service.cm.ManagedService] -
> > org.apache.karaf.log.core
> > 2015-08-29 07:35:24,669 | DEBUG | xFrameworkWiring | core
> > | 9 - org.apache.karaf.log.core - 4.0.1 | ServiceEvent
> > UNREGISTERING - [org.ops4j.pax.logging.spi.PaxAppender] -
> > org.apache.karaf.log.core
> > 2015-08-29 07:35:24,669 | DEBUG | xFrameworkWiring | core
> > | 9 - org.apache.karaf.log.core - 4.0.1 | ServiceEvent
> > UNREGISTERING - [org.apache.karaf.log.core.LogEventFormatter] -
> > org.apache.karaf.log.core
> > 2015-08-29 07:35:24,669 | DEBUG | xFrameworkWiring | core
> > | 9 - org.apache.karaf.log.core - 4.0.1 | ServiceEvent
> > UNREGISTERING - [org.apache.karaf.log.core.LogService] -
> > org.apache.karaf.log.core
> > 2015-08-29 07:35:24,670 | DEBUG | xFrameworkWiring | core
> > | 9 - org.apache.karaf.log.core - 4.0.1 | ServiceEvent
> > UNREGISTERING - [org.apache.karaf.log.core.LogMBean,
> > javax.management.DynamicMBean, javax.management.MBeanRegistration] -
> > org.apache.karaf.log.core
> > 2015-08-29 07:35:24,670 | DEBUG | xFrameworkWiring | core
> > | 9 - org.apache.karaf.log.core - 4.0.1 | BundleEvent
> > STOPPED - org.apache.karaf.log.core
> > 2015-08-29 07:35:24,670 | DEBUG | xFrameworkWiring | fileinstall
> > | 4 - org.apache.felix.fileinstall - 3.5.0 |
> > BundleEvent STOPPING - org.apache.felix.fileinstall
> >
> > On Sat, Aug 29, 2015 at 7:30 AM, Benson Margulies <be...@basistech.com>
> wrote:
> >> Yes. There's only one user, me, I'm developing. All this email was me
> >> struggling to get one pax-exam test to work. And it seems as if the
> >> recipe was to (a) put the mirror in my ~/.m2/settings.xml, (b) use
> >> plain (*), not external:*. However, there is another aspect. When I
> >> was seeing those mysterious hangs, I was at home. When I got things
> >> working, I was in the office. My home does VPN to my office, but I've
> >> seen some odd error messages from Karaf in the past as if the DNS
> >> situation in my house is somehow problematic. And, as I type, I see it
> >> sitting there accomplishing nothing. I am suspicious of the setting:
> >>
> >> org.ops4j.pax.exam.rbc.rmi.host=tinfoilhat.local
> >>
> >> I am going to go try forcing 'localhost'.
> >>
> >> In my previous iteration, when I moved from dev to deployment, I
> >> reconfigured that file to never talk to the network, and all was well
> >> for other users.
> >>
> >> On Sat, Aug 29, 2015 at 7:18 AM, Jean-Baptiste Onofré <jb...@nanthrax.net>
> wrote:
> >>> And the .m2/settings.xml of the user who is running Karaf contains the
> proxy
> >>> setting ?
> >>>
> >>> Regards
> >>> JB
> >>>
> >>>
> >>> On 08/29/2015 01:15 PM, Benson Margulies wrote:
> >>>>
> >>>> Hmm. The file comments say that it looks at:
> >>>>
> >>>> 2. if not found looks for ${user.home}/.m2/settings.xml
> >>>>
> >>>> if not called out, and it _seems_ to be working fine for me.
> >>>>
> >>>> On Sat, Aug 29, 2015 at 1:12 AM, Jean-Baptiste Onofré <
> jb@nanthrax.net>
> >>>> wrote:
> >>>>>
> >>>>> The settings.xml update is not enough: as I said, you have to
> specify the
> >>>>> location of the settings.xml in etc/org.ops4j.pax.url.mvn.cfg as
> well.
> >>>>>
> >>>>> Regards
> >>>>> JB
> >>>>>
> >>>>>
> >>>>> On 08/28/2015 05:17 PM, Benson Margulies wrote:
> >>>>>>
> >>>>>>
> >>>>>> Hmm. I tried adding it to my ~/.m2/settings.xml and that didn't seem
> >>>>>> to work. I'll try again.
> >>>>>>
> >>>>>>
> >>>>>> On Fri, Aug 28, 2015 at 10:20 AM, Jean-Baptiste Onofré <
> jb@nanthrax.net>
> >>>>>> wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>> Hi Benson,
> >>>>>>>
> >>>>>>> for 4 (mirror), you can also update etc/org.ops4j.pax.url.mvn.cfg
> to
> >>>>>>> define
> >>>>>>> the location of a settings.xml containing the mirror definition.
> >>>>>>>
> >>>>>>> Regards
> >>>>>>> JB
> >>>>>>>
> >>>>>>>
> >>>>>>> On 08/28/2015 02:12 PM, Benson Margulies wrote:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> In penance for my many emails, I am hoping that this message is
> >>>>>>>> googleable for others, or can be adapted to documentation.
> >>>>>>>>
> >>>>>>>> 1: Beware of 'wrap'
> >>>>>>>>
> >>>>>>>> -- or -- undefined protocol 'wrap:'
> >>>>>>>>
> >>>>>>>> The karaf-maven-plugin will cheerfully create wrap urls, but does
> not
> >>>>>>>> add a feature dependency for the wrap feature. This is fine in
> >>>>>>>> production, where 'wrap' is boot and your feature is not. It's
> not so
> >>>>>>>> good with pax-exam, where they are all boot features. Adding a
> >>>>>>>>
> >>>>>>>> <feature prerequisite="true"
> dependency="true">wrap</feature>
> >>>>>>>>
> >>>>>>>> to src/main/feature/feature.xml should fix this, but I chose to
> embed
> >>>>>>>> my would-be wrapped dependencies instead.
> >>>>>>>>
> >>>>>>>> 2: Don't forget
> >>>>>>>> '<includeProjectArtifact>true</includeProjectArtifact>'
> >>>>>>>>
> >>>>>>>> -- or -- missing package for your probe bundle, or elsewhere.
> >>>>>>>>
> >>>>>>>> My feature consisted one one bundle of mine, plus its
> dependencies.
> >>>>>>>> So, I added the feature descriptor as a plugin execution instead
> of
> >>>>>>>> having a separate feature project. Turns out that the default is
> not
> >>>>>>>> to include the current project's artifact.
> >>>>>>>>
> >>>>>>>> 3: Watch out for slf4j-api
> >>>>>>>>
> >>>>>>>> -- or -- wiring errors with org.slf4j
> >>>>>>>>
> >>>>>>>> You don't want slf4j-api in your feature(s) -- karaf supplies
> slf4j
> >>>>>>>> via pax-logging. If you accidently include it, the result is a
> wiring
> >>>>>>>> error.
> >>>>>>>>
> >>>>>>>> 4: Karaf does not do maven mirrors
> >>>>>>>>
> >>>>>>>> If your standard maven settings include a * mirror, Karaf will
> hang,
> >>>>>>>> due to Aether's desire to match up the metadata, even if you add
> your
> >>>>>>>> mirror as an additional repo. I cured this with:
> >>>>>>>>
> >>>>>>>> editConfigurationFilePut("etc/org.ops4j.pax.url.mvn.cfg",
> >>>>>>>> "org.ops4j.pax.url.mvn.repositories", "http:/MY-MIRROR-URL"),
> >>>>>>>> editConfigurationFilePut("etc/org.ops4j.pax.url.mvn.cfg",
> >>>>>>>> "org.ops4j.pax.url.mvn.defaultLocalRepoAsRemote", "true"),
> >>>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> Jean-Baptiste Onofré
> >>>>>>> jbonofre@apache.org
> >>>>>>> http://blog.nanthrax.net
> >>>>>>> Talend - http://www.talend.com
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Jean-Baptiste Onofré
> >>>>> jbonofre@apache.org
> >>>>> http://blog.nanthrax.net
> >>>>> Talend - http://www.talend.com
> >>>
> >>>
> >>> --
> >>> Jean-Baptiste Onofré
> >>> jbonofre@apache.org
> >>> http://blog.nanthrax.net
> >>> Talend - http://www.talend.com
>
Re: Lessons learned from my first attempt to use the pax-exam test container
Posted by Benson Margulies <be...@basistech.com>.
I seem to have found a solution, though I am stumped by the lack of my
own code in the stacktraces. I have a blueprint service. I had coded
some substantive initialization in the constructor of the bean. I
moved it to an init-method, and then problems all stopped.
On Sat, Aug 29, 2015 at 7:46 AM, Benson Margulies <be...@basistech.com> wrote:
> I turned the logging level to DEBUG all around:
>
> It hangs, but how it hangs is not simply repeatable. The next time I
> ran it, no backtrace, just 'fileinstall' STOPPING and no further
> progress. Below you'll see an exception. It looks as if all of this is
> felix with a locking problem, but then why does it work in my office?
>
> kill -3 shows some things:
>
> pool-2-thread-1" #34 prio=5 os_prio=31 tid=0x00007febe31f0800
> nid=0x8503 in Object.wait() [0x000000012d39c000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> at java.lang.Object.wait(Object.java:502)
> at org.apache.felix.framework.Felix.acquireGlobalLock(Felix.java:5332)
> - locked <0x00000006c00dc780> (a [Ljava.lang.Object;)
> at org.apache.felix.framework.Felix.installBundle(Felix.java:2990)
> at org.apache.felix.framework.BundleContextImpl.installBundle(BundleContextImpl.java:167)
> at org.eclipse.equinox.internal.region.BundleIdBasedRegion.installBundle0(BundleIdBasedRegion.java:117)
> at org.eclipse.equinox.internal.region.BundleIdBasedRegion.installBundleAtLocation(BundleIdBasedRegion.java:97)
> at org.apache.karaf.features.internal.service.FeaturesServiceImpl.installBundle(FeaturesServiceImpl.java:1164)
> at org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:720)
> at org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1079)
> at org.apache.karaf.features.internal.service.FeaturesServiceImpl$1.call(FeaturesServiceImpl.java:975)
> 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)
>
> "pool-1-thread-1" #33 prio=5 os_prio=31 tid=0x00007febe518e800
> nid=0x8303 waiting on condition [0x000000012c900000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x00000006c09d0c30> (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:972)
> at org.apache.karaf.features.internal.service.FeaturesServiceImpl.installFeatures(FeaturesServiceImpl.java:854)
> at org.apache.karaf.features.internal.service.FeaturesServiceImpl.installFeatures(FeaturesServiceImpl.java:771)
> at org.apache.karaf.features.internal.service.BootFeaturesInstaller.installBootFeatures(BootFeaturesInstaller.java:95)
> at org.apache.karaf.features.internal.service.BootFeaturesInstaller.start(BootFeaturesInstaller.java:76)
> at org.apache.karaf.features.internal.osgi.Activator.doStart(Activator.java:257)
> 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)
>
> Here's the less boring tail of a log:
>
> That geronimo bundle is not in my features.
>
> 2015-08-29 07:35:24,663 | ERROR | pool-1-thread-1 |
> BootFeaturesInstaller | 8 - org.apache.karaf.features.core
> - 4.0.1 | Error installing boot features
> org.osgi.framework.BundleException: Bundle symbolic name and version
> are not unique:
> org.apache.geronimo.specs.geronimo-atinject_1.0_spec:1.0.0
> at org.apache.felix.framework.BundleImpl.createRevision(BundleImpl.java:1313)[org.apache.felix.framework-5.0.1.jar:]
> at org.apache.felix.framework.BundleImpl.<init>(BundleImpl.java:113)[org.apache.felix.framework-5.0.1.jar:]
> at org.apache.felix.framework.Felix.installBundle(Felix.java:2998)[org.apache.felix.framework-5.0.1.jar:]
> at org.apache.felix.framework.BundleContextImpl.installBundle(BundleContextImpl.java:167)[org.apache.felix.framework-5.0.1.jar:]
> at org.eclipse.equinox.internal.region.BundleIdBasedRegion.installBundle0(BundleIdBasedRegion.java:117)[8:org.apache.karaf.features.core:4.0.1]
> at org.eclipse.equinox.internal.region.BundleIdBasedRegion.installBundleAtLocation(BundleIdBasedRegion.java:97)[8:org.apache.karaf.features.core:4.0.1]
> at org.apache.karaf.features.internal.service.FeaturesServiceImpl.installBundle(FeaturesServiceImpl.java:1164)[8:org.apache.karaf.features.core:4.0.1]
> at org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:720)[8:org.apache.karaf.features.core:4.0.1]
> at org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1079)[8:org.apache.karaf.features.core:4.0.1]
> at org.apache.karaf.features.internal.service.FeaturesServiceImpl$1.call(FeaturesServiceImpl.java:975)[8:org.apache.karaf.features.core:4.0.1]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_05]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_05]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_05]
> at java.lang.Thread.run(Thread.java:745)[:1.8.0_05]
> 2015-08-29 07:35:24,666 | DEBUG | xFrameworkWiring | metatype
> | 5 - org.apache.felix.metatype - 1.0.12 | BundleEvent
> STOPPING - org.apache.felix.metatype
> 2015-08-29 07:35:24,667 | DEBUG | pool-1-thread-1 | core
> | 8 - org.apache.karaf.features.core - 4.0.1 |
> ServiceEvent REGISTERED - [javax.management.MBeanRegistration,
> org.apache.karaf.features.management.FeaturesServiceMBean,
> javax.management.NotificationEmitter,
> javax.management.NotificationBroadcaster,
> javax.management.DynamicMBean, javax.management.MBeanRegistration] -
> org.apache.karaf.features.core
> 2015-08-29 07:35:24,667 | DEBUG | xFrameworkWiring | metatype
> | 5 - org.apache.felix.metatype - 1.0.12 | ServiceEvent
> UNREGISTERING - [org.osgi.service.metatype.MetaTypeService] -
> org.apache.felix.metatype
> 2015-08-29 07:35:24,668 | DEBUG | xFrameworkWiring | metatype
> | 5 - org.apache.felix.metatype - 1.0.12 | BundleEvent
> STOPPED - org.apache.felix.metatype
> 2015-08-29 07:35:24,668 | DEBUG | xFrameworkWiring |
> jackson-datatype-guava | 20 -
> com.fasterxml.jackson.datatype.jackson-datatype-guava - 2.4.7.SNAPSHOT
> | BundleEvent STOPPING -
> com.fasterxml.jackson.datatype.jackson-datatype-guava
> 2015-08-29 07:35:24,668 | DEBUG | xFrameworkWiring |
> jackson-datatype-guava | 20 -
> com.fasterxml.jackson.datatype.jackson-datatype-guava - 2.4.7.SNAPSHOT
> | BundleEvent STOPPED -
> com.fasterxml.jackson.datatype.jackson-datatype-guava
> 2015-08-29 07:35:24,668 | DEBUG | xFrameworkWiring | core
> | 9 - org.apache.karaf.log.core - 4.0.1 | BundleEvent
> STOPPING - org.apache.karaf.log.core
> 2015-08-29 07:35:24,668 | DEBUG | xFrameworkWiring | core
> | 9 - org.apache.karaf.log.core - 4.0.1 | ServiceEvent
> UNREGISTERING - [org.osgi.service.cm.ManagedService] -
> org.apache.karaf.log.core
> 2015-08-29 07:35:24,669 | DEBUG | xFrameworkWiring | core
> | 9 - org.apache.karaf.log.core - 4.0.1 | ServiceEvent
> UNREGISTERING - [org.ops4j.pax.logging.spi.PaxAppender] -
> org.apache.karaf.log.core
> 2015-08-29 07:35:24,669 | DEBUG | xFrameworkWiring | core
> | 9 - org.apache.karaf.log.core - 4.0.1 | ServiceEvent
> UNREGISTERING - [org.apache.karaf.log.core.LogEventFormatter] -
> org.apache.karaf.log.core
> 2015-08-29 07:35:24,669 | DEBUG | xFrameworkWiring | core
> | 9 - org.apache.karaf.log.core - 4.0.1 | ServiceEvent
> UNREGISTERING - [org.apache.karaf.log.core.LogService] -
> org.apache.karaf.log.core
> 2015-08-29 07:35:24,670 | DEBUG | xFrameworkWiring | core
> | 9 - org.apache.karaf.log.core - 4.0.1 | ServiceEvent
> UNREGISTERING - [org.apache.karaf.log.core.LogMBean,
> javax.management.DynamicMBean, javax.management.MBeanRegistration] -
> org.apache.karaf.log.core
> 2015-08-29 07:35:24,670 | DEBUG | xFrameworkWiring | core
> | 9 - org.apache.karaf.log.core - 4.0.1 | BundleEvent
> STOPPED - org.apache.karaf.log.core
> 2015-08-29 07:35:24,670 | DEBUG | xFrameworkWiring | fileinstall
> | 4 - org.apache.felix.fileinstall - 3.5.0 |
> BundleEvent STOPPING - org.apache.felix.fileinstall
>
> On Sat, Aug 29, 2015 at 7:30 AM, Benson Margulies <be...@basistech.com> wrote:
>> Yes. There's only one user, me, I'm developing. All this email was me
>> struggling to get one pax-exam test to work. And it seems as if the
>> recipe was to (a) put the mirror in my ~/.m2/settings.xml, (b) use
>> plain (*), not external:*. However, there is another aspect. When I
>> was seeing those mysterious hangs, I was at home. When I got things
>> working, I was in the office. My home does VPN to my office, but I've
>> seen some odd error messages from Karaf in the past as if the DNS
>> situation in my house is somehow problematic. And, as I type, I see it
>> sitting there accomplishing nothing. I am suspicious of the setting:
>>
>> org.ops4j.pax.exam.rbc.rmi.host=tinfoilhat.local
>>
>> I am going to go try forcing 'localhost'.
>>
>> In my previous iteration, when I moved from dev to deployment, I
>> reconfigured that file to never talk to the network, and all was well
>> for other users.
>>
>> On Sat, Aug 29, 2015 at 7:18 AM, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
>>> And the .m2/settings.xml of the user who is running Karaf contains the proxy
>>> setting ?
>>>
>>> Regards
>>> JB
>>>
>>>
>>> On 08/29/2015 01:15 PM, Benson Margulies wrote:
>>>>
>>>> Hmm. The file comments say that it looks at:
>>>>
>>>> 2. if not found looks for ${user.home}/.m2/settings.xml
>>>>
>>>> if not called out, and it _seems_ to be working fine for me.
>>>>
>>>> On Sat, Aug 29, 2015 at 1:12 AM, Jean-Baptiste Onofré <jb...@nanthrax.net>
>>>> wrote:
>>>>>
>>>>> The settings.xml update is not enough: as I said, you have to specify the
>>>>> location of the settings.xml in etc/org.ops4j.pax.url.mvn.cfg as well.
>>>>>
>>>>> Regards
>>>>> JB
>>>>>
>>>>>
>>>>> On 08/28/2015 05:17 PM, Benson Margulies wrote:
>>>>>>
>>>>>>
>>>>>> Hmm. I tried adding it to my ~/.m2/settings.xml and that didn't seem
>>>>>> to work. I'll try again.
>>>>>>
>>>>>>
>>>>>> On Fri, Aug 28, 2015 at 10:20 AM, Jean-Baptiste Onofré <jb...@nanthrax.net>
>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>> Hi Benson,
>>>>>>>
>>>>>>> for 4 (mirror), you can also update etc/org.ops4j.pax.url.mvn.cfg to
>>>>>>> define
>>>>>>> the location of a settings.xml containing the mirror definition.
>>>>>>>
>>>>>>> Regards
>>>>>>> JB
>>>>>>>
>>>>>>>
>>>>>>> On 08/28/2015 02:12 PM, Benson Margulies wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> In penance for my many emails, I am hoping that this message is
>>>>>>>> googleable for others, or can be adapted to documentation.
>>>>>>>>
>>>>>>>> 1: Beware of 'wrap'
>>>>>>>>
>>>>>>>> -- or -- undefined protocol 'wrap:'
>>>>>>>>
>>>>>>>> The karaf-maven-plugin will cheerfully create wrap urls, but does not
>>>>>>>> add a feature dependency for the wrap feature. This is fine in
>>>>>>>> production, where 'wrap' is boot and your feature is not. It's not so
>>>>>>>> good with pax-exam, where they are all boot features. Adding a
>>>>>>>>
>>>>>>>> <feature prerequisite="true" dependency="true">wrap</feature>
>>>>>>>>
>>>>>>>> to src/main/feature/feature.xml should fix this, but I chose to embed
>>>>>>>> my would-be wrapped dependencies instead.
>>>>>>>>
>>>>>>>> 2: Don't forget
>>>>>>>> '<includeProjectArtifact>true</includeProjectArtifact>'
>>>>>>>>
>>>>>>>> -- or -- missing package for your probe bundle, or elsewhere.
>>>>>>>>
>>>>>>>> My feature consisted one one bundle of mine, plus its dependencies.
>>>>>>>> So, I added the feature descriptor as a plugin execution instead of
>>>>>>>> having a separate feature project. Turns out that the default is not
>>>>>>>> to include the current project's artifact.
>>>>>>>>
>>>>>>>> 3: Watch out for slf4j-api
>>>>>>>>
>>>>>>>> -- or -- wiring errors with org.slf4j
>>>>>>>>
>>>>>>>> You don't want slf4j-api in your feature(s) -- karaf supplies slf4j
>>>>>>>> via pax-logging. If you accidently include it, the result is a wiring
>>>>>>>> error.
>>>>>>>>
>>>>>>>> 4: Karaf does not do maven mirrors
>>>>>>>>
>>>>>>>> If your standard maven settings include a * mirror, Karaf will hang,
>>>>>>>> due to Aether's desire to match up the metadata, even if you add your
>>>>>>>> mirror as an additional repo. I cured this with:
>>>>>>>>
>>>>>>>> editConfigurationFilePut("etc/org.ops4j.pax.url.mvn.cfg",
>>>>>>>> "org.ops4j.pax.url.mvn.repositories", "http:/MY-MIRROR-URL"),
>>>>>>>> editConfigurationFilePut("etc/org.ops4j.pax.url.mvn.cfg",
>>>>>>>> "org.ops4j.pax.url.mvn.defaultLocalRepoAsRemote", "true"),
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Jean-Baptiste Onofré
>>>>>>> jbonofre@apache.org
>>>>>>> http://blog.nanthrax.net
>>>>>>> Talend - http://www.talend.com
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Jean-Baptiste Onofré
>>>>> jbonofre@apache.org
>>>>> http://blog.nanthrax.net
>>>>> Talend - http://www.talend.com
>>>
>>>
>>> --
>>> Jean-Baptiste Onofré
>>> jbonofre@apache.org
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
Re: Lessons learned from my first attempt to use the pax-exam test container
Posted by Benson Margulies <be...@basistech.com>.
I turned the logging level to DEBUG all around:
It hangs, but how it hangs is not simply repeatable. The next time I
ran it, no backtrace, just 'fileinstall' STOPPING and no further
progress. Below you'll see an exception. It looks as if all of this is
felix with a locking problem, but then why does it work in my office?
kill -3 shows some things:
pool-2-thread-1" #34 prio=5 os_prio=31 tid=0x00007febe31f0800
nid=0x8503 in Object.wait() [0x000000012d39c000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:502)
at org.apache.felix.framework.Felix.acquireGlobalLock(Felix.java:5332)
- locked <0x00000006c00dc780> (a [Ljava.lang.Object;)
at org.apache.felix.framework.Felix.installBundle(Felix.java:2990)
at org.apache.felix.framework.BundleContextImpl.installBundle(BundleContextImpl.java:167)
at org.eclipse.equinox.internal.region.BundleIdBasedRegion.installBundle0(BundleIdBasedRegion.java:117)
at org.eclipse.equinox.internal.region.BundleIdBasedRegion.installBundleAtLocation(BundleIdBasedRegion.java:97)
at org.apache.karaf.features.internal.service.FeaturesServiceImpl.installBundle(FeaturesServiceImpl.java:1164)
at org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:720)
at org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1079)
at org.apache.karaf.features.internal.service.FeaturesServiceImpl$1.call(FeaturesServiceImpl.java:975)
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)
"pool-1-thread-1" #33 prio=5 os_prio=31 tid=0x00007febe518e800
nid=0x8303 waiting on condition [0x000000012c900000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x00000006c09d0c30> (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:972)
at org.apache.karaf.features.internal.service.FeaturesServiceImpl.installFeatures(FeaturesServiceImpl.java:854)
at org.apache.karaf.features.internal.service.FeaturesServiceImpl.installFeatures(FeaturesServiceImpl.java:771)
at org.apache.karaf.features.internal.service.BootFeaturesInstaller.installBootFeatures(BootFeaturesInstaller.java:95)
at org.apache.karaf.features.internal.service.BootFeaturesInstaller.start(BootFeaturesInstaller.java:76)
at org.apache.karaf.features.internal.osgi.Activator.doStart(Activator.java:257)
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)
Here's the less boring tail of a log:
That geronimo bundle is not in my features.
2015-08-29 07:35:24,663 | ERROR | pool-1-thread-1 |
BootFeaturesInstaller | 8 - org.apache.karaf.features.core
- 4.0.1 | Error installing boot features
org.osgi.framework.BundleException: Bundle symbolic name and version
are not unique:
org.apache.geronimo.specs.geronimo-atinject_1.0_spec:1.0.0
at org.apache.felix.framework.BundleImpl.createRevision(BundleImpl.java:1313)[org.apache.felix.framework-5.0.1.jar:]
at org.apache.felix.framework.BundleImpl.<init>(BundleImpl.java:113)[org.apache.felix.framework-5.0.1.jar:]
at org.apache.felix.framework.Felix.installBundle(Felix.java:2998)[org.apache.felix.framework-5.0.1.jar:]
at org.apache.felix.framework.BundleContextImpl.installBundle(BundleContextImpl.java:167)[org.apache.felix.framework-5.0.1.jar:]
at org.eclipse.equinox.internal.region.BundleIdBasedRegion.installBundle0(BundleIdBasedRegion.java:117)[8:org.apache.karaf.features.core:4.0.1]
at org.eclipse.equinox.internal.region.BundleIdBasedRegion.installBundleAtLocation(BundleIdBasedRegion.java:97)[8:org.apache.karaf.features.core:4.0.1]
at org.apache.karaf.features.internal.service.FeaturesServiceImpl.installBundle(FeaturesServiceImpl.java:1164)[8:org.apache.karaf.features.core:4.0.1]
at org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:720)[8:org.apache.karaf.features.core:4.0.1]
at org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1079)[8:org.apache.karaf.features.core:4.0.1]
at org.apache.karaf.features.internal.service.FeaturesServiceImpl$1.call(FeaturesServiceImpl.java:975)[8:org.apache.karaf.features.core:4.0.1]
at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_05]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_05]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_05]
at java.lang.Thread.run(Thread.java:745)[:1.8.0_05]
2015-08-29 07:35:24,666 | DEBUG | xFrameworkWiring | metatype
| 5 - org.apache.felix.metatype - 1.0.12 | BundleEvent
STOPPING - org.apache.felix.metatype
2015-08-29 07:35:24,667 | DEBUG | pool-1-thread-1 | core
| 8 - org.apache.karaf.features.core - 4.0.1 |
ServiceEvent REGISTERED - [javax.management.MBeanRegistration,
org.apache.karaf.features.management.FeaturesServiceMBean,
javax.management.NotificationEmitter,
javax.management.NotificationBroadcaster,
javax.management.DynamicMBean, javax.management.MBeanRegistration] -
org.apache.karaf.features.core
2015-08-29 07:35:24,667 | DEBUG | xFrameworkWiring | metatype
| 5 - org.apache.felix.metatype - 1.0.12 | ServiceEvent
UNREGISTERING - [org.osgi.service.metatype.MetaTypeService] -
org.apache.felix.metatype
2015-08-29 07:35:24,668 | DEBUG | xFrameworkWiring | metatype
| 5 - org.apache.felix.metatype - 1.0.12 | BundleEvent
STOPPED - org.apache.felix.metatype
2015-08-29 07:35:24,668 | DEBUG | xFrameworkWiring |
jackson-datatype-guava | 20 -
com.fasterxml.jackson.datatype.jackson-datatype-guava - 2.4.7.SNAPSHOT
| BundleEvent STOPPING -
com.fasterxml.jackson.datatype.jackson-datatype-guava
2015-08-29 07:35:24,668 | DEBUG | xFrameworkWiring |
jackson-datatype-guava | 20 -
com.fasterxml.jackson.datatype.jackson-datatype-guava - 2.4.7.SNAPSHOT
| BundleEvent STOPPED -
com.fasterxml.jackson.datatype.jackson-datatype-guava
2015-08-29 07:35:24,668 | DEBUG | xFrameworkWiring | core
| 9 - org.apache.karaf.log.core - 4.0.1 | BundleEvent
STOPPING - org.apache.karaf.log.core
2015-08-29 07:35:24,668 | DEBUG | xFrameworkWiring | core
| 9 - org.apache.karaf.log.core - 4.0.1 | ServiceEvent
UNREGISTERING - [org.osgi.service.cm.ManagedService] -
org.apache.karaf.log.core
2015-08-29 07:35:24,669 | DEBUG | xFrameworkWiring | core
| 9 - org.apache.karaf.log.core - 4.0.1 | ServiceEvent
UNREGISTERING - [org.ops4j.pax.logging.spi.PaxAppender] -
org.apache.karaf.log.core
2015-08-29 07:35:24,669 | DEBUG | xFrameworkWiring | core
| 9 - org.apache.karaf.log.core - 4.0.1 | ServiceEvent
UNREGISTERING - [org.apache.karaf.log.core.LogEventFormatter] -
org.apache.karaf.log.core
2015-08-29 07:35:24,669 | DEBUG | xFrameworkWiring | core
| 9 - org.apache.karaf.log.core - 4.0.1 | ServiceEvent
UNREGISTERING - [org.apache.karaf.log.core.LogService] -
org.apache.karaf.log.core
2015-08-29 07:35:24,670 | DEBUG | xFrameworkWiring | core
| 9 - org.apache.karaf.log.core - 4.0.1 | ServiceEvent
UNREGISTERING - [org.apache.karaf.log.core.LogMBean,
javax.management.DynamicMBean, javax.management.MBeanRegistration] -
org.apache.karaf.log.core
2015-08-29 07:35:24,670 | DEBUG | xFrameworkWiring | core
| 9 - org.apache.karaf.log.core - 4.0.1 | BundleEvent
STOPPED - org.apache.karaf.log.core
2015-08-29 07:35:24,670 | DEBUG | xFrameworkWiring | fileinstall
| 4 - org.apache.felix.fileinstall - 3.5.0 |
BundleEvent STOPPING - org.apache.felix.fileinstall
On Sat, Aug 29, 2015 at 7:30 AM, Benson Margulies <be...@basistech.com> wrote:
> Yes. There's only one user, me, I'm developing. All this email was me
> struggling to get one pax-exam test to work. And it seems as if the
> recipe was to (a) put the mirror in my ~/.m2/settings.xml, (b) use
> plain (*), not external:*. However, there is another aspect. When I
> was seeing those mysterious hangs, I was at home. When I got things
> working, I was in the office. My home does VPN to my office, but I've
> seen some odd error messages from Karaf in the past as if the DNS
> situation in my house is somehow problematic. And, as I type, I see it
> sitting there accomplishing nothing. I am suspicious of the setting:
>
> org.ops4j.pax.exam.rbc.rmi.host=tinfoilhat.local
>
> I am going to go try forcing 'localhost'.
>
> In my previous iteration, when I moved from dev to deployment, I
> reconfigured that file to never talk to the network, and all was well
> for other users.
>
> On Sat, Aug 29, 2015 at 7:18 AM, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
>> And the .m2/settings.xml of the user who is running Karaf contains the proxy
>> setting ?
>>
>> Regards
>> JB
>>
>>
>> On 08/29/2015 01:15 PM, Benson Margulies wrote:
>>>
>>> Hmm. The file comments say that it looks at:
>>>
>>> 2. if not found looks for ${user.home}/.m2/settings.xml
>>>
>>> if not called out, and it _seems_ to be working fine for me.
>>>
>>> On Sat, Aug 29, 2015 at 1:12 AM, Jean-Baptiste Onofré <jb...@nanthrax.net>
>>> wrote:
>>>>
>>>> The settings.xml update is not enough: as I said, you have to specify the
>>>> location of the settings.xml in etc/org.ops4j.pax.url.mvn.cfg as well.
>>>>
>>>> Regards
>>>> JB
>>>>
>>>>
>>>> On 08/28/2015 05:17 PM, Benson Margulies wrote:
>>>>>
>>>>>
>>>>> Hmm. I tried adding it to my ~/.m2/settings.xml and that didn't seem
>>>>> to work. I'll try again.
>>>>>
>>>>>
>>>>> On Fri, Aug 28, 2015 at 10:20 AM, Jean-Baptiste Onofré <jb...@nanthrax.net>
>>>>> wrote:
>>>>>>
>>>>>>
>>>>>> Hi Benson,
>>>>>>
>>>>>> for 4 (mirror), you can also update etc/org.ops4j.pax.url.mvn.cfg to
>>>>>> define
>>>>>> the location of a settings.xml containing the mirror definition.
>>>>>>
>>>>>> Regards
>>>>>> JB
>>>>>>
>>>>>>
>>>>>> On 08/28/2015 02:12 PM, Benson Margulies wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> In penance for my many emails, I am hoping that this message is
>>>>>>> googleable for others, or can be adapted to documentation.
>>>>>>>
>>>>>>> 1: Beware of 'wrap'
>>>>>>>
>>>>>>> -- or -- undefined protocol 'wrap:'
>>>>>>>
>>>>>>> The karaf-maven-plugin will cheerfully create wrap urls, but does not
>>>>>>> add a feature dependency for the wrap feature. This is fine in
>>>>>>> production, where 'wrap' is boot and your feature is not. It's not so
>>>>>>> good with pax-exam, where they are all boot features. Adding a
>>>>>>>
>>>>>>> <feature prerequisite="true" dependency="true">wrap</feature>
>>>>>>>
>>>>>>> to src/main/feature/feature.xml should fix this, but I chose to embed
>>>>>>> my would-be wrapped dependencies instead.
>>>>>>>
>>>>>>> 2: Don't forget
>>>>>>> '<includeProjectArtifact>true</includeProjectArtifact>'
>>>>>>>
>>>>>>> -- or -- missing package for your probe bundle, or elsewhere.
>>>>>>>
>>>>>>> My feature consisted one one bundle of mine, plus its dependencies.
>>>>>>> So, I added the feature descriptor as a plugin execution instead of
>>>>>>> having a separate feature project. Turns out that the default is not
>>>>>>> to include the current project's artifact.
>>>>>>>
>>>>>>> 3: Watch out for slf4j-api
>>>>>>>
>>>>>>> -- or -- wiring errors with org.slf4j
>>>>>>>
>>>>>>> You don't want slf4j-api in your feature(s) -- karaf supplies slf4j
>>>>>>> via pax-logging. If you accidently include it, the result is a wiring
>>>>>>> error.
>>>>>>>
>>>>>>> 4: Karaf does not do maven mirrors
>>>>>>>
>>>>>>> If your standard maven settings include a * mirror, Karaf will hang,
>>>>>>> due to Aether's desire to match up the metadata, even if you add your
>>>>>>> mirror as an additional repo. I cured this with:
>>>>>>>
>>>>>>> editConfigurationFilePut("etc/org.ops4j.pax.url.mvn.cfg",
>>>>>>> "org.ops4j.pax.url.mvn.repositories", "http:/MY-MIRROR-URL"),
>>>>>>> editConfigurationFilePut("etc/org.ops4j.pax.url.mvn.cfg",
>>>>>>> "org.ops4j.pax.url.mvn.defaultLocalRepoAsRemote", "true"),
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Jean-Baptiste Onofré
>>>>>> jbonofre@apache.org
>>>>>> http://blog.nanthrax.net
>>>>>> Talend - http://www.talend.com
>>>>
>>>>
>>>>
>>>> --
>>>> Jean-Baptiste Onofré
>>>> jbonofre@apache.org
>>>> http://blog.nanthrax.net
>>>> Talend - http://www.talend.com
>>
>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
Re: Lessons learned from my first attempt to use the pax-exam test container
Posted by Benson Margulies <be...@basistech.com>.
Yes. There's only one user, me, I'm developing. All this email was me
struggling to get one pax-exam test to work. And it seems as if the
recipe was to (a) put the mirror in my ~/.m2/settings.xml, (b) use
plain (*), not external:*. However, there is another aspect. When I
was seeing those mysterious hangs, I was at home. When I got things
working, I was in the office. My home does VPN to my office, but I've
seen some odd error messages from Karaf in the past as if the DNS
situation in my house is somehow problematic. And, as I type, I see it
sitting there accomplishing nothing. I am suspicious of the setting:
org.ops4j.pax.exam.rbc.rmi.host=tinfoilhat.local
I am going to go try forcing 'localhost'.
In my previous iteration, when I moved from dev to deployment, I
reconfigured that file to never talk to the network, and all was well
for other users.
On Sat, Aug 29, 2015 at 7:18 AM, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
> And the .m2/settings.xml of the user who is running Karaf contains the proxy
> setting ?
>
> Regards
> JB
>
>
> On 08/29/2015 01:15 PM, Benson Margulies wrote:
>>
>> Hmm. The file comments say that it looks at:
>>
>> 2. if not found looks for ${user.home}/.m2/settings.xml
>>
>> if not called out, and it _seems_ to be working fine for me.
>>
>> On Sat, Aug 29, 2015 at 1:12 AM, Jean-Baptiste Onofré <jb...@nanthrax.net>
>> wrote:
>>>
>>> The settings.xml update is not enough: as I said, you have to specify the
>>> location of the settings.xml in etc/org.ops4j.pax.url.mvn.cfg as well.
>>>
>>> Regards
>>> JB
>>>
>>>
>>> On 08/28/2015 05:17 PM, Benson Margulies wrote:
>>>>
>>>>
>>>> Hmm. I tried adding it to my ~/.m2/settings.xml and that didn't seem
>>>> to work. I'll try again.
>>>>
>>>>
>>>> On Fri, Aug 28, 2015 at 10:20 AM, Jean-Baptiste Onofré <jb...@nanthrax.net>
>>>> wrote:
>>>>>
>>>>>
>>>>> Hi Benson,
>>>>>
>>>>> for 4 (mirror), you can also update etc/org.ops4j.pax.url.mvn.cfg to
>>>>> define
>>>>> the location of a settings.xml containing the mirror definition.
>>>>>
>>>>> Regards
>>>>> JB
>>>>>
>>>>>
>>>>> On 08/28/2015 02:12 PM, Benson Margulies wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> In penance for my many emails, I am hoping that this message is
>>>>>> googleable for others, or can be adapted to documentation.
>>>>>>
>>>>>> 1: Beware of 'wrap'
>>>>>>
>>>>>> -- or -- undefined protocol 'wrap:'
>>>>>>
>>>>>> The karaf-maven-plugin will cheerfully create wrap urls, but does not
>>>>>> add a feature dependency for the wrap feature. This is fine in
>>>>>> production, where 'wrap' is boot and your feature is not. It's not so
>>>>>> good with pax-exam, where they are all boot features. Adding a
>>>>>>
>>>>>> <feature prerequisite="true" dependency="true">wrap</feature>
>>>>>>
>>>>>> to src/main/feature/feature.xml should fix this, but I chose to embed
>>>>>> my would-be wrapped dependencies instead.
>>>>>>
>>>>>> 2: Don't forget
>>>>>> '<includeProjectArtifact>true</includeProjectArtifact>'
>>>>>>
>>>>>> -- or -- missing package for your probe bundle, or elsewhere.
>>>>>>
>>>>>> My feature consisted one one bundle of mine, plus its dependencies.
>>>>>> So, I added the feature descriptor as a plugin execution instead of
>>>>>> having a separate feature project. Turns out that the default is not
>>>>>> to include the current project's artifact.
>>>>>>
>>>>>> 3: Watch out for slf4j-api
>>>>>>
>>>>>> -- or -- wiring errors with org.slf4j
>>>>>>
>>>>>> You don't want slf4j-api in your feature(s) -- karaf supplies slf4j
>>>>>> via pax-logging. If you accidently include it, the result is a wiring
>>>>>> error.
>>>>>>
>>>>>> 4: Karaf does not do maven mirrors
>>>>>>
>>>>>> If your standard maven settings include a * mirror, Karaf will hang,
>>>>>> due to Aether's desire to match up the metadata, even if you add your
>>>>>> mirror as an additional repo. I cured this with:
>>>>>>
>>>>>> editConfigurationFilePut("etc/org.ops4j.pax.url.mvn.cfg",
>>>>>> "org.ops4j.pax.url.mvn.repositories", "http:/MY-MIRROR-URL"),
>>>>>> editConfigurationFilePut("etc/org.ops4j.pax.url.mvn.cfg",
>>>>>> "org.ops4j.pax.url.mvn.defaultLocalRepoAsRemote", "true"),
>>>>>>
>>>>>
>>>>> --
>>>>> Jean-Baptiste Onofré
>>>>> jbonofre@apache.org
>>>>> http://blog.nanthrax.net
>>>>> Talend - http://www.talend.com
>>>
>>>
>>>
>>> --
>>> Jean-Baptiste Onofré
>>> jbonofre@apache.org
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
Re: Lessons learned from my first attempt to use the pax-exam test
container
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
And the .m2/settings.xml of the user who is running Karaf contains the
proxy setting ?
Regards
JB
On 08/29/2015 01:15 PM, Benson Margulies wrote:
> Hmm. The file comments say that it looks at:
>
> 2. if not found looks for ${user.home}/.m2/settings.xml
>
> if not called out, and it _seems_ to be working fine for me.
>
> On Sat, Aug 29, 2015 at 1:12 AM, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
>> The settings.xml update is not enough: as I said, you have to specify the
>> location of the settings.xml in etc/org.ops4j.pax.url.mvn.cfg as well.
>>
>> Regards
>> JB
>>
>>
>> On 08/28/2015 05:17 PM, Benson Margulies wrote:
>>>
>>> Hmm. I tried adding it to my ~/.m2/settings.xml and that didn't seem
>>> to work. I'll try again.
>>>
>>>
>>> On Fri, Aug 28, 2015 at 10:20 AM, Jean-Baptiste Onofré <jb...@nanthrax.net>
>>> wrote:
>>>>
>>>> Hi Benson,
>>>>
>>>> for 4 (mirror), you can also update etc/org.ops4j.pax.url.mvn.cfg to
>>>> define
>>>> the location of a settings.xml containing the mirror definition.
>>>>
>>>> Regards
>>>> JB
>>>>
>>>>
>>>> On 08/28/2015 02:12 PM, Benson Margulies wrote:
>>>>>
>>>>>
>>>>> In penance for my many emails, I am hoping that this message is
>>>>> googleable for others, or can be adapted to documentation.
>>>>>
>>>>> 1: Beware of 'wrap'
>>>>>
>>>>> -- or -- undefined protocol 'wrap:'
>>>>>
>>>>> The karaf-maven-plugin will cheerfully create wrap urls, but does not
>>>>> add a feature dependency for the wrap feature. This is fine in
>>>>> production, where 'wrap' is boot and your feature is not. It's not so
>>>>> good with pax-exam, where they are all boot features. Adding a
>>>>>
>>>>> <feature prerequisite="true" dependency="true">wrap</feature>
>>>>>
>>>>> to src/main/feature/feature.xml should fix this, but I chose to embed
>>>>> my would-be wrapped dependencies instead.
>>>>>
>>>>> 2: Don't forget '<includeProjectArtifact>true</includeProjectArtifact>'
>>>>>
>>>>> -- or -- missing package for your probe bundle, or elsewhere.
>>>>>
>>>>> My feature consisted one one bundle of mine, plus its dependencies.
>>>>> So, I added the feature descriptor as a plugin execution instead of
>>>>> having a separate feature project. Turns out that the default is not
>>>>> to include the current project's artifact.
>>>>>
>>>>> 3: Watch out for slf4j-api
>>>>>
>>>>> -- or -- wiring errors with org.slf4j
>>>>>
>>>>> You don't want slf4j-api in your feature(s) -- karaf supplies slf4j
>>>>> via pax-logging. If you accidently include it, the result is a wiring
>>>>> error.
>>>>>
>>>>> 4: Karaf does not do maven mirrors
>>>>>
>>>>> If your standard maven settings include a * mirror, Karaf will hang,
>>>>> due to Aether's desire to match up the metadata, even if you add your
>>>>> mirror as an additional repo. I cured this with:
>>>>>
>>>>> editConfigurationFilePut("etc/org.ops4j.pax.url.mvn.cfg",
>>>>> "org.ops4j.pax.url.mvn.repositories", "http:/MY-MIRROR-URL"),
>>>>> editConfigurationFilePut("etc/org.ops4j.pax.url.mvn.cfg",
>>>>> "org.ops4j.pax.url.mvn.defaultLocalRepoAsRemote", "true"),
>>>>>
>>>>
>>>> --
>>>> Jean-Baptiste Onofré
>>>> jbonofre@apache.org
>>>> http://blog.nanthrax.net
>>>> Talend - http://www.talend.com
>>
>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Lessons learned from my first attempt to use the pax-exam test container
Posted by Benson Margulies <be...@basistech.com>.
Hmm. The file comments say that it looks at:
2. if not found looks for ${user.home}/.m2/settings.xml
if not called out, and it _seems_ to be working fine for me.
On Sat, Aug 29, 2015 at 1:12 AM, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
> The settings.xml update is not enough: as I said, you have to specify the
> location of the settings.xml in etc/org.ops4j.pax.url.mvn.cfg as well.
>
> Regards
> JB
>
>
> On 08/28/2015 05:17 PM, Benson Margulies wrote:
>>
>> Hmm. I tried adding it to my ~/.m2/settings.xml and that didn't seem
>> to work. I'll try again.
>>
>>
>> On Fri, Aug 28, 2015 at 10:20 AM, Jean-Baptiste Onofré <jb...@nanthrax.net>
>> wrote:
>>>
>>> Hi Benson,
>>>
>>> for 4 (mirror), you can also update etc/org.ops4j.pax.url.mvn.cfg to
>>> define
>>> the location of a settings.xml containing the mirror definition.
>>>
>>> Regards
>>> JB
>>>
>>>
>>> On 08/28/2015 02:12 PM, Benson Margulies wrote:
>>>>
>>>>
>>>> In penance for my many emails, I am hoping that this message is
>>>> googleable for others, or can be adapted to documentation.
>>>>
>>>> 1: Beware of 'wrap'
>>>>
>>>> -- or -- undefined protocol 'wrap:'
>>>>
>>>> The karaf-maven-plugin will cheerfully create wrap urls, but does not
>>>> add a feature dependency for the wrap feature. This is fine in
>>>> production, where 'wrap' is boot and your feature is not. It's not so
>>>> good with pax-exam, where they are all boot features. Adding a
>>>>
>>>> <feature prerequisite="true" dependency="true">wrap</feature>
>>>>
>>>> to src/main/feature/feature.xml should fix this, but I chose to embed
>>>> my would-be wrapped dependencies instead.
>>>>
>>>> 2: Don't forget '<includeProjectArtifact>true</includeProjectArtifact>'
>>>>
>>>> -- or -- missing package for your probe bundle, or elsewhere.
>>>>
>>>> My feature consisted one one bundle of mine, plus its dependencies.
>>>> So, I added the feature descriptor as a plugin execution instead of
>>>> having a separate feature project. Turns out that the default is not
>>>> to include the current project's artifact.
>>>>
>>>> 3: Watch out for slf4j-api
>>>>
>>>> -- or -- wiring errors with org.slf4j
>>>>
>>>> You don't want slf4j-api in your feature(s) -- karaf supplies slf4j
>>>> via pax-logging. If you accidently include it, the result is a wiring
>>>> error.
>>>>
>>>> 4: Karaf does not do maven mirrors
>>>>
>>>> If your standard maven settings include a * mirror, Karaf will hang,
>>>> due to Aether's desire to match up the metadata, even if you add your
>>>> mirror as an additional repo. I cured this with:
>>>>
>>>> editConfigurationFilePut("etc/org.ops4j.pax.url.mvn.cfg",
>>>> "org.ops4j.pax.url.mvn.repositories", "http:/MY-MIRROR-URL"),
>>>> editConfigurationFilePut("etc/org.ops4j.pax.url.mvn.cfg",
>>>> "org.ops4j.pax.url.mvn.defaultLocalRepoAsRemote", "true"),
>>>>
>>>
>>> --
>>> Jean-Baptiste Onofré
>>> jbonofre@apache.org
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
Re: Lessons learned from my first attempt to use the pax-exam test
container
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
The settings.xml update is not enough: as I said, you have to specify
the location of the settings.xml in etc/org.ops4j.pax.url.mvn.cfg as well.
Regards
JB
On 08/28/2015 05:17 PM, Benson Margulies wrote:
> Hmm. I tried adding it to my ~/.m2/settings.xml and that didn't seem
> to work. I'll try again.
>
>
> On Fri, Aug 28, 2015 at 10:20 AM, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
>> Hi Benson,
>>
>> for 4 (mirror), you can also update etc/org.ops4j.pax.url.mvn.cfg to define
>> the location of a settings.xml containing the mirror definition.
>>
>> Regards
>> JB
>>
>>
>> On 08/28/2015 02:12 PM, Benson Margulies wrote:
>>>
>>> In penance for my many emails, I am hoping that this message is
>>> googleable for others, or can be adapted to documentation.
>>>
>>> 1: Beware of 'wrap'
>>>
>>> -- or -- undefined protocol 'wrap:'
>>>
>>> The karaf-maven-plugin will cheerfully create wrap urls, but does not
>>> add a feature dependency for the wrap feature. This is fine in
>>> production, where 'wrap' is boot and your feature is not. It's not so
>>> good with pax-exam, where they are all boot features. Adding a
>>>
>>> <feature prerequisite="true" dependency="true">wrap</feature>
>>>
>>> to src/main/feature/feature.xml should fix this, but I chose to embed
>>> my would-be wrapped dependencies instead.
>>>
>>> 2: Don't forget '<includeProjectArtifact>true</includeProjectArtifact>'
>>>
>>> -- or -- missing package for your probe bundle, or elsewhere.
>>>
>>> My feature consisted one one bundle of mine, plus its dependencies.
>>> So, I added the feature descriptor as a plugin execution instead of
>>> having a separate feature project. Turns out that the default is not
>>> to include the current project's artifact.
>>>
>>> 3: Watch out for slf4j-api
>>>
>>> -- or -- wiring errors with org.slf4j
>>>
>>> You don't want slf4j-api in your feature(s) -- karaf supplies slf4j
>>> via pax-logging. If you accidently include it, the result is a wiring
>>> error.
>>>
>>> 4: Karaf does not do maven mirrors
>>>
>>> If your standard maven settings include a * mirror, Karaf will hang,
>>> due to Aether's desire to match up the metadata, even if you add your
>>> mirror as an additional repo. I cured this with:
>>>
>>> editConfigurationFilePut("etc/org.ops4j.pax.url.mvn.cfg",
>>> "org.ops4j.pax.url.mvn.repositories", "http:/MY-MIRROR-URL"),
>>> editConfigurationFilePut("etc/org.ops4j.pax.url.mvn.cfg",
>>> "org.ops4j.pax.url.mvn.defaultLocalRepoAsRemote", "true"),
>>>
>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Lessons learned from my first attempt to use the pax-exam test container
Posted by Benson Margulies <be...@basistech.com>.
Perhaps the version of aether involved doesn't do 'external:*' for
mirrorOf? It's working for me now with a plain '*'.
On Fri, Aug 28, 2015 at 11:17 AM, Benson Margulies <be...@basistech.com> wrote:
> Hmm. I tried adding it to my ~/.m2/settings.xml and that didn't seem
> to work. I'll try again.
>
>
> On Fri, Aug 28, 2015 at 10:20 AM, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
>> Hi Benson,
>>
>> for 4 (mirror), you can also update etc/org.ops4j.pax.url.mvn.cfg to define
>> the location of a settings.xml containing the mirror definition.
>>
>> Regards
>> JB
>>
>>
>> On 08/28/2015 02:12 PM, Benson Margulies wrote:
>>>
>>> In penance for my many emails, I am hoping that this message is
>>> googleable for others, or can be adapted to documentation.
>>>
>>> 1: Beware of 'wrap'
>>>
>>> -- or -- undefined protocol 'wrap:'
>>>
>>> The karaf-maven-plugin will cheerfully create wrap urls, but does not
>>> add a feature dependency for the wrap feature. This is fine in
>>> production, where 'wrap' is boot and your feature is not. It's not so
>>> good with pax-exam, where they are all boot features. Adding a
>>>
>>> <feature prerequisite="true" dependency="true">wrap</feature>
>>>
>>> to src/main/feature/feature.xml should fix this, but I chose to embed
>>> my would-be wrapped dependencies instead.
>>>
>>> 2: Don't forget '<includeProjectArtifact>true</includeProjectArtifact>'
>>>
>>> -- or -- missing package for your probe bundle, or elsewhere.
>>>
>>> My feature consisted one one bundle of mine, plus its dependencies.
>>> So, I added the feature descriptor as a plugin execution instead of
>>> having a separate feature project. Turns out that the default is not
>>> to include the current project's artifact.
>>>
>>> 3: Watch out for slf4j-api
>>>
>>> -- or -- wiring errors with org.slf4j
>>>
>>> You don't want slf4j-api in your feature(s) -- karaf supplies slf4j
>>> via pax-logging. If you accidently include it, the result is a wiring
>>> error.
>>>
>>> 4: Karaf does not do maven mirrors
>>>
>>> If your standard maven settings include a * mirror, Karaf will hang,
>>> due to Aether's desire to match up the metadata, even if you add your
>>> mirror as an additional repo. I cured this with:
>>>
>>> editConfigurationFilePut("etc/org.ops4j.pax.url.mvn.cfg",
>>> "org.ops4j.pax.url.mvn.repositories", "http:/MY-MIRROR-URL"),
>>> editConfigurationFilePut("etc/org.ops4j.pax.url.mvn.cfg",
>>> "org.ops4j.pax.url.mvn.defaultLocalRepoAsRemote", "true"),
>>>
>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
Re: Lessons learned from my first attempt to use the pax-exam test container
Posted by Benson Margulies <be...@basistech.com>.
Hmm. I tried adding it to my ~/.m2/settings.xml and that didn't seem
to work. I'll try again.
On Fri, Aug 28, 2015 at 10:20 AM, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
> Hi Benson,
>
> for 4 (mirror), you can also update etc/org.ops4j.pax.url.mvn.cfg to define
> the location of a settings.xml containing the mirror definition.
>
> Regards
> JB
>
>
> On 08/28/2015 02:12 PM, Benson Margulies wrote:
>>
>> In penance for my many emails, I am hoping that this message is
>> googleable for others, or can be adapted to documentation.
>>
>> 1: Beware of 'wrap'
>>
>> -- or -- undefined protocol 'wrap:'
>>
>> The karaf-maven-plugin will cheerfully create wrap urls, but does not
>> add a feature dependency for the wrap feature. This is fine in
>> production, where 'wrap' is boot and your feature is not. It's not so
>> good with pax-exam, where they are all boot features. Adding a
>>
>> <feature prerequisite="true" dependency="true">wrap</feature>
>>
>> to src/main/feature/feature.xml should fix this, but I chose to embed
>> my would-be wrapped dependencies instead.
>>
>> 2: Don't forget '<includeProjectArtifact>true</includeProjectArtifact>'
>>
>> -- or -- missing package for your probe bundle, or elsewhere.
>>
>> My feature consisted one one bundle of mine, plus its dependencies.
>> So, I added the feature descriptor as a plugin execution instead of
>> having a separate feature project. Turns out that the default is not
>> to include the current project's artifact.
>>
>> 3: Watch out for slf4j-api
>>
>> -- or -- wiring errors with org.slf4j
>>
>> You don't want slf4j-api in your feature(s) -- karaf supplies slf4j
>> via pax-logging. If you accidently include it, the result is a wiring
>> error.
>>
>> 4: Karaf does not do maven mirrors
>>
>> If your standard maven settings include a * mirror, Karaf will hang,
>> due to Aether's desire to match up the metadata, even if you add your
>> mirror as an additional repo. I cured this with:
>>
>> editConfigurationFilePut("etc/org.ops4j.pax.url.mvn.cfg",
>> "org.ops4j.pax.url.mvn.repositories", "http:/MY-MIRROR-URL"),
>> editConfigurationFilePut("etc/org.ops4j.pax.url.mvn.cfg",
>> "org.ops4j.pax.url.mvn.defaultLocalRepoAsRemote", "true"),
>>
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
Re: Lessons learned from my first attempt to use the pax-exam test
container
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Benson,
for 4 (mirror), you can also update etc/org.ops4j.pax.url.mvn.cfg to
define the location of a settings.xml containing the mirror definition.
Regards
JB
On 08/28/2015 02:12 PM, Benson Margulies wrote:
> In penance for my many emails, I am hoping that this message is
> googleable for others, or can be adapted to documentation.
>
> 1: Beware of 'wrap'
>
> -- or -- undefined protocol 'wrap:'
>
> The karaf-maven-plugin will cheerfully create wrap urls, but does not
> add a feature dependency for the wrap feature. This is fine in
> production, where 'wrap' is boot and your feature is not. It's not so
> good with pax-exam, where they are all boot features. Adding a
>
> <feature prerequisite="true" dependency="true">wrap</feature>
>
> to src/main/feature/feature.xml should fix this, but I chose to embed
> my would-be wrapped dependencies instead.
>
> 2: Don't forget '<includeProjectArtifact>true</includeProjectArtifact>'
>
> -- or -- missing package for your probe bundle, or elsewhere.
>
> My feature consisted one one bundle of mine, plus its dependencies.
> So, I added the feature descriptor as a plugin execution instead of
> having a separate feature project. Turns out that the default is not
> to include the current project's artifact.
>
> 3: Watch out for slf4j-api
>
> -- or -- wiring errors with org.slf4j
>
> You don't want slf4j-api in your feature(s) -- karaf supplies slf4j
> via pax-logging. If you accidently include it, the result is a wiring
> error.
>
> 4: Karaf does not do maven mirrors
>
> If your standard maven settings include a * mirror, Karaf will hang,
> due to Aether's desire to match up the metadata, even if you add your
> mirror as an additional repo. I cured this with:
>
> editConfigurationFilePut("etc/org.ops4j.pax.url.mvn.cfg",
> "org.ops4j.pax.url.mvn.repositories", "http:/MY-MIRROR-URL"),
> editConfigurationFilePut("etc/org.ops4j.pax.url.mvn.cfg",
> "org.ops4j.pax.url.mvn.defaultLocalRepoAsRemote", "true"),
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com