river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michał Kłeczek (XPro Sp. z o. o.)" <michal.klec...@xpro.biz>
Subject Re: OSGi
Date Sat, 04 Feb 2017 17:12:04 GMT
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.kleczek@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
>>>
>>>
>



Mime
  • Unnamed multipart/mixed (inline, None, 0 bytes)
View raw message