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
