You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@commons.apache.org by Alex <al...@optonline.net> on 2006/03/16 05:38:39 UTC
common-logging disabling logging
I installed commons http-client and had to add commons-logging b/c it
requires it. I read the docs on 'logging' which either I don't understand
well or docs don't really explain how to setup logging, find out which
logging it's using. If I need to do it in main method or whatever For now
all I really need is to find out how to disable all those "INFO and warnings
logging. If some1 has an example or know how to do it feel free to let me
know.
Thanks
-----Original Message-----
From: Remko Popma [mailto:remko@daiwasmbc.co.jp]
Sent: Wednesday, March 15, 2006 9:01 PM
To: commons-user@jakarta.apache.org
Subject: [logging] log4j TRACE support justifies minor release
I hope this is the correct mailing list, apologies if dev would have been
better.
Support for TRACE-level logging has been available for about eight months
now (log4j 1.2.12 was released in August 2005).
As you are probably aware, the current commons.logging release (1.0.4)
outputs Log.trace() calls at DEBUG level, even if the underlying log4j
version supports the TRACE level.
I understand that this will be fixed in the upcoming JCL 1.1 release, but
this release will also include many other features and fixes, and the
Release Plan wiki page
(http://wiki.apache.org/jakarta-commons/Logging/1.1.0ReleasePlan)
does not have a release date and shows the status as "Preparations for
Alpha 1".
This sounds like a release is still a long time (several months) away.
I also saw that plans for a 1.0.5 release (with support for log4j TRACE
level logging) were cancelled because developers wanted to include so many
new features that a 1.1 release was justified.
I think it is great that developers are so enthusiastic and have many
ideas about how to improve JCL. For servlet-related work, the JCL 1.1
release is probably a great step forward. However, there must be many
developers working on both servlet and non-servlet projects who would
*really* like to have proper TRACE support in commons.logging soon, and
who don't like to wait for the JCL 1.1 release.
Please don't become like log4j 1.3, which has a zillion great features and
will be released Real Soon Now...
I believe that TRACE support alone would justify a minor release.
Would it be a lot of work to release a new version of commons.logging
(1.0.5) with *only* the TRACE issue fixed, and no other changes?
Respectfully,
--Remko Popma
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [common-logging] disabling logging
Posted by Simon Kitching <sk...@apache.org>.
Hi Alex,
On Sat, 2006-04-01 at 20:00 -0500, Alex wrote:
> I can't seem to get disabling logging to work.
>
> I made a jar file put another file 'commons-logging.properties' inside of
> it. Added text
> 'org.apache.commons.logging.Log=org.apache.commons.logging.impl.NoOpLog'
> To it. Put it the first thing in my CLASSPATH and logging still shows up...
>
> Any ideas?
You mean you've created a jarfile 'foo.jar' containing
commons-logging.properties (and maybe some other stuff), and added
foo.jar to the classpath?
I presume you've put the commons-logging.properties file at the top
level, not nested under something like net.optonline.foo.
The thing most likely to be wrong is that somehow your jar is *not* the
first thing on the classpath.
Is the code you're running a stand-alone app, a webapp, or something
else? If you're talking about a webapp, then there are of course
multiple classpaths involved. Generally, environments like Tomcat ignore
any CLASSPATH environment variable and set their own for example.
If you can add something like this to your code it would help debugging
this issue:
Enumeration e = Thread.currentThread.getContextClassLoader().
getResources("commons-logging.properties");
while (e.hasMoreElements()) {
System.out.println(e.nextElement());
}
That will show where the commons-logging.properties file really occurs on the classpath.
Which version of commons-logging are you using?
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
[common-logging] disabling logging
Posted by Alex <al...@optonline.net>.
I can't seem to get disabling logging to work.
I made a jar file put another file 'commons-logging.properties' inside of
it. Added text
'org.apache.commons.logging.Log=org.apache.commons.logging.impl.NoOpLog'
To it. Put it the first thing in my CLASSPATH and logging still shows up...
Any ideas?
Thanks
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: common-logging disabling logging
Posted by Simon Kitching <sk...@apache.org>.
Yep. However using a commons-logging.properties file is generally more
convenient.
You should check whether there is already a commons-logging.properties
file in the classpath (eg inside a jarfile) at a position earlier than
the one you created.
Note that the file should be at the "top level", eg not nested inside
com/acme/...
Cheers,
Simon
On Fri, 2006-03-17 at 20:55 +0100, Dennis Lundberg wrote:
> Hi Alex
>
> Another way to do it is to set a system property when you run your
> program. Something like this (but all on one line):
>
> java -classpath=...
> -Dorg.apache.commons.logging.Log=org.apache.commons.logging.impl.NoOpLog
> com.yourcompany.YourClass
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
[HTTPClient] URL Encoding
Posted by Kedar Panse <ke...@bancbridge.com>.
Greetings!
1. Are there any utility classes from which I can detect if a URL is
encoded or not. In case of redirects which I am handling manually,
Sometimes url is encoded but some servers/sites provide it not encoded.
Is there any smarter way of handling this?
2. I have seen some sites need + for a space and don't accept %20 (may
be some one using manual parsing...). But is there any way I can for
URI class to use + and not %20 ?
Thanks!
Kedar
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
RE: common-httpclient socket timeout
Posted by Alex <al...@optonline.net>.
Am I using the code below correctly to check that it doesn't take URL over
10 seconds to load?
SimpleHttpConnectionManager mr = new SimpleHttpConnectionManager();
mr.getParams().setConnectionTimeout(10000);
HttpClient client = new HttpClient(mr);
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
RE: common-httpclient socket timeout
Posted by Tahir Akhtar <ta...@spectrum-tech.com>.
As far as I know connection timeout property means this:
Abort the connection attempt if connection is not successfully *made* within
specified time limit.
This property is provided so that you can tell the API that I don’t want my
call to connect block for more than specified time. If you don't provide
this parameter than default TCP time-out of underlying implementation will
come into play.
This property has no effect once the connection is successfully made. It
does not dictate how much time connection can remain open.
You will have take a different approach if you want to check how much time
the site took to load, perhaps by taking system time before and after the
operation and subtracting them to find the duration.
Regards,
Tahir Akhtar
-----Original Message-----
From: Alex [mailto:alexny20@optonline.net]
Sent: Monday, March 20, 2006 5:19 AM
To: 'Jakarta Commons Users List'
Subject: common-httpclient socket timeout
I need to set a timeout parameter for a URL. To see if the site is timing
out, (if possible how long it takes to load the site), or just throw an
exception if website is not loaded within given time.
I know I am doing something wrong in the code below, does someone know
HttpClient client = new HttpClient();
HttpClientParams clientParams = new HttpClientParams();
clientParams.setConnectionManagerTimeout(10000);
client.setParams(clientParams);
Thanks
Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.385 / Virus Database: 268.2.5/284 - Release Date: 3/17/2006
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.385 / Virus Database: 268.2.5/284 - Release Date: 3/17/2006
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
common-httpclient socket timeout
Posted by Alex <al...@optonline.net>.
I need to set a timeout parameter for a URL. To see if the site is timing
out, (if possible how long it takes to load the site), or just throw an
exception if website is not loaded within given time.
I know I am doing something wrong in the code below, does someone know
HttpClient client = new HttpClient();
HttpClientParams clientParams = new HttpClientParams();
clientParams.setConnectionManagerTimeout(10000);
client.setParams(clientParams);
Thanks
Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: common-logging disabling logging
Posted by Dennis Lundberg <de...@apache.org>.
Hi Alex
Another way to do it is to set a system property when you run your
program. Something like this (but all on one line):
java -classpath=...
-Dorg.apache.commons.logging.Log=org.apache.commons.logging.impl.NoOpLog
com.yourcompany.YourClass
--
Dennis Lundberg
Alex wrote:
> Thanks Dennis for your response.
> Do you have any other ideas how to disable it because I created
> commons-logging.properties file with
> org.apache.commons.logging.Log=org.apache.commons.logging.impl.NoOpLog
> Added it in my classpath and my program still sends logging info to the
> console.
>
> Thanks
> Alex
>
> -----Original Message-----
> From: Dennis Lundberg [mailto:dennisl@apache.org]
> Sent: Thursday, March 16, 2006 2:04 AM
> To: Jakarta Commons Users List
> Subject: Re: common-logging disabling logging
>
> Hello
>
> In order to disable logging completely you can put a file called
> commons-logging.properties in your class path with the following contents:
>
> org.apache.commons.logging.Log=org.apache.commons.logging.impl.NoOpLog
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
RE: common-logging disabling logging
Posted by Alex <al...@optonline.net>.
Thanks Dennis for your response.
Do you have any other ideas how to disable it because I created
commons-logging.properties file with
org.apache.commons.logging.Log=org.apache.commons.logging.impl.NoOpLog
Added it in my classpath and my program still sends logging info to the
console.
Thanks
Alex
-----Original Message-----
From: Dennis Lundberg [mailto:dennisl@apache.org]
Sent: Thursday, March 16, 2006 2:04 AM
To: Jakarta Commons Users List
Subject: Re: common-logging disabling logging
Hello
In order to disable logging completely you can put a file called
commons-logging.properties in your class path with the following contents:
org.apache.commons.logging.Log=org.apache.commons.logging.impl.NoOpLog
--
Dennis Lundberg
Alex wrote:
> I installed commons http-client and had to add commons-logging b/c it
> requires it. I read the docs on 'logging' which either I don't understand
> well or docs don't really explain how to setup logging, find out which
> logging it's using. If I need to do it in main method or whatever For now
> all I really need is to find out how to disable all those "INFO and
warnings
> logging. If some1 has an example or know how to do it feel free to let me
> know.
>
> Thanks
>
> -----Original Message-----
> From: Remko Popma [mailto:remko@daiwasmbc.co.jp]
> Sent: Wednesday, March 15, 2006 9:01 PM
> To: commons-user@jakarta.apache.org
> Subject: [logging] log4j TRACE support justifies minor release
>
> I hope this is the correct mailing list, apologies if dev would have been
> better.
>
> Support for TRACE-level logging has been available for about eight months
> now (log4j 1.2.12 was released in August 2005).
> As you are probably aware, the current commons.logging release (1.0.4)
> outputs Log.trace() calls at DEBUG level, even if the underlying log4j
> version supports the TRACE level.
>
> I understand that this will be fixed in the upcoming JCL 1.1 release, but
> this release will also include many other features and fixes, and the
> Release Plan wiki page
> (http://wiki.apache.org/jakarta-commons/Logging/1.1.0ReleasePlan)
> does not have a release date and shows the status as "Preparations for
> Alpha 1".
> This sounds like a release is still a long time (several months) away.
>
> I also saw that plans for a 1.0.5 release (with support for log4j TRACE
> level logging) were cancelled because developers wanted to include so many
> new features that a 1.1 release was justified.
>
> I think it is great that developers are so enthusiastic and have many
> ideas about how to improve JCL. For servlet-related work, the JCL 1.1
> release is probably a great step forward. However, there must be many
> developers working on both servlet and non-servlet projects who would
> *really* like to have proper TRACE support in commons.logging soon, and
> who don't like to wait for the JCL 1.1 release.
> Please don't become like log4j 1.3, which has a zillion great features and
> will be released Real Soon Now...
>
> I believe that TRACE support alone would justify a minor release.
> Would it be a lot of work to release a new version of commons.logging
> (1.0.5) with *only* the TRACE issue fixed, and no other changes?
>
> Respectfully,
> --Remko Popma
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: common-logging disabling logging
Posted by Dennis Lundberg <de...@apache.org>.
Hello
In order to disable logging completely you can put a file called
commons-logging.properties in your class path with the following contents:
org.apache.commons.logging.Log=org.apache.commons.logging.impl.NoOpLog
--
Dennis Lundberg
Alex wrote:
> I installed commons http-client and had to add commons-logging b/c it
> requires it. I read the docs on 'logging' which either I don't understand
> well or docs don't really explain how to setup logging, find out which
> logging it's using. If I need to do it in main method or whatever For now
> all I really need is to find out how to disable all those "INFO and warnings
> logging. If some1 has an example or know how to do it feel free to let me
> know.
>
> Thanks
>
> -----Original Message-----
> From: Remko Popma [mailto:remko@daiwasmbc.co.jp]
> Sent: Wednesday, March 15, 2006 9:01 PM
> To: commons-user@jakarta.apache.org
> Subject: [logging] log4j TRACE support justifies minor release
>
> I hope this is the correct mailing list, apologies if dev would have been
> better.
>
> Support for TRACE-level logging has been available for about eight months
> now (log4j 1.2.12 was released in August 2005).
> As you are probably aware, the current commons.logging release (1.0.4)
> outputs Log.trace() calls at DEBUG level, even if the underlying log4j
> version supports the TRACE level.
>
> I understand that this will be fixed in the upcoming JCL 1.1 release, but
> this release will also include many other features and fixes, and the
> Release Plan wiki page
> (http://wiki.apache.org/jakarta-commons/Logging/1.1.0ReleasePlan)
> does not have a release date and shows the status as "Preparations for
> Alpha 1".
> This sounds like a release is still a long time (several months) away.
>
> I also saw that plans for a 1.0.5 release (with support for log4j TRACE
> level logging) were cancelled because developers wanted to include so many
> new features that a 1.1 release was justified.
>
> I think it is great that developers are so enthusiastic and have many
> ideas about how to improve JCL. For servlet-related work, the JCL 1.1
> release is probably a great step forward. However, there must be many
> developers working on both servlet and non-servlet projects who would
> *really* like to have proper TRACE support in commons.logging soon, and
> who don't like to wait for the JCL 1.1 release.
> Please don't become like log4j 1.3, which has a zillion great features and
> will be released Real Soon Now...
>
> I believe that TRACE support alone would justify a minor release.
> Would it be a lot of work to release a new version of commons.logging
> (1.0.5) with *only* the TRACE issue fixed, and no other changes?
>
> Respectfully,
> --Remko Popma
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org