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