river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: Develop new spec for RMIClassLoader replacement
Date Fri, 24 Aug 2012 09:33:06 GMT
Just in case people mistake this as another discussion about OSGi, read 
this first:

      /Project Jigsaw/: Module Class Loading and *...* - OpenJDK -

Gregg's on the right track, I support the work he's doing.  There's 
plenty of time to get this sorted, for now we just need to make 
decisions that will allow flexibility later, when modularity becomes the 
norm and not the exception.



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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message