There are some notable conditions that may exist in modular environments.
1. Lets get this out of the way first: Preferred proxy classes are
implementation classes, the modular environment has no place
managing proxy private implementation classes.
2. In addition to the marshaled smart proxy implementation,
Serialized objects will be transferred between remote hosts and
these may not belong to the proxy preferred class list, instead
they will belong to the Java or Jini platforms, or the Service
API, a local modular environment requires these objects be
instantiated by the correct class instance, which may reside in
different ClassLoaders.
3. Different versions of classes may be present locally in separate
ClassLoaders.
4. Resolving classes for objects a smart proxy refers to may not be
visible via traditionally expected ClassLoader hierarchy trees.
These classes may need to be found by other means. These classes
needn't be visible to the smart proxy, fields may refer to a
common super class or interface.
5. Service API must reside in a parent ClassLoader, so we need to
know super class names, to be able to nominate a suitable parent
ClassLoader for a smart proxy.
This won't be so hard to implement if we have a ClassLoader registry and
we know super class names and version information, this information is
currently not annotated with the Object stream.
A modular JRE won't be released until Java 9, so there's no hurry, but
to ensure we don't overlook any important details, lets create a related
Jira issue to develop a spec.
Cheers,
Peter.
GREGG WONDERLY wrote:
I want to use the netbeans modular application framework as my service UI host.
That is, I want to be able to use all the features of the RCP to create a
complex service UI based client environment. Thus, I want to be able to
download and run serviceUIs inside of netbeans, and that's why I need to be
able to manage how classes are resolved relative to the modularization of
netbeans.
I could then facilitate, as well, interaction with service management UIs so
that we could have a River admin module that could be used in the IDE to talk
to service container management endpoints.
No matter whether the proxy is in the client or in another process, for the IDE to talk
to it, you have to have the same "level" of object compatibility and
communication, to make use of the services exported endpoint and/or serviceUI.
The changes I made were not hard, nor complex. There are relatively few places
that the interactions with RMIClassLoaderSPI occur, and with JINI 2.0 and
PreferredClassLoader, RMIClassLoaderSPIs only useful remaining activity is to
convey the class annotation across the wire.
As I said, what I needed was to set the parent class loader for the downloaded codes context class loader, specifically for netbeans.
What I've learned over the years, is that there are lot of subtle yet
detrimental assumptions about the environment embedded in Jini/RMI. Many of
the things I've run up against, don't add value or otherwise simplify the
developers life. Rather, they complicate things, and leave little flexibility
in deployment scenarios.
This, I feel, is the number one reason why Jini has never gained much traction. It's
hard to "just use it"! We have had lots of examples of this over the years on
the mailing lists and in conversations with people at JavaOne and Jini community meetings.
At this point, changing "everything" to remove the issues, is what I would find
stimulating enough to fully engage.
At this point in my life, I've spent more than a decade using Jini for everything I've done in service based applications. It's been a long hard road to provide my customers with something that worked well enough in their fragile computing environments, that they could be productive. Many just want a web page, because they think that their browser is the only "desktop" they need.
Sending code and marshaling and unmarshaling objects is a huge, huge barrier to some.
Many of us have done this enough, that its just old hat. People love to "buy"
XML marshaling and use http for transport. It seems easy because there are tools that
have been written on both ends and in the middle to simplify the developers life.
Because we've always just used ServiceStarter (well not everyone, but that's all the community
seems to want to support as a part of the "platform"), we have an extremely primitive and
highly configuration dependent "platform".
For many, that seems to be a giant turn off. People want finite choices and
"GUIs" that enumerate all the choices and the ability to just click and pick a
solution. That's where tooling is at in this day and age.
So, that's what I still would like to achieve with River. There are far more
choices then necessary, visible to new developers. The majority of that
flexibility is not needed to get started, and it's possible to put tooling
together that would make it much easier.
Dennis's work on Rio has gone largely ignored, even though it has so much really useful automation and management in it.
We lost out with Seven as well. Mark is not around any longer, really. His
life situation did not allow him to do all the work that was needed to put
something together for public use, and so we ended up without that
simplification of the service deployment scenario either.
There are several different JavaEE deployment tool sets that have been crafted
as well.
I think its very clear that there are a lot of different ideas that have been
layed out, implemented and deployed, which did in fact demonstrate improvements.
With all of that behind us now, I'd really like to see something really
powerful happen with a change in how we view River and how we want to present
it to the world, anew.
Our community is full of lots of ideas and experiences, and I don't want to
diminish any of that by the statements I made above. I'm just trying to relate
what I've seen and where I'd still like to see something happen.
Gregg
-----------------------------
As an aside, the application I want to create would be used as a "come as you are" desktop in a
first-responder or disaster support/recovery environment. There would be services available for accessing
various bits of information, and a complex "this is the state of the event" display would need to
be presentable on all applicable "clients". Different people would have access to different types
of services based on their responsibilities.
I'd like to use netbeans to create this desktop so that the serviceUIs could say "put me in a tab"
or "I'm an editor pane" or "I'm an output pane" etc. This would make it much easier for
the serviceUI assist the user in constructing the right display layout. This would also allow roving
managers or others actively moving through an event to know where to find information on various
clients/displays they would walk past.
On Aug 23, 2012, at 1:25 PM, Greg Trasuk <[email protected]> wrote:
I can't speak for Gregg, but as I understood it, the
CodebaseAccessClassLoader was an attempt to host clients to Jini
services and/or Jini services themselves inside Netbeans. That's
unrelated to developing services in an IDE. Certainly the IDE doesn't
care what you do with the '.class' files it produces.
Speaking for myself (and I've thought about this a fair bit), the real
issue from the developer's perspective is ease of running the code that
you write. Is it actually necessary to load a Jini service proxy inside
the very complicated, modularized classloader environment that Netbeans
implements? It would be convenient if it were easy to do that,
certainly, but it isn't necessary.
Back in the dark ages, we used Ant to create a '.war' file and copy that
file into Tomcat's deployment directory, where a standalone instance of
Tomcat (unaware of either Ant or an IDE) would note the '.war' file's
presence and deploy it in the container. Many servlet-style IDE's do
this today.
In other words, there's no need for a Jini client inside Netbeans or
Eclipse if you just want to deploy stuff.
One level up is to have a remote control interface between the IDE and
the deployment environment. Tomcat's admin application allows for
this. IBM's Rational Application Developer makes web service calls to
the Websphere instance. The IDE could then monitor and control parts of
the container. This is useful for things like deploying applications
"in-place" in the IDE's build directory rather than packaging and
deploying. I think this is how Netbeans now interacts with Tomcat and
Glassfish. I can't think offhand of an example where the IDE interface
does nomitoring, though - it seems to be more common to have an
administration application on the server, although often the IDE can
open a browser to the admin page. This might be different on a Jini
server because there isn't a natural servlet environment to run an
application in.
If the goal is for the IDE to "control" the server, I don't have a
problem with them using a traditional non-Jini protocol (i.e. no
downloaded proxy - they need to agree on the protocol) to do it, since
they're going to be pretty tightly coupled anyway.
Second level-up would be to have visibility into the Jini workgroup from
inside Netbeans or eclipse. In other words, could we have the service
browser functionality inside Netbeans? Again, it would be convenient to
be able to host a Jini client inside Netbeans if it were easy. However,
I think what Gregg W proved with CodebaseAccessClassLoader is that it
isn't that easy. Again, I think a separate executable that Netbeans
talks to using a plain socket protocol would prove easier than trying to
navigate Netbeans' modular classloader hierarchy. This would also be a
good example of where the surrogate spec would come in handy. Netbeans
could ask a surrogate host to launch a surrogate that talks to the Djinn
on its behalf.
You could make an argument similar to the one in "A Note on Distributed
Computing" (Waldo et al) that the idea of serializing an arbitrary
object for transmission over the network is a bit of a fool's errand. I
think it seems perfectly reasonable that the set of classes used in a
service interface could be distributed as a jar file and subjected to
external governance.
To summarize, there's no reason to talk about serialization protocols,
further extensions to codebase annotations, or replacing RMIClassLoader
if the goal is to develop services using an IDE.
Does a service container need a classloader where you can do mystical
things with the codebase and classpath? You betcha! But that's the
container's problem, and it probably has complexities that are more
about the container design than modular classpaths. (If you're curious,
have a look in Surrogate container under
'org.apache.river.container.classloading')
A better question, perhaps, is "what environments should we consider as
clients to business services implemented using River?" For that, I'd
argue the answers "Plain Java", "Servlet environments", and "Other Jini
Services" are the clear winners. I don't see a lot of evidence of
OSGI-based environments for applications in the real world (by which I
mean regular 'Joe Corporate' developers deploying OSGI bundles. Yes, I
accept that servers and IDE's may use an OSGI container as their
implementation environment).
Hosting Jini services in anything besides a Jini-centric environment
(whether it's the 'ServiceStarter' utility or a Jini-centric container)
is guaranteed to be more trouble than it's worth, IMO.
Cheers,
Greg.
On Thu, 2012-08-23 at 08:54, Peter Firmstone wrote:
Enabling developers to develop services in IDE's like Netbeans was the
original motivator (Gregg Wonderly), see
https://issues.apache.org/jira/browse/RIVER-336
Regards,
Peter.
On 23/08/2012 8:57 PM, Simon IJskes - QCG wrote:
On 19-08-12 14:09, Peter Firmstone wrote:
Thoughts?
What is the main driver for the RMIClassLoader replacement?
Gr. Sim
