Re: OSGi [PREVIOUSLY]Re: Maven Build
Thanks Gregg, those are very good points.
Cheers,
Peter.
On 2/10/2017 10:35 PM, Gregg Wonderly wrote:
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 parent ClassLoader may be ignored, depending on the
u
Re: OSGi [PREVIOUSLY]Re: Maven Build
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 parent ClassLoader
Re: OSGi [PREVIOUSLY]Re: Maven Build
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} "createClass
Re: OSGi [PREVIOUSLY]Re: Maven Build
Yes, I've been thinking about it. My current thoughts; ServiceUI can be accessed through net.jini.lookup.ServiceAttributesAccessor, so you can unmarshall ServiceUI objects, without unmarshalling the service itself. However I haven't given much consideration to locating codebases for ServiceUI yet, at least not for OSGi. The reality is that lots of different service implementations might have common ServiceUI components. Sounds like this is an opportune time to start thinking more about it. It also makes me wonder whether MarshalledInstance could accept a URI codebase string, or allow it to be set and retrieved from the current codebase annotation byte array. Cheers, Peter. On 28/09/2017 2:30 AM, Gregg Wonderly wrote: Do you have anything planned around ServiceUI? I really use ServiceUI as a discovery mechanism to find services which export a UI that a user can interact with. What can happen at registration time, besides Entry specification to help with codebase where ServiceUI bits are at? Are you just relying on the “service” setup to include all of that detail, or is there something we can do, to wrap ServiceUI into the mechanism you are talking about here? Gregg On Sep 27, 2017, at 3:59 AM, 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 iso
Re: OSGi [PREVIOUSLY]Re: Maven Build
Yes that's correct. Sun chose to use the ClassLoader to represent the service's pincipal, dynamically granting permission after proxy verification. So that's what we have available on the call stack to use when performing authorisation permission checks: 1. Client's Principal. (Principal based grant) 2. ClassLoader (ClassLoader based grant, usually dynamically) 3. CodeSource's of other modules (CodeSource based grants). Since we trust the code with Maven (because it's downloaded and verified separately), it's probably not appropriate to use a ClassLoader to represent the service's principal in the client. I guess it really depends on the information that needs protection at the client and how much risk there is of information leaking to a service from the client, and the consequences. I suspect that for a lot of applications where the users belong to one organisation, there probably nothing to be done. It may be as simple as using a DomainCombiner to add a ProtectionDomain representing the service's principal (Subject) to the stack, or it may not be necessary to do anything at all.Currently Java only relaxes permission when injecting all ProtectionDomain's on a Thread's call stack with Principals (representing a user Subject), it's effectively granting the permissions of the user to all ProtectionDomain's on the stack. Typically in the current scenario, code, although trusted, is granted less permission in order to allow a user to be granted permission. An alternative behaviour would be to append a protection domain representing a user (Subject) to an existing call stack, such that the resuting permission set is the intersection of all domains (rather than the intersection of all code based grants and the addition of user based grants). In this case code can be granted all the permissions it needs and users might actually reduce the set of permissions, instead of only granting additional permission. So summing up, I think it's something to be aware of, but depending on circumstances probably doesn't require doing anything. Smart proxy's might share ClassLoaders; making dynamic permission grants to ClassLoaders based on the service that has just been authenticated (as per current practise), may not be appropriate. Cheers, Peter. On 28/09/2017 2:54 AM, Dennis Reedy wrote: Hi Peter, In reading your missive I'm not sure I understand when you say "Maven will present a new alternative of maximum sharing, where different service principals will share the same identity.", or "Maven class resolution". Are you referring to an approach where a service may declare it's codebase as an artifact that may have transitive dependencies, and that artifact, when resolved (from perhaps a secure repository) is downloaded onto the requesting client using Maven's local repository scheme? Then remote code becomes local code right? If services publish artifacts to (public/trusted) repositories and follow the approach that published versions are immutable, then a client would download the code only once, and re-use as necessary. Or are you thinking of this or something else? Thanks Dennis On Wed, Sep 27, 2017 at 4:59 AM, 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:
Re: OSGi [PREVIOUSLY]Re: Maven Build
Hi Peter, In reading your missive I'm not sure I understand when you say "Maven will present a new alternative of maximum sharing, where different service principals will share the same identity.", or "Maven class resolution". Are you referring to an approach where a service may declare it's codebase as an artifact that may have transitive dependencies, and that artifact, when resolved (from perhaps a secure repository) is downloaded onto the requesting client using Maven's local repository scheme? Then remote code becomes local code right? If services publish artifacts to (public/trusted) repositories and follow the approach that published versions are immutable, then a client would download the code only once, and re-use as necessary. Or are you thinking of this or something else? Thanks Dennis On Wed, Sep 27, 2017 at 4:59 AM, 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 communicatio
Re: OSGi [PREVIOUSLY]Re: Maven Build
Do you have anything planned around ServiceUI? I really use ServiceUI as a discovery mechanism to find services which export a UI that a user can interact with. What can happen at registration time, besides Entry specification to help with codebase where ServiceUI bits are at? Are you just relying on the “service” setup to include all of that detail, or is there something we can do, to wrap ServiceUI into the mechanism you are talking about here? Gregg > On Sep 27, 2017, at 3:59 AM, 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 Sam
OSGi [PREVIOUSLY]Re: Maven Build
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.
