Mailing-List: contact dev-help@river.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@river.apache.org
Message-ID: <59D20E69.1000300@zeus.net.au>
Date: Mon, 02 Oct 2017 20:01:13 +1000
From: Peter <jini@zeus.net.au>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.28) Gecko/20120306 Thunderbird/3.1.20
MIME-Version: 1.0
To: dev@river.apache.org
Subject: Re: OSGi [PREVIOUSLY]Re: Maven Build
References: <2b2887baf18d97801cf87178c4e49b51@org.tizen.email> <2490ad6a-24dd-b2a4-6ea2-32876a1ac36a@travellinck.com> <59CB687C.2090209@zeus.net.au>
In-Reply-To: <59CB687C.2090209@zeus.net.au>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
archived-at: Mon, 02 Oct 2017 10:01:29 -0000

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 <code>null</code>
          * @param parent the default parent ClassLoader.
          * @return
          * @throws IOException
          * @throws SecurityException if the caller doesn't have {@link
    java.lang.RuntimePermission} "createClassLoader".
          */
         public ClassLoader createClassLoader(String uriPath,
    ClassLoader parent) throws IOException;

    }

Regards,

Peter.

On 27/09/2017 6:59 PM, Peter wrote:
> Some updates on thoughts about OSGi:
>
>   1. In JGDMS, SafeServiceRegistrar (extends ServiceRegistrar),
>      ServiceDiscoveryManager and ProxyPreparer allow provisioning of
>      OSGi bundles for Jini services.
>   2. SafeServiceRegistrar lookup results contain only instances of
>      java.lang.reflect.Proxy (implementing ServiceProxyAccessor,
>      ServiceCodebaseAccessor, ServiceAttributesAccessor) which a user
>      remarshalls and unmarshalls into their OSGi bundle provisioned
>      ClassLoader, prior to retrieving the actual service proxy using
>      ServiceProxyAccessor.
>   3. As a result different service principals using identical proxy
>      codebases, needn't share a ClassLoader, addressing the trust
>      domain issue previously alluded to.
>   4. There's no current mechanism to allow provisioning of a bundle for
>      a Registrar.
>   5. Existing discovery providers accept ClassLoader arguments for
>      unmarshalling Registrar's.
>   6. Existing Multicast responses allow for additional information to
>      be appended; a codebase resource for example.
>   7. LookupLocator, LookupDiscovery and LookupLocatorDiscovery classes
>      don't utilise discovery providers ClassLoader arguments.
>   8. Need to allow bundles to be provisioned for lookup services after
>      multicast discovery, by exposing discovery provider ClassLoader
>      arguments and allowing client to manage provisioning of bundle
>      into a ClassLoader, then passing that in during unicast discovery.
>   9. Don't break backward compatiblity.
>
> Cheers,
>
> Peter.
>
> On 16/11/2016 4:18 PM, Dawid Loubser wrote:
>> +1 for OSGi providing the best solution to the class resolution problem,
>> though I think some work will have to be done around trust, as you say.
>>
>>
>> On 16/11/2016 02:23, Peter wrote:
>>>
>>> The conventional alternatives will remain;  the existing ClassLoader 
>>> isolation and the complexities surrounding multiple copies of the 
>>> same or different versions of the same classes interacting within 
>>> the same jvm.  Maven will present a new alternative of maximum 
>>> sharing, where different service principals will share the same 
>>> identity.
>>>
>>> Clearly, the simplest solution is to avoid code download and only 
>>> use reflection proxy's
>>>
>>> An inter process call isn't remote, but there is a question of how a 
>>> reflection proxy should behave when a subprocess is terminated.
>>>
>>> UndeclaredThrowableException seems appropriate.
>>>
>>> It would plug in via the existing ClassLoading RMIClassLoader 
>>> provider mechanism, it would be a client concern, transparent to the 
>>> service or server.
>>>
>>> The existing behaviour would remain default.
>>>
>>> So there can be multiple class resolution options:
>>>
>>> 1. Existing PrefferedClassProvider.
>>> 2. Maven class resolution, where maximum class sharing exists.  This 
>>> may be preferable in situations where there is one domain of trust, 
>>> eg within one corporation or company.  Max performance.
>>> 3. Process Isolation.  Interoperation between trusted entities, 
>>> where code version incompatibilities may exist, because of separate 
>>> development teams and administrators.  Each domain of trust has it's 
>>> own process domain.  Max compatibility, but slower.
>>> 4. OSGi.
>>>
>>> There may be occassions where simpler (because developers don't need 
>>> to understand ClassLoaders), slow, compatible and reliable wins over 
>>> fast and complex or broken.
>>>
>>> A subprocess may host numerous proxy's and codebases from one 
>>> principal trust domain (even a later version of River could be 
>>> provisioned using Maven).  A subprocess would exist for each trust 
>>> domain. So if there are two companies, code from each remains 
>>> isolated and communicates only using common api.  No unintended code 
>>> versioning conflicts.
>>>
>>> This choice would not prevent or exclude other methods of 
>>> communication, the service, even if isolated within it's own process 
>>> will still communicate remotely over the network using JERI, JSON 
>>> etc.  This is orthogonal to and independant of remote communication 
>>> protocols.
>>>
>>> OSGi would of course be an alternative option, if one wished to 
>>> execute incompatible versions of libraries etc within one process, 
>>> but different trust domains will have a shared identity, again this 
>>> may not matter depending on the use case.
>>>
>>> Cheers,
>>>
>>> Peter.
>>>
>>> ESent from my Samsung device.
>>>
>
>