Re: RMI in Tomcat - last try
hihi Nikola, where are you placing your JAR files? are any in TC/commons/lib or TC/shared/lib? try placing everything together, just as a test. put *all* your classes and JAR files under TC/commons for example and give it a try... they should be able to see each other if they are at the same classloading hierarchy level... this is what i suspect your problem is http://struts.apache.org/userGuide/configuration.html#config_add hth, woodchuck --- Nikola Milutinovic [EMAIL PROTECTED] wrote: Hi all. Me and the team have given up on RMI and went to RPC, but I thought I'd make one last educational attempt. Is anyone using RMI in TC where TC is acting as a RMI client to a remote RMI, general-purpose, server? I have seen tons of (rather old) examples of Applet being a RMI client and they do not help me one bit. To remind the group of my problems, I'll recap. I have a working RMI client and server packages, plus command line test client application which uses RMI client lib successfully against the server. When the same lib is used in Tomcat from a servlet, it throws ClassCastException. Further investigation has shown that the class that Servlet gets from RMI subsystem implements the desired interface, to which it is being cast. It also showed that the classloader of the class was RMI ClassLoader, while other classes in the servlet, including servlet itself werefrom TC's ClassLoader. It lead me to believe that *that* is the source of the problem. It has occured to me that, since TC web application has several classloaders, bound into a hierarchy, maybe RMI classloader should be somehow introduced into it. QUESTIONS Am I on the right track? If yes, how do I bind in RMI ClassLoader into TC's ClassLoader hierarchy? And, lastly, who should do it - Servlet or RMI client? The last question is more a design question, but it could also be a feasibility question, too. Can RMI client detect a classloader it should bind into? It could be dome from the Servlet, but I would like to have a general purpose Servlet that would be oblivious of underlying implementation. I thought that at least JBoss developers would have something to say on this question, since, as I recall, JBoss uses or has been using a lot of RMI. There was one article or was it JBoss docs, which explained some problems of classloading, which were very similar to mine. I don't recall those docs saying anything to solve the problem in TC. Nix. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Discover Yahoo! Stay in touch with email, IM, photo sharing and more. Check it out! http://discover.yahoo.com/stayintouch.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RMI in Tomcat - last try
Woodchuck wrote: hihi Nikola, where are you placing your JAR files? are any in TC/commons/lib or TC/shared/lib? try placing everything together, just as a test. put *all* your classes and JAR files under TC/commons for example and give it a try... they should be able to see each other if they are at the same classloading hierarchy level... this is what i suspect your problem is http://struts.apache.org/userGuide/configuration.html#config_add Hi Woodchuck. I forgot to mention that, when I place ALL classes inside WEB-INF/classes, including the *_Stub classes, then it works. I guess in that case TC's classloader picks up the classes before RMI classloader and, since it is teh same CL, it works. This solution is a patch, as far as I am concerned, since copying all those classes to clients classpath (TC's webapp WEB-INF/classes) is actually what RMI is supposed to root out. If I cannot have server classes in RMI codebase (one place), then I can as well go use RPC or pure sockets/serialization. All of this still makes me believe that somehow RMI classloader should be introduced into TC's CL hierarchy. Or maybe install JBoss altogehter? Nix. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RMI in Tomcat - last try
Hi all. Me and the team have given up on RMI and went to RPC, but I thought I'd make one last educational attempt. Is anyone using RMI in TC where TC is acting as a RMI client to a remote RMI, general-purpose, server? I have seen tons of (rather old) examples of Applet being a RMI client and they do not help me one bit. To remind the group of my problems, I'll recap. I have a working RMI client and server packages, plus command line test client application which uses RMI client lib successfully against the server. When the same lib is used in Tomcat from a servlet, it throws ClassCastException. Further investigation has shown that the class that Servlet gets from RMI subsystem implements the desired interface, to which it is being cast. It also showed that the classloader of the class was RMI ClassLoader, while other classes in the servlet, including servlet itself werefrom TC's ClassLoader. It lead me to believe that *that* is the source of the problem. It has occured to me that, since TC web application has several classloaders, bound into a hierarchy, maybe RMI classloader should be somehow introduced into it. QUESTIONS Am I on the right track? If yes, how do I bind in RMI ClassLoader into TC's ClassLoader hierarchy? And, lastly, who should do it - Servlet or RMI client? The last question is more a design question, but it could also be a feasibility question, too. Can RMI client detect a classloader it should bind into? It could be dome from the Servlet, but I would like to have a general purpose Servlet that would be oblivious of underlying implementation. I thought that at least JBoss developers would have something to say on this question, since, as I recall, JBoss uses or has been using a lot of RMI. There was one article or was it JBoss docs, which explained some problems of classloading, which were very similar to mine. I don't recall those docs saying anything to solve the problem in TC. Nix. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
