Oh, I could not agree more. This is a serious problem. It is whover not solvable by just disabling optimizations since it also plagues MBean. My sugestion of a delegating repostirory the other week was another way of trying to solve this dilemma. If we at least could change JBoss so that it is possible to meaningfully subclass EARDeployer and Heir..Rep outside of JBoss; then it is at least possible to sort of atcjet the problems on your own at least.
//Peter On Tue, 2003-02-25 at 23:17, SourceForge.net wrote: > Bugs item #693239, was opened at 2003-02-25 23:17 > You can respond by visiting: > https://sourceforge.net/tracker/?func=detail&atid=376685&aid=693239&group_id=22866 > > Category: JBossServer > Group: v3.0 Rabbit Hole > Status: Open > Resolution: None > Priority: 5 > Submitted By: Thomas Pasch (aanno) > Assigned to: Nobody/Anonymous (nobody) > Summary: JBoss ClassLoader implementation is unappropriate for EJB co > > Initial Comment: > The Problem > > > -------------- > > > EJB (jar), WEB (war), and enterprise (ear) archives > > > should be isolated from another. This especially means > > > that: > > > (a) independant packed components could use different > > > version of a file with the same qualified name > > > (b) independant packed components could call each > > > other (i.e. home, remote, and local interfaces) > > > > > JBoss ClassLoader design will cache all Class instances > > > globally in standard configuration. This violates (a). It is > > > possible to switch to (ear) archive-wise caching. But this > > > violates (b), because the (client interfaces) packed with > > > component 1 will be loaded with a different ClassLoader > > > than the interface definition packed in component 2 (that > > > also implements the bean) if both components are > deployed on the same JVM. Violation of (b) normally > shows up in a ClassCastException in > PortableRemoteObject.narrow(). > > > > > In summary it is impossible in JBoss to adhere to (a) and > > > (b) at the same time. > > > > > Proposed solution > > > ------------------ > > > There are two ways around this problem: > > > - disable the local call optimisation for call between > independant packed components or > > > - use a IIOP like scheme for all calls. IIOP will only > transfer data members of object instances. It will NOT > share Class implementation between independant packed > component. > > > > > Kind regards, > > > > > aanno > > > ---------------------------------------------------------------------- > > You can respond by visiting: > https://sourceforge.net/tracker/?func=detail&atid=376685&aid=693239&group_id=22866 > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development -- ------------------------------------------------------------ Peter Antman Chief Technology Officer, Development Technology in Media, Box 34105 100 26 Stockholm WWW: http://www.tim.se WWW: http://www.backsource.org Email: [EMAIL PROTECTED] Phone: +46-(0)8-506 381 11 Mobile: +46-(0)704 20 58 11 ------------------------------------------------------------ ------------------------------------------------------- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
