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]
