I'm not sure if it so much of an issue since only DP classes will be downloaded.
> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Jeff > Haynie > Sent: Tuesday, March 04, 2003 10:45 AM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] jboss remoting > > > Yes, the class downloading is inefficient and has some large room for > improvement. However, to be noted, that it will only download classes > from the remote side if the class doesn't exists locally (or at least > isn't visible). This is a little more efficient, as I remember, than > RMI where the RMIClassLoader will automatically pull down all classes > from remote. If we can somehow compose an object dependency graph when > a class is required, we could further optimize this even more. > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Bill > Burke > Sent: Tuesday, March 04, 2003 10:32 AM > To: Jboss-Dev > Subject: [JBoss-dev] jboss remoting > > > Hey all, > > I can see why David was so excited about the new JBoss Remoting > framework that Jeff Haynie and Tom Elrod wrote. I had dinner with Jeff > in Boston last night and over a few beers he discussed in detail their > design and features the framework provides. Jeff/Tom, please correct me > where I'm wrong here. > > Some of the features I remember him discussing: > > 1. As RMI provides class downloading when the client does not have > classes available, so does the JBoss remoting framework. The difference > is that JBoss remoting supports multiple protocols. HTTP, SOAP, Socket > based, etc... > > 2. Callbacks are supported and abstracted seemlessly. This will be > especially important to JMS. > > 3. Management services. You can query to obtain a whole map of your > network. > > 4. Find any jboss remoted object by providing a URI or even a query > string. > > My guess of what needs work: > > 1. We need to abstract how references are created and marshalled. i.e., > an EJB method that returns a reference to, or collection of other > different EJBs. We need to make sure that these references point to the > correct transport layer as they were invoked on. > > 2. The class downloading protocol seems a bit inefficient. > > The cool thing about this framework is that it is being used in > production at Jeff's company so we know this shit must work :) All and > all this is really gonna be great for 4.0. I'd really like to commend > Jeff and Tom on a job well done. I'm looking forward to integrating AOP > with this new framework. > > Bill > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Etnus, makers of TotalView, The > debugger > for complex code. Debugging C/C++ programs can leave you feeling lost > and > disoriented. TotalView can help you find your way. Available on major > UNIX > and Linux platforms. Try it free. www.etnus.com > _______________________________________________ > Jboss-development mailing list [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Etnus, makers of TotalView, > The debugger > for complex code. Debugging C/C++ programs can leave you feeling lost and > disoriented. TotalView can help you find your way. Available on > major UNIX > and Linux platforms. Try it free. www.etnus.com > _______________________________________________ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development ------------------------------------------------------- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
