Marc San Soucie wrote: >I agree with you that client portability and vendor neutrality should be an >EJB goal, but we have to be patient about it. There are quite a few >obstacles to reaching that goal. Handles are just one. Client stubs are >another. Others include security APIs and credentials, configuration >values, and JNDI context implementations. >All of the vendors we've worked with are interested in making continued >progress toward interoperability, portability, and neutrality, as a means >of expanding the acceptance of EJB (and J2EE) as the premier enterprise >application platform. That sounds great. These are difficult problems to address. However, what I have experienced with some of the EJB servers is that many (I mean MANY) vendor-specific classes have to be either loaded in advance or at run-time to the client-side. As soon as the client constructs an InitialContext with a vendor-specific context factory class required, the client has no clue about what classes will be loaded after that. To my surprise, I have seen that many seemingly unnecessary vendor-specific classes such as socket classes, rmi classes, and even class loader classes, and many more, are loaded to the client at run-time for a specific EJB server. Although the EJB Spec does not (or maybe cannot) dictate what classes should or should not be needed on the client-side, I am hoping that the EJB server vendors will make an effort to reduce the unidentifiable run-time classes required for an EJB-based client. Otherwise, application developers will completely lose control of the class requirement for their client-side applications. Any vendor implementation information dealing with this issue would be appreciated. Thanks, -Jian =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
