river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Trasuk <tras...@stratuscom.com>
Subject Re: Develop new spec for RMIClassLoader replacement
Date Thu, 23 Aug 2012 18:25:41 GMT

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
> >


Mime
View raw message