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