Re: [5] Config

[Costin Manolache]

Craig R. McClanahan wrote:

> (Breathing a sigh of relief that I don't actually have to *implement* this
> stuff, but hoping to contribute a little anyway :-)

Well, the fact that I don't have to implement much is a relief for me too...
Both the API and a lot of drivers ( including xml file ) are already
written, we have a lot of support ( caching, etc ) already and Remy is an
expert.


>> For API - my initial approach was to create a clone of 1.4 prefs.
> 
> Thinking outside the box a little, what would be the implications of
> prereq'ing JDK 1.4 as the minimum for Tomcat 5?  Then, we could consider
> using prefs directly instead of via wrappers.

The reason I prefer JNDI over prefs have nothing to do with the VM. 
JNDI is much more mature, more widely used, more powerfull, we
already have a lot of support and knowledge, there are many drivers.

And it supports the 'distributed / high-end' use case ( directory 
server ) out-of-box.

I don't mind having prefs used by default if 1.4 is detected - 
i.e. registry on windows and .xml files on unix. It is quite
easy to write a JNDI context that uses prefs underneath. 
I don't mind using 1.4 features - but using 1.4 as a minimm is 
a bit too much. Even 1.3 may be questionable. 

For me the baseline is what GCJ supports ( i.e. the classpath project ).
I still believe in 'java everywhere' :-)


> Using DirContext instead of just Context would also let us think about a
> storage format with fewer objects in it -- one per managed object instead
> of one per property -- because we could use JNDI attributes for the
> individual properties themselves.  Such an entry maps pretty directly to
> *being* an MBean as well ... it might be possible to kill two birds with
> one stone here.

Exactly ! And one nice thing in JNDI is that we can do a lot of 'lazy'
evaluation. If nobody is going to configure an object, there is no
point introspecting it. Just bind it to a context and when someone
asks for attributes we do the introspection. And you can also 
construct objects dynamically - which is even better. 

JMX will require you to register each object and most implementations
will do a full introspection when you register. And that involves a lot
of objects and overhead.


> Some utility methods that perform direct conversion between the structured
> name types would be well worth it performance-wise.  We don't want to be
> dealing with the String versions of these names any more than we'd have
> to.

+1
The jndi Name is not bad. And it maps well into JMX ObjectName. 


>> 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 ).
>>
> 
> Note that this would need to include configuration changes the component
> does for itself (i.e. calculate the work directory path if one hasn't been
> explicitly configured), not just those performed by external management
> tools.

I don't agree. The configuration is what the user specifies. What the 
component determines by itself shouldn't slip into the config file. 
Only user-initiated config must be stored ( exactly like if the user would 
edit the file directly and restart ). 

 
>> Any operation ( reload, etc ) will be done via JMX - only
>> setting attributes is important for config.
>>
> 
> While on that topic, it would be useful for some managed objects to
> support two "instances" of a component in memory simultaneously -- for
> example, when upgrading a webapp you often want to leave the old version
> running (and accepting requests) until the new version has been fully
> initialized and is ready to start accepting requests.

Probably a 'ver' component in the name ? 

We really need to reorganize the JMX names.


> Part of the motivation for JMX in the first place was to support the
> ability to have external management apps be able to talk with it.  If we
> didn't need that, we wouldn't really need it -- we could just use JNDI to
> represent the internal component hierarchy (extending the way Catalina
> already represents a webapp's static resources as a JNDI context).

I know. JMX is also necesary to support 'operations' ( reload, start, etc ).
But the nice thing about using JNDI as the 'first line' is that JMX can
be used with less performance impact. For example we can have a 'master'
jmx object that would register other on demand - using the information
in the JNDI hierarchy.

 
 
> One avenue to consider if the number of MBeans becomes an issue (I'm not
> sure that it really is -- we've got an instance of the real component
> class per component anyway) is to make MBeans only for coarse grained
> things, and represent fine-grained things as attributes of the coarse
> grained MBeans.  Conceptually, this is the same sort of design choice you
> make with entity EJBs about how fine grained you get.  It's not
> necessarily an all-or-nothing decision.

Well, on MBean per servlet is important if you wa

Re: [5][PATCH]Run Watchdog from the jakarta-tomcat-5 build.xml

[Patrick Luby]

Costin,

I took a look at InspectionUtils.guessInstall() and it looks OK.
However, it has one limitation: it looks at the classpath to guess the
install directory. This works in most cases, but does not work when the
InspectionUtils class is loaded in a classloader. Since both the
commons-launcher and some J2EE servers load Tomcat's Bootstrap class via
a classloader, InspectionUtils.guessInstall() may not work correctly.

The way I worked around this in commons-launcher was to invoke the
getResource() resource on the class e.g. Bootstrap.class.getResource("/"
+ Bootstrap.class.getName() + ".class") to get the classpath element
that this main class was loaded from. This works even if another
application is loading your application using a classloader.

At this point, I could port this "getResource()" logic into
InspectionUtils or I can put this code directly in Bootstrap.java.

What is your preference?

Patrick

[EMAIL PROTECTED] wrote:
> 
> On Thu, 15 Aug 2002, Patrick Luby wrote:
> 
> > Costin,
> >
> > [EMAIL PROTECTED] wrote:
> > > Patrick ( if you read this ) - what's the status with the 'guess home' ?
> > > I can use IntrospectionUtils - it has the whole thing in it ( home/base
> > > setting, find in classpath ). We already need IU for jk - it just needs
> > > to be included in bootstrap.jar to do that.
> > >
> >
> > I haven't ported this yet but I can do it very quickly. The question is
> > where should we put it? Originally, I was going to put it in the
> > Bootstrap.getCatalinaHome() method. However, since we are moving towards
> > using CatalinaService, do you think I should put it there?
> 
> Probably Bootrstrap is the best place - since it needs to construct the
> classpath to load CatalinaService ( so it needs it ).
> 
> If you just include IntrospectionUtil from j-t-c you get it all -
> ( it is used in jk already ). All you need ( besides build.xml changes )
> is:
> 
>  home= IntrospectionUtils.guessInstall("catalina.home", "catalina.base",
>"bootstrap.jar",
> "org.apache.catalina.startup.CatalinaService");
> 
> That will set catalina.home/catalina.base:
> -  if only one is set the other will take that value.
> -  if none is set, it'll look in CLASSPATH for bootstrap.jar and go one
> level up, or for org/apache... if classes/ is used - and set catalina.home
> fromt that.
> 
> You don't need to port it - it is useable directly. ( well, you can
> cut&paste the method if you want, it's independent of the rest )
> 
> Costin
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 

-- 
_
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:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-5 BUILDING.txt build.properties.default build.xml

[patrickl]

patrickl2002/08/15 19:04:14

  Modified:.BUILDING.txt build.properties.default build.xml
  Log:
  Update build to use commons-digester nightly build since it is required to handle 
DTD validation properly
  Submitted by: Jean-Francois Arcand ([EMAIL PROTECTED])
  
  Revision  ChangesPath
  1.19  +2 -2  jakarta-tomcat-5/BUILDING.txt
  
  Index: BUILDING.txt
  ===
  RCS file: /home/cvs/jakarta-tomcat-5/BUILDING.txt,v
  retrieving revision 1.18
  retrieving revision 1.19
  diff -u -r1.18 -r1.19
  --- BUILDING.txt  14 Aug 2002 15:46:37 -  1.18
  +++ BUILDING.txt  16 Aug 2002 02:04:14 -  1.19
  @@ -216,7 +216,7 @@
   
   (8) Download and Install the Commons Digester Binary Distribution
   
  -* Download a binary distribution (version 1.3 or later) from:
  +* Download a binary distribution (version 20020815 or later) from:
   
   http://jakarta.apache.org/builds/jakarta-commons/release/commons-digester
   
  
  
  
  1.28  +4 -4  jakarta-tomcat-5/build.properties.default
  
  Index: build.properties.default
  ===
  RCS file: /home/cvs/jakarta-tomcat-5/build.properties.default,v
  retrieving revision 1.27
  retrieving revision 1.28
  diff -u -r1.27 -r1.28
  --- build.properties.default  13 Aug 2002 16:52:19 -  1.27
  +++ build.properties.default  16 Aug 2002 02:04:14 -  1.28
  @@ -72,11 +72,11 @@
   commons-daemon.loc=jakarta-commons-sandbox/daemon
   
   
  -# - Commons Digester, version 1.3 or later -
  -commons-digester.home=${base.path}/commons-digester-1.3
  +# - Commons Digester, version 20020815 or later -
  +commons-digester.home=${base.path}/commons-digester/dist
   commons-digester.lib=${commons-digester.home}
   commons-digester.jar=${commons-digester.lib}/commons-digester.jar
  
-commons-digester.loc=http://jakarta.apache.org/builds/jakarta-commons/release/commons-digester/v1.3/commons-digester-1.3.tar.gz
  +commons-digester.loc=jakarta-commons/digester
   
   
   # - Commons Logging, version 1.0.1 or later -
  
  
  
  1.30  +0 -5  jakarta-tomcat-5/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-5/build.xml,v
  retrieving revision 1.29
  retrieving revision 1.30
  diff -u -r1.29 -r1.30
  --- build.xml 14 Aug 2002 20:46:52 -  1.29
  +++ build.xml 16 Aug 2002 02:04:14 -  1.30
  @@ -570,11 +570,6 @@
   
   
   
  -  
  -  
  -
  -
  -
 
 
   
  
  
  

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: [5.0] [PROPOSAL] Refactored mapper

[Bill Barker]

- Original Message -
From: "Remy Maucherat" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Thursday, August 15, 2002 10:23 AM
Subject: [5.0] [PROPOSAL] Refactored mapper


> Hi,
>
> I have been hinting at rewriting the main Catalina mapper for Tomcat 5.
>
> The proposal is designed to improve performance, avoid generating
> uneeded garbage String objects, and optimize the welcome files processing.
>
> The following changes are proposed:
> - Expose the decoded URI MessageBytes in the main Request interface of
> Catalina, so that the mapper doesn't have to pay the b2c cost
> - Implement the new mappers as a separate set of classes in
> j-t-c/util/../mapper

I'm hoping that this doesn't imply a dependency in j-t-c/util on
o.a.c.Mapper.  It's mostly the TC3.3 build that I'm worried about.

>
> The new mappers will use exclusively bytes to match contexts/servlets
> and will rewrite the original URIs to handle welcome files without
> sending a redirect back to the client (in most cases).
>

+1 (i.e. I'm willing to help out, if you want).

> Remy
>
>
> --
> To unsubscribe, e-mail:

> For additional commands, e-mail:

>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

jk2 crashes apache2

[Peter T. Abplanalp]

hi all.  i have spent the evening trying to get tomcat 4.0.4 connected
to apache 2 via mod_jk2 with no success.  i got the cvs jtc, compiled
the java side, installed the java stuff in tomcat, compiled the native
stuff, installed that in apache2, created my jk2 and workers2
properties files in the requisite places and tomcat seems to start ok,
although i do get an error that it can't find
${catalina.home}/conf/jk2.properties eventhough the files is there and
tomcat appears to use it as the socket file shows up.  so, i think
tomcat is in good shape; however, apache seg faults.  please find the
output of an strace attached.  apache seems to die while trying to
read the workers2.properties file.

any and all help greatly appreciated!

-- 
Peter Abplanalp

Email:   [EMAIL PROTECTED]
PGP: pgp.mit.edu


execve("/usr/local/apache2/bin/apachectl", ["/usr/local/apache2/bin/apachectl", 
"start"], [/* 21 vars */]) = 0
uname({sys="Linux", node="solo.psaconsultants.com", ...}) = 0
brk(0)  = 0x80d0ef0
open("/etc/ld.so.preload", O_RDONLY)= -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY)  = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=69093, ...}) = 0
old_mmap(NULL, 69093, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40013000
close(3)= 0
open("/lib/libtermcap.so.2", O_RDONLY)  = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\260\r\0"..., 1024) = 1024
fstat64(3, {st_mode=S_IFREG|0755, st_size=11832, ...}) = 0
old_mmap(NULL, 14932, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40024000
mprotect(0x40027000, 2644, PROT_NONE)   = 0
old_mmap(0x40027000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x2000) = 
0x40027000
close(3)= 0
open("/lib/libdl.so.2", O_RDONLY)   = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\260\30"..., 1024) = 1024
fstat64(3, {st_mode=S_IFREG|0755, st_size=11728, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x40028000
old_mmap(NULL, 11300, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40029000
mprotect(0x4002b000, 3108, PROT_NONE)   = 0
old_mmap(0x4002b000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x1000) = 
0x4002b000
close(3)= 0
open("/lib/libc.so.6", O_RDONLY)= 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0hr\1\000"..., 1024) = 1024
fstat64(3, {st_mode=S_IFREG|0755, st_size=1344152, ...}) = 0
old_mmap(NULL, 1207648, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4002c000
mprotect(0x4014a000, 36192, PROT_NONE)  = 0
old_mmap(0x4014a000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x11e000) 
= 0x4014a000
old_mmap(0x4014f000, 15712, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, 
-1, 0) = 0x4014f000
close(3)= 0
munmap(0x40013000, 69093)   = 0
brk(0)  = 0x80d0ef0
brk(0x80d1000)  = 0x80d1000
brk(0x80d2000)  = 0x80d2000
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
open("/dev/tty", O_RDWR|O_NONBLOCK|O_LARGEFILE) = 3
close(3)= 0
brk(0x80d3000)  = 0x80d3000
brk(0x80d4000)  = 0x80d4000
open("/usr/share/locale/locale.alias", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=2601, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x40013000
read(3, "# Locale name alias data base.\n#"..., 4096) = 2601
brk(0x80d5000)  = 0x80d5000
brk(0x80d6000)  = 0x80d6000
brk(0x80d7000)  = 0x80d7000
read(3, "", 4096)   = 0
close(3)= 0
munmap(0x40013000, 4096)= 0
open("/usr/lib/locale/en_US.iso885915/LC_IDENTIFICATION", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=371, ...}) = 0
old_mmap(NULL, 371, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40013000
close(3)= 0
open("/usr/lib/gconv/gconv-modules.cache", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=20666, ...}) = 0
old_mmap(NULL, 20666, PROT_READ, MAP_SHARED, 3, 0) = 0x40014000
close(3)= 0
open("/usr/lib/locale/en_US.iso885915/LC_MEASUREMENT", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=29, ...}) = 0
old_mmap(NULL, 29, PROT_READ, MAP_PRIVATE, 3, 0) = 0x4001a000
close(3)= 0
open("/usr/lib/locale/en_US.iso885915/LC_TELEPHONE", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=65, ...}) = 0
old_mmap(NULL, 65, PROT_READ, MAP_PRIVATE, 3, 0) = 0x4001b000
close(3)= 0
open("/usr/lib/locale/en_US.iso885915/LC_ADDRESS", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=161, ...}) = 0
old_mmap(NULL, 161, PROT_READ, MAP_PRIVATE, 3, 0) = 0x4001c000
close(3) 

Re: Absolute fields required for JDBC & JNDI Realm pages in adminwebapp

[Amy Roh]

John,

Thanks for the feedback.

John Holman wrote:

> Amy
>
> Yes - much too strict for JNDIRealm!

I agree!

> The only configuration attributes
> that should always be specified for this realm are className and
> connectionURL. In addition either userPattern or userSearch must be
> specified (but not both). Other attributes either have default values,
> or not specifying them is itself significant (e.g. if userPassword is
> not specified the realm attempts to bind as the user rather than
> retrieve the user's password). (Note that the realm docs on the website
> are out of date, but the CVS and 4.1.8+  releases have new documentation
> which covers all of this).

I just committed fixes to validate only className and connectionURL and also to
check either userPattern or userSearch is specified but not both.

>
>
> In this connection, there is a problem with the admin application, which
> when it writes out a new version of the server.xml file converts all
> attributes that are unspecified by the user (e.g. in the original
> server.xml file) to attributes that are specified and have the empty
> string as their value This breaks JNDIRealm at the moment, and perhaps
> some other components as well (e.g. other realms).

I committed fixes for this problem so that admin webapp doesn't set various
properties if users don't specify them in the page.

>
>
> However  I suspect this might be awkward to fix because of the way web
> forms work. If you can confirm that the admin app will continue to
> behave in this way (replacing null values with "" for all configuration
> attributes) then I can send you a patch for JNDIRealm to treat these
> values as equivalent. Configuration code in other components might also
> need to change - e.g. RealmBase decides whether a digest is being used
> by testing the value of the digest attribute against null, and throws an
> exception if it gets the empty string, since this is not null but not
> the name of a known digest algorithm either.

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.

I still need someone to comment on other realms so I can make them more
"user-friendly".

Thanks,
Amy

>
>
> John
>
> Amy Roh wrote:
>
> > JDBC and JNDI Realms have many attributes.  What's the minimum list of
> > attributes to enable these two Realms?  I'll need to know the minimum
> > required list of attributes to validate the realm pages in admin
> > webapp.  Currently, it's validating all the fields as required which I
> > think is too strict.
> >
> > Thanks,
> > Amy
> >
> >
> > --
> > To unsubscribe, e-mail:
> > 
> > For additional commands, e-mail:
> > 
> >
>
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/mbeans mbeans-descriptors.xml

[amyroh]

amyroh  2002/08/15 17:31:08

  Modified:catalina/src/share/org/apache/catalina/mbeans
mbeans-descriptors.xml
  Log:
  Minor change in format.
  
  Revision  ChangesPath
  1.67  +18 -18
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/mbeans/mbeans-descriptors.xml
  
  Index: mbeans-descriptors.xml
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/mbeans/mbeans-descriptors.xml,v
  retrieving revision 1.66
  retrieving revision 1.67
  diff -u -r1.66 -r1.67
  --- mbeans-descriptors.xml13 Aug 2002 22:37:06 -  1.66
  +++ mbeans-descriptors.xml16 Aug 2002 00:31:08 -  1.67
  @@ -1016,6 +1016,10 @@
 description="The connection URL for the server we will contact"
type="java.lang.String"/>
   
  +
  +
   
  @@ -1029,19 +1033,14 @@
 description="The base element for role searches"
type="java.lang.String"/>
   
  -
  -
  - 
  -
   
   
  +
  +
   
   
  -
  -
   
  @@ -1064,13 +1058,19 @@
 description="The message format used to select a user"
type="java.lang.String"/>
   
  + 
  +
  
   
  -
  +
   
 
   
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/realm JNDIRealmForm.java SaveJNDIRealmAction.java

[amyroh]

amyroh  2002/08/15 17:30:45

  Modified:webapps/admin/WEB-INF/classes/org/apache/webapp/admin
ApplicationResources_en.properties
ApplicationResources_es.properties
   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.67  +1 -0  
jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/ApplicationResources_en.properties
  
  Index: ApplicationResources_en.properties
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/ApplicationResources_en.properties,v
  retrieving revision 1.66
  retrieving revision 1.67
  diff -u -r1.66 -r1.67
  --- ApplicationResources_en.properties13 Aug 2002 22:35:20 -  1.66
  +++ ApplicationResources_en.properties16 Aug 2002 00:30:45 -  1.67
  @@ -260,6 +260,7 @@
   error.userPassword.required=User Password is required.
   error.userPattern.required=User pattern is required.
   error.userSearch.required=User search is required.
  +error.userPattern.userSearch.defined=Either userPattern or userSearch must be 
specified not both.
   error.contextFactory.required=Context Factory is required.
   error.connPassword.required=Connection password is required.
   error.connURL.required=Connection URL is required.
  
  
  
  1.56  +8 -7  
jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/ApplicationResources_es.properties
  
  Index: ApplicationResources_es.properties
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/ApplicationResources_es.properties,v
  retrieving revision 1.55
  retrieving revision 1.56
  diff -u -r1.55 -r1.56
  --- ApplicationResources_es.properties13 Aug 2002 22:35:20 -  1.55
  +++ ApplicationResources_es.properties16 Aug 2002 00:30:45 -  1.56
  @@ -258,8 +258,9 @@
   error.rolePattern.required=Se requiere el modelo de la busqueda del papel.
   error.userBase.required=Se requiere el elemento bajo del usuario.
   error.userPassword.required=Se requiere la palabra de paso del utilizador.
  -error.userPattern.required=Se requiere el patrón del usuario.
  -error.userSearch.required=Se requiere la búsqueda del usuario.
  +error.userPattern.required=Se requiere el patr=n del usuario.
  +error.userSearch.required=Se requiere la b·squeda del usuario.
  +error.userPattern.userSearch.defined=UserPattern o userSearch se deben 
especificar no ambos.
   error.contextFactory.required=Se requiere la factory del contexto.
   error.connPassword.required=Se requiere la palabra de paso de la conexion.
   error.connURL.required=Se requiere el URL de la conexion.
  @@ -313,16 +314,16 @@
   resources.error.entryType.notimpl=Validaci=n para este tipo no puesto en 
ejecucio'n todavfa.
   resources.error.url.required=Se requiere el URL de Datasource.
   resources.error.driverClass.required=Se requiere la clase del conductor de 
JDBC.
  -resources.error.active.required=Se requieren las conexiones activas 
m¯ximas.
  -resources.error.idle.required=Se requieren las conexiones ociosas m¯ximas.
  -resources.error.wait.required=La espera m¯xima para una conexi=n se 
requiere.
  +resources.error.active.required=Se requieren las conexiones activas 
m»ximas.
  +resources.error.idle.required=Se requieren las conexiones ociosas m»ximas.
  +resources.error.wait.required=La espera m»xima para una conexi=n se 
requiere.
   resources.error.mailhost.required=mail.smtp.host is required.
  -resources.integer.error=Error inv¯lido del n+mero entero.
  +resources.integer.error=Error inv»lido del n+mero entero.
   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=Path requerido
   resources.error.jndiName.required=JNDI Nombre requerido
  
  
  
  1.10  +54 -38
jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/realm/JNDIRealmForm.java
  
  Index: JNDIRealmForm.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/realm/JNDIRealmForm.java,v
  retrieving revision 1.9
  retrieving revision 1.10
  diff -u -r1.9 -r1.10
  --- JNDIRealmForm.java13 Aug 2002 22:35:20 -000

Re: [5] Config

[Craig R. McClanahan]

(Breathing a sigh of relief that I don't actually have to *implement* this
stuff, but hoping to contribute a little anyway :-)

On Thu, 15 Aug 2002 [EMAIL PROTECTED] wrote:

> Date: Thu, 15 Aug 2002 15:50:00 -0700 (PDT)
> From: [EMAIL PROTECTED]
> Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> To: List Tomcat-Dev <[EMAIL PROTECTED]>
> Subject: [5] Config
>
> 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.

Thinking outside the box a little, what would be the implications of
prereq'ing JDK 1.4 as the minimum for Tomcat 5?  Then, we could consider
using prefs directly instead of via wrappers.

> 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.
>

Using DirContext instead of just Context would also let us think about a
storage format with fewer objects in it -- one per managed object instead
of one per property -- because we could use JNDI attributes for the
individual properties themselves.  Such an entry maps pretty directly to
*being* an MBean as well ... it might be possible to kill two birds with
one stone here.

> 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.

Some utility methods that perform direct conversion between the structured
name types would be well worth it performance-wise.  We don't want to be
dealing with the String versions of these names any more than we'd have
to.

>
> 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  - 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 ).
>

Note that this would need to include configuration changes the component
does for itself (i.e. calculate the work directory path if one hasn't been
explicitly configured), not just those performed by external management
tools.

> Any operation ( reload, etc ) will be done via JMX - only
> setting attributes is important for config.
>

While on that topic, it would be useful for some managed objects to
support two "instances" of a component in memory simultaneously -- for
example, when upgrading a webapp you often want to leave the old version
running (and accepting requests) until the new version has been fully
initialized and is ready to start accepting requests.

> 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 ).
>

Yep :-)

> 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.
>

Part of the motivation for JMX in the first place

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/valves ErrorDispatcherValve.java

[patrickl]

patrickl2002/08/15 16:51:14

  Modified:catalina/src/share/org/apache/catalina/valves
ErrorDispatcherValve.java
  Log:
  If a Servlet generates a RuntimeException, it is wrapped by a ServletException. 
Since there is an entry for ServletException in the web.xml, the actual root cause (in 
this case, an IllegalStateException) was never unwrapped, thus leading to unexpected 
behavior.
  
  I made a simple modification to the logic so that if the throwable passed to the 
ErrorDispatcherValve is a ServletException, it will attempt to get the root cause.  If 
the root cause is null, then proceed with the error page lookup with the 
ServletException as the throwable object, otherwise, use the root cause for the error 
page lookup.
Submitted by:   Ryan Lubke ([EMAIL PROTECTED])
  
  Revision  ChangesPath
  1.9   +14 -14
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/valves/ErrorDispatcherValve.java
  
  Index: ErrorDispatcherValve.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/valves/ErrorDispatcherValve.java,v
  retrieving revision 1.8
  retrieving revision 1.9
  diff -u -r1.8 -r1.9
  --- ErrorDispatcherValve.java 2 Dec 2001 22:19:26 -   1.8
  +++ ErrorDispatcherValve.java 15 Aug 2002 23:51:14 -  1.9
  @@ -212,20 +212,20 @@
*/
   protected void throwable(Request request, Response response,
Throwable throwable) {
  -
   Context context = request.getContext();
   if (context == null)
   return;
  -
  +
   Throwable realError = throwable;
  -ErrorPage errorPage = findErrorPage(context, realError);
  -if ((errorPage == null) && (realError instanceof ServletException)) {
  +
  +if (realError instanceof ServletException) {
   realError = ((ServletException) realError).getRootCause();
  -if (realError != null)
  -errorPage = findErrorPage(context, realError);
  -else
  +if (realError == null) {
   realError = throwable;
  -}
  +}
  +} 
  +
  +ErrorPage errorPage = findErrorPage(context, realError);
   
   if (errorPage != null) {
   response.setAppCommitted(false);
  @@ -237,7 +237,7 @@
   sreq.setAttribute(Globals.ERROR_MESSAGE_ATTR,
 throwable.getMessage());
   sreq.setAttribute(Globals.EXCEPTION_ATTR,
  -  throwable);
  +  realError);
   Wrapper wrapper = request.getWrapper();
   if (wrapper != null)
   sreq.setAttribute(Globals.SERVLET_NAME_ATTR,
  @@ -246,7 +246,7 @@
   sreq.setAttribute(Globals.EXCEPTION_PAGE_ATTR,
 ((HttpServletRequest) sreq).getRequestURI());
   sreq.setAttribute(Globals.EXCEPTION_TYPE_ATTR,
  -  throwable.getClass());
  +  realError.getClass());
   if (custom(request, response, errorPage)) {
   try {
   sresp.flushBuffer();
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 11755] - Possible to hang new instance if old instance is not yet fully shut down

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=11755

Possible to hang new instance if old instance is not yet fully shut down





--- Additional Comments From [EMAIL PROTECTED]  2002-08-15 23:48 ---
The two RFEs are bug 11753 and bug 11754 -
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11753
   
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11754
 
dealing with synchronous startup script and shutdown script

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 11755] New: - Possible to hang new instance if old instance is not yet fully shut down

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=11755

Possible to hang new instance if old instance is not yet fully shut down

   Summary: Possible to hang new instance if old instance is not yet
fully shut down
   Product: Tomcat 4
   Version: 4.0.4 Final
  Platform: PC
OS/Version: Linux
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


If one Tomcat process is in the process of shutting down, and another
Tomcat process is then launched from the same set of config files
(same control port) -- *before* the first one has fully shut down --
then it is possible to get in a state where the new Tomcat is
*partially* running, in a sort of undead state -- it is alive, yet
does not work, yet also prevents further Tomcat instances from
running.

This state is reflected in catalina.out by the error message

StandardServer.await: create[8005]: java.net.BindException: Address already in use
java.net.BindException: Address already in use
at java.net.PlainSocketImpl.socketBind(Native Method)
at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:405)
at java.net.ServerSocket.(ServerSocket.java:170)
at org.apache.catalina.core.StandardServer.await(StandardServer.java:277)
at org.apache.catalina.startup.Catalina.start(Catalina.java:794)
at org.apache.catalina.startup.Catalina.execute(Catalina.java:681)
at org.apache.catalina.startup.Catalina.process(Catalina.java:179)
at java.lang.reflect.Method.invoke(Native Method)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:243)

It seems to happen when the original instance has shut down its port
8005 listener, but has not yet closed its port 8080 listener, allowing
the second instance to grab 8005 yet fail to open 8080.  This, in
turn, keeps the third instance from launching at all.  (I may be wrong
about the order, but I have a feeling that the theme of the deadlock
is port socket listeners.)

In Linux this undead state is also signified by the "ps" utility
showing 10 Tomcat threads/processes, instead of the usual 30 or so.

The proper behavior is probably for the second Tomcat to either fail
gracefully and completely when it fails to establish all its
listeners, and/or to wait a moment and try again (perhaps up to a
minute, at which point it should fail completely).

Fixing this (along with the other two RFEs) is important for the implementation
of a restart script, which is a pretty useful thing for a sysadmin to have.

I have been off the Tomcat team for a while, but if a current developer wants to
point me in the right direction, please let me know and I'll see if I can take a
stab at writing a patch myself.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 11754] New: - Synchronous shutdown script - shutdown.sh should wait until Tomcat is fully shut down

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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

   Summary: Synchronous shutdown script - shutdown.sh should wait
until Tomcat is fully shut down
   Product: Tomcat 4
   Version: 4.0.4 Final
  Platform: PC
OS/Version: Linux
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Currently the shutdown script ("shutdown.sh" or "catalina.sh
shutdown") connects to Tomcat, tells it to shut down, then immediately
exits.  It would be desirable if there were a mode in which it delayed
exiting until all webapps were completely shut down and no aspect of
the server were able to accept TCP or HTTP requests.

Bonus points if it provided feedback during the shutdown process,
announcing mesages like "Beginning to stop context foo" and "Finished
stopping context foo" and "Tomcat completely shut down".

Motivation: I have been using Tomcat in a testing mode, where I launch
Tomcat, run my tests, and then shut Tomcat down.  Prior to launching
Tomcat, I need to shut down any *already-running* instances.  However,
since the time required to *really* shut down is variable, I often
misjudge the timing and end up launching the new instance before the
old one is shut down.  This leads to an unclean startup for the new
instance, due to (I presume) port conflicts.  If, instead, the
shutdown script did not exit until shutdown of the old instance were
*complete* (and not just started), I would be assured of a clean
startup for the new instance.

A simple implementation of this would just "ping" the control port,
exiting only when the port is closed.  Would that work, or is it
possible that the control port is closed (no longer accepting
requests) but one or more contexts are still active?

I have been off the Tomcat team for a while, but if this feature is
desirable, and a current developer wants to point me in the right
direction, please let me know and I'll see if I can take a stab at
writing a patch myself.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 11753] New: - Synchronous startup script - startup.sh should wait until Tomcat is fully started

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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

   Summary: Synchronous startup script - startup.sh should wait
until Tomcat is fully started
   Product: Tomcat 4
   Version: 4.0.4 Final
  Platform: PC
OS/Version: Linux
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Currently the startup script ("startup.sh" or "catalina.sh startup")
launches Tomcat in a background process, then immediately exits.  It
would be desirable if there were a mode in which it delayed exiting
until all webapps were initialized, running, and able to accept HTTP
requests.

Bonus points if it provided feedback during the startup process,
announcing log mesages like "Starting context foo" back to the caller
until all contexts are ready.

Even more bonus points if it prints an error and returns a nonzero
exit status if the server could not start for some reason.
(e.g. "java.net.BindException: Address already in use:8080" or
"StandardServer.await: create[8005]: java.net.BindException: Address
already in use", both of which mean that a prior instance of Tomcat
has not been completely shut down)

Motivation: I have been using Tomcat in a testing mode, where I launch
Tomcat, run my tests, and then shut Tomcat down.  If the tests
immediately start sending requests to Tomcat, I often get errors
(which I will summarize in a separate bug report) that are due to the
webapp or server not being completely started up.  A workaround is to
use a delay between Tomcat startup and running the tests.
Unfortunately, the amount of time necessary for the delay is variable
(from 10 to 45 seconds depending on load and CPU speed), and since I
run these tests frequently, every second counts.

I have been off the Tomcat team for a while, but if this feature is
desirable, and a current developer wants to point me in the right
direction, please let me know and I'll see if I can take a stab at
writing a patch myself.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[5] Config

[cmanolache]

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  - 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 ? 

Costin


 






--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 11752] New: - Tomcat 4.0.4 does not play well with xerces2

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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

   Summary: Tomcat 4.0.4 does not play well with xerces2
   Product: Tomcat 4
   Version: 4.0.4 Final
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


If xerces 2 .jar files are included in the WEB-INF/lib directory,
.jsp pages cannot be successfully dispatched.  Tomcat generates an
internal server error with:

java.lang.NoClassDefFoundError: org/w3c/dom/DOMErrorHandler

I found several other similar (but not identical) bug reports that
have been closed as fixed (6374 and 6248), but did not find any
open bug reports describing this specific problem.

To demonstrate this problem:

1) Place xerces2 jar files (xerces-xercesImpl.jar, xerces-xmlParserAPIs.jar)
into the WEB-APP/lib directory.

2) Place the sample HelloWorld.jsp page (see below) into web app's root
directory.

3) Compile the sample HelloWorld.java servlet (see below), and place the
.class file into the WEB-INF/classes directory.

4) Set up an appropriate web.xml file, and invoke the HelloWorld servlet from
a web browser.

--Sample HelloWorld.jsp page:


Hi


Hey there



-- Sample HelloWorld Servlet:
import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
public class HelloWorld extends HttpServlet {
public void doGet(HttpServletRequest request,
HttpServletResponse response)
  throws ServletException, IOException
{
RequestDispatcher requestDispatcher = 
getServletContext().getRequestDispatcher("/HelloWorld.jsp");
requestDispatcher.forward(request, response);
}
}

Sample traceback:
root cause 

java.lang.NoClassDefFoundError: org/w3c/dom/DOMErrorHandler
at java.lang.ClassLoader.defineClass0(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:486)
at 
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:111)
at 
org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLoader
.java:1643)
at 
org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:93
7)
at 
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:13
72)
at 
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:12
54)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:313)
at org.apache.xerces.dom.CoreDocumentImpl.(CoreDocumentImpl.java:173)
at org.apache.xerces.dom.DocumentImpl.(DocumentImpl.java:173)
at 
org.apache.xerces.dom.DeferredDocumentImpl.(DeferredDocumentImpl.java:194)
at 
org.apache.xerces.dom.DeferredDocumentImpl.(DeferredDocumentImpl.java:189)
at 
org.apache.xerces.parsers.AbstractDOMParser.startDocument(AbstractDOMParser.java
:712)
at 
org.apache.xerces.impl.XMLNamespaceBinder.startDocument(XMLNamespaceBinder.java:
444)
at 
org.apache.xerces.impl.dtd.XMLDTDValidator.startDocument(XMLDTDValidator.java:64
4)
at 
org.apache.xerces.impl.XMLDocumentScannerImpl.startEntity(XMLDocumentScannerImpl
.java:431)
at 
org.apache.xerces.impl.XMLEntityManager.startEntity(XMLEntityManager.java:878)
at 
org.apache.xerces.impl.XMLEntityManager.startDocumentEntity(XMLEntityManager.jav
a:741)
at 
org.apache.xerces.impl.XMLDocumentScannerImpl.setInputSource(XMLDocumentScannerI
mpl.java:260)
at 
org.apache.xerces.parsers.DTDConfiguration.parse(DTDConfiguration.java:498)
at 
org.apache.xerces.parsers.DTDConfiguration.parse(DTDConfiguration.java:580)
at org.apache.xerces.parsers.XMLParser.parse(XMLParser.java:152)
at org.apache.xerces.parsers.DOMParser.parse(DOMParser.java:253)
at 
org.apache.xerces.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:201)
at javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:122)
at 
org.apache.jasper.parser.ParserUtils.parseXMLDocument(ParserUtils.java:201)
at 
org.apache.jasper.compiler.TldLocationsCache.processWebDotXml(TldLocationsCache.
java:165)
at 
org.apache.jasper.compiler.TldLocationsCache.(TldLocationsCache.java:138)
at 
org.apache.jasper.EmbededServletOptions.(EmbededServletOptions.java:350)
at org.apache.jasper.servlet.JspServlet.init(JspServlet.java:265)
at 
org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:918)
at 
org.apache.catalina.core.StandardWrapper.allocate(Stan

Re: [5.0] [PROPOSAL] Refactored mapper

[Patrick Luby]

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


[EMAIL PROTECTED] wrote:
> 
> On Thu, 15 Aug 2002, 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 t
> > spec requires.
> >
> > Again, I have sent many messages to the spec leads about this issue
> > without any result, so I give up ...
> 
> The current specification is not implementable for Apache ( or any other
> web server ) - and it breaks every pattern that was used in the web.
> 
> I don't know if we have any representative in the expert group or
> what's the procedure that apache follows in voting for JCP specs -
> but if this is not resolved I'll do my best to find out.
> 
> I'm also curious to who is representing apache ( if any ) in the
> JSP spec - I'm still strugling to understand how the TLD stuff
> happened and nobody noticed or complained in any way - the whole
> 'config in web.xml' model is now screwed, with any file ( including
> jars ) potentially storing config for web applications.
> 
> Costin
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 

-- 
_
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:   
For additional commands, e-mail: 

Tomcat 4.1.9: LifeCycleListener defined in does not get notified (BUG?)

[Roytman, Alex]

Hello

I noticed that in Tomcat 4.1.9 my LifeCycleListener defined on context level does not 
get notified. The same code worked fine in TC 4.0.4 and it also works if I move 
listener definition to server level.

Thank you very much

Alex Roytman


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 11748] - Location header for redirection does not contain the port number

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=11748

Location header for redirection does not contain the port number

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2002-08-15 21:58 ---
The bug is in the client program.  It is not sending the port in the Host 
header, so Tomcat is assuming that the connection is on the default port.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 11748] New: - Location header for redirection does not contain the port number

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=11748

Location header for redirection does not contain the port number

   Summary: Location header for redirection does not contain the
port number
   Product: Tomcat 4
   Version: 4.1.9
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Major
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I have written a Java HTTP Client. It works with Tomcat 4.0.1 but it doesn't 
work with Tomcat 4.1.9. It seems that the location header does not the 
application port number. 

My request (http://localhost:8080/nm/):
GET /nm/ HTTP/1.0
Host: localhost
Content-Length: 0
Connection: Close
User-Agent: None

The response:
Location: http://localhost/nm/index.jsp< Doesn't have port number
Content-Type: text/html
Date: Thu, 15 Aug 2002 21:44:30 GMT
Server: Apache Coyote/1.0
Connection: close

If I just take the Location from the header and do a redirection, the request 
will be invalid.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 11747] - Context level LifeCycleListener does not get invoked if context is defined in a my-context.xml file rather than in server.xml

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=11747

Context level LifeCycleListener does not get invoked if context is defined in a 
my-context.xml file rather than in server.xml

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2002-08-15 21:29 ---
Sorry, my mistake. It works as expected

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 11747] New: - Context level LifeCycleListener does not get invoked if context is defined in a my-context.xml file rather than in server.xml

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=11747

Context level LifeCycleListener does not get invoked if context is defined in a 
my-context.xml file rather than in server.xml

   Summary: Context level LifeCycleListener does not get invoked if
context is defined in a my-context.xml file rather than
in server.xml
   Product: Tomcat 4
   Version: 4.1.9
  Platform: All
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Context defined in my-context.xml starts fine everything seems to work except 
my LifeCycleListener defined in my-context.xml does not get invoked

If I move context definition to server.xml it works fine. LifeCycleListener 
gets called as expected

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [5.0] [PROPOSAL] Refactored mapper

[Patrick Luby]

[EMAIL PROTECTED] wrote:
> The current specification is not implementable for Apache ( or any other
> web server ) - and it breaks every pattern that was used in the web.
> 
> I don't know if we have any representative in the expert group or
> what's the procedure that apache follows in voting for JCP specs -
> but if this is not resolved I'll do my best to find out.

I have heard that Pier is in the Expert Group. But I could be wrong. I
think the Servlet 2.4 spec is going Public Final Draft this month (not
sure exactly when), but you can e-mail the expert group directly at:

[EMAIL PROTECTED]

Also, the latest draft of the spec is at:

http://www.jcp.org/jsr/detail/154.jsp

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:   
For additional commands, e-mail: 

[PATCH][5] build.properties.defaut, BUILDING.txt

[Jean-francois Arcand]

This patch update the required version of the Digester.

Thanks,

-- Jeanfrancois


Index: build.properties.default
===
RCS file: /home/cvspublic/jakarta-tomcat-5/build.properties.default,v
retrieving revision 1.27
diff -u -r1.27 build.properties.default
--- build.properties.default13 Aug 2002 16:52:19 -  1.27
+++ build.properties.default15 Aug 2002 20:39:44 -
@@ -72,7 +72,7 @@
 commons-daemon.loc=jakarta-commons-sandbox/daemon
 
 
-# - Commons Digester, version 1.3 or later -
+# - Commons Digester, version 20020815 or later -
 commons-digester.home=${base.path}/commons-digester-1.3
 commons-digester.lib=${commons-digester.home}
 commons-digester.jar=${commons-digester.lib}/commons-digester.jar
Index: BUILDING.txt
===
RCS file: /home/cvspublic/jakarta-tomcat-5/BUILDING.txt,v
retrieving revision 1.18
diff -u -r1.18 BUILDING.txt
--- BUILDING.txt14 Aug 2002 15:46:37 -  1.18
+++ BUILDING.txt15 Aug 2002 20:39:45 -
@@ -216,7 +216,7 @@
 
 (8) Download and Install the Commons Digester Binary Distribution
 
-* Download a binary distribution (version 1.3 or later) from:
+* Download a binary distribution (version 20020815 or later) from:
 
 http://jakarta.apache.org/builds/jakarta-commons/release/commons-digester
 



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: JMS for Tomcat

[Zhenxin wang]

 I do not think Tomcat supports JMS, Tomcat is only a servlet and JSP
container.

--Zhenxin Wang
DoCoMo Labs USA

- Original Message -
From: "Ming Xie" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, August 15, 2002 1:33 PM
Subject: JMS for Tomcat


> Hi, Does anyone know if Tomcat supports JMS ? Where is the document if
yes.
>
> Can I use j2ee server from Sun as message system when I use Tomcat ?
>
> Please advise.
>
> Ming
> CONFIDENTIALITY NOTICE This electronic mail transmission and any
> accompanying documents contain information belonging to the sender
> ("Information") that may be confidential and legally privileged.  If you
are
> not the intended recipient, any disclosure, copying,distribution or action
> taken in reliance on the Information is strictly prohibited.  If you have
> received the Information in error,please contact the sender by reply email
> and destroy all copies of the original email. Thank you.
>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 11745] New: - web.xml session-timeout value of 0 does not work as specified.

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=11745

web.xml session-timeout value of 0 does not work as specified.

   Summary: web.xml session-timeout value of 0 does not work as
specified.
   Product: Tomcat 4
   Version: 4.0.4 Final
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Minor
  Priority: Other
 Component: Servlet & JSP API
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Setting the session-timeout value to 0 in the web.xml file for a webapp, causes 
immediate (0 minutes) timeout rather than no timeout as stated in the servlet 
2.3 FCS specification.

"If the timeout is 0 or less, the container ensures the default behaviour of 
sessions is never to time out."

-1 (or, I suspect any negative integer) is a fine work-around.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

JMS for Tomcat

[Ming Xie]

Hi, Does anyone know if Tomcat supports JMS ? Where is the document if yes.

Can I use j2ee server from Sun as message system when I use Tomcat ?

Please advise. 

Ming
CONFIDENTIALITY NOTICE This electronic mail transmission and any
accompanying documents contain information belonging to the sender
("Information") that may be confidential and legally privileged.  If you are
not the intended recipient, any disclosure, copying,distribution or action
taken in reliance on the Information is strictly prohibited.  If you have
received the Information in error,please contact the sender by reply email
and destroy all copies of the original email. Thank you.

Re: [5][PATCH]Run Watchdog from the jakarta-tomcat-5 build.xml

[costinm]

On Thu, 15 Aug 2002, Patrick Luby wrote:

> Costin,
> 
> [EMAIL PROTECTED] wrote:
> > Patrick ( if you read this ) - what's the status with the 'guess home' ?
> > I can use IntrospectionUtils - it has the whole thing in it ( home/base
> > setting, find in classpath ). We already need IU for jk - it just needs
> > to be included in bootstrap.jar to do that.
> > 
> 
> I haven't ported this yet but I can do it very quickly. The question is 
> where should we put it? Originally, I was going to put it in the 
> Bootstrap.getCatalinaHome() method. However, since we are moving towards 
> using CatalinaService, do you think I should put it there?

Probably Bootrstrap is the best place - since it needs to construct the 
classpath to load CatalinaService ( so it needs it ).

If you just include IntrospectionUtil from j-t-c you get it all -
( it is used in jk already ). All you need ( besides build.xml changes )
is:

 home= IntrospectionUtils.guessInstall("catalina.home", "catalina.base", 
   "bootstrap.jar",
"org.apache.catalina.startup.CatalinaService"); 

That will set catalina.home/catalina.base:
-  if only one is set the other will take that value.
-  if none is set, it'll look in CLASSPATH for bootstrap.jar and go one
level up, or for org/apache... if classes/ is used - and set catalina.home
fromt that. 

You don't need to port it - it is useable directly. ( well, you can 
cut&paste the method if you want, it's independent of the rest )

Costin


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [5.0] [PROPOSAL] Validation/NamespaceAware

[costinm]

Big +1 !

We can have a small ant-based script that can validate a webapp -
find all the XMLs and TLDs and run schema and DTD validation on it.

Another nice thing we could do - if someone has the time - is 
adding 'Serializable' to Context and all other config objects and
saving a snapshot. Then reuse the dependency checking from jasper
and check if any of the files changed ( web.xml, jars, tlds ). 
On the first load or on change we could validate - and for the
rest just load the .ser object. 

But it is not easy - turning validation off by default until 
we have a way to avoid duplicated validation is a good solution.

Costin


On Thu, 15 Aug 2002, Jean-francois Arcand wrote:

> Hi,
> 
> based on the mailling list feedback, I would like to propose the 
> following solution for the XML Parser DTD/Schema validation/namespace 
> aware problems:
> 
> - Add the following attributes in server.xml under the HOST element:
> 
> xmlValidation="false"
> xmlNamespaceAware="false"
> 
> and set them equal to false by default. This way, peoples will be able 
> to turn it on only if they need it, using the AdminTool or directly in 
> the server.xml file.
> 
> It will still  let the door open for:
> 
> - "have a separate validation program that can be run on a webapp _before_ it is 
>deployed on tomcat" (Costin)
> - keeping validation available when required (Steve)
> - etc.
> 
> Thanks,
> 
> -- Jeanfrancois
> 
> 
> 
> 
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 
> 


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [5.0] [PROPOSAL] Refactored mapper

[costinm]

On Thu, 15 Aug 2002, 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 ...

The current specification is not implementable for Apache ( or any other 
web server ) - and it breaks every pattern that was used in the web. 

I don't know if we have any representative in the expert group or
what's the procedure that apache follows in voting for JCP specs - 
but if this is not resolved I'll do my best to find out. 

I'm also curious to who is representing apache ( if any ) in the 
JSP spec - I'm still strugling to understand how the TLD stuff
happened and nobody noticed or complained in any way - the whole
'config in web.xml' model is now screwed, with any file ( including
jars ) potentially storing config for web applications. 


Costin


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [5.0] [PROPOSAL] Validation/NamespaceAware

[Remy Maucherat]

Jean-francois Arcand wrote:
> Hi,
> 
> based on the mailling list feedback, I would like to propose the 
> following solution for the XML Parser DTD/Schema validation/namespace 
> aware problems:
> 
> - Add the following attributes in server.xml under the HOST element:
> 
> xmlValidation="false"
> xmlNamespaceAware="false"
> 
> and set them equal to false by default. This way, peoples will be able 
> to turn it on only if they need it, using the AdminTool or directly in 
> the server.xml file.

Awesome :)

We should also add those attributes to the default server.xml (in 
addition to adding checkboxes on the Host page in the admin) so that 
people know that they exist.

> It will still  let the door open for:
> 
> - "have a separate validation program that can be run on a webapp 
> _before_ it is deployed on tomcat" (Costin)
> - keeping validation available when required (Steve)
> - etc.
- Doing a TC 3.3 style trick along with background deployment

I think that one looks cool :)

Thanks a lot,
Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/valvesErrorDispatcherValve.java

[Remy Maucherat]

[EMAIL PROTECTED] wrote:
> patrickl2002/08/15 12:11:31
> 
>   Modified:catalina/src/share/org/apache/catalina/valves
> ErrorDispatcherValve.java
>   Log:
>   If a Servlet generates a RuntimeException, it is wrapped by a ServletException.  
>Since there is an entry for ServletException in the web.xml, the actual root cause 
>(in this case, an IllegalStateException) was never unwrapped, thus leading to 
>unexpected behavior.
>   
>   I made a simple modification to the logic so that if the throwable passed to the 
>ErrorDispatcherValve is a ServletException, it will attempt to get the root cause.  
>If the root cause is null, then proceed with the error page lookup with the 
>ServletException as the throwable object, otherwise, use the root cause for the error 
>page lookup.
>   Submitted by:   Ryan Lubke ([EMAIL PROTECTED])

I lacked some time, and couldn't commit it.
Can you also commit it to Tomcat 4.1.x (as this appears to be fixing 
things) ?

Thanks,
Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [5.0] [PROPOSAL] Refactored mapper

[Remy Maucherat]

Bob Herrmann wrote:
> On Thu, 2002-08-15 at 13:23, Remy Maucherat wrote:
> 
>>Hi,
>>
>>I have been hinting at rewriting the main Catalina mapper for Tomcat 5.
>>
>>The proposal is designed to improve performance, avoid generating 
>>uneeded garbage String objects, and optimize the welcome files processing.
> 
> 
> FYI, The 2.4 spec seems to allow servlets to handle "welcome file"
> processing too.  Not sure I understand this completely, but I am looking
> into it (with an eye towards implementing something to satisfy the 2.4
> Spec's servlets as providers of "welcome" files.  Perhaps welcome page
> would be better than 'welcome file.', but I digress)

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 ...

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [5.0] [PROPOSAL] Validation/NamespaceAware

[Patrick Luby]

Jean-François,

I would vote +1 as long as these two HOST attributes are optional
attributes. In other words, if they are missing from server.xml, both
default to "false". I think that is what you are proposing but I just
wanted to make sure.

Patrick

Jean-francois Arcand wrote:
> 
> Hi,
> 
> based on the mailling list feedback, I would like to propose the
> following solution for the XML Parser DTD/Schema validation/namespace
> aware problems:
> 
> - Add the following attributes in server.xml under the HOST element:
> 
> xmlValidation="false"
> xmlNamespaceAware="false"
> 
> and set them equal to false by default. This way, peoples will be able
> to turn it on only if they need it, using the AdminTool or directly in
> the server.xml file.
> 
> It will still  let the door open for:
> 
> - "have a separate validation program that can be run on a webapp _before_ it is 
>deployed on tomcat" (Costin)
> - keeping validation available when required (Steve)
> - etc.
> 
> Thanks,
> 
> -- Jeanfrancois
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 

-- 
_
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:   
For additional commands, e-mail: 

[5.0] [PROPOSAL] Validation/NamespaceAware

[Jean-francois Arcand]

Hi,

based on the mailling list feedback, I would like to propose the 
following solution for the XML Parser DTD/Schema validation/namespace 
aware problems:

- Add the following attributes in server.xml under the HOST element:

xmlValidation="false"
xmlNamespaceAware="false"

and set them equal to false by default. This way, peoples will be able 
to turn it on only if they need it, using the AdminTool or directly in 
the server.xml file.

It will still  let the door open for:

- "have a separate validation program that can be run on a webapp _before_ it is 
deployed on tomcat" (Costin)
- keeping validation available when required (Steve)
- etc.

Thanks,

-- Jeanfrancois






--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm RealmBase.java

[remm]

remm2002/08/15 10:47:04

  Modified:catalina/src/share/org/apache/catalina/realm RealmBase.java
  Log:
  - Remove double URI decoding.
  - This could improve performance as well as fix i18n issues.
  - This may have been a security issue.
  - Reported by Juergen Pill 
  
  Revision  ChangesPath
  1.4   +4 -5  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm/RealmBase.java
  
  Index: RealmBase.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm/RealmBase.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- RealmBase.java9 Aug 2002 01:12:39 -   1.3
  +++ RealmBase.java15 Aug 2002 17:47:04 -  1.4
  @@ -455,7 +455,6 @@
   String contextPath = hreq.getContextPath();
   if (contextPath.length() > 0)
   uri = uri.substring(contextPath.length());
  -uri = RequestUtil.URLDecode(uri); // Before checking constraints
   String method = hreq.getMethod();
   for (int i = 0; i < constraints.length; i++) {
   if (debug >= 2)
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/authenticator AuthenticatorBase.java

[remm]

remm2002/08/15 10:42:57

  Modified:catalina/src/share/org/apache/catalina/authenticator
AuthenticatorBase.java
  Log:
  - Remove double URI decoding.
  - This could improve performance as well as fix i18n issues.
  - This may have been a security issue.
  - Reported by Juergen Pill 
  
  Revision  ChangesPath
  1.33  +4 -5  
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/authenticator/AuthenticatorBase.java
  
  Index: AuthenticatorBase.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/authenticator/AuthenticatorBase.java,v
  retrieving revision 1.32
  retrieving revision 1.33
  diff -u -r1.32 -r1.33
  --- AuthenticatorBase.java9 Jun 2002 02:19:41 -   1.32
  +++ AuthenticatorBase.java15 Aug 2002 17:42:57 -  1.33
  @@ -766,7 +766,6 @@
   String contextPath = hreq.getContextPath();
   if (contextPath.length() > 0)
   uri = uri.substring(contextPath.length());
  -uri = RequestUtil.URLDecode(uri); // Before checking constraints
   String method = hreq.getMethod();
   for (int i = 0; i < constraints.length; i++) {
   if (debug >= 2)
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[5.0] [PROPOSAL] Refactored mapper

[Remy Maucherat]

Hi,

I have been hinting at rewriting the main Catalina mapper for Tomcat 5.

The proposal is designed to improve performance, avoid generating 
uneeded garbage String objects, and optimize the welcome files processing.

The following changes are proposed:
- Expose the decoded URI MessageBytes in the main Request interface of 
Catalina, so that the mapper doesn't have to pay the b2c cost
- Implement the new mappers as a separate set of classes in 
j-t-c/util/../mapper

The new mappers will use exclusively bytes to match contexts/servlets 
and will rewrite the original URIs to handle welcome files without 
sending a redirect back to the client (in most cases).

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [5][PATCH]Run Watchdog from the jakarta-tomcat-5 build.xml

[Patrick Luby]

Costin,

[EMAIL PROTECTED] wrote:
> Patrick ( if you read this ) - what's the status with the 'guess home' ?
> I can use IntrospectionUtils - it has the whole thing in it ( home/base
> setting, find in classpath ). We already need IU for jk - it just needs
> to be included in bootstrap.jar to do that.
> 

I haven't ported this yet but I can do it very quickly. The question is 
where should we put it? Originally, I was going to put it in the 
Bootstrap.getCatalinaHome() method. However, since we are moving towards 
using CatalinaService, do you think I should put it there?

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:   
For additional commands, e-mail: 

Re: [4.1.9] Fix for major bugs

[Remy Maucherat]

David Oxley wrote:
> Has anyone looked at http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7082.
> Can anyone look at fixing this for 4.1.x?

It may not be that easy to fix, but at least I undestand now why so many 
people reported problems with RMI. The bug has an easy workaround, and I 
don't want to risk braking things, so it may not be fixed for the first 
4.1.x stable release.

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 11662] - GlobalResources unavailable in DefaultContext

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=11662

GlobalResources unavailable in DefaultContext

[EMAIL PROTECTED] changed:

   What|Removed |Added

   Severity|Normal  |Major



--- Additional Comments From [EMAIL PROTECTED]  2002-08-15 16:06 ---
Can someone please look into this? All the advantages of having global 
resources cannot be fully utilised when such a bug exists!

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [4.1.9] Fix for major bugs

[David Oxley]

Has anyone looked at http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7082.
Can anyone look at fixing this for 4.1.x?

Cheers.
Dave.


> -Original Message-
> From: Remy Maucherat [mailto:[EMAIL PROTECTED]]
> Sent: 09 August 2002 11:10
> To: Tomcat Developers List
> Subject: [4.1.9] Fix for major bugs
> 
> A few major bugs were fixed in CVS (two tricky bugs in Coyote HTTP/1.1,
> one in Jasper, and possibly one in the Catalina CL - bug 11307). I plan
> to release a 4.1.9 milestone when 11307 is confirmed to be fixed.
> 
> We may then consider 4.1.9 as a candidate for a stable release, as there
> are no real showstopper problems left I can think of (and huge
> improvements over 4.0.x).
> 
> One of the issues left is that DBCP is not stable yet. Could this be
> addressed anytime soon ?
> 
> Remy
> 
> 
> --
> To unsubscribe, e-mail:    [EMAIL PROTECTED]>
> For additional commands, e-mail:  [EMAIL PROTECTED]>

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 11730] New: - build fails - can't find jni_md.h

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=11730

build fails - can't find jni_md.h

   Summary: build fails - can't find jni_md.h
   Product: Tomcat 4
   Version: 4.0.4 Final
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Connector:JK/AJP (deprecated)
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


When running
ant native
I see this message:

   [so] In file included from
/home/murrayc/downloads/jakarta-tomcat-connectors-4.0.4-src/jk/native/jni/jk_jnicb.h:2,
   [so]  from
/home/murrayc/downloads/jakarta-tomcat-connectors-4.0.4-src/jk/native/jni/jk_jnicb.c:64:
   [so] /usr/java/j2sdk1.4.0_01/include/jni.h:27:20: jni_md.h: No such file
or directory

BUILD FAILED
file:/home/murrayc/downloads/jakarta-tomcat-connectors-4.0.4-src/jk/native/build.xml:63:
Compile failed
/home/murrayc/downloads/jakarta-tomcat-connectors-4.0.4-src/jk/native/jni/jk_jnicb.c

Total time: 4 seconds
[root@dev-linux jk]# locate jni_md.h
/usr/include/mozilla/java/jni_md.h
/usr/java/j2sdk1.4.0_01/include/linux/jni_md.h
[root@dev-linux jk]# 

   [so] In file included from
/home/murrayc/downloads/jakarta-tomcat-connectors-4.0.4-src/jk/native/jni/jk_jnicb.h:2,
   [so]  from
/home/murrayc/downloads/jakarta-tomcat-connectors-4.0.4-src/jk/native/jni/jk_jnicb.c:64:
   [so] /usr/java/j2sdk1.4.0_01/include/jni.h:27:20: jni_md.h: No such file
or directory

BUILD FAILED
file:/home/murrayc/downloads/jakarta-tomcat-connectors-4.0.4-src/jk/native/build.xml:63:
Compile failed
/home/murrayc/downloads/jakarta-tomcat-connectors-4.0.4-src/jk/native/jni/jk_jnicb.c

Total time: 4 seconds


[root@dev-linux jk]# locate jni_md.h
/usr/include/mozilla/java/jni_md.h
/usr/java/j2sdk1.4.0_01/include/linux/jni_md.h
[root@dev-linux jk]#

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

JspC / jspc.bat

[John Trollinger]

In trying to use JspC I have noticed that it does not create the .java
files the same way Jasper does when going to the page in a browser.  I
am trying to change this so that they both work the same way (and use as
much of the same code as possible for obvious reasons), is anyone else
working on this or would anyone like to see it as a patch to Jasper 2
when I am done.

If anyone knows why its behavior is like this and that it should not
change please let me know as well.

Thanks, 

John Trollinger


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 11075] - [PATCH] AccessLogValue Request Header ${xxx}i support

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=11075

[PATCH] AccessLogValue Request Header ${xxx}i support





--- Additional Comments From [EMAIL PROTECTED]  2002-08-15 14:28 ---
I was unaware of your patch when I developed the patch I submitted.  When I was 
searching for my own patch in order to see if any progress had taken place, I noticed 
your patch and hence marked our two submissions as duplicates.

I have no concern as to who's patch is used.  I haven't looked at your patch, but I 
presume that our patches are likely to be similar.  I was, however, concerned to 
promote this issue, as it is very awkward having to rebuild and re-patch production 
versions of Tomcat every time a new bug fix release comes out.  I imagine you may feel 
the same way.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 11724] New: - "ant install" fails - no such target

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=11724

"ant install" fails - no such target

   Summary: "ant install" fails - no such target
   Product: Tomcat 4
   Version: 4.0.4 Final
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Connector:JK/AJP (deprecated)
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


README.txt says to do
ant install
but that fails, like so:

BUILD FAILED
Target `install' does not exist in this project.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-catalina/catalina build.xml

[bobh]

bobh2002/08/15 06:56:31

  Modified:catalina build.xml
  Log:
  Change conditional building of Tyrex component to follow this rule,
  
  (full.dist==true) or ( jta.present == true and tyrex.present)
  
  Revision  ChangesPath
  1.17  +7 -7  jakarta-tomcat-catalina/catalina/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/build.xml,v
  retrieving revision 1.16
  retrieving revision 1.17
  diff -u -r1.16 -r1.17
  --- build.xml 14 Aug 2002 21:39:42 -  1.16
  +++ build.xml 15 Aug 2002 13:56:31 -  1.17
  @@ -348,13 +348,13 @@
   
   
   
  -  
  -
  -
  -   
  -   
  -
  -  
  +  
  +
  +
  +  
  +  
  +
  +  
   
   
   
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 11722] New: - There is no "build.properties.sample" file.

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=11722

There is no "build.properties.sample" file.

   Summary: There is no "build.properties.sample" file.
   Product: Tomcat 4
   Version: 4.0.4 Final
  Platform: All
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Connector:Webapp
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


The README.txt file says to rename "build.properties.sample" to
"build.properties", but there is no "build.properties" file.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 11075] - [PATCH] AccessLogValue Request Header ${xxx}i support

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=11075

[PATCH] AccessLogValue Request Header ${xxx}i support





--- Additional Comments From [EMAIL PROTECTED]  2002-08-15 13:16 ---
I don't understand why you didn't want to use the patch I made. Why make an 
effort to contribute if it will be ignored?

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[ANNOUNCEMENT] Tomcat 4.1.9 Beta

[Remy Maucherat]

Tomcat 4.1.9 Beta has been released. It includes bugfixes over the 
previous Tomcat 4.1.8 Beta, including a fix for a rare deadlock 
condition in the Catalina classloader, and Jasper 2 compliance fixes 
(please refer to the release notes for the complete list).

Release notes:
http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.1.9-beta/RELEASE-NOTES

Downloads (source and binaries):
http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.1.9-beta/

Important note: When upgrading from another Tomcat 4.x release, the 
Tomcat work directory must be cleared.

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Absolute fields required for JDBC & JNDI Realm pages in adminwebapp

[John Holman]

Amy

Yes - much too strict for JNDIRealm! The only configuration attributes 
that should always be specified for this realm are className and 
connectionURL. In addition either userPattern or userSearch must be 
specified (but not both). Other attributes either have default values, 
or not specifying them is itself significant (e.g. if userPassword is 
not specified the realm attempts to bind as the user rather than 
retrieve the user's password). (Note that the realm docs on the website 
are out of date, but the CVS and 4.1.8+  releases have new documentation 
which covers all of this).

In this connection, there is a problem with the admin application, which 
when it writes out a new version of the server.xml file converts all 
attributes that are unspecified by the user (e.g. in the original 
server.xml file) to attributes that are specified and have the empty 
string as their value This breaks JNDIRealm at the moment, and perhaps 
some other components as well (e.g. other realms).

However  I suspect this might be awkward to fix because of the way web 
forms work. If you can confirm that the admin app will continue to 
behave in this way (replacing null values with "" for all configuration 
attributes) then I can send you a patch for JNDIRealm to treat these 
values as equivalent. Configuration code in other components might also 
need to change - e.g. RealmBase decides whether a digest is being used 
by testing the value of the digest attribute against null, and throws an 
exception if it gets the empty string, since this is not null but not 
the name of a known digest algorithm either.

John


Amy Roh wrote:

> JDBC and JNDI Realms have many attributes.  What's the minimum list of 
> attributes to enable these two Realms?  I'll need to know the minimum 
> required list of attributes to validate the realm pages in admin 
> webapp.  Currently, it's validating all the fields as required which I 
> think is too strict.
>
> Thanks,
> Amy
>
>
> -- 
> To unsubscribe, e-mail:   
> 
> For additional commands, e-mail: 
> 
>



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: cvs commit: jakarta-tomcat-catalina/catalina build.xml

[Remy Maucherat]

Bob Herrmann wrote:
> On Thu, 2002-08-15 at 00:05, Steve Downey wrote:
> 
>>(jta.present == true) and (full.dist=true or tyrex.present)
> 
> 
> Yea, your right.  I will change that to,
> 
> (full.dist==true) or ( jta.present == true and tyrex.present)
> 
> Does that sound ok?

Yes. Actually, there are a few conditions which do similar things in 
build.xml (compile.dbcp for example).

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: cvs commit: jakarta-tomcat-catalina/catalina build.xml

[Bob Herrmann]

On Thu, 2002-08-15 at 00:05, Steve Downey wrote:
> (jta.present == true) and (full.dist=true or tyrex.present)

Yea, your right.  I will change that to,

(full.dist==true) or ( jta.present == true and tyrex.present)

Does that sound ok?

Cheers,
-bob

> 
> If I'm reading this correctly, this won't build the Tyrex dependant components 
> if jta is not present, EVEN IF full.dist is requested. That means you can set 
> full.dist on and NOT get a full dist.
> 
> If full.dist is set true, then the build should fail if some component is 
> missing. At least it's that way for all other components.
> 
> On Wednesday 14 August 2002 05:39 pm, [EMAIL PROTECTED] wrote:
> > bobh2002/08/14 14:39:42
> >
> >   Modified:catalina build.xml
> >   Log:
> >   make Tyrex only compile if JTA is present (this was breaking my build.)
> >
> >   Revision  ChangesPath
> >   1.16  +7 -4  jakarta-tomcat-catalina/catalina/build.xml
> >
> >   Index: build.xml
> >   ===
> >   RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/build.xml,v
> >   retrieving revision 1.15
> >   retrieving revision 1.16
> >   diff -u -r1.15 -r1.16
> >   --- build.xml 13 Aug 2002 16:26:11 -  1.15
> >   +++ build.xml 14 Aug 2002 21:39:42 -  1.16
> >   @@ -348,10 +348,13 @@
> >
> >
> >
> >   -  
> >   -
> >   -
> >   -  
> >   +  
> >   +
> >   +
> >   +   
> >   +   
> >   +
> >   +  
> >
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
-- 
Cheers,
-bob


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_uriMap.c

[mturk]

mturk   2002/08/15 04:24:54

  Modified:jk/native2/common jk_uriMap.c
  Log:
  uriMap is now the wrapper for positive/negative calls to the 'real'
  map function.
  
  Revision  ChangesPath
  1.37  +18 -4 jakarta-tomcat-connectors/jk/native2/common/jk_uriMap.c
  
  Index: jk_uriMap.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_uriMap.c,v
  retrieving revision 1.36
  retrieving revision 1.37
  diff -u -r1.36 -r1.37
  --- jk_uriMap.c   15 Aug 2002 09:25:18 -  1.36
  +++ jk_uriMap.c   15 Aug 2002 11:24:54 -  1.37
  @@ -79,7 +79,7 @@
   
   static jk_uriEnv_t *jk2_uriMap_mapUri(jk_env_t *env, jk_uriMap_t *uriMap,
 const char *vhost,
  -  const char *uri, int reverse);
  +  const char *uri);
   
   static int jk2_uriMap_checkUri(jk_env_t *env, jk_uriMap_t *uriMap, 
  const char *uri);
  @@ -551,9 +551,9 @@
   
   #define SAFE_URI_SIZE 8192
   
  -static jk_uriEnv_t *jk2_uriMap_mapUri(jk_env_t *env, jk_uriMap_t *uriMap,
  -  const char *vhost,
  -  const char *uri, int reverse)
  +static jk_uriEnv_t *jk2_uriMap_map(jk_env_t *env, jk_uriMap_t *uriMap,
  +   const char *vhost,
  +   const char *uri, int reverse)
   {
   int best_match = -1;
   int longest_match = 0;
  @@ -702,6 +702,20 @@
 "uriMap.mapUri() no match found\n"); 
   
   return NULL;
  +}
  +
  +static jk_uriEnv_t *jk2_uriMap_mapUri(jk_env_t *env, jk_uriMap_t *uriMap,
  +  const char *vhost, const char *uri)
  +{
  +jk_uriEnv_t *match;
  +
  +match = jk2_uriMap_map(env, uriMap, vhost, uri, 0);
  +if (match) {
  +jk_uriEnv_t *rmatch = jk2_uriMap_map(env, uriMap, vhost, uri, 1);
  +if (rmatch)
  +return NULL;
  +}
  +return match;
   }
   
   int JK_METHOD jk2_uriMap_factory(jk_env_t *env, jk_pool_t *pool, jk_bean_t *result,
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-connectors/jk/native2/server/isapi jk_isapi_plugin.c

[mturk]

mturk   2002/08/15 04:23:30

  Modified:jk/native2/server/isapi jk_isapi_plugin.c
  Log:
  Remove the reverse flag from uriMap call.
  All the positive/negative mappings is now done inside the uriMap
  function itself.
  
  Revision  ChangesPath
  1.42  +2 -2  
jakarta-tomcat-connectors/jk/native2/server/isapi/jk_isapi_plugin.c
  
  Index: jk_isapi_plugin.c
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/native2/server/isapi/jk_isapi_plugin.c,v
  retrieving revision 1.41
  retrieving revision 1.42
  diff -u -r1.41 -r1.42
  --- jk_isapi_plugin.c 15 Aug 2002 09:28:42 -  1.41
  +++ jk_isapi_plugin.c 15 Aug 2002 11:23:30 -  1.42
  @@ -334,14 +334,14 @@
   env->l->jkLog(env, env->l,  JK_LOG_DEBUG, 
  "In HttpFilterProc Virtual Host redirection of %s\n", 
  Host);
  -uriEnv = workerEnv->uriMap->mapUri(env, 
workerEnv->uriMap,Host,uri, 0 );
  +uriEnv = workerEnv->uriMap->mapUri(env, 
workerEnv->uriMap,Host,uri );
   }
   
   if (uriEnv==NULL) {
   env->l->jkLog(env, env->l,  JK_LOG_DEBUG, 
  "In HttpFilterProc test Default redirection of %s\n", 
  uri);
  -uriEnv = workerEnv->uriMap->mapUri(env, 
workerEnv->uriMap,NULL,uri, 0 );
  +uriEnv = workerEnv->uriMap->mapUri(env, 
workerEnv->uriMap,NULL,uri );
   }
   
   if( uriEnv!=NULL ) {
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2 mod_jk2.c

[mturk]

mturk   2002/08/15 04:23:04

  Modified:jk/native2/server/apache2 mod_jk2.c
  Log:
  Remove the reverse flag from uriMap call.
  All the positive/negative mappings is now done inside the uriMap
  function itself.
  
  Revision  ChangesPath
  1.49  +1 -8  jakarta-tomcat-connectors/jk/native2/server/apache2/mod_jk2.c
  
  Index: mod_jk2.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/server/apache2/mod_jk2.c,v
  retrieving revision 1.48
  retrieving revision 1.49
  diff -u -r1.48 -r1.49
  --- mod_jk2.c 15 Aug 2002 09:27:18 -  1.48
  +++ mod_jk2.c 15 Aug 2002 11:23:04 -  1.49
  @@ -677,18 +677,11 @@
  If positive, we'll fill a ws_service_t and do the rewrite and
  the real mapping. 
   */
  -uriEnv = workerEnv->uriMap->mapUri(env, workerEnv->uriMap,NULL,r->uri, 0 );
  +uriEnv = workerEnv->uriMap->mapUri(env, workerEnv->uriMap,NULL,r->uri );
   
   if( uriEnv== NULL || uriEnv->workerName == NULL) {
   workerEnv->globalEnv->releaseEnv( workerEnv->globalEnv, env );
   return DECLINED;
  -}
  -else {
  -jk_uriEnv_t *rriEnv = workerEnv->uriMap->mapUri(env, 
workerEnv->uriMap,NULL,r->uri, 1 );
  -if (rriEnv != NULL && rriEnv->workerName != NULL) {
  -workerEnv->globalEnv->releaseEnv(workerEnv->globalEnv, env );
  -return DECLINED;
  -}
   }
   ap_set_module_config( r->request_config, &jk2_module, uriEnv );
   r->handler=JK_HANDLER;
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache13 mod_jk2.c

[mturk]

mturk   2002/08/15 04:22:41

  Modified:jk/native2/server/apache13 mod_jk2.c
  Log:
  Remove the reverse flag from uriMap call.
  All the positive/negative mappings is now done inside the uriMap
  function itself.
  
  Revision  ChangesPath
  1.18  +1 -8  jakarta-tomcat-connectors/jk/native2/server/apache13/mod_jk2.c
  
  Index: mod_jk2.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/server/apache13/mod_jk2.c,v
  retrieving revision 1.17
  retrieving revision 1.18
  diff -u -r1.17 -r1.18
  --- mod_jk2.c 15 Aug 2002 09:27:41 -  1.17
  +++ mod_jk2.c 15 Aug 2002 11:22:41 -  1.18
  @@ -438,18 +438,11 @@
   /* get_env() */
   env = workerEnv->globalEnv->getEnv( workerEnv->globalEnv );
   
  -uriEnv = workerEnv->uriMap->mapUri(env, workerEnv->uriMap,NULL,r->uri, 0 );
  +uriEnv = workerEnv->uriMap->mapUri(env, workerEnv->uriMap,NULL,r->uri, );
   
   if(uriEnv==NULL || uriEnv->workerName==NULL) {
   workerEnv->globalEnv->releaseEnv( workerEnv->globalEnv, env );
   return DECLINED;
  -}
  -else {
  -jk_uriEnv_t *rriEnv = workerEnv->uriMap->mapUri(env, 
workerEnv->uriMap,NULL,r->uri, 1 );
  -if (rriEnv != NULL && rriEnv->workerName != NULL) {
  -workerEnv->globalEnv->releaseEnv(workerEnv->globalEnv, env );
  -return DECLINED;
  -}
   }
   
   ap_set_module_config( r->request_config, &jk2_module, uriEnv );
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-connectors/jk/native2/include jk_uriMap.h

[mturk]

mturk   2002/08/15 04:21:47

  Modified:jk/native2/include jk_uriMap.h
  Log:
  Remove the reverse flag from uriMap call.
  
  Revision  ChangesPath
  1.15  +2 -1  jakarta-tomcat-connectors/jk/native2/include/jk_uriMap.h
  
  Index: jk_uriMap.h
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/include/jk_uriMap.h,v
  retrieving revision 1.14
  retrieving revision 1.15
  diff -u -r1.14 -r1.15
  --- jk_uriMap.h   15 Aug 2002 09:22:16 -  1.14
  +++ jk_uriMap.h   15 Aug 2002 11:21:47 -  1.15
  @@ -139,9 +139,10 @@
   to do what we need ). Even when we'll know, uriMap will be needed
   for other servers. 
   */
  +
   struct jk_uriEnv *(*mapUri)(struct jk_env *env, jk_uriMap_t *_this,
   const char *vhost,
  -const char *uri, int reverse );
  +const char *uri);
   
   /*  @deprecated  */
   /* used by the mapper, temp storage ( ??? )*/
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [COMMENT] mod_jk2 reverse mappings

[Bojan Smojver]

Neat :-)

Bojan

On Thu, 2002-08-15 at 19:43, Mladen Turk wrote:
> Hi,
> 
> Some comments regarding reverse uri mappings.
> 
> This is the simplest way of accomplishing the reverse mapping (I'm not
> sure if this is correct terminology).
> 
> There is additional option for the uri map configuration 'reverse' :
> 
> [uri:/examples/*.gif]
> info=Extension mapping
> reverse=1
> 
> All the 'normal' mappings are skipped for such a directive, so first we
> will map the /examples context. The second call to the mapUri will check
> only the 'reverse' flagged uri mappings. If both are mapped then the
> DECLINED is returned, meaning that we mapped the context but don't wish
> to map the *.gif files in the context.
> 
> The drawback is that we are calling the mapUri twice, first for positive
> and then for negative mappings.
> 
> Of course this could be accomplished in the single call using regular
> expressions, with all the drawbacks using pcre.
> 
> MT.
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Custom DataSource Factory

[teletype]

Hi,

I'd like replace javax.sql.DataSource factory with an 
implementation that fit my needs. Actually it is based on 
BasicDataSourceFactory from DBCP with some improvements. It 
allows overriding of server.xml resource parameters using 
the Hashtable passed to the InitialContext. So I've copied 
all the jars required to commons/lib edited the server.xml 
and web.xml of my webapp and I've started tomcat with 
-Djavax.sql.DataSource.Factory=my.PoolingDataSourceFactory 
option.

When the program tries to access the resource tomcat throws 
exception:

javax.naming.NamingException
at org.apache.naming.NamingContext.lookup
(NamingContext.java:844)
at org.apache.naming.NamingContext.lookup
(NamingContext.java:181)
at org.apache.naming.NamingContext.lookup
(NamingContext.java:822)
at org.apache.naming.NamingContext.lookup
(NamingContext.java:181)
at org.apache.naming.NamingContext.lookup
(NamingContext.java:822)
at org.apache.naming.NamingContext.lookup
(NamingContext.java:181)
at org.apache.naming.NamingContext.lookup
(NamingContext.java:822)
at org.apache.naming.NamingContext.lookup
(NamingContext.java:194)
at org.apache.naming.SelectorContext.lookup
(SelectorContext.java:183)
at javax.naming.InitialContext.lookup
(InitialContext.java:347)

Can you help me out, please?

Thanks.
Have a nice day.




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 11075] - [PATCH] AccessLogValue Request Header ${xxx}i support

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=11075

[PATCH] AccessLogValue Request Header ${xxx}i support

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]



--- Additional Comments From [EMAIL PROTECTED]  2002-08-15 10:09 ---
*** Bug 7554 has been marked as a duplicate of this bug. ***

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 7554] - AccessLogValve doesn't implement %{Referer}i and %{User-Agent}i

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=7554

AccessLogValve doesn't implement %{Referer}i and %{User-Agent}i

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||DUPLICATE



--- Additional Comments From [EMAIL PROTECTED]  2002-08-15 10:09 ---


*** This bug has been marked as a duplicate of 11075 ***

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[COMMENT] mod_jk2 reverse mappings

[Mladen Turk]

Hi,

Some comments regarding reverse uri mappings.

This is the simplest way of accomplishing the reverse mapping (I'm not
sure if this is correct terminology).

There is additional option for the uri map configuration 'reverse' :

[uri:/examples/*.gif]
info=Extension mapping
reverse=1

All the 'normal' mappings are skipped for such a directive, so first we
will map the /examples context. The second call to the mapUri will check
only the 'reverse' flagged uri mappings. If both are mapped then the
DECLINED is returned, meaning that we mapped the context but don't wish
to map the *.gif files in the context.

The drawback is that we are calling the mapUri twice, first for positive
and then for negative mappings.

Of course this could be accomplished in the single call using regular
expressions, with all the drawbacks using pcre.

MT.


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-connectors/jk/native2/server/isapi jk_isapi_plugin.c

[mturk]

mturk   2002/08/15 02:28:42

  Modified:jk/native2/server/isapi jk_isapi_plugin.c
  Log:
  Fix the call to the mapUri. The IIS doesn't support the reverse mappings for now.
  
  Revision  ChangesPath
  1.41  +3 -3  
jakarta-tomcat-connectors/jk/native2/server/isapi/jk_isapi_plugin.c
  
  Index: jk_isapi_plugin.c
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/native2/server/isapi/jk_isapi_plugin.c,v
  retrieving revision 1.40
  retrieving revision 1.41
  diff -u -r1.40 -r1.41
  --- jk_isapi_plugin.c 16 Jul 2002 17:29:20 -  1.40
  +++ jk_isapi_plugin.c 15 Aug 2002 09:28:42 -  1.41
  @@ -334,14 +334,14 @@
   env->l->jkLog(env, env->l,  JK_LOG_DEBUG, 
  "In HttpFilterProc Virtual Host redirection of %s\n", 
  Host);
  -uriEnv = workerEnv->uriMap->mapUri(env, 
workerEnv->uriMap,Host,uri );
  +uriEnv = workerEnv->uriMap->mapUri(env, 
workerEnv->uriMap,Host,uri, 0 );
   }
   
   if (uriEnv==NULL) {
   env->l->jkLog(env, env->l,  JK_LOG_DEBUG, 
  "In HttpFilterProc test Default redirection of %s\n", 
  uri);
  -uriEnv = workerEnv->uriMap->mapUri(env, 
workerEnv->uriMap,NULL,uri );
  +uriEnv = workerEnv->uriMap->mapUri(env, 
workerEnv->uriMap,NULL,uri, 0 );
   }
   
   if( uriEnv!=NULL ) {
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache13 mod_jk2.c

[mturk]

mturk   2002/08/15 02:27:41

  Modified:jk/native2/server/apache13 mod_jk2.c
  Log:
  After succesfull call to the mapUri call the mapUri again with the reverse flag set.
  This will decline the 'reverse' mappings.
  
  Revision  ChangesPath
  1.17  +9 -2  jakarta-tomcat-connectors/jk/native2/server/apache13/mod_jk2.c
  
  Index: mod_jk2.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/server/apache13/mod_jk2.c,v
  retrieving revision 1.16
  retrieving revision 1.17
  diff -u -r1.16 -r1.17
  --- mod_jk2.c 10 Jun 2002 21:55:08 -  1.16
  +++ mod_jk2.c 15 Aug 2002 09:27:41 -  1.17
  @@ -438,11 +438,18 @@
   /* get_env() */
   env = workerEnv->globalEnv->getEnv( workerEnv->globalEnv );
   
  -uriEnv = workerEnv->uriMap->mapUri(env, workerEnv->uriMap,NULL,r->uri );
  +uriEnv = workerEnv->uriMap->mapUri(env, workerEnv->uriMap,NULL,r->uri, 0 );
   
   if(uriEnv==NULL || uriEnv->workerName==NULL) {
   workerEnv->globalEnv->releaseEnv( workerEnv->globalEnv, env );
   return DECLINED;
  +}
  +else {
  +jk_uriEnv_t *rriEnv = workerEnv->uriMap->mapUri(env, 
workerEnv->uriMap,NULL,r->uri, 1 );
  +if (rriEnv != NULL && rriEnv->workerName != NULL) {
  +workerEnv->globalEnv->releaseEnv(workerEnv->globalEnv, env );
  +return DECLINED;
  +}
   }
   
   ap_set_module_config( r->request_config, &jk2_module, uriEnv );
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2 mod_jk2.c

[mturk]

mturk   2002/08/15 02:27:18

  Modified:jk/native2/server/apache2 mod_jk2.c
  Log:
  After succesfull call to the mapUri call the mapUri again with the reverse flag set.
  This will decline the 'reverse' mappings.
  
  Revision  ChangesPath
  1.48  +9 -3  jakarta-tomcat-connectors/jk/native2/server/apache2/mod_jk2.c
  
  Index: mod_jk2.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/server/apache2/mod_jk2.c,v
  retrieving revision 1.47
  retrieving revision 1.48
  diff -u -r1.47 -r1.48
  --- mod_jk2.c 9 Aug 2002 17:45:49 -   1.47
  +++ mod_jk2.c 15 Aug 2002 09:27:18 -  1.48
  @@ -677,13 +677,19 @@
  If positive, we'll fill a ws_service_t and do the rewrite and
  the real mapping. 
   */
  -uriEnv = workerEnv->uriMap->mapUri(env, workerEnv->uriMap,NULL,r->uri );
  +uriEnv = workerEnv->uriMap->mapUri(env, workerEnv->uriMap,NULL,r->uri, 0 );
   
   if( uriEnv== NULL || uriEnv->workerName == NULL) {
   workerEnv->globalEnv->releaseEnv( workerEnv->globalEnv, env );
   return DECLINED;
   }
  -
  +else {
  +jk_uriEnv_t *rriEnv = workerEnv->uriMap->mapUri(env, 
workerEnv->uriMap,NULL,r->uri, 1 );
  +if (rriEnv != NULL && rriEnv->workerName != NULL) {
  +workerEnv->globalEnv->releaseEnv(workerEnv->globalEnv, env );
  +return DECLINED;
  +}
  +}
   ap_set_module_config( r->request_config, &jk2_module, uriEnv );
   r->handler=JK_HANDLER;
   
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_uriMap.c

[mturk]

mturk   2002/08/15 02:25:18

  Modified:jk/native2/common jk_uriMap.c
  Log:
  Check each mapping with the reverse flag and desired mode.
  Mode can be either normal or reverse.
  
  Revision  ChangesPath
  1.36  +32 -14jakarta-tomcat-connectors/jk/native2/common/jk_uriMap.c
  
  Index: jk_uriMap.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_uriMap.c,v
  retrieving revision 1.35
  retrieving revision 1.36
  diff -u -r1.35 -r1.36
  --- jk_uriMap.c   8 Jul 2002 13:35:53 -   1.35
  +++ jk_uriMap.c   15 Aug 2002 09:25:18 -  1.36
  @@ -79,7 +79,7 @@
   
   static jk_uriEnv_t *jk2_uriMap_mapUri(jk_env_t *env, jk_uriMap_t *uriMap,
 const char *vhost,
  -  const char *uri);
  +  const char *uri, int reverse);
   
   static int jk2_uriMap_checkUri(jk_env_t *env, jk_uriMap_t *uriMap, 
  const char *uri);
  @@ -159,7 +159,8 @@
   }
   
   static jk_uriEnv_t *jk2_uriMap_prefixMap(jk_env_t *env, jk_uriMap_t *uriMap,
  - jk_map_t *mapTable, const char *uri, int 
uriLen)
  + jk_map_t *mapTable, const char *uri, 
  + int uriLen, int reverse)
   {
   int best_match=0;
   jk_uriEnv_t *match=NULL;
  @@ -173,7 +174,12 @@
   if( strncmp( uri, uwr->prefix, uwr->prefix_len ) == 0 ) {
   if( uwr->prefix_len > best_match ) {
   best_match=uwr->prefix_len;
  -match=uwr;
  +if (reverse > 0) {
  +if (uwr->reverse)
  +match=uwr;
  +}
  +else if (!uwr->reverse)
  +match=uwr;
   }
   }
   }
  @@ -181,7 +187,8 @@
   }
   
   static jk_uriEnv_t *jk2_uriMap_exactMap(jk_env_t *env, jk_uriMap_t *uriMap,
  -jk_map_t *mapTable, const char *uri, int 
uriLen)
  +jk_map_t *mapTable, const char *uri, 
  +int uriLen, int reverse)
   {
   int i;
   int sz=mapTable->size( env, mapTable);
  @@ -190,14 +197,20 @@
   
   if( uriLen != uwr->prefix_len ) continue;
   if( strncmp( uri, uwr->prefix, uriLen ) == 0 ) {
  -return uwr;
  +if (reverse > 0) {
  +if (uwr->reverse)
  +return uwr;
  +}
  +else if (!uwr->reverse)
  +return uwr;
   }
   }
   return NULL;
   }
   
   static jk_uriEnv_t *jk2_uriMap_suffixMap(jk_env_t *env, jk_uriMap_t *uriMap,
  - jk_map_t *mapTable, const char *suffix, 
int suffixLen)
  + jk_map_t *mapTable, const char *suffix, 
  + int suffixLen, int reverse)
   {
   int i;
   int sz=mapTable->size( env, mapTable);
  @@ -215,7 +228,12 @@
 "uriMap.mapUri() suffix match %s\n",
 uwr->suffix );
   }
  -return uwr;
  +if (reverse > 0) {
  +if (uwr->reverse)
  +return uwr;
  +}
  +else if (!uwr->reverse)
  +return uwr;
   /* indentation trick */
   #ifdef WIN32
   }
  @@ -297,7 +315,7 @@
   continue;
   }
   
  -ctxEnv=jk2_uriMap_prefixMap( env, uriMap, hostEnv->webapps, context, 
strlen( context) );
  +ctxEnv=jk2_uriMap_prefixMap( env, uriMap, hostEnv->webapps, context, 
strlen( context), -1);
   /* if not alredy created, create it */
   if( ctxEnv == NULL ) {
   env->l->jkLog( env, env->l, JK_LOG_INFO,
  @@ -465,7 +483,7 @@
   
   if( uri==NULL ) continue;
   
  -ctxEnv=jk2_uriMap_prefixMap( env, uriMap, hostEnv->webapps, uri, strlen( 
uri ) );
  +ctxEnv=jk2_uriMap_prefixMap( env, uriMap, hostEnv->webapps, uri, strlen( 
uri ), -1 );
   
   if( ctxEnv==NULL ) {
   env->l->jkLog(env, env->l, JK_LOG_INFO, "uriMap.init() no context for 
%s\n", uri); 
  @@ -535,7 +553,7 @@
   
   static jk_uriEnv_t *jk2_uriMap_mapUri(jk_env_t *env, jk_uriMap_t *uriMap,
 const char *vhost,
  -  const char *uri)
  +  const char *uri, int reverse)
   {
   int best_match = -1;
   int longest_match = 0;
  @@ -590,7 +608,7 @@
   uriLen=strl

cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_uriEnv.c

[mturk]

mturk   2002/08/15 02:24:03

  Modified:jk/native2/common jk_uriEnv.c
  Log:
  Add the reverse mapping option to the uri meaning that the mapping will be
  'reversed' or NOT mapped if the actuall mapping is acomplished.
  
  Revision  ChangesPath
  1.25  +2 -0  jakarta-tomcat-connectors/jk/native2/common/jk_uriEnv.c
  
  Index: jk_uriEnv.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_uriEnv.c,v
  retrieving revision 1.24
  retrieving revision 1.25
  diff -u -r1.24 -r1.25
  --- jk_uriEnv.c   8 Jul 2002 13:36:29 -   1.24
  +++ jk_uriEnv.c   15 Aug 2002 09:24:03 -  1.25
  @@ -157,6 +157,8 @@
   uriEnv->servlet=val;
   } else if( strcmp("timing", name) == 0 ) {
   uriEnv->timing=atoi( val );
  +} else if( strcmp("reverse", name) == 0 ) {
  +uriEnv->reverse=atoi( val );
   } else if( strcmp("alias", name) == 0 ) {
   if( uriEnv->match_type == MATCH_TYPE_HOST ) {
   if( uriEnv->aliases==NULL ) {
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-connectors/jk/native2/include jk_uriMap.h

[mturk]

mturk   2002/08/15 02:22:16

  Modified:jk/native2/include jk_uriMap.h
  Log:
  Add the reverse mapping flag to the mapUri call
  
  Revision  ChangesPath
  1.14  +1 -1  jakarta-tomcat-connectors/jk/native2/include/jk_uriMap.h
  
  Index: jk_uriMap.h
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/include/jk_uriMap.h,v
  retrieving revision 1.13
  retrieving revision 1.14
  diff -u -r1.13 -r1.14
  --- jk_uriMap.h   9 May 2002 20:52:54 -   1.13
  +++ jk_uriMap.h   15 Aug 2002 09:22:16 -  1.14
  @@ -141,7 +141,7 @@
   */
   struct jk_uriEnv *(*mapUri)(struct jk_env *env, jk_uriMap_t *_this,
   const char *vhost,
  -const char *uri );
  +const char *uri, int reverse );
   
   /*  @deprecated  */
   /* used by the mapper, temp storage ( ??? )*/
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-connectors/jk/native2/include jk_uriEnv.h

[mturk]

mturk   2002/08/15 02:21:50

  Modified:jk/native2/include jk_uriEnv.h
  Log:
  Add the reverse mapping flag to the uriEnv
  
  Revision  ChangesPath
  1.16  +5 -0  jakarta-tomcat-connectors/jk/native2/include/jk_uriEnv.h
  
  Index: jk_uriEnv.h
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/include/jk_uriEnv.h,v
  retrieving revision 1.15
  retrieving revision 1.16
  diff -u -r1.15 -r1.16
  --- jk_uriEnv.h   31 May 2002 22:27:17 -  1.15
  +++ jk_uriEnv.h   15 Aug 2002 09:21:50 -  1.16
  @@ -208,6 +208,11 @@
   struct jk_map *envvars;
   
   int merged;
  +
  +/* Reverse mappings
  + */
  +int reverse;
  +
   /** XXX .
*/
   /* int status; */
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 11191] - Error while runing an app using a JDBC connection configured as JNDI resource

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=11191

Error while runing an app using a JDBC connection configured as JNDI resource

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WORKSFORME



--- Additional Comments From [EMAIL PROTECTED]  2002-08-15 08:02 ---
I tried this many times with many different versions of Tomcat 4.1.x, and I 
think it does work. I have no means to test your particular configuration, but 
I'll have to assume it's a user error of some sort.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: