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: [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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
