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

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=35835>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/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 changes to:



-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

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

[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://issues.apache.org/bugzilla/show_bug.cgi?id=36121


[EMAIL PROTECTED] changed:

   What|Removed |Added

  Component|Connector:JK/AJP|Native:JK
Product|Tomcat 4|Tomcat 5
Version|4.1.31  |5.5.9




--- Additional Comments From [EMAIL PROTECTED]  2005-09-21 01:01 ---
I have replicated this problem with Apache 2.0.54 and JK 1.2.14 with the latest
versions (from SVN/CVS) of both TC4 and TC5.

It looks like the problem is in the native JK code but I am afraid I don't know
where to start looking. I am moving this issue to TC5 since that is the current
focus of development.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 35835] - Submitting changes through admin app corrupts the HTTPS connector definition 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://issues.apache.org/bugzilla/show_bug.cgi?id=35835





--- Additional Comments From [EMAIL PROTECTED]  2005-09-17 03:28 ---
I verified that this works in 5.5.11-alpha. Any idea whether/when the fix will
be ported to 5.0.x (currently 5.0.30) ? If the fix is to the admin webapp only,
then,
can I just take the admin webapp from 5.5.11 and then try it under 5.0.x ? 
thanks.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

[PATCH] immediately observe JMX-driven host alias changes

[Luke Kirby]

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 used to write the new aliases of the host back to
server.xml, effective on restart.

This patch communicates JMX-driven host alias changes to the mapper so
that the alias is immediately available for use without any need for a
restart, much like JMX-driven host removals/additions already work.

The approach I've taken is to have the StandardHostMBean fire JMX
AttributeChangeNotifications after an add/removeAlias operation. I
changed MapperListener to observe these notifications and then reflect
the change in the the Mapper instance it serves (this required a
little more smarts in Mapper). I had to change
catalina/core/mbeans-descriptor.xml to reinstate StandardHostMBean as
the MBean to be used for StandardHost - I couldn't see where
StandardHostMBean was actually being used before.. any reason? I took
this approach because MapperListener was already JMX-based; I guess
one could choose to do something based more on internal events, but I
hope this suffices.

The patch follows my signature. Let me know if I've missed something
or this solution is unsatisfactory. Hope it works!

Thanks,

  Luke

Index: 
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector/MapperListener.java
===
RCS file: 
/home/cvspublic/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector/MapperListener.java,v
retrieving revision 1.2
diff -u -r1.2 MapperListener.java
--- 
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector/MapperListener.java
29
Jan 2005 19:42:27 - 1.2
+++ 
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector/MapperListener.java
14
Sep 2005 18:03:31 -
@@ -24,6 +24,9 @@
 import javax.management.NotificationListener;
 import javax.management.ObjectInstance;
 import javax.management.ObjectName;
+import javax.management.AttributeChangeNotificationFilter;
+import javax.management.AttributeChangeNotification;
+import javax.management.ListenerNotFoundException;
 
 import org.apache.commons.logging.Log;
 import org.apache.commons.logging.LogFactory;
@@ -69,6 +72,13 @@
 private String domain="*";
 private String engine="*";
 
+/**
+ * The filter for host alias attribute change notifications
+ */
+private AttributeChangeNotificationFilter
hostAliasAttributeNotificationFilter =
+new AttributeChangeNotificationFilter();
+
+
 // --- Constructors
 
 
@@ -77,6 +87,8 @@
  */
 public MapperListener(Mapper mapper) {
 this.mapper = mapper;
+hostAliasAttributeNotificationFilter.disableAllAttributes();
+hostAliasAttributeNotificationFilter.enableAttribute("aliases");
 }
 
 
@@ -159,6 +171,21 @@
 ObjectName objectName = new ObjectName(
 "JMImplementation:type=MBeanServerDelegate");
 mBeanServer.removeNotificationListener(objectName, this);
+
+// remove listeners from all host objects
+Set hostMBeans = mBeanServer.queryMBeans(new
ObjectName(domain + ":type=Host,*"), null);
+Iterator hostMBeanIt = hostMBeans.iterator();
+while (hostMBeanIt.hasNext())
+{
+final ObjectInstance hostMBean =
(ObjectInstance)hostMBeanIt.next();
+try
+{
+   
mBeanServer.removeNotificationListener(hostMBean.getObjectName(),
this);
+} catch (Exception e) {
+log.warn("Error unregistering host listener", e);
+}
+}
+
 } catch (Exception e) {
 log.warn("Error unregistering MBeanServerDelegate", e);
 }
@@ -245,6 +272,25 @@
 }
 }
 }
+
+} else if (notification instanceof AttributeChangeNotification) {
+
+final AttributeChangeNotification attrChangeNotification
= (AttributeChangeNotification)notification;
+
+if ("aliases".equals(attrChangeNotification.getAttributeName()))
+{
+final ObjectName hostName = (ObjectName)
attrChangeNotification.getSource();
+try
+{
+reconfigureAliases(
+hostName,
+(String[])attrChangeNotification.getNewValue());
+}
+catch (Throwable t)
+{
+log.warn("Error updating aliases for " + hostName, t);
+}
+}
 

DO NOT REPLY [Bug 35835] - Submitting changes through admin app corrupts the HTTPS connector definition 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://issues.apache.org/bugzilla/show_bug.cgi?id=35835





--- Additional Comments From [EMAIL PROTECTED]  2005-09-02 02:27 ---
Yes, I'd like to test it out. But where I can get 5.5.10 from ? I see 5.5.9 and
5.5.11-alpha from the download page. Would you like me to try 5.5.11-alpha ?
thanks (and sorry for the delay in responding to this)

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 35835] - Submitting changes through admin app corrupts the HTTPS connector definition 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://issues.apache.org/bugzilla/show_bug.cgi?id=35835


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |NEEDINFO




--- Additional Comments From [EMAIL PROTECTED]  2005-09-01 20:48 ---
Well, when you get a chance to test, please let us know.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

Run Time Worker changes need IIS 5 isolation mode

[Sumpter, Chuck]

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 browser (tested IE5, IE6, Netscape
8, Firefox 1.0.6) click on the worker name, complete the "Disabled"
check box and click Update Worker.  Worker status changes to Disabled as
expected.  Click on the same worker name a second time and the worker
status reverts to OK.  This behavior is also seen if you open the same
jkstatus page in another browser. 

 

This appears to be an offshoot of the ""worker process isolation mode"
that is a part of IIS 6 in a Server 2003 environment. 

Changing to IIS 5's isolation mode seems to resolve the "problem", at
least for me.  

 

For more information, refer to bug #36102.  This issue is being posted
on Tomcat-Dev at the Connector developer's request. 

 

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

[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://issues.apache.org/bugzilla/show_bug.cgi?id=36121





--- Additional Comments From [EMAIL PROTECTED]  2005-08-17 14:25 ---
Also reported Bug #36191 to Apache/mod_include but the conclusion was it wasn't
mod_include. Can anyone help us with this issue?

Tom

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

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

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=36121>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/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: Connector:JK/AJP
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


Adding to the headers of the bug;
Apache 2.0.54 was used with mod_jk 1.2.13 on Redhat 9

Hi,

One of our customers uses SSI (mod_include) to include their jsp's

eg file index.shtml (located in /web/customer/www)




What happens is that "top" and "news" are displayed correctly, but bottom fails
with "[an error occurred while processing this directive]". If we move the
include of "bottom.html" above the jsp line it works (besides from the webpage
not displaying as desired :)

The errorlog contains the following lines after requesting the page from apache;
File does not exist: /web/customer/www/active/bottom.html
unable to include "bottom.html" in parsed file /web/customer/www/index.shtml

If found Bug #34232 mentioning the same, but it was discarded as being apache
and/or mod_include. I didn't find any references to a new(er) ticket in ASF. The
current workaround for our customer would be to update their files to 'include
virtual="../bottom.html"' or revert back to their original "exec cgi" statements
(which worked, but we agreed with them upon that being deprecated).

For some reason the "include virtual" (or include file which causes the same)
that executes the 'jsp' sets the current working directory to "active" instead
of going 'back' to the directory where index.shtml was parsed from.

Any suggestions or options are welcome,

Tom

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 35835] - Submitting changes through admin app corrupts the HTTPS connector definition 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://issues.apache.org/bugzilla/show_bug.cgi?id=35835





--- Additional Comments From [EMAIL PROTECTED]  2005-07-27 02:11 ---
For the storeconfig module, this was fixed in 5.5.10: see
http://cvs.apache.org/viewcvs.cgi/jakarta-tomcat-catalina/modules/storeconfig/src/share/org/apache/catalina/storeconfig/ConnectorStoreAppender.java?rev=1.3&view=log.
 Can you please test 5.5.10 and let us know?

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

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

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=35835>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/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
  Severity: normal
  Priority: P2
 Component: Webapps:Administration
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


I'm using tomcat 5.5.9 version and when I use the admin app to make any changes
to the server.xml file (or evn if I just save, without making any changes), the
HTTPS connector definition (if there is one defined) in server.xml gets
corrupted. Basically the the attribute "sslProtocol=TLS"" is omitted when 
saving it.
As a result, https connection doesn't work. If I add that attribute manually
after  I save the changes through the admin app, then https connection works.

We noticed a similar problem on tomcat 5.0.28 as well, and I posted a question
about this on the tomcat mailing lists last month. In tomcat 5.0.28, the issue
was slightly different that when you save changes through the admin webapp, the
following duplicate attributes to the HTTPS connector were being added. If we
remove those entries manually, then the connector seem to come up fine.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

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

[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://issues.apache.org/bugzilla/show_bug.cgi?id=34250


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2005-07-22 17:40 ---
Good idea, done.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

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

[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://issues.apache.org/bugzilla/show_bug.cgi?id=35746


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |NEEDINFO




--- Additional Comments From [EMAIL PROTECTED]  2005-07-22 15:25 ---
Please submit a patch to the SessionManager using your time tracker, instead of
a generic piece of time tracking code...

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

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

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=35746>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/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: normal
  Priority: P2
 Component: Catalina
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


Hi,
The session manager should be able to age session by age, not by comparison to
system time stamp.

Here is a simple and working time tracker immune to time shifts.
It 'knows' it waited some amount of milliseconds. This cannot be hacked on any
OS. Given that, the time arrow is maintained and session can be aged normally,
even if system time changes on the server, which is more than probable on
appliances and embed system.
 
That would prevent http session to expire and logout user prematurely.
Note that upon the receiver update, 't2' is always the current time (now) and
't1' is usually the last 't2' is no shift was detected.


public void run() {
long t1 = -1;
while(true) {
try {
long t2 = System.currentTimeMillis();

//-- time shifting detection 
long shift = 0;
if(t1>0) { //if not first loop
long expected = t1+intervalMillis;
shift = t2-expected;
if(shift > timePositiveShiftTolerance) {
vlogger.warn("Time shifted in future by 
more than positive tolerance:
shift="+shift+" ms, tolerance="+timePositiveShiftTolerance);
//fireTimeDriftEvent(expected, drift);
t1 = t2-intervalMillis;

} else if(shift < timeNegativeShiftTolerance) {
vlogger.warn("Time shifted in past by 
more than negative tolerance:
shift="+shift+" ms, tolerance="+timeNegativeShiftTolerance);
//fireTimeDriftEvent(expected, drift);
t1 = t2-intervalMillis;

} else {
shift = 0;
}
}


///
//someReceiver.update(t1, t2, shift);
///

t1 = t2;
Thread.sleep(intervalMillis);

} catch(IllegalArgumentException e) {
vlogger.warn("",e);
//no break.
} catch(InterruptedException e) {
break;
} catch(Exception e) {
vlogger.error("",e);
}
}
}

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

Re: WebappLoader and Auto-Detection of Class Changes

[Scott Dudley]

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" <[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 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, and any  entries.  What am I missing.  Looking at
WebappLoader.java and I fail to notice the mechanism which provides said
functionality.

Can someone point me in the right direction?

   



Look at WebappLoader.modified.  That determines if the app should be
reloaded.

 


Many thanks.

--

Regards,

Scott Dudley


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


   





This message is intended only for the use of the person(s) listed above as the 
intended recipient(s), and may contain information that is PRIVILEGED and 
CONFIDENTIAL.  If you are not an intended recipient, you may not read, copy, or 
distribute this message or any attachment. If you received this communication 
in error, please notify us immediately by e-mail and then delete all copies of 
this message and any attachments.

In addition you should be aware that ordinary (unencrypted) e-mail sent through 
the Internet is not secure. Do not send confidential or sensitive information, 
such as social security numbers, account numbers, personal identification 
numbers and passwords, to us via ordinary (unencrypted) e-mail.


 




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



--

Regards,

Scott Dudley


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

Re: WebappLoader and Auto-Detection of Class Changes

[Bill Barker]

- 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 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, and any  entries.  What am I missing.  Looking at
> WebappLoader.java and I fail to notice the mechanism which provides said
> functionality.
>
> Can someone point me in the right direction?
>

Look at WebappLoader.modified.  That determines if the app should be
reloaded.

> Many thanks.
>
> --
>
> Regards,
>
> Scott Dudley
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>



This message is intended only for the use of the person(s) listed above as the 
intended recipient(s), and may contain information that is PRIVILEGED and 
CONFIDENTIAL.  If you are not an intended recipient, you may not read, copy, or 
distribute this message or any attachment. If you received this communication 
in error, please notify us immediately by e-mail and then delete all copies of 
this message and any attachments.

In addition you should be aware that ordinary (unencrypted) e-mail sent through 
the Internet is not secure. Do not send confidential or sensitive information, 
such as social security numbers, account numbers, personal identification 
numbers and passwords, to us via ordinary (unencrypted) e-mail.


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

WebappLoader and Auto-Detection of Class Changes

[Scott Dudley]

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, and any  entries.  What am I missing.  Looking at 
WebappLoader.java and I fail to notice the mechanism which provides said 
functionality.


Can someone point me in the right direction?

Many thanks.

--

Regards,

Scott Dudley


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

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

[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://issues.apache.org/bugzilla/show_bug.cgi?id=32330


[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

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

[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://issues.apache.org/bugzilla/show_bug.cgi?id=34250





--- Additional Comments From [EMAIL PROTECTED]  2005-04-01 16:28 ---
(In reply to comment #1)
> Changing to an enhancement request.  It's one of those ever-continuing 
dialogs
> about how big and how red the destruction button should be ;)

OK, fair enough ;o)

But it's just a boring grey button at the moment with no warning at all...

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

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

[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://issues.apache.org/bugzilla/show_bug.cgi?id=34250


[EMAIL PROTECTED] changed:

   What|Removed |Added

   Severity|normal  |enhancement




--- Additional Comments From [EMAIL PROTECTED]  2005-04-01 15:53 ---
Changing to an enhancement request.  It's one of those ever-continuing dialogs
about how big and how red the destruction button should be ;)

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

Re: Some changes

[Remy Maucherat]

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 adding a Session.getIdInternal method (or propose 
another name) which would do the same as the old getId

- I reported some mess with the JAAS realm some time earlier, which has 
to maintain a map of principals, which is messy and makes code more 
complex (as well as needlessly leaking memory). We do have the exact 
same issue in JBoss, as we use JAAS as well. Scott Stark proposed 
storing the user principal to be returned by Request.getUserPrincipal 
inside the GenericPrincipal itself, while the regular GenericPrincipal 
would be used for calls to hasRole (removing the need for the JAAS realm 
to override the method).
This would mean adding a new constructor to GenericPrincipal:
/**
 * Construct a new Principal, associated with the specified Realm, 
for the
 * specified username and password, with the specified role names
 * (as Strings).
 *
 * @param realm The Realm that owns this principal
 * @param name The username of the user represented by this Principal
 * @param password Credentials used to authenticate this user
 * @param roles List of roles (must be Strings) possessed by this user
 * @param userPrincipal - the principal to be returned from the 
request getUserPrincipal call if not null.
 */
public GenericPrincipal(Realm realm, String name, String password,
List roles, Principal userPrincipal)

That's all the proposals I have for now.
Ok, so nobody cares ;) I'll commit the changes then.
Another thing:
The purpose of DataSourceRealm.authenticate overriding seems to be to 
use only one "connection" for the full authentication process. This 
seems to me like a rather pointless optimization, and straight 
delegation to the RealmBase should be used instead.
I added this myself as part of an omnibus patch which was submitted to 
fix a very serious problem (I was anxious to commit it ...), so I'm 
partially vetoing myself here :)
The change would be to remove the two DataSourceRealm.authenticate methods.

Comments ?
Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=34250>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/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
 Component: Webapps:Administration
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


We distribute the admin webapp so customers can manage users and roles, and
sometimes they press the Commit Changes button (even though it's not required
for users/group/role admin). We've noticed that ther resulting rewrite of Tomcat
config files can lead to running web applications being reloaded - which can be
disasterous for some of our critical apps.

I don't think this behaviour is a bug with Tomcat, but it IS a real problem that
users aren't warned about the potentially devastating effect of clicking Commit
Changes before it happens. A simple dialog warning of the consequences (and
mentioning that user/role admins don't need this button anyway) would be a huge
improvement.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

Some changes

[Remy Maucherat]

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.getIdInternal method (or propose 
another name) which would do the same as the old getId

- I reported some mess with the JAAS realm some time earlier, which has 
to maintain a map of principals, which is messy and makes code more 
complex (as well as needlessly leaking memory). We do have the exact 
same issue in JBoss, as we use JAAS as well. Scott Stark proposed 
storing the user principal to be returned by Request.getUserPrincipal 
inside the GenericPrincipal itself, while the regular GenericPrincipal 
would be used for calls to hasRole (removing the need for the JAAS realm 
to override the method).
This would mean adding a new constructor to GenericPrincipal:
/**
 * Construct a new Principal, associated with the specified Realm, 
for the
 * specified username and password, with the specified role names
 * (as Strings).
 *
 * @param realm The Realm that owns this principal
 * @param name The username of the user represented by this Principal
 * @param password Credentials used to authenticate this user
 * @param roles List of roles (must be Strings) possessed by this user
 * @param userPrincipal - the principal to be returned from the 
request getUserPrincipal call if not null.
 */
public GenericPrincipal(Realm realm, String name, String password,
List roles, Principal userPrincipal)

That's all the proposals I have for now.
Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[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://issues.apache.org/bugzilla/show_bug.cgi?id=34016


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|VERIFIED




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

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

[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://issues.apache.org/bugzilla/show_bug.cgi?id=34016


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2005-03-15 14:07 ---
Fixed.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

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

[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://issues.apache.org/bugzilla/show_bug.cgi?id=34016


[EMAIL PROTECTED] changed:

   What|Removed |Added

 AssignedTo|[EMAIL PROTECTED] |tomcat-
   ||[EMAIL PROTECTED]




--- Additional Comments From [EMAIL PROTECTED]  2005-03-15 14:06 ---
Never assign a bug directly to someone.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

Re: JAAS changes in 5.5.8-alpha

[Remy Maucherat]

Jacek Laskowski wrote:
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 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-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

JAAS changes in 5.5.8-alpha

[Jacek Laskowski]

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 Geronimo/Tomcat to fail ?

It works well in 5.5.7, but fails in 5.5.8-alpha.
Jacek
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Günter Knauf]

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:^
#   illegal implicit conversion from 'int *' to
#   'unsigned int *'

can be fixed for the moment with:

--- jk_worker.c.origSun Feb 13 23:03:50 2005
+++ jk_worker.c Sun Feb 13 23:59:50 2005
@@ -49,7 +49,7 @@
 }
 
 if (!jk_get_worker_list(init_data, &(we->worker_list),
-&we->num_of_workers)) {
+(unsigned int *)&we->num_of_workers)) {
 JK_TRACE_EXIT(l);
 we->num_of_workers = 0;
 we->worker_list = NULL;


however at the moment I cant find find the heck where the type mismatch really 
is...

Mladen: please take a look at jk_lc_worker.c where a couple of times 
num_of_workers is defined as int instead of unsigned...

Guenter.



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

Re: Mod_Jk .. build problem changes...

[Günter Knauf]

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 implicit conversion from 'int' to
#   'unsigned int *'

can be fixed for the moment with:

--- jk_worker.c.origSun Feb 13 23:44:08 2005
+++ jk_worker.c Sun Feb 13 23:59:50 2005
@@ -49,7 +49,7 @@
 }
 
 if (!jk_get_worker_list(init_data, &(we->worker_list),
-we->num_of_workers)) {
+(unsigned int *)&we->num_of_workers)) {
 JK_TRACE_EXIT(l);
 we->num_of_workers = 0;
 we->worker_list = NULL;


however at the moment I cant find find the heck where the type mismatch really 
is...

Mladen: please take a look at jk_lc_worker.c where a couple of times 
num_of_workers is defined as int instead of unsigned...

Guenter.



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

Re: Mod_Jk .. build problem changes...

[Günter Knauf]

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: "DTD HTML 3.2 Final//EN\">\n"  \
> #   Error: ^
> #   declaration syntax error

> Errors caused tool to abort.
> make: *** [Release.o/jk_status.o] Error 1

> Darned at this point if I can spot the reason, however in the hope that
> this was the only one, tweaked the line to continue, and now get:

> Compiling ../common/jk_util.c
> Compiling ../common/jk_worker.c
> ### mwccnlm Compiler:
> #File: ..\common\jk_worker.c
> # --
> #  52:  &we->num_of_workers)) {
> #   Error: ^
> #   illegal implicit conversion from 'int *' to
> #   'unsigned int *'

> Errors caused tool to abort.
> make: *** [Release.o/jk_worker.o] Error 1

> Norm

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



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

Mod_Jk .. build problem changes...

[NormW]

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"  \
#   Error: ^
#   declaration syntax error
Errors caused tool to abort.
make: *** [Release.o/jk_status.o] Error 1
Darned at this point if I can spot the reason, however in the hope that 
this was the only one, tweaked the line to continue, and now get:

Compiling ../common/jk_util.c
Compiling ../common/jk_worker.c
### mwccnlm Compiler:
#File: ..\common\jk_worker.c
# --
#  52:  &we->num_of_workers)) {
#   Error: ^
#   illegal implicit conversion from 'int *' to
#   'unsigned int *'
Errors caused tool to abort.
make: *** [Release.o/jk_worker.o] Error 1
Norm
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[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://issues.apache.org/bugzilla/show_bug.cgi?id=26676





--- Additional Comments From [EMAIL PROTECTED]  2005-02-13 16:09 ---
(In reply to comment #1)
> You are not supposed to add Context declarations to server.xml, because the
> contexts then become impossile to manage. This works as designed, but it is
> obviously different from Tomcat 4.1.x.
If this is so, why does the Tomcat 5.5 DataSource configuration documentation 
instruct you to do so?



-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

RE: JSP changes cause web app reload in 5.5?

[Allistair Crossley]

Hi,

Yep, sure enough 5.5.5's context.xml has 

WEB-INF/web.xml

Cool. Thanks. I just stopped Ant from doing an explicit copy of web.xml unless 
the file has changed like everything else, and that works fine too.

Cheers, Allistair.

> -Original Message-
> From: Remy Maucherat [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 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
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 


 
---
QAS Ltd.
Developers of QuickAddress Software
http://www.qas.com";>www.qas.com
Registered in England: No 2582055
Registered in Australia: No 082 851 474
---

Re: JSP changes cause web app reload in 5.5?

[Remy Maucherat]

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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: JSP changes cause web app reload in 5.5?

[Allistair Crossley]

Dear Remy,

OK, you were right : ;) Our build file was secretly copying web.xml to the 
web application causing a web app reload. 

Sorry about that, but it was restarting at least on JSP copies ;) 

Allistair.

> -Original Message-
> From: Allistair Crossley 
> Sent: 14 December 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 application in question is configured with JNDI 
> datasources and log4j. The architecture of the application 
> uses Struts and Tiles for JSPs. I think I am going to have to 
> try to take copy of the application and work it backwards to 
> see where/what causes the Tomcat web app reload. 
>  
> We use Ant to build the web application. For development JSPs 
> this is a simple copy to the web app folder. For classes, 
> they are compiled. Static resources 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 page is shown (or partial HTML page). 
> Looking in stdout, you can see the web application has been 
> reinitialised. The Ant build output shows no compilation of 
> classes, so the reloadable aspect of Tomcat should not in my 
> view be triggered. 
>  
> 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). 
>  
> I don't know what else to add really at this point. I will 
> perform some further tests tomorrow to narrow it down if I 
> can, but this is an issue with *something*, it's just finding 
> out where. It could be as simple as Ant is touching class 
> files when it should not (which it never used to so I doubt 
> it) or it could be something in Tomcat but I would not know what/why.
>  
> Will let you know if I find any more hard links to what 
> causes the issue.
>  
> Allistair.
> 
>   -Original Message- 
>   From: Remy Maucherat [mailto:[EMAIL PROTECTED] 
>   Sent: Tue 14/12/2004 17:07 
>   To: Tomcat Developers List 
>   Cc: 
>   Subject: 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 reloadable="false"? 
> We don't use anti JAR locking either.
>   > 
>   >
>   You have a vivid imagination. What else ?
>   
>   RÃmy
>   
>   
>   
> -
>   To unsubscribe, e-mail: 
> [EMAIL PROTECTED]
>   For additional commands, e-mail: 
> [EMAIL PROTECTED]
>   
>   
> 
> 
> 
>  
> ---
> QAS Ltd.
> Developers of QuickAddress Software
> http://www.qas.com";>www.qas.com
> Registered in England: No 2582055
> Registered in Australia: No 082 851 474
> ---
> 
> 
> 

Re: JSP changes cause web app reload in 5.5?

[Remy Maucherat]

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 not initialized properly. I suppose you were in 
one of these cases.

Turn on debug logging for the only class which triggers reloading (since 
you have class reloading off, that's the o.a.c.startup.HostConfig 
class). It will tell you what it's checking, and you should easily see 
which watched resource has been updated (hint: it will not be a JSP). 
It's not that difficult.

RÃmy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: JSP changes cause web app reload in 5.5?

[Allistair Crossley]

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 application in question is configured with JNDI datasources and log4j. 
The architecture of the application uses Struts and Tiles for JSPs. I think I 
am going to have to try to take copy of the application and work it backwards 
to see where/what causes the Tomcat web app reload. 
 
We use Ant to build the web application. For development JSPs this is a simple 
copy to the web app folder. For classes, they are compiled. Static resources 
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 page is shown (or partial HTML page). Looking in 
stdout, you can see the web application has been reinitialised. The Ant build 
output shows no compilation of classes, so the reloadable aspect of Tomcat 
should not in my view be triggered. 
 
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). 
 
I don't know what else to add really at this point. I will perform some further 
tests tomorrow to narrow it down if I can, but this is an issue with 
*something*, it's just finding out where. It could be as simple as Ant is 
touching class files when it should not (which it never used to so I doubt it) 
or it could be something in Tomcat but I would not know what/why.
 
Will let you know if I find any more hard links to what causes the issue.
 
Allistair.

-Original Message- 
From: Remy Maucherat [mailto:[EMAIL PROTECTED] 
Sent: Tue 14/12/2004 17:07 
To: Tomcat Developers List 
Cc: 
Subject: 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 reloadable="false"? We don't use anti JAR locking either.
> 
>
You have a vivid imagination. What else ?

RÃmy


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





 
---
QAS Ltd.
Developers of QuickAddress Software
http://www.qas.com";>www.qas.com
Registered in England: No 2582055
Registered in Australia: No 082 851 474
---


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

Re: JSP changes cause web app reload in 5.5?

[Sandy McArthur]

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 time stamps on other files too.

--
Sandy McArthur
"Our lives begin to end the day we become silent
about things that matter." - Martin Luther King, Jr.


smime.p7s
Description: S/MIME cryptographic signature

RE: JSP changes cause web app reload in 5.5?

[Allistair Crossley]

Remy,
 
I really have to bite my lip sometimes with your blunt replies.
 
The fact of the matter is that I am not stupid, nor do I have a vivid 
imagination. You may be a developer of Tomcat but that does not necessarily 
equate to you being right all the time about bugs, and I have seen several 
times where you are wrong, several of which have been things I have reported 
and one of which I fixed. Give me some credit please.
 
Now, the fact of the matter is, we have a situation where Tomcat *is* without a 
doubt reloading our web application on *all* developers' personal Tomcat 5.5.5 
instances. We are all working on different subsystems across the code base too 
and same behaviour. A very junior developer said to me this morning, "this new 
Tomcat is a little temperamental isn't it?". Now this guy does not know much 
about how Tomcat works, but he is very aware of what a Tomcat looks like when 
reloading a web application, e.g a request goes in and we get broken response 
HTML coming back, and of course definate proof in the logs stating quite 
explicitly that the web application is being reloaded. My guess at JDT compiler 
was simply based on the fact that it is used for JSP compilation and is new. An 
assertion or guess that is not "vivid" imo.
 
So I appreciate you cannot reproduce it with maybe servlet-examples OK. But the 
issue *is not* my "vivid imagination". So, I wonder how I can provide something 
that will make you 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: 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 reloadable="false"? We don't use anti JAR locking either.
> 
>
You have a vivid imagination. What else ?

RÃmy


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





 
---
QAS Ltd.
Developers of QuickAddress Software
http://www.qas.com";>www.qas.com
Registered in England: No 2582055
Registered in Australia: No 082 851 474
---


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

Re: JSP changes cause web app reload in 5.5?

[Remy Maucherat]

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 reloadable="false"? We don't use anti JAR locking either.
 

You have a vivid imagination. What else ?
Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

JSP changes cause web app reload in 5.5?

[Allistair Crossley]

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. 

This causes (because we're too keen to see changes) blank pages/broken 
responses and ThreadDeath occasionally when we put immediate requests in to the 
pages. 

It's not quite as nice during development to have to wait that extra short 
while for TC to restart the whole container because of a JSP change, and it 
makes me worry about patching production JSPs.

Is this expected behaviour? Perhaps the new JDT compiler? Can it be stopped 
without using reloadable="false"? We don't use anti JAR locking either.

Cheers, Allistair

> -Original Message-
> From: Shapira, Yoav [mailto:[EMAIL PROTECTED]
> Sent: 14 December 2004 15:52
> To: Allistair Crossley
> Subject: RE: Leaving Millennium, going on vacation...
> 
> 
> 
> Thank you, and the same to you and your family -- enjoy the 
> holidays ;)
> 
> Yoav Shapira http://www.yoavshapira.com
>  
> 
> >-Original Message-
> >From: Allistair Crossley [mailto:[EMAIL PROTECTED]
> >Sent: Tuesday, December 14, 2004 10:28 AM
> >To: Tomcat Developers List
> >Subject: RE: Leaving Millennium, going on vacation...
> >
> >Merry Christmas Yoav, all the best for the New Year and enjoy your
> >holidays. I don't blame you leaving your laptop behind ;)
> >
> >See you in the New Year. Allistair.
> >
> >> -Original Message-
> >> From: Shapira, Yoav [mailto:[EMAIL PROTECTED]
> >> Sent: 14 December 2004 15:20
> >> To: Tomcat Developers List
> >> Subject: Leaving Millennium, going on vacation...
> >>
> >>
> >>
> >> Hi,
> >> Tomorrow is my last day at Millennium, so this [EMAIL PROTECTED]
> address
> >> will become invalid.  I'm going on vacation for most of the rest of
> >> December, and then I'll be back in January (although we'll
> >> see how busy
> >> school will be.  This is just an FYI, I'll still be around 
> for a few
> >> more days before vacation, but after the 19th I'm out of the
> >> country and
> >> not taking my laptop with me...
> >>
> >> Yoav Shapira http://www.yoavshapira.com
> >>
> >>
> >>
> >>
> >>
> >> This e-mail, including any attachments, is a confidential
> >> business communication, and may contain information that is
> >> confidential, proprietary and/or privileged.  This e-mail is
> >> intended only for the individual(s) to whom it is addressed,
> >> and may not be saved, copied, printed, disclosed or used by
> >> anyone else.  If you are not the(an) intended recipient,
> >> please immediately delete this e-mail from your computer
> >> system and notify the sender.  Thank you.
> >>
> >>
> >> 
> -
> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >>
> >
> >
> >
> >---
> >QAS Ltd.
> >Developers of QuickAddress Software
> >http://www.qas.com";>www.qas.com
> >Registered in England: No 2582055
> >Registered in Australia: No 082 851 474
> >---
> >
> >
> >
> >-
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 
> 
> This e-mail, including any attachments, is a confidential 
> business communication, and may contain information that is 
> confidential, proprietary and/or privileged.  This e-mail is 
> intended only for the individual(s) to whom it is addressed, 
> and may not be saved, copied, printed, disclosed or used by 
> anyone else.  If you are not the(an) intended recipient, 
> please immediately delete this e-mail from your computer 
> system and notify the sender.  Thank you.
> 
> 


 
---
QAS Ltd.
Developers of QuickAddress Software
http://www.qas.com";>www.qas.com
Registered in England: No 2582055
Registered in Australia: No 082 851 474
---



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

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

[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://issues.apache.org/bugzilla/show_bug.cgi?id=32330


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2004-11-22 15:55 ---
Not only is this good for your issue, it solves another one which I'd close as 
not reproducible.  So this is great.  Thank you for submitting this patch.

Done for 5.5.5 and 5.0.30.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

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

[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://issues.apache.org/bugzilla/show_bug.cgi?id=32330


[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]




--- Additional Comments From [EMAIL PROTECTED]  2004-11-22 15:55 ---
*** Bug 29904 has been marked as a duplicate of this bug. ***

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

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

[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://issues.apache.org/bugzilla/show_bug.cgi?id=32330





--- Additional Comments From [EMAIL PROTECTED]  2004-11-20 17:20 ---
Created an attachment (id=13509)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=13509&action=view)
fix for this bug: set back original ClassLoader just before returning from
processFile()


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

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

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=32330>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/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
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


In JspC the context classloader is set (initClassLoader() in processFile()), but
never reset to the original. This may cause serious (and hard to find ;-))
classloader trouble when JspC is used as an Ant task. For example, in my case
ant crashes during an xdoclet task (!) that is executed after the jspc task with
the following message: Class org.apache.commons.logging.impl.Jdk14Logger does
not implement Log.

I think the fix is fairly simple: just set back the original classloader after
JspC is done - that is, for me this works fine. I'll attach a patch.

Peter Doornbosch
Luminis - The Art of Software Engineering
web: http://www.luminis.nl

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

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

[Edson Alves Pereira]

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


 <> 



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

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

[Edson Alves Pereira]

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



 <> 



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

cvs commit: jakarta-tomcat-connectors/ajp CHANGES

[mturk]

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
  ===
  JAKARTA TOMCAT CONNECTORS AJP CHANGELOG:-*-text-*-
  Last modified at [$Date: 2004/08/03 10:05:52 $]
  
  Changes in AJP HEAD:
  * Imported proxy sources from 2.1-HEAD
[Mladen Turk]
  
  
  

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

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

[mturk]

mturk   2004/08/03 03:01:41

  Added:   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
  Log:
  Initial import from 2.1-HEAD
  
  Revision  ChangesPath
  1.1  jakarta-tomcat-connectors/ajp/proxy/proxy_util.c
  
  
http://cvs.apache.org/viewcvs/jakarta-tomcat-connectors/ajp/proxy/proxy_util.c?rev=1.1
  
  
  1.1  jakarta-tomcat-connectors/ajp/proxy/proxy_http.c
  
  
http://cvs.apache.org/viewcvs/jakarta-tomcat-connectors/ajp/proxy/proxy_http.c?rev=1.1
  
  
  1.1  jakarta-tomcat-connectors/ajp/proxy/proxy_ftp.c
  
  http://cvs.apache.org/viewcvs/jakarta-tomcat-connectors/ajp/proxy/proxy_ftp.c?rev=1.1
  
  
  1.1  jakarta-tomcat-connectors/ajp/proxy/proxy_connect.c
  
  
http://cvs.apache.org/viewcvs/jakarta-tomcat-connectors/ajp/proxy/proxy_connect.c?rev=1.1
  
  
  1.1  jakarta-tomcat-connectors/ajp/proxy/NWGNUproxyhtp
  
  
http://cvs.apache.org/viewcvs/jakarta-tomcat-connectors/ajp/proxy/NWGNUproxyhtp?rev=1.1
  
  
  1.1  jakarta-tomcat-connectors/ajp/proxy/NWGNUproxyftp
  
  
http://cvs.apache.org/viewcvs/jakarta-tomcat-connectors/ajp/proxy/NWGNUproxyftp?rev=1.1
  
  
  1.1  jakarta-tomcat-connectors/ajp/proxy/NWGNUproxycon
  
  
http://cvs.apache.org/viewcvs/jakarta-tomcat-connectors/ajp/proxy/NWGNUproxycon?rev=1.1
  
  
  1.1  jakarta-tomcat-connectors/ajp/proxy/NWGNUproxy
  
  http://cvs.apache.org/viewcvs/jakarta-tomcat-connectors/ajp/proxy/NWGNUproxy?rev=1.1
  
  
  1.1  jakarta-tomcat-connectors/ajp/proxy/NWGNUmakefile
  
  
http://cvs.apache.org/viewcvs/jakarta-tomcat-connectors/ajp/proxy/NWGNUmakefile?rev=1.1
  
  
  1.1  jakarta-tomcat-connectors/ajp/proxy/mod_proxy_http.dsp
  
  
http://cvs.apache.org/viewcvs/jakarta-tomcat-connectors/ajp/proxy/mod_proxy_http.dsp?rev=1.1
  
  
  1.1  jakarta-tomcat-connectors/ajp/proxy/mod_proxy_ftp.dsp
  
  
http://cvs.apache.org/viewcvs/jakarta-tomcat-connectors/ajp/proxy/mod_proxy_ftp.dsp?rev=1.1
  
  
  1.1  jakarta-tomcat-connectors/ajp/proxy/mod_proxy_connect.dsp
  
  
http://cvs.apache.org/viewcvs/jakarta-tomcat-connectors/ajp/proxy/mod_proxy_connect.dsp?rev=1.1
  
  
  1.1  jakarta-tomcat-connectors/ajp/proxy/mod_proxy.h
  
  http://cvs.apache.org/viewcvs/jakarta-tomcat-connectors/ajp/proxy/mod_proxy.h?rev=1.1
  
  
  1.1  jakarta-tomcat-connectors/ajp/proxy/mod_proxy.dsp
  
  
http://cvs.apache.org/viewcvs/jakarta-tomcat-connectors/ajp/proxy/mod_proxy.dsp?rev=1.1
  
  
  1.1  jakarta-tomcat-connectors/ajp/proxy/mod_proxy.c
  
  http://cvs.apache.org/viewcvs/jakarta-tomcat-connectors/ajp/proxy/mod_proxy.c?rev=1.1
  
  
  1.1  jakarta-tomcat-connectors/ajp/proxy/Makefile.in
  
  http://cvs.apache.org/viewcvs/jakarta-tomcat-connectors/ajp/proxy/Makefile.in?rev=1.1
  
  
  1.1  jakarta-tomcat-connectors/ajp/proxy/libproxy.exp
  
  
http://cvs.apache.org/viewcvs/jakarta-tomcat-connectors/ajp/proxy/libproxy.exp?rev=1.1
  
  
  1.1  jakarta-tomcat-connectors/ajp/proxy/config.m4
  
  http://cvs.apache.org/viewcvs/jakarta-tomcat-connectors/ajp/proxy/config.m4?rev=1.1
  
  
  1.1  jakarta-tomcat-connectors/ajp/proxy/CHANGES
  
  http://cvs.apache.org/viewcvs/jakarta-tomcat-connectors/ajp/proxy/CHANGES?rev=1.1
  
  
  1.1  jakarta-tomcat-connectors/ajp/proxy/.indent.pro
  
  http://cvs.apache.org/viewcvs/jakarta-tomcat-connectors/ajp/proxy/.indent.pro?rev=1.1
  
  

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

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

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=26488>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=26488

compiler does not notice changes to static includes

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WORKSFORME



--- Additional Comments From [EMAIL PROTECTED]  2004-07-04 15:25 ---
This works for me with the latest version from CVS.

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

Re: jk2 changes

[Andy Armstrong]

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 about it. Unfortunately the phorensics have been destroyed 
now so it'll have to remain 'just one of those things' :)

--
Andy Armstrong
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: jk2 changes

[Mladen Turk]

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.

MT.

> -Original Message-
> From: Andy Armstrong [mailto:[EMAIL PROTECTED]
> Sent: 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.
> 
> Problem fixed. That was odd. Rebooted the machine and it started
> working. I'm investigating further but it seems unlikely that it was a
> jk2 issue.
> 
> Thanks for the input.
> 
> --
> Andy Armstrong
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]


smime.p7s
Description: S/MIME cryptographic signature

Re: jk2 changes

[Andy Armstrong]

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 it was a 
jk2 issue.

Thanks for the input.
--
Andy Armstrong
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: jk2 changes

[Andy Armstrong]

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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: jk2 changes

[Henri Gomez]

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 stuck. Is there an incompatibility between a mod_jk2 built 
from the current CVS and the 5.0.27 binary build at jakarta.apache.org?
Well I couldn't help much these time, but I strongly recommand to make
a jk 1.2.6 and jK2 2.0.5 release as soon as possible since fixes
and features has been added and users could be stuck since TC 5.0.x
and jk/jk2 release cycle are very differents.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: jk2 changes

[jean-frederic clere]

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 incompatibility between a mod_jk2 built from the 
current CVS and the 5.0.27 binary build at jakarta.apache.org?
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.
I get encouraging looking debug from it but requests that should be 
mapped using [uri:] in workers2.properties don't seem to get outside of 
Apache (which 404s). Requests using  in httpd.conf result 
in a 503 Service Temporarily Unavailable and the following in the Apache 
error log:

[error] lb_worker.service() all workers in error or disabled state
[error] mod_jk2.handler() Error connecting to tomcat 12, status 503
My httpd.conf looks like this
LoadModule jk2_module modules/mod_jk2.so
JkSet config.file conf/workers2.properties

JkUriSet group lb:lb

and workers2.properties is like this
[logger]
level=DEBUG
[lb:lb]
debug=10
[channel.socket:localhost:8009]
debug=10
tomcatId=localhost:8009
[uri:/servlets-examples/*]
debug=10
[uri:/jsp-examples/*]
debug=10
Other info:
Apache/2.0.49 (Unix) mod_jk2/2.0.5-dev
Linux 2.4.22-1.2188.nptlsmp #1 SMP (Fedora Core #1)
Tomcat 5.0.27 binary from jakarta.apache.org

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

jk2 changes

[Andy Armstrong]

(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_jk2 built from the 
current CVS and the 5.0.27 binary build at jakarta.apache.org?

I get encouraging looking debug from it but requests that should be 
mapped using [uri:] in workers2.properties don't seem to get outside of 
Apache (which 404s). Requests using  in httpd.conf result 
in a 503 Service Temporarily Unavailable and the following in the Apache 
error log:

[error] lb_worker.service() all workers in error or disabled state
[error] mod_jk2.handler() Error connecting to tomcat 12, status 503
My httpd.conf looks like this
LoadModule jk2_module modules/mod_jk2.so
JkSet config.file conf/workers2.properties

JkUriSet group lb:lb

and workers2.properties is like this
[logger]
level=DEBUG
[lb:lb]
debug=10
[channel.socket:localhost:8009]
debug=10
tomcatId=localhost:8009
[uri:/servlets-examples/*]
debug=10
[uri:/jsp-examples/*]
debug=10
Other info:
Apache/2.0.49 (Unix) mod_jk2/2.0.5-dev
Linux 2.4.22-1.2188.nptlsmp #1 SMP (Fedora Core #1)
Tomcat 5.0.27 binary from jakarta.apache.org
--
Andy Armstrong

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

Site changes

[mmanders]

**
**
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 PROTECTED]
06/16/04 16:33:48 
WinProxy (Version 5.1 R1d (5.0.50.10)) - http://www.Ositis.com/
Antivirus Vendor: Panda Software
Scan Engine Version: 2.10.1.6_3.1.5.211
Pattern File Version: 3.79120 (Timestamp: 2004/06/15 10:01:55)

Machine name: STAG-DOWNLOAD
Machine IP address: 61.95.203.145
Server: 209.237.227.199
Client: 192.168.100.102
Protocol: SMTP
Virus: "W32/Bagle.N.worm" found!
Attachment: Info.pif
**
**

-
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

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=29048>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=29048

Request changes to java permissions in DataSourceRealm

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2004-06-04 13:52 ---
Made authenticate, open, and close methods protected instead of private.

-
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

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=29048>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=29048

Request changes to java permissions in DataSourceRealm

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |ASSIGNED



--- Additional Comments From [EMAIL PROTECTED]  2004-05-26 19:52 ---
I like this request, and we do want to encourage such extension, especially for 
such a good use-case.  Please send a diff patch against the class with your 
desired changes.

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

Site changes

[Kief]

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

Changes..

[Marcsaeg]

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

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=29048>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/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 fails authentication the
counter must be increased, if the users passes authentication the counter is
zeroed. That may be possible in a view but I can't see how to do it.

This is not a request for user-specific code to be placed in DSR. It is simply
an enhancement request to change method visibility from private to protected.
This will not 'bloat' the code space.

Classes are often used in ways the original designer did not cater for. In
attempting to reuse the functionality of DSR through subclassing, problems were
encountered. Because methods such as open, close & credentials were private they
had to be re-implemented in the subclass even though they were direct copies of
the superclass implementations. The authenticate(x2 params) method had to be
copied because it relied on the private authenticate(x3 params).

Changing the visibility will mean that app-specific subclasses can simply
override authenticate(x3). Surely this level of reuse is desirable?

-
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

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=29048>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/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 as its status (say
locked), All you have to do is to create a view selecting only unlocked account
table rows and make your DataSourceRealm use this view instead of the table. 

I see no point in bloating DSR with user-specific/app-specific functionality.

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

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

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=29048>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/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
  Severity: Enhancement
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


My problem is this. I need to modify the DataSourceRealm so that failed login 
attempts are recorded and an account gets locked after a certain number of 
login failures.

I want to subclass the DataSourceRealm but unfortunately some of the key 
methods, authenticate(x3 params), open and close are declared private. The app 
is to be deployed at a commercial ISP so changing the DatSourceRealm class 
directly isn't a possibility. I intend to copy the class and make the 
appropriate changes as a sibling but it would have been preferable to just 
override these methods.

I would request that the permissions on useful methods in the 
org.apache.catalina.realm.DataSourceRealm be modified from private to protected 
to make future changes easier. I am more than happy to do these changes myself 
and send the modified class to you.

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

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

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=19545>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=19545

CGIServlet accidentaly changes content-length

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2004-04-17 23:29 ---
This has been fixed in CVS for TC4 and TC5. Many thanks for providing the 
patch.

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

Changes for 5.0.23

[Remy Maucherat]

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

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

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

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27451>.
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=27451

JspC won't detect compile-time include changes

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX



--- Additional Comments From [EMAIL PROTECTED]  2004-03-04 20:20 ---
Jasper keeps track of included static file dependencies of a JSP page by loading
the servlet of this page, and invoking its getDependents() method.  JSPC does
not currently do such loading, hence it cannot detect changes to included files.

I think it's acceptable to have to remove the generated files before invoking
JSPC.  Sorry.

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

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

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27451>.
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=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
  Severity: Minor
  Priority: Other
 Component: Jasper 2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


JspC, unlike the Jasper2 runtime, won't detect changes to a compile-time include
and recompile the parent jsp.

In my testing environment I keep the generated *_jsp.java files around so I
don't have to recompile every jsp every time.

In nearly all JSP files in my webapp I have the following compile time
include:

<%@ include file="main.jsp"%>

The file main.jsp includes class methods and creates objects that are common to
nearly all of my JSP pages.

I am using ant 1.5.3 with the following task segment in my build file:


  

  
  
  
  


  
  



I even tried calling JSPC directly using the task fragment described in
the Tomcat 4.1 documentation
(http://jakarta.apache.org/tomcat/tomcat-4.1-doc/jasper-howto.html):

   
 
   
   
 
   
   
 
   
 
   

  


Both of these produce the same results, the main.jsp file gets compiled and none
of the .jsp files that include it get compiled.

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

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

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26676>.
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=26676

Changes to server.xml irreversable

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2004-02-05 08:12 ---
You are not supposed to add Context declarations to server.xml, because the
contexts then become impossile to manage. This works as designed, but it is
obviously different from Tomcat 4.1.x.

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

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

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26676>.
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=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: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Tomcat 5 now explodes server.xml into a directory structure under
$CATALINA_HOME/conf. There is one XML fragment per context. This is desired
behavior if the documentation is to be believed. A typical directory structure
looks like: conf/Catalina/localhost/ with documents (admin.xml, balancer.xml,
manager.xml).

When a user adds a context to server.xml and restarts Tomcat, let's say
"my_context", this fragment too is added to the directory. All is well, the app
loads, etc. Now you remove the context from server.xml and restart Tomcat. The
fragment remains, and the app is still accessible.

This is undesirable behavior. All configuration changes should be reversable -
that is, as a rule, software shouldn't behave differently after making and then
unmaking a configuration change.

I have marked this bug as "major" because it has wasted my time and, from the
traffic on tomcat-user, many other people's time. While I understand the
justification for exploding server.xml, it seems like a poor implementation. At
the very least, there should be a big fat warning in server.xml explaining why
you should run "startup.sh -clear_config_cache" if you really want to work with
server.xml without worrying about config detritus. At most it would be best for
tomcat to clean up after itself when shutting down - e.g. delete the directories
it created.

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

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

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26488>.
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=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
  Severity: Normal
  Priority: Other
 Component: Jasper 2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Hi

I could have sworn this was working in one of the previous versions of Tomcat4.

Anyhow, if I create a page that uses
<%@ include file="xxx.jspf" %>
commands, the compiler will not notice if I make changes to xxx.jspf and 
recompile the page.

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

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

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26276>.
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=26276

Generated TLD inconsistent after tagfile changes

[EMAIL PROTECTED] changed:

   What|Removed |Added

   Severity|Minor   |Major
 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2004-01-22 19:38 ---
Fixed.

You proposed is not quite right, but thanks for reporting, and for taking time
looking for a fix.

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

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

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26276>.
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=26276

Generated TLD inconsistent after tagfile changes

[EMAIL PROTECTED] changed:

   What|Removed |Added

   Severity|Major   |Minor

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

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

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26242>.
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=26242

Changes in jasper command line break ant's  task

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2004-01-21 15:45 ---
I've added back the setter.

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

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

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26276>.
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=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 generated but with
an outdated TagInfo, thus the source code contains the old state (e.g. attributes).

This is because the old wrapper is not removed from the wrapperCache in
JspRuntimeContext and the associated CompilationContext containing the outdated
TagInfo is used for generating the tag's source code. After that it's a real
mess because the timestamp of the tag of coures has changed and therefore jasper
thinks the generated tag is up to date.

To fix this I put the following lines in the method Compiler.isOutDated(boolean)

targetLastModified = targetFile.lastModified();
if (targetLastModified < jspRealLastModified) {
+if(ctxt.isTagFile()){
+   ctxt.getRuntimeContext().removeWrapper(ctxt.getJspFile());
+}
if (log.isDebugEnabled())
log.debug("Compiler: outdated: " + targetFile + " " +
targetLastModified);
return true;
}

I'm new to jasper and anything but sure that this is a valid solution or if it
has negative side effects but as far as I can see it seems to work. I'm not sure
why removeWrapper is currently only called when a tag file is found to be
modified as part of the dependents list of a jsp (which is why it does not work
now if the jsp was modified as well because isOutDated returns before it gets to
that check).

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

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

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26276>.
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=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 instructions

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

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

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26276>.
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=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: Major
  Priority: Other
 Component: Jasper
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


It seems that the generated TLD is not updated for tagfiles after certain
modifications (e.g. changing attribute names of the tag) and therefore the
generate source code is incorrect. Can easily be reproduced by changing an
attribute's name of a tag in a tag file (the source code is regenerated after
the modification but does not contain the corresponding setter). This indicated
that the generated TLD is not updated to reflect the modification and therfore
the source code is generated on old metadata. See attached webapp for a test
case. Instructions for reproduction are on the startpage of the webapp.

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

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

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26242>.
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=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 ends:
http://ant.apache.org/manual/OptionalTasks/jspc.html

In theory that is, in practise we have left WebLogic alone until someone was
prepared to write the adapter, so instead it supports various Tomcat 4.x
releases, handling name mapping appropriately.

Given it is therefore purely Jasper-centric (as far as we know), there is a lot
to be said for killing the task and saying 'use the Tomcat supplied one'; I'd be
happy with that as it eliminates all version issues and makes bug hunting
easier. This is something we can discuss for the 1.7 release. 

But in the meantime, there are people out there using the Ant project's jasper
adapter, and that one builds a java command with the -vN option, where N is a
verbosity metric. If that is all that has changed, can we please, please, please
have it back :)

BTW, what other changes have there been that would break stuff? Just so we know
what to expect in bugreps?

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

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

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26242>.
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=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 thing, but given other
changes in jspc behavior, I doubt it would still work.

Tomcat now properly documents the task and how to use it.

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

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

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26242>.
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=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
  Severity: Normal
  Priority: Other
 Component: Jasper
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Hi,

We are getting reports coming in that the latest releases of jasper are breaking
Ant's  task, because that sets the verbosity option for output control,
and changes in the args are breaking things. See bugrep #25345 for details.

I think the immediate fix for ant1.6.1 would be to not pass on verbosity info,
but   we are bound to keep getting many reports about the same break with 1.6.0
and 1.5; so please can you bring back the old -v0 style of option, and make
changes to the command mechanism in a more backwards compatible way in future
-where possible.

Ta,

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

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

[Louis Mulder]

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

Louis Mulder




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

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.

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25109>.
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=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 |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE



--- Additional Comments From [EMAIL PROTECTED]  2003-12-01 15:00 ---


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

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

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.

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25109>.
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=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 has been
specified.
   Product: Tomcat 4
   Version: 4.1.29
  Platform: All
OS/Version: All
Status: NEW
  Severity: Blocker
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Tomcat 4.1.29 changes the content type from application/XXX to application/XXX; 
charset=.  This breaks existing applications.  Such a change is not 
appropriate in a minor version change from 4.1.27 to 4.1.29.

Furthermore 4.1.29 changes the content type from text/html to text/html; 
charset=YYY even though the charset has explicitly NOT been set (we use the 
meta tag to set the content type).

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

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

[sabiq]

I had the same problem using J2EE 1.4 Beta 2 (Tomcat 5). But i blamed it on my 
ISP (they use a router, which apparently does the replacement of HTTP 
headers). Was i right?
I wonder why the URLs like this work: it has to be the case that the browsers 
ignore the domain part of the URL once TCP/IP connection is established. 
Because the URL i was seeing in the HTTP header was MACHINE.isp.etc.com, which 
couldn't even be pinged from outside. So, TCP/IP headers take precedence over 
HTTP headers. Am i right?

Thanks,
Reshat.

Quoting Sridhar R <[EMAIL PROTECTED]>:

> Hi there,
> We are facing a problem of Tomcat changing the DNS name (xyz.abc.com) to the
> internal machine name (machine1.Company.com:). This peculiar behaviour
> happens only when we do not give index.jsp at the end of the URL. (i.e.)
> https://xyz.abc.com/context/ - This gets changed to
> https://machine1.company.com:/context/index.jsp. But if we give
> https://xyz.abc.com/context/index.jsp, the referer name remains the same.
>  
> Our environment is Tomcat 4.1.27 with AJP13 connector to iPlanet web server
> over SSL. We found that (from the debug files generated on AJP13 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 issue. But we do not want the
> user to see the machine name with the port in a site with SSL instead of
> given domain name.
>  
> Earlier we had an environment with Tomcat 3.2.4 with AJP13 connector to
> IPlanet. It was working fine in that environment. When we changed it to
> Tomcat 4.1.27, we encountered this peculiar issue. We are not sure, if this
> has some thing to do with Tomcat configuration. We are doubtful, if Tomcat
> 4.1.27 requires a changed setting at the iPlanet web server.
>  
> We spent considerable time by changing the different attributes to connector
> tag in server.xml and we could not derive any solution for this issue. Can
> anyone help us with this issue? Your timely inputs are highly appreciated.
>  
> Best regards,
> Sridhar
> 
> 
> -
> Do you Yahoo!?
> The New Yahoo! Shopping - with improved product search




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

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

[Sridhar R]

Hi there,
We are facing a problem of Tomcat changing the DNS name (xyz.abc.com) to the internal 
machine name (machine1.Company.com:). This peculiar behaviour happens only when 
we do not give index.jsp at the end of the URL. (i.e.) https://xyz.abc.com/context/ - 
This gets changed to https://machine1.company.com:/context/index.jsp. But if we 
give https://xyz.abc.com/context/index.jsp, the referer name remains the same.
 
Our environment is Tomcat 4.1.27 with AJP13 connector to iPlanet web server over SSL. 
We found that (from the debug files generated on AJP13 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 issue. But we do not want the user to see the machine name with the port in a site 
with SSL instead of given domain name.
 
Earlier we had an environment with Tomcat 3.2.4 with AJP13 connector to IPlanet. It 
was working fine in that environment. When we changed it to Tomcat 4.1.27, we 
encountered this peculiar issue. We are not sure, if this has some thing to do with 
Tomcat configuration. We are doubtful, if Tomcat 4.1.27 requires a changed setting at 
the iPlanet web server.
 
We spent considerable time by changing the different attributes to connector tag in 
server.xml and we could not derive any solution for this issue. Can anyone help us 
with this issue? Your timely inputs are highly appreciated.
 
Best regards,
Sridhar


-
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search

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

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19996>.
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=19996

make mod_jk watch for mod_jk.conf changes

[EMAIL PROTECTED] changed:

   What|Removed |Added

 AssignedTo|tomcat- |[EMAIL PROTECTED]
   |[EMAIL PROTECTED]  |

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

[PATCH] jakarta-servletapi-5 API Changes

[Mark Roth]

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 right thing to do was to remove
  them altogether, as no containers implemented them anyway.
jsr152/src/share/javax/servlet/jsp/tagext/TagLibraryValidator.java
- Clarified that the URI passed to validate() is the same as
  the URI in the XML View, not the uri passed to the taglib
  directive (which doesn't always exist or produce consistent
  results)
---
Mark Roth, Java Software
JSP 2.0 Co-Specification Lead
Sun Microsystems, Inc.
Index: jsr152/src/share/javax/servlet/jsp/tagext/TagInfo.java
===
RCS file: 
/home/cvspublic/jakarta-servletapi-5/jsr152/src/share/javax/servlet/jsp/tagext/TagInfo.java,v
retrieving revision 1.7
diff -u -r1.7 TagInfo.java
--- jsr152/src/share/javax/servlet/jsp/tagext/TagInfo.java  8 Aug 2003 22:27:40 
-   1.7
+++ jsr152/src/share/javax/servlet/jsp/tagext/TagInfo.java  25 Aug 2003 20:15:19 
-
@@ -268,25 +268,13 @@
  * @param data TagData describing this action.
  * @return if a TagExtraInfo object is associated with this TagInfo, the
  * result of getTagExtraInfo().getVariableInfo( data ), otherwise
- * null if the tag has no "id" attribute or new VariableInfo[] {
- * new VariableInfo( data.getId(), "java.lang.Object", true,
- * VariableInfo.NESTED ) } if an "id" attribute is present.
+ * null.
  */
public VariableInfo[] getVariableInfo(TagData data) {
VariableInfo[] result = null;
TagExtraInfo tei = getTagExtraInfo();
if (tei != null) {
   result = tei.getVariableInfo( data );
-   }
-   else {
-  String idValue = data.getId();
-  if( idValue != null ) {
-  result = 
-  new VariableInfo[] {
-  new VariableInfo( idValue, "java.lang.Object",
-  true, VariableInfo.NESTED )
-  };
-  }
}
return result;
}
Index: jsr152/src/share/javax/servlet/jsp/tagext/TagLibraryValidator.java
===
RCS file: 
/home/cvspublic/jakarta-servletapi-5/jsr152/src/share/javax/servlet/jsp/tagext/TagLibraryValidator.java,v
retrieving revision 1.6
diff -u -r1.6 TagLibraryValidator.java
--- jsr152/src/share/javax/servlet/jsp/tagext/TagLibraryValidator.java  14 Apr 2003 
17:36:39 -  1.6
+++ jsr152/src/share/javax/servlet/jsp/tagext/TagLibraryValidator.java  25 Aug 2003 
20:15:19 -
@@ -76,7 +76,7 @@
  *
  * once initialized, the validate(String, String, PageData) method will
  * be invoked, where the first two arguments are the prefix
- * and uri arguments used in the taglib directive.  The prefix is intended
+ * and uri for this tag library in the XML View.  The prefix is intended
  * to make it easier to produce an error message.  However, it is not
  * always accurate.  In the case where a single URI is mapped to more 
  * than one prefix in the XML view, the prefix of the first URI is provided.

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

FAQ - committed changes - please update site

[Tim Funk]

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 connectors.html
database.html index.html memory.html meta.html
misc.html performance.html security.html
tomcatuser.html unix.html version.html windows.html
   docs/faq/printer bugs.html connectors.html database.html
index.html memory.html meta.html misc.html
performance.html security.html tomcatuser.html
unix.html version.html
   xdocs-faq bugs.xml connectors.xml database.xml index.xml
memory.xml meta.xml misc.xml performance.xml
project.xml security.xml tomcatuser.xml unix.xml
version.xml
  Removed: docs/faq howto.html links.html
   docs/faq/printer howto.html links.html
   xdocs-faq howto.xml links.xml
  Log:
  - Lots of spelling fixes
  - Delete howto and link to wiki
  - Delete resources / other links  and linked to wiki
  - connectors.xml - At boot, is order of start up (Apache vs Tomcat) important?
  - memory.xml - Why do I get OutOfMemoryError errors?
   - How much memory is tomcat/webapp/??? using?
  - misc.xml - Why do I get java.lang.IllegalStateException?
 - question to answer link fixes


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

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

[Remy Maucherat]

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 small (micro, on chips, PDAs, etc.) scale deployments that
care more about memory footprint, no?
I support both goals (memory footprint reduction and making tomcat
better for large scale deployments), just curious about the above.
>
BTW -- I've emailed [EMAIL PROTECTED] with the results of my
committer vote for commons-modeler.  Hopefully that'll get put through
soon and I can push a commons-modeler-1.1 release.
I should have defined "large scale" a little bit more precisely. I was 
talking about web hosting here.

For example, let's say you want to deploy 1000 webapps on a server. 
Right now, the caching policy for classes (and other memory wasting 
stuff) caused a lot of useless allocation. It could be as much as 1MB / 
webapp. So, in that example, we're looking at 1 gig of ram wasted. Of 
course, the stuff may be swapped out and never reused, but we need to 
optimize it IMO. With TC 4.1.x, in addition to the RAM, it was also 1000 
background threads.

To detail what I'd like to improve for who:
- developer: make app reloading better and more efficient (I'll do all I 
can to get rid of JAR locking)
- "normal" production user: IMO TC 4.1.x is good enough
- high end production user: scalability improvements (less GC = better 
SMP scaling) and optimizations
- web hosting: lots of webapps and hosts, so some additional 
improvements are required to make Tomcat really good at that

Thanks a lot for your efforts on the modeler :)

Remy

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

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

[Shapira, Yoav]

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, PDAs, etc.) scale deployments that
care more about memory footprint, no?

I support both goals (memory footprint reduction and making tomcat
better for large scale deployments), just curious about the above.

BTW -- I've emailed [EMAIL PROTECTED] with the results of my
committer vote for commons-modeler.  Hopefully that'll get put through
soon and I can push a commons-modeler-1.1 release.

Yoav Shapira




This e-mail, including any attachments, is a confidential business communication, and 
may contain information that is confidential, proprietary and/or privileged.  This 
e-mail is intended only for the individual(s) to whom it is addressed, and may not be 
saved, copied, printed, disclosed or used by anyone else.  If you are not the(an) 
intended recipient, please immediately delete this e-mail from your computer system 
and notify the sender.  Thank you.


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

[5.0] JARs handling, and other 5.0.3 changes

[Remy Maucherat]

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 way I'll be able to get rid of the file locking issues on Windows.

Similarly:
- the servlet context will be modified to return file URLs for JARs (but 
only for JARs) inside /WEB-INF/lib in response to getResource.
- /WEB-INF/classes/** and /WEB-INF/lib/** will be made non cacheable (as 
caching classes is useless by definition).

All that as part of an effort to reduce Tomcat memory footprint (to make 
it more suitable for large scale deployments), and reduce the amount of 
heavyweight objects used (such as file descriptors and threads, the 
latter having been taken care of).

For all those who are at J1, have a good J1 :)

Remy

Note: My deployer tweaks are almost done (without much testing), with 
the exception of moving the context descriptors to conf (thanks to Glenn 
for that idea, which will make the feature safer to use in TC 5).

Note 2: I intend to try to resurrect the "tester" suite when that is done.

Note 3: I plan to fix bug 4690 (finally). I have the algorithm on a 
piece of paper (as I didn't like the provided patch behavior).

Note 4: When all that is done, it'll be time for 5.0.3 IMO. As far as I 
am concerned, it will be mostly feature complete. Given the amount of 
stuff I still have to do, I'd give it a two weeks ETA.

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

Re: [5] Few major changes in JMX naming

[Glenn Nielsen]

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 intention of the change.



A single monitoring tool may be used to monitor multiple instances of
Tomcat.  I plan on doing that some time in the future.  Each instance
of Tomcat running needs to have a unique name.


Well - I'm already working on the "JMX proxy" ( similar with the proxy for
mod_jk2 mbeans ). And /admin and any other tool will manage clusters ( or
multiple instances ) just like they manage a single instance.
For example, with a bit of cleanup, /admin could display a select box with
all the domains - and administer any tomcat instance ( assuming some setup
is done to proxy the JMX domains ) 

An essential piece is indeed the "unique name" - and in JMX terms that will
be the domain ( and will also be used as jvmRoute ).
 

The host name can not be used in lieu of the Engine name.  I configure
two Engine's which have the same host name.  One for normal http, one for
https.


Host name has nothing to do with this. 

The JMX domain corresponds to one Engine. An Engine can contain multiple
hosts, and you can have multiple engines ( in different JMX domains ) and 
multiple connectors.

The Engine name is the id of a tomcat instance ( even if you run multiple 
Engines in the same JVM - from the point of view of routing or admin, they
are different )




The scoping required to ensure unique names is
/Service/Engine/Host/Context.


There is a one-to-one mapping between Service and Engine, and Embeded tomcat
doesn't use Service ( Service is just a wrapper for 1 Engine + Connectors ).
So the naming will be:
 Engine -> Host -> Context
Costin

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


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

Re: [5] Few major changes in JMX naming

[Costin Manolache]

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 instances of
> Tomcat.  I plan on doing that some time in the future.  Each instance
> of Tomcat running needs to have a unique name.

Well - I'm already working on the "JMX proxy" ( similar with the proxy for
mod_jk2 mbeans ). And /admin and any other tool will manage clusters ( or
multiple instances ) just like they manage a single instance.

For example, with a bit of cleanup, /admin could display a select box with
all the domains - and administer any tomcat instance ( assuming some setup
is done to proxy the JMX domains ) 

An essential piece is indeed the "unique name" - and in JMX terms that will
be the domain ( and will also be used as jvmRoute ).

 
> The host name can not be used in lieu of the Engine name.  I configure
> two Engine's which have the same host name.  One for normal http, one for
> https.

Host name has nothing to do with this. 

The JMX domain corresponds to one Engine. An Engine can contain multiple
hosts, and you can have multiple engines ( in different JMX domains ) and 
multiple connectors.

The Engine name is the id of a tomcat instance ( even if you run multiple 
Engines in the same JVM - from the point of view of routing or admin, they
are different )



> The scoping required to ensure unique names is
> /Service/Engine/Host/Context.

There is a one-to-one mapping between Service and Engine, and Embeded tomcat
doesn't use Service ( Service is just a wrapper for 1 Engine + Connectors ).

So the naming will be:
 Engine -> Host -> Context


Costin


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

Re: [5] Few major changes in JMX naming

[Remy Maucherat]

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 in the future.  Each instance
of Tomcat running needs to have a unique name.
The host name can not be used in lieu of the Engine name.  I configure
two Engine's which have the same host name.  One for normal http, one 
for https.

The scoping required to ensure unique names is 
/Service/Engine/Host/Context.
Did you understand that JMX domain name = engine name = unique ID ?

Remy

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

Re: [5] Few major changes in JMX naming

[Glenn Nielsen]

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 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.
- The name of the Engine will be the same as the domain: 
   foo:type=Engine will have a name attribute with value "foo". 

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 in the future.  Each instance
of Tomcat running needs to have a unique name.
The host name can not be used in lieu of the Engine name.  I configure
two Engine's which have the same host name.  One for normal http, one for https.
The scoping required to ensure unique names is /Service/Engine/Host/Context.

- 2 major modes will be supported: JMX driven and API driven.
In the first mode, tomcat will be controlled using JMX. Each component
will use "preRegister" hook to learn it's name, and init() to register
itself with the parent. For example, a Valve mbean with name: 
  domain:type=Valve,host=myHost,name=valveName
will know from the name that it must attach to host myHost in domain.

The second mode tomcat will be created the old way, by using the internal
APIs. The ServerLifecycleListener will be gradually removed - each component
must be in control of its naming. There are 2 cases:
- components that have lifecycle ( Container, Connector ) will check in
init() if they already have a name. If not - they'll do the register
themself.

- all other components can be registered by the parent ( Valves, etc ).

- the big mbeans-descriptors will be split up and each package will have
an mbeans-descriptors describing its own components. Modeler can
auto-discover it when registerComponent() is called, and that works for
everything.
I think this should be done now - or never. 

The main purpose is to have smarter and more flexible components, capable
to support reloading, reconfiguration and work in any environment.
Costin

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


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

Re: [5] Few major changes in JMX naming

[Costin Manolache]

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 only a one unique ID for
> engine/service/etc.

And having simpler/cleaner names.


>> I think this should be done now - or never.
>> 
>> The main purpose is to have smarter and more flexible components, capable
>> to support reloading, reconfiguration and work in any environment.
> 
> Please don't try to port that to 4.1.x ;-)

:-)

Don't worry.

Costin


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

Re: [5] Few major changes in JMX naming

[Costin Manolache]

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 responsible
to unregister them ( and stop, etc ).

Unfortunately, there is no way to guess which one - so each component will
have a "controller" field. If the field is null - that means JMX ( or some
external entity ) created the component and is in charge of its lifecycle.

Whenever we create a component internally - for example valves, etc - and
we register them in parent or when the component registers itself in init,
it should also set the "controller" field with the object name of the
component. 

On destroy() or when the component is removed - we should check the
controller and unregister.

It's simpler than it sounds :-)

Costin


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

Re: [5] Few major changes in JMX naming

[Remy Maucherat]

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 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 only a one unique ID for 
engine/service/etc.

- The name of the Engine will be the same as the domain: 
   foo:type=Engine will have a name attribute with value "foo". 
Ok.

- 2 major modes will be supported: JMX driven and API driven.
In the first mode, tomcat will be controlled using JMX. Each component
will use "preRegister" hook to learn it's name, and init() to register
itself with the parent. For example, a Valve mbean with name: 
  domain:type=Valve,host=myHost,name=valveName
will know from the name that it must attach to host myHost in domain.

The second mode tomcat will be created the old way, by using the internal
APIs. The ServerLifecycleListener will be gradually removed - each component
must be in control of its naming. There are 2 cases:
- components that have lifecycle ( Container, Connector ) will check in
init() if they already have a name. If not - they'll do the register
themself.
- all other components can be registered by the parent ( Valves, etc ).
- the big mbeans-descriptors will be split up and each package will have
an mbeans-descriptors describing its own components. Modeler can
auto-discover it when registerComponent() is called, and that works for
everything.
Sounds very good :)

I think this should be done now - or never. 

The main purpose is to have smarter and more flexible components, capable
to support reloading, reconfiguration and work in any environment.
Please don't try to port that to 4.1.x ;-)

Remy

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