Exposing/Including dependencies to/in Bundles

["David G." <da...@gmail.com>]

Quick question about including/exposing dependencies for bundles running under felix. 

As I understand it, there are predominantly 2 ways of exposing 3rd party libs for use in our bundle:

1) Include the 3rd party jar files in the bundle's /lib folder - which exposes all packages of the jar(s) to the code in the bundle.
2) Package the 3rd party jar/jars as an OSGi bundle, exporting the requisite packages in the bnd by way of the manifest.

I seems like the first strategy encourages potential for future conflicts (if another bundle exports the same packages) but reduces the dependencies for the bundle, since its self-contained.

The second strategy allows for reusability of code (all bundles that need 3rd party library X can get the dependencies for the same bundle) however this adds extra dependencies to the bundle deployment lifecycle (you may have ensure that when Bundle A is deployed, there is process in place to deploy 3rd party bundles X, Y and Z).

 - Thoughts around when to use one over the other? 

- Are there any other dangers to using either method I didn't outline above?

 - Any other options?

Thanks


-- 
David Gonzalez
Sent with Sparrow (http://www.sparrowmailapp.com/?sig)

Re: Exposing/Including dependencies to/in Bundles

["Richard S. Hall" <he...@ungoverned.org>]

On 2/27/12 18:57 , Lucas Galfaso wrote:
> Hi,
>
>
> On Mon, Feb 27, 2012 at 4:45 PM, David G.<da...@gmail.com>  wrote:
>> Quick question about including/exposing dependencies for bundles running under felix.
>>
>> As I understand it, there are predominantly 2 ways of exposing 3rd party libs for use in our bundle:
>>
>> 1) Include the 3rd party jar files in the bundle's /lib folder - which exposes all packages of the jar(s) to the code in the bundle.
> Just to add to what Richard pointed out, there is no need to export
> these external libs.
>
>
>> 2) Package the 3rd party jar/jars as an OSGi bundle, exporting the requisite packages in the bnd by way of the manifest.
>>
>> I seems like the first strategy encourages potential for future conflicts (if another bundle exports the same packages) but reduces the dependencies for the bundle, since its self-contained.
> Here I agree with Richard, I do not see how this causes future conflicts.
>
>
>> The second strategy allows for reusability of code (all bundles that need 3rd party library X can get the dependencies for the same bundle) however this adds extra dependencies to the bundle deployment lifecycle (you may have ensure that when Bundle A is deployed, there is process in place to deploy 3rd party bundles X, Y and Z).
>>
>>   - Thoughts around when to use one over the other?
> In a perfect OSGi world, the later approach is best, unluckily for us,
> we are not in that world. Here is where my experience differs from the
> experience Richard had. We found that if we always aim for the later
> approach we see two issues. (1) We go into a bundle-boom effect where
> we end up with many bundles and it is very hard to know what depends
> on what without a very high diligence and being sure that we do not
> have superfluous bundles takes a lot of time, and (2) if we have to
> work with legacy libraries that expect a single class loader that has
> it all, then the former approach makes everybody's life a lot easier.

To be clear, I wasn't trying to imply that one was better than the 
other, rather the latter approach simply doesn't require answering as 
many questions up front about how to package, what to export, whether to 
import AND export, etc.

Either way, though, there is some price to be paid for modularization, 
since the whole point is about putting boundaries around things in order 
to obtain better control and understanding.

-> richard

>
>
>> - Are there any other dangers to using either method I didn't outline above?
> Here I agree with Richard, both ways work well, but there is no "one
> size fits all" approach. You can mix and match both approaches as
> needed.
>
>
>>   - Any other options?
> When we go for the later approach, we try to keep everything into two
> types of bundles. (1) Bundles that just expose the interface to a
> service, and (2) bundles that export as few packages as possible and
> all the services definitions are declared thru DS (and, if possible,
> we export no package and only import the definition from the services
> we want to expose)
>
> Just to be clear, we do know that this approach does use more memory,
> does not allow for class loader short circuits and the class loader
> has to work more (once).
>
> Regards,
>    Lucas
>
>
>> Thanks
>>
>>
>> --
>> David Gonzalez
>> Sent with Sparrow (http://www.sparrowmailapp.com/?sig)
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org

Re: Exposing/Including dependencies to/in Bundles

[Lucas Galfaso <lg...@gmail.com>]

Hi,


On Mon, Feb 27, 2012 at 4:45 PM, David G. <da...@gmail.com> wrote:
> Quick question about including/exposing dependencies for bundles running under felix.
>
> As I understand it, there are predominantly 2 ways of exposing 3rd party libs for use in our bundle:
>
> 1) Include the 3rd party jar files in the bundle's /lib folder - which exposes all packages of the jar(s) to the code in the bundle.

Just to add to what Richard pointed out, there is no need to export
these external libs.


> 2) Package the 3rd party jar/jars as an OSGi bundle, exporting the requisite packages in the bnd by way of the manifest.
>
> I seems like the first strategy encourages potential for future conflicts (if another bundle exports the same packages) but reduces the dependencies for the bundle, since its self-contained.

Here I agree with Richard, I do not see how this causes future conflicts.


> The second strategy allows for reusability of code (all bundles that need 3rd party library X can get the dependencies for the same bundle) however this adds extra dependencies to the bundle deployment lifecycle (you may have ensure that when Bundle A is deployed, there is process in place to deploy 3rd party bundles X, Y and Z).
>
>  - Thoughts around when to use one over the other?

In a perfect OSGi world, the later approach is best, unluckily for us,
we are not in that world. Here is where my experience differs from the
experience Richard had. We found that if we always aim for the later
approach we see two issues. (1) We go into a bundle-boom effect where
we end up with many bundles and it is very hard to know what depends
on what without a very high diligence and being sure that we do not
have superfluous bundles takes a lot of time, and (2) if we have to
work with legacy libraries that expect a single class loader that has
it all, then the former approach makes everybody's life a lot easier.


> - Are there any other dangers to using either method I didn't outline above?

Here I agree with Richard, both ways work well, but there is no "one
size fits all" approach. You can mix and match both approaches as
needed.


>  - Any other options?

When we go for the later approach, we try to keep everything into two
types of bundles. (1) Bundles that just expose the interface to a
service, and (2) bundles that export as few packages as possible and
all the services definitions are declared thru DS (and, if possible,
we export no package and only import the definition from the services
we want to expose)

Just to be clear, we do know that this approach does use more memory,
does not allow for class loader short circuits and the class loader
has to work more (once).

Regards,
  Lucas


>
> Thanks
>
>
> --
> David Gonzalez
> Sent with Sparrow (http://www.sparrowmailapp.com/?sig)
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org

Re: Exposing/Including dependencies to/in Bundles

["Richard S. Hall" <he...@ungoverned.org>]

On 2/27/12 14:45 , David G. wrote:
> Quick question about including/exposing dependencies for bundles running under felix.
>
> As I understand it, there are predominantly 2 ways of exposing 3rd party libs for use in our bundle:
>
> 1) Include the 3rd party jar files in the bundle's /lib folder - which exposes all packages of the jar(s) to the code in the bundle.

Essentially, but there's no such think as a bundle's "/lib" folder, you 
just simply embed the JARs into the bundle JAR file and then mention 
them on the Bundle-ClassPath header (along with "." if you still need 
access to the rest of the bundle's content directly).

> 2) Package the 3rd party jar/jars as an OSGi bundle, exporting the requisite packages in the bnd by way of the manifest.
>
> I seems like the first strategy encourages potential for future conflicts (if another bundle exports the same packages) but reduces the dependencies for the bundle, since its self-contained.

If the internal third-party JARs are only used internally by the bundle 
and are not exported, then it doesn't really cause future conflict. If 
you are exporting them, then you would likely want to import and export 
them to allow the resolver to substitute them in the future when more 
providers are present (check the FAQ on importing and exporting packages 
if you aren't familiar with it).

>
> The second strategy allows for reusability of code (all bundles that need 3rd party library X can get the dependencies for the same bundle) however this adds extra dependencies to the bundle deployment lifecycle (you may have ensure that when Bundle A is deployed, there is process in place to deploy 3rd party bundles X, Y and Z).
>
>   - Thoughts around when to use one over the other?
>
> - Are there any other dangers to using either method I didn't outline above?
>
>   - Any other options?

I'd always do the second if at all possible. It presents the simplest 
overall management, from my point of view. If you are very diligent you 
can get either approach to work, but the second approach requires less 
diligence.

-> richard

>
> Thanks
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org