Please answer the question below regarding usage of
org.apache.aries.blueprint.preemptiveShutdown=false. any repercussions of
doing this?
Also, is there any documentation on this and any other system properties
that are hidden? Perhaps this one should be explicitly set to true/false
by default
JB,
Thanks.
But is there anything in place to prevent the preemptive shutdown from
stopping a bundle before it otherwise would be based on the start-level?
The problem in this case is that the ActiveMQ bundle (that uses blueprint)
gets shutdown before message consumers (that don't use
Hi Kevin,
what do you have in etc/org.apache.karaf.features.cfg ?
Especially:
respectStartLvlDuringFeatureUninstall=true
respectStartLvlDuringFeatureStartup=true
Regards
JB
On 01/09/2015 07:00 AM, Kevin Schmidt wrote:
JB,
Thanks.
But is there anything in place to prevent the preemptive
If you place your stuff in the system directory, I don't see the need to
change the default configuration. This folder is already included in the
defaultRepositories in org.ops4j.pax.url.mvn.cfg.
Define features according to
http://karaf.apache.org/manual/latest/users-guide/provisioning.html
For the xxx times, I already replied ;)
AFAIR, I updated the documentation (let me check and update).
The current 3.0.3-SNAPSHOT version already use a production mode
configuration.
Regards
JB
On 01/08/2015 09:00 AM, Srikanth wrote:
I am also facing similar issue in karaf 3.0.0.
Could you
I am also facing similar issue in karaf 3.0.0.
Could you please send me the configuration?
I have all my artifacts in {karaf.home}/system directory, and want karaf to
access all the artifacts from system directory.
Basically i dont want artifacts to be downloaded and .m2 directory to be
created.
One case I've seen, this issue occurs when ActiveMQ is being used and gets
shutdown as part of the Blueprint shutdown that doesn't seem to follow the
reverse start-level shutdown. Then AMQ clients that aren't using Blueprint
have issues as they are trying to reconnect and don't shutdown.
I found
Hi,
Yeah, this error means your bundle get started before the
cxf-rt-transports-http bundle.
You can make your bundle import an OSGi
service(org.apache.cxf.transport.http.DestinationRegistry) which is exposed by
the cxf-rt-transports-http bundle to ensure cxf bundle get started reliably
An addition: in the meantime I understood that the problem is not specific
for Karaf EIK, but is the same for other OSGI runtimes, if you want to make
a war a web application bundle by just adding a manifest. In the final
archive, everything is in place and runs perfectly in the OSGi runtime
Thanks Freeman, I'll give this a try.
On Thu Jan 08 2015 at 10:54:29 AM Freeman Fang freeman.f...@gmail.com
wrote:
Hi,
Yeah, this error means your bundle get started before the
cxf-rt-transports-http bundle.
You can make your bundle import an OSGi
10 matches
Mail list logo
