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.
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.
