RE: JK2 config problem [RESOLVED]
Hmmm, I didn't forget the attachments but this mail list must not support attachments . . . So here is my original workers2.properties file: [logger] level=DEBUG [shm] file=d:/tomcat41/temp/shm.txt size=1048576 # dev communication channel [channel.socket:203.8.163.164:8009] info=channel for dev # dev worker [ajp13:203.8.163.164:8009] channel=channel.socket:203.8.163.164:8009 # sys test communication channel [channel.socket:203.8.163.166:8010] info=channel for sys test # sys test worker [ajp13:203.8.163.166:8010] channel=channel.socket:203.8.163.166:8010 # map all dev requests to dev worker [uri:203.8.163.164/*] info=map all group=ajp13:203.8.163.164:8009 # map all sys test requests to sys test worker [uri:203.8.163.166/*] info=map all group=ajp13:203.8.163.166:8010 And here is the simplified one: [logger] level=DEBUG [shm] file=d:/tomcat41/temp/shm.txt size=1048576 # dev communication channel [channel.socket:localhost:8009] info=channel for dev # dev worker [ajp13:localhost:8009] channel=channel.socket:localhost:8009 # sys test communication channel [channel.socket:localhost:8010] info=channel for sys test # sys test worker [ajp13:localhost:8010] channel=channel.socket:localhost:8010 # map all dev requests to dev worker [uri:203.8.163.164/*] info=map all group=ajp13:localhost:8009 # map all sys test requests to sys test worker [uri:203.8.163.166/*] info=map all group=ajp13:localhost:8010 Regards, Kent -Original Message- From: Subir Sengupta [mailto:[EMAIL PROTECTED] Sent: Friday, 27 February 2004 6:08 AM To: Tomcat Users List Subject: RE: JK2 config problem [RESOLVED] Did you forget the attachment? -Original Message- From: Kent Boogaart [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 25, 2004 7:30 PM To: '[EMAIL PROTECTED]' Subject: JK2 config problem [RESOLVED] Typical - as soon as I post I figure it out. All I had to do was alter the second IIS site so that the 'jakarta' virtual directory points to the same location as the first site (D:\tomcat41\bin\native\). With that modification, the existing workers2.properties file correctly forwards requests based on the host IP. In fact, the workers2.properties file can be simplified even further to be more readable. A simplified version is attached. Hope this info is useful to others . . . Regards, Kent Hello all, Here's my problem: I would like to have two Tomcat processes running on the one machine, each with a my web-app available via the default context (/). Furthermore, I would like each site to be available via IIS. I have tried for days to get this up and running but with no luck. I could not find any substantial documentation on workers2.properties configuration anywhere. Therefore I have been cross-referencing with JK1 configuration and with the JK2 source code. Following is my set up. Tomcat 1 Directory: D:\tomcat41\ Name: Development The jk2.properties for this tomcat contains: channelSocket.port=8009 The workers2.properties for this tomcat (which is shared for all Tomcats) is attached. As you can see, I have tried to resolve requests from the different IP addresses to the different Tomcats. The server.xml file for this tomcat contains this connector definition: Connector className=org.apache.coyote.tomcat4.CoyoteConnector acceptCount=10 bufferSize=2048 compression=off connectionLinger=-1 connectionTimeout=2 connectionUploadTimeout=30 debug=0 disableUploadTimeout=false enableLookups=true maxKeepAliveRequests=100 maxProcessors=75 minProcessors=5 port=8009 protocolHandlerClassName=org.apache.jk.server.JkCoyoteHandler proxyPort=0 redirectPort=8443 scheme=http secure=false serverSocketTimeout=0 tcpNoDelay=true tomcatAuthentication=true useURIValidationHack=false Factory className=org.apache.catalina.net.DefaultServerSocketFactory/ /Connector Tomcat 2 Directory: D:\tc_system_test\ Name: System test The jk2.properties for this tomcat contains: channelSocket.port=8010 The server.xml file for this tomcat contains exactly the same connector definition as Tomcat 1 except the port is 8010 instead of 8009. IIS Site 1 (Development) IP: 203.8.163.166 jakarta virtual dir points to: D:\tomcat41\bin\native\ IIS Site 2 (System Test) IP: 203.8.163.164 jakarta virtual dir points to: D:\tc_esm_system_test\bin\native\ Symptons When I navigate to the development site via http://203.8.163.166/ it works and I get my default page. When I navigate to the system test site via http://203.8.163.164/ I get a zero size reply error. If I go directly to Tomcat everything works OK. Looking at the ISAPI logs I can see that the development site logs this: HttpFilterProc started Virtual Host redirection
JK2 config problem
Hello all, Here's my problem: I would like to have two Tomcat processes running on the one machine, each with a my web-app available via the default context (/). Furthermore, I would like each site to be available via IIS. I have tried for days to get this up and running but with no luck. I could not find any substantial documentation on workers2.properties configuration anywhere. Therefore I have been cross-referencing with JK1 configuration and with the JK2 source code. Following is my set up. Tomcat 1 Directory: D:\tomcat41\ Name: Development The jk2.properties for this tomcat contains: channelSocket.port=8009 The workers2.properties for this tomcat (which is shared for all Tomcats) is attached. As you can see, I have tried to resolve requests from the different IP addresses to the different Tomcats. The server.xml file for this tomcat contains this connector definition: Connector className=org.apache.coyote.tomcat4.CoyoteConnector acceptCount=10 bufferSize=2048 compression=off connectionLinger=-1 connectionTimeout=2 connectionUploadTimeout=30 debug=0 disableUploadTimeout=false enableLookups=true maxKeepAliveRequests=100 maxProcessors=75 minProcessors=5 port=8009 protocolHandlerClassName=org.apache.jk.server.JkCoyoteHandler proxyPort=0 redirectPort=8443 scheme=http secure=false serverSocketTimeout=0 tcpNoDelay=true tomcatAuthentication=true useURIValidationHack=false Factory className=org.apache.catalina.net.DefaultServerSocketFactory/ /Connector Tomcat 2 Directory: D:\tc_system_test\ Name: System test The jk2.properties for this tomcat contains: channelSocket.port=8010 The server.xml file for this tomcat contains exactly the same connector definition as Tomcat 1 except the port is 8010 instead of 8009. IIS Site 1 (Development) IP: 203.8.163.166 jakarta virtual dir points to: D:\tomcat41\bin\native\ IIS Site 2 (System Test) IP: 203.8.163.164 jakarta virtual dir points to: D:\tc_esm_system_test\bin\native\ Symptons When I navigate to the development site via http://203.8.163.166/ it works and I get my default page. When I navigate to the system test site via http://203.8.163.164/ I get a zero size reply error. If I go directly to Tomcat everything works OK. Looking at the ISAPI logs I can see that the development site logs this: HttpFilterProc started Virtual Host redirection of 203.8.163.166 : 80 [/index.jsp] is a servlet url - should redirect to ajp13:203.8.163.166:8009 check if [/index.jsp] is pointing to the web-inf directory HttpExtensionProc started HttpExtensionProc got a worker for name ajp13:203.8.163.166:8009 channelSocket.receive(): Error receiving message body -1 53 workerEnv.processCallbacks() Error reading reply ajp13.service() ajpGetReply recoverable error 12 handler.response() Header[0] [Content-Type] = [text/html;charset=ISO-8859-1] handler.response() Header[1] [Content-Length] = [61] handler.response(): status=200 headers=2 Into jk_ws_service_t::head Into jk_ws_service_t::write HttpExtensionProc service() returned OK System test, on the other hand, contains this in the log: HttpFilterProc started In HttpFilterProc Virtual Host redirection of 203.8.163.164 : 80 HttpFilterProc [/index.jsp] is a servlet url - should redirect to ajp13:203.8.163.164:8010 HttpFilterProc check if [/index.jsp] is pointing to the web-inf directory It repeats these four lines 9 or 10 times and never reaches the HttpExtensionProc. Looking at the code I can see that the threadPool registry entry affects how the HttpExtensionProc is executed. I tried changing it from the existing value of 5 (which does not use a pool) to 10 (which should use the pool). It had no effect. Can anyone shed some light on this? I hope I have been clear in my explanation of the problem. If not, I would be happy to clarify. Thanks heaps for any help. Kent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
JK2 config problem [RESOLVED]
Typical - as soon as I post I figure it out. All I had to do was alter the second IIS site so that the 'jakarta' virtual directory points to the same location as the first site (D:\tomcat41\bin\native\). With that modification, the existing workers2.properties file correctly forwards requests based on the host IP. In fact, the workers2.properties file can be simplified even further to be more readable. A simplified version is attached. Hope this info is useful to others . . . Regards, Kent Hello all, Here's my problem: I would like to have two Tomcat processes running on the one machine, each with a my web-app available via the default context (/). Furthermore, I would like each site to be available via IIS. I have tried for days to get this up and running but with no luck. I could not find any substantial documentation on workers2.properties configuration anywhere. Therefore I have been cross-referencing with JK1 configuration and with the JK2 source code. Following is my set up. Tomcat 1 Directory: D:\tomcat41\ Name: Development The jk2.properties for this tomcat contains: channelSocket.port=8009 The workers2.properties for this tomcat (which is shared for all Tomcats) is attached. As you can see, I have tried to resolve requests from the different IP addresses to the different Tomcats. The server.xml file for this tomcat contains this connector definition: Connector className=org.apache.coyote.tomcat4.CoyoteConnector acceptCount=10 bufferSize=2048 compression=off connectionLinger=-1 connectionTimeout=2 connectionUploadTimeout=30 debug=0 disableUploadTimeout=false enableLookups=true maxKeepAliveRequests=100 maxProcessors=75 minProcessors=5 port=8009 protocolHandlerClassName=org.apache.jk.server.JkCoyoteHandler proxyPort=0 redirectPort=8443 scheme=http secure=false serverSocketTimeout=0 tcpNoDelay=true tomcatAuthentication=true useURIValidationHack=false Factory className=org.apache.catalina.net.DefaultServerSocketFactory/ /Connector Tomcat 2 Directory: D:\tc_system_test\ Name: System test The jk2.properties for this tomcat contains: channelSocket.port=8010 The server.xml file for this tomcat contains exactly the same connector definition as Tomcat 1 except the port is 8010 instead of 8009. IIS Site 1 (Development) IP: 203.8.163.166 jakarta virtual dir points to: D:\tomcat41\bin\native\ IIS Site 2 (System Test) IP: 203.8.163.164 jakarta virtual dir points to: D:\tc_esm_system_test\bin\native\ Symptons When I navigate to the development site via http://203.8.163.166/ it works and I get my default page. When I navigate to the system test site via http://203.8.163.164/ I get a zero size reply error. If I go directly to Tomcat everything works OK. Looking at the ISAPI logs I can see that the development site logs this: HttpFilterProc started Virtual Host redirection of 203.8.163.166 : 80 [/index.jsp] is a servlet url - should redirect to ajp13:203.8.163.166:8009 check if [/index.jsp] is pointing to the web-inf directory HttpExtensionProc started HttpExtensionProc got a worker for name ajp13:203.8.163.166:8009 channelSocket.receive(): Error receiving message body -1 53 workerEnv.processCallbacks() Error reading reply ajp13.service() ajpGetReply recoverable error 12 handler.response() Header[0] [Content-Type] = [text/html;charset=ISO-8859-1] handler.response() Header[1] [Content-Length] = [61] handler.response(): status=200 headers=2 Into jk_ws_service_t::head Into jk_ws_service_t::write HttpExtensionProc service() returned OK System test, on the other hand, contains this in the log: HttpFilterProc started In HttpFilterProc Virtual Host redirection of 203.8.163.164 : 80 HttpFilterProc [/index.jsp] is a servlet url - should redirect to ajp13:203.8.163.164:8010 HttpFilterProc check if [/index.jsp] is pointing to the web-inf directory It repeats these four lines 9 or 10 times and never reaches the HttpExtensionProc. Looking at the code I can see that the threadPool registry entry affects how the HttpExtensionProc is executed. I tried changing it from the existing value of 5 (which does not use a pool) to 10 (which should use the pool). It had no effect. Can anyone shed some light on this? I hope I have been clear in my explanation of the problem. If not, I would be happy to clarify. Thanks heaps for any help. Kent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Multiple JK2's on one Machine
Hello, I am attempting to set up two separate Tomcat installations on one machine, each available via IIS. The problem I have is that JK2 retrieves its configuration from the registry. Therefore, multiple JK2s on the same machine must have the same configuration. Is there a way to tell the JK2 to retrieve its configuration from a different registry key? Or perhaps there is some other way around this problem? O/S: Windows 2000 SP4 Tomcat Version: 4.1.29 IIS Version: 5.0 Thanks for any help, Kent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Retrieving the context path from a standalone class
Howdy, I took a look at lucene's indexing code. It seems like you can construct an Analyzer from a Reader (so an InputStreamReader constructed from the InputStream returned by ServletContext#getResourceAsStream would work), and then use a RAMDirectory as the IndexWriter's Directory argument. Alternatively you an use an FSDirectory if you want to save the index to disk, use the one directory where the container will let you write, the directory accessible via (File) servletContext.getAttribute(javax.servlet.context.tempdir); That should work, no? Won't that index the JSP source ? Probably. AFAIK there's no way to get the HTML that a JSP page would show without an actual request. Yoav Shapira Yes it does index the source code which was what I was trying to avoid. I understand that I need to request the page in order to execute it. That is why I was trying to construct a URL via which I could request it. Anyhow, everything's working fine in terms of indexing (including JSP execution). It's just that I was trying to eliminate the need for an environment variable for the context path. I will use Jacob's generic method of obtaining it instead of an env entry and all will be sweet. Thanks heaps for your help everyone, Kent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Retrieving the context path from a standalone class
Thanks for your input Shapira and Mike . . . don't get me wrong, I don't want the servlet spec to change unless it really is wrong in this regard. If it isn't then I want to know the correct way to deal with the problem. Sorry for my confusion about the recommended ServletRequestListener solution - it stems from the fact that this interface was introduced in the 2.4 API. I am using Tomcat 4.1 which, I understand, only supports the 2.3 API. I would need Tomcat 5 for such a solution but it is certainly nice to know. So let's consider the RequestDispatcher. As I mentioned, it is easy enough for me to get an appropriate instance of RequestDispatcher. The problem is, in order to include the response, I need an instance of ServletRequest and ServletResponse: public void RequestDispatcher.include(ServletRequest request, ServletResponse response) throws . . . I obviously don't have these in my indexing class. I considered rolling my own but how would I implement the getContextPath() method in HttpServletRequest? I'd be going around in circles. So what about the ServletContext.getResource(String) option? Well, I tried this and it returns a URL such as: jndi:/localhost/CONTEXT_PATH/FOLDER1/FOLDER2/NAME.jsp However, as you'd expect, reading this URL yields the contents of the JSP rather than the results of executing the JSP. I figured I could somehow easily translate this URL into a http URL. I looked at the URL(URL context, String spec) URL constructor but it does not help because of the changing of protocols. Of course, I could simply replace the jndi:/ with http://; and then insert the correct port number - which I have as an env entry :-( - but I'm not convinced this is a good idea either. The only thing I didn't understand in your email was the comment re docBase. I'm not sure what this is - in particular, are you talking HTML document base or some other mechanism - can you enlighten me? Actually I just thought of another argument for supplying deployment information to the developer - feel free to shoot me down. In my web app I have a filter called ProtocolFilter. It simply switches the client in and out of SSL as specified by filter options. In order to perform the switch, the ports must be known. I currently have these ports defined as env entries so that the filter (and other code) can pick them up. How else could I possibly do this? Thanks again, Kent Howdy, [kb] OK, but how can my app be agnostic of the context path if I need to do things like dynamically construct URLs? Why does the need to request a resource in the same web app constitute a design flaw? Surely this is a fairly common requirement . . . how else would I index dynamic resources? Also, if the web app should be completely agnostic of the context path, why does the HttpServletRequest interface define a method to retrieve it? The getContextPath method is there primarily to address HTML restrictions (links). Other ways to access dynamic resources revolve around using the docBase as your reference, not the server root, and include the RequestDispatcher calls and ServletContext#getResource calls. Both of these are agnostic of the context path as far as the application developer is concerned, which is good design. As you already mentioned, you can hack around this in various ugly ways, e.g. including the context path as a context-param in web.xml. This is an easy out many people take. But since you said you wanted to know the clean approach, and I was glad to hear that, I'm trying to explain that approach and the reasoning behind it. [kb] Not entirely sure what you mean here. Are you saying I should write a servlet that also implements ServletContextListener? If so, how do I No, that's not what I meant. I meant exactly what I said, I'll try it again without spaces when referring to servlet API classes: make your ServletContextListener also a ServletRequestListener. You will get notified when the first request comes in. At that time, you grab the context path and store it so that your other classes can retrieve it without needing an HttpServletRequest object. A filter is also a possible solution, and there are several others. Both the filter and the approach above will run the indexing on the first request, which is not what you want. (Although it's trivial to tie a wget request to the server startup script). Perhaps you can modify your existing indexing class to use ServletContext#getResource calls rather than whatever you're using now that requires the context path. Yoav Shapira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Retrieving the context path from a standalone class
Hi Shapira, Please see below for my responses. Regards, Kent Howdy, You're missing a few things: 1. The context path is (according to the spirit of the servlet spec) to be decided by the server administrator, just like the port on which the webapp will run. Your application should be completely agnostic of the actual context path. This is not a design flaw in the servlet API, but a flaw in your own application's current design. [kb] OK, but how can my app be agnostic of the context path if I need to do things like dynamically construct URLs? Why does the need to request a resource in the same web app constitute a design flaw? Surely this is a fairly common requirement . . . how else would I index dynamic resources? Also, if the web app should be completely agnostic of the context path, why does the HttpServletRequest interface define a method to retrieve it? 2. If you want to keep your current design, simply start the indexing thread when the first request comes in using its context path. You can, for example, have your servlet context listener class also be a servlet request listener, and do something on the first incoming request only. [kb] Not entirely sure what you mean here. Are you saying I should write a servlet that also implements ServletContextListener? If so, how do I instigate the first request to the servlet (again, without knowing the context path)? Wouldn't it make more sense to implement a filter and run the index the first time the filter runs? The filter could pass the context path to the indexing thread for subsequent usage. Of course, the indexing would only take place once a request is received - I'd rather a solution that allows the indexing to run on app startup. 3. This is a user, i.e. the tomcat-user list, question, so please continue discussion there. This list is for internal tomcat development discussions. [kb] Sorry, I knew that - just wasn't thinking straight on a Tuesday evening :-) Thanks, Yoav Shapira Millennium ChemInformatics -Original Message- From: Kent Boogaart [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 06, 2004 12:34 AM To: '[EMAIL PROTECTED]' Subject: Retrieving the context path from a standalone class Hi all, I have a class in my web app that runs in a separate thread. It's responsibility is to re-index the site every x minutes (I am using Lucene for site searches). It recursively loops over the relevant files within the web app folder and attempts to index each one (the web app must be exploded at this stage). I have this working for HTML and plain text resources. However, I would like to include JSPs in my index. Of course, I need to request each JSP to get any meaningful information for the index. I have a class that implements the ServletContextListener interface and stores a global reference to the ServletContext object. Originally I thought this would be all I needed to dynamically request JSPs. I figured you could retrieve the servlet context path from the ServletContext object in order to construct a URL to request - how silly of me! It seems you cannot retrieve the context path from anywhere other than the HttpServletRequest interface. Besides being a major design flaw (?), this complicates things for me. I cannot dynamically construct a request URL because I don't know the context path and my application must be able to run under any context path including the default one. I thought about using the ServletContext.getRequestDispatcher() method. However, I needed an implementation of HttpServletRequest and HttpServletResponse in order to use the dispatcher. HttpServletRequest, as I just mentioned, defines the getContextPath() method which I obviously can't implement. The JSPs in my application already rely on this method returning the correct context path. Hence, this was not an option. I also thought of having a servlet that loads on start-up set a global variable containing the context path. However, I would need the servlet to be requested in order to obtain an instance of HttpServletRequest from which I could extract the context path - the parameters to the init() method are of no help. A possible solution is to define an environment entry for the web app that duplicates the details of the context path. This is an awful solution and should not be necessary. Can anyone shed some light on this? Am I missing something embarrassingly obvious here? Thanks, Kent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat and Log4J
Howdy, Your problem is not log4j, it's commons-logging, which is nearly
always the culprit. The issue arises if log4j is in a classloader below
commons-logging, so
commons-logging doesn't know log4j is there. You're configuring log4j OK,
and if you used a log4j Logger rather than a commons-logging Log, you'd see
expected
behavior. But you're using a commons-logging Log, which uses the
commons-logging configuration, which is tied to your server and outputs to
the console. Yoav
Shapira Millennium ChemInformatics
Shapira,
Thanks for the advice. I tried using Log4J directly by one of my classes
and, like you said, it worked. However, I wanted to stick with commons
logging since this is (supposedly) the most flexible logging solution.
Therefore, I tried sticking log4j.jar into ${TOMCAT_HOME}/common/lib and
log4j.xml into ${TOMCAT_HOME}/common/classes. This worked for Tomcat classes
but not my own (my log output was still going to stdout). This had me
stumped.
After further stuffing around, one of my work collegues mentioned he'd
gotten around this problem by including commons-logging.jar and
commons-logging-api.jar in his web app. I tried this and it worked. I then
removed commons-logging-api.jar from my web app and it still worked.
In a way this all kind of makes sense - my web app has its own commons
logging package which finds the log4j package and the configuration.
However, I am surprised that this was all necessary. I am also surprised
that it is (I think) undocumented.
Anyways, thanks for your help.
Regards,
Kent
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Default context for web app
Didn't work. So I can't do what you're doing. Strange. Are you dead certain you don't have an /eSM/ context? Adam Hi Adam, It's a bit hard to tell for certain since I have disabled the manager app. However, I can tell you that there is only one directory below work/Standalone/localhost and it is called _. Tomcat used to create two directories here when it started two contexts - _ and eSM. Also, when I start Tomcat on the command line I can see that my webapp is only started once. I have a ServletContextListener implementation that outputs version details etc. I used to see this information output twice but now I only see it once. Regards, Kent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat and Log4J
All,
I have been trying all day to get Tomcat and Log4J to cooperate. I have
looked through many posts to this mailing list but have been unable to find
any extra information that helps me.
I am running Tomcat 4.1.27 on a Windows 2000 machine. My web app has
log4j-1.2.8.jar in its WEB-INF/lib directory. I have a config file called
log4j.xml in my WEB-INF directory. To load the configuration, I have a
ContextStartupListener implementation with this code in it:
//first things first - initialise the logging sub-system
try {
System.out.println(Initialising Log4J . . .);
String configFile =
WebAppContext.getContextParameter(log4j-config-file);
//provide default
if ((configFile == null) || (.equals(configFile.trim(
{
configFile = /WEB-INF/log4j.xml;
}
String filename =
getServletContext().getRealPath(configFile);
DOMConfigurator.configure(filename);
System.out.println(. . . done);
} catch (Throwable t) {
System.err.println(Exception occurred: + t);
t.printStackTrace(new PrintWriter(System.err));
}
//now create the log
log =
org.apache.commons.logging.LogFactory.getFactory().getInstance(StartupListen
er.class);
log.trace(trace enabled);
log.debug(debug enabled);
log.info(info enabled);
log.warn(warn enabled);
log.error(error enabled);
log.fatal(fatal enabled);
My log4j.xml file is defined as:
?xml version=1.0?
!DOCTYPE log4j:configuration SYSTEM log4j.dtd
log4j:configuration debug=false
xmlns:log4j=http://jakarta.apache.org/log4j/;
appender name=custom
class=org.apache.log4j.DailyRollingFileAppender
param name=File
value=${CATALINA_HOME}/logs/custom.log/
param name=DatePattern value='.'-MM-dd/
layout class=org.apache.log4j.PatternLayout
param name=ConversionPattern value=%d
%-5p [%c] %m%n/
/layout
/appender
root
level value=debug/
appender-ref ref=custom/
/root
/log4j:configuration
As you can see, I have tried to redirect all logging for my webapp to a
custom log file. If I set the log4j.debug system property to true, I can see
that Log4J is successfully finding and using my configuration file. Indeed,
the custom.log file is created. However, none of my log statements are
directed to this file. Instead, they go straight to the console as per
usual. Also, the debug level is the same as usual (ie. level is info instead
of debug as specified in config file).
What's really interesting is that there is some output in custom.log.
However, this output belongs to JBoss client classes (my application
utilises JBoss as an app server). Note that I am running Tomcat standalone -
not as part of a JBoss installation. Here is a sample from custom.log:
2003-12-17 14:54:13,653 DEBUG
[org.jboss.mq.referenceable.SpyConnectionFactoryObjectFactory] Extracting
SpyConnectionFactory from reference
2003-12-17 14:54:13,914 DEBUG
[org.jboss.mq.referenceable.SpyConnectionFactoryObjectFactory] The
GenericConnectionFactory is:
GenericConnectionFactory:[EMAIL PROTECTED],conne
ctionProperties={UIL_ADDRESS_KEY=203.8.163.174, PingPeriod=0,
UIL_PORT_KEY=8096, ClientILService=org.jboss.mq.il.uil.UILClientILService,
UIL_TCPNODELAY_KEY=yes}]
2003-12-17 14:54:13,974 DEBUG [org.jboss.mq.Connection] Setting the
clockDaemon's thread factory
2003-12-17 14:54:14,024 DEBUG
[org.jboss.mq.GenericConnectionFactory] Handing out ClientIL:
org.jboss.mq.il.uil.UILClientILService
2003-12-17 14:54:14,024 DEBUG
[org.jboss.mq.il.uil.UILClientILService] UILClientILService.run()
2003-12-17 14:54:14,134 DEBUG
[org.jboss.mq.referenceable.SpyDestinationObjectFactory]
SpyDestinationObjectFactory-getObjectInstance()
It seems Log4J is being used for JBoss client classes but not for my own.
What am I doing wrong here? I have also checked to ensure that
${CATALINA_HOME}/common/lib does not contain any logging-related JARs except
for commons-logging-api.jar. Similarly, I have made sure that my web app
does not contain any logging-related JARs except for log4j-1.2.8.jar.
Sorry for the long post and thanks for even reading this far. I'd appreciate
any help anyone can offer.
Thanks,
Kent
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Default context for web app
When I do that, I get a context at / and a context at eSM. In $TOMCAT_HOME/work/Standalone/localhost/ tomcat makes both _ and eSM. I use exactly the same context config as you, except some I don't declare since the defaults are the same. The only one I don't recognise is 'displayName' - can't see it in the docs. What is it? As I originally said, putting it in ROOT is the only way I have found to avoid this. But I guess it's not important. Adam Adam, Do you have autoDeploy and deployXml set to false in your Host element? If so then I'm not sure why you are getting two contexts . . . Kent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Default context for web app
Hi Adam, I am currently running against version 4.1.27 of Tomcat. I did not alter the name of my deploy directory. Here is my Context element (with env entries removed): Context className=org.apache.catalina.core.StandardContext cachingAllowed=true charsetMapperClass=org.apache.catalina.util.CharsetMapper cookies=true crossContext=false debug=0 displayName=eSM docBase=D:/tomcat41/bin/../webapps/eSM mapperClass=org.apache.catalina.core.StandardContextMapper path= privileged=false reloadable=false swallowOutput=false useNaming=true wrapperClass=org.apache.catalina.core.StandardWrapper ... /Context My WAR file is called eSM.war and, as you can see, my deploy directory is $TOMCAT_HOME/webapps/eSM. Note, however, that Tomcat uses $TOMCAT_HOME/work/Standalone/localhost/_ as the working directory for the web app since the path is . Regards, Kent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Default context for web app
Hi all, I am trying make my web application available via the default context. In other words, when I type http://localhost:8080/ in a browser on the local machine I want my web app to appear rather than the Tomcat default web app. I figured I'd just need to alter my context's path to (empty string) and alter the existing root context to use /root for it's path rather than . Whilst this kind of works (my web app is available via http://localhost:8080/) it has an unfortunate side effect. My web app is started up twice - once in the context and again in another context based on my web app's name (/eSM). How can I use the default context and only the default context for my web app? Thanks, Kent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Default context for web app
Wow - thanks for all the help people. Just thought I'd update you on how I resolved this. Firstly, I removed all Context elements from conf/server.xml except my own. Then I set autoDeploy to false on the Host element. This almost got everything working as required. However, the admin and manager web apps were still deployed which was unacceptable because they would be available via a live IP. This was because the deployXML attribute was set to true. I set this to false and then only my context was deployed. Thanks again! Kent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Jk2, IIS, BASIC Authorization problem
Hi, I have my web app set up to require BASIC authorization for a subdirectory. Everything works fine when running directly through Tomcat. However, when I run via IIS (version 5 on a win 2000 machine) it does not work. I have done some analysis and found that the Jk2 ISAPI filter appears to be stripping the authorization header off the request. Does anyone have any ideas how to work around this? I have read of other people having similar difficulties with jk1 but the resolution does not apply to jk2. Thanks for any help, Kent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat 4.1, IIS : configuring IIS log output
Hi all, My first post here. I am trying to get IIS to output the details of requests forwarded onto Tomcat rather than just the name of the ISAPI redirector DLL. For example, if IIS receives a GET request http://host/folder/index.jsp; it logs: [date] [time] [c-ip] GET /jakarta/isapi_redirector2.dll - 200 Mozilla/4.0+(compatible;+MSIE+5.01;+Windows+NT+5.0) I would prefer something like this in the log: [date] [time] [c-ip] GET /folder/index.jsp - 200 Mozilla/4.0+(compatible;+MSIE+5.01;+Windows+NT+5.0) This question has been asked before (http://www.mail-archive.com/[EMAIL PROTECTED]/msg32127.html) but I cannot find an answer anywhere. Can anyone point me in the right direction? Thanks, Kent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
