[logging] log4j TRACE support justifies minor release

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

[logging] log4j TRACE support justifies minor release

Remko Popma
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

smime.p7s (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

common-logging disabling logging

Alex-123
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:[hidden email]]
Sent: Wednesday, March 15, 2006 9:01 PM
To: [hidden email]
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [logging] log4j TRACE support justifies minor release

Dennis Lundberg-2
In reply to this post by Remko Popma
Hello

Commons Logging 1.1.0 is currently at release candidate 6, which was
announced yesterday. A quote from that announcement:
 "No major issues have been found in the last 5 candidates.
  It is believed that release candidate 6 is ready for a full release."

So it should be available real soon now ;-)

--
Dennis Lundberg

Remko Popma wrote:

> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: common-logging disabling logging

Dennis Lundberg-2
In reply to this post by Alex-123
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:[hidden email]]
> Sent: Wednesday, March 15, 2006 9:01 PM
> To: [hidden email]
> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>

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

Reply | Threaded
Open this post in threaded view
|

RE: [logging] log4j TRACE support justifies minor release

Remko Popma
In reply to this post by Dennis Lundberg-2
Dennis,

Thanks for getting back to me.
I will try the latest nightly build and let you know if I have any problems.

Thanks,
--Remko

-----Original Message-----
From: Dennis Lundberg
Sent: Thursday, March 16, 2006 3:58 PM
To: Jakarta Commons Users List
Subject: Re: [logging] log4j TRACE support justifies minor release


Hello

Commons Logging 1.1.0 is currently at release candidate 6, which was
announced yesterday. A quote from that announcement:
 "No major issues have been found in the last 5 candidates.
  It is believed that release candidate 6 is ready for a full release."

So it should be available real soon now ;-)

--
Dennis Lundberg

Remko Popma wrote:

> 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: [hidden email]
For additional commands, e-mail: [hidden email]


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

Reply | Threaded
Open this post in threaded view
|

RE: [logging] log4j TRACE support justifies minor release

Remko Popma
In reply to this post by Dennis Lundberg-2
PS.
Can you point me to the URL of that announcement?
I could not find it in
 - the jakarta homepage news section
 - the jakarta commons logging home page
 - the wiki...

Thanks, --Remko

-----Original Message-----
From: Dennis Lundberg [mailto:[hidden email]]
Sent: Thursday, March 16, 2006 3:58 PM
To: Jakarta Commons Users List
Subject: Re: [logging] log4j TRACE support justifies minor release


Hello

Commons Logging 1.1.0 is currently at release candidate 6, which was
announced yesterday. A quote from that announcement:
 "No major issues have been found in the last 5 candidates.
  It is believed that release candidate 6 is ready for a full release."

So it should be available real soon now ;-)

--
Dennis Lundberg

Remko Popma wrote:

> 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: [hidden email]
For additional commands, e-mail: [hidden email]


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

Reply | Threaded
Open this post in threaded view
|

Re: [logging] log4j TRACE support justifies minor release

Niall Pemberton
Its not an "official" release yet - just a release candidate - so its
only announced on the mailing list:

http://www.mail-archive.com/commons-dev%40jakarta.apache.org/msg76921.html

Niall

On 3/16/06, Remko Popma <[hidden email]> wrote:

> PS.
> Can you point me to the URL of that announcement?
> I could not find it in
>  - the jakarta homepage news section
>  - the jakarta commons logging home page
>  - the wiki...
>
> Thanks, --Remko
>
> -----Original Message-----
> From: Dennis Lundberg [mailto:[hidden email]]
> To: Jakarta Commons Users List
>
>
> Hello
>
> Commons Logging 1.1.0 is currently at release candidate 6, which was
> announced yesterday. A quote from that announcement:
>  "No major issues have been found in the last 5 candidates.
>  It is believed that release candidate 6 is ready for a full release."
>
> So it should be available real soon now ;-)
>
> --
> Dennis Lundberg
>
> Remko Popma wrote:
> > 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

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

Reply | Threaded
Open this post in threaded view
|

RE: common-logging disabling logging

Alex-123
In reply to this post by Dennis Lundberg-2
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:[hidden email]]
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:[hidden email]]
> Sent: Wednesday, March 15, 2006 9:01 PM
> To: [hidden email]
> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>

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


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

Reply | Threaded
Open this post in threaded view
|

Re: common-logging disabling logging

Dennis Lundberg-2
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:[hidden email]]
> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: common-logging disabling logging

Simon Kitching
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

common-httpclient socket timeout

Alex-123
In reply to this post by Dennis Lundberg-2
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: common-httpclient socket timeout

Tahir Akhtar H.
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:[hidden email]]
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: [hidden email]
For additional commands, e-mail: [hidden email]

--
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: common-httpclient socket timeout

Alex-123
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

[HTTPClient] URL Encoding

Kedar Panse
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

[common-logging] disabling logging

Alex-123
In reply to this post by Dennis Lundberg-2
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [common-logging] disabling logging

Simon Kitching
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: [hidden email]
For additional commands, e-mail: [hidden email]