Incorrect classloading
Hi, I recently tried to use the newest version of jgroups within a webapp running in tomcat. JGroups comes with a commons-logging.jar for it's own logging. I discovered that Jgroups couldn't use commons logging, because commons logging coulnd't load a log4j class, even though log4j.jar was in WEB-INF/lib. I solved the problem by placing log4j.jar along with the rest of tomcat's jar files (e.g. tomcat's commons-logging.jar). This makes me wonder if there is a problem with using commons logging in a webapp in general? It seems tomcat isn't loading commons-logging from the webapp as expected, but rather uses the one loaded in tomcat already. Is that correct, and if so, why shouldn't a webapp be allowed to use it's own commons-logging? Could this be a variant of http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22701 ? I'm using Tomcat 4.1.30. -dennis - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Incorrect classloading
Shapira, Yoav wrote: Hi, A webapp can use its own commons-logging library, but it must then move the one supplied with Tomcat out of the common and into the server lib directory. I see. That makes sense. Thanks. -dennis - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Embedding Jasper / JSP compiling
Hi, I'm currently working on embedding a jasper engine within a servlet container that I'm writing. During this work I have run into the following questions: 1) Is the only advantage to using fork=true, that the javac memory leak issue is avoided? 2) Has the javac memory leak issue been fixed in newer versions of the JDK? 3) Is there any way to have the Java code generated from JSPs compiled using my own classloader? I was thinking, that if I used fork=false, maybe javac would just use the present classloader. Any help with the above questions would be greatly appreciated, since it seems that I'm on a fairly difficult endeavour here. TIA, -dennis - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Embedding Jasper / JSP compiling
Rick Knowles wrote: Dennis, I'm not a tomcat dev, but hopefully I can help anyway - having done what I think it is you're trying to do. I did mine for the Winstone servlet container (http://winstone.sourceforge.net) For Nos 1 and 2, I can't help. But for No 3 it involves setting context attributes: 1) org.apache.catalina.jsp_classpath, and 2) org.apache.catalina.classloader It seems that 1 is the one that does the work. It doesn't actually even seem to call 2 at class load time, but there is code that reads 2, so I set it anyway. By setting 1, you don't actually set the classloader, but you make a new classloader that has the same classpath. If that's not what you want, maybe someone else on the list can help. The only other thing you have to do is mount the JspServlet, which it sounds like you've already done. Thanks for your answer, which I think would help somewhat. But I already figured this part out, and have that working. The part that I have trouble with is using my own classloader, because with the classpath I can only refer to jars and directories. What I need to do is load classes from jars within jars, and other places as well. But I will certainly look into the org.apache.catalina.classloader context attribute. That one had missed my attention. -dennis - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Embedding part of Tomcat within a J2EE webapp?
Hi, I am currently researching a way to implement web-container-like functionality within a J2EE compliant webapp, that can run on theoretically any servlet container. One way to do this, would be to embed parts of tomcat such that a number of self-managed web applications could be served through the servlet container already sourrounding the controlling webapp. This would include instantiating a Context (perhaps instantiating a StandardContext would do the trick?) and have this serve servlets, jsp, etc. from sources defined by the code instantiating the context. My question is this: Is it possible, and feasable, to instantiate a tomcat representation of a context, and have it serve servlets, compile and serve JSPs, etc.? This should work as continued processing for the existing HttpServletRequest, HttpServletResponse and HttpSession. The Context in question should function as a partial decoration of the existing Context. Is it possible to implement a 'provider' for the DefaultServlet and JspServlet, such that the filesystem/webapp archive can be replaced with arbitary sources? I'm not aware of the detailed differences between Tomcat 4.1 and 5.0, but either could be used. Any input appreciated. -dennis - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
