You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by "Geir Magnusson Jr." <ge...@pobox.com> on 2008/09/03 05:45:45 UTC
noob question about imports
The odds are I'm doing things incorrectly, but I'm having so much fun,
I can't really help myself. Forgive any mistakes in jargon - I'm
fairly new to this.
I have a bundle A and a bundle B.
After A is installed and started, at some future time, it may itself
install and start B which on activation, registers a service S, the
package in which S is implemented is listed as an Export-Package in
B's manifest.
It seems to be that Felix wants A to list that same package as an
Import-Package in A's manifest or else I seem to get a
ClassCastException. However, given the lack of B at the time of A's
installation and starting, the Import-Package isn't getting satisfied.
How do I get myself out of this?
TIA
geir
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: noob question about imports
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Geir Magnusson Jr. wrote:
>
> On Sep 3, 2008, at 9:14 AM, Richard S. Hall wrote:
>
>> When you have public API and if you want to guarantee that your
>> client dependencies resolve, you can include that API in your bundle
>> then both import AND export it. Likewise in your service
>> implementation, you can contain the public API and import AND export
>> it. When the framework resolves dependencies, it will try to resolve
>> the import first, rather than using the export, that way it will
>> avoid creating new class spaces. Check out our OSGi FAQ for some
>> discussion on this topic:
>>
>> http://cwiki.apache.org/FELIX/apache-felix-osgi-faq.html
>>
>> There is no single answer to this situation, it just depends. You
>> have to decide what works best for you with respect to your
>> modularity needs.
>
> Seems kind of yecchy to have to include the API (the interface of the
> service) in the bundle that uses it. I assume I could just add a
> third bundle to the mix, on that contains my service interfaces? and
> have both A and B reference it ?
Yeah, I can understand why this may be odd coming from a standard Java
approach, but in OSGi this is not so uncommon and the framework worries
about the details for you. This was (is?) the recommended packaging
approach for bundles in the spec. But, as Stuart says, you are free to
play around and use the approach that feels the least yucky to you.
Our OSGi FAQ goes over the packaging options too.
-> richard
>
> geir
>
>>
>>
>> -> richard
>>
>>>
>>> Thanks again.
>>>
>>> geir
>>>
>>>>
>>>>
>>>> Thanks,
>>>> Sahoo
>>>>
>>>> Geir Magnusson Jr. wrote:
>>>>> The odds are I'm doing things incorrectly, but I'm having so much
>>>>> fun, I can't really help myself. Forgive any mistakes in jargon -
>>>>> I'm fairly new to this.
>>>>>
>>>>> I have a bundle A and a bundle B.
>>>>>
>>>>> After A is installed and started, at some future time, it may
>>>>> itself install and start B which on activation, registers a
>>>>> service S, the package in which S is implemented is listed as an
>>>>> Export-Package in B's manifest.
>>>>>
>>>>> It seems to be that Felix wants A to list that same package as an
>>>>> Import-Package in A's manifest or else I seem to get a
>>>>> ClassCastException. However, given the lack of B at the time of
>>>>> A's installation and starting, the Import-Package isn't getting
>>>>> satisfied.
>>>>>
>>>>> How do I get myself out of this?
>>>>>
>>>>> TIA
>>>>>
>>>>> geir
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>
>
> ---------------------------------------------------------------------
> 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: noob question about imports
Posted by Stuart McCulloch <mc...@gmail.com>.
2008/9/3 Geir Magnusson Jr. <ge...@pobox.com>
>
> On Sep 3, 2008, at 9:14 AM, Richard S. Hall wrote:
>
> Geir Magnusson Jr. wrote:
>>
>>>
>>> On Sep 3, 2008, at 12:10 AM, Sahoo wrote:
>>>
>>>
>>>> 1. Package the interface in A or in some other bundle C. If you chose
>>>> bundle C, then let A import that package.
>>>> 2. Package the service impl in B. Let B import the interface.
>>>>
>>>> OR
>>>>
>>>> 1. Package the service interface and implementation as part of B. Export
>>>> only the interface package from B.
>>>> 2. Add a DynamicImport-Package for the service interface package in A's
>>>> header. This would work as long as A does not refer to the interface before
>>>> B is installed.
>>>>
>>>
>>> This makes the most sense to me for some reason, although I don't have a
>>> strong argument why - it just feels better to have the interface *not* in A,
>>> and I'm to lazy to want to worry about a C )
>>>
>>
>> This is the main different between optional versus dynamic, dynamic will
>> continually attempt to create a wire to the package at run-time. However,
>> this is not intended as a general approach. It is really intended for
>> SPI-like situations where you do not know the package. Although, it is
>> reasonably safe to do this if you do know the precise package. It is a very
>> bad thing to dynamically import "*".
>>
>
> Got it.
>
>
>>
>> When you have public API and if you want to guarantee that your client
>> dependencies resolve, you can include that API in your bundle then both
>> import AND export it. Likewise in your service implementation, you can
>> contain the public API and import AND export it. When the framework resolves
>> dependencies, it will try to resolve the import first, rather than using the
>> export, that way it will avoid creating new class spaces. Check out our OSGi
>> FAQ for some discussion on this topic:
>>
>> http://cwiki.apache.org/FELIX/apache-felix-osgi-faq.html
>>
>> There is no single answer to this situation, it just depends. You have to
>> decide what works best for you with respect to your modularity needs.
>>
>
> Seems kind of yecchy to have to include the API (the interface of the
> service) in the bundle that uses it. I assume I could just add a third
> bundle to the mix, on that contains my service interfaces? and have both A
> and B reference it ?
>
yes, that would be the bundle C that Sahoo was talking about earlier
it's a trade off - you can either package the API in the same bundle,
which means one less bundle to manage - or you can push it into a
separate API bundle, and avoid duplicating content
some people prefer to include any required APIs, especially when they
want others to take their bundle and drop it onto a framework without
having to dig around for the various API bundles
other people like fine-grained bundles, as it gives them more flexibility
the benefit of OSGi is you can try out various approaches to slicing
a project into bundles and your assembled application will (usually!)
still work - and tools like BND make it easy to re-slice at any time...
FYI, there was an interesting thread on the osgi-dev list in June
titled "Put API/SPI/implementation into separate bundles?" which
discussed various approaches
[ https://mail.osgi.org/pipermail/osgi-dev/2008-June/thread.html ]
geir
--
Cheers, Stuart
Re: noob question about imports
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Sep 3, 2008, at 9:14 AM, Richard S. Hall wrote:
> Geir Magnusson Jr. wrote:
>>
>> On Sep 3, 2008, at 12:10 AM, Sahoo wrote:
>>
>>>
>>> 1. Package the interface in A or in some other bundle C. If you
>>> chose bundle C, then let A import that package.
>>> 2. Package the service impl in B. Let B import the interface.
>>>
>>> OR
>>>
>>> 1. Package the service interface and implementation as part of B.
>>> Export only the interface package from B.
>>> 2. Add a DynamicImport-Package for the service interface package
>>> in A's header. This would work as long as A does not refer to the
>>> interface before B is installed.
>>
>> This makes the most sense to me for some reason, although I don't
>> have a strong argument why - it just feels better to have the
>> interface *not* in A, and I'm to lazy to want to worry about a C )
>
> This is the main different between optional versus dynamic, dynamic
> will continually attempt to create a wire to the package at run-
> time. However, this is not intended as a general approach. It is
> really intended for SPI-like situations where you do not know the
> package. Although, it is reasonably safe to do this if you do know
> the precise package. It is a very bad thing to dynamically import "*".
Got it.
>
>
> When you have public API and if you want to guarantee that your
> client dependencies resolve, you can include that API in your bundle
> then both import AND export it. Likewise in your service
> implementation, you can contain the public API and import AND export
> it. When the framework resolves dependencies, it will try to resolve
> the import first, rather than using the export, that way it will
> avoid creating new class spaces. Check out our OSGi FAQ for some
> discussion on this topic:
>
> http://cwiki.apache.org/FELIX/apache-felix-osgi-faq.html
>
> There is no single answer to this situation, it just depends. You
> have to decide what works best for you with respect to your
> modularity needs.
Seems kind of yecchy to have to include the API (the interface of the
service) in the bundle that uses it. I assume I could just add a
third bundle to the mix, on that contains my service interfaces? and
have both A and B reference it ?
geir
>
>
> -> richard
>
>>
>> Thanks again.
>>
>> geir
>>
>>>
>>>
>>> Thanks,
>>> Sahoo
>>>
>>> Geir Magnusson Jr. wrote:
>>>> The odds are I'm doing things incorrectly, but I'm having so much
>>>> fun, I can't really help myself. Forgive any mistakes in jargon
>>>> - I'm fairly new to this.
>>>>
>>>> I have a bundle A and a bundle B.
>>>>
>>>> After A is installed and started, at some future time, it may
>>>> itself install and start B which on activation, registers a
>>>> service S, the package in which S is implemented is listed as an
>>>> Export-Package in B's manifest.
>>>>
>>>> It seems to be that Felix wants A to list that same package as an
>>>> Import-Package in A's manifest or else I seem to get a
>>>> ClassCastException. However, given the lack of B at the time of
>>>> A's installation and starting, the Import-Package isn't getting
>>>> satisfied.
>>>>
>>>> How do I get myself out of this?
>>>>
>>>> TIA
>>>>
>>>> geir
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: noob question about imports
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Geir Magnusson Jr. wrote:
> Thanks for the response. Inline.
>
> On Sep 3, 2008, at 12:10 AM, Sahoo wrote:
>
>> Looks like the class is duplicated in two bundles. Which bundle
>> contains the service interface class? Here are a couple of ways of
>> doing things:
>
> Yes, that's what I found. (I also was using the R3 manifest version,
> so that had me scratching my head when trying to the
> resolution:=optional thing to get the import, but that seems (from
> your note) to be a red-herring. (But I did learn about R3 vs R4
> manifests, so that's useful...)
Definitely, an optional import will not work here since it will never
get wired to the package after its starts. More below...
>> 1. Package the interface in A or in some other bundle C. If you chose
>> bundle C, then let A import that package.
>> 2. Package the service impl in B. Let B import the interface.
>>
>> OR
>>
>> 1. Package the service interface and implementation as part of B.
>> Export only the interface package from B.
>> 2. Add a DynamicImport-Package for the service interface package in
>> A's header. This would work as long as A does not refer to the
>> interface before B is installed.
>
> This makes the most sense to me for some reason, although I don't have
> a strong argument why - it just feels better to have the interface
> *not* in A, and I'm to lazy to want to worry about a C )
This is the main different between optional versus dynamic, dynamic will
continually attempt to create a wire to the package at run-time.
However, this is not intended as a general approach. It is really
intended for SPI-like situations where you do not know the package.
Although, it is reasonably safe to do this if you do know the precise
package. It is a very bad thing to dynamically import "*".
When you have public API and if you want to guarantee that your client
dependencies resolve, you can include that API in your bundle then both
import AND export it. Likewise in your service implementation, you can
contain the public API and import AND export it. When the framework
resolves dependencies, it will try to resolve the import first, rather
than using the export, that way it will avoid creating new class spaces.
Check out our OSGi FAQ for some discussion on this topic:
http://cwiki.apache.org/FELIX/apache-felix-osgi-faq.html
There is no single answer to this situation, it just depends. You have
to decide what works best for you with respect to your modularity needs.
-> richard
>
> Thanks again.
>
> geir
>
>>
>>
>> Thanks,
>> Sahoo
>>
>> Geir Magnusson Jr. wrote:
>>> The odds are I'm doing things incorrectly, but I'm having so much
>>> fun, I can't really help myself. Forgive any mistakes in jargon -
>>> I'm fairly new to this.
>>>
>>> I have a bundle A and a bundle B.
>>>
>>> After A is installed and started, at some future time, it may itself
>>> install and start B which on activation, registers a service S, the
>>> package in which S is implemented is listed as an Export-Package in
>>> B's manifest.
>>>
>>> It seems to be that Felix wants A to list that same package as an
>>> Import-Package in A's manifest or else I seem to get a
>>> ClassCastException. However, given the lack of B at the time of A's
>>> installation and starting, the Import-Package isn't getting satisfied.
>>>
>>> How do I get myself out of this?
>>>
>>> TIA
>>>
>>> geir
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>
>
> ---------------------------------------------------------------------
> 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: noob question about imports
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Thanks for the response. Inline.
On Sep 3, 2008, at 12:10 AM, Sahoo wrote:
> Looks like the class is duplicated in two bundles. Which bundle
> contains the service interface class? Here are a couple of ways of
> doing things:
Yes, that's what I found. (I also was using the R3 manifest version,
so that had me scratching my head when trying to the
resolution:=optional thing to get the import, but that seems (from
your note) to be a red-herring. (But I did learn about R3 vs R4
manifests, so that's useful...)
>
>
> 1. Package the interface in A or in some other bundle C. If you
> chose bundle C, then let A import that package.
> 2. Package the service impl in B. Let B import the interface.
>
> OR
>
> 1. Package the service interface and implementation as part of B.
> Export only the interface package from B.
> 2. Add a DynamicImport-Package for the service interface package in
> A's header. This would work as long as A does not refer to the
> interface before B is installed.
This makes the most sense to me for some reason, although I don't have
a strong argument why - it just feels better to have the interface
*not* in A, and I'm to lazy to want to worry about a C )
Thanks again.
geir
>
>
> Thanks,
> Sahoo
>
> Geir Magnusson Jr. wrote:
>> The odds are I'm doing things incorrectly, but I'm having so much
>> fun, I can't really help myself. Forgive any mistakes in jargon -
>> I'm fairly new to this.
>>
>> I have a bundle A and a bundle B.
>>
>> After A is installed and started, at some future time, it may
>> itself install and start B which on activation, registers a service
>> S, the package in which S is implemented is listed as an Export-
>> Package in B's manifest.
>>
>> It seems to be that Felix wants A to list that same package as an
>> Import-Package in A's manifest or else I seem to get a
>> ClassCastException. However, given the lack of B at the time of
>> A's installation and starting, the Import-Package isn't getting
>> satisfied.
>>
>> How do I get myself out of this?
>>
>> TIA
>>
>> geir
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: noob question about imports
Posted by Sahoo <Sa...@Sun.COM>.
Looks like the class is duplicated in two bundles. Which bundle contains
the service interface class? Here are a couple of ways of doing things:
1. Package the interface in A or in some other bundle C. If you chose
bundle C, then let A import that package.
2. Package the service impl in B. Let B import the interface.
OR
1. Package the service interface and implementation as part of B. Export
only the interface package from B.
2. Add a DynamicImport-Package for the service interface package in A's
header. This would work as long as A does not refer to the interface
before B is installed.
Thanks,
Sahoo
Geir Magnusson Jr. wrote:
> The odds are I'm doing things incorrectly, but I'm having so much fun,
> I can't really help myself. Forgive any mistakes in jargon - I'm
> fairly new to this.
>
> I have a bundle A and a bundle B.
>
> After A is installed and started, at some future time, it may itself
> install and start B which on activation, registers a service S, the
> package in which S is implemented is listed as an Export-Package in
> B's manifest.
>
> It seems to be that Felix wants A to list that same package as an
> Import-Package in A's manifest or else I seem to get a
> ClassCastException. However, given the lack of B at the time of A's
> installation and starting, the Import-Package isn't getting satisfied.
>
> How do I get myself out of this?
>
> TIA
>
> geir
>
>
> ---------------------------------------------------------------------
> 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