Just a follow up after talking with Tom Watson (the Equinox lead), there
is certainly at least one difference between Felix and Equinox in this
area. On Equinox, if the consumer bundle doesn't import or export the
service package, then Equinox will always assume it is compatible (i.e.,
return true). Felix, on the other hand, will actually try to load the
class from the consumer bundle and if it has no access at all (i.e., it
doesn't import, export, or have it in a private package) then it will
true, but if it has access then it requires that the provider have the
same class unless the "extender exception" applies.
So, if it is working under Equinox, is it because you didn't
import/export it in your consumer bundle? Otherwise, it sounds like
Equinox should work the same way as Felix and you'd be required to use a
separate proxy bundle to gain the "extender exception".
-> richard
On 2/3/12 09:38 , Jeremias Maerki wrote:
Ok, I've just modified Framework 3.0.9 with the proposed change below
and suddenly, my code works. I've used 3.0.9 because that's what I'm
currently using in my system. I've tried trunk but that caused the
following upon startup:
org.osgi.framework.BundleException: Exported package names cannot be zero
length.
at
org.apache.felix.framework.util.manifestparser.ManifestParser.normalizeExportClauses(ManifestParser.java:729)
at
org.apache.felix.framework.util.manifestparser.ManifestParser.<init>(ManifestParser.java:191)
at
org.apache.felix.framework.ExtensionManager.<init>(ExtensionManager.java:220)
at org.apache.felix.framework.Felix.<init>(Felix.java:374)
at
org.apache.felix.framework.FrameworkFactory.newFramework(FrameworkFactory.java:28)
at org.apache.karaf.main.Main.launch(Main.java:265)
at org.apache.karaf.main.Main.main(Main.java:426)
But that's a different story.
I've also scaled down my test system so it works with Equinox, and there
it works, too.
On 03.02.2012 15:08:17 Jeremias Maerki wrote:
Thanks for your reply, Richard!
I was thinking about removing the following part of the "if" in the
"case 2" check:
164&& (m_factory.getClass().getClassLoader() instanceof BundleReference)
165&& !((BundleReference) m_factory.getClass()
166 getClassLoader()).getBundle().equals(m_bundle))
Basically:
if (m_factory != null) {
return true;
}
which would mean: rely on the ServiceFactory to produce correct service
objects. I'm sorry about the word "arbitrary". I just couldn't figure
out where that second part of the "if" came from. The comment above the
check talks about extenders which have to be careful about wiring, too.
But if you don't really have a target bundle like an extender you can
only put the generated ServiceFactories in the distribution provider
bundle itself (in my case).
I guess, I'll try the modification myself first, before you dive into
this.
I've tried with Equinox but had so many issues getting my system running
that I haven't further pursued it. I guess I can try to scale down the
test setup and retry. Knopflerfish worked out of the box.
Will report back later...
On 03.02.2012 14:50:07 Richard S. Hall wrote:
On 2/3/12 04:23 , Jeremias Maerki wrote:
Hi everyone,
I'd like to pick up on a discussion that happened in May 2009 on the dev
list: http://felix.markmail.org/thread/tdowmhihje4c4fza
I think I have a related problem. My use case is this: I'm trying to
implement a simple Remote Services implementation and have a
distribution provider that creates service proxies for imported services.
Since the distribution provider has no wires to the various possible API
bundles for the imported services, it has to create ServiceFactories so
it can first load the interface(s) using the caller bundle and provide
it with a proxy for the right interface for the caller.
Now, Felix doesn't return the imported service (the ServiceFactory),
probably because of the check for case 2 in
ServiceRegistrationImpl.isClassAccessible():
http://svn.apache.org/viewvc/felix/trunk/framework/src/main/java/org/apache/felix/framework/ServiceRegistrationImpl.java?view=annotate
That check was introduced in October 2009 (rev 830347).
That check feels a little arbitrary to me. I guess it works for the
extender case where an extender bundle registers a ServiceFactory under
the target bundle's BundleContext. But in the case of Remote Services I
don't have such a target bundle. The only bundle I can register the
ServiceFactories under is the distribution provider itself. But the case
2 check prohibits that. I have a feeling that if I created a "service
contrainer bundle" next to the distribution provider that receives the
ServiceRegistrations for the proxies I could probably circumvent this
check. But that's not elegant.
I've run my code against Knopflerfish to see how it reacts and there my
approach worked just fine.
The Remote Service Admin spec even hints in 122.5.6 Proxying (4.2.
Enterprise) at using a ServiceProxy and that it's responsible for
avoiding ClassCastExceptions. I may have missed something but Felix may
be too restrictive here. Any thoughts?
I doubt that Felix is too restrictive and certainly not arbitrary...in
fact, by the letter of the spec, Felix isn't restrictive enough. The
spec just says something about if they don't have wires, then fail.
We could certainly try to improve the heuristic, but do you have a
specific suggestion? It is already pretty complicated. The framework is
responsible for making sure that bundles do not get class cast
exceptions, so we can't allow false positives.
Did you try this on Equinox?
-> richard
Thanks,
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
