It looks to me like we are talking past each other.
Thread local resolution context is needed - we both agree on this.
What we do not agree on is that the context should be a single
ClassLoader. It has to be a set of ClassLoaders to support situations
when dependencies are not hierarchical.
The use case is simple - I want to implement "decorator" services that
provide smart proxies wrapping (smart) proxies of other services.
I also want to have Exporters provided as dynamic services which would
allow my services to adapt to changing network environment.
And I would like to stress - I am actually quite negative about OSGI
being the right environment for this.
Thanks,
Michal
Gregg Wonderly wrote:
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.klec...@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
