Re: JSON Logging of Tomcat Access Log.
> On 27.05.2016, at 19:41, Christopher Schultz > wrote: > > AccessLogValve was written to conform to the age-old httpd log file > format, subject to whatever "pattern" you want to apply. > > You could sprinkle your pattern full of JSON stuff, but then > JSON-escaping wouldn't actually occur, etc. > > If you want JSON logging, you are going to have to write your own valve. logback has an additional module called logback-access[1], that implements an access log valve for Tomcat. You could then use a logbook appender that writes JSON, eg. the logstash-logback-encoder[2]. Disclaimer: I’ve never used that combination, and don’t know if there are incombatibilities. In theory, it should work. Rainer [1] http://logback.qos.ch/access.html [2] https://github.com/logstash/logstash-logback-encoder
Re: rotate catalina.out without restart?
> On 01.02.2016, at 16:42, Harald Dunkel wrote: > > Hi folks, > > would it be possible to integate apache's rotatelogs > into catalina.sh to support daily rotation of catalina.out > without restart? On linux, (system) logrotate ha a “copytruncate” option that could be used. You’d need to check whether that could lose some log lines though - and if you could live with that. Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: WebEx meeting invitation: Apache Tomcat: TLS key and certificate generation
On 27.01.2016, at 13:31, Mark Thomas wrote: > > All, > > The recording for this is now available on the Apache Tomcat YouTube > channel: https://www.youtube.com/channel/UCpqpJ0-G1lYfUBQ6_36Au_g I don’t know whether that has s.th. to do with the WebEX sound option, but the sound of the recording is much much better than before. Thanks! Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: WebEx meeting invitation: Apache Tomcat: TLS Virtual Hosting
Hi, > On 08.12.2015, at 11:41, Mark Thomas wrote: > The meetings are currently set up so you have to use a telephone to > connect to the audio. You can either dial in or get the system to call > you back. I am pretty sure that I have attended webex meetings with audio in the webex client. Would it be possible to set up future webinars like that? Having to use a phone is quite cumbersome. Also, audio quality of the youtube recording is really bad (at least this time). Any improvement would be appreciated. Thanks Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [PROPOSAL] Tomcat Webinar series
> On 12.11.2015, at 23:29, Mark Thomas wrote: > > All, > > I've been wondering if there would be any interest in a Tomcat Webinar > series. I'm thinking ~10 minutes of presentation followed by Q&A on > topics of interest to this community with the webinars taking place > every 1/2/4 weeks depending on interest. The webinars would also be > recorded and uploaded somewhere - probably youtube - and linked from > tomcat.apache.org. Great idea! > My initial thoughts on possible topics are: > > - Intro to Tomcat 9 (the first milestone release is in progress as > I type this) > > - TLS virtual hosting with Tomcat 9 > > - Generating TLS keys for Tomcat > > - HTTP/2 and Tomcat 9 > > - Connector selection: BIO vs NIO vs NIO2 vs APR > > - Proxy protocol choice HTTP vs AJP Great list. I wonder though, how thoroughly these can be covered in ~10 min. I’d rather watch a longer webinar, than one that only scratches the surface. Rainer Frey Product Development - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 7 / Java 7
On 03.02.2014, at 22:19, Singh, Ragini wrote: > Hello, > > I upgraded Java 1.6.45 to Java 1.7.51 using java-1.7.0-oracle.x86_64 : Oracle > Java Runtime Environment on RHEL 5. Used the "alternatives" command to make > the Java 7 as Java version. > Now in my custom startup script if I define JAVA_HOME as > JAVA_HOME="/usr/lib/jvm/java" tomcat 7 recognizes the java as 1.6 ( the > previous version) and gives this message > "INFO: The APR based Apache Tomcat Native library which allows optimal > performance in production environments was not found on the > java.library.path: /usr/lib/jvm/java-1.6.0-sun-1.6.0.45 > .x86_64/jre/lib/amd64/server:/usr/lib/jvm/java-1.6.0-sun-1.6.0.45.x86_64/jre/lib/amd64:/usr/lib/jvm/java-1.6.0-sun-1.6.0.45.x86_64/jre/../lib/amd64:/usr/java/packages/lib/amd64:/usr/lib > 64:/lib64:/lib:/usr/lib" > > I modified the JAVA_HOME to JAVA_HOME="/usr/lib/jvm/jre-1.7.0-oracle.x86_64". > Now tomcat starts and gives the message as > "INFO: The APR based Apache Tomcat Native library which allows optimal > performance in production environments was not found on the > java.library.path: > /usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib" > > I believe it is not recognizing the correct Java version which is 1.7. Am I > missing anything ? AFAICT Java 7 has removed $JAVA_HOME/jre/lib/[/ from the default java.library.path - this is independent of Tomcat. So it is very likely that Tomcat *is* using the desired Java now. Others have already written how to verify for sure. > Thank you, > -Ragini Rainer Frey - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] Curious difference in connection behaviour on database side DBCP vs. JDBC?
On 22.11.2013, at 02:20, Christopher Schultz wrote: >> I also think that this is a justifiable spec violation, and all I’m >> asking is that this fact is shown more prominently, esp. as JDBC >> pool is advertised as a drop-in replacement for DBCP. > > Fair enough. Care you file a documentation bug and possibly provide a > patch? Will do, not sure I’ll get to it before the weekend though. Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] Curious difference in connection behaviour on database side DBCP vs. JDBC?
On 20.11.2013, at 14:21, Christopher Schultz wrote: > Rainer, > FWIW, Connection.close also states this: > > " > Releases this Connection object's database and JDBC resources > immediately instead of waiting for them to be automatically released. > " > > Does that mean that all connection pools by design are in direct > violation of the JDBC spec? I assume you’re referring to the "Releases this Connection object's database resources” part, then yes, they’re in violation of the letter of the API spec. I’m not sure whether the Javadoc is regarded as binding as the spec document though. And following the letter would indeed defy the very purpose of the pool. The other pools that I know do free the JDBC resources though. And that’s the part of the behavior that is really visible to the application. (And yes, Javadoc says it is best practice to explicitly close the JDBC resources as early as possible, but it also states that one can get away with not doing so). I also think that this is a justifiable spec violation, and all I’m asking is that this fact is shown more prominently, esp. as JDBC pool is advertised as a drop-in replacement for DBCP. Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Curious difference in connection behaviour on database side DBCP vs. JDBC?
On 19.11.2013, at 14:45, Mark Thomas wrote: > On 19/11/2013 13:32, Carl Boberg wrote: > >> I have here an example of the way we close from the application, (the devs >> have named it dispose). From my untrained non java dev eye we do not seem >> to be doing statement.Close(); and Im curious if that might be the issue? >> If so, why does DBCP handle it nicely and not JDBC? > > Commons DBCP tracks Statements and ResultSets when they are created and > closes the associated Statements and ResultSets when the connection that > created them is returned to the pool. > > Tomcat's JDBC pool does not do this. This is one of the reasons that > Commons DBCP has a larger code base. JDBC spec states (9.4.4): > An application calls the method Connection.close() to indicate that it has > finished using a connection. All Statement objects created from a given > Connection > object will be closed when the close method for the Connection object is > called. Javadoc of Connection.close() and Statement.close() at least imply that as well. ResultSet’s Javadoc explicitly states that a ResultSet is closed when the statement is closed. AFAICT the JDBC pool uses (as most connection pools) the Connection.close() as means to return a connection to the pool. While I understand that the semantics of completely closing a standalone connection and returning a pooled connection is different, this behavior is still a (presumably deliberate) violation of the spec, and makes the usage non-transparent to the application code. IMO this should be clearly stated in the JDBC pool’s docs, in an easily visible way. Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [Fwd: Re: Parameters disappear from PUTs]
On Saturday 06 February 2010 03:27:23 c...@munat.com wrote: > Are you serious? [...] > I'm certain you're not suggesting that browsers be forced to insert a name > before the parameter string in every POST request. [...] > What does *any* of this have to do with a simple > post to the list explaining that parameters passed with a PUT request seem > to be stripped out by Tomcat [...] > It's a mystery to me. If you had properly formatted your message in a way that request headers, request body and response could be distinguished, you would've gotten a useful response sooner. I also misread this several times before I noticed, because it all looked like a big block of headers (quote characters intentionally removed): PUT /json/members/1b35d32f-714d-4393-b8c2-b4805e0c7a13 HTTP/1.1 Host: localhost:12344 User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive X-Requested-With: XMLHttpRequest Content-Type: application/x-www-form-urlencoded; charset=UTF-8 Referer: http://localhost:12344/ Content-Length: 297 Cookie: JSESSIONID=dexcmg3b1r45 emailAddress=bozo%40clown.com&title=Head%20Clown&nameGiven=Bozo&namesMiddle=The&nameFamily=Clown&namePreferred=Bozo&gender=Male&password=&passwordConfirm=&id=1b35d32f-714d-4393- b8c2- b4805e0c7a13&facebookName=bozo.the.clown&twitterName=i.am.bozo&flickrName=bozos.circus&linkedinName=mr.clown.to.you HTTP/1.x 201 Created Content-Length: 82 Content-Type: text/plain; charset=UTF-8 X-Lift-Version: 1.1-M4 Server: Jetty(6.1.22) > Chas. Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: How to solve the problem "java.lang.OutOfMemoryError: unable to create new native thread" in Tomcat5.5.26
On Monday 30 November 2009 10:57:04 Peter Chen wrote: > Hi, > > I meet one problem of OutOfMemoryError when I am running the > Tomcat5.5.26. The OS is Solaris 10 sparc, and the JVM version is > 1.5.0.12, and following is the detail of stack information. > > Nov 29, 2009 12:41:16 AM > > org.apache.tomcat.util.threads.ThreadPool$ControlRunnable run > > SEVERE: Caught exception (java.lang.OutOfMemoryError: unable to create > new native thread) executing > org.apache.tomcat.util.net.leaderfollowerworkerthr...@958b36, While Andre is right that system memory size and JVM parameters are important, this is not the usual OOM that heap space is full. Java is not able to create a OS level thread for a new Java thread. The most common cause seems to be that there is not enough memory to allocate for the thread stack, either because there is not enough system memory available, or the memory limit for the java process is reached. You might be able to increase the memory limit for the process, if OS permits that and you have enough physical memory. If the limit is indeed physical memory, cou can of course increase that or try to move other processes away from the machine. Otherwise you need to provide java with enough memory for the new thread. One approach is to reduce the stack size. There is a -Xss switch to java, but I don't know Solaris, so I'm not sure this works or is sufficient. Possibly the OS has also to be configured to use/allow a smaller stack size. Another approach is to reduce the other memory usage of the java process, by reducing heap (or perhaps permgen) size, so java can use more of its permitted memory for thread stacks instead of heap. See http://www.egilh.com/blog/archive/2006/06/09/2811.aspx and the links in the article. A completely different cause might be that Solaris imposes a limit of the number of threads, regardless of the memory/stack size, per process. Perhaps a Solaris expert has more info. Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Deployment specific configuration - best practice
On Tuesday 17 November 2009 01:15:52 Mark Thomas wrote: > Rainer Frey wrote: > > * settings in /META-INF/context.xml > > This one please. > > Tomcat will extract it on first deployment. OK that will fail but we can > then edit the extracted version and Tomcat will use that from then on. Thanks for the info, will do that. The actual problem is described in Message-Id: <200911161424.38011.rainer.f...@inxmail.de> (Webapp reload and DriverManager in Tomcat 6.0 trunk). Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Webapp reload and DriverManager in Tomcat 6.0 trunk
On Monday 16 November 2009 15:00:32 Pid wrote: > On 16/11/2009 13:54, Rainer Frey wrote: > > I forgot a very important information: the JDBC driver is in tomcat/lib > > because our server usually runs several instances of the same webapp, and > > the customers have to add the JDBC driver themselves because we can't > > supply them due to licensing issues. > > In your test servlet, can you add some logging to see which classloader > the successfully loaded driver class has, the first time you start the app? It is (as expected), the tomcat common classloader, also at reload. INFO: DBTestServlet: Class org.postgresql.Driver loaded by org.apache.catalina.loader.standardclassloa...@184ec44 ^^^ Tomcat start Nov 16, 2009 3:12:11 PM org.apache.catalina.core.ApplicationContext log INFO: DBTestServlet: connection established: org.postgresql.jdbc4.jdbc4connect...@121177e Nov 16, 2009 3:12:11 PM org.apache.catalina.core.ApplicationContext log INFO: ContextListener: contextInitialized() Nov 16, 2009 3:12:11 PM org.apache.catalina.core.ApplicationContext log INFO: SessionListener: contextInitialized() Nov 16, 2009 3:12:41 PM org.apache.catalina.core.ApplicationContext log INFO: DBTestServlet: Class org.postgresql.Driver loaded by org.apache.catalina.loader.standardclassloa...@184ec44 ^^^ Context reload Nov 16, 2009 3:12:41 PM org.apache.catalina.core.ApplicationContext log SEVERE: DBTestServlet: java.sql.SQLException: No suitable driver found for jdbc:postgresql://127.0.0.1/inxmail java.sql.SQLException: No suitable driver found for jdbc:postgresql://127.0.0.1/inxmail at java.sql.DriverManager.getConnection(DriverManager.java:602) at java.sql.DriverManager.getConnection(DriverManager.java:185) at com.inxmail.test.DBTestServlet.init(DBTestServlet.java:50) at javax.servlet.GenericServlet.init(GenericServlet.java:212) I uploaded the webapp again with this logging, and also uploaded the full servlet source file to http://download.inxmail.de/data/user/rfy/DBTestServlet.java Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat behind Apache reverse proxy
On Tuesday 11 August 2009 15:37:54 Rainer Frey wrote: > Also, properties from catalina.properties and from Java System Properties > are expanded, but it seems that catalina.properties takes precedence. I > find this surprising, because system properties are in my perception more > dynamic and runtime/individual start specific than values in a config file. > Is this intentional behavior? If not, should I report a bug? Out of curiosity: does anyone know where in the source the expansion of catalina.properties in server.xml is implemented? Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [ERROR] Cannot create JDBC driver of class '' for connect URL 'null'
On Tuesday 14 July 2009 10:42:19 Neil Youngman wrote: > I'm having trouble getting Oracle access from Axis2 to work under > Tomcat 6. I've spent a lot of time Googling and prodding and poking > the application and I haven't found a solution that works for me. > > Oddly the configuration I'm using seems to work for another > application. > > Let's start with the configuration in axis2/META-INF/context.xml, > which is: > > > > >auth="Container" > type="javax.sql.DataSource" > factory="org.apache.commons.dbcp.BasicDataSourceFactory" You are explicitly specifying the original DBCP factory class "org.apache.commons.dbcp.BasicDataSourceFactory" here. Is this for specific reason, and is the jar file available (I believe it needs to be in tomcat's lib dir, though I'm not sure if the resource is application specific)? What happens if you leave out the factory attribute? > Caused by: org.apache.tomcat.dbcp.dbcp.SQLNestedException: Cannot create > JDBC driver of class '' for connect URL 'null' at > org.apache.tomcat.dbcp.dbcp.BasicDataSource.createDataSource(BasicDataSourc >e.java:1150) at > org.apache.tomcat.dbcp.dbcp.BasicDataSource.getConnection(BasicDataSourceja >va:880) at Obviously the packaged and renamed tomcat DBCP factory is used. Maybe a tomcat fallback if the specified factory is not found? Also might there be a fallback for the JDBC driver if the driver is not found? Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
JMX remote access in Tomcat 5.0
Hi, [Disclaimer: I know well that Tomcat 5.0 is obsolete, an update is planned but not possible until later this year, and I don't want to leave the monitoring issues unaddressed until then.] I use Tomcat 5.0 with Java 6. In Java 6, local JMX access with jconsole is active by default. But when I connect, I only see the VM default MBeans. If I enable remote access (with System property com.sun.management.jmxremote.port=), but still connect localy via the Pid, I also see the Catalina and User trees in the MBeans page. Can anyone explain what the difference is? Also, I want to adapt the JmxRemoteLifecycleListener, that is in Tomcat Trunk (http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/mbeans/JmxRemoteLifecycleListener.java), for Tomcat 5. This code has undergone a few changes over time, regarding the usage of a seperate MBeanServer by Tomcat. First version did not account for that at all, intermediate versions configured Ports for both the platform and the separate tomcat MBeanServer. The newest revision then removed this again, with the remark that tomcat uses the platform MBeanServer. Could anyone help me understand this? Has there been a previous code change in Tomcat, that this change in the listener reflects? Or does this cause tomcat to use the platform MBeanServer? And what is the situation in Tomcat 5.0? Which revision of the lifecycle listener is the best one to base a backport for 5.0 on? One more question: the JmxRemoteLifecycleListener seems to be in trunk only, what is the state regarding inclusion in Tomcat 6.0? Thanks for any information Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Change thread name of HTTP worker threads at Runtime
On Friday 15 May 2009 16:58:55 Caldarale, Charles R wrote: > > From: Rainer Frey (Inxmail GmbH) [mailto:rainer.f...@inxmail.de] > > Subject: Re: Change thread name of HTTP worker threads at Runtime > > > > I just read this up. It says "should ensure". How strong this is > > sepends on whether this has RFC "SHOULD" characteristics, or is > > merely a recommendation. > > It's not a recommendation, it's a requirement. The Tomcat committers are > extremely careful about implementing the spec precisely. There's only one > thread that processes a request from start to finish. > > - Chuck Thanks for confirming. I didn't ever look at this aspect of servlet spec before. Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Change thread name of HTTP worker threads at Runtime
On Friday 15 May 2009 16:07:11 Christopher Schultz wrote: > Rainer, > > On 5/15/2009 2:37 AM, Rainer Frey (Inxmail GmbH) wrote: > > is the assumption that one request is processed by one thread (and never > > passed to another during processing) true for all connectors, including > > NIO? > > Are you asking if the request is passed to another thread at any point > for processing? Exactly, in my case I'm interested in the span between entering the application's filter chain and returning from it in the outmost filter. > Not likely, since Java doesn't support continuations. > The request handler thread should handle the request from start to finish. Is this explicitly stated somewhere? There could theoretically be a queue of Request/Response pairs, and different threads could pick one up, execute one element in the filter chain, and put the pair back for the next thread. > The servlet spec goes on to require (in section 8.2) that the container > dispatches sub-requests (includes or forwards) using the same thread > that was originally chosen to handle the primary request. I just read this up. It says "should ensure". How strong this is sepends on whether this has RFC "SHOULD" characteristics, or is merely a recommendation. > I think you're safe. I guess so too, but it's nice to hear opinions of people with insightinto internals. > -chris Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Change thread name of HTTP worker threads at Runtime
On Wednesday 06 May 2009 12:42:09 Ronald Klop wrote: > Op woensdag, 6 mei 2009 11:58 schreef "Rainer Frey (Inxmail GmbH)" :> > > > Hi, > > > > I occassionally have to analyse thread dumps of tomcat servers which > > serve up to 25 instances of the same (quite complex) web service > > application. All custom threads have names that contain the instance id, > > but it is impossible to see which HTTP processor threads serve which > > application instance. > > > > Now we came up with the idea to rename the threads at the beginning of > > the request processing (to current-name + application-id), and rename > > them back totheir base name after the request is processed. As these > > threads are managed by Tomcat, I am wondering: is this a bad idea? > > Anything in Tomcat (or Java) that could cause a problem if we do that? > > At the company I work we are doing this for a couple of years already with > Tomcat 4, 5 and now 6. Works very well. And makes threaddumps more easy to > read. > > Ronald. Thanks for confirming, I implemented this and it works fine. I wonder though: is the assumption that one request is processed by one thread (and never passed to another during processing) true for all connectors, including NIO? Regards Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Change thread name of HTTP worker threads at Runtime
Hi, I occassionally have to analyse thread dumps of tomcat servers which serve up to 25 instances of the same (quite complex) web service application. All custom threads have names that contain the instance id, but it is impossible to see which HTTP processor threads serve which application instance. Now we came up with the idea to rename the threads at the beginning of the request processing (to current-name + application-id), and rename them back totheir base name after the request is processed. As these threads are managed by Tomcat, I am wondering: is this a bad idea? Anything in Tomcat (or Java) that could cause a problem if we do that? Also, is this better implemented in the servlets (almost all our relevant requests go to servlets, the are hardly any JSP) or as a filter? Filter seems a better idea, but I never developed one, so I might overlook some characteristic that makes this unsuitable to do in a filter. We want to implement this first on Tomcat 5.0, but migrate to Tomcat 6.0 later this year. Any notable differences in this regard? TIA for any thoughts on this. Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Surprising auto-(un)deploy behavior
On Tuesday 31 March 2009 09:42:58 Mark Thomas wrote: > Rainer Frey (Inxmail GmbH) wrote: > > In Tomcat 6.0 deployment works the same, but when I delete the war file, > > the application is undeployed and the expanded directory is deleted. Is > > this change documented somewhere, > > Doesn't look like it Then, is this intended behavior, or a bug? Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Surprising auto-(un)deploy behavior
Hi, I just noticed a surprising behavior change between Tomcat 5.0 and Tomcat 6.0.18 regarding auto-undeployment of war files. I use both versions in default configuration, which means autoDeploy and unpackWARs are both true. (I don't think this matters much, but I tried this with Mac OS X and Java 5 as well as Linux and Java 6). In Tomcat 5.0, I copy the war file to the webapps directory, it is unpacked and deployed. Then I can delete the war file, and the web application runs and will be deployed on next start from the unpacked directory. In Tomcat 6.0 deployment works the same, but when I delete the war file, the application is undeployed and the expanded directory is deleted. Is this change documented somewhere, and is there a way to get the old behavior with tomcat 6.0? Also I think that in Tomcat 5, it was *necessary* to delete the war file to be able to edit the web.xml ofthe deployed application, otherwise it was overwritten from the war file at least at the next server start. What will Tomcat 6 do on startup in this case (a .war file *and* an expanded directory of the same webapp exist, with a newer web.xml in the expanded directory? My question regards development, so there is no need to convince me that autodeployment should not be used in production :-) Regards Rainer Frey - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: not valid Tomcat installation
On Monday 23 March 2009 03:22:05 Martin Gainty wrote: > you'll need to install the sysdeo tomcat plugin available from > http://www.eclipsetotale.com/tomcatPlugin.html > > (step by step instructions available at the site) sigh. development of the sysdeo plugin has stopped, the last release is for Eclipse 3.2, as is clearly visible from your link. To the OP: ignore this advice, unless yopu really use an old Eclipse release w/o the Web Tools feature. Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] Re: Vmware Server 2 web interface uses tomcat but hogs 8005 and 8009
On Tuesday 17 March 2009 15:23:03 André Warnier wrote: > +1 (confirming what Rainer says above). [...] > I also do not really see the interest in running a separate Tomcat on > the physical Linux server, since one can easily define a Virtual host > and run a Tomcat in there. To avoid misunderstandings: I see no problem in running tomcat on the host for use cases like mine. I'm a developer for a tomcat-based client/server application, and I run several instances of tomcat and VMWare server on my linux workstation. I use a Windows VM for our CRM tool and to test the windows version of or Java Swing UI. I also sometimes use additional linux VMs for other tests. It makes no sense for me to virtualize my development environment with tomcat, just to not run anything on the host out of principle. > This interface is sufficiently graphic and complex to deserve a Tomcat > to manage it. There is also a console applet, which you download and > install in the browser, and which allows, through the server, to obtain > a system tty console on each Virtual machine. Since we're offtopic anyway, some details for whoever might be interested (not trying to nitpick, just additional info): the console is no Java Applet, but a browser plugin, and is integrated into the server/vm management web UI. One can also create shortcuts to launch it standalone, after it has been installed in the browser. It does not only provide tty access, but also a VNC-like graphical interface if the guest has a GUI. Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
[OT] Re: Vmware Server 2 web interface uses tomcat but hogs 8005 and 8009
On Tuesday 17 March 2009 15:44:19 Alan Chaney wrote: > >> What do you mean with "the other end"? I use VMWare Server 2 on Ubuntu > >> (original tar.gz install from vmware.com), also found that it blocks the > >> said ports, and simply changed the server.xml of the VMWare Tomcat. > > And how did the client find it? If I missed how to do it, I apologize > for wasting everybody's time but there is no mention in the docs, I > could find nothing on Google and my experiments indicated that you need > to change both client and server and I could only find the server > configuration. > > > He still wants the web manager to work, and the /client/ expects to > > connect on a certain port. If you change VMWare's server-side ports, the > > client can no longer connect. Again: what "client" or "web manager"? And what "it"? The only client I know is my web browser. It connects to the HTTP or HTTPS connector port. I still can't see what would fail after changing the tomcat shutdown port, and the AJP connector port. I couldn't find anything that uses the AJP connector, so one could probably even disable the AJP connector. If you want help on that (which might be considered off-topic here), please answer this question, and also the question how you installed VMWare server. > Correct. I still don't understand why Vmware didn't make this configurable. Well, one can configure the tomcat for the web access like any other tomcat. The tomcat installation is difficut to find though and changes might be overwritten by an update. Apart from that, I don't understand what keeps you from configuring it. Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
[OT] Re: Vmware Server 2 web interface uses tomcat but hogs 8005 and 8009
On Tuesday 17 March 2009 14:46:35 Christopher Schultz wrote: > Rainer, > > > There is no special management instance. VMWare Server is an application > > that runs on a regular host operating system instance (it installs linux > > kernel modules though, and probably also Windows drivers). > > Interesting. This used to be called "VMWare Workstation". Different product. Workstation costs money, has support for 3D acceleration in guests, and host-guest integration stuff like shared folders. A reduced free variation is VMWare Player. VMWare Server is free of charge, optimized on running several VMs and being accessed from remote (Server Console in V1, web console plugin in V2). It is actually the successor of VMWare GSX Server. > > What do you mean with "the other end"? I use VMWare Server 2 on Ubuntu > > (original tar.gz install from vmware.com), also found that it blocks the > > said ports, and simply changed the server.xml of the VMWare Tomcat. > > He still wants the web manager to work, and the /client/ expects to > connect on a certain port. If you change VMWare's server-side ports, the > client can no longer connect. What client or web manager do you talk about? VMWare Server 2.0 has a browser interface, and the browser does not care about the Tomcat shutdown port or the (AFAIK totally unused) AJP connector port. As I wrote (and you did not quote) this browser interface works just fine on my system. Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Vmware Server 2 web interface uses tomcat but hogs 8005 and 8009
On Monday 16 March 2009 22:42:27 Christopher Schultz wrote: > > I spent some time looking to see whether these were configurable, but I > > found nothing, apart from a rather snotty message on the vmware bulletin > > boards stating that they didn't think that you should run a server on > > the same platform as a vmware setup > > Wait, what? > > They said "don't run Tomcat on a VMWare instance?" or "don't run Tomcat > on the VMWare manager instance?". > > Can you clarify this a bit? There is no special management instance. VMWare Server is an application that runs on a regular host operating system instance (it installs linux kernel modules though, and probably also Windows drivers). "They" (meaning this user on the VMWare community, who might or might not be associated with VMWare) say not to run server software on that host operating system. I take that as a recommendation to dedicate a machine to one purpose only (VM hosting in that case), which is common practice in many production environments, but no strict requirement. > > it stops working unless you can edit the 'other end' as it were and that > > doesn't appear possible. I hunted through all the available > > configuration files but the values must be hard-coded. What do you mean with "the other end"? I use VMWare Server 2 on Ubuntu (original tar.gz install from vmware.com), also found that it blocks the said ports, and simply changed the server.xml of the VMWare Tomcat. I don't find any problems with my VMWare installation, it works fine this way, including the start and stop scripts. Maybe the RPMs are different. To the OP: how did you install VMWare? > That's obnoxious. :( I think they should have configured other ports themselves, or at least put the configuration file for their tomcat in a more accessible place (on my system, it is in /usr/lib/vmware/webAccess/tomcat/apache-tomcat-6.0.16/), but it's more an inconvenience than a real problem, and might not affect that many VMWare users. > A good question to the VMWare team would be "hey, why did you use > heavy-ass Java for web interface when you're using virtualized hardware? > ever heard of lighttpd/php or whatever everybody embeds in their > routers?". Sheesh... Their web interface runs on the regular, non-virtualized host OS and provides a not too simple web application to configure, manage and monitor the VMWare server and the virtual machines. I wouldn't think that Java and Tomcat would be considered unsuitable for such a task on this list :-) > -chris Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Question regarding Tomcat memory
On Friday 14 November 2008 21:01:40 Caldarale, Charles R wrote: > > $CATALINA_OPTS -Xms8192M -Xmx8192M -Xss1024K > > Setting -Xss is usually not useful, unless your application is very, very > strange. AFAIK the default stack size of the JVM on 64bit linux is 2M. This is very large, and most apps don't need this much, unless they use deeply recursive algorithms. Setting Xss to a lower value reduces memory footprint of a single thread, and thus allows for more threads and/or larger heap with same amount of physical memory. Regards Rainer Frey -- Software Developer -- Inxmail GmbH Wentzingerstr. 21, 79106 Freiburg, Germany Tel: +49 761 296979-0, Fax: -9 [EMAIL PROTECTED], www.inxmail.de Handelsregister Freiburg, HRB 5870 Ust.-ID: DE198371679 Geschäftsleitung: Martin Bucher, Peter Ziras -- Inxmail Professional kostenlos testen: http://www.inxmail.de/jetzt-testen Tipps und Tricks für E-Mail-Marketers: http://www.inxmail.de/newsletter - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
