You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@karaf.apache.org by afbagwe <af...@sandia.gov> on 2016/09/09 16:35:53 UTC

Hot deploy priority on first start up?

Hi there,

I'm with a group that provisions our own instance of Karaf. We've run into
an issue that might be a bug, so I wanted to ask here first.

It has to do with a *first-time deployment and start-up* of the Karaf
container. We un-tar the instance but before starting it we put our
application JARs into the deploy folder. When Karaf starts it appears to
have no priority over it's own bundles as a part of the boot features set
versus the files in the deploy folder. As a result some of our biundles are
installed  first (with bundle IDs in the 10s) versus their dependencies that
are part of Karaf's boot features (IDs much higher). Our JARs therefore are
in an installed state, and when you try to start them they fail saying they
are missing dependencies even though the dependencies are listed as active
bundles.

Contrast this to the same initial distribution unpacked and started with an
empty deploy folder. We then take the exact same files from the experiment
above and drop them into the deploy folder with Karaf running. This time
they start up properly as active having found their dependencies.

It seems odd that this should occur. My guess is that when starting up for
the first time Karaf should prioritize it's own features and internal
bundles over anything in the deploy folder, but that doesn't seem to be the
case.

Any advice or confirmation or clearing up of misconceptions of how Karaf is
supposed to work would be appreciated.

Thanks!
-Allen



--
View this message in context: http://karaf.922171.n3.nabble.com/Hot-deploy-priority-on-first-start-up-tp4047948.html
Sent from the Karaf - User mailing list archive at Nabble.com.

Re: Hot deploy priority on first start up?

Posted by afbagwe <af...@sandia.gov>.
JIRA ticket here. Thanks!

https://issues.apache.org/jira/browse/KARAF-4723


Guillaume Nodet-2 wrote
> Could you raise a JIRA for that please ?
> I think I've just unwillingly reproduced the issue and I have a fix for
> it.
> 
> 2016-09-10 0:51 GMT+02:00 afbagwe &lt;

> afbagwe@

> &gt;:
> 
>> I've confirmed that
>>
>> featuresBootAsynchronous=false
>> felix.fileinstall.active.level = 80
>>
>> are indeed the settings that are being used. Oddly enough when I ran it
>> again I couldn't reproduce the error on my build environment. However
>> when
>> I
>> set up the same deployment method in a Docker container, it occurred
>> again.
>> Here is the console output showing the problem:
>>
>> admin@witchdoctor>bundle:list
>> START LEVEL 100 , List Threshold: 50
>>  ID | State     | Lvl | Version | Name
>> -----------------------------------------------------------------
>>  10 | Installed |  80 | 2.1.0   | Framework Library: Core
>>  11 | Installed |  80 | 0.1.0   | nik-hello-world
>>  12 | Active    |  50 | 2.6.3   | Jackson-annotations
>>  13 | Active    |  50 | 2.6.3   | Jackson-core
>>  14 | Active    |  50 | 2.6.3   | jackson-databind
>>  15 | Active    |  50 | 2.6.3   | Jackson-JAXRS-base
>>  16 | Active    |  50 | 2.6.3   | Jackson-JAXRS-JSON
>>  17 | Active    |  50 | 2.6.3   | Jackson-module-JAXB-annotations
>>  22 | Active    |  50 | 2.0.1   | javax.ws.rs-api
>>  37 | Active    |  50 | 2.16.3  | camel-blueprint
>>  38 | Active    |  50 | 2.16.3  | camel-catalog
>>  39 | Active    |  50 | 2.16.3  | camel-commands-core
>>  40 | Active    |  50 | 2.16.3  | camel-core
>>  41 | Active    |  50 | 2.16.3  | camel-cxf
>>  42 | Active    |  50 | 2.16.3  | camel-cxf-transport
>>  43 | Active    |  50 | 2.16.3  | camel-jackson
>>  44 | Active    |  50 | 2.16.3  | camel-mina2
>>  45 | Active    |  50 | 2.16.3  | camel-spring
>>  46 | Active    |  50 | 2.16.3  | camel-karaf-commands
>>  47 | Active    |  50 | 1.10.0  | Apache Commons Codec
>>  48 | Active    |  50 | 2.4.0   | Commons IO
>>  49 | Active    |  50 | 3.4.0   | Apache Commons Lang
>>  94 | Active    |  50 | 2.0.9   | Apache MINA Core
>> 149 | Installed |  80 | 0.1     | standalone
>> admin@witchdoctor>bundle:diag 10
>> Framework Library: Core (10)
>> ----------------------------
>> Status: Installed
>> Unsatisfied Requirements:
>>
>>
>> admin@witchdoctor>bundle:start 10
>> Error executing command: Error executing command on bundles:
>>         Error starting bundle 10: Unable to resolve fwk-lib-core [10](R
>> 10.0):
>> missing requirement [fwk-lib-core [10](R 10.0)] osgi.wiring.package;
>> (&(osgi.wiring.package=org.apache.commons.codec.binary)(
>> version>=1.10.0)(!(version>=2.0.0)))
>> Unresolved requirements: [[fwk-lib-core [10](R 10.0)]
>> osgi.wiring.package;
>> (&(osgi.wiring.package=org.apache.commons.codec.binary)(
>> version>=1.10.0)(!(version>=2.0.0)))]
>>
>> -----------------------------
>>
>> As you can see, bundle IDs 10 and 11 are my own jar. Bundle ID 149 is my
>> blueprint file. For whatever reason when I run diag on bundle 10 is
>> doesn't
>> list any unsatisfied requirements, but if I try to start it is says I'm
>> missing my dependency on Apache Commons Codec. That bundle (ID 47) is
>> active
>> and a part of the boot features we have installed. My other bundles fail
>> to
>> start for similar reasons.
>>
>> However if I start up my Karaf instance first and then put the two jars
>> and
>> blueprint into the deploy folder, everything activates correctly with no
>> missing dependencies.
>>
>>
>>
>>
>>
>> --
>> View this message in context: http://karaf.922171.n3.nabble.
>> com/Hot-deploy-priority-on-first-start-up-tp4047948p4047953.html
>> Sent from the Karaf - User mailing list archive at Nabble.com.
>>
> 
> 
> 
> -- 
> ------------------------
> Guillaume Nodet
> ------------------------
> Red Hat, Open Source Integration
> 
> Email: 

> gnodet@

> Web: http://fusesource.com
> Blog: http://gnodet.blogspot.com/





--
View this message in context: http://karaf.922171.n3.nabble.com/Hot-deploy-priority-on-first-start-up-tp4047948p4048142.html
Sent from the Karaf - User mailing list archive at Nabble.com.

Re: Hot deploy priority on first start up?

Posted by Guillaume Nodet <gn...@apache.org>.
Could you raise a JIRA for that please ?
I think I've just unwillingly reproduced the issue and I have a fix for it.

2016-09-10 0:51 GMT+02:00 afbagwe <af...@sandia.gov>:

> I've confirmed that
>
> featuresBootAsynchronous=false
> felix.fileinstall.active.level = 80
>
> are indeed the settings that are being used. Oddly enough when I ran it
> again I couldn't reproduce the error on my build environment. However when
> I
> set up the same deployment method in a Docker container, it occurred again.
> Here is the console output showing the problem:
>
> admin@witchdoctor>bundle:list
> START LEVEL 100 , List Threshold: 50
>  ID | State     | Lvl | Version | Name
> -----------------------------------------------------------------
>  10 | Installed |  80 | 2.1.0   | Framework Library: Core
>  11 | Installed |  80 | 0.1.0   | nik-hello-world
>  12 | Active    |  50 | 2.6.3   | Jackson-annotations
>  13 | Active    |  50 | 2.6.3   | Jackson-core
>  14 | Active    |  50 | 2.6.3   | jackson-databind
>  15 | Active    |  50 | 2.6.3   | Jackson-JAXRS-base
>  16 | Active    |  50 | 2.6.3   | Jackson-JAXRS-JSON
>  17 | Active    |  50 | 2.6.3   | Jackson-module-JAXB-annotations
>  22 | Active    |  50 | 2.0.1   | javax.ws.rs-api
>  37 | Active    |  50 | 2.16.3  | camel-blueprint
>  38 | Active    |  50 | 2.16.3  | camel-catalog
>  39 | Active    |  50 | 2.16.3  | camel-commands-core
>  40 | Active    |  50 | 2.16.3  | camel-core
>  41 | Active    |  50 | 2.16.3  | camel-cxf
>  42 | Active    |  50 | 2.16.3  | camel-cxf-transport
>  43 | Active    |  50 | 2.16.3  | camel-jackson
>  44 | Active    |  50 | 2.16.3  | camel-mina2
>  45 | Active    |  50 | 2.16.3  | camel-spring
>  46 | Active    |  50 | 2.16.3  | camel-karaf-commands
>  47 | Active    |  50 | 1.10.0  | Apache Commons Codec
>  48 | Active    |  50 | 2.4.0   | Commons IO
>  49 | Active    |  50 | 3.4.0   | Apache Commons Lang
>  94 | Active    |  50 | 2.0.9   | Apache MINA Core
> 149 | Installed |  80 | 0.1     | standalone
> admin@witchdoctor>bundle:diag 10
> Framework Library: Core (10)
> ----------------------------
> Status: Installed
> Unsatisfied Requirements:
>
>
> admin@witchdoctor>bundle:start 10
> Error executing command: Error executing command on bundles:
>         Error starting bundle 10: Unable to resolve fwk-lib-core [10](R
> 10.0):
> missing requirement [fwk-lib-core [10](R 10.0)] osgi.wiring.package;
> (&(osgi.wiring.package=org.apache.commons.codec.binary)(
> version>=1.10.0)(!(version>=2.0.0)))
> Unresolved requirements: [[fwk-lib-core [10](R 10.0)] osgi.wiring.package;
> (&(osgi.wiring.package=org.apache.commons.codec.binary)(
> version>=1.10.0)(!(version>=2.0.0)))]
>
> -----------------------------
>
> As you can see, bundle IDs 10 and 11 are my own jar. Bundle ID 149 is my
> blueprint file. For whatever reason when I run diag on bundle 10 is doesn't
> list any unsatisfied requirements, but if I try to start it is says I'm
> missing my dependency on Apache Commons Codec. That bundle (ID 47) is
> active
> and a part of the boot features we have installed. My other bundles fail to
> start for similar reasons.
>
> However if I start up my Karaf instance first and then put the two jars and
> blueprint into the deploy folder, everything activates correctly with no
> missing dependencies.
>
>
>
>
>
> --
> View this message in context: http://karaf.922171.n3.nabble.
> com/Hot-deploy-priority-on-first-start-up-tp4047948p4047953.html
> Sent from the Karaf - User mailing list archive at Nabble.com.
>



-- 
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration

Email: gnodet@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/

Re: Hot deploy priority on first start up?

Posted by afbagwe <af...@sandia.gov>.
I've confirmed that 

featuresBootAsynchronous=false 
felix.fileinstall.active.level = 80 

are indeed the settings that are being used. Oddly enough when I ran it
again I couldn't reproduce the error on my build environment. However when I
set up the same deployment method in a Docker container, it occurred again.
Here is the console output showing the problem:

admin@witchdoctor>bundle:list
START LEVEL 100 , List Threshold: 50
 ID | State     | Lvl | Version | Name
-----------------------------------------------------------------
 10 | Installed |  80 | 2.1.0   | Framework Library: Core
 11 | Installed |  80 | 0.1.0   | nik-hello-world
 12 | Active    |  50 | 2.6.3   | Jackson-annotations
 13 | Active    |  50 | 2.6.3   | Jackson-core
 14 | Active    |  50 | 2.6.3   | jackson-databind
 15 | Active    |  50 | 2.6.3   | Jackson-JAXRS-base
 16 | Active    |  50 | 2.6.3   | Jackson-JAXRS-JSON
 17 | Active    |  50 | 2.6.3   | Jackson-module-JAXB-annotations
 22 | Active    |  50 | 2.0.1   | javax.ws.rs-api
 37 | Active    |  50 | 2.16.3  | camel-blueprint
 38 | Active    |  50 | 2.16.3  | camel-catalog
 39 | Active    |  50 | 2.16.3  | camel-commands-core
 40 | Active    |  50 | 2.16.3  | camel-core
 41 | Active    |  50 | 2.16.3  | camel-cxf
 42 | Active    |  50 | 2.16.3  | camel-cxf-transport
 43 | Active    |  50 | 2.16.3  | camel-jackson
 44 | Active    |  50 | 2.16.3  | camel-mina2
 45 | Active    |  50 | 2.16.3  | camel-spring
 46 | Active    |  50 | 2.16.3  | camel-karaf-commands
 47 | Active    |  50 | 1.10.0  | Apache Commons Codec
 48 | Active    |  50 | 2.4.0   | Commons IO
 49 | Active    |  50 | 3.4.0   | Apache Commons Lang
 94 | Active    |  50 | 2.0.9   | Apache MINA Core
149 | Installed |  80 | 0.1     | standalone
admin@witchdoctor>bundle:diag 10
Framework Library: Core (10)
----------------------------
Status: Installed
Unsatisfied Requirements:


admin@witchdoctor>bundle:start 10
Error executing command: Error executing command on bundles:
	Error starting bundle 10: Unable to resolve fwk-lib-core [10](R 10.0):
missing requirement [fwk-lib-core [10](R 10.0)] osgi.wiring.package;
(&(osgi.wiring.package=org.apache.commons.codec.binary)(version>=1.10.0)(!(version>=2.0.0)))
Unresolved requirements: [[fwk-lib-core [10](R 10.0)] osgi.wiring.package;
(&(osgi.wiring.package=org.apache.commons.codec.binary)(version>=1.10.0)(!(version>=2.0.0)))]

-----------------------------

As you can see, bundle IDs 10 and 11 are my own jar. Bundle ID 149 is my
blueprint file. For whatever reason when I run diag on bundle 10 is doesn't
list any unsatisfied requirements, but if I try to start it is says I'm
missing my dependency on Apache Commons Codec. That bundle (ID 47) is active
and a part of the boot features we have installed. My other bundles fail to
start for similar reasons.

However if I start up my Karaf instance first and then put the two jars and
blueprint into the deploy folder, everything activates correctly with no
missing dependencies.





--
View this message in context: http://karaf.922171.n3.nabble.com/Hot-deploy-priority-on-first-start-up-tp4047948p4047953.html
Sent from the Karaf - User mailing list archive at Nabble.com.

Re: Hot deploy priority on first start up?

Posted by Guillaume Nodet <gn...@apache.org>.
If you use the following, it should work
  * featuresBootAsynchronous=false in etc/org.apache.karaf.features.cfg
  * felix.fileinstall.active.level = 80 in etc/
org.apache.felix.fileinstall-deploy.cfg

If that's not the case, it may be a bug in file install.  You need to try
verifying if the felix.fileinstall.active.level is honored by file install,
which means it should not start polling files before the framework has
reach start level 80.  The first flag should ensure that the boot features
are installed synchronously when the feature service is started the first
time, which should be at level 30 in the default config afaik.


2016-09-09 18:35 GMT+02:00 afbagwe <af...@sandia.gov>:

> Hi there,
>
> I'm with a group that provisions our own instance of Karaf. We've run into
> an issue that might be a bug, so I wanted to ask here first.
>
> It has to do with a *first-time deployment and start-up* of the Karaf
> container. We un-tar the instance but before starting it we put our
> application JARs into the deploy folder. When Karaf starts it appears to
> have no priority over it's own bundles as a part of the boot features set
> versus the files in the deploy folder. As a result some of our biundles are
> installed  first (with bundle IDs in the 10s) versus their dependencies
> that
> are part of Karaf's boot features (IDs much higher). Our JARs therefore are
> in an installed state, and when you try to start them they fail saying they
> are missing dependencies even though the dependencies are listed as active
> bundles.
>
> Contrast this to the same initial distribution unpacked and started with an
> empty deploy folder. We then take the exact same files from the experiment
> above and drop them into the deploy folder with Karaf running. This time
> they start up properly as active having found their dependencies.
>
> It seems odd that this should occur. My guess is that when starting up for
> the first time Karaf should prioritize it's own features and internal
> bundles over anything in the deploy folder, but that doesn't seem to be the
> case.
>
> Any advice or confirmation or clearing up of misconceptions of how Karaf is
> supposed to work would be appreciated.
>
> Thanks!
> -Allen
>
>
>
> --
> View this message in context: http://karaf.922171.n3.nabble.
> com/Hot-deploy-priority-on-first-start-up-tp4047948.html
> Sent from the Karaf - User mailing list archive at Nabble.com.
>



-- 
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration

Email: gnodet@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/