RE: [4.1.27] Builds uploaded
(Note: I decided to skip the LE builds, because I am lazy and people have been confused by them; I'll add them this WE if there's some demand) I for one would love to see the LE builds. We find them very useful; our build process is also tailored to them. Sean Reilly Software Architect, Point2 Technologies, Inc. (306) 955-1855 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [4.1.27] Builds uploaded
Thanks a lot! I appreciate the extra effort. Sean -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED] Sent: Thursday, July 31, 2003 2:13 PM To: Tomcat Developers List Subject: Re: [4.1.27] Builds uploaded Sean Reilly wrote: (Note: I decided to skip the LE builds, because I am lazy and people have been confused by them; I'll add them this WE if there's some demand) I for one would love to see the LE builds. We find them very useful; our build process is also tailored to them. Ok, fine. You'll see them on Sunday then. 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: Http version error
Unless you formatted the email strangely, you have an invalid HTTP request. The directive (POST) the URI, and the version must all be on the first line. Also, the /color tag in the Content-Length header shouldn't be there (I assume that's an email formatted thing, but just in case). So the request should be: POST /Tomcat_tre/WsdaServlet;jsessionid= HTTP/1.1 User-Agent: WSDA_SWCLIENT Content-Type: application/octet-stream Content-length: 19 FRAMEWORK_VERSION: 0.0WSDAFM Does this help? Sean -Original Message- From: Claudio Bisegni [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 25, 2003 3:03 PM To: [EMAIL PROTECTED] Subject: Http version error Hi all, I have a wireless java application writing in superwaba, and i have made myself a code for sending an http servlet request to tomcat. In tomcat 3 al work but with tomcat 4.1 i have his errror HTTP/1.1 505 HTTP Version Not Supported anyone has an idea?? This is the htttp request that i made is: POST /Tomcat_tre/WsdaServlet;jsessionid= HTTP/1.1 User-Agent: WSDA_SWCLIENT Content-Type: application/octet-stream Content-length: 19/color FRAMEWORK_VERSION: 0.0WSDAFM - 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: Http version error
Are there two spaces between the URI and the version in the real request? POST /Tomcat_tre/WsdaServlet;jsessionid= HTTP/1.1 ^^ That could be the source of the problem (if it's not just in the email). -Original Message- From: Claudio Bisegni [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 25, 2003 3:23 PM To: Tomcat Developers List Subject: Re: Http version error thanks in advanced sean, in effectly the email wsa wrong formatted, the real my post is: POST /Tomcat_tre/WsdaServlet;jsessionid= HTTP/1.1 User-Agent: WSDA_SWCLIENT Content-Type: application/octet-stream Content-length: 19 FRAMEWORK_VERSION: 0.0WSDAFM but the error remain I flow this rewest acros a socket any idea? On Tuesday, March 25, 2003, at 10:14 PM, Sean Reilly wrote: POST /Tomcat_tre/WsdaServlet;jsessionid= HTTP/1.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: Http version error
Well, the HTTP/1.1 spec (http://www.w3.org/Protocols/rfc2068/rfc2068, Section 5.1) specifies that a single space should be used. Since one of the differences between tomcat 3 and tomcat 4.1 is that a new HTTP protocol handler (Coyote) was written, it could be the problem. -Original Message- From: Claudio Bisegni [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 25, 2003 3:33 PM To: Tomcat Developers List Subject: Re: Http version error yes there are tow space you think this is the problem??? On Tuesday, March 25, 2003, at 10:26 PM, Sean Reilly wrote: - 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: Http version error
According to this code, you'll need another line break after the final header.
-Original Message-
From: Claudio Bisegni [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 25, 2003 3:57 PM
To: Tomcat Developers List
Subject: Re: Http version error
i have tryed now with one space tommy give me the erro BAd request
thia is my code for create the http request
httpMessage.append(requestMetod);
httpMessage.append( / +
wsda.swclient.WsdaClient.confDelegator.getServerMediatorClass() +
;jsessionid=+ (sessionID==null? :sessionID + ) +HTTP/1.1\n);
httpMessage.append(getHeaderString() + \n);
byte[] headerReqbuf = httpMessage.toString().getBytes();
// scrivo l'header nel buffer
bas.writeBytes(headerReqbuf, 0 , headerReqbuf.length);
// scrivo il dato d inviare nel buffer
bas.writeBytes(data, 0, data.length);
bas.writeBytes(closeSequence, 0, closeSequence.length);
getHeaderMessage is:
private String getHeaderString() {
StringBuffer result = new StringBuffer();
Vector keys = headerhash.getKeys();
for(int idx = 0; idx keys.size(); idx++) {
result.append(keys.elementAt(idx)+:
+headerhash.get(keys.elementAt(idx)));
result.append(\n);
}
return result.toString();
}
note close sequence is an array of tre byte of \n
On Tuesday, March 25, 2003, at 10:39 PM, Sean Reilly wrote:
Well, the HTTP/1.1 spec
(http://www.w3.org/Protocols/rfc2068/rfc2068,
Section 5.1)
specifies that a single space should be used. Since one of the
differences between tomcat 3 and tomcat 4.1 is that a new HTTP
protocol handler (Coyote) was written, it could be the problem.
-Original Message-
From: Claudio Bisegni [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 25, 2003 3:33 PM
To: Tomcat Developers List
Subject: Re: Http version error
yes there are tow space you think this is the problem???
On Tuesday, March 25, 2003, at 10:26 PM, Sean Reilly wrote:
-
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: Tomcat 5 target JDK1.4?
This might start a bit of a flame-fest here, and if so I appologize, but I feel that this is a valid point. A lot of people have been critizing V. Cekvenich for his suggestion, and one of the common reasons given was: Those who have systems in production and have spent alot of time developing applications which are hosted on those systems can't do a major upgrade like JVM 1.3 - JVM 1.4 at the drop of a hat. This particular version of the argument was posted by Glenn, and I believe he's correct in stating this. However, if you can't do a major upgrade like JVM 1.3 - JVM 1.4 at the drop of a hat, why would you consider a major upgrade like Tomcat 4.X - Tomcat 5 at the drop of a hat? The many other arguments against requiring 1.4 notwithstanding (and I'm not attempting to refute _any_ of them here), it would seem to me that testing a major version change of Tomcat + a JVM change wouldn't incur much more overhead than testing a major version change of Tomcat alone. Does anyone have any comments/opinions/counterarguments? Or should I just shut my trap and concentrate on the other reasons requiring J2SE 1.4 is a bad idea ;-) Sean Reilly Software Architect, Point2 Technologies, Inc. (306) 955-1855 [EMAIL PROTECTED] -Original Message- From: V. Cekvenich [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 21, 2003 5:04 PM To: [EMAIL PROTECTED] Subject: Re: Tomcat 5 target JDK1.4? iSeris has JDK 1.4 download from IBM, that is my point. (BEA, and Apple have it as well so we have multi source). Today when you download Tomcat 4 you have the 1.4 LE edition just loook at the site Also downloading a jar, ex: http://jdbc.postgresql.org/download.html have 1.4 required. Today! TC5 is ways of. And I think everyone can agree that JDK1.4 is more stable than 1.3. .V Henri Gomez wrote: V. Cekvenich wrote: For TC 4 OK, but TC5 will have tested 4 vendors JVM 1.4. Most people run JDK 1.4 now. There is at least one person which didn't run JDK 1.4, me, since the JDK 1.4 is not available on my iSeries. -- 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: DO NOT REPLY [Bug 10383] - Specially crafted GET request causes the answering httpd process and the answering AJP13 processor to hang indefinitely
CVSZilla (http://homepages.kcbbs.gen.nz/~tonyg/) supports this kind of functionality quite nicely. Sean Reilly Software Architect, Point2 Technologies, Inc. (306) 955-1855 [EMAIL PROTECTED] -Original Message- (snip) One last general request that is not focused on you: When I encounter problems with apache.org software (not only Tomcat) I use bugzilla very often and most of the time I find a hint there that solves my problem. But very often it is hard work to find all the patched files and the revisions of the files containing the patch that resolved the bug in the CVS (partionally CVS is to blame on this problem). Although I know that the CVS is very dynamic, I think it would help a lot if any person who commits a patch to the CVS in reaction to a bug report writes a short note to the bug report which files have been changed by the patch and the revision numbers of these files. Even if these patches change later on, this information is a good base for searching the actual version of the patch to a bug in the CVS. For this bug the note is rather short: Affected files and revisions: jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4/Ajp13 Processor.java revisions: 1.10, 1.11 Complete patch: http://cvs.apache.org/viewcvs/jakarta-tomcat-connectors/jk/jav a/org/apache/ajp/tomcat4/Ajp13Processor.java.diff?r1=1.9r2=1.11 Remark: The complete patch line is something I would not see within the scope of this short note in general, but in this case this was so easy that I added it for everyones convenience. Again thanks for the help. -- 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: [VOTE] Proposed jspc refactoring (how I use jspc)
For what it's worth, here's how I benefit from jspc on a regular basis. I'm one of the principal developers of a fairly high-traffic site powered by tomcat 4.1.12. We use jspc for correctness checking as part of our compile cycle, for two reasons: a)To enforce valid jsp tag use (required attributes present, etc) b)We use a jstl validator to keep over-enthusiastic web developers from using scriptlets in jsp pages Including jsp checking in the compile cycle (and inflicting bodily harm on developers who cvs commit without compiling ;-) is a big help in keeping code quality high. It's been mentionied in this thread (I think by Remy), that Efficiency is not all that important here, since precomiplation is done before deployment I would respectfully disagree on this point. Not including jsp compilation, our entire build cycle, from a stock tomcat zip to a running tomcat instance with deployed webapps (including all servlet compilation and source code style checking) takes about 35 seconds. Using ant's incremental capabilities, a non-complete build often takes less than 10 seconds. I love that our developers can compile at the drop of a hat, and I encourage this as often as I can. So to me, efficiency is very important; the faster, the better. Right now, a jsp precompilation for 120 jsp pages (which we can put off until production deployment to organizational peculiarities) takes 54 seconds... longer than the rest of our build cycle put together. I would love for jsp compile checking to be performed as part of a regular developer's build cycle, and the faster JspC gets, the easier that is. Also, we do use incremental jsp compiles on a regular basis. Also, I would love to deploy precompiled jsps to production, but conformance to the jsp and servlet specs is important to us, so a servlet compliant way (as opposed to the copying to the work directory solution) would be a positive feature for us. So to sum up, we jspc an entire webapp at a time, but love incremental compilation (which is the only reason I can think of that someone would need to only compile a single jsp), and the faster the process is, the better. Thanks, Sean PS: Also, if you're looking for an example of the kind of performance you can get from a tomcat-powered server (as many people in the user's list seem to be), we're probably a pretty good example. We served 52,708 page views yesterday (of definitely non-static content) from two dual p3 800mhz boxes, and when cpu usage goes over 5% on either machine, we get seriously upset. http://usediron.point2.com Sean Reilly Programmer, Point2 Technologies, Inc. (306) 955-1855 [EMAIL PROTECTED] -Original Message- From: John Trollinger [mailto:jakarta;trollingers.com] Sent: Thursday, November 07, 2002 1:24 PM To: 'Tomcat Developers List' Subject: RE: [VOTE] Proposed jspc refactoring I have to time to go through and fix all the options (including cleaning up the code) but I would like to see what options are actually used (or would like to be used if they work) I also have no problems maintaining jscp as I use it a lot and have customized it to do what I want. I would just like some direction to go with.. John -Original Message- From: news [mailto:news;main.gmane.org] On Behalf Of Costin Manolache Sent: Thursday, November 07, 2002 1:39 PM To: [EMAIL PROTECTED] Subject: Re: [VOTE] Proposed jspc refactoring Remy has a point - the current code is not very clean, and doesn't seem to be tested/maintained enough. I use the ant tasks - and I have a feeling many other users of jspc are doing the same. Removing the CLI and keeping the basic functionality seems like a good idea. For example compiling a jsp page outside a webapp can't work in all cases - if it has includes, etc it needs to resolve, it needs taglib definitions from WEB-INF, etc. I can't see any good reason to keep it if it's half broken by definition. Also - compiling the java files is the job of javac, and the mapping and web.xml fragment generation can be more easily done using only the ant tasks. I would go even further - since we are already using ant to compile the java to .class, it may be a good idea to make the .jsp-.java task 'first class'. In any case - the task is supported ( at least by me, it seems Henri is using it as well ). If there are people who want to support the CLI and the other options - then we can keep them, but if not - I think it's better to remove them or mark as unsupported. Costin Hans Bergsten wrote: Remy Maucherat wrote: Hi, jspc is IMO overly complex, with many features nobody knows how to use, and nobody cares to test (hence sometimes some of them are randomly broken during Jasper refactorings). I will not formally vote on this, because I've been inactive in this project for so long I feel I need to familiarize myself with the current code base before I can
RE: DO NOT REPLY [Bug 13084] - jsp compilation with jikes fails
Just out of curiosity, where would you obtain such a version? I tried jikes 1.16 (win32) from IBM. AFAIK this is the current version of jikes, and also the first version that supports assertions (-source 1.4). It doesn't list the -encoding option. Is -encoding a standard option for jikes? Sean Reilly Programmer, Point2 Technologies, Inc. (306) 955-1855 [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Friday, September 27, 2002 4:33 PM To: [EMAIL PROTECTED] Subject: DO NOT REPLY [Bug 13084] - jsp compilation with jikes fails (snip) http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13084 jsp compilation with jikes fails [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-09-27 22:33 --- You need a version of jikes with support for encoding. If you execute the jikes compiler from a shell with -help and don't see the option -encoding then jikes isn't built with support for encoding. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [TC 4.0] How can I obtain the state of the tomcat server?
You can write a javax.servlet.ServletContextListener which sends a callback of some sort to your application code. If you specify your implementation in the web.xml of a web application like so: listener listener-classcom.foo.MyListener/listener-class /listener then tomcat will call the contextInitialized method of this class as soon as the context is ready to process requests. Sean Sean Reilly Programmer, Point2 Technologies, Inc. (306) 955-1855 [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] -Original Message- From: Stefanos Karasavvidis [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 05, 2002 10:55 AM To: Tomcat Developers List Subject: Re: [TC 4.0] How can I obtain the state of the tomcat server? how about checking a url of the server unitl it gives a 200 response code?? Stefanos Evans, Terry G wrote: I need to know when the server is available for work. Our product does not use startup servlets nor context listeners. We display simple HTML documents on a browser once the Tomcat server has started. My ideal solution would be that my Java application would fire off the Tomcat server (we're using Runtime.getRuntime().exec() calls to start Tomcat and IE) and then would either check the status of the server or receive a callback from the server that it is ready, then my Java application would proceed with starting up the browser. I was hoping to use an internal tomcat feature to implement this. I've looked at CatalinaManager and CatalinaService, but I'm not certain of exactly what they are and what they could do for my situation. Thanks, Terry -Original Message- From: Shapira, Yoav [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 05, 2002 11:22 AM To: Tomcat Developers List Subject: RE: [TC 4.0] How can I obtain the state of the tomcat server? Hi, The state of the server process can be many things. It can be the server process is alive, it can be that the host/port respond to requests, and it can be that your app is actually available for work. All of these can be checked in various ways. Which one were you interested in? What would be your ideal solution? One idea is, if you have any startup servlets or context listeners, have them write our a file in a specific location or a message to some log. Then have the process that starts the web browser poll, checking for the existence of this file or this message in the log. Another one is to use a 3rd tool, e.g. a JMS server, where you could send a message from your server to a queue, and have your java app wait for that message before starting the browser... You get my drift: there are many many ways to do this ;) Were you looking for an internal tomcat feature? Yoav Shapira Millennium ChemInformatics -Original Message- From: Evans, Terry G [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 05, 2002 11:01 AM To: '[EMAIL PROTECTED]' Subject: [TC 4.0] How can I obtain the state of the tomcat server? I am developing a Java application that is designed to start up a Tomcat server and a web browser. I don't want the web browser to start up until the Tomcat server is running, but I don't want to put in an arbitrary sleep time between starting the server and starting the web browser. Is there a way that I can query the state of the server process? OS : Windows 2000 Professional JDK/JRE : 1.4.0_01 Tomcat : 4.0 Thanks for your time, Terry -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:tomcat-dev- [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: Bug 11091 has now been untouched for over a month
Here are the contents of the attachment. The directory structure is as follows: Error.jsp and test.jsp would be in the web-app's main directory web.xml goes in a WEB-INF subdirectory Sean -Original Message- From: jean-frederic clere [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 04, 2002 2:20 AM To: Tomcat Developers List Subject: Re: Bug 11091 has now been untouched for over a month Sean Reilly wrote: Hi, I posted bug #11091 (http://issues.apache.org/bugzilla/show_bug.cgi?id=11091) on July 23rd. Since then, nobody besides myself has posted a comment to it, and it is still assigned to [EMAIL PROTECTED] The recent test milestone (4.1.10) released on August 30th does not fix the issue. Has anyone looked into this bug at all? Are there any plans to fix it? Any comments at all would be very much appreciated. I cannot read the attachement (id=2450). Could you please mail it to me? I will try to have a look. Thanks in advance, Sean Sean Reilly Programmer, Point2 Technologies, Inc. (306) 955-1855 [EMAIL PROTECTED] 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] Error.jsp Description: Error.jsp test.jsp Description: test.jsp ?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 !-- this web application is distributable -- distributable/ !-- error page mapping -- error-page exception-typejavax.servlet.jsp.JspException/exception-type location/Error.jsp/location /error-page error-page error-code500/error-code location/Error.jsp/location /error-page /web-app -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Bug 11091 has now been untouched for over a month
hmm... it was working well for me. Maybe it was a whitespace issue? At any rate your version should have essentially the same effect. -Original Message- From: jean-frederic clere [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 04, 2002 9:58 AM To: Tomcat Developers List Subject: Re: Bug 11091 has now been untouched for over a month Clere, Jean-Frederic wrote: Clere, Jean-Frederic wrote: Sean Reilly wrote: Hi, I posted bug #11091 (http://issues.apache.org/bugzilla/show_bug.cgi?id=11091) on July 23rd. Since then, nobody besides myself has posted a comment to it, and it is still assigned to [EMAIL PROTECTED] The recent test milestone (4.1.10) released on August 30th does not fix the issue. Has anyone looked into this bug at all? Are there any plans to fix it? Any comments at all would be very much appreciated. I cannot read the attachement (id=2450). I have read it now - Sorry than was my fault - The test.jsp does not compile, I have changed it to: +++ % if (true) throw new javax.servlet.jsp.JspException(deliberate crash); % +++ Could you please mail it to me? I will try to have a look. Thanks in advance, Sean Sean Reilly Programmer, Point2 Technologies, Inc. (306) 955-1855 [EMAIL PROTECTED] 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] -- 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]
Bug 11091 has now been untouched for over a month
Hi, I posted bug #11091 (http://issues.apache.org/bugzilla/show_bug.cgi?id=11091) on July 23rd. Since then, nobody besides myself has posted a comment to it, and it is still assigned to [EMAIL PROTECTED] The recent test milestone (4.1.10) released on August 30th does not fix the issue. Has anyone looked into this bug at all? Are there any plans to fix it? Any comments at all would be very much appreciated. Thanks in advance, Sean Sean Reilly Programmer, Point2 Technologies, Inc. (306) 955-1855 [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
