cvs commit: jakarta-tomcat-connectors/jk/conf jk2.properties
mturk 2002/08/16 01:20:28
Modified:jk/conf jk2.properties
Log:
To be able to use the jni inside the jk2.properties you will need at least
one channelJni directive. It can be anything (even channelJni.foo=bar).
This can be either bug (cause the directives are not checked), or feature
meaning that you need at least one directive to enable the channel itself.
Also IMO we should promote the 'inprocess' as a favorite option for using JNI,
and making LoadLibray from Java as depriciated.
Revision ChangesPath
1.10 +8 -0 jakarta-tomcat-connectors/jk/conf/jk2.properties
Index: jk2.properties
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/conf/jk2.properties,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- jk2.properties9 Aug 2002 17:36:17 - 1.9
+++ jk2.properties16 Aug 2002 08:20:28 - 1.10
@@ -12,4 +12,12 @@
# Just to check if the the config is working
# shm.file=${jkHome}/work/jk2.shm
+# In order to enable jni use any channelJni directive
+# channelJni.disabled = 0
+# And one of the following directives:
+
# apr.jniModeSo=/opt/apache2/modules/mod_jk2.so
+
+# If set to inprocess the mod_jk2 will Register natives itself
+# This will enable the starting of the Tomcat from mod_jk2
+# apr.jniModeSo=inprocess
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 11752] - Tomcat 4.0.4 does not play well with xerces2
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11752. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11752 Tomcat 4.0.4 does not play well with xerces2 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2002-08-16 09:05 --- CL bugs won't be fixed in 4.0.x. Use 4.1.x instead (or consider upgrading). -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 11754] - Synchronous shutdown script - shutdown.sh should wait until Tomcat is fully shut down
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11754. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11754 Synchronous shutdown script - shutdown.sh should wait until Tomcat is fully shut down [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2002-08-16 09:05 --- *** This bug has been marked as a duplicate of 11753 *** -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 11753] - Synchronous startup script - startup.sh should wait until Tomcat is fully started
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11753. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11753 Synchronous startup script - startup.sh should wait until Tomcat is fully started --- Additional Comments From [EMAIL PROTECTED] 2002-08-16 09:05 --- *** Bug 11754 has been marked as a duplicate of this bug. *** -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5] Config
[EMAIL PROTECTED] wrote: After a lot of thinking and searching, I found a solution that I think will work well. If you like it - I'll need some help from Remy to implement it. If you don't like it - I'm waiting for a better one... There are 3 major parts: 1. Config storage. Currently that's server.xml. 2. Configuring various components ( runtime config, init, etc ). That's done using digester/introspection in 4.x ( init ) and JMX ( at runtime ) 3. Saving config. That's done via introspecting life objects and generating server.xml in 4.x What I'm proposing is a pluggable config storage, using JNDI API for storage and JMX ( and introspection ) for runtime changes. For API - my initial approach was to create a clone of 1.4 prefs. I think a much better solution is to use JNDI as API. We already depend on JNDI, and JNDI is available to all VMs - including in GCJ, kaffe. The interface is mature, flexible and well known. In addition it is very easy to create wrappers to jdk1.4 prefs and back - so both 'flavors' can be used. The data will be organized to follow the JMX naming hierarchy ( after reorganizing the naming schema ): each tomcat component that is configurable will have a JMX name and associated attributes, and those will be stored in the directory. An ObjectName will be a jndi Name. We'll automatically gain access to all 'stores' that jndi supports - ldap, directory servers, etc. There are also file providers implementing standard xml formats ( or ldif ?). An additional format to support may be the jboss-style mbean - which may be syntactically closer to the jmx-based runtime. The second layer will be a wrapper that can use either introspection or JMX, possibly an extension of modeler. We'll have a clear distinction between 'persistent' config and 'runtime' config. JMX was not designed for storage ( even if it has the optional load/store methods ), and it is useful to be able to choose between making changes in the running server ( some may be temporary ) and making changes in the persistent store. Using notifications it is possible to propagate any change via JMX to the store - but that should be optional ( i.e. you could choose to not change the store, but only the runtime ). Any operation ( reload, etc ) will be done via JMX - only setting attributes is important for config. It is possible to also use DirContext to represent 'life' objects - and use the same API to set attributes on the persistent and life sub-trees. ( with JMX or introspection underneath ). There are few (major) issues with JMX - I don't know how well it will scale, giving the huge number of objects it involves. One way to solve this is to use mx4j internals - for example to delay some of the introspection, optimize some lookups, etc. Right now the JNDI model seems better suited for a large number of objects ( if we start representing each servlet as an mbean - for example to collect time information ). But overall JMX is the right way to go about configuring and operating on live objects, and JNDI is (IMO) the right way to go about storing hierarchical and config data. What do you think ? I love it :) This really seems to pick the best APIs for the job. It's a good idea to use JNDI for configuration storing indeed, as it allows enterprise scale deployments, and seems generally better suited than JMX. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5.0] [PROPOSAL] Refactored mapper
On Thu, 2002-08-15 at 15:37, Remy Maucherat wrote: [...] Yes, but welcome files for non physical resources cannot be implemented (since you have no way of asking a servlet if it can or cannot process a resource). I'll implement something which works and which is very close to what the spec requires. Again, I have sent many messages to the spec leads about this issue without any result, so I give up ... I don't completely understand the issue(s), but consider this, servlet-mapping servlet-nameBooServlet/servlet-name url-pattern/*.boo/url-pattern /servlet-mapping welcome-file-list welcome-fileindex.jsp/welcome-file welcome-fileindex.boo/welcome-file /welcome-file-list Is the problem that by the time the 'welcome file logic' gets a chance to handle the request, the logic that would have been able to pass this request off to a servlet is way too far up the call stack?It is almost like the DefaultServlet would need to open a connection to the loopback and check each welcome file URI to find one that gets to something useful (this is just a mental exercise, don't get excited I wouldn't think of implementing this.) Cheers, -bob -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5.0] [PROPOSAL] Refactored mapper
Bob Herrmann wrote: On Thu, 2002-08-15 at 15:37, Remy Maucherat wrote: [...] Yes, but welcome files for non physical resources cannot be implemented (since you have no way of asking a servlet if it can or cannot process a resource). I'll implement something which works and which is very close to what the spec requires. Again, I have sent many messages to the spec leads about this issue without any result, so I give up ... I don't completely understand the issue(s), but consider this, servlet-mapping servlet-nameBooServlet/servlet-name url-pattern/*.boo/url-pattern /servlet-mapping welcome-file-list welcome-fileindex.jsp/welcome-file welcome-fileindex.boo/welcome-file /welcome-file-list Is the problem that by the time the 'welcome file logic' gets a chance to handle the request, the logic that would have been able to pass this request off to a servlet is way too far up the call stack?It is almost like the DefaultServlet would need to open a connection to the loopback and check each welcome file URI to find one that gets to something useful (this is just a mental exercise, don't get excited I wouldn't think of implementing this.) It means that in that case, no matter what the URL is (as long as it ends with a '/'), it will end up to your_url/index.boo, which isn't good since it may be completely stupid (and your other entries in the welcome file list would get ignored), unless you have a way to verify that it is intelligent to forward to index.boo (it's easy to do for physical files, as you can check to see if it exists, but you can't do it in the general case). So it's possible to implement what is in the spec for physical files *or* for exact servlet mappings (where you consider that if a servlet is mapped to an exact URL without wildcards, and that you match that URL with a welcome file, you can assume it's a good idea to redirect). However, it's not possible for non physical resources (which is a new requirement). Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Adding a cookie via a filterChain...
Does anyone have some example code that adds a cookie to the response header via a filterChain in tomcat 4.0?? I am at a dead end and would really appreciate some help... Thanks, Les Parker This electronic mail transmission may contain confidential information and is intended only for the person(s) named. Any use, copying or disclosure by any other person is strictly prohibited. If you have received this transmission in error, please notify the sender via e-mail.
Re: [5] Config
SNIP/ What do you think ? I love it :) This really seems to pick the best APIs for the job. It's a good idea to use JNDI for configuration storing indeed, as it allows enterprise scale deployments, and seems generally better suited than JMX. Remy To the extent that JNDI and JMX do the jobs they were designed for, it makes perfect sense. JNDI is all about locating and retrieving data by name. JMX is mostly a runtime mechanism for component management. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Adding a cookie via a filterChain...
On Fri, 16 Aug 2002, Les Parker wrote:
Date: Fri, 16 Aug 2002 10:00:14 -0600
From: Les Parker [EMAIL PROTECTED]
Reply-To: Tomcat Developers List [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Adding a cookie via a filterChain...
Does anyone have some example code that adds a cookie to the response
header via a filterChain in tomcat 4.0?? I am at a dead end and would
really appreciate some help...
Adding a cookie in a filter is the same as adding one in a servlet, and
suffers the same restrictions. In particular, you won't be able to add
one after the response has been commited ... for example, this won't work:
public class MyFilter implements Filter {
public void doFilter(ServletRequest req, ServletResponse res,
FilterChain chain) {
// Pass the request on
chain.doFilter(req, res);
// Now try to add a cookie
((HttpServletResponse) res).addCookie(...);
}
}
Because the servlet will have committed the response already -- and
cookies are sent in the HTTP headers, so they need to be added before
that.
Another potential problem, even if you add the cookie before the response
is committed, is that a servlet can do RequestDispatcher.forward() -- or a
JSP page can do jsp:forward -- which will cause all the headers
(including your cookie) to be reset.
Details of how to deal with this depend on precisely what you're trying to
do, but may involve having to write a servlet response wrapper that
buffers the response data so that you can add the cookie after the fact
(with a potentially severe negative impact on performance).
Thanks,
Les Parker
Craig
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5.0] [PROPOSAL] Refactored mapper
On Thu, 2002-08-15 at 18:38, Patrick Luby wrote: Remy and Costin, I found the following draft wording that is being considered for the Servlet 2.4 spec. The exact wording may change, but the context should stay the same. Are there any unimplementable pieces in this proposed wording: The wording in the 4th paragraph in section 9.10 of the Servlet 2.4 spec may change to: The web server must append each welcome file in the order specified in the deployment descriptor to the partial request and check whether a [static] resource [or servlet] in the WAR is mapped to that request URI. The web container must send the request to the first resource in the WAR that matches [in the order of 1. a static resource, 2. a servlet that matches exactly, 3. a servlet that matches according to the path mapping rule]. Patrick Humm... how does this help? First, note that the extension mapping is not mentioned, so things like *.jsp, *.boo are not relevant to welcome files. Consider this, servlet-mapping servlet-nameBooServlet/servlet-name url-pattern/boo/*/url-pattern /servlet-mapping servlet-mapping servlet-nameFooServlet/servlet-name url-pattern/boo/foo/*/url-pattern /servlet-mapping servlet-mapping servlet-nameExServlet/servlet-name url-patternexactMatch/url-pattern /servlet-mapping welcome-file-list welcome-fileindex.html/welcome-file welcome-file/boo/AlwaysGoesHere/welcome-file welcome-file/boo/foo/NeverGetsHere/welcome-file welcome-fileexactMatch/welcome-file welcome-fileindex.jsp/welcome-file !-- how come extension mapping is ok here? or is it not ok. -- /welcome-file-list Somewhat confused (typical), Bob -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 5899] - HTTP POST parameters ignored in CGIServlet.java
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5899. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5899 HTTP POST parameters ignored in CGIServlet.java [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |ASSIGNED -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5] Config
On Fri, 16 Aug 2002, Steve Downey wrote: This really seems to pick the best APIs for the job. It's a good idea to use JNDI for configuration storing indeed, as it allows enterprise scale deployments, and seems generally better suited than JMX. Remy To the extent that JNDI and JMX do the jobs they were designed for, it makes perfect sense. JNDI is all about locating and retrieving data by name. JMX is mostly a runtime mechanism for component management. JMX has almost no support for storing the data ( the load/store are not even close to a real API like JNDI or prefs ). The real question for storage was JNDI or prefs - with prefs beeing a bit simpler. But I think as an API JNDI is far more powerfull and not that complex ( for simple tasks it is simple ). And it works in any VM ( including 1.1 ), is mature, etc. Both JMX and JNDI are about names and attributes. But JMX is very specialized to runtime. We could use JNDI for runtime API - it does have this flexibility - either as a wrapper on top of JMX or doing direct introspection. It is already used to store 'life' objects ( the java:env ), and it's not hard to extend it to support setAttribute() and operate like any DirContext on runtime objects. But it has no support for operations, and JMX has various unique features ( like SNMP, the HTTP adapter, etc ). Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5.0] [PROPOSAL] Refactored mapper
Bob Herrmann wrote: On Thu, 2002-08-15 at 18:38, Patrick Luby wrote: Remy and Costin, I found the following draft wording that is being considered for the Servlet 2.4 spec. The exact wording may change, but the context should stay the same. Are there any unimplementable pieces in this proposed wording: The wording in the 4th paragraph in section 9.10 of the Servlet 2.4 spec may change to: The web server must append each welcome file in the order specified in the deployment descriptor to the partial request and check whether a [static] resource [or servlet] in the WAR is mapped to that request URI. The web container must send the request to the first resource in the WAR that matches [in the order of 1. a static resource, 2. a servlet that matches exactly, 3. a servlet that matches according to the path mapping rule]. Patrick Humm... how does this help? First, note that the extension mapping is not mentioned, so things like *.jsp, *.boo are not relevant to welcome files. Consider this, servlet-mapping servlet-nameBooServlet/servlet-name url-pattern/boo/*/url-pattern /servlet-mapping servlet-mapping servlet-nameFooServlet/servlet-name url-pattern/boo/foo/*/url-pattern /servlet-mapping servlet-mapping servlet-nameExServlet/servlet-name url-patternexactMatch/url-pattern /servlet-mapping welcome-file-list welcome-fileindex.html/welcome-file welcome-file/boo/AlwaysGoesHere/welcome-file welcome-file/boo/foo/NeverGetsHere/welcome-file welcome-fileexactMatch/welcome-file welcome-fileindex.jsp/welcome-file !-- how come extension mapping is ok here? or is it not ok. -- /welcome-file-list Somewhat confused (typical), And imagine what users will say ;-) Basically, I read it as not using extension mapping for non physical resources, but only for physical resources (otherwise the default home page of Tomcat when you set it up won't work, which is a problem IMO ;-)). It now looks doable with the standalone Tomcat. It may still be unimplementable through Apache, though. My wish would be that only physical resources can be used as welcome files, so that the spec is implementable through a native webserver. (Quite frankly, the use case for the rest is very limited, and very confusing; plus it would impose a complex wording in the spec - still not right in that version) Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Adding a cookie via a filterChain...
Thanks Craig for your help.
Here is what does'nt seem to work... Any ideas??
public final class SessionControlFilter implements Filter
{
private String attribute = null;
private FilterConfig filterConfig = null;
public void init(FilterConfig filterConfig) throws ServletException
{
this.filterConfig = filterConfig;
this.attribute = filterConfig.getInitParameter(attribute);
sessionController = SessionController.getInstance();
}
public void doFilter(ServletRequest request, ServletResponse response, FilterChain
chain)
throws IOException, ServletException
{
if (attribute != null) request.setAttribute(attribute, this);
if(getCookie((HttpServletRequest)request, CHOCLATE_CHIP) == null)
{
makeCookie((HttpServletResponse)response, CHOCLATE_CHIP, CLIENT, 666);
}
chain.doFilter(request, response);
}
public static Cookie getCookie(HttpServletRequest request, String name)
{
Cookie[] cookies = request.getCookies();
Cookie myCookie = null;
for (int i=0;icookies.length ;i++ )
{
if (cookies[i].getName().equals(name))
{
myCookie = cookies[i];
break;
}
}
return myCookie;
}
public void makeCookie(HttpServletResponse response, String name, String channel,
String visitorId)
{
String value = channel + | + visitorId;
Cookie newCookie = new Cookie(name, value);
newCookie.setPath(/);
newCookie.setComment(No comment.);
newCookie.setMaxAge(31536);
newCookie.setVersion(1);
response.addCookie(newCookie);
}
public void destroy()
{
this.attribute = null;
this.filterConfig = null;
}
}
This electronic mail transmission may contain confidential information and is intended
only for the person(s) named. Any use, copying or disclosure by any other person is
strictly prohibited. If you have received this transmission in error, please notify
the sender via e-mail.
Re: [5.0] [PROPOSAL] Refactored mapper
Remy, Remy Maucherat wrote: It now looks doable with the standalone Tomcat. It may still be unimplementable through Apache, though. My wish would be that only physical resources can be used as welcome files, so that the spec is implementable through a native webserver. (Quite frankly, the use case for the rest is very limited, and very confusing; plus it would impose a complex wording in the spec - still not right in that version) I really don't like this spec change either. After carefully reading the revised wording, it still seems that spec is saying if I can't find any of the listed static welcome files, start looking for anything that can serve up a response. OK, maybe I am being overly dramatic, but it seems that the spec is trying to apply complex pattern matching rules to when the user requests the / resource and the webapp is missing all of the static welcome file resources. As far as I can tell, the only time the servlet mapping gets used is when the webapp has, for example /index.html as a welcome file and then then the webapp developer forget to put a index.html file in the webapp. Am I missing some bigger and better feature? Or is this spec trying to solve a problem that can be easily handled with the existing welcome file behavior? Patrick -- Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-5 BUILDING.txt build.properties.default
patrickl2002/08/16 10:03:19
Modified:.BUILDING.txt build.properties.default
Log:
Update build instructions to user JTA 1.0.1a and correct commons-digester build
error.
Submitted by: Steve Downey ([EMAIL PROTECTED])
Revision ChangesPath
1.20 +27 -9 jakarta-tomcat-5/BUILDING.txt
Index: BUILDING.txt
===
RCS file: /home/cvs/jakarta-tomcat-5/BUILDING.txt,v
retrieving revision 1.19
retrieving revision 1.20
diff -u -r1.19 -r1.20
--- BUILDING.txt 16 Aug 2002 02:04:14 - 1.19
+++ BUILDING.txt 16 Aug 2002 17:03:19 - 1.20
@@ -81,8 +81,9 @@
that you unpack ldap.jar and jaas.jar into the lib subdirectory of
the JNDI directory, parallel to jndi.jar.
-* This is optional with JDK 1.3 or later.
-
+* This is optional with JDK 1.3 or later. It is required for building
+ with full.dist=on. The build process expects this to be in
+ {base.path}/jndi-1.2.1.
(4) Download and Install the Xerces 2 Distribution
@@ -291,8 +292,11 @@
http://java.sun.com/products/jdbc/download.html
-* Place the jar in a convenient location.
+* Place the jar in a convenient location. The build process expects it
+ in ${base.path}/jdbc2_0-stdext.
+* No Tomcat class depends on JDBC directly. Tyrex and commons-dbcp
+ depend on it, and it is distributed with a full distribution.
(14) Download and Install an implementation of the JMX 1.0 specification. This
can be either MX4J (http://mx4j.sourceforge.net) or Sun JMX 1.0 Reference
@@ -322,7 +326,10 @@
http://java.sun.com/products/javabeans/glasgow/jaf.html
* Unpack the package into a convenient location so that it
- resides in its own subdirectory.
+ resides in its own subdirectory. The build process expects this by
+ default to be in ${base.path}/jaf-1.0.1
+
+* The Java Activation Framework is used by the JavaMail optional package.
(16) Download and Install JavaMail 1.2
@@ -332,7 +339,10 @@
http://java.sun.com/products/javamail/index.html
* Unpack the package into a convenient location so that
- it resides in its own subdirectory.
+ it resides in its own subdirectory. The build process expects this
+ by default to be in ${base.path}/javamail-1.2
+
+* JavaMail is used to provide JNDI named mail sessions.
(17) Download and Install the JSSE 1.0.2 Reference Implementation
@@ -343,17 +353,25 @@
http://java.sun.com/products/jsse/
* Unpack the reference implementation into a convenient location so that
- it resides in its own subdirectory.
+ it resides in its own subdirectory. The build expects this to be in
+ ${base.path}/jsse-1.0.2.
+
+* This is optional with JDK 1.4 and later.
+
+* Used to provide SSL and Certificate support in Catalina and in Connectors.
(18) Download and Install the Java Transaction APIs
-* Download the Java Transaction API (JTA) package (version 1.0.1) from:
+* Download the Java Transaction API (JTA) package (version 1.0.1a) from:
http://java.sun.com/products/jta/
* Unpack the package into a convenient location so that it resides in its
- own subdirectory.
+ own subdirectory. By default, the Tomcat build expects this to be
+ {base.path}/jta-1_0_1a/
+
+* Used to provide JNDI named transaction factories.
(19) Download and Install the Struts Binary Distribution
1.29 +6 -6 jakarta-tomcat-5/build.properties.default
Index: build.properties.default
===
RCS file: /home/cvs/jakarta-tomcat-5/build.properties.default,v
retrieving revision 1.28
retrieving revision 1.29
diff -u -r1.28 -r1.29
--- build.properties.default 16 Aug 2002 02:04:14 - 1.28
+++ build.properties.default 16 Aug 2002 17:03:19 - 1.29
@@ -73,8 +73,8 @@
# - Commons Digester, version 20020815 or later -
-commons-digester.home=${base.path}/commons-digester/dist
-commons-digester.lib=${commons-digester.home}
+commons-digester.home=${base.path}/commons-digester
+commons-digester.lib=${commons-digester.home}/dist
commons-digester.jar=${commons-digester.lib}/commons-digester.jar
commons-digester.loc=jakarta-commons/digester
@@ -192,10 +192,10 @@
jsse.jar=${jsse.lib}/jsse.jar
-# - Java Transaction API (JTA), version 1.0.1 or later -
-jta.home=${base.path}/jta-spec1_0_1
+# - Java Transaction API (JTA), version 1.0.1a or later -
+jta.home=${base.path}/jta-1_0_1a
jta.lib=${jta.home}
-jta.jar=${jta.lib}/jta-spec1_0_1.jar
+jta.jar=${jta.lib}/jta.jar
# - JUnit Unit Test Suite, version 3.7 or later -
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL
Re: Adding a cookie via a filterChain...
On Fri, 16 Aug 2002, Les Parker wrote:
Date: Fri, 16 Aug 2002 10:57:03 -0600
From: Les Parker [EMAIL PROTECTED]
Reply-To: Tomcat Developers List [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: Adding a cookie via a filterChain...
Thanks Craig for your help.
Here is what does'nt seem to work... Any ideas??
This should really be moved over to TOMCAT-USER where it belongs ... but
does your servlet/JSP page use forwarding? If so the cookie you create
will still get wiped out.
Craig
public final class SessionControlFilter implements Filter
{
private String attribute = null;
private FilterConfig filterConfig = null;
public void init(FilterConfig filterConfig) throws ServletException
{
this.filterConfig = filterConfig;
this.attribute = filterConfig.getInitParameter(attribute);
sessionController = SessionController.getInstance();
}
public void doFilter(ServletRequest request, ServletResponse response,
FilterChain chain)
throws IOException, ServletException
{
if (attribute != null) request.setAttribute(attribute, this);
if(getCookie((HttpServletRequest)request, CHOCLATE_CHIP) == null)
{
makeCookie((HttpServletResponse)response, CHOCLATE_CHIP, CLIENT, 666);
}
chain.doFilter(request, response);
}
public static Cookie getCookie(HttpServletRequest request, String name)
{
Cookie[] cookies = request.getCookies();
Cookie myCookie = null;
for (int i=0;icookies.length ;i++ )
{
if (cookies[i].getName().equals(name))
{
myCookie = cookies[i];
break;
}
}
return myCookie;
}
public void makeCookie(HttpServletResponse response, String name, String channel,
String visitorId)
{
String value = channel + | + visitorId;
Cookie newCookie = new Cookie(name, value);
newCookie.setPath(/);
newCookie.setComment(No comment.);
newCookie.setMaxAge(31536);
newCookie.setVersion(1);
response.addCookie(newCookie);
}
public void destroy()
{
this.attribute = null;
this.filterConfig = null;
}
}
This electronic mail transmission may contain confidential information and is
intended only for the person(s) named. Any use, copying or disclosure by any other
person is strictly prohibited. If you have received this transmission in error,
please notify the sender via e-mail.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5.0] [PROPOSAL] Refactored mapper
On Fri, 16 Aug 2002, Remy Maucherat wrote: The wording in the 4th paragraph in section 9.10 of the Servlet 2.4 spec may change to: The web server must append each welcome file in the order specified in the deployment descriptor to the partial request and check whether a [static] resource [or servlet] in the WAR is mapped to that request URI. The web container must send the request to the first resource in the WAR that matches [in the order of 1. a static resource, 2. a servlet that matches exactly, 3. a servlet that matches according to the path mapping rule]. Patrick Humm... how does this help? First, note that the extension mapping is not mentioned, so things like *.jsp, *.boo are not relevant to welcome files. Very good point Bob. The new wording brakes other pieces. My wish would be that only physical resources can be used as welcome files, so that the spec is implementable through a native webserver. (Quite frankly, the use case for the rest is very limited, and very confusing; plus it would impose a complex wording in the spec - still not right in that version) +1 My view of the correct behavior ( and others have spent more time with that than me, and they should speak ): - first check for static files. If one is found, that'll do it. That's what the server does - if the file is present. Normal extension mapping will be used on the file. - check for exact or prefix mappings. That will cover precompiled JSPs. - don't check for extension mapping if no physical file is present. There is no way to know if an extension-mapped resource actually exist - so any way you turn it, it can't be used for welcome files without some extra info. The file existence can do that. Keep in mind that extension mapping is a fundamental concept from web servers that was screwed in the servlet spec - no existing server does extension mapping without a physical file. PathInfo is just another victim of 'redefining' and 'extending' a de-facto standard. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5.0] [PROPOSAL] Refactored mapper
On Fri, 16 Aug 2002, Patrick Luby wrote: I really don't like this spec change either. After carefully reading the revised wording, it still seems that spec is saying if I can't find any of the listed static welcome files, start looking for anything that can serve up a response. OK, maybe I am being overly dramatic, but it seems that the spec is trying to apply complex pattern matching rules to when the user requests the / resource and the webapp is missing all of the static welcome file resources. As far as I can tell, the only time the servlet mapping gets used is when the webapp has, for example /index.html as a welcome file and then then the webapp developer forget to put a index.html file in the webapp. Or index.jsp ? If index.jsp has been precompiled - you need path mapping. What if you have struts and index.do ? With no real file in the dir, but some definition in an xml file ? Am I missing some bigger and better feature? Or is this spec trying to solve a problem that can be easily handled with the existing welcome file behavior? There is no 'existing welcome file behavior' in the servlet spec. The spec has allways been broken, and people just ignored it and implemented what the web servers are doing and users expect. The root of the problem is the extension mapping definition that can't check for existence of the resource ( since the resource is no longer there ). You either exclude extension mapping, or allow only 'normal' extension mapping ( the one used by web servers ). Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[5][PATCH] Fix the JUnit tests in Catalina
This patch fixes the JUnit tests in Catalina to run against the ROOT webapp. Now 'ant test' succeeds. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5][PATCH] Fix the JUnit tests in Catalina
Steve Downey wrote:
This patch fixes the JUnit tests in Catalina to run against the ROOT webapp.
Now 'ant test' succeeds.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Index: catalina/build.xml
===
RCS file: /home/cvspublic/jakarta-tomcat-catalina/catalina/build.xml,v
retrieving revision 1.17
diff -u -r1.17 build.xml
--- catalina/build.xml 15 Aug 2002 13:56:31 - 1.17
+++ catalina/build.xml 16 Aug 2002 17:50:09 -
@@ -15,7 +15,7 @@
property name=catalina.dist value=${catalina.home}/dist/
property name=test.failonerror value=true/
property name=test.runner value=junit.textui.TestRunner/
- property name=test.webapp value=../webapps/build/examples/
+ property name=test.webapp value=../webapps/build/ROOT/
property name=test.webapp.war value=${java.io.tmpdir}/webapp.war/
!-- Source dependencies --
Index: catalina/src/test/org/apache/naming/resources/BaseDirContextTestCase.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-catalina/catalina/src/test/org/apache/naming/resources/BaseDirContextTestCase.java,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 BaseDirContextTestCase.java
--- catalina/src/test/org/apache/naming/resources/BaseDirContextTestCase.java 18 Jul
2002 16:47:31 - 1.1.1.1
+++ catalina/src/test/org/apache/naming/resources/BaseDirContextTestCase.java 16 Aug
+2002 17:50:10 -
@@ -139,8 +139,7 @@
* directory context.
*/
protected static final String topLevelNames[] =
-{ images, jsp, servlets, META-INF, WEB-INF };
-
+{ index.jsp, jakarta-banner.gif, tomcat.gif, tomcat-power.gif,
+META-INF, WEB-INF };
/**
* The set of names that should be present in the WEB-INF
@@ -247,7 +246,7 @@
// Look up the WEB-INF entry
Object webInfEntry = context.lookup(WEB-INF);
assertNotNull(Found WEB-INF entry, webInfEntry);
-assert(WEB-INF entry is a DirContext,
+assertTrue(WEB-INF entry is a DirContext,
webInfEntry instanceof DirContext);
DirContext webInfContext = (DirContext) webInfEntry;
@@ -303,7 +302,7 @@
// Look up the WEB-INF entry
Object webInfEntry = context.lookup(WEB-INF);
assertNotNull(Found WEB-INF entry, webInfEntry);
-assert(WEB-INF entry is a DirContext,
+assertTrue(WEB-INF entry is a DirContext,
webInfEntry instanceof DirContext);
DirContext webInfContext = (DirContext) webInfEntry;
@@ -353,20 +352,20 @@
while (ne.hasMore()) {
Object next = ne.next();
-assert(list() returns NameClassPair instances,
+assertTrue(list() returns NameClassPair instances,
next instanceof NameClassPair);
NameClassPair ncp = (NameClassPair) next;
-assert(Name ' + ncp.getName() + ' is expected,
+assertTrue(Name ' + ncp.getName() + ' is expected,
isListed(ncp.getName(), list));
if (isDirContext(ncp.getName())) {
-assert(Class ' + ncp.getClassName() + ' is ' +
+assertTrue(Class ' + ncp.getClassName() + ' is ' +
contextClassName + ',
contextClassName.equals(ncp.getClassName()));
}
-assert(Relative is 'true', ncp.isRelative());
+assertTrue(Relative is 'true', ncp.isRelative());
}
@@ -391,30 +390,30 @@
while (ne.hasMore()) {
Object next = ne.next();
-assert(listBindings() returns Binding instances,
+assertTrue(listBindings() returns Binding instances,
next instanceof Binding);
Binding b = (Binding) next;
-assert(Name ' + b.getName() + ' is expected,
+assertTrue(Name ' + b.getName() + ' is expected,
isListed(b.getName(), list));
if (isDirContext(b.getName())) {
-assert(Class ' + b.getClassName() + ' is ' +
+assertTrue(Class ' + b.getClassName() + ' is ' +
contextClassName + ',
contextClassName.equals(b.getClassName()));
}
-assert(Relative is 'true', b.isRelative());
+assertTrue(Relative is 'true', b.isRelative());
Object object = b.getObject();
assertNotNull(Name ' + b.getName() + ' has a non-null object,
object);
-if (b.getName().equals(web.xml)) {
-assert(Entry ' + b.getName() + ' is a Resource,
- object instanceof Resource);
-} else {
-assert(Entry ' + b.getName() + ' is a
DO NOT REPLY [Bug 11754] - Synchronous shutdown script - shutdown.sh should wait until Tomcat is fully shut down
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11754. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11754 Synchronous shutdown script - shutdown.sh should wait until Tomcat is fully shut down [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|DUPLICATE | --- Additional Comments From [EMAIL PROTECTED] 2002-08-16 18:49 --- I closed that by accident. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/test/org/apache/naming/resources BaseDirContextTestCase.java
patrickl2002/08/16 11:51:20
Modified:catalina build.xml
catalina/src/test/org/apache/naming/resources
BaseDirContextTestCase.java
Log:
This patch fixes the JUnit tests in Catalina to run against the ROOT webapp. Now
'ant test' succeeds.
Submitted by: Steve Downey ([EMAIL PROTECTED])
Revision ChangesPath
1.18 +1 -1 jakarta-tomcat-catalina/catalina/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/build.xml,v
retrieving revision 1.17
retrieving revision 1.18
diff -u -r1.17 -r1.18
--- build.xml 15 Aug 2002 13:56:31 - 1.17
+++ build.xml 16 Aug 2002 18:51:20 - 1.18
@@ -15,7 +15,7 @@
property name=catalina.dist value=${catalina.home}/dist/
property name=test.failonerror value=true/
property name=test.runner value=junit.textui.TestRunner/
- property name=test.webapp value=../webapps/build/examples/
+ property name=test.webapp value=../webapps/build/ROOT/
property name=test.webapp.war value=${java.io.tmpdir}/webapp.war/
!-- Source dependencies --
1.2 +41 -42
jakarta-tomcat-catalina/catalina/src/test/org/apache/naming/resources/BaseDirContextTestCase.java
Index: BaseDirContextTestCase.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/test/org/apache/naming/resources/BaseDirContextTestCase.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- BaseDirContextTestCase.java 18 Jul 2002 16:47:31 - 1.1
+++ BaseDirContextTestCase.java 16 Aug 2002 18:51:20 - 1.2
@@ -139,8 +139,7 @@
* directory context.
*/
protected static final String topLevelNames[] =
-{ images, jsp, servlets, META-INF, WEB-INF };
-
+{ index.jsp, jakarta-banner.gif, tomcat.gif, tomcat-power.gif,
META-INF, WEB-INF };
/**
* The set of names that should be present in the WEB-INF
@@ -247,7 +246,7 @@
// Look up the WEB-INF entry
Object webInfEntry = context.lookup(WEB-INF);
assertNotNull(Found WEB-INF entry, webInfEntry);
-assert(WEB-INF entry is a DirContext,
+assertTrue(WEB-INF entry is a DirContext,
webInfEntry instanceof DirContext);
DirContext webInfContext = (DirContext) webInfEntry;
@@ -303,7 +302,7 @@
// Look up the WEB-INF entry
Object webInfEntry = context.lookup(WEB-INF);
assertNotNull(Found WEB-INF entry, webInfEntry);
-assert(WEB-INF entry is a DirContext,
+assertTrue(WEB-INF entry is a DirContext,
webInfEntry instanceof DirContext);
DirContext webInfContext = (DirContext) webInfEntry;
@@ -353,20 +352,20 @@
while (ne.hasMore()) {
Object next = ne.next();
-assert(list() returns NameClassPair instances,
+assertTrue(list() returns NameClassPair instances,
next instanceof NameClassPair);
NameClassPair ncp = (NameClassPair) next;
-assert(Name ' + ncp.getName() + ' is expected,
+assertTrue(Name ' + ncp.getName() + ' is expected,
isListed(ncp.getName(), list));
if (isDirContext(ncp.getName())) {
-assert(Class ' + ncp.getClassName() + ' is ' +
+assertTrue(Class ' + ncp.getClassName() + ' is ' +
contextClassName + ',
contextClassName.equals(ncp.getClassName()));
}
-assert(Relative is 'true', ncp.isRelative());
+assertTrue(Relative is 'true', ncp.isRelative());
}
@@ -391,30 +390,30 @@
while (ne.hasMore()) {
Object next = ne.next();
-assert(listBindings() returns Binding instances,
+assertTrue(listBindings() returns Binding instances,
next instanceof Binding);
Binding b = (Binding) next;
-assert(Name ' + b.getName() + ' is expected,
+assertTrue(Name ' + b.getName() + ' is expected,
isListed(b.getName(), list));
if (isDirContext(b.getName())) {
-assert(Class ' + b.getClassName() + ' is ' +
+assertTrue(Class ' + b.getClassName() + ' is ' +
contextClassName + ',
contextClassName.equals(b.getClassName()));
}
-assert(Relative is 'true', b.isRelative());
+assertTrue(Relative is 'true', b.isRelative());
cvs commit: jakarta-tomcat-catalina/webapps/admin/WEB-INF/classes/org/apache/webapp/admin ApplicationResources_en.properties ApplicationResources_es.properties
amyroh 2002/08/16 12:00:35 Modified:webapps/admin/WEB-INF/classes/org/apache/webapp/admin ApplicationResources_en.properties ApplicationResources_es.properties Log: Add error messages for JNDIRealm. Revision ChangesPath 1.3 +1 -0 jakarta-tomcat-catalina/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/ApplicationResources_en.properties Index: ApplicationResources_en.properties === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/ApplicationResources_en.properties,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- ApplicationResources_en.properties14 Aug 2002 20:45:16 - 1.2 +++ ApplicationResources_en.properties16 Aug 2002 19:00:35 - 1.3 @@ -258,6 +258,7 @@ error.userPassword.required=liUser Password is required./li error.userPattern.required=liUser pattern is required./li error.userSearch.required=liUser search is required./li +error.userPattern.userSearch.defined=liEither userPattern or userSearch must be specified not both./li error.contextFactory.required=liContext Factory is required./li error.connPassword.required=liConnection password is required./li error.connURL.required=liConnection URL is required./li 1.3 +8 -7 jakarta-tomcat-catalina/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/ApplicationResources_es.properties Index: ApplicationResources_es.properties === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/ApplicationResources_es.properties,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- ApplicationResources_es.properties14 Aug 2002 20:45:16 - 1.2 +++ ApplicationResources_es.properties16 Aug 2002 19:00:35 - 1.3 @@ -256,8 +256,9 @@ error.roleBase.required=liSe requiere el elemento bajo del papel./li error.rolePattern.required=liSe requiere el modelo de la busqueda del papel./li error.userPassword.required=liSe requiere la palabra de paso del utilizador./li -error.userPattern.required=liSe requiere el patrón del usuario./li -error.userSearch.required=liSe requiere la búsqueda del usuario./li +error.userPattern.required=liSe requiere el patr=n del usuario./li +error.userSearch.required=liSe requiere la b·squeda del usuario./li +error.userPattern.userSearch.defined=liUserPattern o userSearch se deben especificar no ambos./li error.contextFactory.required=liSe requiere la factory del contexto./li error.connPassword.required=liSe requiere la palabra de paso de la conexion./li error.connURL.required=liSe requiere el URL de la conexion./li @@ -311,16 +312,16 @@ resources.error.entryType.notimpl=liValidaci=n para este tipo no puesto en ejecucio'n todavfa./li resources.error.url.required=liSe requiere el URL de Datasource./li resources.error.driverClass.required=liSe requiere la clase del conductor de JDBC./li -resources.error.active.required=liSe requieren las conexiones activas mßximas./li -resources.error.idle.required=liSe requieren las conexiones ociosas mßximas./li -resources.error.wait.required=liLa espera mßxima para una conexi=n se requiere./li +resources.error.active.required=liSe requieren las conexiones activas m¯ximas./li +resources.error.idle.required=liSe requieren las conexiones ociosas m¯ximas./li +resources.error.wait.required=liLa espera m¯xima para una conexi=n se requiere./li resources.error.mailhost.required=limail.smtp.host is required./li -resources.integer.error=liError invßlido del n·mero entero./li +resources.integer.error=liError inv¯lido del n+mero entero./li resources.actions.userdb.create=Cree La Nueva Base de datos Del Usuario resources.actions.userdb.edit=Corrija La Base de datos Del Usuario resources.actions.userdb.delete=Bases de datos Del Usuario De la Cancelaci=n resources.userdb.location=Localizaci=n -resources.userdb.factory=Fßbrica +resources.userdb.factory=F¯brica resources.treeBuilder.userdbs=Bases de datos Del Usuario resources.error.path.required=liPath requerido/li resources.error.jndiName.required=liJNDI Nombre requerido/li -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 11775] - Admin app looking for wrong attribute user in Data Sources config
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11775. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11775 Admin app looking for wrong attribute user in Data Sources config [EMAIL PROTECTED] changed: What|Removed |Added CC||tomcat- ||[EMAIL PROTECTED] Status|NEW |ASSIGNED -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 11091] - Tomcat (4.1.7 - 4.1.9)-LE-jdk14 ignores error page specified in web.xml
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11091. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11091 Tomcat (4.1.7 - 4.1.9)-LE-jdk14 ignores error page specified in web.xml [EMAIL PROTECTED] changed: What|Removed |Added Summary|Tomcat 4.1.7 ignores error |Tomcat (4.1.7 - 4.1.9)-LE- |page specified in web.xml |jdk14 ignores error page ||specified in web.xml --- Additional Comments From [EMAIL PROTECTED] 2002-08-16 19:42 --- The test case also fails with tomcat 4.1.9 (jakarta-tomcat-4.1.9-LE-jdk14) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[5] [TODO] Config first task
I will bootstrap the new configuration code by writing a DOM based JNDI directory context to provide some compatibility with the current server.xml. I'll start experimenting with the JNDI naming conventions we'll be using as I implement the context (obviously, that will happen in the test program I'll write). I'd like to advocate mirroring all changes to the configuration to the backend immediately (without the need for a commit as it is done now). The initial experimental implementation will use: - a DOM tree to mirror the XML, and that easily maps to the structure - algorithms wise, it is likely to look like the WARDirContext - I may use JDOM, as some DOM to XML serialization is needed, and isn't provided by JAXP Note: The only reason why I want to use something like JDOM is for the serialization. If someone has ideas about how to do it without JDOM (I'm fine with using straight DOM), let me know (I'd like to avoid writing my own serialization code if possible, although it could be useful to do so for performance reasons). Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DBCP multiple pools for multiple contexts under 4.0.4?
Hi All, A couple of weeks ago I wrote about a Poolman DataSource factory for Tomcat, but the latest version of Poolman ended up being too buggy for production work. We've since moved to DBCP from Commons. I'm trying to configure a global DB pool for multiple contexts and I'm having trouble using the BasicDataSourceFactory with Tomcat 4.0.4. Since Tomcat 4.0.x doesn't support the GlobalNamingResources structure (like 4.1.x) which sounds like the right thing to use, I'm placing the DBCP Resource in a DefaultContext. However, it appears that every time a context tries to access the pool, DBCP creates a brand new pool for that context instead of sharing a global one. Any ideas on how to configure this on 4.0.4? I guess one option would be to modify the BasicDataSourceFactory, but maybe there's a way to do it in the config files in 4.0.4. Is anybody using DBCP as a global pooler for multiple contexts? Thanks a lot! Ike _ Isaac Arias Tokenzone, Inc. __ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/resources SaveDataSourceAction.java SetUpDataSourceAction.java
amyroh 2002/08/16 13:17:07
Modified:webapps/admin/WEB-INF/classes/org/apache/webapp/admin/resources
SaveDataSourceAction.java
SetUpDataSourceAction.java
Log:
Change to look for username attribute insted of user in JNDI datasource
since DBCP no longer supports the user attribute.
Fix for bugzilla 11775.
Revision ChangesPath
1.7 +17 -17
jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/resources/SaveDataSourceAction.java
Index: SaveDataSourceAction.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/resources/SaveDataSourceAction.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- SaveDataSourceAction.java 14 Jun 2002 13:29:29 - 1.6
+++ SaveDataSourceAction.java 16 Aug 2002 20:17:07 - 1.7
@@ -176,26 +176,26 @@
Object params[] = new Object[2];
params[0] = dataSourceForm.getJndiName();
-params[1] = ResourceUtils.DATASOURCE_CLASS;
-
+params[1] = ResourceUtils.DATASOURCE_CLASS;
+
String resourcetype = dataSourceForm.getResourcetype();
String path = dataSourceForm.getPath();
String host = dataSourceForm.getHost();
String service = dataSourceForm.getService();
-
+
ObjectName oname = null;
try {
if (resourcetype!=null) {
// Construct the MBean Name for the naming source
if (resourcetype.equals(Global)) {
-oname =
+oname =
new ObjectName(ResourceUtils.NAMINGRESOURCES_TYPE +
ResourceUtils.GLOBAL_TYPE);
-} else if (resourcetype.equals(Context)) {
-oname =
-new ObjectName (ResourceUtils.NAMINGRESOURCES_TYPE +
-ResourceUtils.CONTEXT_TYPE + ,path= + path +
+} else if (resourcetype.equals(Context)) {
+oname =
+new ObjectName (ResourceUtils.NAMINGRESOURCES_TYPE +
+ResourceUtils.CONTEXT_TYPE + ,path= + path +
,host= + host + ,service= + service);
} else if (resourcetype.equals(DefaultContext)) {
// add defaultcontext support later
@@ -205,7 +205,7 @@
// Create the new object and associated MBean
objectName = (String) mserver.invoke(oname, addResource,
params, signature);
-
+
} catch (Exception e) {
getServlet().log
@@ -219,11 +219,11 @@
}
}
-
+
// Perform an Update User database transaction
String attribute = null;
try {
-
+
ObjectName oname = new ObjectName(objectName);
attribute = url;
@@ -234,7 +234,7 @@
mserver.setAttribute
(oname,
new Attribute(attribute, dataSourceForm.getDriverClass()));
-attribute = user;
+attribute = username;
mserver.setAttribute
(oname,
new Attribute(attribute, dataSourceForm.getUsername()));
@@ -271,7 +271,7 @@
return (null);
}
-
+
// Proceed to the list entries screen
return (mapping.findForward(DataSources List Setup));
1.10 +15 -15
jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/resources/SetUpDataSourceAction.java
Index: SetUpDataSourceAction.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/resources/SetUpDataSourceAction.java,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- SetUpDataSourceAction.java20 Jun 2002 02:31:06 - 1.9
+++ SetUpDataSourceAction.java16 Aug 2002 20:17:07 - 1.10
@@ -115,7 +115,7 @@
* The MessageResources we will be retrieving messages from.
*/
private MessageResources resources = null;
-
+
// - Public Methods
@@ -156,8 +156,8 @@
String path = request.getParameter(path);
String host = request.getParameter(host);
String service =
cvs commit: jakarta-tomcat-4.0/webapps/tomcat-docs jndi-resources-howto.xml
amyroh 2002/08/16 13:18:38 Modified:webapps/tomcat-docs jndi-resources-howto.xml Log: Update the doc following the current DBCP implementation - username instead of user. Revision ChangesPath 1.14 +4 -4 jakarta-tomcat-4.0/webapps/tomcat-docs/jndi-resources-howto.xml Index: jndi-resources-howto.xml === RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/tomcat-docs/jndi-resources-howto.xml,v retrieving revision 1.13 retrieving revision 1.14 diff -u -r1.13 -r1.14 --- jndi-resources-howto.xml 16 Mar 2002 20:32:31 - 1.13 +++ jndi-resources-howto.xml 16 Aug 2002 20:18:38 - 1.14 @@ -113,9 +113,9 @@ codeoverride/code attribute to true)./p pGlobal resources can be defined in the server-wide JNDI context, by adding -the resource elements described above to the -a href=config/globalresources.htmllt;GlobalNamingResourcesgt;/a -child element of the a href=config/server.htmllt;Servergt;/a +the resource elements described above to the +a href=config/globalresources.htmllt;GlobalNamingResourcesgt;/a +child element of the a href=config/server.htmllt;Servergt;/a element./p /section @@ -503,7 +503,7 @@ type=javax.sql.DataSource/gt; lt;ResourceParams name=jdbc/EmployeeDBgt; lt;parametergt; - lt;namegt;userlt;/namegt; + lt;namegt;usernamelt;/namegt; lt;valuegt;dbusernamelt;/valuegt; lt;/parametergt; lt;parametergt; -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5] [TODO] Config first task
On Fri, 16 Aug 2002, Remy Maucherat wrote: I will bootstrap the new configuration code by writing a DOM based JNDI directory context to provide some compatibility with the current server.xml. Great. I am not very sure if we should spend too much time preserving the current server.xml. If it can be done without too many restrictions in the naming structure - great. I was thinking to look at one of the existing file-based stores ( XML, etc). What's important is to have a well-organised naming hierarchy - the one used for mbeans is a bit confusing. I'll start experimenting with the JNDI naming conventions we'll be using as I implement the context (obviously, that will happen in the test program I'll write). The naming convenitons are the critical part. Good luck :-) I'd like to advocate mirroring all changes to the configuration to the backend immediately (without the need for a commit as it is done now). The initial experimental implementation will use: - a DOM tree to mirror the XML, and that easily maps to the structure - algorithms wise, it is likely to look like the WARDirContext - I may use JDOM, as some DOM to XML serialization is needed, and isn't provided by JAXP Note: The only reason why I want to use something like JDOM is for the serialization. If someone has ideas about how to do it without JDOM (I'm fine with using straight DOM), let me know (I'd like to avoid writing my own serialization code if possible, although it could be useful to do so for performance reasons). Yes, just use an identity Transformer. It's quite easy - you make a trasnformation between a DOMSource and a FileDestination. ( make sure you turn on indentation !) Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/catalina/src/conf server.xml
amyroh 2002/08/16 13:19:32 Modified:catalina/src/conf server.xml Log: Update the JNDI datasource sample configuration following the current DBCP implementation - username instead of user. Revision ChangesPath 1.62 +1 -1 jakarta-tomcat-4.0/catalina/src/conf/server.xml Index: server.xml === RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/conf/server.xml,v retrieving revision 1.61 retrieving revision 1.62 diff -u -r1.61 -r1.62 --- server.xml18 Jun 2002 03:24:50 - 1.61 +++ server.xml16 Aug 2002 20:19:32 - 1.62 @@ -346,7 +346,7 @@ Resource name=jdbc/EmployeeAppDb auth=SERVLET type=javax.sql.DataSource/ ResourceParams name=jdbc/EmployeeAppDb -parameternameuser/namevaluesa/value/parameter +parameternameusername/namevaluesa/value/parameter parameternamepassword/namevalue/value/parameter parameternamedriverClassName/name valueorg.hsql.jdbcDriver/value/parameter -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 11775] - Admin app looking for wrong attribute user in Data Sources config
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11775. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11775 Admin app looking for wrong attribute user in Data Sources config [EMAIL PROTECTED] changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-08-16 20:23 --- Fixed 8/16/02. Amy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/conf server.xml
amyroh 2002/08/16 14:04:26 Modified:catalina/src/conf server.xml Log: Update the JNDI datasource sample configuration following the current DBCP implementation - username instead of user. Revision ChangesPath 1.4 +12 -12jakarta-tomcat-catalina/catalina/src/conf/server.xml Index: server.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/conf/server.xml,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- server.xml4 Aug 2002 19:41:06 - 1.3 +++ server.xml16 Aug 2002 21:04:26 - 1.4 @@ -88,7 +88,7 @@ enableLookups=true redirectPort=8443 acceptCount=10 debug=0 connectionTimeout=2 useURIValidationHack=false / -!-- Note : To disable connection timeouts, set connectionTimeout value +!-- Note : To disable connection timeouts, set connectionTimeout value to -1 -- !-- Define a SSL Coyote HTTP/1.1 Connector on port 8443 -- @@ -220,7 +220,7 @@ -- !-- Define the default virtual host -- - Host name=localhost debug=0 appBase=webapps + Host name=localhost debug=0 appBase=webapps unpackWARs=true autoDeploy=true !-- Normally, users must authenticate themselves to each web app @@ -293,22 +293,22 @@ -- - !-- PersistentManager: Uncomment the section below to test Persistent + !-- PersistentManager: Uncomment the section below to test Persistent Sessions. - + saveOnRestart: If true, all active sessions will be saved to the Store when Catalina is shutdown, regardless of - other settings. All Sessions found in the Store will be + other settings. All Sessions found in the Store will be loaded on startup. Sessions past their expiration are ignored in both cases. - maxActiveSessions: If 0 or greater, having too many active + maxActiveSessions: If 0 or greater, having too many active sessions will result in some being swapped out. minIdleSwap limits this. -1 means unlimited sessions are allowed. 0 means sessions will almost always be swapped out after use - this will be noticeably slow for your users. minIdleSwap: Sessions must be idle for at least this long - (in seconds) before they will be swapped out due to - maxActiveSessions. This avoids thrashing when the site is + (in seconds) before they will be swapped out due to + maxActiveSessions. This avoids thrashing when the site is highly active. -1 or 0 means there is no minimum - sessions can be swapped out at any time. maxIdleSwap: Sessions will be swapped out if idle for this @@ -319,13 +319,13 @@ If set to = 0, guarantees that all sessions found in the Store will be loaded on startup. maxIdleBackup: Sessions will be backed up (saved to the Store, - but left in active memory) if idle for this long (in seconds), + but left in active memory) if idle for this long (in seconds), and all sessions found in the Store will be loaded on startup. If set to -1 sessions will not be backed up, 0 means they should be backed up shortly after being used. To clear sessions from the Store, set maxActiveSessions, maxIdleSwap, - and minIdleBackup all to -1, saveOnRestart to false, then restart + and minIdleBackup all to -1, saveOnRestart to false, then restart Catalina. -- !-- @@ -346,7 +346,7 @@ Resource name=jdbc/EmployeeAppDb auth=SERVLET type=javax.sql.DataSource/ ResourceParams name=jdbc/EmployeeAppDb -parameternameuser/namevaluesa/value/parameter +parameternameusername/namevaluesa/value/parameter parameternamepassword/namevalue/value/parameter parameternamedriverClassName/name valueorg.hsql.jdbcDriver/value/parameter @@ -361,7 +361,7 @@ valuelocalhost/value /parameter /ResourceParams - ResourceLink name=linkToGlobalResource + ResourceLink name=linkToGlobalResource global=simpleValue type=java.lang.Integer/ /Context -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For
cvs commit: jakarta-tomcat-catalina/webapps/docs jndi-resources-howto.xml
amyroh 2002/08/16 14:05:16 Modified:webapps/docs jndi-resources-howto.xml Log: Update the doc following the current DBCP implementation - username instead of user. Revision ChangesPath 1.3 +4 -4 jakarta-tomcat-catalina/webapps/docs/jndi-resources-howto.xml Index: jndi-resources-howto.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/jndi-resources-howto.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- jndi-resources-howto.xml 30 Jul 2002 03:58:28 - 1.2 +++ jndi-resources-howto.xml 16 Aug 2002 21:05:16 - 1.3 @@ -113,9 +113,9 @@ codeoverride/code attribute to true)./p pGlobal resources can be defined in the server-wide JNDI context, by adding -the resource elements described above to the -a href=config/globalresources.htmllt;GlobalNamingResourcesgt;/a -child element of the a href=config/server.htmllt;Servergt;/a +the resource elements described above to the +a href=config/globalresources.htmllt;GlobalNamingResourcesgt;/a +child element of the a href=config/server.htmllt;Servergt;/a element./p /section @@ -503,7 +503,7 @@ type=javax.sql.DataSource/gt; lt;ResourceParams name=jdbc/EmployeeDBgt; lt;parametergt; - lt;namegt;userlt;/namegt; + lt;namegt;usernamelt;/namegt; lt;valuegt;dbusernamelt;/valuegt; lt;/parametergt; lt;parametergt; -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 11779] New: - Coyote AJP 1.3 connector doesn't support tomcatAuthentication=false
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11779. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11779 Coyote AJP 1.3 connector doesn't support tomcatAuthentication=false Summary: Coyote AJP 1.3 connector doesn't support tomcatAuthentication=false Product: Tomcat 4 Version: 4.1.9 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Major Priority: Other Component: Connector:Coyote JK 2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] using the Coyote AJP1.3 connector and mod_jk, when I perform BASIC authentication using Apache 2.0.39, I get through Apache, but when I try to make the call to request.getRemoteUser(), all it ever returns is null. When I use the, now deprecated, old AJP1.3 connector with tomcatAuthentication=false, request.getRemoteUser() always gets the user that was logged in through Apache, never null. For this reason, I can't use the Coyote AJP connector. Why is tomcatAuthentication=false not supported? Is there a replacement for this functionality? The biggest problem is, I can't use the Admin app without the Coyote AJP connector specified because the old connector doesn't support JMX. BTW, I try to get to the Admin app through port 8080 which doesn't get handled by Apache, but directly by Tomcat. Why does one *have* to specify the Coyote AJP connector in order to allow JMX to work when the AJP connector isn't even a factor in connecting to the Admin app through port 8080 Jake -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Absolute fields required for JDBC JNDI Realm pages in adminwebapp
Amy Roh wrote: I just committed fixes to validate only className and connectionURL and also to check either userPattern or userSearch is specified but not both. Thanks! I don't think any change to JNDIRealm is necessary since I changed admin so that it doesn't replace null values with for all configuration attributes anymore. Could you see if everything is ok now? I'll commit the changes to Tomcat 5 once I make sure it works correctly. Sounds good, but I'm afraid I won't be able to do this for about 10 days ... off on holiday early tomorrow. I'll check as soon as I get back. Would it be too late for the changes to go into TC 4.1? I still need someone to comment on other realms so I can make them more user-friendly. Thanks, Amy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/webapps/admin/users group.jsp role.jsp user.jsp
amyroh 2002/08/16 15:24:07
Modified:webapps/admin build.xml
webapps/admin/WEB-INF/classes/org/apache/webapp/admin
AttributeTag.java
webapps/admin/users group.jsp role.jsp user.jsp
Log:
Fix for bugzilla 10458 - Editing a User causes a JavaScript error because the
script is trying to focus on a hidden object - username is not guaranteed to be
focusable because if your editing an existing user, the field is hidden. (non
focusable object IE5+)
Patch submitted by Andrew Conrad - [EMAIL PROTECTED]
Revision ChangesPath
1.4 +11 -1 jakarta-tomcat-4.0/webapps/admin/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/admin/build.xml,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- build.xml 17 Jan 2002 20:02:16 - 1.3
+++ build.xml 16 Aug 2002 22:24:06 - 1.4
@@ -22,6 +22,8 @@
pathelement location=${jmx.jar}/
pathelement location=${servlet.jar}/
pathelement location=${struts.jar}/
+pathelement location=${commons-beanutils.jar}/
+
/path
@@ -30,7 +32,7 @@
!-- JDK flags --
available property=jdk.1.2.present classname=java.util.HashMap /
-available property=jdk.1.3.present
+available property=jdk.1.3.present
classname=java.lang.reflect.Proxy /
available property=jdk.1.4.present classname=java.nio.Buffer /
@@ -59,12 +61,18 @@
available property=struts.present
classname=org.apache.struts.action.ActionForm
classpath=${struts.jar} /
+available property=beanutils.present
+ classname=org.apache.commons.beanutils.PropertyUtils
+ classpath=${common-beanutils.jar} /
+
!-- JAR files availability flags --
available property=jmx.jar.present file=${jmx.jar} /
available property=modeler.jar.present file=${commons-modeler.jar} /
available property=servlet.jar.present file=${servlet.jar} /
available property=struts.jar.present file=${struts.jar} /
+available property=beanutils.jar.present file=${commons-beanutils.jar} /
+
!-- Conditional compilation flags (determined from the flags above) --
condition property=compile.admin
@@ -125,6 +133,8 @@
echo message=modeler.jar.present=${modeler.jar.present} /
echo message=servlet.jar.present=${servlet.jar.present} /
echo message=struts.jar.present=${struts.jar.present} /
+echo message=beanutils.jar.present=${beanutils.jar.present} /
+
echo message=--- Optional JARs --- /
1.2 +5 -4
jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/AttributeTag.java
Index: AttributeTag.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/AttributeTag.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- AttributeTag.java 23 Jan 2002 23:06:54 - 1.1
+++ AttributeTag.java 16 Aug 2002 22:24:06 - 1.2
@@ -70,7 +70,8 @@
import javax.servlet.jsp.JspWriter;
import javax.servlet.jsp.PageContext;
import javax.servlet.jsp.tagext.TagSupport;
-import org.apache.struts.util.PropertyUtils;
+import org.apache.commons.beanutils.PropertyUtils;
+
/**
1.5 +1 -1 jakarta-tomcat-4.0/webapps/admin/users/group.jsp
Index: group.jsp
===
RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/admin/users/group.jsp,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- group.jsp 24 Jul 2002 00:03:25 - 1.4
+++ group.jsp 16 Aug 2002 22:24:07 - 1.5
@@ -17,7 +17,7 @@
html:errors/
-html:form method=POST action=/users/saveGroup focus=groupname
+html:form method=POST action=/users/saveGroup !--focus=groupname--
html:hidden property=databaseName/
html:hidden property=objectName/
1.5 +1 -1 jakarta-tomcat-4.0/webapps/admin/users/role.jsp
Index: role.jsp
===
RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/admin/users/role.jsp,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- role.jsp 24 Jul 2002 00:03:25 - 1.4
+++ role.jsp 16 Aug 2002 22:24:07 - 1.5
@@ -17,7 +17,7 @@
html:errors/
-html:form method=POST action=/users/saveRole focus=rolename
+html:form method=POST action=/users/saveRole !--focus=rolename--
html:hidden property=databaseName/
html:hidden property=objectName/
1.6 +1 -1 jakarta-tomcat-4.0/webapps/admin/users/user.jsp
Index: user.jsp
DO NOT REPLY [Bug 10458] - Editing User causes JavaScript Error
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10458. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10458 Editing User causes JavaScript Error [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-08-16 22:27 --- I applied the patches, however, the bug still appears in IE5+. I removed the focus attribute from the three files and the bug no longer exists. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Absolute fields required for JDBC JNDI Realm pages in adminwebapp
John Holman wrote: Amy Roh wrote: I just committed fixes to validate only className and connectionURL and also to check either userPattern or userSearch is specified but not both. Thanks! I don't think any change to JNDIRealm is necessary since I changed admin so that it doesn't replace null values with for all configuration attributes anymore. Could you see if everything is ok now? I'll commit the changes to Tomcat 5 once I make sure it works correctly. Sounds good, but I'm afraid I won't be able to do this for about 10 days ... off on holiday early tomorrow. I'll check as soon as I get back. Would it be too late for the changes to go into TC 4.1? It's in cvs already so it'll be in the next release 4.1.10. Have a good vacation. :-) Amy I still need someone to comment on other realms so I can make them more user-friendly. Thanks, Amy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5] [TODO] Config first task
On second tought, it would be excelent if you can map server.xml. The only issue I have is the naming hierarcy - but we can address that later. One thing I hate in the current JNDI code is the binding on thread/class loader, etc. I understand what it is supposed to do, but we shouldn't have to do that internally. The way I see it, we'll have 2 JNDI 'trees': - one for 'config data' ( the new one ). - one for 'runtime data' - including the VFS, various java:env, etc. We still need to 'bind' the initial context for each webapp so that webapps can see their separated envs. But internal code should have access to the root of the tree, for example stored in some top-level objects - and be able to access anything with a simple lookup. If we are going to go with the JNDI-based config, than I think it may be worth to first clean up and add some more docs to the jndi code we have. I know you knows the code very well - but for those with less JNDI experience it would help a lot. The binding seems the trickiest part, and I can't understand why it is actually needed from inside. Costin On Fri, 16 Aug 2002, Remy Maucherat wrote: I will bootstrap the new configuration code by writing a DOM based JNDI directory context to provide some compatibility with the current server.xml. I'll start experimenting with the JNDI naming conventions we'll be using as I implement the context (obviously, that will happen in the test program I'll write). I'd like to advocate mirroring all changes to the configuration to the backend immediately (without the need for a commit as it is done now). The initial experimental implementation will use: - a DOM tree to mirror the XML, and that easily maps to the structure - algorithms wise, it is likely to look like the WARDirContext - I may use JDOM, as some DOM to XML serialization is needed, and isn't provided by JAXP Note: The only reason why I want to use something like JDOM is for the serialization. If someone has ideas about how to do it without JDOM (I'm fine with using straight DOM), let me know (I'd like to avoid writing my own serialization code if possible, although it could be useful to do so for performance reasons). Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10458] - Editing User causes JavaScript Error
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10458. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10458 Editing User causes JavaScript Error --- Additional Comments From [EMAIL PROTECTED] 2002-08-16 22:54 --- The patches were only if you decided to use Struts 1.1B2 with a nightly build after 20020624. But since it is still in beta, that doesn't seem like a good choice. Thanks -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 11784] New: - Failure in loading class with destroy method of Servlet
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11784.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11784
Failure in loading class with destroy method of Servlet
Summary: Failure in loading class with destroy method of Servlet
Product: Tomcat 4
Version: 4.0.4 Final
Platform: PC
OS/Version: Windows 9x
Status: NEW
Severity: Normal
Priority: Other
Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
We are implementing Tomcat in our Production environment (on AIX 4.3.3), and
have been facing a problem. In our Servlet init() function, we load a class
dynamically using Class.forName(). The class being loaded resides in our WEB-
INF/classes directory. The init() method works fine. But when we load another
class in our destroy() method, we get a ClassNotFoundException. Both classes
reside in the same WEB-INF/classes directory.
This problem occurs only when the classes are in WEB-INF/classes directory. If
we put the classes in a JAR file and place the JAR file in WEB-INF/lib, the
problem goes away.
I managed to reproduce the problem on my PC (running on Windows 98) by creating
a small test servlet. The code for the servlet and the helper classes are given
below:
Try class:
--
import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
public class Try extends HttpServlet {
public void init() throws ServletException {
getServletContext().log(Try initialized);
try {
Class.forName(Test1);
}
catch(Exception e) {
getServletContext().log(Caught exception + e);
}
}
public void destroy() {
getServletContext().log(Try destroyed);
try {
Class.forName(Test2);
}
catch(Exception e) {
getServletContext().log(Caught exception + e);
}
}
public void doGet(HttpServletRequest request, HttpServletResponse response)
throws IOException, ServletException {
response.setContentType(text/plain);
PrintWriter writer = response.getWriter();
writer.println(Hello World);
}
}
Test1 class:
public class Test1 {
public void sayHello() {
System.out.println(In Test1);
}
}
Test2 class:
public class Test2 {
public void sayHello() {
System.out.println(In Test2);
}
}
Output from log file:
-
2002-08-16 23:39:09 StandardHost[localhost]: Installing web application at
context path /dm from URL file:C:\Program Files\Apache Tomcat 4.0\webapps\dm
2002-08-16 23:39:09 WebappLoader[/dm]: Deploying class repositories to work
directory C:\Program Files\Apache Tomcat 4.0\work\Standalone\localhost\dm
2002-08-16 23:39:09 StandardManager[/dm]: Seeding random number generator class
java.security.SecureRandom
2002-08-16 23:39:09 StandardManager[/dm]: Seeding of random number generator
has been completed
2002-08-16 23:39:09 ContextConfig[/dm]: Missing application web.xml, using
defaults only
2002-08-16 23:39:09 ContextConfig[/dm]: Added certificates - request attribute
Valve
2002-08-16 23:39:09 StandardWrapper[/dm:default]: Loading container servlet
default
2002-08-16 23:39:09 default: init
2002-08-16 23:39:09 StandardWrapper[/dm:invoker]: Loading container servlet
invoker
2002-08-16 23:39:09 invoker: init
2002-08-16 23:39:09 jsp: init
2002-08-16 23:39:09 Internal Error: File /WEB-INF/web.xml not found
2002-08-16 23:39:18 org.apache.catalina.INVOKER.Try: init
2002-08-16 23:39:18 Try initialized
2002-08-16 23:39:45 StandardHost[localhost]: Removing web application at
context path /manager
2002-08-16 23:39:45 StandardHost[localhost]: Removing web application at
context path /dm
2002-08-16 23:39:45 Try destroyed
2002-08-16 23:39:45 Caught exceptionjava.lang.ClassNotFoundException: Test2
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler ScriptingVariabler.java Compiler.java Generator.java Node.java
luehe 2002/08/16 16:18:54
Modified:jasper2/src/share/org/apache/jasper/compiler Compiler.java
Generator.java Node.java
Added: jasper2/src/share/org/apache/jasper/compiler
ScriptingVariabler.java
Log:
Added compilation step which determines, for every custom tag, the
scripting variables that need to be declared. For example, if a custom
action is nested, it must not redeclare the AT_BEGIN variables of its
encapsulating action, etc.
Scripting variables are now generated at the appropriate places,
according to their scope.
Revision ChangesPath
1.27 +6 -3
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Compiler.java
Index: Compiler.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Compiler.java,v
retrieving revision 1.26
retrieving revision 1.27
diff -u -r1.26 -r1.27
--- Compiler.java 12 Aug 2002 21:58:48 - 1.26
+++ Compiler.java 16 Aug 2002 23:18:54 - 1.27
@@ -248,6 +248,9 @@
// this compilation unit.
TagFileProcessor.loadTagFiles(this, pageNodes);
+ // Determine which custom tag needs to declare which scripting vars
+ ScriptingVariabler.set(pageNodes);
+
// generate servlet .java file
Generator.generate(writer, this, pageNodes);
writer.close();
1.66 +107 -121
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java
Index: Generator.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java,v
retrieving revision 1.65
retrieving revision 1.66
diff -u -r1.65 -r1.66
--- Generator.java12 Aug 2002 17:55:45 - 1.65
+++ Generator.java16 Aug 2002 23:18:54 - 1.66
@@ -247,73 +247,60 @@
return poolName;
}
}
-
+
page.visit(new TagHandlerPoolVisitor(tagHandlerPoolNames));
}
-
-/*
- * For every custom tag, declares its scripting variables with AT_BEGIN
- * and AT_END scopes.
- */
-private void declareAtBeginAtEndScriptingVariables(Node.Nodes page)
+
+private void declareTemporaryScriptingVars(Node.Nodes page)
throws JasperException {
- class ScriptingVariableDeclarationVisitor extends Node.Visitor {
+ class ScriptingVarVisitor extends Node.Visitor {
- /*
- * Vector keeping track of which scripting variables have already
- * been declared
- */
- private Vector scriptVars;
+ private Vector vars;
- /*
- * Constructor.
- */
- public ScriptingVariableDeclarationVisitor() {
- scriptVars = new Vector();
+ ScriptingVarVisitor() {
+ vars = new Vector();
}
public void visit(Node.CustomTag n) throws JasperException {
- TagVariableInfo[] tagVarInfos = n.getTagVariableInfos();
- VariableInfo[] varInfos = n.getVariableInfos();
-
- if ((varInfos == null) (tagVarInfos == null)) {
- visitBody(n);
- }
-
- if (varInfos != null) {
- for (int i=0; ivarInfos.length; i++) {
- int scope = varInfos[i].getScope();
- String varName = varInfos[i].getVarName();
- if (((scope == VariableInfo.AT_BEGIN)
- || (scope == VariableInfo.AT_END))
- varInfos[i].getDeclare()
- !scriptVars.contains(varName)) {
- out.printin(varInfos[i].getClassName());
- out.print( );
- out.print(varName);
- out.println( = null;);
- scriptVars.add(varName);
+ if (n.getCustomNestingLevel() 0) {
+ TagVariableInfo[] tagVarInfos = n.getTagVariableInfos();
+ VariableInfo[] varInfos = n.getVariableInfos();
+
+ if (varInfos != null) {
+ for (int i=0; ivarInfos.length; i++) {
+ String varName = varInfos[i].getVarName();
+ String tmpVarName = _jspx_ + varName + _
+ + n.getCustomNestingLevel();
+ if (!vars.contains(tmpVarName)) {
+ vars.add(tmpVarName);
+ out.printin(varInfos[i].getClassName());
+ out.print( );
+
cvs commit: jakarta-tomcat-catalina/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/realm JNDIRealmForm.java SaveJNDIRealmAction.java
amyroh 2002/08/16 16:24:45
Modified:webapps/admin/WEB-INF/classes/org/apache/webapp/admin/realm
JNDIRealmForm.java SaveJNDIRealmAction.java
Log:
Change the validation of JNDIRealm and also fix to not replace null
configuration attributes with .
Revision ChangesPath
1.3 +84 -38
jakarta-tomcat-catalina/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/realm/JNDIRealmForm.java
Index: JNDIRealmForm.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/realm/JNDIRealmForm.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- JNDIRealmForm.java14 Aug 2002 20:45:16 - 1.2
+++ JNDIRealmForm.java16 Aug 2002 23:24:45 - 1.3
@@ -84,14 +84,24 @@
// - Instance Variables
/**
- * Should we search the entire subtree for matching roles?
+ * The text for the connection user name.
*/
-private String roleSubtree = false;
+private String connectionName = null;
/**
- * Should we search the entire subtree for matching users?
+ * The text for the connection Password.
*/
-private String userSubtree = false;
+private String connectionPassword = null;
+
+/**
+ * The text for the connection URL.
+ */
+private String connectionURL = null;
+
+/**
+ * The text for the context Factory.
+ */
+private String contextFactory = null;
/**
* The text for the digest algorithm.
@@ -104,11 +114,6 @@
private String roleBase = null;
/**
- * The text for the user role name.
- */
-private String userRoleName = null;
-
-/**
* The text for the role name.
*/
private String roleName = null;
@@ -119,39 +124,39 @@
private String rolePattern = null;
/**
- * The text for the connection user name.
+ * Should we search the entire subtree for matching roles?
*/
-private String connectionName = null;
+private String roleSubtree = false;
/**
- * The text for the connection Password.
+ * The text for the user Base.
*/
-private String connectionPassword = null;
+private String userBase = null;
/**
- * The text for the connection URL.
+ * The text for the user Password.
*/
-private String connectionURL = null;
+private String userPassword = null;
/**
- * The text for the context Factory.
+ * The text for the user Pattern.
*/
-private String contextFactory = null;
+private String userPattern = null;
/**
- * The text for the user Password.
+ * The text for the user role name.
*/
-private String userPassword = null;
+private String userRoleName = null;
/**
- * The text for the user search Pattern.
+ * The text for the user Search.
*/
-private String userPattern = null;
+private String userSearch = null;
/**
- * The text for the user Search.
+ * Should we search the entire subtree for matching users?
*/
-private String userSearch = null;
+private String userSubtree = false;
/**
* Set of valid values for search subtrees(true/false).
@@ -270,6 +275,24 @@
}
/**
+ * Return the userBase.
+ */
+public String getUserBase() {
+
+return this.userBase ;
+
+}
+
+/**
+ * Set the userBase.
+ */
+public void setUserBase(String userBase ) {
+
+this.userBase = userBase ;
+
+}
+
+/**
* Return the user role name.
*/
public String getUserRoleName() {
@@ -458,6 +481,7 @@
this.rolePattern = null;
this.roleBase = null;
+this.userBase = null;
this.userPassword = null;
this.userPattern = null;
this.userSearch = null;
@@ -495,6 +519,8 @@
sb.append(roleBase);
sb.append(',userPassword=');
sb.append(userPassword);
+sb.append(,userBase=);
+sb.append(userBase);
sb.append(',userPattern=);
sb.append(userPattern);
sb.append(',userSearch=);
@@ -532,12 +558,33 @@
if (submit != null) {
// the following fields are required.
-if ((digest == null) || (digest.length() 1)) {
+if ((connectionURL == null) || (connectionURL.length() 1)) {
+errors.add(connectionURL,
+new ActionError(error.connURL.required));
+}
+
+// Either userPattern
cvs commit: jakarta-tomcat-catalina/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/resources SaveDataSourceAction.java SetUpDataSourceAction.java
amyroh 2002/08/16 16:25:31
Modified:webapps/admin/WEB-INF/classes/org/apache/webapp/admin/resources
SaveDataSourceAction.java
SetUpDataSourceAction.java
Log:
Change to look for username attribute insted of user in JNDI datasource
since DBCP no longer supports the user attribute.
Fix for bugzilla 11775.
Revision ChangesPath
1.2 +17 -17
jakarta-tomcat-catalina/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/resources/SaveDataSourceAction.java
Index: SaveDataSourceAction.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/resources/SaveDataSourceAction.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- SaveDataSourceAction.java 18 Jul 2002 16:48:27 - 1.1
+++ SaveDataSourceAction.java 16 Aug 2002 23:25:31 - 1.2
@@ -176,26 +176,26 @@
Object params[] = new Object[2];
params[0] = dataSourceForm.getJndiName();
-params[1] = ResourceUtils.DATASOURCE_CLASS;
-
+params[1] = ResourceUtils.DATASOURCE_CLASS;
+
String resourcetype = dataSourceForm.getResourcetype();
String path = dataSourceForm.getPath();
String host = dataSourceForm.getHost();
String service = dataSourceForm.getService();
-
+
ObjectName oname = null;
try {
if (resourcetype!=null) {
// Construct the MBean Name for the naming source
if (resourcetype.equals(Global)) {
-oname =
+oname =
new ObjectName(ResourceUtils.NAMINGRESOURCES_TYPE +
ResourceUtils.GLOBAL_TYPE);
-} else if (resourcetype.equals(Context)) {
-oname =
-new ObjectName (ResourceUtils.NAMINGRESOURCES_TYPE +
-ResourceUtils.CONTEXT_TYPE + ,path= + path +
+} else if (resourcetype.equals(Context)) {
+oname =
+new ObjectName (ResourceUtils.NAMINGRESOURCES_TYPE +
+ResourceUtils.CONTEXT_TYPE + ,path= + path +
,host= + host + ,service= + service);
} else if (resourcetype.equals(DefaultContext)) {
// add defaultcontext support later
@@ -205,7 +205,7 @@
// Create the new object and associated MBean
objectName = (String) mserver.invoke(oname, addResource,
params, signature);
-
+
} catch (Exception e) {
getServlet().log
@@ -219,11 +219,11 @@
}
}
-
+
// Perform an Update User database transaction
String attribute = null;
try {
-
+
ObjectName oname = new ObjectName(objectName);
attribute = url;
@@ -234,7 +234,7 @@
mserver.setAttribute
(oname,
new Attribute(attribute, dataSourceForm.getDriverClass()));
-attribute = user;
+attribute = username;
mserver.setAttribute
(oname,
new Attribute(attribute, dataSourceForm.getUsername()));
@@ -271,7 +271,7 @@
return (null);
}
-
+
// Proceed to the list entries screen
return (mapping.findForward(DataSources List Setup));
1.2 +15 -15
jakarta-tomcat-catalina/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/resources/SetUpDataSourceAction.java
Index: SetUpDataSourceAction.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/resources/SetUpDataSourceAction.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- SetUpDataSourceAction.java18 Jul 2002 16:48:27 - 1.1
+++ SetUpDataSourceAction.java16 Aug 2002 23:25:31 - 1.2
@@ -115,7 +115,7 @@
* The MessageResources we will be retrieving messages from.
*/
private MessageResources resources = null;
-
+
// - Public Methods
@@ -156,8 +156,8 @@
String path = request.getParameter(path);
String host = request.getParameter(host);
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/mbeans mbeans-descriptors.xml
amyroh 2002/08/16 16:54:24 Modified:catalina/src/share/org/apache/catalina/mbeans mbeans-descriptors.xml Log: Minor change in format. Revision ChangesPath 1.6 +21 -17 jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/mbeans/mbeans-descriptors.xml Index: mbeans-descriptors.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/mbeans/mbeans-descriptors.xml,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- mbeans-descriptors.xml14 Aug 2002 20:43:49 - 1.5 +++ mbeans-descriptors.xml16 Aug 2002 23:54:23 - 1.6 @@ -1015,6 +1015,10 @@ description=The connection URL for the server we will contact type=java.lang.String/ +attribute name=contextFactory + description=The JNDI context factory for this Realm + type=java.lang.String/ + attribute name=debug description=The debugging detail level for this component type=int/ @@ -1028,28 +1032,22 @@ description=The base element for role searches type=java.lang.String/ -attribute name=roleSearch - description=The message format used to select roles for a user - type=java.lang.String/ - - attribute name=userRoleName - description=The name of the attribute in the user's entry containing - roles for that user - type=java.lang.String/ - attribute name=roleName description=The name of the attribute containing roles held elsewhere type=java.lang.String/ +attribute name=roleSearch + description=The message format used to select roles for a user + type=java.lang.String/ + attribute name=roleSubtree description=Should we search the entire subtree for matching memberships? type=boolean/ -attribute name=userSubtree - description=Should we search the entire subtree for matching - users? - type=boolean/ +attribute name=userBase + description=The base element for user searches + type=java.lang.String/ attribute name=userPassword description=The attribute name used to retrieve the user password @@ -1059,13 +1057,19 @@ description=The message format used to select a user type=java.lang.String/ + attribute name=userRoleName + description=The name of the attribute in the user's entry containing + roles for that user + type=java.lang.String/ + attribute name=userSearch description=The message format used to search for a user type=java.lang.String/ -attribute name=contextFactory - description=The JNDI context factory for this Realm - type=java.lang.String/ +attribute name=userSubtree + description=Should we search the entire subtree for matching + users? + type=boolean/ /mbean -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/webapps/admin/users group.jsp role.jsp user.jsp
amyroh 2002/08/16 16:56:18
Modified:webapps/admin build.xml
webapps/admin/WEB-INF/classes/org/apache/webapp/admin
AttributeTag.java
webapps/admin/users group.jsp role.jsp user.jsp
Log:
Fix for bugzilla 10458 - Editing a User causes a JavaScript error because the
script is trying to focus on a hidden object - username is not guaranteed to be
focusable because if your editing an existing user, the field is hidden. (non
focusable object IE5+)
Patch submitted by Andrew Conrad - [EMAIL PROTECTED]
Revision ChangesPath
1.4 +8 -1 jakarta-tomcat-catalina/webapps/admin/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/admin/build.xml,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- build.xml 13 Aug 2002 16:30:44 - 1.3
+++ build.xml 16 Aug 2002 23:56:18 - 1.4
@@ -27,6 +27,7 @@
pathelement location=${servlet-api.jar}/
pathelement location=${jsp-api.jar}/
pathelement location=${struts.jar}/
+pathelement location=${commons-beanutils.jar}/
/path
@@ -35,7 +36,7 @@
!-- JDK flags --
available property=jdk.1.2.present classname=java.util.HashMap /
-available property=jdk.1.3.present
+available property=jdk.1.3.present
classname=java.lang.reflect.Proxy /
available property=jdk.1.4.present classname=java.nio.Buffer /
@@ -67,6 +68,10 @@
available property=struts.present
classname=org.apache.struts.action.ActionForm
classpath=${struts.jar} /
+available property=beanutils.present
+ classname=org.apache.commons.beanutils.PropertyUtils
+ classpath=${common-beanutils.jar} /
+
!-- JAR files availability flags --
available property=jmx.jar.present file=${jmx.jar} /
@@ -74,6 +79,7 @@
available property=servlet-api.jar.present file=${servlet-api.jar} /
available property=jsp-api.jar.present file=${jsp-api.jar} /
available property=struts.jar.present file=${struts.jar} /
+available property=beanutils.jar.present file=${commons-beanutils.jar} /
!-- Conditional compilation flags (determined from the flags above) --
condition property=compile.admin
@@ -136,6 +142,7 @@
echo message=servlet-api.jar.present=${servlet-api.jar.present} /
echo message=jsp-api.jar.present=${jsp-api.jar.present} /
echo message=struts.jar.present=${struts.jar.present} /
+echo message=beanutils.jar.present=${beanutils.jar.present} /
echo message=--- Optional JARs --- /
1.2 +6 -5
jakarta-tomcat-catalina/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/AttributeTag.java
Index: AttributeTag.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/AttributeTag.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- AttributeTag.java 18 Jul 2002 16:48:21 - 1.1
+++ AttributeTag.java 16 Aug 2002 23:56:18 - 1.2
@@ -70,7 +70,8 @@
import javax.servlet.jsp.JspWriter;
import javax.servlet.jsp.PageContext;
import javax.servlet.jsp.tagext.TagSupport;
-import org.apache.struts.util.PropertyUtils;
+import org.apache.commons.beanutils.PropertyUtils;
+
/**
1.3 +1 -1 jakarta-tomcat-catalina/webapps/admin/users/group.jsp
Index: group.jsp
===
RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/admin/users/group.jsp,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- group.jsp 24 Jul 2002 20:57:28 - 1.2
+++ group.jsp 16 Aug 2002 23:56:18 - 1.3
@@ -17,7 +17,7 @@
html:errors/
-html:form method=POST action=/users/saveGroup focus=groupname
+html:form method=POST action=/users/saveGroup !--focus=groupname--
html:hidden property=databaseName/
html:hidden property=objectName/
1.3 +1 -1 jakarta-tomcat-catalina/webapps/admin/users/role.jsp
Index: role.jsp
===
RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/admin/users/role.jsp,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- role.jsp 24 Jul 2002 20:57:28 - 1.2
+++ role.jsp 16 Aug 2002 23:56:18 - 1.3
@@ -17,7 +17,7 @@
html:errors/
-html:form method=POST action=/users/saveRole focus=rolename
+html:form method=POST action=/users/saveRole !--focus=rolename--
html:hidden property=databaseName/
html:hidden property=objectName/
1.3 +1 -1
[PATCH] Xerces 2.0.1 also is buggy
Hi,
Xerces 2.0.1 contains a bug that produce the error Remy reports earlier
this week :-(
Xerces 2.0.2 contains a bug that produce a StackTraceOverflow :-(
In order to supports schema and dtd, Xerces nightly build is the only
version that parse properly DTD and schema when validation is on.
That's a very good reason why we need to have by default validation
turned off ;-)
Thanks,
-- Jeanfrancois
Index: build.properties.default
===
RCS file: /home/cvspublic/jakarta-tomcat-5/build.properties.default,v
retrieving revision 1.29
diff -u -r1.29 build.properties.default
--- build.properties.default16 Aug 2002 17:03:19 - 1.29
+++ build.properties.default16 Aug 2002 23:36:59 -
@@ -103,12 +103,12 @@
regexp.loc=http://jakarta.apache.org/builds/jakarta-regexp/release/v1.2/jakarta-regexp-1.2.tar.gz
-# - Xerces XML Parser, version 2_0_1 -
-xerces.home=${base.path}/xerces-2_0_1
+# - Xerces XML Parser, version 20020815 or latter -
+xerces.home=${base.path}/xml-xerces
xerces.lib=${xerces.home}
xercesImpl.jar=${xerces.lib}/xercesImpl.jar
xmlParserAPIs.jar=${xerces.lib}/xmlParserAPIs.jar
-xerces.loc=http://xml.apache.org/dist/xerces-j/old_xerces2/Xerces-J-bin.2.0.1.tar.gz
+xerces.loc=xml-xerces
# --
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler ScriptingVariabler.java Compiler.java Generator.java JspDocumentParser.java Node.java Parser.java
luehe 2002/08/16 17:14:24
Modified:jasper2/src/share/org/apache/jasper/compiler Tag:
tomcat_4_branch Compiler.java Generator.java
JspDocumentParser.java Node.java Parser.java
Added: jasper2/src/share/org/apache/jasper/compiler Tag:
tomcat_4_branch ScriptingVariabler.java
Log:
Added compilation step which determines, for every custom tag, the
scripting variables that need to be declared. For example, if a custom
action is nested, it must not redeclare the AT_BEGIN variables of its
encapsulating action, etc.
Scripting variables are now generated at the appropriate places,
according to their scope.
Revision ChangesPath
No revision
No revision
1.18.2.3 +6 -3
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Compiler.java
Index: Compiler.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Compiler.java,v
retrieving revision 1.18.2.2
retrieving revision 1.18.2.3
diff -u -r1.18.2.2 -r1.18.2.3
--- Compiler.java 20 Jul 2002 02:44:49 - 1.18.2.2
+++ Compiler.java 17 Aug 2002 00:14:23 - 1.18.2.3
@@ -237,6 +237,9 @@
// Collect page info
Collector.collect(this, pageNodes);
+ // Determine which custom tag needs to declare which scripting vars
+ ScriptingVariabler.set(pageNodes);
+
// generate servlet .java file
Generator.generate(writer, this, pageNodes);
writer.close();
1.35.2.3 +102 -126
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java
Index: Generator.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java,v
retrieving revision 1.35.2.2
retrieving revision 1.35.2.3
diff -u -r1.35.2.2 -r1.35.2.3
--- Generator.java8 Aug 2002 11:00:39 - 1.35.2.2
+++ Generator.java17 Aug 2002 00:14:23 - 1.35.2.3
@@ -235,70 +235,57 @@
page.visit(new TagHandlerPoolVisitor(tagHandlerPoolNames));
}
-
-/*
- * For every custom tag, declares its scripting variables with AT_BEGIN
- * and AT_END scopes.
- */
-private void declareAtBeginAtEndScriptingVariables(Node.Nodes page)
+
+private void declareTemporaryScriptingVars(Node.Nodes page)
throws JasperException {
- class ScriptingVariableDeclarationVisitor extends Node.Visitor {
+ class ScriptingVarVisitor extends Node.Visitor {
- /*
- * Vector keeping track of which scripting variables have already
- * been declared
- */
- private Vector scriptVars;
+ private Vector vars;
- /*
- * Constructor.
- */
- public ScriptingVariableDeclarationVisitor() {
- scriptVars = new Vector();
+ ScriptingVarVisitor() {
+ vars = new Vector();
}
public void visit(Node.CustomTag n) throws JasperException {
- TagVariableInfo[] tagVarInfos = n.getTagVariableInfos();
- VariableInfo[] varInfos = n.getVariableInfos();
-
- if ((varInfos == null) (tagVarInfos == null)) {
- visitBody(n);
- }
-
- if (varInfos != null) {
- for (int i=0; ivarInfos.length; i++) {
- int scope = varInfos[i].getScope();
- String varName = varInfos[i].getVarName();
- if (((scope == VariableInfo.AT_BEGIN)
- || (scope == VariableInfo.AT_END))
- varInfos[i].getDeclare()
- !scriptVars.contains(varName)) {
- out.printin(varInfos[i].getClassName());
- out.print( );
- out.print(varName);
- out.println( = null;);
- scriptVars.add(varName);
+ if (n.getCustomNestingLevel() 0) {
+ TagVariableInfo[] tagVarInfos = n.getTagVariableInfos();
+ VariableInfo[] varInfos = n.getVariableInfos();
+
+ if (varInfos != null) {
+ for (int i=0; ivarInfos.length; i++) {
+ String varName = varInfos[i].getVarName();
+ String tmpVarName = _jspx_ + varName + _
+ + n.getCustomNestingLevel();
+ if (!vars.contains(tmpVarName)) {
+ vars.add(tmpVarName);
+
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Node.java
luehe 2002/08/16 17:15:28 Modified:jasper2/src/share/org/apache/jasper/compiler Node.java Log: removed redundant field Revision ChangesPath 1.26 +3 -4 jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Node.java Index: Node.java === RCS file: /home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Node.java,v retrieving revision 1.25 retrieving revision 1.26 diff -u -r1.25 -r1.26 --- Node.java 16 Aug 2002 23:18:54 - 1.25 +++ Node.java 17 Aug 2002 00:15:27 - 1.26 @@ -889,7 +889,6 @@ private TagFileInfo tagFileInfo; private Class tagHandlerClass; private VariableInfo[] varInfos; - private TagVariableInfo[] nestedTagVarInfos; private int customNestingLevel; private ChildInfo childInfo; private boolean implementsIterationTag; -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] Xerces 2.0.1 also is buggy
Jean-François,
Can you also submit the patch to both BUILDING.txt and build.xml.
build.xml needs to use the cvsbuild target to download and build
Xerces since you can't reliably use downloadgz for nightly builds
since they disappear of the website after 2 weeks.
Patrick
Jean-francois Arcand wrote:
Hi,
Xerces 2.0.1 contains a bug that produce the error Remy reports earlier
this week :-(
Xerces 2.0.2 contains a bug that produce a StackTraceOverflow :-(
In order to supports schema and dtd, Xerces nightly build is the only
version that parse properly DTD and schema when validation is on. That's
a very good reason why we need to have by default validation turned off ;-)
Thanks,
-- Jeanfrancois
Index: build.properties.default
===
RCS file: /home/cvspublic/jakarta-tomcat-5/build.properties.default,v
retrieving revision 1.29
diff -u -r1.29 build.properties.default
--- build.properties.default 16 Aug 2002 17:03:19 - 1.29
+++ build.properties.default 16 Aug 2002 23:36:59 -
@@ -103,12 +103,12 @@
regexp.loc=http://jakarta.apache.org/builds/jakarta-regexp/release/v1.2/jakarta-regexp-1.2.tar.gz
-# - Xerces XML Parser, version 2_0_1 -
-xerces.home=${base.path}/xerces-2_0_1
+# - Xerces XML Parser, version 20020815 or latter -
+xerces.home=${base.path}/xml-xerces
xerces.lib=${xerces.home}
xercesImpl.jar=${xerces.lib}/xercesImpl.jar
xmlParserAPIs.jar=${xerces.lib}/xmlParserAPIs.jar
-xerces.loc=http://xml.apache.org/dist/xerces-j/old_xerces2/Xerces-J-bin.2.0.1.tar.gz
+xerces.loc=xml-xerces
# --
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
Patrick Luby Email: [EMAIL PROTECTED]
Sun Microsystems Phone: 408-276-7471
901 San Antonio Road, USCA14-303
Palo Alto, CA 94303-4900
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 11785] New: - mime-mapping for WMLS is incorrect
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11785. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11785 mime-mapping for WMLS is incorrect Summary: mime-mapping for WMLS is incorrect Product: Tomcat 4 Version: 4.0.3 Final Platform: All OS/Version: Other Status: NEW Severity: Major Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] In tomcat4/conf/web.xml The entry for wmls mime-mapping is incorrect. It is currently mime-mapping extensionwmls/extension mime-typetext/vnd.wap.wmls/mime-type /mime-mapping But, SHOULD BE as follows (I added cript to the MimeType.) mime-mapping extensionwmls/extension mime-typetext/vnd.wap.wmlscript/mime-type /mime-mapping Thank You, Chris. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Watchdog aggregation of headers may be incorrect
Watchdog now merges headers, by design. ie (from the checking message) Modified logic to send duplicate headers as one aggregated header vs. two headers: header1: val1 header1: val2 -will now be- header1: val1, val2 Due to this, it looks like a couple of tests are failing. GetHeadersTest and HttpServletRequestWrapperGetHeadersTest. GetHeadersTest looks for two Accept-Language headers, en-us and ga-us. It does work if they are sent as Accept-Language:en-us Accept-Language:ga-us But, being sent as: Accept-Language:en-us, ga-us it is presented to the servlet as ONE header, with the value en-us, ga-us However, I'm not sure that it shouldn't be. Parsing a multivalued header is not only diffcult, it seems to depend on which header is being parsed. Certainly full interpretation is very dependent on the header, e.g. Accept-Language: da, en-gb;q=0.8, en;q=0.7 Date: Wed, 15 Nov 1995 06:25:24 GMT The first has three values, the second has one. Interpretation depends on the name of the header. I don't believe the Request.getHeaders() mechanism should try and interpret the values after the :. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 8817] - nested custom jsp tags not working?
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8817. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8817 nested custom jsp tags not working? --- Additional Comments From [EMAIL PROTECTED] 2002-08-17 02:04 --- Created an attachment (id=2744) updated tag library descriptor to use JSP for body content instead of tagdependent as suggested -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 8817] - nested custom jsp tags not working?
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8817. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8817 nested custom jsp tags not working? [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Additional Comments From [EMAIL PROTECTED] 2002-08-17 02:13 --- The reply is greatly appreciated, but either i am missing something, or the suggestion does not work. I tried setting the body-content element value to JSP for all of the tags and also just the insert tag, but I saw no difference. The way I am testing the example is to open http://localhost:8080/learning/introduction.jsp. The response should like similar to the one in the example at http://developer.java.sun.com/developer/technicalArticles/javaserverpages/jsp_te mplates Instead, none of the content is included. There are System.outs all over com.bjv.tags.templates.PutTag but none of them are printed during page processing. I don't think that the template:put name=footer content=footer.jsp/ are being processed at all. Any more suggestions? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Watchdog aggregation of headers may be incorrect
- Original Message - From: Patrick Luby [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Friday, August 16, 2002 6:43 PM Subject: Re: Watchdog aggregation of headers may be incorrect Steve, Your assessment is correct: an aggregate header like: header1: val1, val2 should be converted to this for the HttpRequest: header1: val1 header1: val2 Tomcat 4 used to do this conversion correctly but then it stopped doing the conversion a few months ago. This should be fixed as it is Servlet spec non-compliance. However, I am not sure where the parsing of headers is now performed in Tomcat? Can anyone point Steve to where this header parsing of the ServerSocket input stream is being done? For stand-alone, it is: j-t-c/http11/src/java/org/apache/coyote/http11/InternalInputBuffer.parseHead er It's a bit more complicated for Apache/IIS/iPlanet. Patrick Steve Downey wrote: Watchdog now merges headers, by design. ie (from the checking message) Modified logic to send duplicate headers as one aggregated header vs. two headers: header1: val1 header1: val2 -will now be- header1: val1, val2 Due to this, it looks like a couple of tests are failing. GetHeadersTest and HttpServletRequestWrapperGetHeadersTest. GetHeadersTest looks for two Accept-Language headers, en-us and ga-us. It does work if they are sent as Accept-Language:en-us Accept-Language:ga-us But, being sent as: Accept-Language:en-us, ga-us it is presented to the servlet as ONE header, with the value en-us, ga-us However, I'm not sure that it shouldn't be. Parsing a multivalued header is not only diffcult, it seems to depend on which header is being parsed. Certainly full interpretation is very dependent on the header, e.g. Accept-Language: da, en-gb;q=0.8, en;q=0.7 Date: Wed, 15 Nov 1995 06:25:24 GMT The first has three values, the second has one. Interpretation depends on the name of the header. I don't believe the Request.getHeaders() mechanism should try and interpret the values after the :. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Watchdog aggregation of headers may be incorrect
On Friday 16 August 2002 09:43 pm, Patrick Luby wrote: SNIP/ Tomcat 4 used to do this conversion correctly but then it stopped doing the conversion a few months ago. I'll bet dollars to donuts that it was exactly when Coyote was brought in as the connector, replacing the older o.a.c.connector.http.HttpProcessor. Looking at it, it does a lot more detailed parsing of the HTTP headers while receiving the request. Coyote does a lot more lazy evaluation, holding everything in MessageBytes for as long as possible. This saves on unnecessary object creation and GC. This should be fixed as it is Servlet spec non-compliance. However, I am not sure where the parsing of headers is now performed in Tomcat? This shouldn't be handled as part of parsing headers off the wire. I think it should probably be handled in org.apache.tomcat.util.http.MimeHeaders, when the value, or values, is/are actually requested. Header names can be mapped to different content models. This might improve performace in getIntHeader and getDateHeader.X-headers and unknown headers should probably get mapped to TEXT. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
