One thing... On 9 November 2012 10:44, Peter Firmstone <j...@zeus.net.au> wrote:
> Motivated by Sim's suggestions: > > Any objection to changing it to net.jini.io.**MarshalClassResolverSPI? > > This places it right where it's needed. > > Since all URI in a code base string will reside in one ClassLoader, all > classes in that ClassLoader must use the same provider. For instance an > osgi:, maven: or httpmd: provider annotations could not mix within the same > ClassLoader. > I'll have to do some checking but I don't think that's a current constraint on the makeup of a codebase. Strictly from memory I recall codebase is a set of URL's separated by spaces and nothing more. I'm not sure how that's going to fit with insisting on a single provider. > > So in this case it would be acceptable to parse the codebase string, the > scheme of the first URI found would be used to select a suitable provider. > This wouldn't prohibit the use of custom ClassLoaders like URIClassLoader > and BundleClassLoader (an interface for OSGi ClassLoaders). > > Existing known types would be diverted to RMIClassLoaderSPI, via a default > provider to avoid breaking existing code. > Thus URL would not necessarily be required for class resolution. Jar > files may be downloaded separately and loaded from a local cache. > > The URL used in the CodeSource might also be different, a local file: or > perhaps even null, Certificates used to represent the CodeSource for > security purposes. It would be the responsibility of the ClassLoader > associated with the Service Provider to determine a codebase string > suitable for remote code. > > These service providers would be part of a sub project, or implemented by > downstream developers, not part of River directly. > > However there is one important omission, how do you remotely install a > provider instance that doesn't exist locally? > > One method might be to append a the provider URL to the codebase string. > > The process would proceed as follows: > > 1. The scheme of the first provider would be used to select a > suitable provider if available. > 2. If a suitable provider is not found locally, the last URI codebase > string can optionally be a URL from which the provider can be > retrieved. > 3. The Provider jar must be signed and trusted (it can be signed with > a self signed certificate generated by the administrator, trusted > at the client). If not trusted a ClassNotFoundException will be > thrown. > 4. The Provider will be loaded into it's own ClassLoader instance and > instantiated from a no arg constructor, it isn't a remote object. > 5. The service loader will be refreshed, the provider then selected > to perform class resolution. > > An alternative to signing a jar file for the provider, might be to > retrieve it across an https: connection, the server is authenticated. The > https codebase server could be granted sufficient permission based on it's > URL, perhaps using RemotePolicy, or using a local policy file. > > Are we going too far? Thoughts? > > Cheers, > > Peter. > > > Peter Firmstone wrote: > >> Simon IJskes - QCG wrote: >> >>> On 08-11-12 13:40, Peter Firmstone wrote: >>> >>> Yes, but lets play around with it in skunk. Dan's made some valid >>>> >>> >>> Indeed Dan has made valid remarks, but i really dont like skunk. Tom >>> suggested sub projects once. I did not see any benefits at that time. But i >>> think it might be helpful right now. >>> >>> We could use the subprojects as 'clients' to the core, and allow >>> requirements of these subprojects drive the modifications of the core. >>> >>> We can decide whatever status a subproject will have, and we do not make >>> them heavyweight. Just an extra jar, an extra libs and an extra src in a >>> directory together. >>> >>> I'm thinking about osgi, wan, internet, jmx transports etc. We treat the >>> sub projects as first class citizens, and do proper release management on >>> them. Just not that often. >>> >>> Am i still thinking too grandiose Dan? >>> >>> Gr. Simon >>> >>> >>> Ok, because it's small I think we can consider it, can you provide the >> hooks to load different providers? The non default providers themselves >> can be a subproject. We need to carefully consider security since we're >> making it possible for downloaded code to resolve classes. >> >> My SecurityManager and policy providers were developed in skunk, then >> merged. URI changes were made in trunk, although this was a big change >> semantically, the code footprint is small. For large changes to foundation >> code we need skunk, not everything can be bolted on or plugged in. >> >> Cheers, >> >> Peter. >> >> > >
