[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [riena-dev] Interface not visible from class loader!
|
Am 30.03.2009 um 21:07 schrieb Scott Lewis:
Hi Christian,
Christian Campo wrote:
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.
You are right that Dynamic-ImportPackage can be relatively slow, but
compared to the deserialization and i/o in most environments it's not
going to be a problem.
Sure ? I read that in an article about Hibernate that Buddy-Policies
can be slow. Since databases also have some IO, I think they wouldnt
have mentioned that if that wasn't an issue. Also note that the
classloader visits the Buddy-Policy not once but for every little
class it finds. So in a large object net that can be several. (any 2
to 3 diget number of classes). What happens on a subsequent call ?
Probably the classloader knows the class and doesnt do the thing again.
but thanks for the input. I know BuddyPolicies are not ideal but they
are currently the best way to handle this problem I know.
Buddy policies can be used, but they have their own
disadvantages...for
example with some VMs it has been possible to get deadlocks. Also,
they
only work with Equinox (i.e. they are not OSGi but rather Equinox
specific)...and except for the global policy there can/will be
dependency issues (for example, having interface plugins (used to
create
proxies) depend upon part/parts of Riena).
Equinox specific right ! Yes interface and parameter, return value
plugins will be dependant on Riena parts. Thats their way of telling
that it is ok to instantiate their classes. I find that a good
documentation for dependency graphs. Shouldnt be an issue though. But
I agree that their are different tastes about using the various OSGi/
Equinox keywords and semantics.
Scott
christian
_______________________________________________
riena-dev mailing list
riena-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/riena-dev
