You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "Moloney, Tim M" <Ti...@ManTech.com> on 2009/09/01 16:04:19 UTC
Karaf Feature problem after FileInstall replaced FileMonitor
After upgrading my copy of Felix to the latest trunk (r809641), my
custom packaging of Karaf no longer works.
I've created a custom assembly based on the assembly in Karaf. I've
added our application bundles and customized some configuration files,
including using a custom feature repository and setting featuresBoot to
start our application. All was working great until FileMonitor was
replaced with FileInstall (although, this problem may not even be
related). When Karaf starts, I get the following exception.
[pool-2-thread-2] ERROR
org.apache.geronimo.blueprint.container.BlueprintContainerImpl - Unable
to start blueprint container for bundle
org.apache.felix.karaf.features.core
org.osgi.service.blueprint.container.ComponentDefinitionException:
Unable to intialize bean featuresService
at
org.apache.geronimo.blueprint.container.BeanRecipe.internalCreate(BeanRe
cipe.java:519)
at
org.apache.geronimo.blueprint.di.AbstractRecipe.create(AbstractRecipe.ja
va:64)
at
org.apache.geronimo.blueprint.container.BlueprintRepository.createInstan
ces(BlueprintRepository.java:212)
at
org.apache.geronimo.blueprint.container.BlueprintRepository.createAll(Bl
ueprintRepository.java:140)
at
org.apache.geronimo.blueprint.container.BlueprintContainerImpl.instantia
teEagerComponents(BlueprintContainerImpl.java:603)
at
org.apache.geronimo.blueprint.container.BlueprintContainerImpl.doRun(Blu
eprintContainerImpl.java:310)
at
org.apache.geronimo.blueprint.container.BlueprintContainerImpl.run(Bluep
rintContainerImpl.java:211)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at
java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.acc
ess$301(ScheduledThreadPoolExecutor.java:98)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run
(ScheduledThreadPoolExecutor.java:207)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecuto
r.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.ja
va:908)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.RuntimeException: URL
[mvn:com.mrsl.vp/scimitar/3.0.0-SNAPSHOT/xml/features] could not be
resolved.
at
org.ops4j.pax.url.mvn.internal.Connection.getInputStream(Connection.java
:195)
at
org.apache.felix.karaf.features.internal.RepositoryImpl.load(RepositoryI
mpl.java:89)
at
org.apache.felix.karaf.features.internal.FeaturesServiceImpl.internalAdd
Repository(FeaturesServiceImpl.java:143)
at
org.apache.felix.karaf.features.internal.FeaturesServiceImpl.start(Featu
resServiceImpl.java:393)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
a:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
Impl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.apache.geronimo.blueprint.utils.ReflectionUtils.invoke(ReflectionUti
ls.java:206)
at
org.apache.geronimo.blueprint.container.BeanRecipe.invoke(BeanRecipe.jav
a:639)
at
org.apache.geronimo.blueprint.container.BeanRecipe.internalCreate(BeanRe
cipe.java:517)
... 14 more
Karaf will successfully start with my customizations, if I ensure that
all the bundles listed in the features repository are in my local
repository (~/.m2/repository), even though they are in the Karaf
repository (the system directory of the assembly). Alternatively, if I
change featuresRepository and featuresBoot back to the default, Karaf
will start properly and I can then execute features:addUrl to the custom
repository, then features:install our application.
It appears that any bundle loaded by the Feature mechanism at boot time
needs to be in my local repository even if it is in the Karaf
repository. Karaf should be able to find these bundles in the system
directory like it used to. This is probably just a configuration issue,
but I can't figure out how to get it to work the way it did before
FileInstall replaced FileMonitor.
Tim Moloney The reasonable man adapts himself to
MRSL the world; the unreasonable one persists
2015 Cattlemen Road in trying to adapt the world to himself.
Sarasota, FL 34232 Therefore all progress depends on the
(941) 377-6775 x208 unreasonable man. George Bernard Shaw
RE: Karaf Feature problem after FileInstall replaced FileMonitor
Posted by "Moloney, Tim M" <Ti...@ManTech.com>.
I've attached the log messages from just the starting of Karaf.
To generate this, I:
- built the trunk of Karaf assembly (r812920)
- removed my local repository
- set "featuresBoot=webconsole" in
apache-felix-karaf-0.9.0-SNAPSHOT/etc/org.apache.felix.karaf.features.cf
g
- set "log4j.rootLogger=TRACE, ..." in
apache-felix-karaf-0.9.0-SNAPSHOT/etc/org.ops4j.pax.logging.cfg
- ran apache-felix-karaf-0.9.0-SNAPSHOT/bin/karaf
- copied apache-felix-karaf-0.9.0-SNAPSHOT/data/log/karaf.log to
karaf.log.TRACE
- entered <ctrl-d> at karaf@root> prompt to shutdown Karaf
Here is the exception that get generated:
[pool-2-thread-1] ERROR
org.apache.geronimo.blueprint.container.BlueprintContainerImpl - Unable
to start blueprint container for bundle
org.apache.felix.karaf.features.core
org.osgi.service.blueprint.container.ComponentDefinitionException:
Unable to intialize bean featuresService
at
org.apache.geronimo.blueprint.container.BeanRecipe.internalCreate(BeanRe
cipe.java:519)
at
org.apache.geronimo.blueprint.di.AbstractRecipe.create(AbstractRecipe.ja
va:64)
at
org.apache.geronimo.blueprint.container.BlueprintRepository.createInstan
ces(BlueprintRepository.java:212)
at
org.apache.geronimo.blueprint.container.BlueprintRepository.createAll(Bl
ueprintRepository.java:140)
at
org.apache.geronimo.blueprint.container.BlueprintContainerImpl.instantia
teEagerComponents(BlueprintContainerImpl.java:603)
at
org.apache.geronimo.blueprint.container.BlueprintContainerImpl.doRun(Blu
eprintContainerImpl.java:310)
at
org.apache.geronimo.blueprint.container.BlueprintContainerImpl.run(Bluep
rintContainerImpl.java:211)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at
java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.acc
ess$301(ScheduledThreadPoolExecutor.java:98)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run
(ScheduledThreadPoolExecutor.java:207)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecuto
r.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.ja
va:908)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.RuntimeException: URL
[mvn:org.apache.felix.karaf/apache-felix-karaf/0.9.0-SNAPSHOT/xml/featur
es] could not be resolved.
at
org.ops4j.pax.url.mvn.internal.Connection.getInputStream(Connection.java
:195)
at
org.apache.felix.karaf.features.internal.RepositoryImpl.load(RepositoryI
mpl.java:89)
at
org.apache.felix.karaf.features.internal.FeaturesServiceImpl.internalAdd
Repository(FeaturesServiceImpl.java:143)
at
org.apache.felix.karaf.features.internal.FeaturesServiceImpl.start(Featu
resServiceImpl.java:396)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
a:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
Impl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.apache.geronimo.blueprint.utils.ReflectionUtils.invoke(ReflectionUti
ls.java:206)
at
org.apache.geronimo.blueprint.container.BeanRecipe.invoke(BeanRecipe.jav
a:639)
at
org.apache.geronimo.blueprint.container.BeanRecipe.internalCreate(BeanRe
cipe.java:517)
... 14 more
Tim Moloney The reasonable man adapts himself to
MRSL the world; the unreasonable one persists
2015 Cattlemen Road in trying to adapt the world to himself.
Sarasota, FL 34232 Therefore all progress depends on the
(941) 377-6775 x208 unreasonable man. George Bernard Shaw
RE: Karaf Feature problem after FileInstall replaced FileMonitor
Posted by "Moloney, Tim M" <Ti...@ManTech.com>.
I added the following two lines to etc/org.ops4j.pax.logging.cfg.
log4j.logger.org.ops4j.pax=TRACE
log4j.logger.org.apache.felix.karaf=TRACE
However, I only got the following two line during startup.
16:01:03,701 | DEBUG | pool-2-thread-2 | ssh
| ? ? | ServiceEvent REGISTERED
16:01:03,703 | DEBUG | pool-1-thread-1 | BlueprintListener
| af.gshell.osgi.BlueprintListener 67 | Blueprint app state changed to
Created for bundle 10
Tim Moloney The reasonable man adapts himself to
MRSL the world; the unreasonable one persists
2015 Cattlemen Road in trying to adapt the world to himself.
Sarasota, FL 34232 Therefore all progress depends on the
(941) 377-6775 x208 unreasonable man. George Bernard Shaw
> -----Original Message-----
> From: Guillaume Nodet [mailto:gnodet@gmail.com]
> Sent: Tuesday, September 01, 2009 11:47
> To: dev@felix.apache.org
> Subject: Re: Karaf Feature problem after FileInstall replaced
> FileMonitor
>
> Right, good point.
> Could you enable TRACE level logging in Karaf, as IIRC, the maven url
> handler has lots of debugging statements at this level to
> show what it does
> and why the resolution fails.
>
> On Tue, Sep 1, 2009 at 17:42, Moloney, Tim M
> <Ti...@mantech.com>wrote:
>
> >
> > Since the stack trace below includes
> >
> >
> >
> org.ops4j.pax.url.mvn.internal.Connection.getInputStream(Conne
> ction.java
> > :195)
> >
> > isn't the Maven URL handler already registered?
> >
> >
> > Tim Moloney The reasonable man adapts himself to
> > MRSL the world; the unreasonable one persists
> > 2015 Cattlemen Road in trying to adapt the world to himself.
> > Sarasota, FL 34232 Therefore all progress depends on the
> > (941) 377-6775 x208 unreasonable man. George Bernard Shaw
> >
> >
> >
> > > -----Original Message-----
> > > From: Guillaume Nodet [mailto:gnodet@gmail.com]
> > > Sent: Tuesday, September 01, 2009 10:10
> > > To: dev@felix.apache.org
> > > Subject: Re: Karaf Feature problem after FileInstall replaced
> > > FileMonitor
> > >
> > > I think the problem is that the features service try to
> > > install bundles that
> > > use the maven url handler.
> > > This will only work if the maven url handler has been
> > > previously registered.
> > > Switching from the deployer to felix fileinstall might have
> > > changed the
> > > timing of those operations and let this bug surface.
> > > I suppose a way to overcome that would be to add a dependency
> > > on the maven
> > > url handler to the features service, so that we're sure
> that when the
> > > features are installed, the maven url handler is available.
> > >
> > > On Tue, Sep 1, 2009 at 16:04, Moloney, Tim M
> > > <Ti...@mantech.com>wrote:
> > >
> > > >
> > > > After upgrading my copy of Felix to the latest trunk
> (r809641), my
> > > > custom packaging of Karaf no longer works.
> > > >
> > > > I've created a custom assembly based on the assembly in
> Karaf. I've
> > > > added our application bundles and customized some
> > > configuration files,
> > > > including using a custom feature repository and setting
> > > featuresBoot to
> > > > start our application. All was working great until
> FileMonitor was
> > > > replaced with FileInstall (although, this problem may
> not even be
> > > > related). When Karaf starts, I get the following exception.
> > > >
> > > > [pool-2-thread-2] ERROR
> > > >
> > > org.apache.geronimo.blueprint.container.BlueprintContainerImpl
> > > - Unable
> > > > to start blueprint container for bundle
> > > > org.apache.felix.karaf.features.core
> > > >
> org.osgi.service.blueprint.container.ComponentDefinitionException:
> > > > Unable to intialize bean featuresService
> > > > at
> > > >
> > > org.apache.geronimo.blueprint.container.BeanRecipe.internalCre
> > > ate(BeanRe
> > > > cipe.java:519)
> > > > at
> > > >
> > > org.apache.geronimo.blueprint.di.AbstractRecipe.create(Abstrac
> > > tRecipe.ja
> > > > va:64)
> > > > at
> > > >
> > > org.apache.geronimo.blueprint.container.BlueprintRepository.cr
> > > eateInstan
> > > > ces(BlueprintRepository.java:212)
> > > > at
> > > >
> > > org.apache.geronimo.blueprint.container.BlueprintRepository.cr
> > > eateAll(Bl
> > > > ueprintRepository.java:140)
> > > > at
> > > >
> > > org.apache.geronimo.blueprint.container.BlueprintContainerImpl
> > > .instantia
> > > > teEagerComponents(BlueprintContainerImpl.java:603)
> > > > at
> > > >
> > > org.apache.geronimo.blueprint.container.BlueprintContainerImpl
> > > .doRun(Blu
> > > > eprintContainerImpl.java:310)
> > > > at
> > > >
> > > org.apache.geronimo.blueprint.container.BlueprintContainerImpl
> > > .run(Bluep
> > > > rintContainerImpl.java:211)
> > > > at
> > > >
> > > java.util.concurrent.Executors$RunnableAdapter.call(Executors.
> > > java:441)
> > > > at
> > > >
> java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> > > > at
> java.util.concurrent.FutureTask.run(FutureTask.java:138)
> > > > at
> > > >
> > > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutu
> > > reTask.acc
> > > > ess$301(ScheduledThreadPoolExecutor.java:98)
> > > > at
> > > >
> > > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutu
> > > reTask.run
> > > > (ScheduledThreadPoolExecutor.java:207)
> > > > at
> > > >
> > > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadP
> > > oolExecuto
> > > > r.java:886)
> > > > at
> > > >
> > > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolE
> > > xecutor.ja
> > > > va:908)
> > > > at java.lang.Thread.run(Thread.java:619)
> > > > Caused by: java.lang.RuntimeException: URL
> > > > [mvn:com.mrsl.vp/scimitar/3.0.0-SNAPSHOT/xml/features]
> could not be
> > > > resolved.
> > > > at
> > > >
> > > org.ops4j.pax.url.mvn.internal.Connection.getInputStream(Conne
> > > ction.java
> > > > :195)
> > > > at
> > > >
> > > org.apache.felix.karaf.features.internal.RepositoryImpl.load(R
> > > epositoryI
> > > > mpl.java:89)
> > > > at
> > > >
> > > org.apache.felix.karaf.features.internal.FeaturesServiceImpl.i
> > > nternalAdd
> > > > Repository(FeaturesServiceImpl.java:143)
> > > > at
> > > >
> > > org.apache.felix.karaf.features.internal.FeaturesServiceImpl.s
> > > tart(Featu
> > > > resServiceImpl.java:393)
> > > > at
> > > sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > > > at
> > > >
> > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccess
> > > orImpl.jav
> > > > a:39)
> > > > at
> > > >
> > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMeth
> > > odAccessor
> > > > Impl.java:25)
> > > > at java.lang.reflect.Method.invoke(Method.java:597)
> > > > at
> > > >
> > > org.apache.geronimo.blueprint.utils.ReflectionUtils.invoke(Ref
> > > lectionUti
> > > > ls.java:206)
> > > > at
> > > >
> > > org.apache.geronimo.blueprint.container.BeanRecipe.invoke(Bean
> > > Recipe.jav
> > > > a:639)
> > > > at
> > > >
> > > org.apache.geronimo.blueprint.container.BeanRecipe.internalCre
> > > ate(BeanRe
> > > > cipe.java:517)
> > > > ... 14 more
> > > >
> > > > Karaf will successfully start with my customizations, if I
> > > ensure that
> > > > all the bundles listed in the features repository are
> in my local
> > > > repository (~/.m2/repository), even though they are in the Karaf
> > > > repository (the system directory of the assembly).
> > > Alternatively, if I
> > > > change featuresRepository and featuresBoot back to the
> > > default, Karaf
> > > > will start properly and I can then execute features:addUrl
> > > to the custom
> > > > repository, then features:install our application.
> > > >
> > > > It appears that any bundle loaded by the Feature mechanism
> > > at boot time
> > > > needs to be in my local repository even if it is in the Karaf
> > > > repository. Karaf should be able to find these bundles in
> > > the system
> > > > directory like it used to. This is probably just a
> > > configuration issue,
> > > > but I can't figure out how to get it to work the way it
> did before
> > > > FileInstall replaced FileMonitor.
> > > >
> > > >
> > > > Tim Moloney The reasonable man adapts himself to
> > > > MRSL the world; the unreasonable one persists
> > > > 2015 Cattlemen Road in trying to adapt the world to himself.
> > > > Sarasota, FL 34232 Therefore all progress depends on the
> > > > (941) 377-6775 x208 unreasonable man. George Bernard Shaw
> > > >
> > > >
> > > >
> > >
> > >
> > > --
> > > Cheers,
> > > Guillaume Nodet
> > > ------------------------
> > > Blog: http://gnodet.blogspot.com/
> > > ------------------------
> > > Open Source SOA
> > > http://fusesource.com
> > >
> >
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
Re: Karaf Feature problem after FileInstall replaced FileMonitor
Posted by Guillaume Nodet <gn...@gmail.com>.
Right, good point.
Could you enable TRACE level logging in Karaf, as IIRC, the maven url
handler has lots of debugging statements at this level to show what it does
and why the resolution fails.
On Tue, Sep 1, 2009 at 17:42, Moloney, Tim M <Ti...@mantech.com>wrote:
>
> Since the stack trace below includes
>
>
> org.ops4j.pax.url.mvn.internal.Connection.getInputStream(Connection.java
> :195)
>
> isn't the Maven URL handler already registered?
>
>
> Tim Moloney The reasonable man adapts himself to
> MRSL the world; the unreasonable one persists
> 2015 Cattlemen Road in trying to adapt the world to himself.
> Sarasota, FL 34232 Therefore all progress depends on the
> (941) 377-6775 x208 unreasonable man. George Bernard Shaw
>
>
>
> > -----Original Message-----
> > From: Guillaume Nodet [mailto:gnodet@gmail.com]
> > Sent: Tuesday, September 01, 2009 10:10
> > To: dev@felix.apache.org
> > Subject: Re: Karaf Feature problem after FileInstall replaced
> > FileMonitor
> >
> > I think the problem is that the features service try to
> > install bundles that
> > use the maven url handler.
> > This will only work if the maven url handler has been
> > previously registered.
> > Switching from the deployer to felix fileinstall might have
> > changed the
> > timing of those operations and let this bug surface.
> > I suppose a way to overcome that would be to add a dependency
> > on the maven
> > url handler to the features service, so that we're sure that when the
> > features are installed, the maven url handler is available.
> >
> > On Tue, Sep 1, 2009 at 16:04, Moloney, Tim M
> > <Ti...@mantech.com>wrote:
> >
> > >
> > > After upgrading my copy of Felix to the latest trunk (r809641), my
> > > custom packaging of Karaf no longer works.
> > >
> > > I've created a custom assembly based on the assembly in Karaf. I've
> > > added our application bundles and customized some
> > configuration files,
> > > including using a custom feature repository and setting
> > featuresBoot to
> > > start our application. All was working great until FileMonitor was
> > > replaced with FileInstall (although, this problem may not even be
> > > related). When Karaf starts, I get the following exception.
> > >
> > > [pool-2-thread-2] ERROR
> > >
> > org.apache.geronimo.blueprint.container.BlueprintContainerImpl
> > - Unable
> > > to start blueprint container for bundle
> > > org.apache.felix.karaf.features.core
> > > org.osgi.service.blueprint.container.ComponentDefinitionException:
> > > Unable to intialize bean featuresService
> > > at
> > >
> > org.apache.geronimo.blueprint.container.BeanRecipe.internalCre
> > ate(BeanRe
> > > cipe.java:519)
> > > at
> > >
> > org.apache.geronimo.blueprint.di.AbstractRecipe.create(Abstrac
> > tRecipe.ja
> > > va:64)
> > > at
> > >
> > org.apache.geronimo.blueprint.container.BlueprintRepository.cr
> > eateInstan
> > > ces(BlueprintRepository.java:212)
> > > at
> > >
> > org.apache.geronimo.blueprint.container.BlueprintRepository.cr
> > eateAll(Bl
> > > ueprintRepository.java:140)
> > > at
> > >
> > org.apache.geronimo.blueprint.container.BlueprintContainerImpl
> > .instantia
> > > teEagerComponents(BlueprintContainerImpl.java:603)
> > > at
> > >
> > org.apache.geronimo.blueprint.container.BlueprintContainerImpl
> > .doRun(Blu
> > > eprintContainerImpl.java:310)
> > > at
> > >
> > org.apache.geronimo.blueprint.container.BlueprintContainerImpl
> > .run(Bluep
> > > rintContainerImpl.java:211)
> > > at
> > >
> > java.util.concurrent.Executors$RunnableAdapter.call(Executors.
> > java:441)
> > > at
> > > java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> > > at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> > > at
> > >
> > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutu
> > reTask.acc
> > > ess$301(ScheduledThreadPoolExecutor.java:98)
> > > at
> > >
> > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutu
> > reTask.run
> > > (ScheduledThreadPoolExecutor.java:207)
> > > at
> > >
> > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadP
> > oolExecuto
> > > r.java:886)
> > > at
> > >
> > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolE
> > xecutor.ja
> > > va:908)
> > > at java.lang.Thread.run(Thread.java:619)
> > > Caused by: java.lang.RuntimeException: URL
> > > [mvn:com.mrsl.vp/scimitar/3.0.0-SNAPSHOT/xml/features] could not be
> > > resolved.
> > > at
> > >
> > org.ops4j.pax.url.mvn.internal.Connection.getInputStream(Conne
> > ction.java
> > > :195)
> > > at
> > >
> > org.apache.felix.karaf.features.internal.RepositoryImpl.load(R
> > epositoryI
> > > mpl.java:89)
> > > at
> > >
> > org.apache.felix.karaf.features.internal.FeaturesServiceImpl.i
> > nternalAdd
> > > Repository(FeaturesServiceImpl.java:143)
> > > at
> > >
> > org.apache.felix.karaf.features.internal.FeaturesServiceImpl.s
> > tart(Featu
> > > resServiceImpl.java:393)
> > > at
> > sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > > at
> > >
> > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccess
> > orImpl.jav
> > > a:39)
> > > at
> > >
> > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMeth
> > odAccessor
> > > Impl.java:25)
> > > at java.lang.reflect.Method.invoke(Method.java:597)
> > > at
> > >
> > org.apache.geronimo.blueprint.utils.ReflectionUtils.invoke(Ref
> > lectionUti
> > > ls.java:206)
> > > at
> > >
> > org.apache.geronimo.blueprint.container.BeanRecipe.invoke(Bean
> > Recipe.jav
> > > a:639)
> > > at
> > >
> > org.apache.geronimo.blueprint.container.BeanRecipe.internalCre
> > ate(BeanRe
> > > cipe.java:517)
> > > ... 14 more
> > >
> > > Karaf will successfully start with my customizations, if I
> > ensure that
> > > all the bundles listed in the features repository are in my local
> > > repository (~/.m2/repository), even though they are in the Karaf
> > > repository (the system directory of the assembly).
> > Alternatively, if I
> > > change featuresRepository and featuresBoot back to the
> > default, Karaf
> > > will start properly and I can then execute features:addUrl
> > to the custom
> > > repository, then features:install our application.
> > >
> > > It appears that any bundle loaded by the Feature mechanism
> > at boot time
> > > needs to be in my local repository even if it is in the Karaf
> > > repository. Karaf should be able to find these bundles in
> > the system
> > > directory like it used to. This is probably just a
> > configuration issue,
> > > but I can't figure out how to get it to work the way it did before
> > > FileInstall replaced FileMonitor.
> > >
> > >
> > > Tim Moloney The reasonable man adapts himself to
> > > MRSL the world; the unreasonable one persists
> > > 2015 Cattlemen Road in trying to adapt the world to himself.
> > > Sarasota, FL 34232 Therefore all progress depends on the
> > > (941) 377-6775 x208 unreasonable man. George Bernard Shaw
> > >
> > >
> > >
> >
> >
> > --
> > Cheers,
> > Guillaume Nodet
> > ------------------------
> > Blog: http://gnodet.blogspot.com/
> > ------------------------
> > Open Source SOA
> > http://fusesource.com
> >
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
RE: Karaf Feature problem after FileInstall replaced FileMonitor
Posted by "Moloney, Tim M" <Ti...@ManTech.com>.
Since the stack trace below includes
org.ops4j.pax.url.mvn.internal.Connection.getInputStream(Connection.java
:195)
isn't the Maven URL handler already registered?
Tim Moloney The reasonable man adapts himself to
MRSL the world; the unreasonable one persists
2015 Cattlemen Road in trying to adapt the world to himself.
Sarasota, FL 34232 Therefore all progress depends on the
(941) 377-6775 x208 unreasonable man. George Bernard Shaw
> -----Original Message-----
> From: Guillaume Nodet [mailto:gnodet@gmail.com]
> Sent: Tuesday, September 01, 2009 10:10
> To: dev@felix.apache.org
> Subject: Re: Karaf Feature problem after FileInstall replaced
> FileMonitor
>
> I think the problem is that the features service try to
> install bundles that
> use the maven url handler.
> This will only work if the maven url handler has been
> previously registered.
> Switching from the deployer to felix fileinstall might have
> changed the
> timing of those operations and let this bug surface.
> I suppose a way to overcome that would be to add a dependency
> on the maven
> url handler to the features service, so that we're sure that when the
> features are installed, the maven url handler is available.
>
> On Tue, Sep 1, 2009 at 16:04, Moloney, Tim M
> <Ti...@mantech.com>wrote:
>
> >
> > After upgrading my copy of Felix to the latest trunk (r809641), my
> > custom packaging of Karaf no longer works.
> >
> > I've created a custom assembly based on the assembly in Karaf. I've
> > added our application bundles and customized some
> configuration files,
> > including using a custom feature repository and setting
> featuresBoot to
> > start our application. All was working great until FileMonitor was
> > replaced with FileInstall (although, this problem may not even be
> > related). When Karaf starts, I get the following exception.
> >
> > [pool-2-thread-2] ERROR
> >
> org.apache.geronimo.blueprint.container.BlueprintContainerImpl
> - Unable
> > to start blueprint container for bundle
> > org.apache.felix.karaf.features.core
> > org.osgi.service.blueprint.container.ComponentDefinitionException:
> > Unable to intialize bean featuresService
> > at
> >
> org.apache.geronimo.blueprint.container.BeanRecipe.internalCre
> ate(BeanRe
> > cipe.java:519)
> > at
> >
> org.apache.geronimo.blueprint.di.AbstractRecipe.create(Abstrac
> tRecipe.ja
> > va:64)
> > at
> >
> org.apache.geronimo.blueprint.container.BlueprintRepository.cr
> eateInstan
> > ces(BlueprintRepository.java:212)
> > at
> >
> org.apache.geronimo.blueprint.container.BlueprintRepository.cr
> eateAll(Bl
> > ueprintRepository.java:140)
> > at
> >
> org.apache.geronimo.blueprint.container.BlueprintContainerImpl
> .instantia
> > teEagerComponents(BlueprintContainerImpl.java:603)
> > at
> >
> org.apache.geronimo.blueprint.container.BlueprintContainerImpl
> .doRun(Blu
> > eprintContainerImpl.java:310)
> > at
> >
> org.apache.geronimo.blueprint.container.BlueprintContainerImpl
> .run(Bluep
> > rintContainerImpl.java:211)
> > at
> >
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.
> java:441)
> > at
> > java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> > at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> > at
> >
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutu
> reTask.acc
> > ess$301(ScheduledThreadPoolExecutor.java:98)
> > at
> >
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutu
> reTask.run
> > (ScheduledThreadPoolExecutor.java:207)
> > at
> >
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadP
> oolExecuto
> > r.java:886)
> > at
> >
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolE
> xecutor.ja
> > va:908)
> > at java.lang.Thread.run(Thread.java:619)
> > Caused by: java.lang.RuntimeException: URL
> > [mvn:com.mrsl.vp/scimitar/3.0.0-SNAPSHOT/xml/features] could not be
> > resolved.
> > at
> >
> org.ops4j.pax.url.mvn.internal.Connection.getInputStream(Conne
> ction.java
> > :195)
> > at
> >
> org.apache.felix.karaf.features.internal.RepositoryImpl.load(R
> epositoryI
> > mpl.java:89)
> > at
> >
> org.apache.felix.karaf.features.internal.FeaturesServiceImpl.i
> nternalAdd
> > Repository(FeaturesServiceImpl.java:143)
> > at
> >
> org.apache.felix.karaf.features.internal.FeaturesServiceImpl.s
> tart(Featu
> > resServiceImpl.java:393)
> > at
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > at
> >
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccess
> orImpl.jav
> > a:39)
> > at
> >
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMeth
> odAccessor
> > Impl.java:25)
> > at java.lang.reflect.Method.invoke(Method.java:597)
> > at
> >
> org.apache.geronimo.blueprint.utils.ReflectionUtils.invoke(Ref
> lectionUti
> > ls.java:206)
> > at
> >
> org.apache.geronimo.blueprint.container.BeanRecipe.invoke(Bean
> Recipe.jav
> > a:639)
> > at
> >
> org.apache.geronimo.blueprint.container.BeanRecipe.internalCre
> ate(BeanRe
> > cipe.java:517)
> > ... 14 more
> >
> > Karaf will successfully start with my customizations, if I
> ensure that
> > all the bundles listed in the features repository are in my local
> > repository (~/.m2/repository), even though they are in the Karaf
> > repository (the system directory of the assembly).
> Alternatively, if I
> > change featuresRepository and featuresBoot back to the
> default, Karaf
> > will start properly and I can then execute features:addUrl
> to the custom
> > repository, then features:install our application.
> >
> > It appears that any bundle loaded by the Feature mechanism
> at boot time
> > needs to be in my local repository even if it is in the Karaf
> > repository. Karaf should be able to find these bundles in
> the system
> > directory like it used to. This is probably just a
> configuration issue,
> > but I can't figure out how to get it to work the way it did before
> > FileInstall replaced FileMonitor.
> >
> >
> > Tim Moloney The reasonable man adapts himself to
> > MRSL the world; the unreasonable one persists
> > 2015 Cattlemen Road in trying to adapt the world to himself.
> > Sarasota, FL 34232 Therefore all progress depends on the
> > (941) 377-6775 x208 unreasonable man. George Bernard Shaw
> >
> >
> >
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
Re: Karaf Feature problem after FileInstall replaced FileMonitor
Posted by Guillaume Nodet <gn...@gmail.com>.
I think the problem is that the features service try to install bundles that
use the maven url handler.
This will only work if the maven url handler has been previously registered.
Switching from the deployer to felix fileinstall might have changed the
timing of those operations and let this bug surface.
I suppose a way to overcome that would be to add a dependency on the maven
url handler to the features service, so that we're sure that when the
features are installed, the maven url handler is available.
On Tue, Sep 1, 2009 at 16:04, Moloney, Tim M <Ti...@mantech.com>wrote:
>
> After upgrading my copy of Felix to the latest trunk (r809641), my
> custom packaging of Karaf no longer works.
>
> I've created a custom assembly based on the assembly in Karaf. I've
> added our application bundles and customized some configuration files,
> including using a custom feature repository and setting featuresBoot to
> start our application. All was working great until FileMonitor was
> replaced with FileInstall (although, this problem may not even be
> related). When Karaf starts, I get the following exception.
>
> [pool-2-thread-2] ERROR
> org.apache.geronimo.blueprint.container.BlueprintContainerImpl - Unable
> to start blueprint container for bundle
> org.apache.felix.karaf.features.core
> org.osgi.service.blueprint.container.ComponentDefinitionException:
> Unable to intialize bean featuresService
> at
> org.apache.geronimo.blueprint.container.BeanRecipe.internalCreate(BeanRe
> cipe.java:519)
> at
> org.apache.geronimo.blueprint.di.AbstractRecipe.create(AbstractRecipe.ja
> va:64)
> at
> org.apache.geronimo.blueprint.container.BlueprintRepository.createInstan
> ces(BlueprintRepository.java:212)
> at
> org.apache.geronimo.blueprint.container.BlueprintRepository.createAll(Bl
> ueprintRepository.java:140)
> at
> org.apache.geronimo.blueprint.container.BlueprintContainerImpl.instantia
> teEagerComponents(BlueprintContainerImpl.java:603)
> at
> org.apache.geronimo.blueprint.container.BlueprintContainerImpl.doRun(Blu
> eprintContainerImpl.java:310)
> at
> org.apache.geronimo.blueprint.container.BlueprintContainerImpl.run(Bluep
> rintContainerImpl.java:211)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
> at
> java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.acc
> ess$301(ScheduledThreadPoolExecutor.java:98)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run
> (ScheduledThreadPoolExecutor.java:207)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecuto
> r.java:886)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.ja
> va:908)
> at java.lang.Thread.run(Thread.java:619)
> Caused by: java.lang.RuntimeException: URL
> [mvn:com.mrsl.vp/scimitar/3.0.0-SNAPSHOT/xml/features] could not be
> resolved.
> at
> org.ops4j.pax.url.mvn.internal.Connection.getInputStream(Connection.java
> :195)
> at
> org.apache.felix.karaf.features.internal.RepositoryImpl.load(RepositoryI
> mpl.java:89)
> at
> org.apache.felix.karaf.features.internal.FeaturesServiceImpl.internalAdd
> Repository(FeaturesServiceImpl.java:143)
> at
> org.apache.felix.karaf.features.internal.FeaturesServiceImpl.start(Featu
> resServiceImpl.java:393)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
> a:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
> Impl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.apache.geronimo.blueprint.utils.ReflectionUtils.invoke(ReflectionUti
> ls.java:206)
> at
> org.apache.geronimo.blueprint.container.BeanRecipe.invoke(BeanRecipe.jav
> a:639)
> at
> org.apache.geronimo.blueprint.container.BeanRecipe.internalCreate(BeanRe
> cipe.java:517)
> ... 14 more
>
> Karaf will successfully start with my customizations, if I ensure that
> all the bundles listed in the features repository are in my local
> repository (~/.m2/repository), even though they are in the Karaf
> repository (the system directory of the assembly). Alternatively, if I
> change featuresRepository and featuresBoot back to the default, Karaf
> will start properly and I can then execute features:addUrl to the custom
> repository, then features:install our application.
>
> It appears that any bundle loaded by the Feature mechanism at boot time
> needs to be in my local repository even if it is in the Karaf
> repository. Karaf should be able to find these bundles in the system
> directory like it used to. This is probably just a configuration issue,
> but I can't figure out how to get it to work the way it did before
> FileInstall replaced FileMonitor.
>
>
> Tim Moloney The reasonable man adapts himself to
> MRSL the world; the unreasonable one persists
> 2015 Cattlemen Road in trying to adapt the world to himself.
> Sarasota, FL 34232 Therefore all progress depends on the
> (941) 377-6775 x208 unreasonable man. George Bernard Shaw
>
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com