Follow up: > On 15 Feb 2022, at 13:05, Peter Firmstone <peter.firmst...@zeus.net.au> wrote: > > >> >> - How do you provide the above mentioned JavaSpaceEventPublisher >> - How would you provide a java.sql.DataSource as a service? > > > If you don't have an ObjectEndpoint, then there is no one to authenticate, > you only have bytes to de-serialize, so how do you establish trust, ie who > did the bytes come from? However it is possible to have a service that has > an ObjectEndpoint and only uses it for authentication of the proxy serializer > and codebase provisioning after which the deserialized bytes become objects > and don't make remote method calls. I think that would be an acceptable > alternative; someone needs to vouch for the serialized bytes.
You still need to load code to be able to deserialise. How do you do that in your solution? > > >> >>> Now the proxy serializer is itself a service (bootstrap proxy), that is >>> authenticated when using secure endpoints. You could quite easily add an >>> interface to the proxy serializer to return your object annotation. >>> >>> Note that I use a string, because I also use it in secure multicast >>> discovery protocols (typically IPv6), which don't include objects, for >>> authentication and provisioning a ClassLoader for a lookup service proxy >>> prior to any Object de-serialization. >>> >>> https://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml >>> >>> <https://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml> >>> >>> Summing up to simplify JGDMS and solve some very difficult issues, it had >>> to give up: >>> >>> 1. Support for circular references in serialized object graphs, was >>> dropped. >>> >> My solution supports any object graph. > > > What capability do you need circular references for? This is besides the point. The point is that code loading should be orthogonal to serialisation format an whether it supports circular references. [...] >> >> It would be great to be able to merge the ideas and work on common solution. >> The question is whether it should be Apache River project… > > > I think the PMC has already decided River's fate, and I tend to agree with > their decision, the problem is that historically, it hasn't been possible to > innovate inside the Apache River project, innovation has been forced to > happen elsewhere and it wasn't just what I was doing, there was an attempt to > do some container work in River but that also got shut down. People had > trouble in the past agreeing on Rivers direction and there are no currently > active developers. It is still possible to get a group of people together > to create an Apache project, but I don't think the code needs it. github > and other sites like it are better for loose collaboration, where developers > can feed off each others ideas and innovations and the best solutions survive. I am with you here. Michal
