river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter <j...@zeus.net.au>
Subject Re: OSGi Bundles for services
Date Fri, 24 Feb 2017 11:54:01 GMT
True, better to start small and grow, just looking for some buy in, 's all.

Cheers,

Peter.

On 24/02/2017 9:43 AM, Niclas Hedhman wrote:
> I am sure there a lot of devils in the details here, but I think that you
> have something that is workable, and better to get something smaller (but
> evolvable) out the door for people to try than to spend eternity debating
> the better approach.
>
> Cheers
> Niclas
>
> On Fri, Feb 24, 2017 at 7:14 AM, Peter<jini@zeus.net.au>  wrote:
>
>> When you think about classes with annotations in this environment, it also
>> means that classes at the client
>> may not return to the originating ClassLoader as boomerangs, unless
>> they're resolved by a common imported package by the proxy bundle.  When
>> the boomerang returns it will be loaded in a PreferredClassLoader which has
>> the proxy as the parent ClassLoader in teh client instead of the
>> originating ClassLoader.
>>
>> So if the client registered a listener with a service that remotely
>> filtered or sent events as batches, the client would have to view the
>> results via a common api interface.  There would of course be no codebase
>> annotation losses, the point is objects may not return to their originating
>> loader, so it would seem best to avoid using codebase annotations in OSGi
>> unless a developer is very familiar with ClassLoaders etc.
>>
>> It might be possible to register ClassLoader's with their codebase
>> annotation locally and associate them with proxy ClassLoaders, via a lookup
>> list in PreferredClassProvider, allowing boomerangs to return to the
>> correct ClassLoader, while also allowing PreferredClassProvider to discover
>> annotations.  The annotation itself doesn't need to be a reference to the
>> Bundle, just a suitable list of jar files that would provide the same
>> classes.
>>
>> The thought exercise is interesting in any case.  Sometimes though,
>> simpler is better, it may be preferable to see how developers cope without
>> the bells and whistles first as this is far easier to debug and less
>> subject to problems, for some minor sacrifices in capability.
>>
>> Regards,
>>
>> Peter.
>>
>>
>> On 24/02/2017 8:52 AM, Peter wrote:
>>
>>> In case you're wondering why I've created bundles / modules
>>> structured like below, if the endpoint was deserialized into the
>>> service implementation bundle instead of the proxy bundle,
>>> it may not be able to see deserialized classes from the proxy bundle's
>>>   transitive imports.
>>>
>>> In effect the proxy bundle becomes the equivalent of the application
>>> ClassLoader at each endpoint.
>>>
>>> So any annotated classes will be loaded into PreferredClassLoader's
>>> that have the proxy bundle as the parent ClassLoader.  Any classes in
>>> these ClassLoaders would have a very limited view, they could only
>>> utilise packages imported by the proxy bundle, allowing the proxy
>>> to limit available classes very easily, similar to a sandbox.
>>>
>>> For example Mercury's proxy would allow packages in the java.* namespace
>>> plus classes from any of the following packages:
>>>
>>> Import-Package: net.jini.admin;version="[3.0,4)",net.jini.core.constra
>>>   int;version="[3.0,4)",net.jini.core.discovery;version="[3.0,4)",net.j
>>>   ini.core.entry;version="[3.0,4)",net.jini.core.event;version="[3.0,4)
>>>   ",net.jini.core.lease;version="[3.0,4)",net.jini.event;version="[3.0,
>>>   4)",net.jini.export;version="[3.0,4)",net.jini.id;version="[3.0,4)",n
>>>   et.jini.io;version="[3.0,4)",net.jini.lookup;version="[3.0,4)",net.ji
>>>   ni.security;version="[3.0,4)",net.jini.security.proxytrust;version="[
>>>   3.0,4)",org.apache.river.admin;version="[3.0,4)",org.apache.river.api
>>>   .io;version="[3.0,4)",org.apache.river.landlord;version="[3.0,4)",org
>>>   .apache.river.proxy;version="[3.0,4)"
>>>
>>> DownloadPermission can be used to prevent marshalling of downloaded
>>> objects.
>>>
>>> However the service could advertise available resouces via an Entry.
>>>
>>> Cheers,
>>>
>>> Peter.
>>>
>>> On 23/02/2017 4:13 PM, Peter wrote:
>>>
>>>> Hmm,  ASCII keeps getting scrubbed, so here it is:
>>>>
>>>>
>>>>                            SERVER JVM
>>>> ============================================================
>>>>
>>>>                                              ______________
>>>>                                             |              |
>>>>                                             |  Service     |
>>>>                                             |  API Bundle  |
>>>>                                             |______________|
>>>>                                                    |
>>>>                                                    |
>>>>                                                 Imports
>>>>                                                   API
>>>>                                                 Packages
>>>>                                                    |
>>>>                                                    |
>>>>   ____________________                       ______|_______
>>>> |                    |   Imports packages  |              |
>>>> |   Service Bundle   |<--------------------| Proxy Bundle |---EP
>>>> |   Implements       |      from proxy     |______________|   |
>>>> |   Proxy API        |                                        |
>>>> |____________________|                                        |
>>>>                                                                |
>>>> ============================================================  |
>>>>                                                                |
>>>>                                                                |
>>>>                                                                |
>>>>                                                                N
>>>>                                                                E
>>>>                             CLIENT JVM                         T
>>>> ============================================================  W
>>>>                                                                O
>>>>                                              ______________    R
>>>>   ____________________                      |              |   K
>>>> |                    |   Imports packages  |  Service     |   |
>>>> |  Management Agent  |<--------------------|  API Bundle  |   |
>>>> |  Discovers&        |       from API      |______________|   |
>>>> |  Registers service |                            |           |
>>>> |____________________|                            |           |
>>>>                                                 Imports        |
>>>>                                                   API          |
>>>>                                                 Packages       |
>>>>                                                    |           |
>>>>                                                    |           |
>>>>                                              ______|_______    |
>>>>                                             |              |   |
>>>>                                             | Proxy Bundle |---EP
>>>>                                             |______________|
>>>>
>>>> ============================================================
>>>>
>>>> Note other package imports omitted for clarity.
>>>>
>>>> On 23/02/2017 3:26 PM, Peter wrote:
>>>>
>>>>> I've attached some ASCII of the relationship between server and client
>>>>> jvm bundles.
>>>>>
>>>>> The ClassLoader at the server is set using the invocation layer factory
>>>>> (a configuration item).
>>>>>
>>>>> The client ClassLoader is determined during delayed unmarshalling and
>>>>> smart proxy bundle provisioning.
>>>>>
>>>>> This ensures that deserialization at each endpoint has a compatible
>>>>> view of classes (as recently discussed on osgi-dev).
>>>>>
>>>>> It's important at this time to distinguish between remote objects and
>>>>> remote services, registered with a lookup service.
>>>>>
>>>>> A remote service must have a proxy bundle for OSGi.  The proxy bundle
>>>>> manifest determines requirements and wiring to package import versions.
>>>>> This includes dynamic proxy based services.
>>>>>
>>>>> For arguments sake, a remote object becomes a remote service when it
is
>>>>> registered with a lookup service.
>>>>>
>>>>> A remote object isn't registered with a lookup service.  Listeners are
>>>>> typically remote objects.  In OSGi, it is advisable for remote objects
to
>>>>> be dynamic proxy's without a codebase.  Remote Object proxy's will be
>>>>> deserialized into the remote endpoint's nominated ClassLoader.  For
>>>>> example, if it is transferred via a service, the remote object's dynamic
>>>>> proxy stub will be loaded into the service's proxy bundle ClassLoader
in
>>>>> the server jvm.
>>>>>
>>>>> As Nic pointed out earlier, Bundle ClassLoader's are not instances of
>>>>> URLClassLoader and lack codebase annotations as a result.
>>>>>
>>>>> With the above rules in place, there is no need to create a custom
>>>>> RMIClassLoaderSpi specific to OSGi.
>>>>>
>>>>> With the above rules in place, it does open up an opportunity to use
a
>>>>> remote object (eg a listener) with a conventional codebase as Mic had
>>>>> requested.   This would use the PreferredClassProvider infrastructure,
so
>>>>> the remote object proxy PreferredClassLoader would utilise the services
>>>>> server jvm proxy bundle ClassLoader as it's parent.  This style of remote
>>>>> object should not be registered as a remote service.
>>>>>
>>>>> I would probably discourage this use case, except for advanced users.
>>>>>
>>>>> I think we need to make a distinction between remote services and
>>>>> remote objects for OSGi.
>>>>>
>>>>> This is a very practical solution for OSGi.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Peter.
>>>>>
>>>>>
>>>>> Sent from my Samsung device.
>>>>>
>>>>
>>>>
>>>
>


Mime
View raw message