I do not see any problems concerning the static property:
the
static field CLASSCONTEXT will be initialized during the classloading
of RemoteServiceFactoryHessian and the only method that is exposed is
the native getClassContext method of java.lang.SecurityManager.
I am using the call stack, because I don't want to change
the
api of the factories. The best solution would be, if the to
Register.remoteProxy would allow a classloader as parameter. I first
wrapped that call in a try-finally-block to change the context
classloader temporarly, but I think that could lead to other problems.
As a short reminder: initially I stumbled upon the same
exception Yau got: "IllegalArgumentException: Interface not visible
from class loader". Because that exception did not mention anything
about buddy policies, I started debugging and searched for a solution.
If the RemoteServiceFactoryHessian would catch this exception and would
rethrow another IllegalArgumentException with a better error message,
most people would be happy with adding the buddy property.
>>> Christian Campo
<christian.campo@xxxxxxxxxxxx>
31.03.2009 05:50 >>>
Hi Olaf, Scott,
@Olaf,
I think your solution will work, but I am not a big fan of looking at
the call stack. Also your solution confuses me because some variables
like CLASSCONTEXT are static. Are you sure that this solution works
even if multiple threads try to create a proxy at the same time with
different bundles trying to do that ?
Not sure why that is any better than the buddy policy. Also the buddy
policy thing not only deals with the interface itself but also with
all return values or paramters. If they are not in the same package as
the interface they need to be buddy to. Your solution would not help
anymore.
@Scott: While that solution should work I guess, I am afraid that it
makes the system way slower. I have already read somewhere in the
internet that buddy policies are a timing problem. Because they mean
that for every class the classloaded search a large list of bundles.
If it would search all bundles, I believe the result could be even
worse. Since they are not only consulted for the interfaces but
possibly also for return values and parameters, I am not sure that way
is a good idea.
but thanks for the input. I know BuddyPolicies are not ideal but they
are currently the best way to handle this problem I know.
christian
Am 30.03.2009 um 09:40 schrieb Scott Lewis:
> Hi Olaf and Rieners,
>
> Also, you should see the OSGi manifest entry:
>
> Dynamic-ImportPackage: *
>
> What this does is tell the classloader for the bundle that
contains
> this
> markup (e.g. the Riena Hessian bundle I expect) that it should
look
> for
> a class in every exported package within the current runtime. As
long
> as the proxy interface class is exported, the hessian proxy
factory
> code
> would then find it. You can scope it by package if you wish.
>
> Scott
>
>
> Olaf Fricke wrote:
>> Hi Yau, hi Christian,
>>
>> I found another solution for the classloading issue, the does
neither
>> need the buddy definition nor the dependency to
>> org.eclipse.riena.communication.core.
>>
>> To find such a solution, I had to dig into the code that
throws the
>> java.lang.IllegalArgumentException. The reason for that
exception is
>> that the HessianProxyFactory tries to construct a new
>> java.lang.reflect.Proxy instance. Because Hessian does not know
>> better, it gives the current context classloader to to javas
>> reflection classes. That classloader is the ContextFinder of
Equinox.
>> When loading classes, the ContextFinder searches for the first
class
>> of an non-internal bundle on the callstack and delegates the
>> classloading to that bundle. This bundle is the
com.caucho.hessian
>> bundle and that bundle does indeed know nothing about any
concrete
>> service interfaces.
>>
>> My first try for a solution was to give the classloader of the
>> interface class to the rienaHessianProxyFactory (by calling
>> endpoint.getServiceInterfaceClass().getClassLoader(). This
appoach
>> failed too, because Hessian tries to bind the Proxy instance to
>> another interface, too
(com.caucho.hessian.io.HessianRemoteObject).
>> Too make this interface visible to the bundle that contains the
>> service interface, you can add a dependency to
com.cauche.hessian. I
>> tried this and it worked. But that appoach would require that
each
>> api
>> bundle is dependend of hessian, which is no good idea.
>>
>> Instead, I looked for another solution and detected that the
bundle
>> that creates the service proxy (for example
>> org.eclipse.riena.communication.sample.pingpong.client.config)
knows
>> both interfaces, because is has indeed dependencies to
>> com.cauche.hessian and to the service interface. The remaining
task
>> was to find a way to give the classloader of that bundle to the
>> rienaHessianProxyFactory.
>>
>> Therefore I added the following code to the class
>> org
>> .eclipse
>> .riena
>>
.internal.communication.factory.hessian.RemoteServiceFactoryHessian,
>> to be able to get the current execution stack:
>>
>> // copied from org.eclipse.osgi.internal.loader.BundleLoader
>> static final class ClassContext extends SecurityManager {
>> // need to make this method public
>> public Class<?>[] getClassContext() {
>> return super.getClassContext();
>> }
>> }
>>
>> @SuppressWarnings("unchecked")
>> public final static ClassContext CLASS_CONTEXT =
(ClassContext)
>> AccessController.doPrivileged(new PrivilegedAction() {
>> public Object run() {
>> return new ClassContext();
>> }
>> });
>>
>> In the method
>>
RemoteServiceFactoryHessian.createProxy(RemoteServiceDescription
>> endpoint) I replaced the line
>> Object proxy =
>>
rienaHessianProxyFactory.create(endpoint.getServiceInterfaceClass(),
>> uri, classLoader);
>> with the following code:
>> // determine the classloader for the class that called
the
>> factory
>> Class<?>[] classContext =
CLASS_CONTEXT.getClassContext();
>> ClassLoader classLoader =
>> Thread.currentThread().getContextClassLoader();
>> for (int i = 1; i < classContext.length; i++) { //
starting at 1
>> is required due to the inner class
>> Class<?> clazz = classContext[i];
>> if (clazz != null && clazz != this.getClass()
&& clazz !=
>> RemoteServiceFactory.class && clazz !=
ProxyFactory.class) {
>> classLoader = clazz.getClassLoader();
>> break;
>> }
>> }
>>
>> Object proxy =
>>
rienaHessianProxyFactory.create(endpoint.getServiceInterfaceClass(),
>> uri, classLoader);
>> The main idea is to lookup the first class from the callstack
that
>> does not belong to the proxy creation and give the classlaoder
of
>> that
>> class to Hessian.
>>
>> I tried my solution on the PingPong sample and it worked
without the
>> buddy definition and without a dependency from the
pingpong.common
>> bundle to the org.eclipse.riena.communication.core bundle.
>>
>> Best regards,
>> Olaf
>>
>>
>>
------------------------------------------------------------------------
>>
>> _______________________________________________
>> riena-dev mailing list
>>
riena-dev@xxxxxxxxxxx
>>
https://dev.eclipse.org/mailman/listinfo/riena-dev
>>
>
> _______________________________________________
> riena-dev mailing list
>
riena-dev@xxxxxxxxxxx
>
https://dev.eclipse.org/mailman/listinfo/riena-dev
_______________________________________________
riena-dev mailing list
riena-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/riena-dev