+1 Sent from my iPhone
On Nov 15, 2011, at 7:09 PM, Niclas Hedhman <nic...@hedhman.org> wrote: > On Wed, Nov 16, 2011 at 7:10 AM, Peter Firmstone <j...@zeus.net.au> wrote: > >> If we share only the Service API, Java and Jini Platform classes and >> objects, then we minimise Java platform issues. >> > > I must have done something wrong in the past then, because that was always > the case for me. > > >> if the proxy is later transferred to another node in the network, the >> codebase annotations have been lost because the classes were loaded by the >> application class loader and resolved from the class path. If the 2nd >> remote node doesn't have the required classes on its classpath, it's game >> over. >> > > Well, not necessarily. I used http:// URLs as the classpath for the entire > application (yes, in its own child to the system classloader). Classpath > annotations worked well. I could imagine that a River container has a > webserver built--in and serving its own classes to needing clients. > > >> This problem could be solved if the Classpath isn't visible to the proxy, >> only the ServiceAPI, Java and Jini Platform classes, so developers don't >> have to understand ClassLoader visibility and preferred classes and may >> instead just focus on developing services and getting their OS and network >> to support multicast discovery. >> > > Agree that it might help, or not... If you are forced to understand > classloader mechanics, I think you will learn to design better applications. > > >> Some options: >> >> 1. Use the extension classloader >> 2. OR Create a new child classloader, for the application and all >> libraries. >> 3. OR Use a Subprocess >> > > Not sure I like any of those. > > > Do you think it's time we work towards a standard container? So that at >> some point in the future all the downstream projects will be able to >> support it as well as their existing container? >> >> What are the requirements for such a container? >> > > There a bunch of containers already, why not then discuss the pros/cons of > each and see how what feedback there is. > > > Cheers > -- > Niclas Hedhman, Software Developer > http://www.qi4j.org - New Energy for Java > > I live here; http://tinyurl.com/3xugrbk > I work here; http://tinyurl.com/6a2pl4j > I relax here; http://tinyurl.com/2cgsug
