DO NOT REPLY [Bug 35835] - Submitting changes through admin app corrupts the HTTPS connector definition in server.xml

gzilla/show_bug.cgi?id=35835 --- Additional Comments From [EMAIL PROTECTED] 2005-09-29 13:42 --- This is a bug(perhaps) for EXE installed verion of tomcat5.5.12,the ZIP version is correct. with EXE installed version,if i you edit config file(server.xml) in admin app the http 8080 connector c

DO NOT REPLY [Bug 36121] - Including JSP's changes working directory

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://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 35835] - Submitting changes through admin app corrupts the HTTPS connector definition in server.xml

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://issues.apache.org/bugzilla/show_bu

[PATCH] immediately observe JMX-driven host alias changes

Heya, I was surprised to discover that the Host object exposed via JMX allows for addAlias/removeAlias operations but that these changes were never communicated to the Mapper. As such, they weren't immediately effective and were only really of use with the Admin application, which can be us

DO NOT REPLY [Bug 35835] - Submitting changes through admin app corrupts the HTTPS connector definition in server.xml

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://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 35835] - Submitting changes through admin app corrupts the HTTPS connector definition in server.xml

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://issues.apache.org/bugzilla/show_bu

Run Time Worker changes need IIS 5 isolation mode

Unless IIS 6 is set in IIS 5 isolation mode, changes like disabling or stopping a worker using the JK Status Manager do not appear to "hold" or persist across multiple browser sessions. Environment: Server 2003, Tomcat 4.1.27, jk1.2.14 Scenario: open jkstatus page in any brows

DO NOT REPLY [Bug 36121] - Including JSP's changes working directory

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://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 36121] New: - Including JSP's changes working directory

gzilla/show_bug.cgi?id=36121 Summary: Including JSP's changes working directory Product: Tomcat 4 Version: 4.1.31 Platform: Other OS/Version: other Status: NEW Severity: major Priority: P2 Component: Conne

DO NOT REPLY [Bug 35835] - Submitting changes through admin app corrupts the HTTPS connector definition in server.xml

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://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 35835] New: - Submitting changes through admin app corrupts the HTTPS connector definition in server.xml

gzilla/show_bug.cgi?id=35835 Summary: Submitting changes through admin app corrupts the HTTPS connector definition in server.xml Product: Tomcat 5 Version: 5.5.9 Platform: Other OS/Version: other Status: NEW Se

DO NOT REPLY [Bug 34250] - Commit changes button should have confirmation dialog

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://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 35746] - session manager should be immune to system clock time changes (solution provided)

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://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 35746] New: - session manager should be immune to system clock time changes (solution provided)

gzilla/show_bug.cgi?id=35746 Summary: session manager should be immune to system clock time changes (solution provided) Product: Tomcat 5 Version: 5.0.30 Platform: Other OS/Version: other Status: NEW Severity:

Re: WebappLoader and Auto-Detection of Class Changes

Bill, I added an over-ridden modified() method to my classloader that also checks for changes to my added classes folders. I see that WebappLoader.java checks only jars. Works like a charm. Thanks. Bill Barker wrote: - Original Message - From: "Scott Dudley" <[EM

Re: WebappLoader and Auto-Detection of Class Changes

- Original Message - From: "Scott Dudley" <[EMAIL PROTECTED]> To: Sent: Friday, June 03, 2005 12:46 PM Subject: WebappLoader and Auto-Detection of Class Changes > > I extended WebappLoader.java to create a custom classloader to allow me > to append an alter

WebappLoader and Auto-Detection of Class Changes

I extended WebappLoader.java to create a custom classloader to allow me to append an alternate set of class folders. The loader works as intended but I noted that it doesn't detect any changes to these resources and call Context.reload() as is the case with WEB-INF/classes, lib, an

DO NOT REPLY [Bug 32330] - JspC changes context classloader

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://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 34250] - Commit changes button should have confirmation dialog

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://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 34250] - Commit changes button should have confirmation dialog

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://issues.apache.org/bugzilla/show_bu

Re: Some changes

Remy Maucherat wrote: I will propose making some changes: - Add Jan's patch to have an ISE thrown for Session.getId if the session is expired. However, it is important for container internal components to be able to call getId, even if the session is invalidated. As a result, I propose add

DO NOT REPLY [Bug 34250] New: - Commit changes button should have confirmation dialog

gzilla/show_bug.cgi?id=34250 Summary: Commit changes button should have confirmation dialog Product: Tomcat 5 Version: 5.5.7 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Com

Some changes

I will propose making some changes: - Add Jan's patch to have an ISE thrown for Session.getId if the session is expired. However, it is important for container internal components to be able to call getId, even if the session is invalidated. As a result, I propose adding a Session.getIdInt

DO NOT REPLY [Bug 34016] - antiResourceLocking webapp fails to deploy on Tomcat restart after Commit Changes in Admin webapp

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://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 34016] - antiResourceLocking webapp fails to deploy on Tomcat restart after Commit Changes in Admin webapp

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://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 34016] - antiResourceLocking webapp fails to deploy on Tomcat restart after Commit Changes in Admin webapp

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://issues.apache.org/bugzilla/show_bu

Re: JAAS changes in 5.5.8-alpha

that could cause a JAAS test in Geronimo/Tomcat to fail ? It works well in 5.5.7, but fails in 5.5.8-alpha. I see no changes in the JAAS code, besides removing some logging. You can check the CVS history. Rémy - To unsubscribe, e-ma

JAAS changes in 5.5.8-alpha

Hi, I've just upgraded Geronimo to use Tomcat 5.5.8-alpha and suddenly one of the JAAS test that worked well in 5.5.7 failed. I haven't yet investigated what could break it, thus nothing can I say about the issue. What changed between 5.5.7 and 5.5.8-alpha that could cause a JAAS test in Geroni

Re: Mod_Jk .. build problem changes.../resend

woops! was the wrong error and diff! Hi, and before you ask, the next error: Compiling ../common/jk_worker.c ### mwccnlm Compiler: #File: ..\common\jk_worker.c # -- # 52: &we->num_of_workers)) { # Error:

Re: Mod_Jk .. build problem changes...

Hi, and before you ask, the next error: Compiling ../common/jk_worker.c ### mwccnlm Compiler: #File: ..\common\jk_worker.c # -- # 52: we->num_of_workers)) { # Error:^ # illegal imp

Re: Mod_Jk .. build problem changes...

Hi Norm, just fixed - see my last commit. > Just updated mod_jk from CVS and now see the following: > Compiling ../common/jk_sockbuf.c > Compiling ../common/jk_status.c > ### mwccnlm Compiler: > #File: ..\common\jk_status.c > # -- > # 34:

Mod_Jk .. build problem changes...

Greetings All, Just updated mod_jk from CVS and now see the following: Compiling ../common/jk_sockbuf.c Compiling ../common/jk_status.c ### mwccnlm Compiler: #File: ..\common\jk_status.c # -- # 34: "DTD HTML 3.2 Final//EN\">\n" \ #

DO NOT REPLY [Bug 26676] - Changes to server.xml irreversable

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://issues.apache.org/bugzilla/show_bu

RE: JSP changes cause web app reload in 5.5?

rat [mailto:[EMAIL PROTECTED] > Sent: 15 December 2004 13:57 > To: Tomcat Developers List > Subject: Re: JSP changes cause web app reload in 5.5? > > > Allistair Crossley wrote: > > >Our build file was secretly copying web.xml to the web > application causing a web

Re: JSP changes cause web app reload in 5.5?

Allistair Crossley wrote: Our build file was secretly copying web.xml to the web application causing a web app reload. I think earlier versions (like 5.0.x) used to watch web.xml as well. If you don't like the feature, you can edit the list of watched resources in conf/context.xml. RÃmy -

RE: JSP changes cause web app reload in 5.5?

mber 2004 22:04 > To: Tomcat Developers List > Subject: RE: JSP changes cause web app reload in 5.5? > > > I had a quick go at this like you probably did with something > simple, and there is certainly no web application reload in > this circumstance. > > The web a

Re: JSP changes cause web app reload in 5.5?

Allistair Crossley wrote: Thinking about it harder, I can say with 85% surity that this started happening with around 5.5.4 (since I always upgrade our test server on the day of a new Tomcat release). Sigh. Well, of course, it was "broken" with earlier builds, because in some cases reloading was

RE: JSP changes cause web app reload in 5.5?

and config files are also copied. I had the issue in question all day today. All I was doing was making textual changes to a JSP. I used Ant to copy them across (which we have been doing since April 2004) and then made a request to a Struts action (which then return the JSP in question). A white

Re: JSP changes cause web app reload in 5.5?

On Dec 14, 2004, at 11:17 AM, Allistair Crossley wrote: changes to JSPs now cause Tomcat to reload our web applications. Could be deploying the webapp from the same working directory that your IDE uses? Maybe when you think you are only saving the changed jsp you are also modifying the last mod

RE: JSP changes cause web app reload in 5.5?

believe it. I will try and get something together for you asap. Cheers, Allistair -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED] Sent: Tue 14/12/2004 17:07 To: Tomcat Developers List Cc: Subject: Re:

Re: JSP changes cause web app reload in 5.5?

Allistair Crossley wrote: Myself and my developers have noticed that with our new 5.5 development Tomcats changes to JSPs now cause Tomcat to reload our web applications. I cannot reproduce this. Is this expected behaviour? Perhaps the new JDT compiler? Can it be stopped without using

JSP changes cause web app reload in 5.5?

Hi Remy, I have a quick question that I'd like to ask that I don't think anyone on the user list is going to be able to answer ... Myself and my developers have noticed that with our new 5.5 development Tomcats changes to JSPs now cause Tomcat to reload our web applications. T

DO NOT REPLY [Bug 32330] - JspC changes context classloader

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://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 32330] - JspC changes context classloader

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://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 32330] - JspC changes context classloader

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://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 32330] New: - JspC changes context classloader

gzilla/show_bug.cgi?id=32330 Summary: JspC changes context classloader Product: Tomcat 5 Version: 5.0.28 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Jasper Assi

patch - changes in Tomcat-4.1.29´s Jasper to support different encodings

Title: patch - changes in Tomcat-4.1.29´s Jasper to support different encodings     I´ve made some changes in Jasper to support easyer encoding variations, here is the patches.     Regards,     Edson Alves Pereira

patch - changes in Tomcat-4.1.29´s Jasper to support different encodings

Title: patch - changes in Tomcat-4.1.29´s Jasper to support different encodings     I´ve made some changes in Jasper to support easyer encoding variations, here is the patches.     Regards,     Edson Alves Pereira

cvs commit: jakarta-tomcat-connectors/ajp CHANGES

mturk 2004/08/03 03:05:52 Added: ajp CHANGES Log: Initial file. All the changes goes here. Revision ChangesPath 1.1 jakarta-tomcat-connectors/ajp/CHANGES Index: CHANGES

cvs commit: jakarta-tomcat-connectors/ajp/proxy proxy_util.c proxy_http.c proxy_ftp.c proxy_connect.c NWGNUproxyhtp NWGNUproxyftp NWGNUproxycon NWGNUproxy NWGNUmakefile mod_proxy_http.dsp mod_proxy_ftp.dsp mod_proxy_connect.dsp mod_proxy.h mod_proxy.dsp mod_proxy.c Makefile.in libproxy.exp config.m4 CHANGES .indent.pro

mod_proxy_connect.dsp mod_proxy.h mod_proxy.dsp mod_proxy.c Makefile.in libproxy.exp config.m4 CHANGES .indent.pro Log: Initial import from 2.1-HEAD Revision ChangesPath 1.1 jakarta-tomcat-connectors/ajp

DO NOT REPLY [Bug 26488] - compiler does not notice changes to static includes

gzilla/show_bug.cgi?id=26488 compiler does not notice changes to static includes [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RE

Re: jk2 changes

Mladen Turk wrote: The problem could be in the shm. On some platforms the shm remains hunging until reboot. The apr-1.0 has introduced a new function apr_shm_remove(), for removing a named shared memory segment. Ahah! Yes, that would make sense I think although I didn't notice any diagnostics abou

RE: jk2 changes

Wednesday, June 23, 2004 7:52 PM > To: Tomcat Developers List > Subject: Re: jk2 changes > > jean-frederic clere wrote: > > It works on my machine (Apache/2.1.0-dev (Unix) DAV/2 mod_jk2/2.0.5-dev) > > May be that is a problem with IPV6: Use 127.0.0.1 instead of localhost.

Re: jk2 changes

jean-frederic clere wrote: It works on my machine (Apache/2.1.0-dev (Unix) DAV/2 mod_jk2/2.0.5-dev) May be that is a problem with IPV6: Use 127.0.0.1 instead of localhost. Problem fixed. That was odd. Rebooted the machine and it started working. I'm investigating further but it seems unlikely that

Re: jk2 changes

jean-frederic clere wrote: It works on my machine (Apache/2.1.0-dev (Unix) DAV/2 mod_jk2/2.0.5-dev) May be that is a problem with IPV6: Use 127.0.0.1 instead of localhost. Nope :( My investigations continue... -- Andy Armstrong - T

Re: jk2 changes

jean-frederic clere wrote: Andy Armstrong wrote: (posted to the right list now - oops) I'm just making sure the Lotus Domino connector works with the latest jk2 version. As a preamble to that I usually make sure I can get mod_jk2 working with Apache 2 as a kind of baseline. This time I'm getting

Re: jk2 changes

Andy Armstrong wrote: (posted to the right list now - oops) I'm just making sure the Lotus Domino connector works with the latest jk2 version. As a preamble to that I usually make sure I can get mod_jk2 working with Apache 2 as a kind of baseline. This time I'm getting stuck. Is there an incompa

jk2 changes

(posted to the right list now - oops) I'm just making sure the Lotus Domino connector works with the latest jk2 version. As a preamble to that I usually make sure I can get mod_jk2 working with Apache 2 as a kind of baseline. This time I'm getting stuck. Is there an incompatibility between a mod

Site changes

** ** WARNING: WinProxy has detected a virus in file attached to this e-mail message! The attachment has been automatically removed to protect your network. WinProxy Administrator: [EMAIL

DO NOT REPLY [Bug 29048] - Request changes to java permissions in DataSourceRealm

gzilla/show_bug.cgi?id=29048 Request changes to java permissions in DataSourceRealm [EMAIL PROTECTED] changed: What|Removed |Added Status|ASSIGNED|RE

DO NOT REPLY [Bug 29048] - Request changes to java permissions in DataSourceRealm

gzilla/show_bug.cgi?id=29048 Request changes to java permissions in DataSourceRealm [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |AS

Site changes

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

Changes..

Norton AntiVirus Deleted1.txt Description: plain/text - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 29048] - Request changes to java permissions in DataSourceRealm

gzilla/show_bug.cgi?id=29048 Request changes to java permissions in DataSourceRealm --- Additional Comments From [EMAIL PROTECTED] 2004-05-18 10:57 --- As you say, providing a view will provide some of the required function without code modification. The problem is that if the users

DO NOT REPLY [Bug 29048] - Request changes to java permissions in DataSourceRealm

gzilla/show_bug.cgi?id=29048 Request changes to java permissions in DataSourceRealm --- Additional Comments From [EMAIL PROTECTED] 2004-05-18 08:04 --- You can achieve it the other (simpler, imho) way round. Provided that you have the table containing user data (username, password) as well

DO NOT REPLY [Bug 29048] New: - Request changes to java permissions in DataSourceRealm

gzilla/show_bug.cgi?id=29048 Request changes to java permissions in DataSourceRealm Summary: Request changes to java permissions in DataSourceRealm Product: Tomcat 5 Version: 5.0.19 Platform: Other OS/Version: Other Status: NEW Se

DO NOT REPLY [Bug 19545] - CGIServlet accidentaly changes content-length

gzilla/show_bug.cgi?id=19545 CGIServlet accidentaly changes content-length [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RE

Changes for 5.0.23

Personally, I am done (and it was faster than what I expected, which is cool). Hopefully, I didn't break cookies. The new exception "chaining" (I call that nested exceptions, usually) is useful for debugging, obviously. Rémy -

DO NOT REPLY [Bug 27451] - JspC won't detect compile-time include changes

gzilla/show_bug.cgi?id=27451 JspC won't detect compile-time include changes [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW

DO NOT REPLY [Bug 27451] New: - JspC won't detect compile-time include changes

gzilla/show_bug.cgi?id=27451 JspC won't detect compile-time include changes Summary: JspC won't detect compile-time include changes Product: Tomcat 4 Version: 4.1.24 Platform: PC OS/Version: Linux Status: NEW

DO NOT REPLY [Bug 26676] - Changes to server.xml irreversable

gzilla/show_bug.cgi?id=26676 Changes to server.xml irreversable [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Reso

DO NOT REPLY [Bug 26676] New: - Changes to server.xml irreversable

gzilla/show_bug.cgi?id=26676 Changes to server.xml irreversable Summary: Changes to server.xml irreversable Product: Tomcat 5 Version: 5.0.18 Platform: All OS/Version: Other Status: NEW Severity: Major Priority:

DO NOT REPLY [Bug 26488] New: - compiler does not notice changes to static includes

gzilla/show_bug.cgi?id=26488 compiler does not notice changes to static includes Summary: compiler does not notice changes to static includes Product: Tomcat 4 Version: 4.1.29 Platform: PC OS/Version: Windows NT/2K Status: NEW Se

DO NOT REPLY [Bug 26276] - Generated TLD inconsistent after tagfile changes

gzilla/show_bug.cgi?id=26276 Generated TLD inconsistent after tagfile changes [EMAIL PROTECTED] changed: What|Removed |Added Severity|Minor

DO NOT REPLY [Bug 26276] - Generated TLD inconsistent after tagfile changes

gzilla/show_bug.cgi?id=26276 Generated TLD inconsistent after tagfile changes [EMAIL PROTECTED] changed: What|Removed |Added Severity|Major

DO NOT REPLY [Bug 26242] - Changes in jasper command line break ant's task

gzilla/show_bug.cgi?id=26242 Changes in jasper command line break ant's task [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW

DO NOT REPLY [Bug 26276] - Generated TLD inconsistent after tagfile changes

gzilla/show_bug.cgi?id=26276 Generated TLD inconsistent after tagfile changes --- Additional Comments From [EMAIL PROTECTED] 2004-01-21 13:50 --- I did some more research. This is actually what happens: If both the jsp using the tag and the tagfile have been modified, the tag class is gen

DO NOT REPLY [Bug 26276] - Generated TLD inconsistent after tagfile changes

gzilla/show_bug.cgi?id=26276 Generated TLD inconsistent after tagfile changes --- Additional Comments From [EMAIL PROTECTED] 2004-01-20 11:51 --- Created an attachment (id=10022) zip file containing test webapp with instru

DO NOT REPLY [Bug 26276] New: - Generated TLD inconsistent after tagfile changes

gzilla/show_bug.cgi?id=26276 Generated TLD inconsistent after tagfile changes Summary: Generated TLD inconsistent after tagfile changes Product: Tomcat 5 Version: 5.0.18 Platform: PC OS/Version: Windows XP Status: NEW Severity:

DO NOT REPLY [Bug 26242] - Changes in jasper command line break ant's task

gzilla/show_bug.cgi?id=26242 Changes in jasper command line break ant's task --- Additional Comments From [EMAIL PROTECTED] 2004-01-19 16:03 --- Remy, It is not so much that we document the Jasper task, but that we ship with our own task which is meant to support different back

DO NOT REPLY [Bug 26242] - Changes in jasper command line break ant's task

gzilla/show_bug.cgi?id=26242 Changes in jasper command line break ant's task --- Additional Comments From [EMAIL PROTECTED] 2004-01-19 15:11 --- I don't see the point of Ant documenting this, or having the pre declared task. Any reason for this ? Forward compatibility is one

DO NOT REPLY [Bug 26242] New: - Changes in jasper command line break ant's task

gzilla/show_bug.cgi?id=26242 Changes in jasper command line break ant's task Summary: Changes in jasper command line break ant's task Product: Tomcat 5 Version: 5.0.16 Platform: Other OS/Version: Other Status: NEW

Request for changes in the Tomcat.nsi file of TOMCAT 5

Hi, could someone change the tomcat.nsi file with the following options: 1. Search at the first place for the presence of the JSDK instead of the JRE 2. Create a possibility to read the default parameters like InstallDir and InstType from an Tomcat.ini file, so these values could be used for an

DO NOT REPLY [Bug 25109] - Tomcat 4.1.29 changes the content type set by the user by appending an charset, even though no charset has been specified.

gzilla/show_bug.cgi?id=25109 Tomcat 4.1.29 changes the content type set by the user by appending an charset, even though no charset has been specified. [EMAIL PROTECTED] changed: What|Removed

DO NOT REPLY [Bug 25109] New: - Tomcat 4.1.29 changes the content type set by the user by appending an charset, even though no charset has been specified.

gzilla/show_bug.cgi?id=25109 Tomcat 4.1.29 changes the content type set by the user by appending an charset, even though no charset has been specified. Summary: Tomcat 4.1.29 changes the content type set by the user by appending an charset, even though no charset ha

Re: DNS name changes to Machine name with Tomcat 4.1.27 - Reason?

connector) > the host (and referer) name changes once the authentication is complete. > Since the domain name changes to the machine name, one more authentication > popup window comes up. Although, it changes the URL with the machine instead > of domain, the application works without any is

DNS name changes to Machine name with Tomcat 4.1.27 - Reason?

referer) name changes once the authentication is complete. Since the domain name changes to the machine name, one more authentication popup window comes up. Although, it changes the URL with the machine instead of domain, the application works without any issue. But we do not want the user to see

DO NOT REPLY [Bug 19996] - make mod_jk watch for mod_jk.conf changes

gzilla/show_bug.cgi?id=19996 make mod_jk watch for mod_jk.conf changes [EMAIL PROTECTED] changed: What|Removed |Added AssignedTo|tomcat- |[EMAIL PRO

[PATCH] jakarta-servletapi-5 API Changes

jsr152/src/share/javax/servlet/jsp/tagext/TagInfo.java - Fixed incorrect clarification of getVariableInfo(). The original semantics requiring special treatment of the id attribute were supposed to have been removed in JSP 1.2. We brought them back to life in JSP 2.0, but the

FAQ - committed changes - please update site

I just committed a mass update. But given the way diff works on the rendered HTML files - the email barfed and returned to me. Can someone update the tomcat site? Attached is the summary of the FAQ changes. funkman 2003/07/10 18:57:40 Modified:docs/faq bugs.html classnotfound.html

Re: [5.0] JARs handling, and other 5.0.3 changes

Shapira, Yoav wrote: Hi, All that as part of an effort to reduce Tomcat memory footprint (to make it more suitable for large scale deployments), I'm just curious how the two go together? Wouldn't large-scale deployments care less if tomcat's memory footprint was larger? It's typically the s

RE: [5.0] JARs handling, and other 5.0.3 changes

Hi, >All that as part of an effort to reduce Tomcat memory footprint (to make >it more suitable for large scale deployments), I'm just curious how the two go together? Wouldn't large-scale deployments care less if tomcat's memory footprint was larger? It's typically the small (micro, on chips,

[5.0] JARs handling, and other 5.0.3 changes

Hi, I plan to try to get rid (as much as I can) of JAR URLs inside the Catalina (and Jasper) processing, because of the issues which (still, unfortunately :-( ) plague them in the JDK. I will use the fact that all the JAR URLs returned by the classloader are actually file based. I hope that wa

Re: [5] Few major changes in JMX naming

Thanks for clarifying that Costin. Just wanted to make sure. :-) Costin Manolache wrote: Glenn Nielsen wrote: I haven't looked at or played with the new JMX featuers. But I do have some thoughts on names and scopes. We need to ensure that there is a unique naming mechanism. That's the inte

Re: [5] Few major changes in JMX naming

Glenn Nielsen wrote: > I haven't looked at or played with the new JMX featuers. But I do have > some thoughts on names and scopes. We need to ensure that there is a > unique naming mechanism. That's the intention of the change. > A single monitoring tool may be used to monitor multiple insta

Re: [5] Few major changes in JMX naming

Glenn Nielsen wrote: I haven't looked at or played with the new JMX featuers. But I do have some thoughts on names and scopes. We need to ensure that there is a unique naming mechanism. A single monitoring tool may be used to monitor multiple instances of Tomcat. I plan on doing that some time i

Re: [5] Few major changes in JMX naming

Costin Manolache wrote: Not as major as the build breakage, I hope - but I think it is better to do it as soon as possible. Unless someone has good reasons not to do it, I'll start refactoring the JMX registration. There are few things I would like to do: - get rid of "service=XXX" in names. The JM

Re: [5] Few major changes in JMX naming

Remy Maucherat wrote: >> - get rid of "service=XXX" in names. The JMX domain will correspond to >> one tomcat instance - there is no reason to make things more complex. The >> admin can just list all mbeans, search for "*:type=Engine" and get the >> domain. > > Ok, so that goes along with having

Re: [5] Few major changes in JMX naming

I forgot one important thing: The main problem with supporting both registrations is the deregistration - who should unregister a component ? If the components are started by JMX - then JMX is supposed to unregister them. If they are created automatically - then whoever created them is respon

Re: [5] Few major changes in JMX naming

Costin Manolache wrote: Not as major as the build breakage, I hope - but I think it is better to do it as soon as possible. Unless someone has good reasons not to do it, I'll start refactoring the JMX registration. There are few things I would like to do: - get rid of "service=XXX" in names. The JM

  1   2   3   >