In the "good old times" I used to create my custom
Karaf just by using the maven-assemblies plugin combined with the
features-plugin. This way I just added all required bundles into the
system repo, addded those
bundles to the startup.properties and en-voilà had a nice Karaf runtime
with all needed bundles :)
just another working solution that already worked for Karaf 1.x to 2.x :)
just my 0.02$
regards, Achim
Am 12.04.2012 19:56, schrieb David Jencks:
I think this is an indication of why relying on mvn urls is a bad idea in karaf.
I'm not sure how practical it is in any version of karaf but you might try
installing all the bundles you use in the karaf repository and modifying your
feature descriptors to use reference: file urls. This will mean the cache
doesn't contain the actual bundles, just a little metadata bascally pointing to
the actual file system location. Since there's still only one copy of the
actual bundle the disc space should be the same. When you do a clean start or
remove your cache forcibly then everything you need will still be in the karaf
repo.
A while back in karaf 3 you could sort of automate this by making a custom
karaf assembly and including all your features as startup features. This will
basically hardcode what bundles are running, but they'll all be installed using
reference urls and be actually present in the system repo. I haven't tried
this recently to make sure it still works, and I can't seriously recommend
using unreleased karaf 3 in production.
david jencks
On Apr 12, 2012, at 10:35 AM, bobshort wrote:
Hi,
We are using Karaf on plug computers in the field to collect data. These
plug computers are sometimes hot power cycled due to power outages, etc.
Occasionally, when they are hot power cycled, karaf will not come back up
cleanly. We've tried both Felix and Equinox and had issues with both.
I noticed this from the Karaf docs:
/ Launching Karaf can result in a deadlock in Felix during module
dependency resolution.
This is often a result of sending a SIGINT (control-C) to the process
when it will not cleanly exit.
This can corrupt the caches and cause startup problems in the very next
launch. It is fixed by emptying the component cache:
rm -rf data/cache/*/
Unfortunately cleaning up the component cache effectively un-deploys all the
features and bundles we've installed. In this case we have to get remote
access to the plug computer and completely re-install all our features. This
is a major pain for us and for our customers.
Any suggestions on workaround for this issue that does not involve
re-installing everything?
--
View this message in context:
http://karaf.922171.n3.nabble.com/Karaf-Corrupt-Component-Cache-tp3905992p3905992.html
Sent from the Karaf - User mailing list archive at Nabble.com.
--
- Apache Karaf<http://karaf.apache.org/> Committer& PMC
- OPS4J Pax Web<http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer&
Project Lead
- Blog<http://notizblog.nierbeck.de/>
