RE: Trouble getting Tomcat to parse .html files of JSP tags.

2001-04-17 Thread Tõnu Põld

Hi,

You need to specify that the jsp servlet should process the .html files.
Try to add something like this into web.xml file:



jsp


org.apache.jasper.runtime.JspServlet


-2147483646





jsp


*.html



Look at the example web.xml file in $TOMCAT_HOME/conf directory.

Regards,
Tõnu

> -Original Message-
> From: Stuart Allen [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, April 17, 2001 8:53 AM
> To: [EMAIL PROTECTED]
> Subject: Trouble getting Tomcat to parse .html files of JSP tags.
> 
> 
> I have been trying for some time now to configure Tomcat/ 
> Apache to allow 
> the inclusion of JSP tags in .html files. In my tomcat-apache 
> file, that is 
> included at the bottom of http.conf, I have the following lines:
> 
> JkMount /mydev/*.html ajp12
> JkMount /mydev/*.jsp ajp12
> JkMount /mydev/servlet/* ajp12
> 
> I have two files, index.jsp and index.html in 
> $TOMCAT_HOME/webapps/mydev. 
> They contain:
> 
> 
>  
>  
>  
>  
>  
>  
> 
> 
> Accessing index.jsp runs the servlet, accessing index.html 
> does not. Any 
> help with this matter will be greatly appreciated.
> 
> Regards,
> Stuart
> 



RE: Trouble getting Tomcat to parse .html files of JSP tags.

2001-04-18 Thread Tõnu Põld

Hi,

I suspect the problem relies in Apache and mod_jk configuration, and not in
Tomcat engine, because the Tomcat web server (default port 8080) seems to
serve the .html files with JSP tags correctly.

The only configuration needed in Tomcat engine side is the servlet-mapping
in web.xml:

 
 jsp


 *.html



There might be some directives like "Location" or "Directory" in your
Apache's httpd.conf, which force the Apache to pass by the Tomcat and take
the .html files directly from filesystem.

Sorry, but I don't know the Apache's directives very well.

Regards,
Tõnu

> -Original Message-
> From: Stuart Allen [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, April 18, 2001 6:36 AM
> To: [EMAIL PROTECTED]
> Subject: RE: Trouble getting Tomcat to parse .html files of JSP tags.
> 
> 
> Hi Tõnu
> 
> It's always the way isn't it, two minutes after I sent the 
> last message it 
> started to work (well, sort of). I changed the mapping from 
> *.html to /. It 
> says in the Servlet Specification that this makes jsp the 
> default servlet 
> of the application. This is quite acceptable for what I am 
> trying to do, 
> but I still don't know why *.html didn't work...
> 
> 
> At 09:21 17/04/2001 +0200, you wrote:
> >Hi,
> >
> >You need to specify that the jsp servlet should process the 
> .html files.
> >Try to add something like this into web.xml file:
> >
> > 
> > 
> > jsp
> > 
> > 
> > org.apache.jasper.runtime.JspServlet
> > 
> > 
> > -2147483646
> > 
> > 
> >
> > 
> > 
> > jsp
> > 
> > 
> > *.html
> > 
> > 
> >
> >Look at the example web.xml file in $TOMCAT_HOME/conf directory.
> >
> >Regards,
> >Tõnu
> >
> > > -Original Message-
> > > From: Stuart Allen [mailto:[EMAIL PROTECTED]]
> > > Sent: Tuesday, April 17, 2001 8:53 AM
> > > To: [EMAIL PROTECTED]
> > > Subject: Trouble getting Tomcat to parse .html files of JSP tags.
> > >
> > >
> > > I have been trying for some time now to configure Tomcat/
> > > Apache to allow
> > > the inclusion of JSP tags in .html files. In my tomcat-apache
> > > file, that is
> > > included at the bottom of http.conf, I have the following lines:
> > >
> > > JkMount /mydev/*.html ajp12
> > > JkMount /mydev/*.jsp ajp12
> > > JkMount /mydev/servlet/* ajp12
> > >
> > > I have two files, index.jsp and index.html in
> > > $TOMCAT_HOME/webapps/mydev.
> > > They contain:
> > >
> > > 
> > >  
> > >  
> > >  
> > >   flush="true">
> > >  
> > >  
> > > 
> > >
> > > Accessing index.jsp runs the servlet, accessing index.html
> > > does not. Any
> > > help with this matter will be greatly appreciated.
> > >
> > > Regards,
> > > Stuart
> > >
> 



RE: AutoLogon J_Security_Check

2001-05-04 Thread Tõnu Põld

Hi,

I have done similar logon with JSP in Tomcat.
In my case I use form based login, and I need a separate login page.
After successful login the user must be redirected to default page.
It couldn't be achieved with Tomcat (3.2.1) login mechanism, because the
login page is returned after user have made a request for a restricted page.
Also, after login the user is redirected to the same page he/she requested.
It couldn't also be achieved by making the request from a separate login
page directly to j_security_check, because in this case the user is
redirected to /catalog/null page, which doesn't exist.

So what I did was:
1. A static html login page. The page has form with fields "j_password" and
"j_username". 
2. For processing the request submitted from this static login page I made a
page "loginredirect.jsp"
3. In loginredirect.jsp page I take the request parameters "j_password" and
"j_username" and dispatch the login request to the j_security_check resource
for user audenthication/authorization.
4. After dispatching I redirect user to the default page, which is also
restricted page. Now if the login succeeded the default page is returned to
the user.

My loginredirect page looks:
-
<%-- Set autoflush to false to prevent the premature response --%>
<%@ page autoFlush="false" %>
<%
 // this page is restricted with "security-constraint" in web.xml
 String path = "/catalog/default.jsp";

 // redirect the page to default location, but first audenthicate the user
 response.setStatus(302, "Found");
 response.setHeader("Location", path);

 // Here I call the j_security_check to audenthicate and authorize the user 
 // The dispatched request can't set any response attributes, but it saves 
 //  audenthication parameters in session
 RequestDispatcher rd = application.getRequestDispatcher(
   "/login/j_security_check?j_username="+ 
   request.getParameter("j_username")+
   "&j_password="+request.getParameter("j_password"));
 rd.include(request, response);

 // Here we discard the output that was written in j_security_check 
 // This doesn't work in Tomcat 3.2.1 ???
 if (!response.isCommitted()) {
 response.reset();
 }

 // If authorization succeeded, then the j_security_check added the
appropriate
 // attributes into request session. Now we redirect the request to default
 // page.
%>


Document moved


Document moved

This document has moved here.


<% out.flush(); %>
--

Regards,
Tõnu

> -Original Message-
> From: Warren Crossing 
> Sent: Friday, May 04, 2001 7:09 AM
> To: '[EMAIL PROTECTED]'
> Subject: AutoLogon J_Security_Check
> 
> 
> hey all, 
> 
> i'm about to build a servlet class component that proactively &
> automatically ( without being prompted ) logs the user into 
> servlet security
> and bypasses a browser request for j_security_check..
> 
> i plan to achieve this by using;
> a static html page with a form on it
> a known dummy protected page to trigger the j_security_check 
> response.. 
> a servlet class to receive the request
> spoof the browser request to request dummy page,
> log the user in trick =) repsond with j_user_name & j_password.
> and getRequestDispatcher().forward to the target page..
> 
> i know its a little more tricky than this & so i'll ask if anyone is
> interesed in the outcome.. or attempted this before with 
> tomcat. i've done a
> similar thing with weblogic servlet security.  and this 
> functionality is
> desireable to when merging my web portal into a web page 
> interface.. but i
> know its bad for guaranteed security.
> 
> regards,
> 
> warren.
> 



RE: Ever increasing heap size with Tomcat 3.2.3 !!!

2001-12-19 Thread Tõnu Põld

Hi

We have a similar problem with IBM JDK 1.3.0 (JIT enabled).
I suggest to debug the garbage collector (gc) by turning on the -verbosegc
command option. The garbage collecting activity will be written to stderr.

In our case I suspect that it is JVM problem because the output shows that
90% heap is free, but still the OutOfMemoryException occurs sometimes. The
exception occurs when the servlet application tries to allocate big amount
of memory (5Mb). Even if we set the -Xmx128m and -Xms128m the error occurs,
although the output shows that there is 90% (115Mb) free space in heap.

I suspect that the OutOfMemoryError occurs because the heap gets too
fragmented, therefore the gc can't allocate big sequential memory area. This
makes me believe that the heap defragmentation process takes place very
seldom. If big amount of memory is needed then it is allocated from the end
of the heap, but if the heap size grows close to the maximum, then the
exception occurs. Does anybody know if there is a way to force the
defragmentation to occur more frequently?

I have stress tested our application Sun JRE 1.2.2, and the OutOfMemoryError
never occurred.

With IBM JDK we minimized the occurrences of OutOfMemoryError by setting the
-Xms64m and -Xmx128m. In this case the garbage collector keeps the heap size
somewhere between min and max. Example from our log: 86% free
(92324744/107150328). But if we generate too much load then we still get the
OutOfMemoryError. But at the moment our application doesn't get so much
load, so the OutOfMemoryExcpetions are rare.

Would be very thankful if anybody could confirm/explain my suspicions,
Tõnu

> -Original Message-
> From: Hawkins, Keith (Keith) [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, December 18, 2001 7:34 PM
> To: [EMAIL PROTECTED]; tomcat-user
> Subject: Ever increasing heap size with Tomcat 3.2.3 !!!
> 
> 
> 
> Hello,
> 
> Before my manager insists that we switch to JRun,  can any of 
> the Tomcat
> developers help with a problem of an ever increasing heap size of the
> Tomcat java.exe. ??  (We are running Tomcat 3.2.3 and 
> JRE1.3.1. and the
> IIS redirector)
> 
> We are running a load test using LoadRunner scripts on some JSP and
> servlets that are running under Tomcat.  The load is not all 
> that heavy
> but the heap size of the Tomcat java.exe process keeps growing and
> growing. We modified the java command line to start with  -Xmx128m to
> allow 128 MB of heap but we still max out after a day or so.   We even
> modified one of our servlets to create a thread that runs  
> Runtime.gc()
> every 30 seconds.   The LoadRunner scripts just keep logging 
> in the same
> 5 people via our authentication servlet so you would think memory use
> would level out at some point.
> 
> Nothing we do seems to keep the heap size from growing.  
> 
> Are there known issues with Tomcat and heap size??
> 
> Doing a web search revealed numerous posts with people having similar
> problems so I believe there is a problem.   The standard 
> response these
> people receive is to increase the heap size via -Xmx   But that seems
> like a band-aid rather than a real solution.   That just delays the
> inevitable.
> 
> Any insight as to how to keep the Tomcat process from 
> grabbing more and
> more memory would be appreciated.
> 
> Thanks,
> Keith
> 
> 
> 
> 
> 
> 
> 
> 

--
To unsubscribe:   
For additional commands: 
Troubles with the list: 




RE: Character Encoding Problem

2001-07-02 Thread Tõnu Põld

Hi,

You should compile the java classes with ISO-8859-9 encoding.
Look at the -encoding flag of the 'javac' compiler.

In compilation the 8-byte characters in strings are converted to unicode
characters.
By default the encoding is probably ISO-8859-1.

Regards,
Tõnu


> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Monday, July 02, 2001 10:33 AM
> To: [EMAIL PROTECTED]
> Subject: Character Encoding Problem
> 
> 
> Hi,
> 
> I know that this is a popular (!?) problem in tomcat. Dur 
> despite my efforts I could not find any solution. Here it goes:
> 
> We have jsp page in encoding type ISO-8859-9. With the line
> <%@ page contentType = "text/html; charset=ISO-8859-9" %>
> we define the encoding type of the document.
> 
> Result:
> The strings in the jsp file are encoded correctly, like
> - The text in html
> - the text written inside jsp code between <%, %>
> 
> Problem:
> The strings that are recevied from a class, read from a file, 
> inside a constant are not encoded correctly.
> 
> <%= "Pretend to be a ISO8859-9 string" %> is encoded correctly but,
> inside a class let's say we have
> String x = "Pretend to be a ISO8859-9 string";
> then
> <%= myClass.c %> is encoded wrong with many ?'s
> 
> The problem is not in JVM/JDK, I think, as I read a file and 
> write the content into another file, both files are the same 
> with no loss in encoding.
> 
> Also the encoding problem is there when I include files with
>  If I include the file with <%@ include .. the problem is
> not there .. But I really need to use  
> Can anyone solve my problem ?? ..
> 
> Arif Tumer ..
> 



RE: ?lgi:RE: Character Encoding Problem

2001-07-02 Thread Tõnu Põld

Just a thought about the  -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Monday, July 02, 2001 11:16 AM
> To: [EMAIL PROTECTED]
> Subject: ?lgi:RE: Character Encoding Problem
> 
> 
> > Kimden: Tõnu Põld <[EMAIL PROTECTED]>
> > Tarih: 2001/07/02 Mon AM 10:48:10 GMT+03:00
> > Kime: "'[EMAIL PROTECTED]'" 
> <[EMAIL PROTECTED]>
> > Konu: RE: Character Encoding Problem
> > 
> > Hi,
> > 
> > You should compile the java classes with ISO-8859-9 encoding.
> > Look at the -encoding flag of the 'javac' compiler.
> > 
> > In compilation the 8-byte characters in strings are 
> converted to unicode
> > characters.
> > By default the encoding is probably ISO-8859-1.
> > 
> > Regards,
> > Tõnu
> > 
> 
> I tried, a few minutes ago, but the problem remains. I don't
> know the usage of -encoding parameter in detail but,
> I think it is related with the string constants in the 
> source files. The main problem is the encoding when I read
> a text file and show its contents in the jsp with something like,
> 
> <%= FileReader.readLine() %>
> 
> And as I mentioned, when I load a file and write it into 
> another file, the encoding is correct. The result of my 
> string manipulation functions are correct. The single, 
> devastating, problem occurs when I pass a string with 
> characters in ISO-8859-9, from a class to jsp.
> 
> Ah,  
> Himm .. It is a stupid thought but is it something to do with 
> dynamic strings vs. static strings. As far as I know when <%@ 
> include.. is used the file is statically included,
> at compile time, but  dynamically after compilation. Also the string constants in 
> jsp files are compiled, but strings read from files are
> read and generated in execution time .. Himmm .. I think I am 
> going paranoic :) ..
> 
> Thanks, anyway .. Has anyone encountered this kind of problem 
> before ??
> 
> Arif ..
> 



RE: Character Encoding Problem

2001-07-02 Thread Tõnu Põld

Hi,

I still believe your initial bytes are converted to java strings (unicode)
using a wrong encoding.

If you have a string created from bytes using the "ISO-8859-9" encoding, and
if the JSP page has a directive <%@ page content-type="ISO-8859-9"%>, then
it should be OK. 

For debuging you could try to convert your string to another encoding, look
what happens.
For example:

<%@ page content-type="ISO-8859-9"%>
String s = new String( initalString.getBytes("ISO-8859-1"), "ISO-8859-9");
<%= s %>

If this dislays your string correctly, then you have used the "ISO-8859-1"
encoding in creation of a java string from inital bytes!

By the way which version of Tomcat are you using. An older release (3.2.1)
had some bugs with encoding conversion. Try the latest 3.2.2 release.

The request parameters from HTTP post are probably in "ISO-8859-1" encoding
because most browsers do not specify the encoding when submiting a request,
so Tomcat uses the default encoding. To convert them correctly to java
strings encoding, the following could be used (assuming that they really are
"ISO-8859-9"):
String param = new String( initalParam.getBytes("ISO-8859-1"),
"ISO-8859-9");

Regards,
Tõnu



> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Monday, July 02, 2001 3:34 PM
> To: [EMAIL PROTECTED]
> Subject: RE: Character Encoding Problem
> 
> 
> > > When reading bytes from file with FileReader the default 
> character encoding
> > > is used.
> > > I think you must specify your own encoding when reading the file.
> > >
> > 
> > I'll try that. But the same compiled classes and the same 
> jdk version works well with Resin JSP Server and the files. 
> The problem occurs with Tomcat.
> > 
> 
> Nay, still problems. A lot of ?'s in the visual output. 
> Himpf. The point is, which is interesting, if a have an html 
> form with ISO-8859-9 encoded chars, and post it to a jsp 
> file, and write the parameters to a system text file, the 
> text is correct!!
> 
> The problem seems to occur during displaying strings obtained 
> from inside a class .. Any other display problems with other 
> character sets ?? .. Any more idea ?? ..
> 
> Let's remember the problem. We cannot display ISO-8859-9 
> encoded string constants of a class, or strings read from a 
> file, in jsp documents in correct encoding.
> Usage of <%@ page content-type does not solve
> Usage of javac -encoding does not solve
> Usage of encodings in file read/writes of java.io routines 
> does not solve
> 
> The problem is with Tomcat, no problems with Resin used in 
> the same environment, OS/JDK.
> 
> Arif ..
> 



RE: foriegn characters turn to ? in database

2001-07-12 Thread Tõnu Põld

Hi,

There are several places where this "?" conversion might happen.

a) If your JSP page output should be in Latin2, then you must have the <%@
page contentType = "text/html; charset=ISO-8859-2" %> directive in JSP page.
Else the default encoding (iso-8859-1) is used and the strings are converted
from Latin2 to Latin1. Because some Latin2 charcters are missing in Latin1,
those characters are dispayed as question marks.

b) If your database uses Latin2, then the JDBC draiver might not convert the
charcters to correct java unicode charcters. This may happen because the
JDBC draiver thinks your database uses Latin1 encoding. Make sure the JDBC
draiver supports Latin2. This could be tested by getting some Java String
from database and by comparing the numeric character code with the character
code in unicode table (http://www.unicode.org/charts/). For finding the
numeric character code use: 
char c = dbString.charAt(0);

If the JDBC draiver supports only Latin1, then the strings could be
convereted to Latin2 by using something like this:
String s = new String( dbString.getBytes("ISO-8859-1"), "ISO-8859-2");

On most cases the "?" conversion happens when the Java character (16 bit
unicode char) is converted 8-bit character. Please look some Java
tutorial/manual to learn more about the Java Characters/Strings.

Best Regards,
Tõnu

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, July 12, 2001 7:47 AM
> To: [EMAIL PROTECTED]
> Subject: Re: foriegn characters turn to ? in database
> 
> 
> Hi!
> 
> I have seen this behavior too.
> I'm using MYSQL 3.23.36 with Latin2 character set as default. 
> I can see 
> these foreign characters in the database, but they are 
> converted to ? on 
> the JSP output. Sometimes also the foreign characters that 
> are in the JSP 
> itself get converted to ?.
> 
> Any idea?
> 
> Best regards,
>  Kovi
> 
> P.S.: Using WinNT 4 Service Pack 6, Tomcat 3.3m4
> 
> At 22:27 11.7.01 +, you wrote:
> 
> >Bryan, does your database use foreign character sets?
> >
> > >From: "Bryan Murtha"
> > >Reply-To: [EMAIL PROTECTED]
> > >To: [EMAIL PROTECTED]
> > >Subject: foriegn characters turn to ? in database
> > >Date: Wed, 11 Jul 2001 20:58:53
> > >
> > >Hey All,
> > >
> > >
> > > We are accepting form submissions from users all over the world.
> > >The foriegn characters end up in Sybase looking like a ?. Does
> > >someone
> > >know how to deal with this?
> > >
> > >Regards,
> > >Bryan
> > >
> > >
> > >Original Message Follows
> > >From: Stefanos Karasavvidis
> > >Reply-To: [EMAIL PROTECTED]
> > >To: [EMAIL PROTECTED]
> > >Subject: getServletContext() throws NullPoinetException
> > >Date: Tue, 10 Jul 2001 17:46:04 +0300
> > >
> > >I've just installed tomcat 3.2.2 and have the following problem.
> > >
> > >I want to call getServletContext() from a servlets service method
> > >but
> > >get the folowing exception
> > >*Internal Servlet Error:*
> > >
> > >java.lang.NullPointerException
> > > at
> > 
> >javax.servlet.GenericServlet.getServletContext(GenericServlet
.java:205)
> > > at TestServlet.service(TestServlet.java:32)
> > > at
> > 
> >org.apache.tomcat.core.ServletWrapper.doService(ServletWrappe
r.java:405)
> > > at org.apache.tomcat.core.Handler.service(Handler.java:287)
> > > at
> > 
> >org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.
java:372)
> > > at
> > 
> >org.apache.tomcat.core.ContextManager.internalService(Context
Manager.java 
> > :797)
> > > at
> > 
> >org.apache.tomcat.core.ContextManager.service(ContextManager.
> java:743)
> > > at
> > 
> >org.apache.tomcat.service.connector.Ajp12ConnectionHandler.pr
> ocessConnect 
> > ion(Ajp12ConnectionHandler.java:166)
> > > at
> > 
> >org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoi
nt.java:416)
> > > at
> > 
> >org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadP
ool.java:501)
> > > at java.lang.Thread.run(Thread.java:484)
> > >
> > >
> > >Moreover the getServletConfig() returns null which is probably the
> > >main
> > >reason for this problem
> > >
> > >Any ideas??
> > >
> > >Stefanos
> > >
> > >
> > >
> > >_
> > >Get your FREE download of MSN Explorer at http://explorer.msn.com
> > >
> >
> >
> >--
> >Get your FREE download of MSN Explorer at 
> >http://explorer.msn.com
> 



RE: foriegn characters turn to ? in database

2001-07-12 Thread Tõnu Põld

It should work, if the Java has UTF-8 support -- and it does have.

Another case might be when the Java VM doesn't have the international
character encoding support. Some time ago I had trouble with it -- so you
must get the "International" version of JDK (I know that Sun's JDK download
page has two choises, one of which is "International version").

But be aware that most Internet browsers do not send the encoding in HTTP
request. So at server side we must guess what encoding do the bytes (in the
request) have. By default Tomcat 3.2 assumes that they are Latin1. So if you
post a request from a page which is in UTF-8 then the browser sends the
request in UTF-8, but because the encoding is missing, then Tomcat converts
bytes to strings using Latin1 encoding. To convert them correctly you cold
use something like: 

String s = new String(
request.getParameter("my_param").getBytes("ISO-8859-1"), "UTF-8");

Also, some browsers might send UTF-8 request bytes in form %, don't know
how does Tomcat understands that.

Tõnu

> -Original Message-
> From: James Radvan [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, July 12, 2001 12:23 PM
> To: '[EMAIL PROTECTED]'
> Subject: RE: foriegn characters turn to ? in database
> 
> 
> Out of interest, will using "charset=UTF-8" work? (unicode)
> 
> James
> 
> -
> James Radvan
> Websphere Analyst/Architect
> London, UK
> [EMAIL PROTECTED]
> +44 7990 624899
> 
> 



RE: default file name in download

2001-01-17 Thread Tõnu Põld

Hi,

Try the "Content-disposition" header.
It seems to work with MS Internet Explorer and Netscape browsers - I have
not tested others.

If you want to return a RTF file named MyFilename.rtf, it could be done like
this:

class MyServlet extends javax.servlet.http.HttpServlet{
...
  public void doGet(HttpServletRequest req,HttpServletResponse res)
throws javax.servlet.ServletException, java.io.IOException{
...
res.setContentType("text/rtf");
res.setHeader("Content-disposition",
"filename=MyFilename.rtf");
...
  }
}

Regards,
Tõnu

> -Original Message-
> From: cga [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, January 18, 2001 6:44 AM
> To: [EMAIL PROTECTED]
> Subject: default file name in download
> 
> 
> Hi there,
> 
> I am doing a servlet that presents the output in two 
> flawors. The first
> one is a html page, I use a jsp.
> The second one is a downloable file which I generate 
> throught a jsp.
> Changing the content-type is easy. But I would like to give the file a
> download name. I mean, when the user clicks on the save 
> button he would have
> a default name that I will give. I mean, something like 
> 'usefuldata.dat'
> instead of 'MyServlet'.
> Does anybody knows how to do it?
> 
> Thanks in advance,
> 
> Carlos Gaston Alvarez
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
> 

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