2015-07-08 16:48 GMT+02:00 Benson Margulies <ben...@basistech.com>: > On Wed, Jul 8, 2015 at 10:32 AM, Jean-Baptiste Onofré <j...@nanthrax.net> > 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. > > > > ? > > > > 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: users-unsubscr...@felix.apache.org > >> For additional commands, e-mail: users-h...@felix.apache.org > >> > > > > -- > > Jean-Baptiste Onofré > > jbono...@apache.org > > http://blog.nanthrax.net > > Talend - http://www.talend.com > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org > > For additional commands, e-mail: users-h...@felix.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org > For additional commands, e-mail: users-h...@felix.apache.org > >
