I suppose you refer to https://issues.apache.org/jira/browse/FELIX-4885.
Not sure what you tried, but if you set your cache directory to be read-only using a chmod ogua-w data/cache (in Karaf), I've been able to run a read-only karaf without too much problem. I had to turn off the felix locking by adding felix.cache.locking = false to etc/config.properties, but apart from that, things seems to work well enough. 2015-07-08 17:18 GMT+02:00 Benson Margulies <[email protected]>: > On Wed, Jul 8, 2015 at 10:54 AM, Guillaume Nodet <[email protected]> > wrote: > > 2015-07-08 16:48 GMT+02:00 Benson Margulies <[email protected]>: > > > >> On Wed, Jul 8, 2015 at 10:32 AM, Jean-Baptiste Onofré <[email protected]> > >> wrote: > >> > Hi Benson, > >> > >> Hi Jean-Baptiste, thanks for giving my situation some thought! > >> > >> > > >> > What you are doing looks like a container: why not using Karaf and > >> features > >> > >> Well, I started out with plain Felix. We've ended up with Equinox. I'm > >> assuming that Karaf needs Felix as opposed to Equinox, I'm sure you'll > >> correct me if I'm wrong. > > > > > > That has already been answered ... ;-) > > > > > >> Here's why we ended up on Equinox: > >> > >> We deliver a very large amount of read-only data to our users; it's > >> statistical models and dictionaries. We don't want them to have to > >> make copies. This data is mapped into memory, not just read from > >> streams. > >> > >> I created a mechanism in which our bundles contain (via a fragment) > >> this data as a compressed tar archive. The Activators call > >> BundleContext.getDataFile(), and unpack the data into there. This > >> works great in Felix, so long as only one process is using the > >> container. However, a user with multiple processes needs multiple > >> containers and multiple copies, because Felix disables getDataFile() > >> entirely for shared containers. > >> > >> Equinox, on the other hand, allows for shared, read-only, data. I can > >> load my bundles into a container, tell them to unpack their data, and > >> then treat the resulting container as a read-only, shared, resource, > >> complete with all the data. > >> > >> If we wanted to make use of Karaf, I'd have to give up on keeping the > >> data seamlessly inside the container, or find out that I can, in fact, > >> run Karaf atop of Equinox, or find out that Karaf has some other > >> solution to the shared data problem. I confess that, until this email, > >> I hadn't considered Karaf, so I didn't do any research on the question > >> of Karaf's feelings about the framework implementation. > >> > > > > What's your configuration for shared containers ? > > We may be able to enhance felix to fix that if needed if that's the only > > problem. > > Here are the Equinox-specific options that we set. If Felix supported > the equivalent, we'd be happy Felix users. > > if (readOnly) { > // in spite of the seemingly standard names, these are > Equinox-specific. > configProps.put("osgi.configuration.area.readOnly", "true"); > configProps.put("osgi.sharedConfiguration.area.readOnly", "true"); > configProps.put("osgi.instance.area.readOnly", "true"); > configProps.put("osgi.user.area.readOnly", "true"); > } > > I think that I tried and failed to convince the Felix community that > this was a valuable feature once before, but I'm happy to try again. > > The crucial phenomenon here is that BundleContext.getDataFile() will > return non-null values when you set these. > > > > > > > >> > >> > >> > ? > >> > > >> > Karaf features are an interesting way to do provisioning, and with > >> profiles > >> > it allows you to do runtime provisioning and custom distribution > >> > provisioning. > >> > > >> > For testing, allow me to disagree about pax-exam: it's not so complex, > >> and > >> > it runs fine by itself. > >> > >> I ran into a number of potholes, and some of my co-workers took one > >> look at a typical configuration setup in a test class and needed a > >> beer. > >> > >> An example pothole: the 'Parameterized test' feature appears / > >> appeared to be completely broken. > >> > >> However, we're still using it. > >> > >> > >> > >> > >> > >> > > >> > Regards > >> > JB > >> > > >> > > >> > On 07/08/2015 04:22 PM, Benson Margulies wrote: > >> >> > >> >> To expand on what I'm doing, in case of useful advice: > >> >> > >> >> Here I am, part of a team that builds and maintains a large body of > >> >> Java code. Until recently, no OSGi at all. Maven is our build tool. > >> >> IntelliJ is our predominant IDE. > >> >> > >> >> Recently, we decided to introduce OSGi into the picture. However, we > >> >> can't just wipe out the past; we have many users who would have > >> >> kittens if asked to use OSGi. And we would like to avoid radical > >> >> changes in tooling. So we want to build bundles, and we want to test > >> >> bundles, and we want to deliver a device that uses OSGi 'behind the > >> >> application's back' for those who don't want to deal with it. That > >> >> amounts to launching the framework via the API, and adding some > >> >> packages to the system bundle to allow communication between 'inside' > >> >> and 'outside'. > >> >> > >> >> We added Maven modules that use the bundle plugin to our major > >> >> components. Where possible, we are using the existing OSGi status of > >> >> common open source facilities (commons-io, Jackson, etc). We arranged > >> >> things so that almost all communications are via services, not > >> >> exported packages. Where there are exported packages, the bundles are > >> >> simple in their structure (no packages exported from embedded jars), > >> >> so that we could retain relatively plain processes for Java > >> >> compilation. > >> >> > >> >> For testing, we pulled in pax-exam. I'm not especially thrilled with > >> >> pax-exam; it seems complex and fragile to me. > >> >> > >> >> Now, I'm looking at provisioning; when the time comes to set up a > >> >> container with the right set of components, how do we assemble all > the > >> >> dependencies without a bunch of manual metadata maintenance? > >> >> > >> >> --------------------------------------------------------------------- > >> >> To unsubscribe, e-mail: [email protected] > >> >> For additional commands, e-mail: [email protected] > >> >> > >> > > >> > -- > >> > Jean-Baptiste Onofré > >> > [email protected] > >> > http://blog.nanthrax.net > >> > Talend - http://www.talend.com > >> > > >> > --------------------------------------------------------------------- > >> > To unsubscribe, e-mail: [email protected] > >> > For additional commands, e-mail: [email protected] > >> > > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [email protected] > >> For additional commands, e-mail: [email protected] > >> > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
