river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregg Wonderly <ge...@cox.net>
Subject Re: OSGi
Date Wed, 01 Feb 2017 20:56:43 GMT
Part of the “preferred” is to keep downloads from happening.  But the other is the fact
that the UI is already using/linked to specific sources of the Entry classes that it uses
for finding the name of the service, the icon and other details.  There are serviceUI classes
which are also already bound at the time of service discovery and the serviceUI for that service
needs to resolve to those classes, not any in the codebase jars for the service.

Gregg

> On Feb 1, 2017, at 5:52 AM, Peter <jini@zeus.net.au> wrote:
> 
> Gregg,
> 
> Have you got some more detail on your Entry classes that need to be preferred?
> 
> Thanks,
> 
> Peter.
> 
> Sent from my Samsung device.
>  
>   Include original message
> ---- Original message ----
> From: Gregg Wonderly <gergg@cox.net>
> Sent: 31/01/2017 12:56:56 am
> To: dev@river.apache.org
> Subject: Re: OSGi
> 
> Maybe you can help me out here by explaining how it is that execution context and class
visibility are both handled by OSGi bundles.  For example, one of my client applications is
a desktop environment.  It does service look up for all services registrations providing a
“serviceUI”.  It then integrates all of those services into a desktop view where the UIs
are running at the same time with each one imbedded in a JDesktopPane or a JTabbedPane or
a JFrame or JDialog.  There are callbacks from parts of that environment into my application
which in turn is interacting with the ServiceUI component.  You have AWT event threads which
are calling out, into the ServiceUIs and lots of other threads of execution which all, ultimately,
must have different class loading environments so that the ServiceUI components can know where
to load code from. 
> 
> It’s exactly TCCL that allows them to know that based on all the other class loading
standards.  The ClassLoader is exactly the thing that all of them have in common if you include
OSGi bundles as well.  The important detail, is that if the TCCL is not used as new ClassLoaders
are created, then there is no context for those new ClassLoaders to reference, universally.

> 
> The important details are: 
> 
>     1) The desktop application has to be able to prefer certain Entry classes which define
details that are presented to the user. 
>     2) When the user double clicks on a services icon, or right clicks and selects “Open
in new Frame”, an async worker thread needs a TCCL pointing at the correct parent class
loader for the service’s URLClassLoader to reference so that the preferred classes work.

>     3) Anytime that the AWT Event thread might be active inside of the services UI implementation,
it also needs to indicate the correct parent class loader if that UI component causes other
class loading to occur. 
>     4) I am speaking specifically in the context of deferred class loading which is controlled
outside of the service discovery moment. 
> 
>   
>>  On Jan 30, 2017, at 4:04 AM, Michał Kłeczek (XPro Sp. z o. o.) <michal.kleczek@xpro.biz>
wrote: 
>>   
>>  What I think Jini designers did not realize is that class loading can be treated
exactly as any other capability provided by a (possibly remote) service. 
>>  Once you realize that - it is possible to provide a kind of a "universal container
infrastructure" where different class loading implementations may co-exist in a single JVM.

> 
> That’s precisely what ClassLoader is for.  TCCL is precisely to allow “some class”
to know what context to associate newly loaded classes with, so that in such an environment,
any code can load classes on behalf of some other code/context.  It doesn’t matter if it
is TCCL or some other class management scheme such as OSGi bundles.  We are talking about
the same detail, just implemented in a different way. 
> 
>>  What's more - these class loading implementations may be dynamic themselves - ie.
it is a service that provides the client with a way to load its own (proxy) classes. 
>>   
>>  In other words: "there not enough Jini in Jini itself”. 
> 
> I am not sure I understand where the short coming is at then.  Maybe you can illustrate
with an example where TCCL fails to allow some piece of code to load classes on behalf of
another piece of code? 
> 
> In my desktop application environment, there is a abstract class which is used by each
serviceUI to allow the desktop to know if it provides the ability to open into one of the
above mentioned JComponent subclasses.  That class is preferred and provided and resolved
using the codebase of the desktop client.  That class loading environment is then the place
where the service is finally resolved and classes created so that the proxy can be handed
to the serviceUI component which ultimately only partially resolves from the services codebase.

> 
> It’s this class compatibility which needs to be lightweight. 
> 
>>   
>>  We have _all_ the required pieces in place: 
>>  - dynamic code loading and execution (ClassLoaders), 
>>  - security model and implementation that allows restricting rights of the downloaded
code, 
>>  - and a serialization/deserialization which allows sending arbitrary data (and yes
- code too) over the wire. 
>>   
>>  It is just the matter of glueing the pieces together. 
> 
> Correct, but it’s a matter of class compatibility where a client environment has to
interact with a service and the serviceUI components where TCCL excels and providing the ability
to create class loaders with the correct parent context, for Java based code.  OSGi introduces
the opportunity for some extra bells and whistles.  But I don’t see that it can completely
eliminate the nature of TCCL and how it was intended to be used. 
> 
>>   
>>  Thanks, 
>>  Michal 
>>   
>>   
>>  Gregg Wonderly wrote: 
>>>  <snip> 
>>>  I am not an OSGi user.  I am not trying to be an OSGi opponent.  What I am trying
to say is that I consider all the commentary in those articles about TCCL not working to be
just inexperience and argument to try and justify a different position or interpretation of
what the real problem is. 
>>>   
>>>  The real problem is that there is not one “module” concept in Java (another
one is almost here in JDK 9/Jigsaw).  No one is working together on this, and OSGi is solving
problems in a small part of the world of software.   It works well for embedded, static systems.
 I think OSGi misses the mark on dynamic systems because of the piecemeal loading and resolving
of classes.  I am not sure that OSGi developers really understand everything that Jini can
do because of the choices made (and not made) in the design.  The people who put Jini together
had a great deal of years of experience piecing together systems which needed to work well
with a faster degree of variability and adaptation to the environment then what most people
seem to experience in their classes and work environments which are locked down by extremely
controlled distribution strategies which end up slowing development in an attempt to control
everything that doesn’t actually cause quality to suffer. 
>>>   
>>>  Gregg 
>>>   
>>>   
>>   
> 
> 


Mime
View raw message