RE: thread deadlock problem
Hi Antonio, Are you absolutely sure of that? Could you please triple-check it? A System.out.println(something) at the *very* beginning of the doGet/doPost method would be enough. Yeah. I'm basing it on the timestamps in the log4j log messages (which I've never yet seen to be wrong). And I've verified it numerous times. Strange... Unlikely... but possible... Yeah, that's what I thought too. And you would not make your writer wait, so your process would be faster, wouldn't it? Yes, it would be faster (at least theoretically, although in practice blocking doesn't occur unless the pipe fills up...so by tuning the size of your pipe you should be able to come up with something that is just as fast, in XX% of the cases). The downside of writing the whole thing to memory is that in this small percentage of scenarios, the entire document gets written to memory first, and if its a report that is hundreds of pages long, its possible to run your server out of memory under load. So the piped approach (if I could get it to work), would be preferable, even if there's a slight hit on throughput. But if I can't, I can live with the in-memory version. Christian -- Christian Cryder Internet Architect, ATMReports.com Project Chair, BarracudaMVC - http://barracudamvc.org -- Coffee? I could quit anytime, just not today -Original Message- From: Antonio Fiol Bonnin [mailto:[EMAIL PROTECTED] Sent: Sunday, March 21, 2004 3:42 AM To: Tomcat Users List Subject: Re: thread deadlock problem Christian Cryder wrote: This works perfectly about 99% of the time. What we are observing is that there are certain situations where we encounter a deadlock scenario (and that's what prompted my original question). Basically, req2a writes the redirect back to the client, the client receives the redirect and actually sends a request back to the server (verified this by using a proxy to examine what is getting sent)... BUT - if req2a is already in the blocking code, tomcat simply does not accept req3 until the blocking code times out! Bad. Are you absolutely sure of that? Could you please triple-check it? A System.out.println(something) at the *very* beginning of the doGet/doPost method would be enough. Without seeing the code, I'd say there is a missing notifyAll() or notify() somewhere, to wake up the thread that is wait()'ing. Now what's interesting is that tomcat itself is not blocked at this point - I can send requests from other browsers, and those get handled just fine. So something seems to be happening where Tomcat cannot accept this particular request (req3), perhaps because its still trying to keep the physical connection associated with req2a open(?) (I'm thinking keep-alives here...in other words, if the browser is using keep-alives, req3 will be coming across the same physical connection as req2a, so its almost like tomcat thinks it still can't receive a new request across this connection, although the browser thinks its fine to go ahead and send it). But after req2a writes the redirect response to the browser, I close the writer and flush the buffer - there's nothing else I can do to say hey, I really am done with that response (even though I'm going to continue running in the background on the server and writing additional data - the real response, the report - to a memory structure). Strange... Unlikely... but possible... One easy solution is just to modify our piped reader/writer so that when the pipe size gets maxed it simply expands the size of the pipe. This would mean that we'd never actually have to block, so we'd never hit our deadlock. The downside is that it now means that in some cases we might be significantly increasing the size of our memory footprint for the server. Another option, I suppose, would be to simply pipe the document to disk, rather than storing it to memory. And you would not make your writer wait, so your process would be faster, wouldn't it? HTH, Antonio Fiol - 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]
thread deadlock problem
Hi folks,
I need to know if someone can explain the following behavior:
1. client browser issues a request
2. tomcat servlet code starts handling the request...
a. writes an html redirect to the resp, flushes the buffer, etc
b. thread continues processing (writing to a data structure)
3. client browser receives 2a response and generates another request...
a. reads data out of the data structure populated by 2b
What's happening is that 2b fills up the structure and then blocks, waiting
until 3a reads some of the data out, so that it can continue. The blocking
code looks like this:
...check to see if data pipe still full
...timeout if we've waited too long
notifyAll();
try {
wait(1000);
Thread.yield();
} catch (InterruptedException ex) {
throw new java.io.InterruptedIOException();
}
Now what is happening is that in certain situations, the request for 3a
never gets accepted by the server until 2b times out. I'm trying to
understand why (and what to do about it). I have verified that the client
not only receives the response from 2a, but it actually issues the request
for 3a. Nevertheless, once Tomcat is in this blocking code (above) it does
not seem to accept requests from this particular browser window, -UNTIL- 2b
times out.
Can anyone explain this to me? Should I be blocking/yielding in some other
fashion? Why won't Tomcat accept my subsequent requests when I'm in this
blocking code?
What I'm looking for more than just that's a stupid thing to do - I'm
hoping someone can either
a) explain the nitty-gritty of how tomcat handles writing the code back to
the browser (and telling the browser that everything is complete) in the
case where the thread may actually need to continue running for a longer
period of time -or-
b) offer some constructive suggestions as to where I should start looking in
the tomcat code to answer those questions myself
Any suggestions would be greatly appreciated...
tia,
Christian
--
Christian Cryder
Internet Architect, ATMReports.com
Project Chair, BarracudaMVC - http://barracudamvc.org
--
Coffee? I could quit anytime, just not today
-
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: thread deadlock problem
never actually have to block, so we'd never hit our deadlock. The
downside is that it now means that in some cases we might be significantly
increasing the size of our memory footprint for the server. Another option,
I suppose, would be to simply pipe the document to disk, rather than storing
it to memory.
I can (and will) look at both of these if need be, but first I'd prefer to
hear if there is something obvious that exlains the behavior of tomcat - I'd
really like to understand why what we're doing only deadlocks in a very
small percentage of our cases. I'd like to understand why our blocking code
does not allow tomcat to continue (as I'd expect), and why tomcat can't turn
around and accept req3 from the browser in this situation.
Long answer to a short question, but hopefully that helps flesh things out.
THanks much,
CHristian
--
Christian Cryder
Internet Architect, ATMReports.com
Project Chair, BarracudaMVC - http://barracudamvc.org
--
Coffee? I could quit anytime, just not today
-Original Message-
From: Edson Alves Pereira [mailto:[EMAIL PROTECTED]
Sent: Friday, March 19, 2004 8:00 AM
To: 'Tomcat Users List'
Subject: RE: thread deadlock problem
Why are you trying to do this kind of control?
--
De: Christian Cryder[SMTP:[EMAIL PROTECTED]
Responder: Tomcat Users List
Enviada:sexta-feira, 19 de março de 2004 9:55
Para: Tomcat-User
Assunto:thread deadlock problem
Hi folks,
I need to know if someone can explain the following behavior:
1. client browser issues a request
2. tomcat servlet code starts handling the request...
a. writes an html redirect to the resp, flushes the buffer, etc
b. thread continues processing (writing to a data structure)
3. client browser receives 2a response and generates another request...
a. reads data out of the data structure populated by 2b
What's happening is that 2b fills up the structure and then blocks,
waiting
until 3a reads some of the data out, so that it can continue.
The blocking
code looks like this:
...check to see if data pipe still full
...timeout if we've waited too long
notifyAll();
try {
wait(1000);
Thread.yield();
} catch (InterruptedException ex) {
throw new java.io.InterruptedIOException();
}
Now what is happening is that in certain situations, the request for 3a
never gets accepted by the server until 2b times out. I'm trying to
understand why (and what to do about it). I have verified that
the client
not only receives the response from 2a, but it actually issues
the request
for 3a. Nevertheless, once Tomcat is in this blocking code
(above) it does
not seem to accept requests from this particular browser window, -UNTIL-
2b
times out.
Can anyone explain this to me? Should I be blocking/yielding in
some other
fashion? Why won't Tomcat accept my subsequent requests when I'm in this
blocking code?
What I'm looking for more than just that's a stupid thing to do - I'm
hoping someone can either
a) explain the nitty-gritty of how tomcat handles writing the
code back to
the browser (and telling the browser that everything is complete) in the
case where the thread may actually need to continue running for a longer
period of time -or-
b) offer some constructive suggestions as to where I should
start looking
in
the tomcat code to answer those questions myself
Any suggestions would be greatly appreciated...
tia,
Christian
--
Christian Cryder
Internet Architect, ATMReports.com
Project Chair, BarracudaMVC - http://barracudamvc.org
--
Coffee? I could quit anytime, just not today
-
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: thread deadlock problem
is the thread mentioned in 2b the same as the one that handled 2a ?
Yep, same thread.
--
Christian Cryder
Internet Architect, ATMReports.com
Project Chair, BarracudaMVC - http://barracudamvc.org
--
Coffee? I could quit anytime, just not today
-Original Message-
From: Hans [mailto:[EMAIL PROTECTED]
Sent: Friday, March 19, 2004 8:21 AM
To: Tomcat Users List
Subject: Re: thread deadlock problem
hi,
is the thread mentioned in 2b the same as the one that handled 2a ?
grtz
Hans
At 07:55 19/03/2004 -0500, you wrote:
Hi folks,
I need to know if someone can explain the following behavior:
1. client browser issues a request
2. tomcat servlet code starts handling the request...
a. writes an html redirect to the resp, flushes the buffer, etc
b. thread continues processing (writing to a data structure)
3. client browser receives 2a response and generates another request...
a. reads data out of the data structure populated by 2b
What's happening is that 2b fills up the structure and then
blocks, waiting
until 3a reads some of the data out, so that it can continue.
The blocking
code looks like this:
...check to see if data pipe still full
...timeout if we've waited too long
notifyAll();
try {
wait(1000);
Thread.yield();
} catch (InterruptedException ex) {
throw new java.io.InterruptedIOException();
}
Now what is happening is that in certain situations, the request for 3a
never gets accepted by the server until 2b times out. I'm trying to
understand why (and what to do about it). I have verified that the client
not only receives the response from 2a, but it actually issues
the request
for 3a. Nevertheless, once Tomcat is in this blocking code
(above) it does
not seem to accept requests from this particular browser window,
-UNTIL- 2b
times out.
Can anyone explain this to me? Should I be blocking/yielding in
some other
fashion? Why won't Tomcat accept my subsequent requests when I'm in this
blocking code?
What I'm looking for more than just that's a stupid thing to do - I'm
hoping someone can either
a) explain the nitty-gritty of how tomcat handles writing the
code back to
the browser (and telling the browser that everything is complete) in the
case where the thread may actually need to continue running for a longer
period of time -or-
b) offer some constructive suggestions as to where I should
start looking in
the tomcat code to answer those questions myself
Any suggestions would be greatly appreciated...
tia,
Christian
--
Christian Cryder
Internet Architect, ATMReports.com
Project Chair, BarracudaMVC - http://barracudamvc.org
--
Coffee? I could quit anytime, just not today
-
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: thread deadlock problem
Hi Hans,
is performed repeatedly in a while lus?
Yep. It's basically the same as Sun's PipedReader/PipedWriter, but modified
to support the notion of a configurable pipe size and a timeout. I am
attaching the actual classes so you can see them (cf. line 218 in
BetterPipedReader)
What's the notifyAll doing there by the way?
Well, its in there because the Sun code had it in there. My understanding of
what's going on is that if the writer blocks it does a notifyAll to wake up
any pending readers, and the readers do something similar when they read (to
wake up any pending writers that may be blocked because the pipe was full).
My understanding of their use of wait is a little shakier - I thought that
substituting sleep(xxx) instead would basically do the same thing, but it
doesn't - the whole thing craps out then. So I left it as wait()
And is this code being executed in a synchronized block?
Yep. Its happening in
protected synchronized void receive(int c)
But the writer thread (req2a) is the only thread calling this method. The
reader thread (req3 - when it gets there) will be calling
public synchronized int read()
Its interesting to me that the way Sun has implemented this, they don't
actually have to synchronize access to the underlying data structure (a
char[]) - they just have 2 indexes: one for read position and one for write
position. I thought was kind of clever. But they are still synching on the
methods, so I'm not sure whether they're actually gaining much in
performance or not.
Christian
--
Christian Cryder
Internet Architect, ATMReports.com
Project Chair, BarracudaMVC - http://barracudamvc.org
--
Coffee? I could quit anytime, just not today
-Original Message-
From: Hans [mailto:[EMAIL PROTECTED]
Sent: Friday, March 19, 2004 9:33 AM
To: Tomcat Users List
Subject: RE: thread deadlock problem
ok,
and can you give some more details on the blocking code.
I assume :
...check to see if data pipe still full
...timeout if we've waited too long
notifyAll();
try {
wait(1000);
Thread.yield();
} catch (InterruptedException ex) {
throw new java.io.InterruptedIOException();
}
is performed repeatedly in a while lus?
What's the notifyAll doing there by the way?
And is this code being executed in a synchronized block?
grtz
Hans
At 09:01 19/03/2004 -0500, you wrote:
is the thread mentioned in 2b the same as the one that handled 2a ?
Yep, same thread.
--
Christian Cryder
Internet Architect, ATMReports.com
Project Chair, BarracudaMVC - http://barracudamvc.org
--
Coffee? I could quit anytime, just not today
-Original Message-
From: Hans [mailto:[EMAIL PROTECTED]
Sent: Friday, March 19, 2004 8:21 AM
To: Tomcat Users List
Subject: Re: thread deadlock problem
hi,
is the thread mentioned in 2b the same as the one that handled 2a ?
grtz
Hans
At 07:55 19/03/2004 -0500, you wrote:
Hi folks,
I need to know if someone can explain the following behavior:
1. client browser issues a request
2. tomcat servlet code starts handling the request...
a. writes an html redirect to the resp, flushes the buffer, etc
b. thread continues processing (writing to a data structure)
3. client browser receives 2a response and generates another
request...
a. reads data out of the data structure populated by 2b
What's happening is that 2b fills up the structure and then
blocks, waiting
until 3a reads some of the data out, so that it can continue.
The blocking
code looks like this:
...check to see if data pipe still full
...timeout if we've waited too long
notifyAll();
try {
wait(1000);
Thread.yield();
} catch (InterruptedException ex) {
throw new java.io.InterruptedIOException();
}
Now what is happening is that in certain situations, the
request for 3a
never gets accepted by the server until 2b times out. I'm trying to
understand why (and what to do about it). I have verified
that the client
not only receives the response from 2a, but it actually issues
the request
for 3a. Nevertheless, once Tomcat is in this blocking code
(above) it does
not seem to accept requests from this particular browser window,
-UNTIL- 2b
times out.
Can anyone explain this to me? Should I be blocking/yielding in
some other
fashion? Why won't Tomcat accept my subsequent requests when
I'm in this
blocking code?
What I'm looking for more than just that's a stupid thing
to do - I'm
hoping someone can either
a) explain the nitty-gritty of how tomcat handles writing the
code
RE: Session not destroyed after server shutdown
Hi Jake! But this means everything you put in the session needs to be serializable, right? I don't think this impacts Barracuda (because I don't think its saving anything in the session - just creating the OR wrappers over the session), but we might want to check. Of course, we can continue that conversation on the bmvc list... Christian -- Christian Cryder Internet Architect, ATMReports.com Project Chair, BarracudaMVC - http://barracudamvc.org -- Coffee? I could quit anytime, just not today -Original Message- From: Jacob Kjome [mailto:[EMAIL PROTECTED] Sent: Friday, March 19, 2004 10:20 AM To: Tomcat Users List Subject: Re: Session not destroyed after server shutdown Sessions aren't destroyed until the session times out. If you shut the server down, existing sessions will be written to file. If you bring the server back up before the timeout of those sessions, they will still exist upon server restart. If you think about it, this is usually desired behavior. I believe you can turn this off on the Coyote connector, but I've forgotten how. I can't imagine why you wouldn't want it to work this way. What if you were doing emergency server maintainance and had to restart the app while some users were connected. Blowing away their sessions would normally be undesired. You can always delete the work directory for the app if you actually do desire to blow away sessions as well. Jake Quoting Joao Batistella [EMAIL PROTECTED]: Hello! I'm using Tomcat 4 and all sessions that I have when the server is up are not destroyed when I shutdown te server. I've implemented a ServletContextListener to register when the app is going down and a HttpSessionListener to see when a session is destroyed. When the server goes down the sessions are not destroyed and, when it comes up again, the sessions are still there. If I try to get a session attribute by some key before setting the same attribute I have a result different of null. Anyone knows what is this? My sofwate versions: Windows XP Professional Tomcat 4.1.29-LE J2sdk 1.4.2 Thanks, JP - 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]
Configuring Tomcat connections
Can someone offer some suggestions on configuring the number of connections Tomcat 4.1 will accept? I am using a stress tester to access the sample servlet (http://localhost:8080/examples/servlet/HelloWorldExample). Somewhere around 14-15 concurrent requests, I start seeing java.net.ConnectException: Connection refused: connect Looking in the Tomcat server.xml file, I see Connector className=org.apache.coyote.tomcat4.CoyoteConnector port=8080 minProcessors=5 maxProcessors=75 enableLookups=true redirectPort=8443 acceptCount=10 debug=0 connectionTimeout=2 useURIValidationHack=false / I assume this is the connector I'm going through (since my URL is referring to port 8080). According to the docs (http://jakarta.apache.org/tomcat/tomcat-4.1-doc/config/webapp.html) acceptCount and maxProcessors should affect this behavior, but I am not seeing any changes when I adjust them upwards. Should I be looking elsewhere? Anyone have any suggestions? Thanks, Christian -- Christian Cryder Internet Architect, ATMReports.com Project Chair, BarracudaMVC - http://barracudamvc.org -- Coffee? I could quit anytime, just not today - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Configuring Tomcat connections
Ok, so I tried upgrading to Tomcat 5.0.16, and I am still seeing similar results (slightly better). I am hitting the standard HelloWorld servlet (http://localhost:8080/servlets-examples/servlet/HelloWorldExample). When I get over about 16-17 simultaneous connections, I start getting connect expections. I am using the default server configuration from server.xml (and once again, changing these values does not seem to make any difference whatsoever): Connector port=8080 maxThreads=150 minSpareThreads=25 maxSpareThreads=75 enableLookups=false redirectPort=8443 acceptCount=100 debug=0 connectionTimeout=2 disableUploadTimeout=true / So how come I can't get more than 20 connections at a time? What gives??? Christian (I am running on Win2K Pro, by the way; latest service packs, 512 MB Ram) -- Christian Cryder Internet Architect, ATMReports.com Project Chair, BarracudaMVC - http://barracudamvc.org -- Coffee? I could quit anytime, just not today -Original Message- From: Christian Cryder [mailto:[EMAIL PROTECTED] Sent: Thursday, January 15, 2004 2:32 PM To: Tomcat-User Subject: Configuring Tomcat connections Can someone offer some suggestions on configuring the number of connections Tomcat 4.1 will accept? I am using a stress tester to access the sample servlet (http://localhost:8080/examples/servlet/HelloWorldExample). Somewhere around 14-15 concurrent requests, I start seeing java.net.ConnectException: Connection refused: connect Looking in the Tomcat server.xml file, I see Connector className=org.apache.coyote.tomcat4.CoyoteConnector port=8080 minProcessors=5 maxProcessors=75 enableLookups=true redirectPort=8443 acceptCount=10 debug=0 connectionTimeout=2 useURIValidationHack=false / I assume this is the connector I'm going through (since my URL is referring to port 8080). According to the docs (http://jakarta.apache.org/tomcat/tomcat-4.1-doc/config/webapp.html) acceptCount and maxProcessors should affect this behavior, but I am not seeing any changes when I adjust them upwards. Should I be looking elsewhere? Anyone have any suggestions? Thanks, Christian -- Christian Cryder Internet Architect, ATMReports.com Project Chair, BarracudaMVC - http://barracudamvc.org -- Coffee? I could quit anytime, just not today - 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]
Tomcat 4.1 ignoring -Xmx params
Hey folks, has anyone observed scenarios where Tomcat appears to ignore the -Xmx param? We are running 4.1 as a service on Win 2000 Pro, and have manually uninstalled/reinstalled the tomcat service as follows: to uninstall: - tomcat.exe -uninstall Apache Tomcat 4.1 to install: - tomcat -install Apache Tomcat 4.1 E:\sun\j2sdk1.4.1_01\jre\bin\client\jvm.dll -Xmx256m -Xms128m -Djava.class .path=D:\Program Files\Apache Group\Tomcat 4.1\bin\bootstrap.jar -Dcatalina.home=D:\Program Files\Apache Group\Tomcat 4.1 -Djava.endorsed.dirs=D:\Program Files\Apache Group\Tomcat 4.1\common\endorsed -start org.apache.catalina.startup.BootstrapService -params start -stop org.apache.catalina.startup.BootstrapService -params stop -out D:\Program Files\Apache Group\Tomcat 4.1\logs\stdout.log -err D:\Program Files\Apache Group\Tomcat 4.1\logs\stderr.log What we are seeing here is that everything seems to work just fine, but Tomcat does not seem to stop at the 256m max that we are requesting? Is this to be expected? Or are we doing something stupid? Thanks much, Christian -- Christian Cryder [[EMAIL PROTECTED]] Internet Architect, ATMReports.com Barracuda - http://barracudamvc.org -- Coffee? I could quit anytime, just not today -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Tomcat 4.1 ignoring -Xmx params
What we are doing is running Tomcat as a service on a production server; we specify both -Xmx and -Xms values. What we are seeing is that after several days of use, Tomcat is well over the max, by a magnitude of 100+ MB. Our experience has been that when we run it manually it seems to stay within the bounds, but when running as a service it seems to go beyond them. So perhaps we're not installing the service correctly... Christian -- Christian Cryder [[EMAIL PROTECTED]] Internet Architect, ATMReports.com Barracuda - http://barracudamvc.org -- Coffee? I could quit anytime, just not today -Original Message- From: Hari Venkatesan [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 28, 2003 10:02 AM To: Tomcat Users List Subject: RE: Tomcat 4.1 ignoring -Xmx params How did you find out it is ignoring -Xmx parameter. Initially when you start up tomcat, it would allocate only the minimum heap that you set in -Xms. Hari -Original Message- From: Christian Cryder [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 28, 2003 11:49 AM To: Tomcat-User Subject: Tomcat 4.1 ignoring -Xmx params Hey folks, has anyone observed scenarios where Tomcat appears to ignore the -Xmx param? We are running 4.1 as a service on Win 2000 Pro, and have manually uninstalled/reinstalled the tomcat service as follows: to uninstall: - tomcat.exe -uninstall Apache Tomcat 4.1 to install: - tomcat -install Apache Tomcat 4.1 E:\sun\j2sdk1.4.1_01\jre\bin\client\jvm.dll -Xmx256m -Xms128m - Djava.class .path=D:\Program Files\Apache Group\Tomcat 4.1\bin\bootstrap.jar -Dcatalina.home=D:\Program Files\Apache Group\Tomcat 4.1 -Djava.endorsed.dirs=D:\Program Files\Apache Group\Tomcat 4.1\common\endorsed -start org.apache.catalina.startup.BootstrapService -params start -stop org.apache.catalina.startup.BootstrapService -params stop -out D:\Program Files\Apache Group\Tomcat 4.1\logs\stdout.log -err D:\Program Files\Apache Group\Tomcat 4.1\logs\stderr.log What we are seeing here is that everything seems to work just fine, but Tomcat does not seem to stop at the 256m max that we are requesting? Is this to be expected? Or are we doing something stupid? Thanks much, Christian -- Christian Cryder [[EMAIL PROTECTED]] Internet Architect, ATMReports.com Barracuda - http://barracudamvc.org -- Coffee? I could quit anytime, just not today -- To unsubscribe, e-mail: mailto:tomcat-user- [EMAIL PROTECTED] For additional commands, e-mail: mailto:tomcat-user- [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Tomcat 4.1 ignoring -Xmx params
As an aside, and this applies for windows as well as linux/solaris: -Xms and -Xmx control the size of the JVM heap. That's not the total JVM size. There are other spaces, e.g. the stack, symbol tables, and OS process overhead, that contribute to the overall process size. How much they contribute depends on the OS version, JDK version, and other things, and is very difficult to predict precisely. You can measure it at any given point by comparing the output from an OS-level top (e.g. top on linux, or the task manager in windows) to the output of Runtime.getRuntime().totalMemory(). You will always see a difference. Excellent point, and one I had considered. So if you're basing your assertion that -Xmx is ignored on the output of an OS-level tool, please rethink your assertion in light of the above. Ok, so this _is_ what I'm basing it on (looking at MS's Task manager). BUT...it still doesn't seem reasonable that the actual memory used is 150 MB than the limit specified to the JVM. In other words, if I tell the JVM -Xmx512 and the OS Task Mgr is reporting that Tomcat is using 670 MB, doesn't this seem like more than just an overhead issue? I'm perfectly content if that is in fact the answer, I'm just trying to confirm whether or not we have a problem. Any suggestions? tia, Christian -- Christian Cryder [[EMAIL PROTECTED]] Internet Architect, ATMReports.com Barracuda - http://barracudamvc.org -- Coffee? I could quit anytime, just not today -Original Message- From: Shapira, Yoav [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 28, 2003 10:21 AM To: Tomcat Users List Subject: RE: Tomcat 4.1 ignoring -Xmx params Howdy, As an aside, and this applies for windows as well as linux/solaris: -Xms and -Xmx control the size of the JVM heap. That's not the total JVM size. There are other spaces, e.g. the stack, symbol tables, and OS process overhead, that contribute to the overall process size. How much they contribute depends on the OS version, JDK version, and other things, and is very difficult to predict precisely. You can measure it at any given point by comparing the output from an OS-level top (e.g. top on linux, or the task manager in windows) to the output of Runtime.getRuntime().totalMemory(). You will always see a difference. So if you're basing your assertion that -Xmx is ignored on the output of an OS-level tool, please rethink your assertion in light of the above. If you're basing it on the actual Runtime.totalMemory() output, then you are correct in saying you likely did not install tomcat correctly. Yoav Shapira Millennium ChemInformatics -Original Message- From: Christian Cryder [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 28, 2003 12:10 PM To: Tomcat Users List Subject: RE: Tomcat 4.1 ignoring -Xmx params What we are doing is running Tomcat as a service on a production server; we specify both -Xmx and -Xms values. What we are seeing is that after several days of use, Tomcat is well over the max, by a magnitude of 100+ MB. Our experience has been that when we run it manually it seems to stay within the bounds, but when running as a service it seems to go beyond them. So perhaps we're not installing the service correctly... Christian -- Christian Cryder [[EMAIL PROTECTED]] Internet Architect, ATMReports.com Barracuda - http://barracudamvc.org -- Coffee? I could quit anytime, just not today -Original Message- From: Hari Venkatesan [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 28, 2003 10:02 AM To: Tomcat Users List Subject: RE: Tomcat 4.1 ignoring -Xmx params How did you find out it is ignoring -Xmx parameter. Initially when you start up tomcat, it would allocate only the minimum heap that you set in -Xms. Hari -Original Message- From: Christian Cryder [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 28, 2003 11:49 AM To: Tomcat-User Subject: Tomcat 4.1 ignoring -Xmx params Hey folks, has anyone observed scenarios where Tomcat appears to ignore the -Xmx param? We are running 4.1 as a service on Win 2000 Pro, and have manually uninstalled/reinstalled the tomcat service as follows: to uninstall: - tomcat.exe -uninstall Apache Tomcat 4.1 to install: - tomcat -install Apache Tomcat 4.1 E:\sun\j2sdk1.4.1_01\jre\bin\client\jvm.dll -Xmx256m -Xms128m - Djava.class .path=D:\Program Files\Apache Group\Tomcat 4.1\bin\bootstrap.jar -Dcatalina.home=D:\Program Files\Apache Group\Tomcat 4.1 -Djava.endorsed.dirs=D:\Program Files\Apache Group\Tomcat 4.1\common\endorsed -start org.apache.catalina.startup.BootstrapService -params start -stop org.apache.catalina.startup.BootstrapService -params stop -out D
security-constraint problems
Hi folks! I'm observing a couple of problems with security-constraints, and I'd like to know wether I'm encountering bugs in Tomcat or simply doing something stupid. Here are the details: I have a constraint that is setup like this: security-constraint web-resource-collection web-resource-nameTest/web-resource-name url-pattern/servlet/HelloWorld/url-pattern url-pattern*.event/url-pattern /web-resource-collection auth-constraint role-nameUser/role-name /auth-constraint /security-constraint 1. URL patterns with wildcards do not seem to be matching. For instance, given a url of http://localhost:8080/MyApp/GoHome.event, when I use the following url patterns, I do not get challenged: url-pattern/*.event/url-pattern url-pattern*.event/url-pattern If I use the specific url, however: url-pattern/GoHome.event/url-pattern then it does in fact work and I get prompted for user/pwd as expected. So my question is, am I doing somethign wrong or is this in fact a bug? 2. When I try and access Tomcat directly on port 8080 using http://localhost:8080/MyApp/servlet/HelloWorld, I get challenged as expected. When I try to access the exact same URL through IIS using http://localhost/MyApp/servlet/HelloWorld, I don't get challenged at all; I just immediately get an access denied error message. If I remove the url pattern for /servlet/HelloWorld, then I can access it just fine through IIS, which tells me that the isapi redirection is working ok. Again, am I doing something wrong, or is this a bug? Should role based authentication work when integrating Tomcat with IIS? Thanks, Christian -- Christian Cryder [[EMAIL PROTECTED]] Internet Architect, ATMReports.com Barracuda - http://barracuda.enhydra.org -- What a great time to be a(n employed) Geek -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
JNDI problems
Hi folks,
Ok, I'm using Tomcat 4.0.1, and am trying to access a JDBC datasource via
JNDI. I've tried to study the docs before asking stupid questions, but I'm
completely stuck right now and am hoping someone can see what I'm doing
wrong.
The primary resources that I've been using include:
1. http://jakarta.apache.org/tomcat/tomcat-4.0-doc/jndi-resources-howto.html
2. http://www.j-netdirect.com/JSQLTechRef.htm#J2EE_DataSource
Based on the instructions, my server.xml defines a resource like this:
!-- Test99 Context --
Context path=/Test99 docBase=E:\Test99 debug=1
Resource name=jdbc/Test99DB auth=Container
type=javax.sql.DataSource/
ResourceParams name=jdbc/Test99DB
parameter
namedatabase/namevaluepubs/value
/parameter
parameter
namedriverClassName/namevaluecom.jnetdirect.jsql.JSQLDataSource/value
/parameter
parameter
namedriverName/namevaluejdbc:JSQLConnect:/value
/parameter
parameter
nameuser/namevaluesa/value
/parameter
parameter
namepassword/namevalue/value
/parameter
/ResourceParams
/Context
My Test99 webapp's web.xml in turn defines a resource like this:
resource-ref
descriptionSample JDBC Resource/description
res-ref-namejdbc/Test99DB/res-ref-name
res-typejavax.sql.DataSource/res-type
res-authContainer/res-auth
/resource-ref
And finally, my servlet code looks like this:
initCtx = new InitialContext();
envCtx = (Context) initCtx.lookup(java:comp/env);
ds = (DataSource) envCtx.lookup(jdbc/Test99DB);
When I run this, initCtx and envCtx both seem to get loaded properly
(they're not null). When I try to lookup the DataSource, however, it always
comes back as null. When I add some debugging stmts, like this:
System.out.println(initCtx:+initCtx);
System.out.println(envCtx:+envCtx);
NamingEnumeration enum = envCtx.list(jdbc/);
while (enum.hasMore()) {System.out.println( -- +enum.next());}
System.out.println(ds:+ds);
here's the output I get:
initCtx:javax.naming.InitialContext@5ddb6e
envCtx:org.apache.naming.NamingContext@71235b
-- Test99DB: org.apache.naming.ResourceRef
ds:null
So it looks like JNDI is working and the resource is available; why then is
ds coming back as null? Am I doing something stupid? I'm really confused on
this one; if you have any suggestions I'd love to hear from you.
tia,
Christian
--
Christian Cryder [[EMAIL PROTECTED]]
Internet Architect, ATMReports.com
Barracuda - http://barracuda.enhydra.org
--
What a great time to be a(n employed) Geek
--
To unsubscribe: mailto:[EMAIL PROTECTED]
For additional commands: mailto:[EMAIL PROTECTED]
Troubles with the list: mailto:[EMAIL PROTECTED]
RE: Accessing Manager app through URLConnection
I was able to get it to work by following the instructions in Craigs email.
I'm attaching a couple of classes that I created to make the whole thing
easy. Basically, look at the very bottom of HttpRequester.java, and you'll
see an example that looks something like this:
HttpRequester hr = new HttpRequester();
String urlStr = http://localhost:8080/manager/list;;
hr.setRequest(urlStr, HttpRequester.GET, null, admin, 123123, null);
hr.connect();
String inputLine;
while ((inputLine = hr.readLine()) != null) {
System.out.println(inputLine);
}
hr.disconnect();
urlStr = http://localhost:8080/manager/reload?path=/examples;;
hr.setRequest(urlStr, HttpRequester.GET, null, admin, 123123, null);
hr.connect();
String inputLine;
while ((inputLine = hr.readLine()) != null) {
System.out.println(inputLine);
}
hr.disconnect();
Both of these work for me.
Christian
--
Christian Cryder [[EMAIL PROTECTED]]
Internet Architect, ATMReports.com
Barracuda - http://barracuda.enhydra.org
--
What a great time to be a(n employed) Geek
-Original Message-
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
he.org]On Behalf Of Donald Lee
Sent: Saturday, January 26, 2002 12:58 PM
To: [EMAIL PROTECTED]
Subject: Re: Accessing Manager app through URLConnection
I setup mine and it authenticates then gives me,
FAIL - Unknown command
I don't even know where to begin troubleshooting because I don't
know what I
am supposed to be looking for.
Localhost_log file has the following,
2002-01-26 15:13:35 StandardWrapper[/manager:Manager]: Loading container
servlet Manager
2002-01-26 15:13:35 Manager: init
2002-01-26 15:13:35 Manager: init: Associated with Deployer 'localhost'
localhost_access_log has
192.168.0.1 - - [26/Jan/2002:15:13:33 -0500] GET /manager
HTTP/1.1 401 618
192.168.0.1 - dwlee1 [26/Jan/2002:15:13:35 -0500] GET /manager HTTP/1.1
200 40
Original Message Follows
From: Craig R. McClanahan [EMAIL PROTECTED]
Reply-To: Tomcat Users List [EMAIL PROTECTED]
To: Tomcat Users List [EMAIL PROTECTED]
Subject: Re: Accessing Manager app through URLConnection
Date: Sat, 26 Jan 2002 08:46:45 -0800 (PST)
On Fri, 25 Jan 2002, Christian Cryder wrote:
Date: Fri, 25 Jan 2002 23:31:28 -0700
From: Christian Cryder [EMAIL PROTECTED]
Reply-To: Tomcat Users List [EMAIL PROTECTED]
To: Tomcat-User [EMAIL PROTECTED]
Subject: Accessing Manager app through URLConnection
Ok, how can I go about accessing the Manager app through a URL
connection?
Its currently generating a 401 error code, and I know the reason is
because
of the role stuff...how can I programatically assign a role?
Or is there
a
way I can pass the user/pwd info along with the url
poarameters somehow?
I'd
greatly appreciate some ideas on this...
Hi Christian,
You are indeed getting a 401 error because the manager webapp is protected
by a security constraint using BASIC authentication. If you run it from a
browser, you get the usual pop-up dialog.
To use automated connections, your client code is going to have to create
an Authorization header that encodes the username and password, in the
format required by RFC 2617, and include it with the request to bypass the
401 dialog. One source of code you could use to figure out what's
necessary is in the HEAD branch of the Tomcat 4 repository -- in class
org.apache.catalina.ant.AbstractCatalinaTask. (As the name implies, this
is the base class for a set of custom Ant tasks that interact with the
Manager webpp, documented on the manager-howto.html page in the nightly
builds of Tomcat 4.
THanks,
Christian
Craig McClanahan
--
To unsubscribe: mailto:[EMAIL PROTECTED]
For additional commands: mailto:[EMAIL PROTECTED]
Troubles with the list: mailto:[EMAIL PROTECTED]
--
I am Microsoft of Borg. You will be assimilated.
Resistance is futi . . .
GENERAL PROTECTION FAULT IN MSBORG32.DLL
--
Donald Lee ([EMAIL PROTECTED])
Associate Enterprise Engineer
MCSE, Compaq ASE, ACT, A+, TCT, HP
_
Join the worlds largest e-mail service with MSN Hotmail.
http://www.hotmail.com
--
To unsubscribe: mailto:[EMAIL PROTECTED]
For additional commands: mailto:[EMAIL PROTECTED]
Troubles with the list: mailto:[EMAIL PROTECTED]
HttpRequester.java
Description: Binary data
HttpOutputWriter.java
Description: Binary data
HttpConverter.java
Description: Binary data
--
To unsubscribe: mailto:[EMAIL PROTECTED]
For additional commands: mailto:[EMAIL PROTECTED]
Troubles with the list: mailto:[EMAIL PROTECTED]
RE: Tomcat 4 Runtime.exec()? (solved)
Hi guys,
Well, I just figured it out...turns out that when I run it as a standalone
application, something like this works just fine:
File path = new File(C:/temp99);
String cmd = test.bat;
Runtime.getRuntime().exec(cmd, null, path);
When I run it in Tomcat, however, the cmd _must_ include the path, like
this:
File path = new File(C:/temp99);
String cmd = C:/temp99/test.bat;
Runtime.getRuntime().exec(cmd, null, path);
If I don't do this, it blows up. Is that wierd or what? What I can't figure
out is that in both cases I am using the same JDK (1.3.1), so I'm not sure
why the first example works standalone but not in a servlet. Wierd wierd
wierd. Oh well, at least it works... *sigh* :-)
Thanks for your everyone's help!
Christian
--
Christian Cryder [[EMAIL PROTECTED]]
Internet Architect, ATMReports.com
Barracuda - http://barracuda.enhydra.org
--
What a great time to be a(n employed) Geek
-Original Message-
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
he.org]On Behalf Of Christian Cryder
Sent: Friday, January 25, 2002 7:43 PM
To: Tomcat-User
Subject: Tomcat 4 Runtime.exec()?
Can anyone tell me why the Runtime.exec() call in the following piece of
code runs fine standalone, but blows chunks in Tomcat 4?
File path = new File(E:/WebProjects/lutris/cvs/Barracuda/src);
String[] args = new String[] {ant.bat,admin.sample1};
try {
Process p = Runtime.getRuntime().exec(args, null, path);
StringBuffer sbOut = new StringBuffer(1000);
BufferedReader br = new BufferedReader(new
InputStreamReader(p.getInputStream()));
while (true) {
String s = br.readLine();
if (s==null) break;
System.out.println(s);
}
br.close();
p.waitFor();
System.out.println (sbOut.toString());
System.out.println (Exit status: +p.exitValue());
} catch (Exception e) {
System.out.println (Unexpected error executing cmd:+e);
}
Like I said, it works fine when run as an application. But in
Tomcat, I get
the following stack trace:
Path: E:\WebProjects\lutris\cvs\Barracuda\src (exists=true)
Args[0]: ant.bat
Args[1]: admin.sample1
Unexpected error executing cmd:java.io.IOException: CreateProcess: ant.bat
admin.sample1 error=2
java.io.IOException: CreateProcess: ant.bat admin.sample1 error=2
at java.lang.Win32Process.create(Native Method)
at java.lang.Win32Process.init(Unknown Source)
at java.lang.Runtime.execInternal(Native Method)
at java.lang.Runtime.exec(Unknown Source)
...
snip
...
Suggestions? Is there something I don't know about invoking Runtime.exec()
from with a servlet?
Thanks,
Christian
--
Christian Cryder [[EMAIL PROTECTED]]
Internet Architect, ATMReports.com
Barracuda - http://barracuda.enhydra.org
--
What a great time to be a(n employed) Geek
--
To unsubscribe: mailto:[EMAIL PROTECTED]
For additional commands: mailto:[EMAIL PROTECTED]
Troubles with the list: mailto:[EMAIL PROTECTED]
--
To unsubscribe: mailto:[EMAIL PROTECTED]
For additional commands: mailto:[EMAIL PROTECTED]
Troubles with the list: mailto:[EMAIL PROTECTED]
Tomcat 4 Runtime.exec()?
Can anyone tell me why the Runtime.exec() call in the following piece of
code runs fine standalone, but blows chunks in Tomcat 4?
File path = new File(E:/WebProjects/lutris/cvs/Barracuda/src);
String[] args = new String[] {ant.bat,admin.sample1};
try {
Process p = Runtime.getRuntime().exec(args, null, path);
StringBuffer sbOut = new StringBuffer(1000);
BufferedReader br = new BufferedReader(new
InputStreamReader(p.getInputStream()));
while (true) {
String s = br.readLine();
if (s==null) break;
System.out.println(s);
}
br.close();
p.waitFor();
System.out.println (sbOut.toString());
System.out.println (Exit status: +p.exitValue());
} catch (Exception e) {
System.out.println (Unexpected error executing cmd:+e);
}
Like I said, it works fine when run as an application. But in Tomcat, I get
the following stack trace:
Path: E:\WebProjects\lutris\cvs\Barracuda\src (exists=true)
Args[0]: ant.bat
Args[1]: admin.sample1
Unexpected error executing cmd:java.io.IOException: CreateProcess: ant.bat
admin.sample1 error=2
java.io.IOException: CreateProcess: ant.bat admin.sample1 error=2
at java.lang.Win32Process.create(Native Method)
at java.lang.Win32Process.init(Unknown Source)
at java.lang.Runtime.execInternal(Native Method)
at java.lang.Runtime.exec(Unknown Source)
...
snip
...
Suggestions? Is there something I don't know about invoking Runtime.exec()
from with a servlet?
Thanks,
Christian
--
Christian Cryder [[EMAIL PROTECTED]]
Internet Architect, ATMReports.com
Barracuda - http://barracuda.enhydra.org
--
What a great time to be a(n employed) Geek
--
To unsubscribe: mailto:[EMAIL PROTECTED]
For additional commands: mailto:[EMAIL PROTECTED]
Troubles with the list: mailto:[EMAIL PROTECTED]
Accessing Manager app through URLConnection
Ok, how can I go about accessing the Manager app through a URL connection? Its currently generating a 401 error code, and I know the reason is because of the role stuff...how can I programatically assign a role? Or is there a way I can pass the user/pwd info along with the url poarameters somehow? I'd greatly appreciate some ideas on this... THanks, Christian -- Christian Cryder [[EMAIL PROTECTED]] Internet Architect, ATMReports.com Barracuda - http://barracuda.enhydra.org -- What a great time to be a(n employed) Geek -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
RE: Getting IIS to pick up changes to uriworkermap.properties?
Ah-ha! That explains it. Thanks much! Christian -- Christian Cryder [[EMAIL PROTECTED]] Internet Architect, ATMReports.com Instant Messenger: ChristianSCryder Barracuda - http://barracuda.enhydra.org -- What a great time to be a Geek -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] he.org]On Behalf Of Ignacio J. Ortega Sent: Monday, January 14, 2002 3:07 PM To: 'Tomcat Users List' Subject: RE: Getting IIS to pick up changes to uriworkermap.properties? De: Christian Cryder [mailto:[EMAIL PROTECTED]] Enviado el: lunes 14 de enero de 2002 22:40 Isapi_redirector.dll is loaded by inetinfo.exe, that's the IISAdmin service, so you need to Restart IISAdmin Service itself, not IIS alone.. Saludos , Ignacio J. Ortega -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED] -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
Getting IIS to pick up changes to uriworkermap.properties?
Hi folks, I have followed the very excellent instructions at http://members.ozemail.com.au/~lampante/howto/tomcat/iisnt/ that describe how to integrate Tomcat 4.0.1 with IIS. At this point, I have everything working, but I am observing a (hopefully) minor problem. When I want to add a new webapp to Tomcat, I modify a) server.xml to point to the new web app directory (ie e:\test99) b) uriworkermap.properties to map the request url from IIS to Tomcat (/test99) Then I cycle both Tomcat and IIS services. What I notice, however, is that the new webapp is still not accesible until I reboot: if I try to access http://localhost:8080/test99 (Tomcat direct) I can get to it, but at http://localhost/test99 (IIS) I cannot. Consequently, it seems to me that Tomcat is picking up the changes (since I can access the app on its local 8080 port), but IIS is not. I am wondering if there is something else I need to do in order to get IIS to notice the change (short of actually rebooting *blech!*). Am I doing something stupid? Have I missed some essential piece of documentation? If anyone has any suggestions I'd love to hear them... Christian -- Christian Cryder [[EMAIL PROTECTED]] Internet Architect, ATMReports.com Instant Messenger: ChristianSCryder Barracuda - http://barracuda.enhydra.org -- What a great time to be a Geek -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
ANN: Barracuda Beta 1
Hi folks, Just a brief announcement to let you know that the Beta 1 release of Barracuda is now available at http://barracuda.enhydra.org. If you never work with Servlets, JSPs, XML or DOM, delete this email now. For those of you who are still reading and wonder What the heck is Barracuda?, read on. Barracuda is an open-source Presentation Framework designed to make it easier to build servlet based webapps by applying proven client-server patterns to the web development paradigm. Key features include: -DOM based templating mechanism for better separation of code from content (default implementation uses XMLC...see http://xmlc.enhydra.org) -UI component model that provides a series of server side widgets (table, list, template, etc) that make it easy to manipulate DOM structures. Strongly typed MVC interfaces just like in Swing. Support for multiple markup languages (HTML, WML, XML, etc). -Event model that provides Model 2 style flow control and allows for true event driven programming on the server. You can add listeners to components and your server-side event handler code will automatically get notified when an action occurs on the client. -Form mapping and validation framework that makes it possible to easily convert HTTP Request form parameters into first class Java objects and validate them -Localization services that extend the XMLC compiler to make it really easy to localize DOM templates and then load them based on target locale -based on the Servlet 2.2+ API (so it'll run in any decent app-server). -And of course it's open source! ;-) Full details at the website--source available under CVS, mailing list to ask questions, lots of documentation, sample apps, yadda, yadda, yadda. Enjoy! Christian Christian Cryder [EMAIL PROTECTED] Barracuda - Open-source MVC Component Framework for Webapps http://barracuda.enhydra.org What a great time to be a Geek
