Re: Two modest proposals about common\lib
look at common.loader, server.loader and shared.loader in catalina.properties. That's what we use for the described purpose. Benson Margulies wrote: Remy, Can you send me a doc reference to the relevant properties? Maybe a howto is in order here. If there's already a capability to append lib/class/endorsed dirs in a prop file, then there's surely no reason to add some other place to configure the same thing. --benson - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
checkContextLastModified() question
Hi,
I'm looking into eliminating (or configuring) the delay between
modifying my web.xml files and restarting of the context during
development, which according to Yoav is not configurable. I looked into
the code. However, I don't quite understand the criterion which is used
to decide whether a reload should be performed.
starting in line 783 in HostConfig
if (newLastModified (webInfLastModified +
5000)) {
webXmlLastModified.remove(contextName);
restartContext(context);
} else {
webXmlLastModified.put
(contextName, new Long(newLastModified));
}
I don't understand the first comparison. The lastModified of web.xml
must be at least 5 seconds after the lastModified of the WEB-INF
directory? I'm sure I do not understand it correctly. Could someone
please shed some light on this?
Thanks in advance,
Robert
--
Robert Krüger
Signal7 GmbH
Brüder Knauss Str. 79
64285 Darmstadt
Germany
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Handling of JNDI ResourceLinks
Hi,
currently it is not possible to use ResourceLinks to bind a
UserTransaction in the java:comp context of a web application because
the way it is implemented ResourceLinks are always bound in the
java:comp/env context. I stumbled across this because I thought it would
make sense to configure my transaction manager only in one place and
have all my webapps access it via ResourceLinks instead of copying the
configuration for each webapp, which did not work. The current behaviour
is not documented and a little hard to understand. It is only a minor
thing (therefore I'm not filing a bug) but I would be grateful if you
could make that little change to make the behaviour a little more
consistent. I have attached a patch that does this which you may use if
you agree with the (rather simple) way I fixed it.
Thanks in advance and regards,
Robert
--
Robert Krüger
Signal7 GmbH
Brüder Knauss Str. 79
64285 Darmstadt
Germany
Index: catalina/src/share/org/apache/catalina/core/NamingContextListener.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/NamingContextListener.java,v
retrieving revision 1.4
diff --unified -r1.4 NamingContextListener.java
--- catalina/src/share/org/apache/catalina/core/NamingContextListener.java 2 Sep
2003 21:22:04 - 1.4
+++ catalina/src/share/org/apache/catalina/core/NamingContextListener.java 22 Jan
2004 09:46:03 -
@@ -939,10 +939,14 @@
addAdditionalParameters(resourceLink.getNamingResources(), ref,
resourceLink.getName());
try {
+javax.naming.Context ctx = envCtx;
+if(javax.transaction.UserTransaction.equals(resourceLink.getType())){
+ctx = compCtx;
+}
if (debug = 2)
log( Adding resource link + resourceLink.getName());
-createSubcontexts(envCtx, resourceLink.getName());
-envCtx.bind(resourceLink.getName(), ref);
+createSubcontexts(ctx, resourceLink.getName());
+ctx.bind(resourceLink.getName(), ref);
} catch (NamingException e) {
log(sm.getString(naming.bindFailed, e));
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: JMX 1.2 / JMX Remote 1.0
Simon, I think you're right. I observerd the same. I downloaded and built Tomcat 5 from CVS using the build.xml file provided on the website 3 days ago and the file jakarta-tomcat-5/build/common/lib/jmx.jar does not contain the JMX 1.2 classes. In my case my code broke because Monitor.addObserverdObject is not there (was added in 1.2). To make sure I checked in the class file and it is not there. Regards, Robert Simon Clare wrote: Hi This is probably: a: stupid b: annoying or possibly both but i'm having a bit of a problem with JMX specs in Tomcat. Am I right in thinking that JMX 1.2.1 RI is the current version within Tomcat 5 (http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24413)? However, the reference implementation (and spec) has the method: javax.management.MBeanServer.getClassLoaderRepository() But the JMX implementation bundled with Tomcat (5.016) does not (and throws a noSuchMethodException when I try and use it. My small mind has been throw into confusion, and I am contemplating Classpath order based hacks (shudder). simon clare FULL (AND BORING) DETAILS I'm connecting remotely to a JMX 1.2.1 RI JMX Server using the JMX 1.0 Remote RI and querying a few MBeans. This works a treat in a stand alone vanilla VM. However, inside a web container (weblogic and tomcat) where there is theortically all the JMX stuff allready there (minus the remote stuff) the same code does not work, it throws a NoSuchMethodException on javax.management.MBeanServer.getClassLoaderRepository(). Which is weird as this method should be there according to the JMX 1.2.1 spec. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Robert Krüger Signal7 GmbH Brüder Knauss Str. 79 64285 Darmstadt Germany - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
JUnit Testsuite instructions
Hi, I have just checked out and built Tomcat 5 from cvs (using the build.xml provided on the website) and was not able to find a JUnit Testsuite. Could someone send me a pointer to somewhere on the site where the testing procedures for Tomcat are documented if it exists? Thanks in advance, Robert -- Robert Krüger Signal7 GmbH Brüder Knauss Str. 79 64285 Darmstadt Germany - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
status of JTA integration
Hi, we're currently in the process of porting our applications from orion to tomcat 5. As our code relies on a JTA environment we tried JOTM (which seems to be the recommended JTA environment, especially taking into account the announcements regarding the Objectweb and Apache partnership). However, the JOTM integration does not appear to be very well maintained, e.g. many IMHO crucial pooling configuration parameters are not even exposed in their JNDI ObjectFactory. After changing that I ran into bugs with the connection pool and found the code rather hard to read and therefore took a look at tyrex (After all it is still the first choice for transaction management for geronimo according to the geronimo website). However, the tyrex project (although reopened) seems to be rather dead (practically no traffic on the list) and the tomcat integration does not seem to be maintained at all. However, the Tyrex concepts and code looked OK, therefore I hacked together a tomcat integration with ObjectFactories for UserTransaction, DataSource and TransactionManager which seems to work OK. Now I would like to know it there is an official position of the jakarta team regarding the use of a specific JTA environment now and in the near future (geronimo?) and if there is any interest in the code I produced for the tyrex integration (I already asked on the tyrex list but as stated above it appears to be rather dead and I got no answer). Thanks in advance for any comments, Robert -- Robert Krüger Signal7 GmbH Brüder Knauss Str. 79 64285 Darmstadt Germany - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: status of JTA integration
Remy Maucherat wrote: I'd like to point out that Geronimo does not have anything to do with either Tomcat or Jakarta. I missed that, you're right I thought JOTM was the TM of the moment :-( Oh well ... :-( The other useable TMs I know about is the one from JBoss. It embeds Tomcat, and you can configure JBoss to have just Tomcat + the TM + the DataSource (+ the management stuff) so maybe it can work for you. I might try that, although currently my patched version of tyrex works fine and I'm a little reluctant to put in a monster like jboss just for JTA and connection pooling but if the tyrex people will not accept my additions/fixes in CVS tyrex is of course a dead end and jboss might be the only sensible way to go. This was removed because people complained about bugs which were not fixed (since the project is no longer really active). So I'm reluctant to add back support. I got in touch with a Tyrex developer a few months ago, and suggested they added a standard ObjectFactory in their distribution. I don't know if they did it (if they did, great, there's no problem anymore). makes sense. I will try to contact the tyrex people again. If they don't want it, so be it. Thank you for the quick answers. They helped. Robert Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Robert Krüger Signal7 GmbH Brüder Knauss Str. 79 64285 Darmstadt Germany - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: status of JTA integration
Hi, I know about the jboss's modularity but currently only tomcat 4.x is integrated in jboss and I need 5.x. I will probably look into that once my current tyrex-based solution gives me any trouble. Thanks for the hint, Robert Jeff Tulley wrote: Last I checked (a while ago, admittedly), JBoss was architected such that you can deploy only the pieces you need - VERY modular. So, you can make it not a monster, but rather just Tomcat + JTA, if I am not mistaken. It seemed at the time (early JBoss 3.0 days) that such a thing was not that hard either. -- Robert Krüger Signal7 GmbH Brüder Knauss Str. 79 64285 Darmstadt Germany - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: status of JTA integration
I tried it before tyrex and got it to work but was not so happy with what I found there (see my first posting). Filip Hanik wrote: also look at http://jotm.objectweb.org/ I believe they have a tomcat integration - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Coyote Session-Handling
Hi, we're currently porting a number of applications from Orion to Tomcat 5 and I ran into a (not so dramatic) problem. I set up 2 virtual hosts (i.e. 2 Services) running on the same host but different port and deployed two web applications. Now it is not possible to use these two web applications simultaneously as they interfere with each other's session, i.e. the browser sends the JSESSIONID cookie to both sites (which is correct according to RFC 2109, I think, because they only differ in port) but Coyote considers the sent session ID invalid whenever I change from one application to the other and sets a new one effectively killing the session I had open in the other application. Is that behaviour intentional? The code of CoyoteRequest.doGetSession looks as if that was the case. One possible solution for that would be to allow opening a new session under the JSESSIONID that was passed to the web application (in my case the second one accessed). Are you aware of any negative implications of that approach (I believe orion does it that way)? In my case the current behaviour means that I cannot deploy frontend and backend of my application on the same host only differing in port, which of course can be overcome by using another host name but I would like to know if you think this limitation could be removed. Thanks in advance, Best regards, Robert -- Robert Krüger Signal7 GmbH Brüder Knauss Str. 79 64285 Darmstadt Germany - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
