RE: log4j stops logging at console
Quoting Mark Womack <[EMAIL PROTECTED]>:
> Yeah, but you are playing roulette with determining which application
> installs the respository selector and assuming they are all trying to
> install the same one. It really should be better supported at the container
> level. Have you gotten the JNDI context selector to work in JBoss? I tried
> some time ago and had problems, but did not have a chance to follow up in
> detail.
>
Support at the container level would be nice. My point is that even if JBoss
doesn't feel like supporting it, it is pretty easy to make it happen yourself
without JBoss' support. If one controls the server to a certain degree, the
whole "roulette" analogy fades away. Sometimes it is hard to get a project
that big to listen to you in a timely manner. In any case, the only "support"
we'd need at the container level would be setting a system property. Assuming
the ContextJNDISelector works under JBoss, it would be very simple for someone
to add the extra -D param to JBoss' startup script. I don't know why it
wouldn't work? It works under Tomcat and weblogic. Should work in JBoss.
Jake
> -Mark
>
> > -Original Message-
> > From: Jacob Kjome [mailto:[EMAIL PROTECTED]
> > Sent: Monday, May 16, 2005 8:32 PM
> > To: Log4J Users List
> > Subject: RE: log4j stops logging at console
> >
> >
> > The thing that confused me was that it seemed like he was saying that
> > there
> > were two physically separate instances of JBoss being started up. That
> > is,
> > each in their own JVM. If that were the case, then this issue would be a
> > bit perplexing. If it is all, ultimately running under a single JBoss
> > instance, then your explanation makes sense.
> >
> > I wouldn't say that JBoss needs internal rework to get
> > application-separated logging working, though. If the repository selector
> > hasn't already been set, it can be set once by any application. If it
> > has,
> > then JBoss already has the concept in mind, and they must provide some
> > sort
> > of hook-in to be able to configure the repository selector.
> >
> > Jake
> >
> > At 09:38 AM 5/16/2005 -0700, you wrote:
> > >JBoss, by current design, only provides for one logging context (ie
> > >LoggerRepository). On top of that, the JBoss log4j.xml also sets up a
> > >special CONSOLE appender that maps the System.out and System.err
> > streams.
> > >
> > >If you do any kind of configuration after JBoss starts up that affects
> > the
> > >console appender OR affects loggers that have been defined in the JBoss
> > >log4j.xml file, then it will affect the output to the log files.
> > Especially
> > >Console, do not mess with Console. Also, if your log4j code ever calls
> > >LoggerRepository.shutdown() during a redeploy, then logging will be
> > hosed as
> > >well.
> > >
> > >JBoss really needs to provide a better mechanism to allowing web apps
> > and
> > >ejb's to do their own logging.
> > >
> > >Log4j does provide some "layering" of configuration where you can set up
> > >your own loggers and appenders as long as they are not references by the
> > >first/base configuration file. Or you can just add your logging stuff
> > to
> > >the JBoss log4j.xml file directly.
> > >
> > >You may also find the following link useful, but I don't know if anyone
> > has
> > >gotten to work correctly in JBoss or not. Seems to me that to be
> > completely
> > >efficient, it would need to be supported pretty deep in the JBoss log4j
> > >initialization.
> > >
> > >http://www.qos.ch/logging/sc.jsp
> > >
> > >-Mark
> > >
> > >
> > >> -Original Message-
> > >> From: Clandes Tino [mailto:[EMAIL PROTECTED]
> > >> Sent: Monday, May 16, 2005 6:51 AM
> > >> To: log4j-user@logging.apache.org
> > >> Subject: log4j stops logging at console
> > >>
> > >> Hello all.
> > >> I am facing the problem with log4j usage in two
> > >> separate applications.
> > >> I am using CONSOLE appenders for both of them.
> > >> Applications are started separately (in two shell
> > >> windows). The first app (App1) is assembled as EAR and
> > >> deployed under JBoss (it uses log4j.jar from
> > >> JBoss/server/default/lib and initializes log4j through
> > >> MBean, where appenders and loggers are configured).
> > >>
> > >> Here is the method in MBean that configures log4j in
> > >> App1:
> > >> ---
> > >> private void initLog4j() throws ConfigurationException
> > >> {
> > >> final Properties props = new Properties();
> > >> props.setProperty("log4j.category.com.myapp",
> > >> "DEBUG, CONSOLE, FILE");
> > >>
> > >>
> > props.setProperty("log4j.appender.CONSOLE","org.apache.log4j.ConsoleAppend
> > >> er");
> > >>
> > props.setProperty("log4j.appender.CONSOLE.layout","org.apache.log4j.Patter
> > >> nLayout")
> > >>
> > >>
> > props.setProperty("log4j.appender.CONSOLE.layout.ConversionPattern","%d{IS
> > >> O8601}
> > >> %-5p [%c{1}] [%X{use
test, please ignore
Testing. For some reason my messages to log4j mailing lists are taking a while to post. -Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: log4j stops logging at console
Yeah, but you are playing roulette with determining which application
installs the respository selector and assuming they are all trying to
install the same one. It really should be better supported at the container
level. Have you gotten the JNDI context selector to work in JBoss? I tried
some time ago and had problems, but did not have a chance to follow up in
detail.
-Mark
> -Original Message-
> From: Jacob Kjome [mailto:[EMAIL PROTECTED]
> Sent: Monday, May 16, 2005 8:32 PM
> To: Log4J Users List
> Subject: RE: log4j stops logging at console
>
>
> The thing that confused me was that it seemed like he was saying that
> there
> were two physically separate instances of JBoss being started up. That
> is,
> each in their own JVM. If that were the case, then this issue would be a
> bit perplexing. If it is all, ultimately running under a single JBoss
> instance, then your explanation makes sense.
>
> I wouldn't say that JBoss needs internal rework to get
> application-separated logging working, though. If the repository selector
> hasn't already been set, it can be set once by any application. If it
> has,
> then JBoss already has the concept in mind, and they must provide some
> sort
> of hook-in to be able to configure the repository selector.
>
> Jake
>
> At 09:38 AM 5/16/2005 -0700, you wrote:
> >JBoss, by current design, only provides for one logging context (ie
> >LoggerRepository). On top of that, the JBoss log4j.xml also sets up a
> >special CONSOLE appender that maps the System.out and System.err
> streams.
> >
> >If you do any kind of configuration after JBoss starts up that affects
> the
> >console appender OR affects loggers that have been defined in the JBoss
> >log4j.xml file, then it will affect the output to the log files.
> Especially
> >Console, do not mess with Console. Also, if your log4j code ever calls
> >LoggerRepository.shutdown() during a redeploy, then logging will be
> hosed as
> >well.
> >
> >JBoss really needs to provide a better mechanism to allowing web apps
> and
> >ejb's to do their own logging.
> >
> >Log4j does provide some "layering" of configuration where you can set up
> >your own loggers and appenders as long as they are not references by the
> >first/base configuration file. Or you can just add your logging stuff
> to
> >the JBoss log4j.xml file directly.
> >
> >You may also find the following link useful, but I don't know if anyone
> has
> >gotten to work correctly in JBoss or not. Seems to me that to be
> completely
> >efficient, it would need to be supported pretty deep in the JBoss log4j
> >initialization.
> >
> >http://www.qos.ch/logging/sc.jsp
> >
> >-Mark
> >
> >
> >> -Original Message-
> >> From: Clandes Tino [mailto:[EMAIL PROTECTED]
> >> Sent: Monday, May 16, 2005 6:51 AM
> >> To: log4j-user@logging.apache.org
> >> Subject: log4j stops logging at console
> >>
> >> Hello all.
> >> I am facing the problem with log4j usage in two
> >> separate applications.
> >> I am using CONSOLE appenders for both of them.
> >> Applications are started separately (in two shell
> >> windows). The first app (App1) is assembled as EAR and
> >> deployed under JBoss (it uses log4j.jar from
> >> JBoss/server/default/lib and initializes log4j through
> >> MBean, where appenders and loggers are configured).
> >>
> >> Here is the method in MBean that configures log4j in
> >> App1:
> >> ---
> >> private void initLog4j() throws ConfigurationException
> >> {
> >> final Properties props = new Properties();
> >> props.setProperty("log4j.category.com.myapp",
> >> "DEBUG, CONSOLE, FILE");
> >>
> >>
> props.setProperty("log4j.appender.CONSOLE","org.apache.log4j.ConsoleAppend
> >> er");
> >>
> props.setProperty("log4j.appender.CONSOLE.layout","org.apache.log4j.Patter
> >> nLayout")
> >>
> >>
> props.setProperty("log4j.appender.CONSOLE.layout.ConversionPattern","%d{IS
> >> O8601}
> >> %-5p [%c{1}] [%X{user}] - %m%n");
> >>
> >>
> props.setProperty("log4j.appender.FILE","org.apache.log4j.RollingFileAppen
> >> der");
> >>
> >> props.setProperty("log4j.appender.FILE.File",
> >> getConfigurationSetting(LOG_FILE));
> >>
> >> props.setProperty("log4j.appender.FILE.MaxFileSize",
> >> getConfigurationSetting(MAX_FILE_SIZE));
> >>
> >> props.setProperty("log4j.appender.FILE.MaxBackupIndex",
> >> getConfigurationSetting(MAX_BACKUP_FILE));
> >>
> >>
> props.setProperty("log4j.appender.FILE.layout","org.apache.log4j.PatternLa
> >> yout");
> >>
> >>
> props.setProperty("log4j.appender.FILE.layout.ConversionPattern","%d{ISO86
> >> 01}
> >> %-5p [%c{1}] [%X{user} %X{ip} %X{userAgent}] -
> >> %m%n");
> >>
> >> PropertyConfigurator.configure(props);
> >> }
> >>
> >> App1 uses A.jar and B.jar from App2 in compilation and
> >> runtime. Both jars are placed in sar archive and
> >> deployed in default/deploy folder und
Re: Large log files chainsaw
Hi Andreas, We have large log files as well (between 300MB - 1.5GB per day of pattern layout output). The solution we use, which has its disadvantages admittedly in terms of performance and disk space, is to use two different appenders - one using pattern layout and the other using xml layout. The xml one is rotated every 50MB, the other is rotated daily. Support teams use the pattern layout file (outside of chainsaw) for simple tasks and if deeper analysis is required we load the 50MB xmllayout file into chainsaw (50MB ~= 100,000 events). We also have a JMS appender logging to a non-persistent weblogic jms topic and we use a JMS receiver to monitor the system in realtime occasionally if necessary (but this is mainly because our file logs are on a filesystem that's not easy to access). Fortunately even with the increased logging overhead from all these appenders, performance is still acceptable, and we only keep the logs for a month before deleting them so space isn't a problem either. Cheers, Stephen Andreas Knecht <[EMAIL PROTECTED]> 17/05/2005 01:17
RE: Large log files chainsaw
Here are a few recommendations: - Filter events at the receiver - LogFilePatternReceiver provides a 'filterExpression' parameter. Only events that match the expression are processed in the UI. - Modify VM args - get the bundle from the Chainsaw page and run Chainsaw from the command line, adjusting appropriate parameters (heap, gc, etc) - Make sure the cyclic buffer size is larger than your log file size (using wc -l or another utility) - Cut the file into pieces and load the pieces one at a time Scott -Original Message- From: Andreas Knecht [mailto:[EMAIL PROTECTED] Sent: Mon 5/16/2005 5:17 PM To: Log4J Users List Cc: Subject:Large log files chainsaw Hi everyone, I would like to use chainsaw with some production logs (with the filepattern receiver). Only problem is that these logs tend to be around 200-300 MB in size (around 1.2-1.8 Million lines). I've tried increasing the cyclic buffer size to 50 and chainsaw became more or less unusable as soon as I started the receiver to parse the log file. Has anyone here tried to use chainsaw for similar purposes? Any recommendations? Are there other gui tools to view logs that perform better than chainsaw for this task? Regards, Andreas -- Andreas Knecht Object Consulting Level 25, Northpoint, 100 Miller St North Sydney. NSW 2060 Direct: +61 2 9459 3398 http://www.objectconsulting.com.au/ - 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: PropertyConfigurator.configure problem
See the "Default Initialization Procedure" section at http://logging.apache.org/log4j/docs/manual.html Bascially default initialization is probably happening before you call PropertyConfigurator.configure. It would be best to remove log4j.properties from the classpath. On 5/4/05, Tishkin, Eugene <[EMAIL PROTECTED]> wrote: > > > Why when I call PropertyConfigurator.configure method and provide > Properties object as a parameter or file, it's looking for > log4j.properties file anyway and grabs first on the CLASSPATH? > > Shouldn't it just use what was provided? > > Regards, > Eugene Tishkin > > This e-mail and any attachments may contain confidential information. Any > distributing, copying or reliance upon the contents of this e-mail by anyone > other > than the intended recipient is strictly prohibited. If you have received this > e-mail > accidentally, please delete it and notify the sender. Although this message > has been > screened for viruses, we cannot guarantee that our virus scanner will detect > all > viruses and take no responsibility for any damage or loss that may be caused > by its > contents. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- James Stauffer Are you good? Take the test at http://www.livingwaters.com/good/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
changing the font and color of error messages
Hi, I would like to change the color and font of error messages in the log file while logging. how can i do this??? thanks n regards, Sridhar Reddy -Original Message- From: Curt Arnold [mailto:[EMAIL PROTECTED] Sent: Monday, May 16, 2005 6:11 PM To: Log4J Users List Subject: Re: log4j stops logging at console On May 16, 2005, at 8:50 AM, Clandes Tino wrote: > Hello all. > I am facing the problem with log4j usage in two > separate applications. > I am using CONSOLE appenders for both of them. > Applications are started separately (in two shell > windows). The first app (App1) is assembled as EAR and > deployed under JBoss (it uses log4j.jar from > JBoss/server/default/lib and initializes log4j through > MBean, where appenders and loggers are configured). > > Could you see if the problem occurs with the CVS HEAD? It might be an instance of bug 31056 (http://issues.apache.org/bugzilla/ show_bug.cgi?id=31056) which was recently addressed. - 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: log4j stops logging at console
The thing that confused me was that it seemed like he was saying that there
were two physically separate instances of JBoss being started up. That is,
each in their own JVM. If that were the case, then this issue would be a
bit perplexing. If it is all, ultimately running under a single JBoss
instance, then your explanation makes sense.
I wouldn't say that JBoss needs internal rework to get
application-separated logging working, though. If the repository selector
hasn't already been set, it can be set once by any application. If it has,
then JBoss already has the concept in mind, and they must provide some sort
of hook-in to be able to configure the repository selector.
Jake
At 09:38 AM 5/16/2005 -0700, you wrote:
>JBoss, by current design, only provides for one logging context (ie
>LoggerRepository). On top of that, the JBoss log4j.xml also sets up a
>special CONSOLE appender that maps the System.out and System.err streams.
>
>If you do any kind of configuration after JBoss starts up that affects the
>console appender OR affects loggers that have been defined in the JBoss
>log4j.xml file, then it will affect the output to the log files. Especially
>Console, do not mess with Console. Also, if your log4j code ever calls
>LoggerRepository.shutdown() during a redeploy, then logging will be hosed as
>well.
>
>JBoss really needs to provide a better mechanism to allowing web apps and
>ejb's to do their own logging.
>
>Log4j does provide some "layering" of configuration where you can set up
>your own loggers and appenders as long as they are not references by the
>first/base configuration file. Or you can just add your logging stuff to
>the JBoss log4j.xml file directly.
>
>You may also find the following link useful, but I don't know if anyone has
>gotten to work correctly in JBoss or not. Seems to me that to be completely
>efficient, it would need to be supported pretty deep in the JBoss log4j
>initialization.
>
>http://www.qos.ch/logging/sc.jsp
>
>-Mark
>
>
>> -Original Message-
>> From: Clandes Tino [mailto:[EMAIL PROTECTED]
>> Sent: Monday, May 16, 2005 6:51 AM
>> To: log4j-user@logging.apache.org
>> Subject: log4j stops logging at console
>>
>> Hello all.
>> I am facing the problem with log4j usage in two
>> separate applications.
>> I am using CONSOLE appenders for both of them.
>> Applications are started separately (in two shell
>> windows). The first app (App1) is assembled as EAR and
>> deployed under JBoss (it uses log4j.jar from
>> JBoss/server/default/lib and initializes log4j through
>> MBean, where appenders and loggers are configured).
>>
>> Here is the method in MBean that configures log4j in
>> App1:
>> ---
>> private void initLog4j() throws ConfigurationException
>> {
>> final Properties props = new Properties();
>> props.setProperty("log4j.category.com.myapp",
>> "DEBUG, CONSOLE, FILE");
>>
>> props.setProperty("log4j.appender.CONSOLE","org.apache.log4j.ConsoleAppend
>> er");
>> props.setProperty("log4j.appender.CONSOLE.layout","org.apache.log4j.Patter
>> nLayout")
>>
>> props.setProperty("log4j.appender.CONSOLE.layout.ConversionPattern","%d{IS
>> O8601}
>> %-5p [%c{1}] [%X{user}] - %m%n");
>>
>> props.setProperty("log4j.appender.FILE","org.apache.log4j.RollingFileAppen
>> der");
>>
>> props.setProperty("log4j.appender.FILE.File",
>> getConfigurationSetting(LOG_FILE));
>>
>> props.setProperty("log4j.appender.FILE.MaxFileSize",
>> getConfigurationSetting(MAX_FILE_SIZE));
>>
>> props.setProperty("log4j.appender.FILE.MaxBackupIndex",
>> getConfigurationSetting(MAX_BACKUP_FILE));
>>
>> props.setProperty("log4j.appender.FILE.layout","org.apache.log4j.PatternLa
>> yout");
>>
>> props.setProperty("log4j.appender.FILE.layout.ConversionPattern","%d{ISO86
>> 01}
>> %-5p [%c{1}] [%X{user} %X{ip} %X{userAgent}] -
>> %m%n");
>>
>> PropertyConfigurator.configure(props);
>> }
>>
>> App1 uses A.jar and B.jar from App2 in compilation and
>> runtime. Both jars are placed in sar archive and
>> deployed in default/deploy folder under Jboss.
>>
>> The other (App2) is RMI Server application deployed
>> separately (it uses another log4j-1.2.8.jar placed in
>> its classpath). A.jar and B.jar are in its classpath.
>> App2 configures log4j by log4j properties file:
>>
>>
>> log4j.category.CONSOLE = , aCONSOLE
>> log4j.appender.aCONSOLE =
>> org.apache.log4j.ConsoleAppender
>> log4j.additivity.CONSOLE=false
>> log4j.appender.aCONSOLE.ImmediateFlush=true
>> log4j.appender.aCONSOLE.layout=org.apache.log4j.PatternLayout
>> --
>>
>> Both applications are physically on the same machine.
>> The problem occurs when some class from App1 invokes a
>> class from B.jar. Then logging disappears from console
>> window of App1. No further message in log appears.
>> However logging into file works OK.
>>
>> My question is:
>> What can
Large log files chainsaw
Hi everyone, I would like to use chainsaw with some production logs (with the filepattern receiver). Only problem is that these logs tend to be around 200-300 MB in size (around 1.2-1.8 Million lines). I've tried increasing the cyclic buffer size to 50 and chainsaw became more or less unusable as soon as I started the receiver to parse the log file. Has anyone here tried to use chainsaw for similar purposes? Any recommendations? Are there other gui tools to view logs that perform better than chainsaw for this task? Regards, Andreas -- Andreas Knecht Object Consulting Level 25, Northpoint, 100 Miller St North Sydney. NSW 2060 Direct: +61 2 9459 3398 http://www.objectconsulting.com.au/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: log4j stops logging at console
JBoss, by current design, only provides for one logging context (ie
LoggerRepository). On top of that, the JBoss log4j.xml also sets up a
special CONSOLE appender that maps the System.out and System.err streams.
If you do any kind of configuration after JBoss starts up that affects the
console appender OR affects loggers that have been defined in the JBoss
log4j.xml file, then it will affect the output to the log files. Especially
Console, do not mess with Console. Also, if your log4j code ever calls
LoggerRepository.shutdown() during a redeploy, then logging will be hosed as
well.
JBoss really needs to provide a better mechanism to allowing web apps and
ejb's to do their own logging.
Log4j does provide some "layering" of configuration where you can set up
your own loggers and appenders as long as they are not references by the
first/base configuration file. Or you can just add your logging stuff to
the JBoss log4j.xml file directly.
You may also find the following link useful, but I don't know if anyone has
gotten to work correctly in JBoss or not. Seems to me that to be completely
efficient, it would need to be supported pretty deep in the JBoss log4j
initialization.
http://www.qos.ch/logging/sc.jsp
-Mark
> -Original Message-
> From: Clandes Tino [mailto:[EMAIL PROTECTED]
> Sent: Monday, May 16, 2005 6:51 AM
> To: log4j-user@logging.apache.org
> Subject: log4j stops logging at console
>
> Hello all.
> I am facing the problem with log4j usage in two
> separate applications.
> I am using CONSOLE appenders for both of them.
> Applications are started separately (in two shell
> windows). The first app (App1) is assembled as EAR and
> deployed under JBoss (it uses log4j.jar from
> JBoss/server/default/lib and initializes log4j through
> MBean, where appenders and loggers are configured).
>
> Here is the method in MBean that configures log4j in
> App1:
> ---
> private void initLog4j() throws ConfigurationException
> {
> final Properties props = new Properties();
> props.setProperty("log4j.category.com.myapp",
> "DEBUG, CONSOLE, FILE");
>
> props.setProperty("log4j.appender.CONSOLE","org.apache.log4j.ConsoleAppend
> er");
> props.setProperty("log4j.appender.CONSOLE.layout","org.apache.log4j.Patter
> nLayout")
>
> props.setProperty("log4j.appender.CONSOLE.layout.ConversionPattern","%d{IS
> O8601}
> %-5p [%c{1}] [%X{user}] - %m%n");
>
> props.setProperty("log4j.appender.FILE","org.apache.log4j.RollingFileAppen
> der");
>
> props.setProperty("log4j.appender.FILE.File",
> getConfigurationSetting(LOG_FILE));
>
> props.setProperty("log4j.appender.FILE.MaxFileSize",
> getConfigurationSetting(MAX_FILE_SIZE));
>
> props.setProperty("log4j.appender.FILE.MaxBackupIndex",
> getConfigurationSetting(MAX_BACKUP_FILE));
>
> props.setProperty("log4j.appender.FILE.layout","org.apache.log4j.PatternLa
> yout");
>
> props.setProperty("log4j.appender.FILE.layout.ConversionPattern","%d{ISO86
> 01}
> %-5p [%c{1}] [%X{user} %X{ip} %X{userAgent}] -
> %m%n");
>
> PropertyConfigurator.configure(props);
> }
>
> App1 uses A.jar and B.jar from App2 in compilation and
> runtime. Both jars are placed in sar archive and
> deployed in default/deploy folder under Jboss.
>
> The other (App2) is RMI Server application deployed
> separately (it uses another log4j-1.2.8.jar placed in
> its classpath). A.jar and B.jar are in its classpath.
> App2 configures log4j by log4j properties file:
>
>
> log4j.category.CONSOLE = , aCONSOLE
> log4j.appender.aCONSOLE =
> org.apache.log4j.ConsoleAppender
> log4j.additivity.CONSOLE=false
> log4j.appender.aCONSOLE.ImmediateFlush=true
> log4j.appender.aCONSOLE.layout=org.apache.log4j.PatternLayout
> --
>
> Both applications are physically on the same machine.
> The problem occurs when some class from App1 invokes a
> class from B.jar. Then logging disappears from console
> window of App1. No further message in log appears.
> However logging into file works OK.
>
> My question is:
> What can cause such behavior?
>
> Thanx for the hint in advance.
> Best regards
> Milan
>
>
>
>
> ___
> How much free photo storage do you get? Store your holiday
> snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com
>
> -
> 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]
