For those not following my emails on this list :) :
My "codebase annotations" are actually objects of (sub)classes of:
abstract class CodeBase implements Serializable {
...
abstract Class loadClass(String name, ClassLoader defaultLoader)
throws IOException, ClassNotFoundException;
...
}
The interface is actually different for several reasons but the idea is
the same.
So my AnnotatedInputStream is something like:
class AnnotatedInputStream extends ObjectInputStream {
protected Class resolveClass(...) {
((CodeBase)readObject()).loadClass(...);
}
}
Simply speaking I allow the _service_ to provide an object that can
download the code.
Peter proposed to provide serialized CodeBase instances as Base64
encoded strings (or something similar) - to maintain the assumption that
codebase annotation is String.
But I do not see it as important at this moment - if needed - might be
implemented.
Thanks,
Michal
Gregg Wonderly wrote:
Okay, then I think you should investigate my replacement of the
RMIClassLoaderSPI implementation with a pluggable mechanism.
public interface CodebaseClassAccess {
public Class loadClass( String codebase,
String name ) throws IOException,
ClassNotFoundException;
public Class loadClass(String codebase,
String name,
ClassLoader defaultLoader) throws
IOException,ClassNotFoundException;
public Class loadProxyClass(String codebase,
String[] interfaceNames,
ClassLoader defaultLoader ) throws
IOException,ClassNotFoundException;
public String getClassAnnotation( Class cls );
public ClassLoader getClassLoader(String codebase) throws IOException;
public ClassLoader createClassLoader( URL[] urls,
ClassLoader parent,
boolean requireDlPerm,
AccessControlContext ctx );
/**
* This should return the class loader that represents the system
* environment. This might often be the same as {@link
#getSystemContextClassLoader()}
* but may not be in certain circumstances where container mechanisms
isolate certain
* parts of the classpath between various contexts.
* @return
*/
public ClassLoader getParentContextClassLoader();
/**
* This should return the class loader that represents the local system
* environment that is associated with never-preferred classes
* @return
*/
public ClassLoader getSystemContextClassLoader( ClassLoader defaultLoader
);
}
I have forgotten what Peter renamed it to. But this base interface is what all
of the Jini codebase uses to load classes. The annotation is in the “codebase”
parameter. From this you can explore how the annotation can move from being a
URL, which you could recognize and still use, but substitute your own indicator
for another platform such as a maven or OSGi targeted codebase.
Thus, you can still use the annotation, but use it to specify the type of
stream instead of what to download via HTTP.
Gregg
On Feb 4, 2017, at 2:02 AM, Michał Kłeczek (XPro Sp. z o.
o.)<michal.klec...@xpro.biz> wrote:
My annotated streams replace codebase resolution with object based one (ie -
not using RMIClassLoader).
Michal
Gregg Wonderly wrote:
Why specific things do you want your AnnotatedStream to provide?
Gregg
