felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <gno...@gmail.com>
Subject Re: Karaf Feature problem after FileInstall replaced FileMonitor
Date Tue, 01 Sep 2009 14:09:48 GMT
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 <Tim.Moloney@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message