Responses in-line.
> Date: Wed, 29 Mar 2006 09:18:20 +0200
> From: Peter Kriens <[EMAIL PROTECTED]>
> Subject: Re: [osgi-dev] Indirect dependencies in OSGi/Equinox
> To: David Kemper <[EMAIL PROTECTED]>
> Cc: osgi-dev@bundles.osgi.org
> Message-ID: <[EMAIL PROTECTED]>
> Content-Type: text/plain; charset=iso-8859-15
>
> I originally understood you want a central shared store for
> efficiency, but each Framework would have set of installed bundles
> which is a subset of the store.
>
> The idea of having hundreds of Frameworks with all the same
> configuration while they have different tasks does not sound like a
> good approach to me. You invariably get incompatibilities between
> bundles and of course runtime inefficiencies.
Each framework would have its own configuration.
>
> Anyway, to get the different behaviors, you will have to do start/stop
> different bundles anyway, otherwise all frameworks would do the same.
> So configuration per framework runtime will be necessary. It seems to
> me that you need a different set of installed bundles
> per framework/runtime, which obviously could come from a shared bundle
> store.
>
> So I am not sure what the problem is with JDBC and Hibernate. Lets say
> you have application A that has a dependency on Derby (bad) and runs
> in framework F. A is an existing application, it can therefore not
> be modified.
> It is started with new A(Connection c)
I think I see the methodology. For Hibernate, have the bundle that
will be using Hibernate for de/serialization depend on its domain
class bundles; Hibernate itself will depend on the bundles it needs
directory, and will DynamicImport-Package: * to handle the domain
classes. It is then an issue of ensuring that the framework runs
with all the necessary bundles. The case is similar for JDBC.
>
> I would wrap A in a bundle and provide an activator to bridge OSGi and
> the application A.
>
> manifest:
> Import-Package: ...,org.apache.derby.embedded, (A's imports
> can be calculated)
> Bundle-Classpath: .,a.jar
> Service-Component: component.xml
>
> component.xml
> -> impl = Activator
> -> provides ManagedService
> -> references ...
>
> Activator
>
> ComponentContext context;
> A a;
>
> public void activate(ComponentContext c) {
> context = c;
> }
>
> public void update(Dictionary d) {
> if ( d==null)
> return;
>
> if( a != null )
> a.close();
>
> String url = (String) d.get("jdbcurl");
> if ( url != null ) {
> File dir = context.getBundleContext().getDataFile("db");
> dir.mkdir();
> String jdbc = url+dir.getAbsolutePath();
> Connection connection = DriverManager.getConnection(jdbc,
> asProps(d));
> }
> a = new A(connection,...);
> }
>
> Derby is already an OSGi bundle out of the box so it should register
> itself automatically.
>
> Now this seems so easy, so I probably missed the point. However, this
> should give you enough target to tell where my misunderstanding is.
>
> About Hibernate.
>
> This also boils down to the situation that you need to define the set
> of installed bundles, which should be smaller than the bundle store.
> This set is only marginally defined by Hibernate and mostly by the the
> clients of hibernate. So Hibernate should use Import-Package for the
> classes it knows it depends on and DynamicImport-Package: * for the
> rest.
>
> The clients that use Hibernate should export or import the domain
> classes that need to be serialized/deserialized. This is independent
> of Hibernate.
>
> I think there is sufficient information in the manifests of the client
> bundles to decide the set of installed bundles automatically. So you
> start with your client bundle imports and from the import-packages
> you calculate the dependencies. This will automatically find hibernate
> and any domain classes that are needed by the client. As far as I can
> see any domain classes to be serialized are needed by the clients or
> are exported by the clients. I have a hard time constructing a
> realistic use case where the domain classes are never explicitly
> specified as an import and export.
>
> So I am again not sure what the problem is?
I think at this point the problem is late binding in the legacy/
flattening case. I don't think it's possible to let the customer add
their own bundles to the mix (e.g. their own JDBC driver
implementation) without running some code during launch or re-
flattening.
For example, in our legacy runtimes, you can drop JARs into a set of
common directories, and these will be picked up by the next launch of
the runtime. You can use this to supply, say, your own drivers, or
to apply targeted support fixes to the rest of the code. This model
breaks down when we talk about adding the possibility of multiple
versions of bundles. What if one runtime configuration uses v1.0 of
bundle A, and another runtime configuration uses v2.0 of bundle A,
and you need to apply a patch to only v1.0? Dropping a JAR into the
common directory will be picked up by both versions if you simple add
all those JARs to the boot path. If we use OSGi metadata during
flattening, we can resolve the version closure, but this implies
reflattening everything if the user needs to provide a new dynamic
bundle. We've gained multi-versioning at the expense of customer
drag-and-drop.
I think it all hinges around the fact that *someone* needs to tell
OSGi what to run with. There's no single, magic, fits-all way to
configure these multiple runtimes with a perfect balance of
determinism and customer ease-of-use. I'm sure no one on this list
is surprised, but one can always hope for "and then magic occurs..." ;-)
> The non-osgi case (I understand from the description the non-osgi app
> is still using the OSGi headers).
>
> If the customer imports the driver package, you can include the
> specific JDBC driver. However, you still need to configure the URL and
> the name of the DB.
>
> Of course you have to be careful here because a flattened classpath
> cannot model the OSGi network of classloaders. You could seriously
> confuse bundles.
Agreed. However in our case we control the vast majority of the
package space, so we hope to manage this risk (and we can provide
tooling to detect or diagnose possible problems).
> -----------------------------
> I can see the advantage of having a single repository that contains
> ALL the bundles/jars that are being used. Sharing the bits on disk has
> a huge advantage if you have a lot of simultaneous framework runtimes.
> The reference: url of Eclipse and Felix seem to go a long way towards
> this goal (but can still be improved for your use case I guess wrt
> embedded jars and DLLs).
>
> However, I do not see how each framework could see this (potentially
> huge) repository as the set of installed bundles. I think you will
> need to configure this.
Agreed. The working approach is to start with a (small) number of
core bundles, and traverse the dependency tree to form the bundle
closure. This would be the out-of-band "flattening" step.
> Now you can tell me what I missed :-)
I hope I have above. I don't think you missed anything. I think
most of our remaining problems is formulating a methodology for
providing some dynamic dependency features (customer-provided bundles
and our supplied support fixes) to an otherwise static legacy
flattened world. If you have any ideas around this, I'm all
ears...or, rather, eyes.
>
> Kind regards,
>
> Peter Kriens
Thanks for your time,
/djk
_______________________________________________
osgi-dev mailing list
osgi-dev@bundles.osgi.org
http://bundles.osgi.org/mailman/listinfo/osgi-dev
