Re: OSGi [PREVIOUSLY]Re: Maven Build

[Gregg Wonderly]

I like the constructor argument mechanism as it becomes thread local detail, 
rather than VM level detail.   Too many “platform” things in Java have ended up 
being “service type platform” like, instead of multiple services platform like. 
 Keeping things thread of execution specific helps us support “multiple 
services platform” more readily.  It also affords CodeSource level security 
controls more readily.

Gregg

> On Oct 2, 2017, at 5:01 AM, Peter  wrote:
> 
> I'm considering api that may be required for improved OSGi support.
> 
> In order for an OSGi environment to deserialize a proxy, it needs to first 
> install a bundle for the proxy and resolve any dependencies.  For OSGi a 
> ProxyPreparer must first locally marshall (create a MarshalledInstance) a 
> java.lang.reflect.Proxy (implementing ServiceProxyAccessor, 
> ServiceCodebaseAccessor, ServiceAttributesAccessor) instance (returned by 
> SafeServiceRegistrar.lookup) and unmarshall it, passing in the bundle 
> ClassLoader as the default ClassLoader.  This ensures the ServiceProxy's 
> Bundle ClassLoader becomes the default ClassLoader for the underlying JERI 
> endopoint.  Only at this time will a call 
> ServiceProxyAccessor.getServiceProxy() result in a correctly unmarshalled 
> proxy.   If this step isn't performed the default ClassLoader for the JERI 
> Endpoint will be the SafeServiceRegistrar's proxy ClassLoader, and a 
> ClassNotFoundException will be thrown when calling 
> ServiceProxyAccessor.getServiceProxy().
> 
> Given there's some complexity in the above, it would be prudent to implement 
> this in say a convenience class, perhaps called OSGiProxyPreparer, so 
> developers don't have to (boilerplate).
> 
> But we still need something from the underlying modular framework, to install 
> a Bundle for the service proxy and to ensure OSGiProxyPreparer recieves a 
> ClassLoader, while avoiding a dependency on OSGi.   The OSGiProxyPreparer 
> could accept a ProxyClassLoaderProvisioner (see below) as a constructor 
> argument?   Keep in mind the ProxyPreparer is a configuration concern.
> 
> The discovery infrastructure (LookupLocator, LookupLocatorDiscovery and 
> LookupDiscover classes) also needs a way to receive a ClassLoader to 
> deserialize lookup service proxy's.  The codebase URL can be provided in a 
> multicast response, the same interface would need to be used as in 
> ProxyPreparation.
> 
> Please provide feedback, thoughts or suggestions.
> 
>   /*
> * Copyright 2017 The Apache Software Foundation.
> *
> * Licensed under the Apache License, Version 2.0 (the "License");
> * you may not use this file except in compliance with the License.
> * You may obtain a copy of the License at
> *
> *  http://www.apache.org/licenses/LICENSE-2.0
> *
> * Unless required by applicable law or agreed to in writing, software
> * distributed under the License is distributed on an "AS IS" BASIS,
> * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
>   implied.
> * See the License for the specific language governing permissions and
> * limitations under the License.
> */
>   package net.jini.loader;
> 
>   import java.io.IOException;
> 
>   /**
> * Allows client code to implement provisioning of a ClassLoader
>   for a URI path,
> * where the use of codebase annotations is unsuitable.
> *
> * The first URI in the path, must be the proxy URI, any
>   additionally appended
> * URI are dependants, it's possible these may not be loaded
>   directly by the returned
> * ClassLoader, but their classes should still be visible and
>   resolvable from it.
> * Only the proxy URI classes are guaranteed to be loaded by a
>   returned
> * ClassLoader.
> * Dependant URI are not guaranteed to be loaded if suitable
>   versions are
> * already.
> *
> * Some systems, notably OSGi, manage ClassLoader visibility
>   differently than
> * Java's typical hierarchical ClassLoader relationships,
>   implementors of this
> * interface may implement this to provision codebases into a
>   ClassLoader,
> * prior to deserializing a proxy into the resolved ClassLoader.
> *
> * A proxy may be an instance of {@link java.lang.reflect.Proxy}
>   and have
> * no associated codebase, in this case, a new ClassLoader should
>   be returned
> * into which a dynamic proxy class can be provisioned.
> *
> * The implementing class must have {@link java.lang.RuntimePermission}
> * "getClassLoader" and "createClassLoader".  The implementing
>   class must
> * ensure that the caller has {@link java.lang.RuntimePermission}
> * "createClassLoader" as well.
> *
> */
>   public interface ProxyClassLoaderProvisioner {
> 
>/**
> * Create a new ClassLoader, given a space separated list of URL's.
> *
> * The first URL must contain the proxy class.
> *
> * The 

Re: OSGi [PREVIOUSLY]Re: Maven Build

[Peter]

I'm considering api that may be required for improved OSGi support.

In order for an OSGi environment to deserialize a proxy, it needs to 
first install a bundle for the proxy and resolve any dependencies.  For 
OSGi a ProxyPreparer must first locally marshall (create a 
MarshalledInstance) a java.lang.reflect.Proxy (implementing 
ServiceProxyAccessor, ServiceCodebaseAccessor, 
ServiceAttributesAccessor) instance (returned by 
SafeServiceRegistrar.lookup) and unmarshall it, passing in the bundle 
ClassLoader as the default ClassLoader.  This ensures the ServiceProxy's 
Bundle ClassLoader becomes the default ClassLoader for the underlying 
JERI endopoint.  Only at this time will a call 
ServiceProxyAccessor.getServiceProxy() result in a correctly 
unmarshalled proxy.   If this step isn't performed the default 
ClassLoader for the JERI Endpoint will be the SafeServiceRegistrar's 
proxy ClassLoader, and a ClassNotFoundException will be thrown when 
calling ServiceProxyAccessor.getServiceProxy().


Given there's some complexity in the above, it would be prudent to 
implement this in say a convenience class, perhaps called 
OSGiProxyPreparer, so developers don't have to (boilerplate).


But we still need something from the underlying modular framework, to 
install a Bundle for the service proxy and to ensure OSGiProxyPreparer 
recieves a ClassLoader, while avoiding a dependency on OSGi.   The 
OSGiProxyPreparer could accept a ProxyClassLoaderProvisioner (see below) 
as a constructor argument?   Keep in mind the ProxyPreparer is a 
configuration concern.


The discovery infrastructure (LookupLocator, LookupLocatorDiscovery and 
LookupDiscover classes) also needs a way to receive a ClassLoader to 
deserialize lookup service proxy's.  The codebase URL can be provided in 
a multicast response, the same interface would need to be used as in 
ProxyPreparation.


Please provide feedback, thoughts or suggestions.

   /*
 * Copyright 2017 The Apache Software Foundation.
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 *  http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
   implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */
   package net.jini.loader;

   import java.io.IOException;

   /**
 * Allows client code to implement provisioning of a ClassLoader
   for a URI path,
 * where the use of codebase annotations is unsuitable.
 *
 * The first URI in the path, must be the proxy URI, any
   additionally appended
 * URI are dependants, it's possible these may not be loaded
   directly by the returned
 * ClassLoader, but their classes should still be visible and
   resolvable from it.
 * Only the proxy URI classes are guaranteed to be loaded by a
   returned
 * ClassLoader.
 * Dependant URI are not guaranteed to be loaded if suitable
   versions are
 * already.
 *
 * Some systems, notably OSGi, manage ClassLoader visibility
   differently than
 * Java's typical hierarchical ClassLoader relationships,
   implementors of this
 * interface may implement this to provision codebases into a
   ClassLoader,
 * prior to deserializing a proxy into the resolved ClassLoader.
 *
 * A proxy may be an instance of {@link java.lang.reflect.Proxy}
   and have
 * no associated codebase, in this case, a new ClassLoader should
   be returned
 * into which a dynamic proxy class can be provisioned.
 *
 * The implementing class must have {@link java.lang.RuntimePermission}
 * "getClassLoader" and "createClassLoader".  The implementing
   class must
 * ensure that the caller has {@link java.lang.RuntimePermission}
 * "createClassLoader" as well.
 *
 */
   public interface ProxyClassLoaderProvisioner {

/**
 * Create a new ClassLoader, given a space separated list of URL's.
 *
 * The first URL must contain the proxy class.
 *
 * The parent ClassLoader may be ignored, depending on the
   underlying
 * infrastructure.
 *
 * If uriPath is null, a ClassLoader is still created to
   accommodate
 * any dynamically created classes, with the parent ClassLoader
   as the
 * parent.
 *
 * @param uriPath the codebase URL path as a space-separated list
 * of URLs, or null
 * @param parent the default parent ClassLoader.
 * @return
 * @throws IOException
 * @throws SecurityException if the caller doesn't have {@link
   java.lang.RuntimePermission}