Tomcat 3.3 CVS: class/jar reloading
Still a bit confused with it... When I put class files into WEB-INF/classes, Tomcat reports something like this: DependManager: Added /home/httpd/html/binarix.dev/WEB-INF/classes/com/binarix/velocity/PumpServlet.class class com.binarix.velocity.PumpServlet Cool. Works as expected, the app gets dumped when I refresh the class. The second test is with a jar file that contains the very same class. The application still works, so, obviously, the actually class file is found in the jar file. The class is not available anywhere else as the app stops working once the jar is removed from WEB-INF/lib. However, Tomcat does not report any action from DependManger in relation to this jar file. Neither it dumps the app when the jar gets refeshed. I went through the code briefly and there are references to jar files in DependManger. I must be doing something seriously silly here... Bojan
Re: TC4: web.xml and reloading
Jim Cheesman wrote: I have to back this statement up - jar reloading on TC4/Win2000 is a risky business, to say the least. Sometimes it works, sometimes not... I wonder if it's anything to do with the server checking for a new jar at the same time as the filesystem overwrites the old one? Nasty. Maybe it's a JDK for Win specific thingy, rather then a Tomcat bug? Does it work with IBM JDK? I'm having some problems with jar reloading in TC 3.3. But this is happening on Linux and the tricky part is that DependManager doesn't even report jar files as dependencies... Bojan
Re: Tomcat 3.3 CVS: class/jar reloading
Bojan Smojver wrote: Still a bit confused with it... When I put class files into WEB-INF/classes, Tomcat reports something like this: DependManager: Added /home/httpd/html/binarix.dev/WEB-INF/classes/com/binarix/velocity/PumpServlet.class class com.binarix.velocity.PumpServlet Cool. Works as expected, the app gets dumped when I refresh the class. The second test is with a jar file that contains the very same class. The application still works, so, obviously, the actually class file is found in the jar file. The class is not available anywhere else as the app stops working once the jar is removed from WEB-INF/lib. However, Tomcat does not report any action from DependManger in relation to this jar file. Neither it dumps the app when the jar gets refeshed. I went through the code briefly and there are references to jar files in DependManger. I must be doing something seriously silly here... Bojan Don't worry about answering this one. I've transferred to dev list. It seems to be a bug in TC 3.3. Bojan
TC4: web.xml and reloading
I looked through the source code and in the documentation of the Loader to see if the change of web.xml will cause an application reload in TC4 when relaodable is set to true, but I couldn't find anything that would tell me that explicitly. I'm sure this is the case in TC3.3, I was just trying to establish if that was the case in TC4. Bojan PS. Is there really any need to keep the current documentation on the web site? The experimental seems to be more comprehensive.
Re: TC4: web.xml and reloading
Craig R. McClanahan wrote: On Wed, 12 Sep 2001, Bojan Smojver wrote: Date: Wed, 12 Sep 2001 10:40:21 +1000 From: Bojan Smojver [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: Tomcat User List [EMAIL PROTECTED] Subject: TC4: web.xml and reloading I looked through the source code and in the documentation of the Loader to see if the change of web.xml will cause an application reload in TC4 when relaodable is set to true, but I couldn't find anything that would tell me that explicitly. I'm sure this is the case in TC3.3, I was just trying to establish if that was the case in TC4. When you set an application's Context entry to say reloadable='true', Tomcat starts a background task that watches for changes to *any* class that was originally loaded from /WEB-INF/classes or /WEB-INF/lib. If such a change is detected, the app will be reloaded. The default checking interval is 15 seconds, and can be changed like this: Context ... reloadable=true ... Loader checkInterval=5/ /Context Of course, you can reload any application at any time (whether or not you've set reloadable) by using the Manager application. My question was about web.xml, not the classes and jars (that's explained in Loader docs). If web.xml changes, TC3.3 will dump the app and reload because web.xml gets stored in the DependManager (from memory). Does TC4 behave the same? Bojan
Re: JSP/Servlet --EJB
Huaxin wrote: A little bit off topic, sorry about that. I see most of the examples using EJB from Servlet. However, is there any example of using JSP with EJB directly? (without too much scriplet, and hopefully more efficient than create a bean to interact with the EJB) thanks a lot Every JSP eventually becomes a servlet, so there shouldn't be any technical difficulties in doing that. But, is this really the design you want to have? Embedding EJB call machinery into JSP will make the code contain a lot of the stuff that has nothing to do with presentation. Unless, of course, you're using the JSP's for non presentational purposes here... But if you do, then straight servlets or beans are a better choices anyway, therefore the lack of examples :-) Here is an article that explains the Model 2 architecture: http://www.javaworld.com/javaworld/jw-12-1999/jw-12-ssj-jspmvc.html Bojan
Re: TC4: web.xml and reloading
Remy Maucherat wrote: My question was about web.xml, not the classes and jars (that's explained in Loader docs). If web.xml changes, TC3.3 will dump the app and reload because web.xml gets stored in the DependManager (from memory). Does TC4 behave the same? No web.xml reloading in TC 4. Remy OK. Is there a way to force app reload from one of the servlets running within that app (apart from the obvious touching of classes or jars). Something like telling the classloader to dump the thing? Bojan
Re: TC4: web.xml and reloading
Remy Maucherat wrote: Remy Maucherat wrote: My question was about web.xml, not the classes and jars (that's explained in Loader docs). If web.xml changes, TC3.3 will dump the app and reload because web.xml gets stored in the DependManager (from memory). Does TC4 behave the same? No web.xml reloading in TC 4. Remy OK. Is there a way to force app reload from one of the servlets running within that app (apart from the obvious touching of classes or jars). Something like telling the classloader to dump the thing? You can use the manager servlet. See the manager webapp and the docs for more details. http://jakarta.apache.org/tomcat/tomcat-4.0-doc-exp/manager-howto.html Remy OK. Sounds good. Anything like that for TC3.3 that you know of? BTW, what was the reason behind not including web.xml in the reload? It seems like a pretty important part of the app... Bojan
Re: TC4: web.xml and reloading
Craig R. McClanahan wrote: When you set an application's Context entry to say reloadable='true', Tomcat starts a background task that watches for changes to *any* class that was originally loaded from /WEB-INF/classes or /WEB-INF/lib. If such a change is detected, the app will be reloaded. The default checking interval is 15 seconds, and can be changed like this: Context ... reloadable=true ... Loader checkInterval=5/ /Context Of course, you can reload any application at any time (whether or not you've set reloadable) by using the Manager application. I looked through the StandardLoader code just to get the feel for the way it works. The way I understand it is that if a .jar file in WEB-INF/lib gets changed, the app is going to be reloaded (provided the above is specified). Does that mean that if I have a text file, rather then a class file, in one of those jars and I deploy a new version of the jar with only the text file changed, the app gets reloaded? Bojan
Re: Can TC4 work with JBoss ?
SongDongsheng wrote: My question is: 1) Can TC4 work with jboss ? 2) is so, how can I do it ? Thanks, Dongsheng Song Although I don't use that combination, I don't see any reason why not. Unless, of course you want to run them in the same JVM. JBoss manual mentions that Catalina support is under way, so JBoss developers might be a better source of information. If you don't want to use the same JVM for both, then it should be really easy. Just normal JNDI/RMI instrumentation will do the trick. Bojan
Re: TC4: web.xml and reloading
Remy Maucherat wrote: Essentially, yes. JAR reloading is not very reliable on my Windows box, though (and you can't remove JARs; but strangely you can ovewrite them). Sometimes, the changes get picked up, sometimes they do not. I have yet to find the reasons for this, unfortunately :-( Swet! It means that I can package my properties files into a jar and the app will be reloaded when the new jar, with new properties arrives. As for Windows, I don't use the platform all that much (and not at all for Java). The ratio here is 6:1 in favour of Linux. Bojan
Re: ServletContext access question
Maybe you can use application init parameters instead? Bojan Viktors Krebss wrote: Hello, Does anyone know how can I access servlet init parameters form another servlet ? I mean I can access servlet context (context-param ) using getServletContext().getContext(/some_servlet) but what I need is to get into servlet...init-paramparam-I-need-to-know/init-param.../servlet . Is it possible at all ? Thanks for you help. Regards, -- Viktors Krebss, [EMAIL PROTECTED] SMC , http://www.smc.lv/ tel: +371-748, mob: +371-9243923, fax: +371-701
Re: FW: IIS+Tomcat Q
Maybe you can use getRemoteUser, isUserInRole, getUserPrincipal etc. from HttpServletRequest interface to find out who's logged on? Once the user is authenticated, you'll always get its info from the above and Tomcat will make sure that this guy is part of the correct session. Does that answer your question? Bojan Ratnakar Palle wrote: I've a very basic question about IIS+Tomcat integration. I've to validate the user against the NT domain. When the request comes in, IIS validates the user against NT and forwards the request to Tomcat. After user gets validated, how does the Tomcat keep the user in session?? I mean, how does the Tomcat make use of Servlet container session mechanism. Hope I was clear on my question.. Any help or pointers would be of great help... Thanks in advance, -Ratnakar
Re: Using Tomcat with MSAccess
What's the actual error message? Maybe you can print out the SQL statement to see if the syntax is OK. It could be invalid SQL. Are you running this under Windows NT/2000 or 9x/ME? Maybe the user Tomcat runs under doesn't have access rights on this database? I don't really use Access, I'm just trying to apply my PostgreSQL experiences... And maybe you can have a look at JBoss or similar EJB container. No more SQL... Bojan Jeffrey Worst wrote: I'm writing an applet using Tomcat to register new members for a library. Everything works fine until I get to the part where the new information is being inserted into the MSAccess DB. I have commented below where the error occurs. Any help would be appreciated. Thanks, Jeff
Re: Binding to a single IP
It's explained in the server.xml file... Promise to brush up on my reading skills :-) Bojan Bojan Smojver wrote: I've been looking through the docos to find how to bind Tomcat's connectors of Tomcat itself to just a single IP address (ie. 127.0.0.1), which is handy for securing it. Couldn't find anything... Can someone point me in the right direction? Bojan
Binding to a single IP
I've been looking through the docos to find how to bind Tomcat's connectors of Tomcat itself to just a single IP address (ie. 127.0.0.1), which is handy for securing it. Couldn't find anything... Can someone point me in the right direction? Bojan
mod_webapp (Tomcat 4.0 b2, b3): compilation quick fix
I've posted to this list a few days ago a message related to the
compilation problems of mod_webapp. It seems that the versions that come
with b2 and b3 of Tomcat 4.0 are screwed (even after cleaning double new
lines in Makefiles). I didn't have the patience to go through the code
to determine why (a lame way of saying that I don't have a clue what's
in there ;-)
The quick fix in order to get it to *compile* is to revert to b1
release. And just as an FYI, it can also be compiled and statically
linked into Apache. Just whack mod_webapp.c into webapplib directory,
put mod_webapp.o into the OBJS in the Makefile for webapplib. This will
place the object file into libwebapp.a after compilation. Then create a
directory under src/modules (Apache source) for it and copy the library
(libwebapp.a) there. Create Makefile.tmpl, for instance:
--
LIB=libwebapp.a
all: ${LIB}
${LIB}:
${RANLIB} $@
clean:
--
libwebapp.module file, for instance:
--
Name: webapp_module
ConfigStart
LIBS="-Lmodules/webapp -L../modules/webapp
-L../../modules/webapp -lwebapp -ldl $LIBS"
RULE_HIDE=yes
ConfigEnd
--
run configure (activate the module) and it should get into Apache after
you run make.
Back to testing its functionality now...
Bojan
Re: mod_webapp (Tomcat 4.0 b2, b3): compilation quick fix
It's a bit stupid to reply to your own post. Anyway...
Apache will fail to start with staticly linked mod_webapp due to the
fact that this module is not capable of handling the second pass of the
configuration file successfuly. It will report 'Duplicate connection
name'. The originating file is wa_connection.c. Since the
WebAppConnection has been defined in the first pass, it won't accept the
same one in the second pass because it checks for duplicate connections.
Bojan
Bojan Smojver wrote:
I've posted to this list a few days ago a message related to the
compilation problems of mod_webapp. It seems that the versions that come
with b2 and b3 of Tomcat 4.0 are screwed (even after cleaning double new
lines in Makefiles). I didn't have the patience to go through the code
to determine why (a lame way of saying that I don't have a clue what's
in there ;-)
The quick fix in order to get it to *compile* is to revert to b1
release. And just as an FYI, it can also be compiled and statically
linked into Apache. Just whack mod_webapp.c into webapplib directory,
put mod_webapp.o into the OBJS in the Makefile for webapplib. This will
place the object file into libwebapp.a after compilation. Then create a
directory under src/modules (Apache source) for it and copy the library
(libwebapp.a) there. Create Makefile.tmpl, for instance:
--
LIB=libwebapp.a
all: ${LIB}
${LIB}:
${RANLIB} $@
clean:
--
libwebapp.module file, for instance:
--
Name: webapp_module
ConfigStart
LIBS="-Lmodules/webapp -L../modules/webapp
-L../../modules/webapp -lwebapp -ldl $LIBS"
RULE_HIDE=yes
ConfigEnd
--
run configure (activate the module) and it should get into Apache after
you run make.
Back to testing its functionality now...
Bojan
mod_webapp compilation
Anyone out there had any luck compiling the mod_webapp? Even after removing double new lines from the Makefiles, there is a whole heap of compilation error messages (mostly undeclared stuff)... And if mod_webapp is not ready, can mod_jk be used with Tomcat 4.0? Configuration: RedHat Linux 7.0 Tomcat 4.0 b2 (b3 source not published) Bojan
Re: sdk 1.3.0 fcs and netscape plugin problem
Try to put the plugin in ~/.netscape/plugins instead. Bojan "Robert B. Easter" wrote: cd /usr/local/netscape/plugins ln -s /usr/local/j2sdk1.3.0/jre/plugin/i386/javaplugin.so javaplugin.so
Re: Passwod Protecting a directory
In tomcat's conf directory there is a file called tomcat-users.xml. There are a few user accounts already there (Tomcat 3.2.1), one is called 'tomcat', having a role 'tomcat' (a bit confusing but Java Servlet API Spec 2.2 might clear that up for you). Next set you web.xml file up. Something like: - ?xml version="1.0" encoding="ISO-8859-1"? !DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.2//EN" "http://java.sun.com/j2ee/dtds/web-app_2_2.dtd" web-app security-constraint web-resource-collection web-resource-nameDemo/web-resource-name url-pattern/*/url-pattern user-data-constraint transport-guaranteeNONE/transport-guarantee /user-data-constraint http-methodGET/http-method http-methodPOST/http-method /web-resource-collection auth-constraint role-nametomcat/role-name /auth-constraint /security-constraint login-config auth-methodBASIC/auth-method realm-nameExample/realm-name /login-config /web-app - should be sufficient to grant only 'tomcat' role permission to see the resource of the site '/*' (basically everything under tomcat's control). Note that this is done using basic authentication and there is no encryption involved. You might want to read JDBCRealm HOWTO if you wish to use an SQL database to store user accounts and roles. Hope this is useful (and correct :-) Bojan Tim Kang wrote: I was wondering if anybody knows how to password protect a directory in Tomcat environment Please let me know Thanks Tim
JSP engine init parameters
I've been trying for a while to implement the init parameters for JSP engine mentioned in Tomcat FAQ's but without much luck. First, I think the 'org.apache.jasper.runtime.JSPServlet' is wrong, there is no such class in Tomcat 3.2.1. It should probably be 'org.apache.jasper.servlet.JspServlet' instead. Anyway, I've tried putting the parameters like 'keepgenerated', 'sendErrToClient' etc. into web.xml file but Tomcat refuses to take them because it rejects duplicate servlet 'jsp'. Then I tried to put init parameters directly into the 'org.apache.tomcat.context.WebXmlReader' and rebuild the Tomcat distribution, but they didn't make any difference whatsoever to the behaviour of Tomcat. If I enable Jikes compiler through the same file it works fine. Does anyone have any ideas how to make this work? Thanks, Bojan
Re: Tomcat 3.2 - Default web.xml not being read
I just compiler the attached file into a class, put the class into the webserver.jar (to avoid changing CLASSPATH for testing) and modified server.xml file with: ContextInterceptor className="tc3.JasperOptions" sendErrToClient="false" keepgenerated="false" / after the WebXmlReader section and restarted Tomcat and Apache. The errors are still going to the browser and generated java files are still there. I was hoping this file would fix the problem I had with init parameters but it doesn't. I must be doing something really silly... Any ideas? Bojan [EMAIL PROTECTED] wrote: Given that the default web.xml is not being read, how do you enable Jikes as the JspCompiler? That setting used to be in web.xml. What's the syntax to specify it in server.xml, or did we lose this functionality for Tomcat 3.2? (If so, could it be put back, or define a syntax in server.xml for it?). I'll try to write a small interceptor that sets the compiler and other options for jasper ( probably next week it'll be ready ). ( that will not require a new release of tomcat - you just install the interceptor in the classpath and add it to tomcat.jar ). Ok, I don't think it'll be ready next week - you can use it today, it took 10 minutes to write and test :-) You can set all the options that jasper knows - compile the interceptor ( you need tomcat jars in CLASSPATH ), add it to CLASSPATH, and then add in your server.xml ( after WebXmlReader ): ContextInterceptor className="tc3.JasperOptions" keepGenerated="true" jspCompilerPlugin="org.apache.jasper.compiler.JikesJavaCompiler" / ( run javadoc and read all other options you can set ). It should work with any tomcat 3.2 - in 3.3 there is already one ( JspInterceptor ) that does a much better integration ( and is faster than the servlet used in 3.2 ). Costin Name: JasperOptions.java JasperOptions.javaType: Plain Text (TEXT/PLAIN) Encoding: BASE64
Re: mod_jk vs. statically linked Apache
I didn't actually say that the configuration works. It'll be some time before I know that for sure. But it does compile and link :-) If I understand correctly, DSO is described in Apache INSTALL file as optional. I have seen references in the jk code to dl related functions (and actually -ldl needs to be specified to link mod_jk into Apache successfully) and now I'm not sure if statically linking the module would affect it (and my limited knowledge suggests it shouldn't, but I could be dead wrong here). If it's not too much trouble, would you be able to explain why (technically) static linking isn't supported in mod_jk before I waste too much time on testing. Regards, Bojan Static linking was not an intended supported configuration, so there was no need to document it. The fact that it works at all means you are lucky. Craig McClanahan
mod_jk vs. statically linked Apache
I've noticed that there aren't any instructions about compiling and then statically linking mod_jk.so into Apache (mod_jk HOWTO from Tomcat 3.2). Is this intentional (ie. do you want to move people away from doing that) or is it just missing because most people prefer DSO? I've been able to compile and statically link mod_jk.o into Apache (on RedHat Linux 7.0), but it requires some fiddling. Would this be something others would like to know about? Bojan
