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:[email protected]] 
> Sent: Tuesday, September 01, 2009 10:10
> To: [email protected]
> 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 
> <[email protected]>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
> 

Reply via email to