I had talked about this issue with the Equinox team with regards to this
bug:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=326918
It is my understanding that Equinox has a similar set of rules as the
Felix framework. I know for a fact that they do not simply return true
for the existence of any ServiceFactory; that is not a viable solution.
I also know that the ECF guys ran into this same issue (with Equinox)
and that they solved it by introducing a separate proxy bundle under
which they'd register their service factories.
However, if you can boil down a simple example test case to reproduce
the issue, I'll gladly take a look at it and see if there is any
refinement in the rules that might help; although, in all honesty I
don't see how...even the "extender" exception is actually bogus since it
opens up the possibility of false positives.
-> 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
