river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter <j...@zeus.net.au>
Subject Re: River-436 - need some explanation of preferred class provider
Date Tue, 04 Mar 2014 01:28:58 GMT
----- Original message -----
> The Util interface should not be preferred.   Implementations of Util can
> be preferred but not Util itself.
> 
> Services need a common api that all implementations and clients can use
> to interract, even if this is a kind of codebase service.
> 
> Modifying an interface is generally considered bad practise but now Java
> 8 makes it possible to add default methods for added functionality, that
> line blurs somewhat.   What can you do if an earlier interface is loaded
> by a parent ClassLoader and you need a later version, make it preferred?
> 
> My thoughts are that interfaces should never be preferred and all
> classes defined in their methods shouldn't be preferred either.
> 
> It would be relatively easy to write a new implementation that ensures
> that interfaces are loaded into their own ProtectionDomain in a parent
> ClassLoader.   But that would be confusing as dynamic policy grants are
> made to ClassLoader's not ProtectionDomains.
> 
> But using ProtectionDomains in this manner, preserves security, ensures
> maximum visibility and avoids codebase annotation loss, if we ask the
> ProtectionDomain for the annotation, instead of the ClassLoader.   But
> this is not how we do things presently.
> 

To clarify, codebase annotation loss occurrs where identical classes with different annotations
are loaded into the same ClassLoader.  ProtectionDomains do allow different classes with different
codebase annotations to be loaded into the same ClassLoader.

Service api shouldn't be changed after deployment.  So if it didn't exist locally, it would
be safe from a security perspective to load it into its own ProtectionDomain in the application
ClassLoader for maximum visibility and interoperability, rather than the proxy's child ClassLoader.

> Cheers,
> 
> Peter.
> 
> ----- Original message -----
> > But it will also be loaded by WrapperProxy ClassLoader, since it is
> > preferred there. So it will end up with ClassCastException, right?
> > 
> > Regards,
> > Michal
> > 
> > If Util is installed locally, it will only be loaded by the application
> > ClassLoader, since it isn't preferred.
> > 
> > Peter.
> > 
> > ----- Original message -----
> > > Folks,
> > > while woking on the River-436 patch proposal I've came across the
> > > scenario that I am not sure how to handle:
> > > 
> > > Utility service:
> > > //inteface is NOT preferred
> > > interface Util {...}
> > > //class IS preferred
> > > class UtilProxy implements Util {}
> > > 
> > > Wrapper service:
> > > //NOT preferred
> > > interface Wrapper {}
> > > //preferred
> > > class WrapperProxy implements Serializable{
> > > //initialized with Util impl from a lookup service
> > > private Util util;
> > > }
> > > 
> > > Wrapper service codebase includes Util interface but it is
> > > _preferred_.
> > > 
> > > Would deserialization of WrapperProxy end with ClassCastException?
> > > From what I understand UtilProxy is annotated with its codebase. When
> > > deserializing UtilProxy a ClassLoader is going to be created with
> > > parent set to TCCL. It means Util interface is going to be loaded
> > > twice by two ClassLoaders - one for WrapperProxy codebase and another
> > > for UtilProxy codebase.
> > > 
> > > Am I correct?
> > > And if so: is it desired behavior?
> > > 
> > > Regards,
> > > 
> > > --
> > > Michał Kłeczek
> > > XPro Quality Matters
> > > http://www.xpro.biz
> > > 
> 


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message