Actually, Distributed could dovetail nicely with a modular service provider, by
decoupling implementation from state, object state can be migrated to alternate
implementations, remotely, or even locally within the same jvm.
Cheers,
Peter.
----- Original message -----
> ----- Original message -----
> > Peter,
> >
> > I must say that Distributable looks really cool - simple and elegant.
>
> It'd be nice to see it catch on!
>
> > The only thing that I would actually remove is setting up an
> > untrusted object security context in
> > SerialReflectionFactory.create(). It is not really needed _iff_ the
> > code you are executing is already trusted :)
>
> I wanted to prevent constructors being used on ClassLoader, Sockets and
> also prevent using private or package private constructors or basically
> creating objects that shouldn't be serialised. The reason is, the
> object that's about to be created has no ProtectionDomian yet on the
> stack. An object can of course perform a PrivilegedAction from within
> its constructor, so this seemed like a reasonable compromise.
>
>
> Cheers,
>
> Peter.
>
> >
> > Regards,
> >
> > On Thursday, March 06, 2014 09:42:50 PM Peter wrote:
> > > Also worth noting is an interface called Distributed, this is an
> > > alternative to Serializable. Underneath the covers it uses
> > > Externalizable, so it's fast, it also uses constructors, so objects
> > > can use final fields and preserve invarients and subclass non
> > > serializable objects without no arg constructors. Internal state of
> > > Distributed objects are not published and objects can evolve freely,
> > > provided they maintain constructor method signatures. In fact, you
> > > can use interfaces, static factory methods and builder objects, so
> > > your Distributed implementation can be package private and be
> > > completely replaced with another implementation even with a totally
> > > different class name, think providers
> > >
> > > Total and complete freedom from Serializable warts, but completely
> > > compatible, leveraging Object Input and Output streams and the entire
> > > existing Serializable infrastructure.
> > >
> > > Combined with remote reflection proxies and lambda based services
> > > with dynamic remote code generation, we'll be on the doorstep of
> > > distributed compute nirvana.
> > >
> > > Downloaded code may soon be irrelevant to distributed computing and
> > > with it versioning and ClassLoader issues.
> > >
> > > Takes a little time to sink in though.
> > >
> > > The next question for those daring enough to ask "Where will the
> > > future take us?"
> > >
> > > Cheers,
> > >
> > > Peter.
> > >
> > > ----- Original message -----
> > >
> > > > 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.
> > > >
> > > > ----- Original message -----
> > > >
> > > > > Greg,
> > > > >
> > > > > I cannot agree more with the statement that mobile code is the
> > > > > cornerstone of River. I do not want to send just "data"
> > > > > (XML/JSON/whatever). I want to exchange _objects_ (data +
> > > > > code - well... in the end it is all data :-) ). And I want
> > > > > it to be _secure_ and ubiquitous. IMHO we should just make it
> > > > > work - because it simply does not work at this moment - as
> > > > > shown in my example.
> > > > >
> > > > > What I'm arguing is that it is not fixable with hierarchical
> > > > > class loading. The problem is that the client simply does
> > > > > not know what should be the "parent" when deserializing
> > > > > objects. Your River-336 patch is not going to change it
> > > > > (while still important since RMIClassLoader dependency is really
> > > > > a PITA).
> > > > >
> > > > > I am not proposing any particular solution at this moment - BUT I
> > > > > would really like the community to have a second look at
> > > > > existing solutions before coming up with yet another one.
> > > > >
> > > > > The requirements - as I see them right now would be:
> > > > >
> > > > > 1. Make it possible to exchange arbitrary object graphs composed
> > > > > of objects which classes are from _different_ codebases.
> > > > > That would make it possible to create smart proxies wrapping
> > > > > other services' smart proxies (which in theory is possible
> > > > > today... but in practice is not)
> > > > >
> > > > > 2. Do not allow yet untrusted code to execute. Ever.
> > > > > It basically means that from security perspective current
> > > > > algorithm: - deserialize an object
> > > > > - ask it for secure proxy
> > > > > - ask the secure proxy for a verifier
> > > > > - verify the original object
> > > > > is just simply wrong :)
> > > > > What's more - if we only allow trusted code to execute then the
> > > > > whole proxy verification problem becomes much simpler - all
> > > > > those complicated UntrustedObjectSecurityContext tricks are
> > > > > no longer necessary - it is enough to just ask an object
> > > > > to verify itself (placing apropriate invocation
> > > > > constraints on it first).
> > > > >
> > > > > The River-436 patch is going to (mostly) solve 2. The only
> > > > > potential holes left are in unicast response parsing where
> > > > > ObjectInputStream is created to read MarshalledInstance
> > > > > from the network - opening possibility of DOS or other
> > > > > attacks exploiting local code vulnerabilities. It is also going
> > > > > to open a possibility to solve 1 because it is going to make
> > > > > class loading algorithms extensible/dynamic.
> > > > >
> > > > > The big question is whether it is possible to fix 1 without
> > > > > imposing any "container" or "class loading scheme" on the
> > > > > client/service implementor.
> > > > >
> > > > > OTOH - while we do not provide any "container" today - we do
> > > > > provide a "platform". There is no way any client can work without
> > > > > having jsk- platform.jar in its classpath and without specifying
> > > > > PreferredClassProvider as RMIClassProvider and configuring
> > > > > httpmd url handler.
> > > > >
> > > > > Regards,
> > > > >
> > > > > On Tuesday, March 04, 2014 08:03:13 PM Gregg Wonderly wrote:
> > > > > > One of the greatest things about Java is serialization and
> > > > > > mobile code! One of the most limiting aspects of any
> > > > > > language is Serialization!
> > > > > >
> > > > > > If you have an interface or data class that two classes need to
> > > > > > access, there is no choice but to have a common parent class
> > > > > > loader. Your client can institute such as class loading scheme
> > > > > > completely independently of Jini’s use of some other class
> > > > > > loading scheme, provided that you at least allow the “parent
> > > > > > load this please” mechanism of hierarchical class loading to
> > > > > > occur.
> > > > > >
> > > > > > My changes to remove the explicit reliance/dependence on
> > > > > > RMIClassLoader in River-336, and instead allow you to plug in
> > > > > > how the “parent load this please” call out to work, is how you
> > > > > > can solve this so that it actually works for your clients
> > > > > > special needs. The best thing is that this mechanism can
> > > > > > be plugged into, at runtime, whereas RMIClassLoaderSPI is a
> > > > > > onetime thing that requires access to the app class loader,
> > > > > > which might not be possible in some clients. All that is
> > > > > > required is a security grant that allows a particular codebase
> > > > > > to plugin a specific class name.
> > > > > >
> > > > > > Gregg Wonderly
> > > > > >
> > > > > > On Mar 4, 2014, at 7:39 PM, Gregg Wonderly <ge...@cox.net>
> > > > > > wrote:
> > > > > > > > On Mar 4, 2014, at 12:02 AM, Michał Kłeczek
> > > > > > > > <michal.klec...@xpro.biz> wrote:
> > > > > > > >
> > > > > > > > The real problem is that Util interface is in two
> > > > > > > > codebases. It should be in a single codebase shared
> > > > > > > > between UtilProxy and WrapperProxy. But to make it
> > > > > > > > possible we would need to have peer class loading like in
> > > > > > > > ClassWorlds or OSGI. It is not solvable in a standard
> > > > > > > > hierarchical class loading scheme.
> > > > > > >
> > > > > > > This is one of the good examples of where hierarchical
> > > > > > > loading can present challenges.
> > > > > > >
> > > > > > > But the question really is, can an arbitrary client really
> > > > > > > expect for arbitrary services to interact correctly?
> > > > > > > If you want them to do this, it has been shown over and over
> > > > > > > that global types are the best, least troublesome choice.
> > > > > > >
> > > > > > > If you want ubiquitous interactions why not use string based
> > > > > > > values such as XML or better yet, JSON?
> > > > > > >
> > > > > > > Then code and data is immune to class loading snafus and not
> > > > > > > bound to a container or hosting "standard"!
> > > > > > >
> > > > > > > Gregg
> > > > > > >
> > > > > > > > Anyway... It is not really River-436 problem so my patch
> > > > > > > > proposal is going
> > > > > > > > to have the same issue since it is just a replacement for
> > > > > > > > String annotations and not change in class loading scheme.
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > > Michal
> > > > > > > >
> > > > > > > > 4 mar 2014 06:38 "Michał Kłeczek" <michal.klec...@xpro.biz>
> > > > > > > >
> > > > > > > > napisał(a):
> > > > > > > > > 1. The problem is there is no such thing as "the service
> > > > > > > > > interface". It is
> > > > > > > > > context dependent. What is "the service interface" for
> > > > > > > > > service browser?
> > > > > > > > >
> > > > > > > > > 2. In this particular case Util interface is an
> > > > > > > > > implementation detail of WrapperProxy. It is Wrapper
> > > > > > > > > interface the client is interested in. So I would say it
> > > > > > > > > should be preferred in WrapperProxy codebase.
> > > > > > > > >
> > > > > > > > > 3. Even if Util is not preferred in WrapperProxy codebase
> > > > > > > > > we still have ClassCastException if the client does not
> > > > > > > > > have Util in its classpath. Why
> > > > > > > > > should it? it is interested in Wrapper not in Util. So
> > > > > > > > > either a. We always get ClassCastException if Util is
> > > > > > > > > preferred in WrapperProxy codebase, or
> > > > > > > > > b. We get ClassCastException anyway if a client does not
> > > > > > > > > have Util in its
> > > > > > > > > classpath.
> > > > > > > > > Let's say I want to register RemoteEventListener that
> > > > > > > > > wraps a Javaspace proxy to write events in a space. Does
> > > > > > > > > that mean the service "event source"
> > > > > > > > > has to be aware of Javaspace interface??? That would be
> > > > > > > > > absurd...
> > > > > > > > >
> > > > > > > > > It all does not have anything to do with codebase
> > > > > > > > > services.
> > > > > > > > >
> > > > > > > > > Thanks,
> > > > > > > > > Michal
> > > > > > > > >
> > > > > > > > > 4 mar 2014 00:09 "Peter" <j...@zeus.net.au> napisał(a):
> > > > > > > > > > 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.
> > > > > > > > > >
> > > > > > > > > > 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
> > > >
> > > > <Attachment> Michał Kłeczek (XPro).vcf
> >
> > --
> > Michał Kłeczek
> > XPro Sp. z o. o.
> > ul. Borowskiego 2
> > 03-475 Warszawa
> > Polska
> > --
> > Michał Kłeczek
> > XPro Sp. z o. o.
> > ul. Borowskiego 2
> > 03-475 Warszawa
> > Polska
>
> <Attachment> Michał Kłeczek (XPro).vcf
>
