Re: JavaOne volunteers?

2005-06-17 Thread Amy Roh

Tim Funk wrote:


I can sit around for 2 or 3 hours.


Me too...

Amy



-Tim

Henri Yandell wrote:


Unsure if the Tomcat community saw Geir's email asking for volunteers
at JavaOne.

The ASF have a booth there (donated to us) if we can get people to man
it etc. Given that it's the flagship product, will any Tomcat people
be interested in volunteering?

I think the idea is to spend 2 or 3 hours sitting at the desk etc,
being positive about Tomcat, ASF, Open-Source etc on June 27th-29th.

Wish I could convince my bosses to let me head out there :(
 



-
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: [RESULT] PMC Chair

2005-04-01 Thread Amy Roh
Remy Maucherat wrote:
Henri Yandell wrote:
19 votes were recorded, and thus the proposed Tomcat PMC is:
Keith Wannamaker (keith)
Mark Thomas (markt)
Larry Isaacs (larryi)
Filip Hanik (fhanik)
Tim Funk (funkman)
Kin-man Chung (kinman)
Henri Gomez (hgomez)
Mladen Turk (mturk)
Costin Manolache (costin)
Jim Jagielski (jim)
Bill Barker (billbarker)
Ian Darwin (idarwin)
Peter Rossbach (pero)
Kurt Miller (truk)
Glenn Nielsen (glenn)
Jean-Frederic Clere (jfclere)
Amy Roh (amyroh)
Jeanfrancois Arcand (jfarcand)
Remy Maucherat (remm)
Yoav Shapira (yoavs)
The result was:
13 - Remy
 5 - Yoav
 1 - Costin

(that's funny, but I can count 20 people)
It's a fraud!  I demand a recount.  sorry I couldn't help myself.  ;-)
Thanks a lot for taking care of this, which also was a great mechanism 
for determining who would be on the PMC (I don't see Jan Luehe there, 
though, so he would have to be added to the list). And thanks to the 
voters, of course ;)

What's the next step now ?
Rémy
-
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: [VOTE] PMC Chair

2005-03-29 Thread Amy Roh
Hi Hen,
Remy has my vote.
Thanks,
Amy
Henri Yandell wrote:
Just as an update, I've recorded 11 public/private votes from:
Keith Wannamaker (keith)
Mark Thomas (markt)
Larry Isaacs (larryi)
Filip Hanak (fhanak)
Tim Funk (funkman)
Kin-man Chung (kinman)
Henri Gomez (hgomez)  
Mladen Turk (mturk)
Costin Manolache (costin)
Jim Jagielski (jim)
Bill Barker (billbarker)

There are 70 committers, and it's a holiday weekend (4 day weekend in
some places, so not back til Tuesday) so I suspect it's best to keep
the vote open for some more time.
The above, plus Remy and Yoav, would represent the proposed PMC list,
and I'll report on additional votes on Tuesday night.
Hen
-
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: TLP Draft Proposal

2005-03-22 Thread Amy Roh
Didn't we propose TLP a while back ago when we were little?  ;-) 

Anyone remember what happened then?  Just curious...
Thanks,
Amy
Yoav Shapira wrote:
Hi,
Below is a draft of our TLP proposal.  The format is fairly standard, copied
from other recent TLP promotions.  (You can see those in ASF Board meeting
minutes).
I've added all currently active committers to the initial PMC.  If I've
missed anyone, please let me know.
Part of the proposal is the initial PMC Chairman.  I'd like to put myself up
as a candidate, and if anyone else is interested, now's the time to speak
up.  This is a rotating term anyways, so anyone interested who sticks around
long enough will get a chance to wear the hat.
Once we agree on the draft phrasing, we'll have an actual vote.  I believe
that actually takes place on [EMAIL PROTECTED] rather than tomcat-dev?  Are 
there
any active Tomcat committers who are not Jakarta PMC members?  If I were to
guess, maybe Peter anyone else as new?
Yoav
[BEGIN DRAFT PROPOSAL]
X. Establish the Apache Tomcat Project
  WHEREAS, the Board of Directors deems it to be in the best
  interests of the Foundation and consistent with the
  Foundation's purpose to establish a Project Management
  Committee charged with the creation and maintenance of
  open-source software related to the Servlet and Java Server Pages
  specifications, for distribution at no charge to the public.
  NOW, THEREFORE, BE IT RESOLVED, that a Project Management
  Committee (PMC), to be known as the Apache Tomcat PMC, be and
  hereby is established pursuant to Bylaws of the Foundation; and
  be it further
  RESOLVED, that the Apache Tomcat PMC be and hereby is
  responsible for the creation and maintenance of software
  related to creation and maintenance of open-source software
  related to Servlet and Java Server Pages technologies based on
software licensed to the Foundation; and be it further
  RESOLVED, that the office of Vice President, Apache Tomcat be
  and hereby is created, the person holding such office to serve
  at the direction of the Board of Directors as the chair of the
  Apache Tomcat PMC, and to have primary responsibility for
  management of the projects within the scope of responsibility
  of the Apache Tomcat PMC; and be it further
  RESOLVED, that the persons listed immediately below be and
  hereby are appointed to serve as the initial members of the
  Apache Tomcat PMC:
  Jean-Francois Arcand ([EMAIL PROTECTED])
  Bill Barker ([EMAIL PROTECTED])
  Tim Funk ([EMAIL PROTECTED])
  Filip Hanik ([EMAIL PROTECTED])
  Jan Luehe ([EMAIL PROTECTED])
  Costin Manolache ([EMAIL PROTECTED])
  Remy Maucherat ([EMAIL PROTECTED])
  Amy Roh ([EMAIL PROTECTED])
  Peter Rossbach ([EMAIL PROTECTED])
  Yoav Shapira ([EMAIL PROTECTED])
  Mark Thomas ([EMAIL PROTECTED])
  Mladen Turk ([EMAIL PROTECTED])
NOTE: Who am I missing?  Kin-man?  Craig?  Keith?  Others?
 NOW, THEREFORE, BE IT FURTHER RESOLVED, that [XXX]
  be appointed to the office of Vice President, Apache Tomcat, to
  serve in accordance with and subject to the direction of the
  Board of Directors and the Bylaws of the Foundation until
  death, resignation, retirement, removal or disqualification, or
  until a successor is appointed; and be it further
  RESOLVED, that the initial Apache Tomcat PMC be and hereby is
  tasked with the creation of a set of bylaws intended to
  encourage open development and increased participation in the
  Apache Tomcat Project; and be it further
  RESOLVED, that the initial Apache Tomcat PMC be and hereby is
  tasked with the migration and rationalization of the Apache Jakarta
  PMC Tomcat subproject; and be it further
  RESOLVED, that all responsibility pertaining to the Jakarta Tomcat
  sub-project and encumbered upon the Apache Jakarta PMC are
  hereafter discharged.
[END OF DRAFT PROPOSAL]
Yoav Shapira
System Design and Management Fellow
MIT Sloan School of Management / School of Engineering
Cambridge, MA USA
[EMAIL PROTECTED] / [EMAIL PROTECTED]

-
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: I broke this (I think), but I don't know quite why...

2004-11-30 Thread Amy Roh
I'm looking at it now.  I think I know why.  I'll commit the fix into both 
branches when I confirm.

Thanks,
Amy
Shapira, Yoav wrote:
Hi,
As http://issues.apache.org/bugzilla/show_bug.cgi?id=32445 shows, I
apparently broke the admin webapp when I made it compile with Struts 1.2
for Tomcat 5.0.30.  I've looked at it for a bit, and I can't quite
figure out why it's broken or how to fix it quickly, probably because my
Struts knowledge is not where it should be.
The ApplicationResources.properties are where they used to be, properly
packaged in the catalina-admin.jar and on the classpath.  I didn't
change any of the struts config files either.  So I'm a bit puzzled as
to why this is broken and would appreciate hints on a fix.
I remember similar issues, but I forgot the cause, sorry :(
Hopefully I'll remember.
The reason I'm asking now (and copying Amy, my admin webapp guru -- Amy
I hope you don't mind the personal email), is that I made the same code
changes for Tomcat 5.5.5, which is slated to be released in about 48
hours.
Are there similar issues in that branch ?
It works for me (running from my build folder, which doesn't prove much).
Rémy
-
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]


Struts requirement - Re: I broke this (I think), but I don't know quite why...

2004-11-30 Thread Amy Roh
The fix will not be compatible with Struts 1.1.  We'd need to change Struts 
requirement version 1.2 or later.

Vote to require Struts 1.2 or above?
Thanks,
Amy
Shapira, Yoav wrote:
Hi,
As http://issues.apache.org/bugzilla/show_bug.cgi?id=32445 shows, I
apparently broke the admin webapp when I made it compile with Struts 1.2
for Tomcat 5.0.30.  I've looked at it for a bit, and I can't quite
figure out why it's broken or how to fix it quickly, probably because my
Struts knowledge is not where it should be.
The ApplicationResources.properties are where they used to be, properly
packaged in the catalina-admin.jar and on the classpath.  I didn't
change any of the struts config files either.  So I'm a bit puzzled as
to why this is broken and would appreciate hints on a fix.
I remember similar issues, but I forgot the cause, sorry :(
Hopefully I'll remember.
The reason I'm asking now (and copying Amy, my admin webapp guru -- Amy
I hope you don't mind the personal email), is that I made the same code
changes for Tomcat 5.5.5, which is slated to be released in about 48
hours.
Are there similar issues in that branch ?
It works for me (running from my build folder, which doesn't prove much).
Rémy
-
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]


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


Re: TCK questions

2004-11-10 Thread Amy Roh
Here are my findings after talking to compatibility folks.
TCK reports just like the TCK are under NDA and cannot be posted to any 
public website, newsgroup, etc.  Only ASF members who are covered by NDA is 
allowed to see the test results.

Geir is the person who understands this well and is the ASF liason.
The only ASF people that can run the TCKS are those who have the correct 
NDAs.  Geir has this information.  The TCKs cannot be run on a box that is 
accessible by non-NDA ASF members.

Hope this helps.
Thanks,
Amy
- Original Message - 
From: Shapira, Yoav [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Wednesday, November 10, 2004 6:03 AM
Subject: TCK questions


Hi,
I have two questions regarding the Servlet and JSP TCKs that you (the
powers that be) run for us on Tomcat releases (thanks again ;)).
1. When you run the TCKs, is there a report produced?  If so, what's its
format and can it posted to this list?
2. I know the TCK scholarship for the Servlet and JSP JSRs was granted
to the ASF, so theoretically (and I don't really want to do this at the
moment, just asking) we should be able to run the TCKs ourselves
assuming a proper authentication approach was taken (i.e. only run on
minotaur.apache.org, testing org.apache code, etc.)?
Thanks,
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]

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


Re: [VOTE] 5.5.3 Stability Rating

2004-10-19 Thread Amy Roh
Tomcat 5.5.3 should be rated:
[ X ] Beta, it's getting closer to stable 

Sorry for the late vote.  Better late than never.  ;-)
Amy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: TCKs for 4.1.31

2004-10-08 Thread Amy Roh
Hey Keith,

Hey Amy, would you mind running the TCKs against the 4.1.31 rc?
http://apache.org/~keith/rc2/
How does one go about obtaining these tests?
I only have the TCKs for the latest specs Servlet 2.4/JSP2.0 so it won't be 
compatible with Tomcat 4.1.

I believe Apache has contacts that have access to the TCKs.  I'll see if I 
can get the previous TCks and Apache contacts' names.

Thanks,
Amy
Thanks,
Keith
Amy Roh wrote:
Thanks Jan for the update.
I have confirmed that all JSP TCK tests pass with the latest 
StandardWrapper.java.  I have retagged the file so the 5.5.3 release has 
the fix.

Thanks,
Amy 

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


Re: TCKs for 5.5.3 and 5.0.29

2004-10-07 Thread Amy Roh
Sounds good to me.  :-)

Thanks,
Amy

- Original Message - 
From: Shapira, Yoav [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Thursday, October 07, 2004 5:47 AM
Subject: RE: TCKs for 5.5.3 and 5.0.29



Hi,
OK, I've made the Hotfix available on the www.apache.org/dist download
pages, and after giving the mirrors the usual 8 hours to pick it up, I'll
post a brief announcement to the user list.  Thanks,

Yoav Shapira
Millennium Research Informatics


-Original Message-
From: Remy Maucherat [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 07, 2004 8:08 AM
To: Tomcat Developers List
Subject: Re: TCKs for 5.5.3 and 5.0.29

Shapira, Yoav wrote:

Hi,
Thanks for noting and resolving the bug.  I'm hesitant to put out a new
5.5.3 build though, because that will create confusion among those
who've already downloaded it.  But we do have other options:
- Just issue a hotfix with StandardWrapper.class, tell people to put it
in server/lib.  We've done this before with other single-class fixes, so
there's precedent.
- Issue a new 5.5.3.1 (now possible with the new versioning scheme)
release.
- Leave this be, keep 5.5.3 at alpha, and have this fix go only into
5.5.4.

What do people think?


The issue is not critical, so proceed with 5.5.3 with a hotfix for
people who really need it (so that's the first option).

Rémy


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


-
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: TCKs for 5.5.3 and 5.0.29

2004-10-06 Thread Amy Roh
I'm on it.  Will let you know in a bit.
Amy
- Original Message - 
From: Shapira, Yoav [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Wednesday, October 06, 2004 6:28 AM
Subject: TCKs for 5.5.3 and 5.0.29


Hi,
Sun folks, or anyone with access to the Servlet and JSP TCKs: can you
please run them against the 5.5.3 and 5.0.29 releases when you get a
chance, and post your results here?  Thanks in advance ;)
Both 5.0.29 and 5.5.3 pass all our internal tests without exception.
Yoav Shapira
Millennium Research Informatics


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]

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


Re: TCKs for 5.5.3 and 5.0.29

2004-10-06 Thread Amy Roh
I ran the Servlet/JSP TCKs.  They both passed on the 5.0.29 release.
The Servlet TCK passed on the 5.5.3 release but the following 2 JSP TCK 
tests failed out of 615 tests.
Test case throws exception: [BaseUrlClient] null failed! Check output for 
cause of failure.
 a.. 
com/sun/ts/tests/jsp/spec/core_syntax/implicitobjects/URLClient.java#checkConfigTest 
: URLClient_checkConfigTest
 b.. 
com/sun/ts/tests/jsp/spec/tagfiles/implicitobjects/URLClient.java#checkConfigTest 
: URLClient_checkConfigTest

Thanks,
Amy
- Original Message - 
From: Shapira, Yoav [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Wednesday, October 06, 2004 6:28 AM
Subject: TCKs for 5.5.3 and 5.0.29


Hi,
Sun folks, or anyone with access to the Servlet and JSP TCKs: can you
please run them against the 5.5.3 and 5.0.29 releases when you get a
chance, and post your results here?  Thanks in advance ;)
Both 5.0.29 and 5.5.3 pass all our internal tests without exception.
Yoav Shapira
Millennium Research Informatics


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]

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


Re: TCKs for 5.5.3 and 5.0.29

2004-10-06 Thread Amy Roh
Thanks Jan for the update.
I have confirmed that all JSP TCK tests pass with the latest 
StandardWrapper.java.  I have retagged the file so the 5.5.3 release has the 
fix.

Thanks,
Amy

Hi Amy,
Amy Roh wrote:
I ran the Servlet/JSP TCKs.  They both passed on the 5.0.29 release.
The Servlet TCK passed on the 5.5.3 release but the following 2 JSP TCK 
tests failed out of 615 tests.
Test case throws exception: [BaseUrlClient] null failed! Check output for 
cause of failure.
 a.. 
com/sun/ts/tests/jsp/spec/core_syntax/implicitobjects/URLClient.java#checkConfigTest 
: URLClient_checkConfigTest
 b.. 
com/sun/ts/tests/jsp/spec/tagfiles/implicitobjects/URLClient.java#checkConfigTest 
: URLClient_checkConfigTest
I committed a fix for these 2 failures yesterday (in
StandardWrapper.java):
  revision 1.49
  date: 2004/10/06 00:54:46;  author: luehe;  state: Exp;  lines: +1 -1
  Undid previous change, as in the case where a servlet has a jsp-file
  and also declares some init params, as in:
servlet
  servlet-namexxx/servlet-name
  jsp-file/xxx.jsp/jsp-file
  init-param
param-namename1/param-name
param-valuevalue1/param-value
  /init-param
/servlet
  it needs its *own* JspServlet instance that it can initialize with its
  own params. Sharing of JspServlet instance is not possible in this
  case.
  Will have to come up with a better solution against loss of monitoring
  info (the JspServlet that handles the above jsp-file currently is not
  registered with JMX).
I think we need to retag this file with 5.5.3.
Jan

Thanks,
Amy
- Original Message - From: Shapira, Yoav [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Wednesday, October 06, 2004 6:28 AM
Subject: TCKs for 5.5.3 and 5.0.29

Hi,
Sun folks, or anyone with access to the Servlet and JSP TCKs: can you
please run them against the 5.5.3 and 5.0.29 releases when you get a
chance, and post your results here?  Thanks in advance ;)
Both 5.0.29 and 5.5.3 pass all our internal tests without exception.
Yoav Shapira
Millennium Research Informatics


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]

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


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


Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml

2004-10-04 Thread Amy Roh
Hi Remy,
 Modified:.build.xml
  catalina/src/share/org/apache/catalina/core
   StandardContext.java StandardEngine.java
   mbeans-descriptors.xml
  catalina/src/share/org/apache/catalina/connector
   Connector.java
  resources/mbeans tomcat5-ant.xml
  catalina/src/share/org/apache/catalina/realm RealmBase.java
  webapps/docs changelog.xml
 Log:
 - Fix embed and deployer packaging.
 - Fix JMX registration of realm.
 - Fix a variety of problems in MBean names.

 1.26  +18 -1 
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardEngine.java

 Index: StandardEngine.java
 ===
 RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardEngine.java,v
 retrieving revision 1.25
 retrieving revision 1.26
 diff -u -r1.25 -r1.26
 --- StandardEngine.java 16 Aug 2004 09:31:05 - 1.25
 +++ StandardEngine.java 3 Oct 2004 08:53:56 - 1.26
 @@ -404,6 +404,23 @@
  if( !initialized ) {
  init();
  }
 +
 +// Look for a realm - that may have been configured earlier.
 +// If the realm is added after context - it'll set itself.
 +if( realm == null ) {
 +ObjectName realmName=null;
 +try {
 +realmName=new ObjectName( domain + :type=Realm);
 +if( mserver.isRegistered(realmName ) ) {
 +Realm nrealm = 
(Realm)mserver.getAttribute(realmName,
 + 
managedResource);
I don't think Realm has managedResource attribute.
Shouldn't we be moving towards getting rid of all non-serializable 
attributes and return types in order to support remote access to MBeanServer 
using JSR 160?

Thanks,
Amy
 +setRealm(nrealm);
 +}
 +} catch( Throwable t ) {
 +log.debug(No realm for this engine  + realmName);
 +}
 +}
 +
  // Log our server identification information
  //System.out.println(ServerInfo.getServerInfo());
  log.info( Starting Servlet Engine:  + 
ServerInfo.getServerInfo());


 1.36  +1 -1 
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/mbeans-descriptors.xml

 Index: mbeans-descriptors.xml
 ===
 RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/mbeans-descriptors.xml,v
 retrieving revision 1.35
 retrieving revision 1.36
 diff -u -r1.35 -r1.36
 --- mbeans-descriptors.xml 29 Sep 2004 21:09:40 - 1.35
 +++ mbeans-descriptors.xml 3 Oct 2004 08:53:56 - 1.36
 @@ -547,7 +547,7 @@
 returnType=void
parameter name=connector
   description=Connector object
 - type=org.apache.catalina.Connector/
 + type=org.apache.catalina.connector.Connector/
  /operation

  operation name=start description=Start impact=ACTION 
returnType=void /


 1.6   +2 -2 
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector/Connector.java

 Index: Connector.java
 ===
 RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector/Connector.java,v
 retrieving revision 1.5
 retrieving revision 1.6
 diff -u -r1.5 -r1.6
 --- Connector.java 29 Sep 2004 09:55:38 - 1.5
 +++ Connector.java 3 Oct 2004 08:53:56 - 1.6
 @@ -1156,7 +1156,7 @@
  log.debug(Adding to  + parentName );
  if( mserver.isRegistered(parentName )) {
  mserver.invoke(parentName, addConnector, new Object[] 
{ this },
 -new String[] {org.apache.catalina.Connector});
 +new String[] 
{org.apache.catalina.connector.Connector});
  // As a side effect we'll get the container field set
  // Also initialize will be called
  //return;


 1.17  +16 -35jakarta-tomcat-5/resources/mbeans/tomcat5-ant.xml
 Index: tomcat5-ant.xml
 ===
 RCS file: /home/cvs/jakarta-tomcat-5/resources/mbeans/tomcat5-ant.xml,v
 retrieving revision 1.16
 retrieving revision 1.17
 diff -u -r1.16 -r1.17
 --- tomcat5-ant.xml 13 Nov 2003 08:45:48 - 1.16
 +++ tomcat5-ant.xml 3 Oct 2004 08:53:56 - 1.17
 @@ -145,8 +145,12 @@
target name=run depends=init,jmx-console
  description=Start tomcat as an mbean, no server.xml
 +property name=catalina.useNaming value=false /
 +
 +!--
  modelerRegistry 
resource=org/apache/catalina/mbeans/mbeans-descriptors.xml /
  modelerRegistry 
resource=org/apache/catalina/loader/mbeans-descriptors.xml /
 +--
  mkdir dir=${tomcat.home}/work/${domain}/ /

  jmx-service
 @@ 

Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler SmapUtil.java

2004-09-20 Thread Amy Roh
[EMAIL PROTECTED] wrote:
amyroh  2004/09/20 10:51:28
 Modified:jasper2/src/share/org/apache/jasper/compiler SmapUtil.java
 Log:
 Remove verbose.
 -if (verbose) {
 -if (log.isDebugEnabled())
 -log.debug(constant pool count:  + 
constantPoolCount);
 -}
 +log(constant pool count:  + constantPoolCount);

You need to keep if (log.isDebugEnabled()), otherwise, zillions of Strings 
will be created for no reason (as the parameter of your method will have 
to be created).
I have added the following log helper method so I don't have to do if 
(log.isDebugEnabled()) everytime I use log.debug()

 +
 +private static void log(String msg) {
 +if (log.isDebugEnabled())
 +log.debug(msg);
 +}
 +
  }
Amy
Rémy 

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


Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler SmapUtil.java

2004-09-20 Thread Amy Roh

Amy Roh wrote:
[EMAIL PROTECTED] wrote:
amyroh  2004/09/20 10:51:28
 Modified:jasper2/src/share/org/apache/jasper/compiler 
SmapUtil.java
 Log:
 Remove verbose.
 -if (verbose) {
 -if (log.isDebugEnabled())
 -log.debug(constant pool count:  + 
constantPoolCount);
 -}
 +log(constant pool count:  + constantPoolCount);

You need to keep if (log.isDebugEnabled()), otherwise, zillions of 
Strings will be created for no reason (as the parameter of your method 
will have to be created).

I have added the following log helper method so I don't have to do if 
(log.isDebugEnabled()) everytime I use log.debug()

 +
 +private static void log(String msg) {
 +if (log.isDebugEnabled())
 +log.debug(msg);
 +}
 +
  }
Amy
  +log(constant pool count:  + constantPoolCount);
But even to call your log() method, a String will need to be created that 
combines the constant pool count: with a 
String.valueOf(constantPoolCount).  Even if it's just going to be thrown 
away.
-Paul
Ah, I see what you mean.  I'll commit the fix. 

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


Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/xmlparser ParserUtils.java UTF8Reader.java

2004-09-17 Thread Amy Roh
[EMAIL PROTECTED] wrote:
amyroh  2004/09/17 14:02:34
 Modified:jasper2/src/share/org/apache/jasper/compiler SmapUtil.java
  jasper2/src/share/org/apache/jasper/runtime 
HttpJspBase.java
  jasper2/src/share/org/apache/jasper/security
   SecurityClassLoad.java
  jasper2/src/share/org/apache/jasper/xmlparser
   ParserUtils.java UTF8Reader.java
 Log:
 More logging changes.

You might want to get rid of the if (verbose) and other if 
(debug_flag_with_funky_name) at the same time :)
Yeah, I thought about that.  But I didn't want to just get rid of it in case 
some folks are still using the property.

Does anyone object to getting rid of debug/verbose property?
Thanks,
Amy
Rémy 

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


Re: [VOTE] 5.0.28 Stability Rating

2004-09-07 Thread Amy Roh
[X] Stable
[ ] Beta
[ ] Alpha
Amy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: [ANN] Apache Jakarta Tomcat 5.0.28 Released

2004-09-01 Thread Amy Roh
FYI, all Servlet/JSP TCKs passed on Tomcat 5.0.28 bundle.  

+1 to mark it as STABLE.  :-)

Thanks,
Amy

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



Re: [VOTE] [5.5] Release plan votes

2004-08-28 Thread Amy Roh
 ballot
 I approve the release plan:
 [X] Yes
 [ ] No
 /ballot
 
 ballot
 Tomcat 5.5 should use the following API set for the coding:
 [ ] J2SE 1.3
 [X] J2SE 1.4
 [ ] J2SE 5.0
 /ballot
 
 ballot
 Yoav Shapira will act as the release manager for this branch:
 [X] Yes
 [ ] No
 /ballot

Cheers,
Amy

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



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

2004-08-24 Thread Amy Roh
 [EMAIL PROTECTED] wrote:

 amyroh  2004/08/24 10:53:52
 
   Modified:catalina/src/share/org/apache/catalina/startup Tag:
 TOMCAT_5_0 ClassLoaderFactory.java
   Log:
   Do not load outdated xml-apis.jar  xercesImpl.jar from endorsed if JDK
5.0 is used.
 
 
 I doubt you can use the JDK compat class from there (you're in the
 bootstrap.jar).

Hmm.  Really?  I checked to see if the classLoader loads the jars.  They get
loaded if I run on JDK 1.4 and not on JDK 5.0.

Amy


 Rémy


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



Re: 5.0.28 next week?

2004-08-23 Thread Amy Roh
+1

I'd like to add startup scripts that don't use endorsed so that tomcat
5.0.28 can be run on JDK 5.0 if needed to be.  People can test it out by
switching the scripts.  I'm running TCKs to see if there're any problems but
will commit soon.

Let me know if anyone has issues with this.

Thanks,
Amy

- Original Message - 
From: Shapira, Yoav [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Monday, August 23, 2004 11:42 AM
Subject: 5.0.28 next week?



Hola,
I'm ready to cut 5.0.28 once the JSP folks are done with their work.  I
think you guys are actually all done and waiting for me, right?  Shall
we say this weekend with Friday as the deadline for committing any code
on the TOMCAT_5_0 branch?


Yoav Shapira
Millennium Research Informatics





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]



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



Re: endorsed directory (WAS: 5.0.28 next week?)

2004-08-23 Thread Amy Roh
I'm not getting rid of endorsed.  I'm just adding additional scripts so you
have an option to pick up the xml parsers from JDK 5.0 with 5.0.28 release
if you choose to.

The default behavior will be the same.

Amy

 I don't know why you want to get rid of endorsed.  Sure java 5.0 will
 have an up to date xerces, but it will get out of date in the future, so
 you might as well keep the endorsed directory.

 Amy Roh wrote:
  +1
 
  I'd like to add startup scripts that don't use endorsed so that tomcat
  5.0.28 can be run on JDK 5.0 if needed to be.  People can test it out by
  switching the scripts.  I'm running TCKs to see if there're any problems
but
  will commit soon.
 
  Let me know if anyone has issues with this.

 -
 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: common/endorsed classLoader

2004-08-18 Thread Amy Roh
  Are endorsed jars getting loaded somewhere else other than Bootstrap?

 Using the default startup scripts, they are loaded into the System CL (the
 only way a delegating CL can find them :).

You mean -Djava.endorsed.dirs in catalina scripts, correct?

BTW, why do they need to be loaded into the System CL in the scripts on top
of commonLoader in Bootstrap using common.loader property in
org/apache/catalina/startup/catalina.properties?

Thanks,
Amy


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



common/endorsed classLoader

2004-08-17 Thread Amy Roh
I wrote up some code in Bootstrap/ClassLoaderFactory to not load xml api
jars in common/endorsed if JDK 1.5 is used.  I see that the jars don't get
loaded when I check the StandardClassLoader but still the jars conflict
somehow resulting an error when used JDK1.5 unless endorsed directory is
physically removed.

Are endorsed jars getting loaded somewhere else other than Bootstrap?

Thanks,
Amy


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



Re: New committer: Peter Rossbach

2004-07-30 Thread Amy Roh
+1

Amy

 I'd like to nominate Peter Rossbach pr _at_ objektpark.de as a 
 committer on the Tomcat project. Peter submitted a 
 significant amount of 
 useful patches for Tomcat, and wants to contribute more.

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



ap_scoreboard_image: referenced symbol not found error

2004-07-22 Thread Amy Roh
Hi,

In an attempt to enable JK2 with Apache server on Unix, I have added the
following line in httpd.conf.

LoadModule jk2_module modules/mod_jk2-2.0.43.so

I got the mod_jk2-2.0.43.so from the JK2 binary download page.  However,
when I try to start the server, I get the following symbol
ap_scoreboard_image: referenced symbol not found error.

Syntax error on line 234 of /apache/conf/httpd.conf:
Cannot load /apache/modules/mod_jk2-2.0.43.so into server: ld.so.1
: /apache/bin/httpd: fatal: relocation error: file
/apache/modules/mod_jk2-2.0.43.so: symbol ap_scoreboard_image: referenced
symbol not found

I can get windows mod_jk2.so to work fine on a windows machine.

Anyone has more insight on what the error entails?

Thanks,
Amy



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



Re: ap_scoreboard_image: referenced symbol not found error

2004-07-22 Thread Amy Roh
I upgraded my Apache server to 2.0.50 and it fixed itself.  :-)


 Hi,
 
 In an attempt to enable JK2 with Apache server on Unix, I have added the
 following line in httpd.conf.
 
 LoadModule jk2_module modules/mod_jk2-2.0.43.so
 
 I got the mod_jk2-2.0.43.so from the JK2 binary download page.  However,
 when I try to start the server, I get the following symbol
 ap_scoreboard_image: referenced symbol not found error.
 
 Syntax error on line 234 of /apache/conf/httpd.conf:
 Cannot load /apache/modules/mod_jk2-2.0.43.so into server: ld.so.1
 : /apache/bin/httpd: fatal: relocation error: file
 /apache/modules/mod_jk2-2.0.43.so: symbol ap_scoreboard_image: referenced
 symbol not found
 
 I can get windows mod_jk2.so to work fine on a windows machine.
 
 Anyone has more insight on what the error entails?
 
 Thanks,
 Amy
 
 
 
 -
 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: [VOTE] 5.0.27 as Stable

2004-07-14 Thread Amy Roh
 ballot
 Release 5.0.27 as Stable:
 [X] Yes
 [ ] No
 /ballot

Amy

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



JavaOne fun at the XYZ Bar Monday June 28 at 8:30 PM

2004-06-25 Thread Amy Roh
Hi Tomcat-Dev folks,

As most of you probably know, the JavaOne conference will be held in San
Francisco at the Moscone Center next week.

The Servlet spec expert group is getting together to talk about the good old
days and the good days to come.  I am not sure who on this list will be
attending the conference but you are all welcome.  If you are at the
conference or in the area please stop by at 8:30 PM - 10:00 PM Monday June
28th.

http://www.worldsbestbars.com/city/SanFrancisco/XYZBar.asp

Hope to see you there.

Cheers!
Amy


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



JK2 documentation

2004-06-15 Thread Amy Roh
I see a bunch of jk docs
http://jakarta.apache.org/tomcat/tomcat-4.1-doc/jk2/index.html.  Which one
should I follow to set up jk2 with TC5?  Having some difficulties setting it
up - probably config issues...

Thanks,
Amy

Jun 15, 2004 10:56:17 AM org.apache.jk.common.MsgAjp processHeader
SEVERE: BAD packet signature 18245
Jun 15, 2004 10:56:17 AM
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable run
SEVERE: Caught exception (java.lang.NullPointerException) executing
[EMAIL PROTECTED], terminating thread


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



Re: Admin webapp help for persistence

2004-05-27 Thread Amy Roh
All right.  Let me take a look at it and let you know.

Amy

- Original Message - 
From: Shapira, Yoav [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Thursday, May 27, 2004 9:17 AM
Subject: Admin webapp help for persistence



Hi,
I've just added support for specifying thread priority in the coyote
connector (http://nagoya.apache.org/bugzilla/show_bug.cgi?id=28914).  I
think I have all the code in place including for viewing and editing
this attribute in the Admin webapp: it looks fine in the GUI.  However,
if one modifies the value and commits changes, the old attribute value
is written to server.xml.  Amy or someone more knowledgable than myself:
can you please look at the connector threadPriority attribute
persistence code and tell me what I missed? ;)  Thanks,

Yoav Shapira
Millennium Research Informatics





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]




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



Re: [5.0.25] Release vote

2004-05-21 Thread Amy Roh
  ballot
  Release 5.0.25 as Stable:
  [X] Yes
  [ ] No
  /ballot

Amy

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



wrong timeIdel value in StandardSession

2004-04-26 Thread Amy Roh
The following patch causes regression where sessions don't expire when it
should.  I have a test app that does refresh every 70 sec.  When I set
timeout to 2 minute - the session *never* expires.

cvs diff -r 1.26 -r 1.27 StandardSession.java

587c587
 int timeIdle = (int) ((timeNow - lastAccessedTime) / 1000L);
---
 int timeIdle = (int) ((timeNow - thisAccessedTime) / 1000L);

I propose to revert the patch.

Thanks,
Amy


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



Re: wrong timeIdel value in StandardSession

2004-04-26 Thread Amy Roh
Bill Barker wrote:
- Original Message - 
From: Amy Roh [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Monday, April 26, 2004 6:07 PM
Subject: wrong timeIdel value in StandardSession



The following patch causes regression where sessions don't expire when it
should.  I have a test app that does refresh every 70 sec.  When I set
timeout to 2 minute - the session *never* expires.


I see the change to be not so much a regression as a bug-fix :).  Your app
is accessing the session every 70 sec, so the session is never idle for the
required 2 min to allow it to expire.
I see on Remy's commit that Ths patch needs to be tested for possible 
regressions.  The test jsp actually checks if the session expired after 
timeout and alerts when refreshed.  I am attaching the jsp.




cvs diff -r 1.26 -r 1.27 StandardSession.java

587c587
 int timeIdle = (int) ((timeNow - lastAccessedTime) / 1000L);
---
   int timeIdle = (int) ((timeNow - thisAccessedTime) / 1000L);


I have added some debugging statements and found the following.

setMaxInactiveInterval 120
timeIdle now 0
timeIdle before 0
timeIdle now 36
timeIdle before 36
timeIdle now 116
timeIdle before 186
WOULD HAVE EXPIRED WITH OLD TIMEIDLE
timeIdle now 70
timeIdle before 70
timeIdle now 0
timeIdle before 70
timeIdle now 26
timeIdle before 96
timeIdle now 70
timeIdle before 140
WOULD HAVE EXPIRED WITH OLD TIMEIDLE
timeIdle now 0
timeIdle before 70
timeIdle now 16
timeIdle before 86
timeIdle now 70
timeIdle before 140
WOULD HAVE EXPIRED WITH OLD TIMEIDLE
timeIdle now 0
timeIdle before 70
timeIdle now 6
timeIdle before 76
timeIdle now 66
timeIdle before 137
WOULD HAVE EXPIRED WITH OLD TIMEIDLE
timeIdle now 70
timeIdle before 140
WOULD HAVE EXPIRED WITH OLD TIMEIDLE
timeIdle now 0
timeIdle before 70
timeIdle now 56
timeIdle before 127
WOULD HAVE EXPIRED WITH OLD TIMEIDLE
Let me know what you think

Thanks,
Amy

I propose to revert the patch.


I'm -1 on reverting unless you can explain why you think that the previous
behavior is correct wrt the spec.  And, no, the fact that this bug has been
in every version of Tomcat back to at least 3.2.x isn't good enough ;-).


Thanks,
Amy
-
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]

?xml version=1.0 ?
!DOCTYPE web-app PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.3//EN http://java.sun.com/dtd/web-app_2_3.dtd;

web-app

	session-config
session-timeout2/session-timeout
/session-config

	welcome-file-list
		welcome-fileindex.jsp/welcome-file
	/welcome-file-list

/web-app

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

Re: [5.0.22] Release vote

2004-04-09 Thread Amy Roh
I'm voting 0 on this, because of one bug I found:  
- Logging into Admin webapp, clicking on Connector (8080) brings up an
error page: javax.servlet.jsp.JspException: Missing message for key
connector.useBodyEncodingForURI

I just fixed this.  Thanks for pointing it out.

Amy

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



Re: [5.0.22] Release vote

2004-04-09 Thread Amy Roh
 Amy Roh wrote:
  I just fixed this.  Thanks for pointing it out.

 Thanks. The last String related bug was worse though ;)

Which bug?  Sorry, I'm lost.


 Rémy


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



Re: [Vote] Guenter Knauf as commiter

2004-03-17 Thread Amy Roh
+1  Welcome.  :-)

Amy

Henri Gomez wrote:
 
 Hi to all,
 
 jk2 2.0.4 seems in a good shape and I'd like to thanks all of
 you commiter, and tomcat-dev members for your feedback, patches
 and time.
 
 I'd like to see Guenter Knauf promoted to commiter since he
 provided us may fine patches on jk2 and help make this release
 happen.
 
 We need more and more people involved in the native side of
 jakarta-tomcat-connectors and Guenter show us these lasts week
 that he's a good candidate.
 
 Vote please, he's got of course my +1.
 
 -
 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.0] Next release

2004-03-04 Thread Amy Roh
 - plenty of admin webapp patches need to be merged; Amy and Larry were
 the last persons seen maintaining this feature, so can one of you two do
 it if you have time ?

Haven't had much time to spend on admin lately.  Let me try to spend some
time on admin before the next release to update.  Let me know if you're
aware of any patches other than the ones that come up in bugzilla when I
query for tomcat 5 admin.

Thanks,
Amy


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



Re: allowTrace attribute causing problems in the adminapplication

2004-02-27 Thread Amy Roh
I can't reproduce this one either.  Clean install might be the answer...


 Yeah, I saw this on a newly-downloaded Tomcat 4.1.30 on SUSE linux 8.2,
 java 1.3.1 (Sun?)  I first saw it on NetWare, JVM 1.4.2.  I thought it
 was something I had done wrong on NetWare, so I quickly tried it on
 Linux.
 
 Let me try a restart as you suggest, and try it on Windows with a clean
 download.

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



Re: allowTrace attribute causing problems in the adminapplication

2004-02-27 Thread Amy Roh
K.  I can reproduce the problem with 4.1.30 build but not in the workspace.
Looks like the latest org.apache.coyote.tomcat4.CoyoteConnector with
allowTrace didn't get tagged for 4.1.30.  4.1.30 tag has outdated
o.a.c.tomcat4.CoyoteConnector

Amy


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



Re: Remote Access using JSR 160

2004-02-13 Thread Amy Roh
Are you using modeler 1.1?  You need to have the latest modeler change for
the fix - org.apache.commons.modeler.BaseModelMBean 1.25.  The fix went in
after 1.1 release.  How about that for sneaky  ;-)  All should be good if
you have the latest BaseModelMBean.  :-)

Amy

 Yes, it says it returns a String, but if you actually get the attribute,
 you get an ObjectName (I did modify the JMX proxy servlet to make sure
 of that). Sneaky :)

 Rémy


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



Remote Access using JSR 160

2004-02-12 Thread Amy Roh
Not all Tomcat 5 MBeans are serializable and I think we should make all our
exposed MBeans serializable if we want to support remote access to
MBeanServer using JSR 160.  We'll need to modify Tomcat MBeans to only have
serializable attributes and return types.

Comments?

Thanks,
Amy


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



Re: Remote Access using JSR 160

2004-02-12 Thread Amy Roh
 Would it be possible to wait until tomorrow to start doing that (ie,
 after I tag 5.0.19) ?

Sure, it can wait.  I wasn't planning on doing it right away.  I need to see
whether we can accomplish this first - it'll be very nice to do so.

 BTW, another problem: on StandardContext and StandardWrapper, the
 objectName attribute returns an ObjectName, rather than a String.

Really?  This was fixed a while ago.  ContainerBase.getObjectName() returns
a String.

Thanks,
Amy

 Rémy


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



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

2004-01-08 Thread Amy Roh
Remy Maucherat wrote:
[EMAIL PROTECTED] wrote:

amyroh  2004/01/07 21:32:25

  Modified:catalina/src/share/org/apache/catalina/core
StandardHost.java
   catalina/src/share/org/apache/catalina/mbeans
MBeanFactory.java
  Log:
  Fix bugzilla 25878 - Add HostConfig after new Host is created via 
admin and prevent duplicate errorReportValve creation after restart.
  Patch submitted by [EMAIL PROTECTED] (Peter Rossbach).


I thought the StandardHost patch wasn't super clean. I think keeping a 
reference to the valve (and removing it on stop using that) would likely 
be a lot better. I'll see if I can improve it.
Sounds good.

Amy

Rémy

-
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: Exception in RealmBase

2004-01-08 Thread Amy Roh
Mark Woon wrote:

Hi all,

I'm reposting this in the hopes that someone will responsd.
I have a custom Realm implementation that extends
org.apache.catalina.realm.RealmBase.  It used to work in 4.x, but in
5.0.16, I'm getting the following exception on startup:
21:17:29,719 ERROR RealmBase:1092 - Can't register null
java.lang.NullPointerException
  at org.apache.catalina.realm.RealmBase.init(RealmBase.java:1088)
  at org.apache.catalina.realm.RealmBase.start(RealmBase.java:769)
  at
org.pharmgen.webapp.tomcat.PharmGenRealmAdapter.setRealm(PharmGenRealmAdapter.java:34) 

  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) 

  at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) 

  at java.lang.reflect.Method.invoke(Method.java:324)
  at
org.securityfilter.config.SecurityConfig.addRealm(SecurityConfig.java:216)
[snip]
I've taken a look at the source, and as far as I can tell, it's because
the container is null.  What is responsible for providing the Realm the
container it's in?  Is there some new bit of configuration I need to do
in Tomcat 5?  I'm also surprised that there's this bit of code in
RealmBase.init():
if( container== null ) {
// do some stuff, and don't set container or oname
}
if( oname==null ) {
try {
  ContainerBase cb=(ContainerBase)container;
  //  NPE HAPPENS HERE  
  oname=new ObjectName(cb.getDomain()+:type=Realm +
cb.getContainerSuffix());
  // some other stuff
} catch (Throwable e) {
  log.error( Can't register  + oname, e);
}
}
How are you adding your realm?  It seems the code under container==null 
should be executed when the realm is added via JMX using full object 
name only.  It's using its own object name to figure out its container 
and calls setRealm to its container.  When oname==null, the realm should 
already have its container...

Amy

I don't have any experience with JMX, so maybe it's doing something
behind the scenes, but if not, that bit of code looks wrong.  While this
seems to be an error that can be safely ignored if I'm not using JMX,
it's still a little distressing.
Any help would be appreciated.

Thanks,
-Mark





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


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

2003-12-10 Thread Amy Roh
 Amy Roh wrote:
  [EMAIL PROTECTED] wrote:
 
  remm2003/12/05 01:28:55
 
Modified:catalina/src/share/org/apache/catalina/session
  StandardManager.java
Log:
- isValid already expires sessions, so backgroundProcess shouldn't
call
  expire again.
 
  isValid doesn't *always* expire session.
  
  StandardSession.isValid() -
 
  public boolean isValid() {
 
  if (this.expiring){
  return true;
  }
 
  if (!this.isValid ) {
  *** return false;
  }
 
  if (maxInactiveInterval = 0) {
  long timeNow = System.currentTimeMillis();
  int timeIdle = (int) ((timeNow - lastAccessedTime) / 1000L);
  if (timeIdle = maxInactiveInterval) {
  *** expire(true);
  }
  }
 
  return (this.isValid);
  }
 
  If StandardSession.isValid is false, then we want to expire the session.
   However, isValid() call doesn't get to expire(true) and just return
  false.  So removing session.expire() from
  StandardManager.processExpires() won't work all the time.  Am I missing
  something?

 There doesn't seem many methods changing isValid to false. invalidate is
 another one, and it calls expire. As long as all the methods which
 invalidate the session right away expire them, it should be ok I think.

IMHO, not calling expire() because no method changes isValid to false
doesn't seem like a clean approach.  Moreover,
PersistentManagerBase.processExpires() keeps expire() making it not
consistent.

Amy

 Rémy


 -
 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: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm RealmBase.java

2003-12-09 Thread Amy Roh
Remy Maucherat wrote:

[EMAIL PROTECTED] wrote:

amyroh  2003/12/08 17:54:33

  Modified:catalina/src/share/org/apache/catalina/core
ApplicationFilterFactory.java
   catalina/src/share/org/apache/catalina/realm 
RealmBase.java
  Log:
  Revert the patch.  Seems like this case is already handled in the 
Mapper in TC5.


M, forget my -1 (I should read *all* my email before replying) :-D
Note that there's an open bug about this: bug 25015 
(http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25015). Could you get 
some spec related folk to comment on it ?
Servlet spec folks talked about this (parameters in path and whether 
getpathinfo should return them or not), and they couldn't get the 
consensus. Most people seem to like that getPathInfo should NOT include 
the parameters, but we haven't had a thorough discussion and that's 
listed as an item for the next version of the spec. So, for now, it's 
container-specific but the servlet spec lead recommends to remove them.

Amy

The ex was:
http://localhost/appname/servlet-name/extra;path/info;here/hi.jsp
Looking at the URI RFC, I think this should be changed to:
http://localhost/appname/servlet-name/extra/info/hi.jsp
Rémy



-
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: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session StandardManager.java

2003-12-09 Thread Amy Roh
[EMAIL PROTECTED] wrote:

remm2003/12/05 01:28:55

  Modified:catalina/src/share/org/apache/catalina/session
StandardManager.java
  Log:
  - isValid already expires sessions, so backgroundProcess shouldn't call
expire again.
isValid doesn't *always* expire session.

StandardSession.isValid() -

public boolean isValid() {

if (this.expiring){
return true;
}
if (!this.isValid ) {
*** return false;
}
if (maxInactiveInterval = 0) {
long timeNow = System.currentTimeMillis();
int timeIdle = (int) ((timeNow - lastAccessedTime) / 1000L);
if (timeIdle = maxInactiveInterval) {
*** expire(true);
}
}
return (this.isValid);
}
If StandardSession.isValid is false, then we want to expire the session. 
 However, isValid() call doesn't get to expire(true) and just return 
false.  So removing session.expire() from 
StandardManager.processExpires() won't work all the time.  Am I missing 
something?

Thanks,
Amy
  - Bug 25234, submitted by Paul Harvey.
  
  Revision  ChangesPath
  1.16  +5 -11 jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/StandardManager.java
  
  Index: StandardManager.java
  ===
  RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/StandardManager.java,v
  retrieving revision 1.15
  retrieving revision 1.16
  diff -u -r1.15 -r1.16
  --- StandardManager.java	29 Nov 2003 18:06:35 -	1.15
  +++ StandardManager.java	5 Dec 2003 09:28:55 -	1.16
  @@ -813,13 +813,7 @@
   for (int i = 0; i  sessions.length; i++) {
   StandardSession session = (StandardSession) sessions[i];
   if (!session.isValid()) {
  -try {
  -expiredSessions++;
  -session.expire();
  -} catch (Throwable t) {
  -log.error(sm.getString
  -  (standardManager.expireException), t);
  -}
  +expiredSessions++;
   }
   }
   long timeEnd = System.currentTimeMillis();
  
  
  

-
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: [VOTE] 5.0.16

2003-12-03 Thread Amy Roh



 Note: 5.0.16 is almost identical to 5.0.15, but please test it anyway
 for regressions.

 ballot
 Release 5.0.16 as Stable ?
 [X] Yes
 [ ] No
 /ballot

Amy


 As usual, if there's either a serious problem or a regression over
 previous builds, there will be a new build.

 Rémy



 -
 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: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java

2003-11-25 Thread Amy Roh
- Original Message -
From: Remy Maucherat [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Tuesday, November 25, 2003 12:27 AM
Subject: Re: cvs commit:
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net
PoolTcpEndpoint.java


 [EMAIL PROTECTED] wrote:
  amyroh  2003/11/24 15:01:22
 
Modified:http11/src/java/org/apache/coyote/http11
Http11Protocol.java
 util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java
Log:
Add getters for all attributes defined in MBeanInfo so getAttribute
calls suceed.

 Rectification: I'll integrate your patch, but it would be best to remove
 the fields which are duplicated with the thread pool MBean.

Question...  How are the attributes for these MBeans in j-t-c get generated?
I don't see descriptor files.  It seems if you have setters, the
correspondent attributes get automatically added to MBeanInfo.  And you get
an error trying to getAttribute on the attribute which is included in
MBeanInfo because it's missing getter methods.

Thanks,
Amy

 Rémy



 -
 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: [VOTE] New committer: Mark Thomas

2003-11-20 Thread Amy Roh
+1

Amy

- Original Message - 
From: Remy Maucherat [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Thursday, November 20, 2003 1:19 PM
Subject: [VOTE] New committer: Mark Thomas


 Hi,

 I'd like to nominate Mark Thomas as a Tomcat committer. He has
 contibuted a significant amount of fixes already, and does what nobody
 else does: roam Bugzila to fix older issues and cleanup the database. He
 has special interest in the WebDAV code, which currently has no
maintainer.

 He has my +1.

 Rémy



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



Vegas Anyone? :-)

2003-11-07 Thread Amy Roh

ApacheCon 2003 will be held in Las Vegas this November 16-19.  Who is going
to be there from Tomcat Dev?  Maybe we can coordinate Tomcat get together...
:-)

Amy


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



Connector ObjectName includes address

2003-11-04 Thread Amy Roh
Currently, connector objectname includes address in this format:

domain:type=Connector,port=8080,address=0.0.0.0.

This causes a problem when IPV6 addresses are used since IPV6 addresses 
include colons.  The javax.management.ObjectName doesn't allow to have 
colon character in it and this causes 
javax.management.MalformedObjectNameException: ObjectName: invalid 
character ':' in value part of property.

I propose to exclude address as connector objectname property since port 
number alone should keep the objectnames unique.

Are we using address value from connector objectname anywhere?

Thanks,
Amy


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


Re: Connector ObjectName includes address

2003-11-04 Thread Amy Roh
Bill Barker wrote:

- Original Message -
From: Amy Roh [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Tuesday, November 04, 2003 6:01 PM
Subject: Connector ObjectName includes address


Currently, connector objectname includes address in this format:

domain:type=Connector,port=8080,address=0.0.0.0.

This causes a problem when IPV6 addresses are used since IPV6 addresses
include colons.  The javax.management.ObjectName doesn't allow to have
colon character in it and this causes
javax.management.MalformedObjectNameException: ObjectName: invalid
character ':' in value part of property.
I propose to exclude address as connector objectname property since port
number alone should keep the objectnames unique.


What about the case where I have several V-Hosts, each with it's own
Connector listening on port 80?
That's the case I forgot about.  I guess we need address in connector 
objectname since connectors can share the same port...



Are we using address value from connector objectname anywhere?

Thanks,
Amy


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




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


Re: [VOTE] New builds

2003-10-29 Thread Amy Roh
 ballot
 Release 4.1.29 as Stable ?
 [X] Yes
 [ ] No
 /ballot
 
 ballot
 Release 5.0.14 as Beta ?
 [X] Yes
 [ ] No
 /ballot

Amy

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



CoyoteRequest.recycle() and userPrincipal

2003-09-30 Thread Amy Roh
The admin logs you out and asks you to reauthenticate yourself again after
you do commit.  It seems like after the admin gets redeployed, the same
CoyoteRequestFacade loses its userPrincipal in the recycle() method.  What
is the motivation for setting userPrincipal to null in recycle()?  I don't
think it's acceptable to ask the user to keep logging on and reauthenticate
his/herself everytime you commit.

Comments?
Thanks,
Amy


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



Re: CoyoteRequest.recycle() and userPrincipal

2003-09-30 Thread Amy Roh
Remy Maucherat wrote:
Amy Roh wrote:

The admin logs you out and asks you to reauthenticate yourself again 
after
you do commit.  It seems like after the admin gets redeployed, the same
CoyoteRequestFacade loses its userPrincipal in the recycle() method.  
What
is the motivation for setting userPrincipal to null in recycle()?  I 
don't
think it's acceptable to ask the user to keep logging on and 
reauthenticate
his/herself everytime you commit.

Comments?


Well, I think it is perfectly acceptable, sorry ;-)

BTW, there's no CoyoteRequestFacade.recycle, that's in CoyoteRequest, 
and it is obviously a field which needs to be recycled.
I meant to say CoyoteRequest.  :-)

Fixing this will create a major security issue. Please refrain from 
fixing things you do not seem to understand well, or please only do so 
in Sun's repositories.
I see that there will be security issues if we don't clean up the field 
in the request.  No such fix will go into Sun's repositories if it's a 
security issue.  I obviously posted the email to the list for additional 
 comments to understand the code better.

Thanks,
Amy
Remy

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


admin commit stops the app and doesn't restart

2003-09-23 Thread Amy Roh
The admin logs you out after commit due to the following error.  Looks 
like commit stopped the app and didn't restart correctly.

Comments?
Amy
Sep 23, 2003 1:52:13 PM org.apache.catalina.loader.WebappClassLoader 
loadClass
INFO: Illegal access: this web application instance has been stopped 
already (th
e eventual following stack trace is caused by an error thrown for 
debugging purp
oses as well as to attempt to terminate the thread which caused the 
illegal acce
ss, and has no functional impact)
Sep 23, 2003 1:52:13 PM org.apache.catalina.loader.WebappClassLoader 
loadClass
INFO: Illegal access: this web application instance has been stopped 
already (th
e eventual following stack trace is caused by an error thrown for 
debugging purp
oses as well as to attempt to terminate the thread which caused the 
illegal acce
ss, and has no functional impact)
Sep 23, 2003 1:52:13 PM org.apache.catalina.loader.WebappClassLoader 
loadClass
INFO: Illegal access: this web application instance has been stopped 
already (th
e eventual following stack trace is caused by an error thrown for 
debugging purp
oses as well as to attempt to terminate the thread which caused the 
illegal acce
ss, and has no functional impact)
Sep 23, 2003 1:52:13 PM org.apache.coyote.tomcat5.CoyoteAdapter service
SEVERE: An exception or error occurred in the container during the 
request proce
ssing
java.lang.ThreadDeath
at 
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoa
der.java:1252)
at 
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoa
der.java:1212)
at java.beans.Introspector.instantiate(Introspector.java:1293)
at 
java.beans.Introspector.findExplicitBeanInfo(Introspector.java:382)
at java.beans.Introspector.init(Introspector.java:331)
at java.beans.Introspector.getBeanInfo(Introspector.java:132)
at 
org.apache.commons.beanutils.PropertyUtils.getPropertyDescriptors(Pro
pertyUtils.java:949)
at 
org.apache.commons.beanutils.PropertyUtils.getPropertyDescriptors(Pro
pertyUtils.java:979)
at 
org.apache.commons.beanutils.PropertyUtils.getPropertyDescriptor(Prop
ertyUtils.java:887)
at 
org.apache.commons.beanutils.PropertyUtils.getSimpleProperty(Property
Utils.java:1172)
at 
org.apache.commons.beanutils.PropertyUtils.getNestedProperty(Property
Utils.java:772)
at 
org.apache.commons.beanutils.PropertyUtils.getProperty(PropertyUtils.
java:801)
at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperV
alve.java:297)
at 
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValv
eContext.java:151)
at 
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.jav
a:563)
at 
org.apache.catalina.core.StandardContextValve.invokeInternal(Standard
ContextValve.java:245)
at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextV
alve.java:199)
at 
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValv
eContext.java:151)
at 
org.apache.catalina.authenticator.AuthenticatorBase.invoke(Authentica
torBase.java:573)
at 
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValv
eContext.java:149)
at 
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.jav
a:563)
at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.j
ava:195)
at 
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValv
eContext.java:151)
at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.j
ava:164)
at 
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValv
eContext.java:149)
at 
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.jav
a:563)
at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineVal
ve.java:156)
at 
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValv
eContext.java:151)
at 
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.jav
a:563)
at 
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:972)

at 
org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:20
9)
at 
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java
:670)
at 
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.proce
ssConnection(Http11Protocol.java:517)
at 
org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java
:580)
at 
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadP
ool.java:666)
at java.lang.Thread.run(Thread.java:536)



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


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

2003-09-22 Thread Amy Roh
Remy Maucherat wrote:

Remy Maucherat wrote:

[EMAIL PROTECTED] wrote:

amyroh  2003/09/21 16:11:17

  Modified:catalina/src/share/org/apache/catalina/session
ManagerBase.java
  Log:
  Fix to properly create Manager MBean at webapp restart - bugtraq 
4924607.


-1 for the last two patches (they don't work). I look at the issues 
and will revert them.


Hmmm, forget it, I should have looked at the code before sending the 
email :-P

   oname = null;
   // Self-registration, undo it
   Registry.getRegistry().unregisterComponent(oname);
I guess I can see where the NPE is coming from :-D
Thanks.  X)

Amy

Remy



-
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: Manager deploy when unpackWARs = false

2003-09-22 Thread Amy Roh
Remy Maucherat wrote:

Amy Roh wrote:

Local deploys do not copy the WAR over.


So local deploy is *not* persistant until we implement to save 
config.  This
is what I was referring to.


Fixing the bug is rather annoying, and the amount of stuff which should 
be automated is quite big, and seems not worth it.
Instead, I'd like to remove local deploy from the manager servlet (IMO, 
it's useless). If using the Ant tasks to do a local deploy, then it's up 
to you to persist the config later, upon the user's choice.
+0

I think we should also add some Ant tasks:
- a save config Ant task - with a context parameter allowing to save 
just one context (this task is also useful when using the JMX tasks to 
reconfigure Tomcat, and persisting the config is needed)
- maybe extend a bit the JMX tasks
+1

Amy

Comments ?

Remy



-
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: [PROPOSAL] Narrow down the list of JARs to be scanned for TLDs

2003-09-22 Thread Amy Roh
 The proposal is to add a configurable String property (tldJarNames)
 on Context, which specifies the comma-separated list of JAR file names
 (without any path info) that must be scanned for TLDs.

+1 
Amy :-)

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



Re: [VOTE] 5.0.12 stability rating

2003-09-20 Thread Amy Roh
 ballot
 [ ] Alpha
 [X] Beta
 /ballot

Amy

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



Manager deploy when unpackWARs = false

2003-09-19 Thread Amy Roh
Deployed webapps don't survive restart if Host unpackWARs is set to false.
Is this expected behavior?

Thanks,
Amy


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



Re: Manager deploy when unpackWARs = false

2003-09-19 Thread Amy Roh
 Amy Roh wrote:
  Deployed webapps don't survive restart if Host unpackWARs is set to
false.
  Is this expected behavior?

 It works fine for me.

Are you using HTMLManager?

Amy

 If you're using install then don't, I've deprecated it (it's been
 confusing people), and deploy should be used instead. If you want to
 save after an install, then use the admin's commit.

 Remy


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



Re: Manager deploy when unpackWARs = false

2003-09-19 Thread Amy Roh

 Of course. It corresponds to using the deploy task.
 After deploying, the WAR should be in the host appBase.

I might be on crack again but my WAR doesn't get copied over to the host
appBase (webapps).  If I set unpackWARs to true the war gets unpacked into
its directory under webapps.

Amy


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



Re: Manager deploy when unpackWARs = false

2003-09-19 Thread Amy Roh
 Local deploys do not copy the WAR over.

So local deploy is *not* persistant until we implement to save config.  This
is what I was referring to.

 I'm talking about the Upload a WAR which will copy the WAR to the
appBase.

I know this one works.  :-)

 (please, don't always try to use the only situation which causes trouble)

I'm not.  It's your favorite sqe folks.  ;-)

 (please vote to my lame ballots)

Okie.  X-)


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



ManagerServlet undeploy

2003-09-18 Thread Amy Roh
Undeploy fails for any app that's not installed under webapps directory. 
 For example, an attempt to undeploy /admin will fail with Cannot 
undeploy document base for path /admin because of the following lines 
from ManagerServlet line 1384

// Validate the docBase path of this application
String deployedPath = deployed.getCanonicalPath();
String docBase = context.getDocBase();
File docBaseDir = new File(docBase);
if (!docBaseDir.isAbsolute()) {
docBaseDir = new File(appBaseDir, docBase);
}
String docBasePath = docBaseDir.getCanonicalPath();
if (!docBasePath.startsWith(deployedPath)) {
writer.println(sm.getString(managerServlet.noDocBase,
displayPath));
return;
}
Any app that's installed using context configuration file with docBase 
other than ../webapps will not pass the condition since deployedPath 
is always ../webapps.

What is the reasoning behind this validation?

Thanks,
Amy


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


Re: [PATCH] CGI Servlet bugs

2003-09-02 Thread Amy Roh
Jeff Tulley wrote:
Still, I think the item number one - not assuming the separator is a
\ is needed for OS portability, right?  It looks like this was just
committed as-is, not using File.separator or File.separatorChar
You need to use File.separator for escaping double quote on different OS?

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


Re: DO NOT REPLY [Bug 22328] - javax.management.ReflectionException:Cannot find method getClassName with this signature

2003-08-31 Thread Amy Roh
I have updated the bug report.  Thanks for the reminder.

Amy

Tim Funk wrote:
IIRC - I think Amy submitted a patch to fix this. Can I resolve this as 
fixed?

-Tim


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


Re: cvs commit: jakarta-tomcat-catalina/webapps/admin/connectorconnector.jsp

2003-08-30 Thread Amy Roh
The AJP connector still lies,
Can you tell me what the discrepancy is in AJP connector?  I just 
followed the doc.

All of my Connectors (http, https, ajp) show blanks for the Processors
section (even for those that I've explicitly configured in 'server.xml').
What do you mean?  There is no longer Processors section.  I got rid 
of maxProcessor and minProcessor from the page since they're deprecated. 
 Instead, admin now shows maxSpareThreads, maxThreads, and minSpareThreads.

Thanks for the comments.  :-)
Amy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: [5.0] JMX 1.2

2003-08-29 Thread Amy Roh
Hi Remy,

JSR 160 will go final in October (assuming the final ballot passes, as 
seems very likely).  At that stage the RI will be released under 
essentially the same licensing terms as the JMX RI.  So yes, Tomcat will 
be able to use it.

Amy

Remy Maucherat wrote:
As discussed before, I'm going to package the JMX RI 1.2.1 with TC 5.0.x 
from now on (after testing, of course).
I'll leave MX4J part of the build process.

Q to the Sun folks: can I legally ship the JMX remote 1.0 RI binary with 
Tomcat ?

Remy


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


Re: cvs commit:jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5mbeans-descriptors.xml

2003-08-29 Thread Amy Roh
There's no minProcessors anymore, only minSpareThreads. Similarly, 
maxProcessors should return maxThreads. You should add a note in the 
description that both are deprecated.
I don't use minProcessors or maxProcessors.  I just left them in the 
descriptor instead of removing them.  I can either add a note or remove 
them.

BTW, I think StandardServer should be adapted to create the new conector 
format, rather than use the old attribute names (and likely the socket 
factory also).
Can you elaborate?

Thanks,
Amy


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


Re: cvs commit: jakarta-tomcat-catalina/webapps/admin/users user.jsp

2003-08-28 Thread Amy Roh
Forgot to credit Jeff Tulley ([EMAIL PROTECTED]) for the patch.  Thanks.

[EMAIL PROTECTED] wrote:
amyroh  2003/08/27 16:32:30

  Modified:webapps/admin login.jsp
   webapps/admin/users user.jsp
  Log:
  Get rid of the maximum size of the username and password fields.
  Fix 22268 to allow to use SHA digest.


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


commons-dbcp and pool

2003-08-28 Thread Amy Roh
Where do these jars get used?  They're under core optional libraries in 
build.properties.  Do we need these jars in order to fun tomcat 
standalone, manager, and admin webapp?

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


Re: [VOTE] 5.0.9 stability rating

2003-08-27 Thread Amy Roh
Resend.  It's been almost 3 hours since I sent the original email. 
wonder if it's my mail server or apache...

Amy Roh wrote:

Remy Maucherat wrote:

Amy Roh wrote:

Remy Maucherat wrote:

Amy Roh wrote:

I'll update the mbean-descriptor.xml and admin page for Connector 
soon.




Thanks. Sorry for the trouble.




No Problem.  I just committed the updates.  Let me know if there is 
additional updates or if I missed/overlooked anything.


The changes are a bit more complex than what you did. The new syntax is:

HTTP/1.1:

Connector port=8080
   maxThreads=150 minSpareThreads=25 maxSpareThreads=75
   enableLookups=false redirectPort=8443 
acceptCount=100
   debug=0 connectionTimeout=2
   disableUploadTimeout=true /
(the thread pool configuration changed, basically)

AJP/1.3:

Connector port=8009
   enableLookups=false redirectPort=8443 debug=0
   protocol=AJP/1.3 /
(ie, no thread pool configuration here)
Please don't add get/set on the CoyoteConnector class itself (we're 
trying to avoid that, as it's protocol dependent; you can look at 
Bill's patch - which I reverted for performance reasons, but which did 
the right thing on principle). IMO, you should add those to the 
ConnectorMBean, and use get/setProperty. What do you think ?


I thought we're moving away from using *MBean classes and instead using 
the actual class for management implementation.  But I see that why we 
want to avoid the getters and setters from the class due to protocol 
dependency.  We can definitely move the getters/setters into a 
ConnectorMBean as long as modeler keeps supporting extending class 
mbean.  I can either update o.a.c.mbeans.ConnectorMBean and use it or 
put the ConnectorMBean in the coyote directory with the mbean-descriptor 
and the Connector class.  I'll need to update admin to represent thread 
pool configuration changes.

Amy

Remy



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


[Fwd: Re: [VOTE] 5.0.9 stability rating]

2003-08-27 Thread Amy Roh
resend again.  my email's been getting lost for some reason.

 Original Message 
Subject: Re: [VOTE] 5.0.9 stability rating
Date: Tue, 26 Aug 2003 16:11:35 -0700
From: Amy Roh [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
References: [EMAIL PROTECTED] 
[EMAIL PROTECTED] [EMAIL PROTECTED] 
[EMAIL PROTECTED] [EMAIL PROTECTED] 
[EMAIL PROTECTED] [EMAIL PROTECTED] 
[EMAIL PROTECTED] [EMAIL PROTECTED]

btw, why does Http11Protocol.getAttribute always return null?  Is it on
purpose or just not implement yet since no usage?
Amy Roh wrote:

Resend.  It's been almost 3 hours since I sent the original email. 
wonder if it's my mail server or apache...

Amy Roh wrote:

Remy Maucherat wrote:

Amy Roh wrote:

Remy Maucherat wrote:

Amy Roh wrote:

I'll update the mbean-descriptor.xml and admin page for Connector 
soon.




Thanks. Sorry for the trouble.




No Problem.  I just committed the updates.  Let me know if there is 
additional updates or if I missed/overlooked anything.




The changes are a bit more complex than what you did. The new syntax is:

HTTP/1.1:

Connector port=8080
   maxThreads=150 minSpareThreads=25 
maxSpareThreads=75
   enableLookups=false redirectPort=8443 
acceptCount=100
   debug=0 connectionTimeout=2
   disableUploadTimeout=true /
(the thread pool configuration changed, basically)

AJP/1.3:

Connector port=8009
   enableLookups=false redirectPort=8443 debug=0
   protocol=AJP/1.3 /
(ie, no thread pool configuration here)
Please don't add get/set on the CoyoteConnector class itself (we're 
trying to avoid that, as it's protocol dependent; you can look at 
Bill's patch - which I reverted for performance reasons, but which 
did the right thing on principle). IMO, you should add those to the 
ConnectorMBean, and use get/setProperty. What do you think ?


I thought we're moving away from using *MBean classes and instead 
using the actual class for management implementation.  But I see that 
why we want to avoid the getters and setters from the class due to 
protocol dependency.  We can definitely move the getters/setters into 
a ConnectorMBean as long as modeler keeps supporting extending class 
mbean.  I can either update o.a.c.mbeans.ConnectorMBean and use it or 
put the ConnectorMBean in the coyote directory with the 
mbean-descriptor and the Connector class.  I'll need to update admin 
to represent thread pool configuration changes.

Amy

Remy



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






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


Re: [VOTE] 5.0.9 stability rating

2003-08-27 Thread Amy Roh
Remy Maucherat wrote:

Amy Roh wrote:

Remy Maucherat wrote:

Amy Roh wrote:

I'll update the mbean-descriptor.xml and admin page for Connector soon.


Thanks. Sorry for the trouble.


No Problem.  I just committed the updates.  Let me know if there is 
additional updates or if I missed/overlooked anything.


The changes are a bit more complex than what you did. The new syntax is:

HTTP/1.1:

Connector port=8080
   maxThreads=150 minSpareThreads=25 maxSpareThreads=75
   enableLookups=false redirectPort=8443 acceptCount=100
   debug=0 connectionTimeout=2
   disableUploadTimeout=true /
(the thread pool configuration changed, basically)
AJP/1.3:

Connector port=8009
   enableLookups=false redirectPort=8443 debug=0
   protocol=AJP/1.3 /
(ie, no thread pool configuration here)
Please don't add get/set on the CoyoteConnector class itself (we're 
trying to avoid that, as it's protocol dependent; you can look at Bill's 
patch - which I reverted for performance reasons, but which did the 
right thing on principle). IMO, you should add those to the 
ConnectorMBean, and use get/setProperty. What do you think ?
I thought we're moving away from using *MBean classes and instead using 
the actual class for management implementation.  But I see that why we 
want to avoid the getters and setters from the class due to protocol 
dependency.  We can definitely move the getters/setters into a 
ConnectorMBean as long as modeler keeps supporting extending class 
mbean.  I can either update o.a.c.mbeans.ConnectorMBean and use it or 
put the ConnectorMBean in the coyote directory with the mbean-descriptor 
and the Connector class.  I'll need to update admin to represent thread 
pool configuration changes.

Amy

Remy



-
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: [VOTE] 5.0.9 stability rating

2003-08-27 Thread Amy Roh
btw, why does Http11Protocol.getAttribute always return null?  Is it on 
purpose or just not implement yet since no usage?

Amy Roh wrote:

Resend.  It's been almost 3 hours since I sent the original email. 
wonder if it's my mail server or apache...

Amy Roh wrote:

Remy Maucherat wrote:

Amy Roh wrote:

Remy Maucherat wrote:

Amy Roh wrote:

I'll update the mbean-descriptor.xml and admin page for Connector 
soon.




Thanks. Sorry for the trouble.




No Problem.  I just committed the updates.  Let me know if there is 
additional updates or if I missed/overlooked anything.




The changes are a bit more complex than what you did. The new syntax is:

HTTP/1.1:

Connector port=8080
   maxThreads=150 minSpareThreads=25 
maxSpareThreads=75
   enableLookups=false redirectPort=8443 
acceptCount=100
   debug=0 connectionTimeout=2
   disableUploadTimeout=true /
(the thread pool configuration changed, basically)

AJP/1.3:

Connector port=8009
   enableLookups=false redirectPort=8443 debug=0
   protocol=AJP/1.3 /
(ie, no thread pool configuration here)
Please don't add get/set on the CoyoteConnector class itself (we're 
trying to avoid that, as it's protocol dependent; you can look at 
Bill's patch - which I reverted for performance reasons, but which 
did the right thing on principle). IMO, you should add those to the 
ConnectorMBean, and use get/setProperty. What do you think ?


I thought we're moving away from using *MBean classes and instead 
using the actual class for management implementation.  But I see that 
why we want to avoid the getters and setters from the class due to 
protocol dependency.  We can definitely move the getters/setters into 
a ConnectorMBean as long as modeler keeps supporting extending class 
mbean.  I can either update o.a.c.mbeans.ConnectorMBean and use it or 
put the ConnectorMBean in the coyote directory with the 
mbean-descriptor and the Connector class.  I'll need to update admin 
to represent thread pool configuration changes.

Amy

Remy



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




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


Re: [VOTE] 5.0.9 stability rating

2003-08-27 Thread Amy Roh
Bill Barker wrote:

If you need help in implementation, I'm more than happy to lend a hand ;-).
Point of fact was that I was assuming that I would be making the changes
you've made myself.
Cool.  So I looked at your reverted patch.  I think it makes sense to 
put similar implemntation into ConnectorMBean class then.  Would you 
like to do it or do you want me to use your patch and apply it?

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


Re: [VOTE] 5.0.9 stability rating

2003-08-25 Thread Amy Roh
1) The admin webapp lies about Connector properties.
I'll update the mbean-descriptor.xml and admin page for Connector soon.

Amy

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


Re: cvs commit:jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/coreContainerBase.java StandardContext.java StandardWrapper.java

2003-07-29 Thread Amy Roh


Remy Maucherat wrote:
[EMAIL PROTECTED] wrote:

amyroh  2003/07/28 17:09:43

  Modified:catalina/src/share/org/apache/catalina/core
ContainerBase.java StandardContext.java
StandardWrapper.java
  Log:
  Send JSR77 spec required notifications for J2EE mbeans.


I like that feature, BTW (wether or not it is part of a spec).
Thanks for catching the typos.  :-)

Amy

Remy



-
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.0.5] New tag tomorrow ?

2003-07-24 Thread Amy Roh
+1

Amy

--- Remy Maucherat [EMAIL PROTECTED] wrote:
 To be able to reach beta quality around the end of
 this month, a new 
 milestone will need to be released at the end of
 this week (and more 
 generally, I think a one milestone per week schedule
 can't hurt when 
 trying to go to beta - even if we end up missing the
 deadline ;-) ).
 
 As usual, I'll populate the changelog. I'll also try
 to add some docs 
 content.
 
 Comments ?
 
 Remy
 
 
 

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


__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

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



RE: [5.0] Commons dependencies

2003-06-04 Thread Amy Roh
I don't think I have commons commit privilege.  Can you apply this one line patch?
 
The log should say - Fix to return String instead of ObjectName type for getObjectName 
following JSR77 spec.
 
cvs server: Diffing .
Index: BaseModelMBean.java
===
RCS file: /home/cvs/jakarta-commons/modeler/src/java/org/apache/commons/modeler/
BaseModelMBean.java,v
retrieving revision 1.22
diff -r1.22 BaseModelMBean.java
1325c1325
 return oname;
---
 return oname.toString();

Thanks,
Amy

Costin Manolache [EMAIL PROTECTED] wrote:
 There seem to be no bugs open for modeler in Bugzilla (Zarro Boogs
 found ;)), so the next step is a release vote it appears...

Yes. There is one problem that Amy reported few weeks ago - I don't know 
how it was resolved.


Costin


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


-
Do you Yahoo!?
Free online calendar with sync to Outlook(TM).

checkInterval for loader and manager

2003-05-27 Thread Amy Roh
Remy,

We don't have checkInterval attribute for loader and
manager after refactoring.  Should I remove it from
admin?  I see it's broken since then.

Thanks,
Amy 


HTTP Status 500 - Error retrieving attribute
checkInterval



*type* Status report

*message* _Error retrieving attribute checkInterval_

*description* _The server encountered an internal
error (Error retrieving attribute checkInterval) that
prevented it from fulfilling this request._ 

__
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com

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



Re: checkInterval for loader and manager

2003-05-27 Thread Amy Roh
I have fixed admin so checkInterval is no longer on the context pages.  I like your 
first name better than backgroundProcessorDelay ;-)


Remy Maucherat [EMAIL PROTECTED] wrote:

Amy Roh wrote:
 Remy,
 
 We don't have checkInterval attribute for loader and
 manager after refactoring. Should I remove it from
 admin? I see it's broken since then.

Ah, yes, sorry, I forgot to update admin :-(

All containers should get the new backgroundProcessorDelay attribute 
(if it's 0, they'll spawn a background process thread which will be 
used for them and their children, unless they themselves have a 0 value).

I have nothing against changing the backgroundProcessorDelay name 
(it's better than my first name, though ;-) ).

Remy


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



-
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.

Re: disable jmx option in tc5

2003-04-02 Thread Amy Roh
Costin Manolache wrote:
Amy Roh wrote:


Just out of curiosity, is there a simple way to disable jmx in tc5 other
than changing tomcat code to avoid registration/unregistration manually
which won't be trivial.


Just out of curiosity, why would you want to do this ?
I don't.  I was just thinking of different options to integrate tomcat 
into a product that already handles jsr77 code for webmodules.  just 
brain storming...

The whole point of using ( and requiring ) JMX is to simplify the
model. I know that right now it doesn't look simpler, especially since
some pieces are broken - but things are getting consistent and at least
in my opinion they'll be much simpler in the end.
I couldn't agree more.

Thanks,
Amy
A lot of the complexity in the current JMX stuff is related with the
2 config models - we need to support server.xml and direct API calls for
backward compat.
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: disable jmx option in tc5

2003-04-02 Thread Amy Roh


Costin Manolache wrote:
Amy Roh wrote:


Just out of curiosity, is there a simple way to disable jmx in tc5 other
than changing tomcat code to avoid registration/unregistration manually
which won't be trivial.


Just out of curiosity, why would you want to do this ?
I don't.  I was just thinking of different options to integrate tomcat
into a product that already handles jsr77 code for webmodules.  just
brain storming...


Hmmm. We could use the jsr77 option ( that is now in 4.1.x ) and generate
JSR77 names only if it is on. 

Or we could just use the other kind of names allways - and have a separate
module that re-register the objects with JSR77 names ( if needed ).
But the real issue is that a product shouldn't handle JSR77 for
webmodules,  that's plain wrong. The mbeans for WebModule and Servlet
must be handled by tomcat - who is the one that knows when a servlet 
or webmodule is instantiated  or removed or changes state, and can provide
usefull info ( statistics, etc ).
Yeah, I've already thought about the alternative.  It's not very pretty. 
 There can be lots of coordination problems. and it's missing the point.

BTW, how about that servlet unavilable error?  Were you able to figure 
out what's the problem?  Didn't see any commits on that.

A product that creates some wrappers or dummy objects with JSR77 names 
is useless - they'll have no real management value, since you would manage
the wrong components. 

The EJB container should handle the JSR77 components that are related with 
EJBs, and tomcat ( or whatever servlet implementation ) should handle the 
JSR77 for its components.

( jboss seems to be one case where jsr77 is implemented outside of the 
servlet container ).

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: TC5 Servlet unavailable error

2003-04-01 Thread Amy Roh


Costin Manolache wrote:
Amy Roh wrote:


Amy Roh wrote:


It seems like when context is stopped and restarted, servlet always
returns unavailable.  You can generate an error by saving your
changes
in admin by commit.  Then any process after that returns admin
servlet unavailalbe.
Mar 31, 2003 4:48:29 PM org.apache.catalina.core.StandardWrapperValve
invoke INFO: Servlet admin.login_jsp is currently unavailable


I tought I fixed it. Are you doing stop/destroy/init/start or just
stop/start ?
I'm not manually doing anything.  When I commit my changes in admin, I
think the admin context gets restarted and the application is set to
unavailable
right away.  Therefore any consequent requests fail.


I'll try to fix it - probably moving the unregister/register from destroy
to stop will do it.
Or maybe we can send a notification context reloading and have the mapper
reset its data ?
I'm not sure.  Are you able to reproduce it?


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]


disable jmx option in tc5

2003-04-01 Thread Amy Roh
Just out of curiosity, is there a simple way to disable jmx in tc5 other 
than changing tomcat code to avoid registration/unregistration manually 
which won't be trivial.

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


TC5 Servlet unavailable error

2003-03-31 Thread Amy Roh
It seems like when context is stopped and restarted, servlet always 
returns unavailable.  You can generate an error by saving your changes 
in admin by commit.  Then any process after that returns admin servlet 
unavailalbe.

Mar 31, 2003 4:48:29 PM org.apache.catalina.core.StandardWrapperValve invoke
INFO: Servlet admin.login_jsp is currently unavailable
Amy

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


Re: TC5 Servlet unavailable error

2003-03-31 Thread Amy Roh
 Amy Roh wrote:

  It seems like when context is stopped and restarted, servlet always
  returns unavailable.  You can generate an error by saving your changes
  in admin by commit.  Then any process after that returns admin servlet
  unavailalbe.
 
  Mar 31, 2003 4:48:29 PM org.apache.catalina.core.StandardWrapperValve
  invoke INFO: Servlet admin.login_jsp is currently unavailable


 I tought I fixed it. Are you doing stop/destroy/init/start or just
 stop/start ?

I'm not manually doing anything.  When I commit my changes in admin, I think
the admin context gets restarted and the application is set to unavailable
right away.  Therefore any consequent requests fail.


 The trick is to unregister and re-register the context, I think the
 mapper may hold references to the old wrappers.

 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: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core StandardPipeline.java

2003-03-28 Thread Amy Roh
 remm2003/03/28 06:58:08

   Modified:catalina/src/share/org/apache/catalina/core
 StandardPipeline.java
   Log:
   - Valves registration should only happen on start/stop, otherwise, the
container
 hierarchy may not be initialized.

Does this mean valves can't be added without stoping the container which
will have to remove dynamic valve creation/addition feature in admin?

Amy


   Revision  ChangesPath
   1.7   +7 -7
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/Standard
Pipeline.java

   Index: StandardPipeline.java
   ===
   RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/cor
e/StandardPipeline.java,v
   retrieving revision 1.6
   retrieving revision 1.7
   diff -u -r1.6 -r1.7
   --- StandardPipeline.java 27 Mar 2003 03:06:39 - 1.6
   +++ StandardPipeline.java 28 Mar 2003 14:58:08 - 1.7
   @@ -477,6 +477,8 @@
} catch (LifecycleException e) {
log.error(StandardPipeline.addValve: start: , e);
}
   +// Register the newly added valve
   +registerValve(valve);
}

// Add this Valve to the set associated with this Pipeline
   @@ -486,8 +488,6 @@
results[valves.length] = valve;
valves = results;
}
   -// register the newly added valve
   -registerValve(valve);

}

   @@ -602,9 +602,9 @@
} catch (LifecycleException e) {
log.error(StandardPipeline.removeValve: stop: , e);
}
   +// Unregister the removed valave
   +unregisterValve(valve);
}
   -// unregister the removed valave
   -unregisterValve(valve);

}





 -
 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: TC5 JMX

2003-03-25 Thread Amy Roh
 Amy Roh wrote:

  I moved the valve registration in addValve().
 
  Cool.  I think logger and realm registration should be in setLogger and
  setRealm as well so mbeans can get registered correctly.  Also,
  deregistration for old mbean should happen when new logger or realm is
  null.

 +1 :-)

 For the second part - deregistration should happen on stop().

 If you are going to implement this ( please ! ), don't worry about the
 embed use case, I'll fix it if there are problems.

So you haven't done logger/realm registration/deregistration?  I would hate
to duplicate what you already have in your workspace.  So let me know.  I
can add registration in start() and deregistration in stop().  Is there a
reason why LoggerBase doesn't implement Lifecycle?  Logger registration
won't be consistent since only FileLogger implements Lifecycle and not the
other two (SystemOut, SystemErr).



  I got reload() to work - but right now I'm stuck with some problems in
  stop()/start().
 
  Reload doesn't deal with modified web.xml - and for some reason
  stop()/start() finds some older mappers, something is not cleaning up.
 
  stop() does now remove all mbeans that it created.
 
  Awesome.  :-)

 Well, I finally got it working ( in standalone ). I had to create a new
 ServletContext, copy all the settings, then unregister and register again.

 It's a bit tricky - we have to unregister/register, otherwise the mapper
 will not work, and what's worse - it's almost impossible to undo all the
 actions that happen in init/start ( since many are driven by web.xml ).

This reminds me that the current mapper doesn't work if there isn't an
Engine with Catalina name since it's hard coded, right?

Amy


 I don't know how start/stop worked before ( or if it worked ), but
creating
 a new context seemes like a reasonable solution and may avoid some leaks
 or other problems.

 The negative is that extending StandardContext will become more tricky.

 I'll probably commit tommorow - I still need to remove a lot of debug
 statements and test in embeded case. ( I also checked Host.stop - it
 seems to clean up the JMX, I don't know yet if start() will recreate
 the same environemnt ).


 Costin

 
  Amy
 
 
  ( by now I mean my work version, I have a number of debug statements
  to remove and I'll check in ).
 
 
 
  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]




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



TC5 JMX

2003-03-24 Thread Amy Roh
Costin,

It doesn't seem like mbeans are created appropriately when logger, realm,
and valve are dynamically added after start.  Is the mbean registration code
listening to those events?  I see that logger/valve registration is done in
ContainerBase.start().  Also, the mbeans are not getting deregistered and
failed to be removed from admin.  Let me know what your plans are.  :-)

Thanks!
Amy


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



Re: TC5 JMX

2003-03-24 Thread Amy Roh
 Amy Roh wrote:

  Costin,
 
  It doesn't seem like mbeans are created appropriately when logger,
realm,
  and valve are dynamically added after start.  Is the mbean registration
  code listening to those events?

 It should.

 For valve - I think it works now ( I'll make a commit soon with few more
 fixes ). The registration happens in ContainerBase, when the valve is
added
 - and unregistration is also in ContainerBase when the vavle is removed.

   I see that logger/valve registration is done in
  ContainerBase.start().  Also, the mbeans are not getting deregistered
and
  failed to be removed from admin.  Let me know what your plans are.  :-)

 I moved the valve registration in addValve().

Cool.  I think logger and realm registration should be in setLogger and
setRealm as well so mbeans can get registered correctly.  Also,
deregistration for old mbean should happen when new logger or realm is null.


 I got reload() to work - but right now I'm stuck with some problems in
 stop()/start().

 Reload doesn't deal with modified web.xml - and for some reason
 stop()/start() finds some older mappers, something is not cleaning up.

 stop() does now remove all mbeans that it created.

Awesome.  :-)

Amy


 ( by now I mean my work version, I have a number of debug statements
 to remove and I'll check in ).



 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]



[Fwd: failure notice]

2003-03-18 Thread Amy Roh
FYI.  The change was too big to be posted.

 Original Message 
Subject: failure notice
Date: 18 Mar 2003 10:48:29 -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Hi. This is the qmail-send program at apache.org.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.
[EMAIL PROTECTED]:
ezmlm-reject: fatal: Sorry, I don't accept messages larger than 10 
bytes (#5.2.3)

--- Below this line is a copy of the message.

Return-Path: [EMAIL PROTECTED]
Received: (qmail 43645 invoked by uid 500); 18 Mar 2003 10:48:29 -
Delivered-To: [EMAIL PROTECTED]
Received: (qmail 43618 invoked from network); 18 Mar 2003 10:48:28 -
Received: from icarus.apache.org (208.185.179.13)
  by daedalus.apache.org with SMTP; 18 Mar 2003 10:48:28 -
Received: (qmail 24363 invoked by uid 1290); 18 Mar 2003 10:48:27 -
Date: 18 Mar 2003 10:48:27 -
Message-ID: [EMAIL PROTECTED]
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: cvs commit: 
jakarta-tomcat-catalina/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/valve 
AddValveAction.java DeleteValvesAction.java ValveUtil.java
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

amyroh  2003/03/18 02:48:26

  Modified:webapps/admin/WEB-INF web.xml
   webapps/admin/WEB-INF/classes/org/apache/webapp/admin
Lists.java SetUpTreeAction.java
TomcatTreeBuilder.java TreeControlNode.java
webapps/admin/WEB-INF/classes/org/apache/webapp/admin/connector
AddConnectorAction.java DeleteConnectorAction.java
DeleteConnectorsAction.java
SaveConnectorAction.java
webapps/admin/WEB-INF/classes/org/apache/webapp/admin/context
AddContextAction.java DeleteContextAction.java
DeleteContextsAction.java EditContextAction.java
SaveContextAction.java
webapps/admin/WEB-INF/classes/org/apache/webapp/admin/defaultcontext
AddDefaultContextAction.java
DeleteDefaultContextAction.java
DeleteDefaultContextsAction.java
EditDefaultContextAction.java
SaveDefaultContextAction.java
   webapps/admin/WEB-INF/classes/org/apache/webapp/admin/host
DeleteHostAction.java DeleteHostsAction.java
EditHostAction.java SaveHostAction.java
   webapps/admin/WEB-INF/classes/org/apache/webapp/admin/logger
AddLoggerAction.java DeleteLoggerAction.java
DeleteLoggersAction.java SaveLoggerAction.java
   webapps/admin/WEB-INF/classes/org/apache/webapp/admin/realm
AddRealmAction.java DeleteRealmsAction.java
EditRealmAction.java SaveJDBCRealmAction.java
SaveJNDIRealmAction.java SaveMemoryRealmAction.java
SaveUserDatabaseRealmAction.java
webapps/admin/WEB-INF/classes/org/apache/webapp/admin/resources
DeleteDataSourcesAction.java
DeleteEnvEntriesAction.java
DeleteMailSessionsAction.java
DeleteResourceLinksAction.java
DeleteUserDatabasesAction.java
ListDataSourcesAction.java
ListEnvEntriesAction.java
ListMailSessionsAction.java
ListResourceLinksAction.java ResourceUtils.java
ResourcesTreeBuilder.java SaveDataSourceAction.java
SaveEnvEntryAction.java SaveMailSessionAction.java
SaveResourceLinkAction.java
SaveUserDatabaseAction.java
webapps/admin/WEB-INF/classes/org/apache/webapp/admin/service
DeleteServiceAction.java DeleteServicesAction.java
SaveServiceAction.java
   webapps/admin/WEB-INF/classes/org/apache/webapp/admin/users
UsersTreeBuilder.java
   webapps/admin/WEB-INF/classes/org/apache/webapp/admin/valve
AddValveAction.java DeleteValvesAction.java
ValveUtil.java
  Log:
  Partial work towards to synch up MBean ObjectNames without service 
attribute.
  Need to deprecate the usage of MBeanFactory and use Catalina components'
  JMX calls instead.



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


Re: /admin

2003-03-17 Thread Amy Roh
Costin Manolache wrote:
The admin app is now mostly broken - I did a small try to get it running,
but it'll take more work.
Amy - I would appreciate your help :-)
Okie.  I'll try to synch up the mbean names this week.  :-)

Amy

There are still several components that need to be changed - the biggest
problem at the moment is that some components are using the Engine name
and some are using the default from mbeans-descriptors.
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: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalinaServerFactory.java

2003-03-17 Thread Amy Roh
Costin Manolache wrote:
Mladen Turk wrote:


What I ment was a catalina.bat or catalina.sh embedded
calling o.a.c.s.Embedded


I think Embedded class should be deprecated in 5.0, and all
'embedding' should be done via JMX.
-1 for deprecating the current Embedded class.

I totally agree that JMX is very flexible and powerful way to go and I 
think it's great. :-)  However, for backward compatibility I don't think 
we should just deprecate it easily and force whoever was using tomcat 
Embedded class to change his/her implementation to use JMX.

Amy

I haven't tested Embedded recently ( but it was working about a 
week ago ). 

You can create your own main() ( or use the small startup class in
modeler ) and load an mbeans.xml file. 

Controlling everything via JMX is much more flexible and powerfull
than using wrappers or helpers like Embedded.
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: /admin - what needs to be done

2003-03-17 Thread Amy Roh
Costin Manolache wrote:
The biggest change will be getting rid of all direct references and casts to
catalina classes - and use JMX consistently.
I don't think admin uses direct references to catalina classes at all. 
It was planned so that managedResource attribute (which corresponds to 
mbean's catalina object) from all mbeans were removed from the 
descriptor so that admin doesn't have an access to the catalina objects. 
 :-)

It should _never_ do direct calls to any tomcat class - only JMX 
Yes.

Amy



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]


  1   2   3   >