[RESULT] Build 6.0.14

[Remy Maucherat]

5 stable votes, no other votes.

Rémy

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

Fwd: Tomcat 6.0.13 - NPE in AprEndpoint run method

[Sriram Narayanan]

Hello Tomcat Developers:

We faced this issue today, and this is preventing us from moving to
Tomcat 6.0.13.

Should I file a bug report ? Would sending a patch help ? Or is the
issue something else ?

-- Sriram

-- Forwarded message --
From: Reich, Matthias <[EMAIL PROTECTED]>
Date: Jul 18, 2007 2:01 PM
Subject: Tomcat 6.0.13 - NPE in AprEndpoint run method
To: Tomcat Users List <[EMAIL PROTECTED]>



Hi,

When sending requests to Tomcat during the startup phase, I got a NPE in
the AprEndpoint run method, line 1495:

 getPoller().add(socket);

This can happen because in the start method, the pollers are initialized
after the acceptor threads already have been started so that the
getPoller() call can either run into a NPE itself (if the pollers array
is not yet initialized) or return null (if pollers[pollerRoundRobin] is
not yet initialized.

Thus, I think the error can easily be prevented by starting the
acceptors after initializing the pollers.

Regards,
Matthias

-
To start a new topic, 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: Fwd: Tomcat 6.0.13 - NPE in AprEndpoint run method

[Remy Maucherat]

Sriram Narayanan wrote:

When sending requests to Tomcat during the startup phase, I got a NPE in
the AprEndpoint run method, line 1495:

 getPoller().add(socket);

This can happen because in the start method, the pollers are initialized
after the acceptor threads already have been started so that the
getPoller() call can either run into a NPE itself (if the pollers array
is not yet initialized) or return null (if pollers[pollerRoundRobin] is
not yet initialized.

Thus, I think the error can easily be prevented by starting the
acceptors after initializing the pollers.


Yes, there's no reason to start the accept thread first.

Rémy

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

Re: [VOTE] Releasing Tomcat Connectors 1.2.25

[Guenter Knauf]

Hi,
> Apache Tomcat Connectors 1.2.25 is:

> [x] Stable - no major issues, no regressions

Guen.



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

svn commit: r563905 - /tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java

[remm]

Author: remm
Date: Wed Aug  8 07:55:33 2007
New Revision: 563905

URL: http://svn.apache.org/viewvc?view=rev&rev=563905
Log:
- As suggested by a couple people, start accepting after starting everything 
else, to avoid running into non 
  initialized fields.

Modified:
tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java

Modified: tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java?view=diff&rev=563905&r1=563904&r2=563905
==
--- tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java 
(original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java Wed 
Aug  8 07:55:33 2007
@@ -725,14 +725,6 @@
 workers = new WorkerStack(maxThreads);
 }
 
-// Start acceptor threads
-for (int i = 0; i < acceptorThreadCount; i++) {
-Thread acceptorThread = new Thread(new Acceptor(), getName() + 
"-Acceptor-" + i);
-acceptorThread.setPriority(threadPriority);
-acceptorThread.setDaemon(daemon);
-acceptorThread.start();
-}
-
 // Start poller threads
 pollers = new Poller[pollerThreadCount];
 for (int i = 0; i < pollerThreadCount; i++) {
@@ -767,6 +759,15 @@
 sendfileThread.start();
 }
 }
+
+// Start acceptor threads
+for (int i = 0; i < acceptorThreadCount; i++) {
+Thread acceptorThread = new Thread(new Acceptor(), getName() + 
"-Acceptor-" + i);
+acceptorThread.setPriority(threadPriority);
+acceptorThread.setDaemon(daemon);
+acceptorThread.start();
+}
+
 }
 }
 



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

svn commit: r563911 - /tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml

[remm]

Author: remm
Date: Wed Aug  8 08:05:25 2007
New Revision: 563911

URL: http://svn.apache.org/viewvc?view=rev&rev=563911
Log:
- Update changelog.

Modified:
tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml

Modified: tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml?view=diff&rev=563911&r1=563910&r2=563911
==
--- tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml (original)
+++ tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml Wed Aug  8 08:05:25 2007
@@ -48,6 +48,14 @@
   
 
   
+  
+
+  
+In the APR connector, start accepting connections after fully starting
+the connector, to prevent possible exceptions due to non initialized 
fields. (remm)
+  
+
+  
   
 
   



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

Re: 6.x feature wishlist

[Remy Maucherat]

Bill Barker wrote:
2. Add a block/no-block parameter to InputFilter.doRead and 
OutputFilter.doWrite
   InputFilter -> public int doRead(ByteChunk chunk, Request unused, 
boolean block) throws IOException;
   OutputFilter -> public int doWrite(ByteChunk chunk, Response unused, 
boolean block) throws IOException;
   Servlet 3.0 will most likely expose non blocking read/write through the 
servlet API, this will get us there ahead of time
   Haven't thought of how we expose this API yet though, but more will 
follow


I agree with Remy here.  We should do it when we know that Servlet 3.0 
requires it.  Until then, the transport layer should be opaque to the 
Servlet container.  That is how Coyote is currently designed (i.e. if 
somebody had an itch to resurect the JNI Channel for Windows (IIS/Httpd) for 
AJP/1.3, would this even be meaningful?).


I'd like to clarify that I am working on non blocking functionality (to 
implement my withdrawn API proposal), but I meant I don't see any 
business at this point exposing the possibility of partial writes in any 
API, since it would mean some higher level code would have to deal with 
this additional complexity, maybe up to the servlet layer. I believe 
partial writes can be handled well enough without this strategy.



4. Startup -> server.xml warnings
  If one enters an invalid element or attribute that is simply ignored 
today, at least output an info or warn message letting the

  admin know if its misconfiguration.



You can get the attributes now by setting debug logging on 
o.a.t.u.IntrospectionUtils.  It wouldn't be hard to do in general (e.g. make 
IntrospectionUtils.setAttribute return boolean instead of void, and warn in 
Digester.startElement if no rules are configured, but make the later 
configurable so that the TC shutdown digester doesn't produce a ton of 
warnings).  However, it means that our fork of Digester increasingly moves 
away from c-d.


This would be a great strategy (and there's no reason not to include it 
in the current 6.0.x branch if it's simple). I'll play with it and see 
what it does.


Rémy

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

Re: svn commit: r562194 - in /tomcat/connectors/trunk/jk: native/common/jk_ajp13.h native/common/jk_ajp_common.c native/common/jk_lb_worker.c xdocs/miscellaneous/changelog.xml xdocs/reference/workers

[Jim Jagielski]

On Aug 2, 2007, at 4:29 PM, Rainer Jung wrote:

And in fact it doesn't matter. I found it more logical, to have  
JK_STATUS_ERROR and JK_STATUS_FATAL_ERROR closer together (for  
those reading the code). The constants are not used outside JK, so  
there is no compatibility problem.


It looks like your are closely following todays JK changes. I  
really appreciate that! Unless you find problems, I just now  
commited my last change (hopefully) for 1.2.25.


A other little nit: The see a few places where
we have things like (in jk_lb_worker.c for example):

   &(p->lb_workers[0].s->route[0])

Can't they simply be reduced to

   p->lb_workers[0].s->route

?

Not exactly sure what I'm missing there...

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

svn commit: r563925 - /tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java

[fhanik]

Author: fhanik
Date: Wed Aug  8 09:00:07 2007
New Revision: 563925

URL: http://svn.apache.org/viewvc?view=rev&rev=563925
Log:
forward port from 6.0

Modified:
tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java

Modified: tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java?view=diff&rev=563925&r1=563924&r2=563925
==
--- tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java (original)
+++ tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java Wed Aug  8 
09:00:07 2007
@@ -725,14 +725,6 @@
 workers = new WorkerStack(maxThreads);
 }
 
-// Start acceptor threads
-for (int i = 0; i < acceptorThreadCount; i++) {
-Thread acceptorThread = new Thread(new Acceptor(), getName() + 
"-Acceptor-" + i);
-acceptorThread.setPriority(threadPriority);
-acceptorThread.setDaemon(daemon);
-acceptorThread.start();
-}
-
 // Start poller threads
 pollers = new Poller[pollerThreadCount];
 for (int i = 0; i < pollerThreadCount; i++) {
@@ -767,6 +759,15 @@
 sendfileThread.start();
 }
 }
+
+// Start acceptor threads
+for (int i = 0; i < acceptorThreadCount; i++) {
+Thread acceptorThread = new Thread(new Acceptor(), getName() + 
"-Acceptor-" + i);
+acceptorThread.setPriority(threadPriority);
+acceptorThread.setDaemon(daemon);
+acceptorThread.start();
+}
+
 }
 }
 



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

Re: svn commit: r562194 - in /tomcat/connectors/trunk/jk: native/common/jk_ajp13.h native/common/jk_ajp_common.c native/common/jk_lb_worker.c xdocs/miscellaneous/changelog.xml xdocs/reference/worker

[Rainer Jung]

You are missing nothing. Feel free to scratch :)

Regards,

Rainer

Jim Jagielski wrote:


On Aug 2, 2007, at 4:29 PM, Rainer Jung wrote:

And in fact it doesn't matter. I found it more logical, to have 
JK_STATUS_ERROR and JK_STATUS_FATAL_ERROR closer together (for those 
reading the code). The constants are not used outside JK, so there is 
no compatibility problem.


It looks like your are closely following todays JK changes. I really 
appreciate that! Unless you find problems, I just now commited my last 
change (hopefully) for 1.2.25.


A other little nit: The see a few places where
we have things like (in jk_lb_worker.c for example):

   &(p->lb_workers[0].s->route[0])

Can't they simply be reduced to

   p->lb_workers[0].s->route

?

Not exactly sure what I'm missing there...


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

Re: 6.x feature wishlist

[atul]

Bill,

Thanks for your response.

I think it was true for the older browsers but with most new versions it should 
be configurable.
I tried it with Mozilla Firefox 2.0 and it asks me everytime. The setting is 
under options ---> advanced tab --> Encryption ---> Certificates - When website 
requires certificate : Ask me every time.

On the server side I simply used 

certs = (X509Certificate[])
m_Request.getAttribute("javax.servlet.request.X509Certificate");
if ((certs == null) || (certs.length < 1))
certs = (X509Certificate[])
m_Request.getAttribute("org.apache.coyote.request.X509Certificate");


I am sure other browsers such as IE 6? 7 will have similar setting.

Please let me know if any further info is needed.

Thanks
A t u l


- Original Message 
From: Bill Barker <[EMAIL PROTECTED]>
To: dev@tomcat.apache.org
Sent: Tuesday, August 7, 2007 10:01:46 PM
Subject: Re: 6.x feature wishlist


For most browsers, this won't really work.  Most browsers treat CLIENT-CERT 
login the same way that they treat BASIC, so once they have authenticated, 
they won't ask the user again, and just re-send the same credentials.  It is 
easy enough to write a Valve to do this, but as I said, it won't work the 
way you want it to.  As such, I'd be against including it in Tomcat unless 
you can write such a Valve and show that it works.

"atul" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
I was wondering if a feature to achieve SSL "logout" would make it in here 
too !

SSL Logout :

Provide a way to session-tear-off/logout for an authenticated session using 
X509Certificate based client/mutual SSL. So that when the user tries to 
access a protected resource again without closing the browser (user agent), 
the server re-negotiates ssl and ask for client certificate.

I was not able to find this in any of Tomcat 4.x, 5.x Or 6.x.
This would be great feature and I know quiet a few people are looking for 
it.

Thanks
A t u l


- Original Message 
From: Filip Hanik - Dev Lists <[EMAIL PROTECTED]>
To: Tomcat Developers List 
Sent: Monday, August 6, 2007 10:36:24 PM
Subject: 6.x feature wishlist


I wanted to start a wish list of what we can move forward with, here is
a short list of items that I had in mind as a starter

1. Session replication - stateless backup location
   Store the backup location of a session as part of the sessionId,
similar to the jvmRoute but opposite.
   This way, you can scale a cluster horizontally, since the location of
the backup node doesn't have to be known until you fail over.

2. Add a block/no-block parameter to InputFilter.doRead and
OutputFilter.doWrite
InputFilter -> public int doRead(ByteChunk chunk, Request unused,
boolean block) throws IOException;
OutputFilter -> public int doWrite(ByteChunk chunk, Response unused,
boolean block) throws IOException;
Servlet 3.0 will most likely expose non blocking read/write through
the servlet API, this will get us there ahead of time
Haven't thought of how we expose this API yet though, but more will
follow

3. Consolidate connector code
   Currently we have
Http11Processor/Http11NioProcessor/Http11AprProcessor doing almost the
same thing, there is much that
   can be consolidated to make the code more maintainable
   Essentially, you create a Endpoint base line interface.
   At the same time we could consolidate the Internal(In/Out)put buffers
as they are copies too.
   We have some fairly tuned endpoints now, it would also be nice to
make these protocol agnostic.

4. Startup -> server.xml warnings
   If one enters an invalid element or attribute that is simply ignored
today, at least output an info or warn message letting the
   admin know if its misconfiguration.

5. Finish bayeux -> I started this in sandbox, took me a while to
understand the protocol, and its not as cool as I thought it would be
   but I still feel its important for it to be part of Tomcat

6. Auto context logging
   Automatically create loggers for each context, so that one doesn't
have to specify one per context in logging.properties
   Of course, you can turn on/off the auto context logger through
logging.properties

7. File cache - use MappedByteBuffers for the file cache, that way the
send file operation can benefit even more
   when you have two direct buffers, and you also avoid reading the disk
each time for a file
   ideas on this came from Jeanfrancois Arcand.

(http://fisheye5.cenqua.com/browse/glassfish/appserv-http-engine/src/java/com/sun/enterprise/web/connector/grizzly/FileCache.java?r=1.21)

8. Add getName()/setName() to the WebappClassLoader, name of the web app
classloader will correspond to the one of the Context container
   Applications like Terracotta or AOP apps can much easier plug in and
be able to share data when they know what loader the class came from

9. Add the configuration option to start the connectors after all apps
are deployed
   If some applications are taking long to startup, load balanc

Re: svn commit: r562194 - in /tomcat/connectors/trunk/jk: native/common/jk_ajp13.h native/common/jk_ajp_common.c native/common/jk_lb_worker.c xdocs/miscellaneous/changelog.xml xdocs/reference/worker

[Jim Jagielski]

:)

It just seemed like a conscious coding style and didn't want
to confuse things...

Or else it was some normal C array/pointer confusion :)
*duck*

On Aug 8, 2007, at 12:09 PM, Rainer Jung wrote:


You are missing nothing. Feel free to scratch :)

Regards,

Rainer

Jim Jagielski wrote:

On Aug 2, 2007, at 4:29 PM, Rainer Jung wrote:
And in fact it doesn't matter. I found it more logical, to have  
JK_STATUS_ERROR and JK_STATUS_FATAL_ERROR closer together (for  
those reading the code). The constants are not used outside JK,  
so there is no compatibility problem.


It looks like your are closely following todays JK changes. I  
really appreciate that! Unless you find problems, I just now  
commited my last change (hopefully) for 1.2.25.

A other little nit: The see a few places where
we have things like (in jk_lb_worker.c for example):
   &(p->lb_workers[0].s->route[0])
Can't they simply be reduced to
   p->lb_workers[0].s->route
?
Not exactly sure what I'm missing 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: 6.x feature wishlist

[Remy Maucherat]

Remy Maucherat wrote:
You can get the attributes now by setting debug logging on 
o.a.t.u.IntrospectionUtils.  It wouldn't be hard to do in general 
(e.g. make IntrospectionUtils.setAttribute return boolean instead of 
void, and warn in Digester.startElement if no rules are configured, 
but make the later configurable so that the TC shutdown digester 
doesn't produce a ton of warnings).  However, it means that our fork 
of Digester increasingly moves away from c-d.


This would be a great strategy (and there's no reason not to include it 
in the current 6.0.x branch if it's simple). I'll play with it and see 
what it does.


After experimenting, this works great, but (there's a but) there's a 
glitch with the fake "className" attribute (or whatever replacement is 
used to pass to the object creation rule).


I don't know how to avoid it in a simple way without a hack. Bill, any 
ideas ?


Rémy

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

DO NOT REPLY [Bug 43062] New: - jvmtiEventVMDeath event doesn't return in JVMTI when shutting down tomcat 6 as a service.

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

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

   Summary: jvmtiEventVMDeath event doesn't return in JVMTI when
shutting down tomcat 6 as a service.
   Product: Tomcat 6
   Version: 6.0.13
  Platform: PC
OS/Version: Windows XP
Status: NEW
  Severity: critical
  Priority: P2
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I am working on a Java profiler using JVMTI interface provided by JDK 5 and 
above. I always get abnormal termination of tomcat 6 as service when stopping 
it. I ran through DevStudio debugger and found the callback of 
jvmtiEventVMDeath in JVMTI is never activated when shutting down tomcat 6 and 
an unhandled exception is caught. It doesn't happen on tomcat 5.5 as service 
and also it works fine with tomcat 6 as commandline. I have asked this question 
to tomcat-user/developer list but no response.Is there something about shutting 
down the server different between 6 and 5.5 to make this happen?

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

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

May Chun Chew/FEA/PEC is out of the office.

[May Chun Chew]

I will be out of the office starting  08/09/2007 and will not return until
08/13/2007.

For urgent matters, pls contact [EMAIL PROTECTED] Tel:
(65)63629408
I am also Contactable at (65)97876648.


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

status of trunk

[Filip Hanik - Dev Lists]

what is the plan for trunk? the reason I started the 6.x feature list 
was to get some development going for the next version of Tomcat.
Remy was the one who initiated trunk and suggested future development to 
go in there.


Is there anything but the disagreement around the CometEvent interface 
holding this back?
There are already several enhancements in trunk that are not in 6.0, not 
comet related, but if we are not moving trunk forward, then its time to 
merge the branches back to 6.0.x


personally I would prefer
1. resolve the issue around the CometEvent interface, (it was resolved 
when Remy pulled back his proposal, but from what I understand, its 
coming back)

2. continue future development in trunk

thoughts...
Filip

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

Re: 6.x feature wishlist

[Filip Hanik - Dev Lists]

Remy Maucherat wrote:

Filip Hanik - Dev Lists wrote:
I wanted to start a wish list of what we can move forward with, here 
is a short list of items that I had in mind as a starter


Here's my opinion on these. I think most of them are not a good idea, 
actually.



1. Session replication - stateless backup location
  Store the backup location of a session as part of the sessionId, 
similar to the jvmRoute but opposite.
  This way, you can scale a cluster horizontally, since the location 
of the backup node doesn't have to be known until you fail over.


No idea about that.

2. Add a block/no-block parameter to InputFilter.doRead and 
OutputFilter.doWrite
   InputFilter -> public int doRead(ByteChunk chunk, Request unused, 
boolean block) throws IOException;
   OutputFilter -> public int doWrite(ByteChunk chunk, Response 
unused, boolean block) throws IOException;
   Servlet 3.0 will most likely expose non blocking read/write 
through the servlet API, this will get us there ahead of time
   Haven't thought of how we expose this API yet though, but more 
will follow


I think it's too early to speculate on what the Servlet API may add, 
and I don't see any benefit this would bring at this point. I am 
managing to implement non blocking functionality without major 
problems without these additional calls. I also think your API 
proposal for Comet in trunk is inappropriate, and I will come back 
with my original proposal, which I like more and more. So -1 for this 
one.
bummer, this community has always been against any kind of non blocking 
stuff. well, it will bite us later :)



3. Consolidate connector code
  Currently we have 
Http11Processor/Http11NioProcessor/Http11AprProcessor doing almost 
the same thing, there is much that

  can be consolidated to make the code more maintainable
  Essentially, you create a Endpoint base line interface.
  At the same time we could consolidate the Internal(In/Out)put 
buffers as they are copies too.
  We have some fairly tuned endpoints now, it would also be nice to 
make these protocol agnostic.


This has been tried before (I was supporting it), but the endpoints 
(and connectors) have a fairly different processing logic. The result 
was actually more complex than the original version, so I removed it. 
-1 too.
APR and NIO are almost identical, in other words, when I wrote the NIO 
crap, I copied the APR code, and then replaced any native with java.nio
but I can see how this is a pain, but at some point, it would be nice to 
have a more modular system and reuse more of the code



4. Startup -> server.xml warnings
  If one enters an invalid element or attribute that is simply 
ignored today, at least output an info or warn message letting the

  admin know if its misconfiguration.


That's going to be hard to do in a consistent way.

apparently not :), you're already experimenting with it


5. Finish bayeux -> I started this in sandbox, took me a while to 
understand the protocol, and its not as cool as I thought it would be

  but I still feel its important for it to be part of Tomcat


Ok. You could try to come up with something better if you think it's 
not good enough.
yes, the downside is the client support, that's where the sticky issue. 
I could do something better for the server, but who would use it if 
there is no client.
so I'll continue with this, however, we need to resolve the CometEvent 
interface issue first



6. Auto context logging
  Automatically create loggers for each context, so that one doesn't 
have to specify one per context in logging.properties
  Of course, you can turn on/off the auto context logger through 
logging.properties


I don't like that:
- very little logging occurs through the context logger (or maybe it's 
a default for the whole webapp like if you added a file handler in 
logging.properties ?)
- JULI already provides a separate logging environment for the webapp 
(because it uses a separate classloader), and webapps interested in 
that can easily configure it using a logging.properties
- JULI specific (if this is actually done, I would like to remove 
log4j support)
- and most importantly, would automagically be creating zillions of 
small logfiles, so I like the idea of people configuring it in better 
than configuring it out
it would be configurable of course, its an added option, and I've seen 
the usage requested. Since its configurable and you can decide to use it 
or not, I don't see why we wouldn't offer it


7. File cache - use MappedByteBuffers for the file cache, that way 
the send file operation can benefit even more
  when you have two direct buffers, and you also avoid reading the 
disk each time for a file

  ideas on this came from Jeanfrancois Arcand.
  
(http://fisheye5.cenqua.com/browse/glassfish/appserv-http-engine/src/java/com/sun/enterprise/web/connector/grizzly/FileCache.java?r=1.21) 



I dislike gimmick cache functionality inside the connector (worst 
Grizzly idea ever ...), where actually the overh

svn commit: r564046 - /tomcat/tc6.0.x/trunk/webapps/docs/extras.xml

[markt]

Author: markt
Date: Wed Aug  8 16:45:21 2007
New Revision: 564046

URL: http://svn.apache.org/viewvc?view=rev&rev=564046
Log:
Fix typos.
Play with wording.
Add note about license for wsdl4j.jar

Modified:
tomcat/tc6.0.x/trunk/webapps/docs/extras.xml

Modified: tomcat/tc6.0.x/trunk/webapps/docs/extras.xml
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/webapps/docs/extras.xml?view=diff&rev=564046&r1=564045&r2=564046
==
--- tomcat/tc6.0.x/trunk/webapps/docs/extras.xml (original)
+++ tomcat/tc6.0.x/trunk/webapps/docs/extras.xml Wed Aug  8 16:45:21 2007
@@ -31,9 +31,9 @@
 
   
   
-A number of additional third party components may be used with Apache 
Tomcat, but are not
-provided directly in the downlad bundle for a variety of reasons. These 
may be built by
-users should they need it.
+A number of additional third party components may be used with Apache
+Tomcat, but are not provided directly in the download bundle. These
+components may be built by users should they need them.
   
 
   
@@ -41,18 +41,21 @@
   
 
 
-  The additional components are built using the extras.xml 
Ant script which is
-  present in the source bundle of Tomcat.
+  The additional components are built using the extras.xml Ant
+  script which is present in the source bundle of Tomcat.
 
 
 The build process is the following:
 
 
-Follow the build instructions to build a 
Tomcat binary from
-the source bundle (note: it will be used by the build process of the 
additional components, but
-does not need to be actually used later on)
-Execute the command ant -f extras.xml to run the build 
script
-The additional components JARs will be placed in the 
output/extras folder
+Follow the build instructions to build a
+Tomcat binary from the source bundle (note: it will be used by the 
build
+process of the additional components, but does not need to be actually
+used later on)
+Execute the command ant -f extras.xml to run the build
+script
+The additional components JARs will be placed in the
+output/extras folder
 Refer to the documentation below about the usage of these JARs
 

@@ -63,10 +66,12 @@
   
 
   
-Tomcat uses a package renamed commons-logging API implementation which is 
hardcoded to use
-the java.util.logging API. The commons-logging additional component builds 
a full fledged
-package renames commons-logging implementation which can be used to 
replace the implementation
-provided with Tomcat. See the logging page for 
usage instructions.
+Tomcat uses a package renamed commons-logging API implementation which is
+hardcoded to use the java.util.logging API. The commons-logging additional
+component builds a full fledged package renames commons-logging
+implementation which can be used to replace the implementation provided 
with
+Tomcat. See the logging page for usage
+instructions.
   
 
   
@@ -74,9 +79,15 @@
   
 
   
-Tomcat provides factories for JSR 109 which may be used to resolve web 
services references.
-Place the generated catalina-ws.jar as well as jaxrpc.jar and wsdl4j.jar 
(or another implementation
-of JSR 109) in the Tomcat lib folder.
+Tomcat provides factories for JSR 109 which may be used to resolve web
+services references. Place the generated catalina-ws.jar as well as
+jaxrpc.jar and wsdl4j.jar (or another implementation of JSR 109) in the
+Tomcat lib folder.
+  
+
+  
+Users should be aware that wsdl4j.jar is licenced under CPL 1.0 and not the
+Apache License version 2.0.
   
 
   



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

svn commit: r564069 [1/2] - in /tomcat/trunk/java/org/apache/catalina/ha: ./ authenticator/ deploy/ jmx/ session/ tcp/

[fhanik]

Author: fhanik
Date: Wed Aug  8 18:54:34 2007
New Revision: 564069

URL: http://svn.apache.org/viewvc?view=rev&rev=564069
Log:
Setup framework for cluster JMX operations


Added:
tomcat/trunk/java/org/apache/catalina/ha/jmx/
tomcat/trunk/java/org/apache/catalina/ha/jmx/ClusterJmxHelper.java
Modified:

tomcat/trunk/java/org/apache/catalina/ha/authenticator/mbeans-descriptors.xml
tomcat/trunk/java/org/apache/catalina/ha/deploy/mbeans-descriptors.xml
tomcat/trunk/java/org/apache/catalina/ha/mbeans-descriptors.xml
tomcat/trunk/java/org/apache/catalina/ha/session/mbeans-descriptors.xml
tomcat/trunk/java/org/apache/catalina/ha/tcp/SimpleTcpCluster.java
tomcat/trunk/java/org/apache/catalina/ha/tcp/mbeans-descriptors.xml

Modified: 
tomcat/trunk/java/org/apache/catalina/ha/authenticator/mbeans-descriptors.xml
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/ha/authenticator/mbeans-descriptors.xml?view=diff&rev=564069&r1=564068&r2=564069
==
--- 
tomcat/trunk/java/org/apache/catalina/ha/authenticator/mbeans-descriptors.xml 
(original)
+++ 
tomcat/trunk/java/org/apache/catalina/ha/authenticator/mbeans-descriptors.xml 
Wed Aug  8 18:54:34 2007
@@ -1,25 +1,23 @@
 
 
-
-  
-
-
-
-
-
-
-
+  
+
+
+
   
-
 

Modified: tomcat/trunk/java/org/apache/catalina/ha/deploy/mbeans-descriptors.xml
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/ha/deploy/mbeans-descriptors.xml?view=diff&rev=564069&r1=564068&r2=564069
==
--- tomcat/trunk/java/org/apache/catalina/ha/deploy/mbeans-descriptors.xml 
(original)
+++ tomcat/trunk/java/org/apache/catalina/ha/deploy/mbeans-descriptors.xml Wed 
Aug  8 18:54:34 2007
@@ -1,11 +1,10 @@
 
 
-  
-  
+type="org.apache.catalina.ha.deploy.FarmWarDeployer">  
 

Added: tomcat/trunk/java/org/apache/catalina/ha/jmx/ClusterJmxHelper.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/ha/jmx/ClusterJmxHelper.java?view=auto&rev=564069
==
--- tomcat/trunk/java/org/apache/catalina/ha/jmx/ClusterJmxHelper.java (added)
+++ tomcat/trunk/java/org/apache/catalina/ha/jmx/ClusterJmxHelper.java Wed Aug  
8 18:54:34 2007
@@ -0,0 +1,130 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ * 
+ *  http://www.apache.org/licenses/LICENSE-2.0
+ * 
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.catalina.ha.jmx;
+
+import org.apache.tomcat.util.modeler.Registry;
+import org.apache.catalina.ha.CatalinaCluster;
+import org.apache.juli.logging.Log;
+import org.apache.juli.logging.LogFactory;
+import org.apache.catalina.ha.tcp.SimpleTcpCluster;
+import org.apache.catalina.ha.session.DeltaManager;
+import org.apache.catalina.ha.deploy.FarmWarDeployer;
+import org.apache.catalina.ha.authenticator.ClusterSingleSignOn;
+import org.apache.catalina.core.StandardHost;
+import javax.management.ObjectName;
+import org.apache.catalina.core.StandardEngine;
+import javax.management.MBeanServerFactory;
+import javax.management.MBeanServer;
+import javax.management.modelmbean.ModelMBean;
+import org.apache.tomcat.util.modeler.ManagedBean;
+import javax.management.DynamicMBean;
+
+public class ClusterJmxHelper {
+
+protected static Registry registry = Registry.getRegistry(null,null);
+
+protected static Log log = LogFactory.getLog(ClusterJmxHelper.class);
+
+protected static boolean jmxEnabled = true;
+
+protected static MBeanServer mbeanServer = null;
+
+public static Registry getRegistry() {
+return registry;
+}
+
+public static MBeanServer getMBeanServer() throws Exception {
+if (mbeanServer == null) {
+if (MBeanServerFactory.findMBeanServer(null).size() > 0) {
+mbeanServer = (MBeanServer) 
MBeanServerFactory.findMBeanServer(null).get(0);
+} else {
+mbeanServer = MBeanServerFactory.createMBeanServer();
+}
+}
+return mbeanServer;
+}
+
+protected static boolean initMetaData(Class clazz) {
+try {
+if (clazz==null) return false;
+   

Re: 6.x feature wishlist

[Bill Barker]

"Remy Maucherat" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> Remy Maucherat wrote:
>>> You can get the attributes now by setting debug logging on 
>>> o.a.t.u.IntrospectionUtils.  It wouldn't be hard to do in general (e.g. 
>>> make IntrospectionUtils.setAttribute return boolean instead of void, and 
>>> warn in Digester.startElement if no rules are configured, but make the 
>>> later configurable so that the TC shutdown digester doesn't produce a 
>>> ton of warnings).  However, it means that our fork of Digester 
>>> increasingly moves away from c-d.
>>
>> This would be a great strategy (and there's no reason not to include it 
>> in the current 6.0.x branch if it's simple). I'll play with it and see 
>> what it does.
>
> After experimenting, this works great, but (there's a but) there's a 
> glitch with the fake "className" attribute (or whatever replacement is 
> used to pass to the object creation rule).
>
> I don't know how to avoid it in a simple way without a hack. Bill, any 
> ideas ?
>

We're pretty consistant in our attribute names in server.xml, so while it 
isn't the cleanest solution, it should work for us.  How about adding to 
Digester (depending on taste) either
setFakeAttributes(String [] names)
or
setFakeAttributes(List names)
The second lets us hide the lookup in List.contains, the first makes the 
caller simplier for a small list of exclusions.  Then 
Digester.addSetProperties can pass it on to the setPropertiesRule.

If this was for c-d, then we'd probably need:
   setFakeAttributes(Map> names)
but that seems like overkill for our fork of Digester.

> Rémy 




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

svn commit: r564071 - /tomcat/trunk/java/org/apache/catalina/ha/jmx/ClusterJmxHelper.java

[fhanik]

Author: fhanik
Date: Wed Aug  8 18:58:50 2007
New Revision: 564071

URL: http://svn.apache.org/viewvc?view=rev&rev=564071
Log:
remove not used fields

Modified:
tomcat/trunk/java/org/apache/catalina/ha/jmx/ClusterJmxHelper.java

Modified: tomcat/trunk/java/org/apache/catalina/ha/jmx/ClusterJmxHelper.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/ha/jmx/ClusterJmxHelper.java?view=diff&rev=564071&r1=564070&r2=564071
==
--- tomcat/trunk/java/org/apache/catalina/ha/jmx/ClusterJmxHelper.java 
(original)
+++ tomcat/trunk/java/org/apache/catalina/ha/jmx/ClusterJmxHelper.java Wed Aug  
8 18:58:50 2007
@@ -111,13 +111,10 @@
 private static ObjectName getDefaultClusterName(SimpleTcpCluster cluster) 
throws Exception {
 String domain = getMBeanServer().getDefaultDomain();
 String type = ":type=";
-boolean hostParent = false;
-//Step 1. Register the Cluster MBean
 String clusterType= type+"Cluster";
 if (cluster.getContainer() instanceof StandardHost) {
 domain = ((StandardHost) cluster.getContainer()).getDomain();
 clusterType += ",host=" + cluster.getContainer().getName();
-hostParent = true;
 } else {
 if (cluster.getContainer() instanceof StandardEngine) {
 domain = ((StandardEngine) cluster.getContainer()).getDomain();



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

svn commit: r564074 - /tomcat/trunk/java/org/apache/catalina/ha/jmx/ClusterJmxHelper.java

[fhanik]

Author: fhanik
Date: Wed Aug  8 19:06:32 2007
New Revision: 564074

URL: http://svn.apache.org/viewvc?view=rev&rev=564074
Log:
remove throwing of exceptions, handle everything inside the JMX helper

Modified:
tomcat/trunk/java/org/apache/catalina/ha/jmx/ClusterJmxHelper.java

Modified: tomcat/trunk/java/org/apache/catalina/ha/jmx/ClusterJmxHelper.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/ha/jmx/ClusterJmxHelper.java?view=diff&rev=564074&r1=564073&r2=564074
==
--- tomcat/trunk/java/org/apache/catalina/ha/jmx/ClusterJmxHelper.java 
(original)
+++ tomcat/trunk/java/org/apache/catalina/ha/jmx/ClusterJmxHelper.java Wed Aug  
8 19:06:32 2007
@@ -100,12 +100,17 @@
 }
 }
 
-public static boolean unregisterDefaultCluster(SimpleTcpCluster cluster) 
throws Exception {
-ObjectName clusterName = getDefaultClusterName(cluster);
-if (getMBeanServer().isRegistered(clusterName)) {
-getMBeanServer().unregisterMBean(clusterName);
+public static boolean unregisterDefaultCluster(SimpleTcpCluster cluster) {
+try {
+ObjectName clusterName = getDefaultClusterName(cluster);
+if (getMBeanServer().isRegistered(clusterName)) {
+getMBeanServer().unregisterMBean(clusterName);
+}
+return true;
+}catch ( Exception x ) {
+log.warn("Unable to unregister default cluster implementation with 
JMX",x);
+return false;
 }
-return true;
 }
 
 private static ObjectName getDefaultClusterName(SimpleTcpCluster cluster) 
throws Exception {



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