Felix Meschberger wrote:
Nevertheless it looks better to me to find a method with the interface
class known to the consumer (Component C) and get a ClassCastException
in case the Class objects would not match than to no be able to find the
bind method due to incompatible class objects.
Ag
Hi,
THe point is actually, that in an OSGi framework multiple bundles might
be exporting the same package, yet with different versions. The Bundle A
with Component C referring to service interface I (interface exported by
Bundles B and D) might use a different interface class object than the
Felix Meschberger wrote:
Right, this should work as the framework should already guarantee that
the class object used by the service and the class object used by the
abstract class with the bind methods are the same.
Nevertheless, I would think, that using the class loader from
Class.getCla
Hi,
Carsten Ziegeler schrieb:
Stuart McCulloch wrote:
looking at the current code that trawls the super-classes, I believe the
problem could be solved by changing 'DependencyManager.java:734'
so a ClassNotFoundException will drop down to the exhaustive search
of declared methods (this code wou
Stuart McCulloch wrote:
looking at the current code that trawls the super-classes, I believe the
problem could be solved by changing 'DependencyManager.java:734'
so a ClassNotFoundException will drop down to the exhaustive search
of declared methods (this code would need to be refactored out, so
Richard S. Hall wrote:
It probably makes sense to change this in some fashion. We have the same
issue inside the framework when we are trying to figure out how if a
class is visible to a given bundle (in Util.loadClassUsingClass()). So,
it makes sense that SCR might have to do something simil
2008/7/7 Carsten Ziegeler <[EMAIL PROTECTED]>:
> Stuart McCulloch wrote:
>
>>
>> imho SCR should be using the classloader of the class that declared the
>> bind/unbind method, ie:
>>
>> method.getDeclaringClass().getClassLoader()
>>
>> when loading parameter classes - always using B's classloade
Carsten Ziegeler wrote:
Stuart McCulloch wrote:
imho SCR should be using the classloader of the class that declared the
bind/unbind method, ie:
method.getDeclaringClass().getClassLoader()
when loading parameter classes - always using B's classloader doesn't
sound
right to me
Yes, I agre
Stuart McCulloch wrote:
imho SCR should be using the classloader of the class that declared the
bind/unbind method, ie:
method.getDeclaringClass().getClassLoader()
when loading parameter classes - always using B's classloader doesn't sound
right to me
Yes, I agree - now, the current implem
2008/7/7 Carsten Ziegeler <[EMAIL PROTECTED]>:
> Hi,
>
> I came across a problem related to class loading in SCR and before trying
> to fix this I would get some feedback if this is really a bug (see
> FELX-624).
>
> Now, the problem is as follows - we have three bundles.
> Bundle C : Provides a s
Hi,
I came across a problem related to class loading in SCR and before
trying to fix this I would get some feedback if this is really a bug
(see FELX-624).
Now, the problem is as follows - we have three bundles.
Bundle C : Provides a service for SERVICE_X which is registered through SCR.
Bun
11 matches
Mail list logo
