----- Original message ----- > I am not saying OSGI is prevented. I am saying OSGI class loading model > _could_ be used to fix class loading issues. Because current River class > loading is simply broken. > > If you look at my example - the Wrapper service is simple and sharing > only Wrapper interface with its client. And still it is not possible to > use it!!!
PreferredClassLoader may not be the right tool for more complex class relationships. > > As per fixing security - may I ask how it is going to be accomplished? > By initially placing limitations on deserialisation until trust is established. These are: 1. Place a limit of the size of the stream, avoids DOS. 2. Before using / loading any class during deserialisation, check it is trusted, against a list of trusted classes, this also means avoiding any codebase downloads. 3. After trust is established, remove restrictions. To do this may require a buffer, where a stream is inspected prior to deserialisation, but where we are looking for a ProxyTrustVerifier proxy in the stream, after authenticating the proxy, we then ask that proxy for a list of classes it trusts to be deserialised, and we add these to the trusted class list. Any classes that appear in the stream that aren't trusted aren't deserialised. Following deserialisation the ProxyTrustVerifier proxy can then be asked to verify the smart proxy and if verified, deserialisation restrictions can be lifted, any constraints will remain in place. Presently I'm working on fixing race conditions and visibility bugs, SDM is proving quite challenging. > Also... Could you elaborate more on code dynamically generated at the > server and how does it differ from code downloading? Bytecode for lambda expressions is generated at runtime by the jvm, lambda's use a single serialization proxy class, necessary implementation bytecode is dynamically compiled upon deserialisation. How lambdas change > anything (since lambdas are only Java _language_ level constructs I > really don't see how). Dynamically compiled code doesn't need a codebase annotation, it's created as needed and it's visibility is correct for each use case, it's very specific, implementing a public interface and interacting through this. > > The solution to class loading issues is really simple... Use class > loading model that is good enough :-) - hierarchical is not. > > I am actually thinking about jboss-modules library. From their website: > "It implements a thread-safe, fast, and highly concurrent delegating > class loader model, coupled to an extensible module resolution system, > which combine to form a unique, simple and powerful system for > application execution and distribution." Looks interesting, appears to be AL2 licensed? > > Regards, > > On Thursday, March 06, 2014 07:56:13 PM Peter wrote: > > River doesn't prevent using OSGi, in fact, we are making changes to > > enable it, we also want to support Maven, but we don't currently > > mandate using either. > > > > I'd reccomment keeping services simple and ensure you only share common > > public interfaces and classes (service api) and ensure these shared > > classes are installed locally on your clients. > > > > As for security that will be fixed in a following release and we are > > making steps towards that. > > > > Even for OSGi, without River, deserialisation is complex beast. > > > > With Java 8, we'll be looking at lambda based services where code is > > dynamically generated at the server, it's an inversion of control that > > will allow much more flexibility. In fact I'd reccommend avoiding > > downloaded code, if it can be avoided, or at least keep it simple and > > ensure all shared classes are installed locally. > > > > If you have a solution to ClassLoader issues, I'm all ears, honestly > > though, ClassLoaders are a Java issue, we do our best to work around > > them, I'm not aware of a silver bullet. Beware of complex ClassLoader > > relationships, as these can lead to deadlock. > > > > Cheers, > > > > Peter. > > > > -- > Michał Kłeczek > XPro Sp. z o. o. > ul. Borowskiego 2 > 03-475 Warszawa > Polska <Attachment> Michał Kłeczek (XPro).vcf
