You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Vinicius Carvalho <vi...@caravelatech.com> on 2009/01/19 14:56:46 UTC
Import/Export design question
Hello there! I've got Hall's book, and even after reading section 2.4.3
where he explains why would one need to import and export a package I'm
still a bit confused.
A good explanation provided by him was " (...)common situation when
importing and exporting is useful is
when using an interface-based development approach. (...)" Well, this is
just my case :)
We are building an open source governance tool (we already have the product
on a locked non osgi architecture, we are just migrating and opening it to
the community), well we have several parsers (Java, COBOL, C#, C++, PHP ...)
and we would like to have our parsers to be implemented as bundles. So I
guess I'll have an interface: org.openspotlight.parsers.Parser which each
bundle must implement, so let's suppose I have two bundles (java and cobol)
I would export this packages:
Export-Package: org.openspotlight.parsers.java
.
.
.
Export-Package: org.openspotlight.parsers.cobol
Why would I need to add an import-package statement to my manifest as well?
Would it be a problem if I do not? Also We intend to use the parsers as
services, so on each bundle we add an activator to register the given
implementation using the general interface, I guess this is ok as well
right?
Best regards
Re: Import/Export design question
Posted by Vinicius Carvalho <vi...@caravelatech.com>.
Richard thanks very much, very very clear now :) This covers everything we
needed thanks.
PS: Just to share, we might use first approach since we have some bundles
that are "system bundles" and there's no way the product shall work without
them. The Parser API is one of those.
Regards
On Mon, Jan 19, 2009 at 5:53 PM, Richard S. Hall <he...@ungoverned.org>wrote:
> So, as I understand the situation you are describing, we have the following
> packages (abbreviated to save typing):
>
> * parsers - containing the Parser interface.
> * parsers.java - containing the Java Parser implementation.
> * parsers.cobol - containing the COBOL Parser implementation.
>
> We can package this up in four ways:
>
> 1. Three inter-dependent bundles:
> 1. Bundle A containing and exporting parsers.
> 2. Bundle B containing Java impl and importing parsers from A.
> 3. Bundle C containing COBOL impl and importing parsers from A.
> 2. Two inter-dependent bundles (the bundle exporting parsers could be
> reversed):
> 1. Bundle A containing parsers and Java impl and exporting parsers.
> 2. Bundle B containing COBOL impl and importing parsers from A.
> 3. Two self-contained bundles:
> 1. Bundle A containing parsers and Java impl and exporting parsers.
> 2. Bundle B containing parsers and COBOL impl and exporting
> parsers.
> 4. Two self-contained, but potentially inter-dependent bundles:
> 1. Bundle A containing parsers and Java impl and
> exporting/importing parsers.
> 2. Bundle B containing parsers and COBOL impl and
> exporting/import parsers.
>
> (Note: Below you mention something about exporting parsers.java and/or
> parsers.cobol, but you should not need to export these since they are
> implementations of the well-known parsers.Parser API, so all collaboration
> should be through the public API.)
>
> Given these four options, approach (1) is the most intuitive. The downside
> of approach (1) is that no implementations are ever self-contained, you
> always need to deploy multiple bundles to get your implementation to work.
>
> Approach (2) is a variant of approach one where we make one of our impls
> self-contained, while the other one is not. This solution is not very good
> since it is asymmetric and the second bundle still requires the other impl
> to be present just to get the parsers package.
>
> Approach (3) looks good at first blush, since both impls are
> self-contained. However, there is an issue in this approach. Since both
> bundles ONLY export parsers, their respective impls are using their own
> copies of the parsers.Parser class. As a result, if both are deployed at the
> same time, then clients will only be able to see one or the other impl, but
> not both, since a client cannot see two copies of the same class at the same
> time.
>
> This leads to approach (4), which solves the issue in approach (3) by not
> only exporting the parsers package, but also importing it. Now both A and B
> are self-contained, so if they are deployed independently, they will work
> without needing any other bundles. However, if they are deployed at the same
> time, the OSGi framework will choose one copy of the parsers package and
> wire the other bundle to the selected package. Now a client will be
> compatible with both impls, since there is only one copy of the parsers
> package in use.
>
> Importing and exporting the same package is not necessary at all if you are
> following approach (1), where you package your public API in a separate
> bundle. It is generally only useful when you package your public
> interface-based API with an implementation of it.
>
> These are just rules of thumb, though. The ultimate rule to consider when
> exporting a package is, do you expect that someone else may also export the
> package and you might want to substitute their export for yours (typically
> because you want class space compatibility). If so, then you should also
> import your export. If not, then you should only export.
>
> -> richard
>
>
> Vinicius Carvalho wrote:
>
>> Hello there! I've got Hall's book, and even after reading section 2.4.3
>> where he explains why would one need to import and export a package I'm
>> still a bit confused.
>>
>> A good explanation provided by him was " (...)common situation when
>> importing and exporting is useful is
>> when using an interface-based development approach. (...)" Well, this is
>> just my case :)
>>
>> We are building an open source governance tool (we already have the
>> product
>> on a locked non osgi architecture, we are just migrating and opening it to
>> the community), well we have several parsers (Java, COBOL, C#, C++, PHP
>> ...)
>> and we would like to have our parsers to be implemented as bundles. So I
>> guess I'll have an interface: org.openspotlight.parsers.Parser which each
>> bundle must implement, so let's suppose I have two bundles (java and
>> cobol)
>> I would export this packages:
>>
>> Export-Package: org.openspotlight.parsers.java
>> .
>> .
>> .
>> Export-Package: org.openspotlight.parsers.cobol
>>
>>
>> Why would I need to add an import-package statement to my manifest as
>> well?
>> Would it be a problem if I do not? Also We intend to use the parsers as
>> services, so on each bundle we add an activator to register the given
>> implementation using the general interface, I guess this is ok as well
>> right?
>>
>> Best regards
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Re: Import/Export design question
Posted by "Richard S. Hall" <he...@ungoverned.org>.
So, as I understand the situation you are describing, we have the
following packages (abbreviated to save typing):
* parsers - containing the Parser interface.
* parsers.java - containing the Java Parser implementation.
* parsers.cobol - containing the COBOL Parser implementation.
We can package this up in four ways:
1. Three inter-dependent bundles:
1. Bundle A containing and exporting parsers.
2. Bundle B containing Java impl and importing parsers from A.
3. Bundle C containing COBOL impl and importing parsers from A.
2. Two inter-dependent bundles (the bundle exporting parsers could be
reversed):
1. Bundle A containing parsers and Java impl and exporting parsers.
2. Bundle B containing COBOL impl and importing parsers from A.
3. Two self-contained bundles:
1. Bundle A containing parsers and Java impl and exporting parsers.
2. Bundle B containing parsers and COBOL impl and exporting
parsers.
4. Two self-contained, but potentially inter-dependent bundles:
1. Bundle A containing parsers and Java impl and
exporting/importing parsers.
2. Bundle B containing parsers and COBOL impl and
exporting/import parsers.
(Note: Below you mention something about exporting parsers.java and/or
parsers.cobol, but you should not need to export these since they are
implementations of the well-known parsers.Parser API, so all
collaboration should be through the public API.)
Given these four options, approach (1) is the most intuitive. The
downside of approach (1) is that no implementations are ever
self-contained, you always need to deploy multiple bundles to get your
implementation to work.
Approach (2) is a variant of approach one where we make one of our impls
self-contained, while the other one is not. This solution is not very
good since it is asymmetric and the second bundle still requires the
other impl to be present just to get the parsers package.
Approach (3) looks good at first blush, since both impls are
self-contained. However, there is an issue in this approach. Since both
bundles ONLY export parsers, their respective impls are using their own
copies of the parsers.Parser class. As a result, if both are deployed at
the same time, then clients will only be able to see one or the other
impl, but not both, since a client cannot see two copies of the same
class at the same time.
This leads to approach (4), which solves the issue in approach (3) by
not only exporting the parsers package, but also importing it. Now both
A and B are self-contained, so if they are deployed independently, they
will work without needing any other bundles. However, if they are
deployed at the same time, the OSGi framework will choose one copy of
the parsers package and wire the other bundle to the selected package.
Now a client will be compatible with both impls, since there is only one
copy of the parsers package in use.
Importing and exporting the same package is not necessary at all if you
are following approach (1), where you package your public API in a
separate bundle. It is generally only useful when you package your
public interface-based API with an implementation of it.
These are just rules of thumb, though. The ultimate rule to consider
when exporting a package is, do you expect that someone else may also
export the package and you might want to substitute their export for
yours (typically because you want class space compatibility). If so,
then you should also import your export. If not, then you should only
export.
-> richard
Vinicius Carvalho wrote:
> Hello there! I've got Hall's book, and even after reading section 2.4.3
> where he explains why would one need to import and export a package I'm
> still a bit confused.
>
> A good explanation provided by him was " (...)common situation when
> importing and exporting is useful is
> when using an interface-based development approach. (...)" Well, this is
> just my case :)
>
> We are building an open source governance tool (we already have the product
> on a locked non osgi architecture, we are just migrating and opening it to
> the community), well we have several parsers (Java, COBOL, C#, C++, PHP ...)
> and we would like to have our parsers to be implemented as bundles. So I
> guess I'll have an interface: org.openspotlight.parsers.Parser which each
> bundle must implement, so let's suppose I have two bundles (java and cobol)
> I would export this packages:
>
> Export-Package: org.openspotlight.parsers.java
> .
> .
> .
> Export-Package: org.openspotlight.parsers.cobol
>
>
> Why would I need to add an import-package statement to my manifest as well?
> Would it be a problem if I do not? Also We intend to use the parsers as
> services, so on each bundle we add an activator to register the given
> implementation using the general interface, I guess this is ok as well
> right?
>
> Best regards
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org