Re: Welcome Adrian

[Adrian Sutton]

On Tuesday, June 3, 2003, at 04:42  PM, Ortwin Glück wrote:

Adrian Sutton wrote:
And if anyone ever works out how a company with just 15 employees 
winds up having this much trouble approving one signature I'd love to 
hear the explanation... :)
Adrian,

Welcome, man! It's good to have you on board.
Thanks Odi.

Just a few thoughts about the legal noise:
The agreement must be signed by you, not your boss. What you commit is 
your responsibility. How this integrates with your company is an issue 
only between you and your company, but not between Apache Group and 
your company. So you can just fax in the form signed by you. But you 
should have a similar agreement with your company that you are allowed 
to contribute certain code under the Apache License.
Yep, the current problem is getting permission for me to sign the form. 
 Since I very occasionally work on HttpClient from work (we do use it 
in our product) any formal agreements in relation to me and HttpClient 
needs to have approval from my employer.  Also, the license agreement 
specifically states that I should get clearance from my employer.  
Things get even foggier because any work I do relating to my work at 
Ephox is owned by Ephox so even working on HttpClient in my own time 
involves Ephox.  This may turn out to be the trigger to demand some 
changes to my employment conditions but we'll see how it goes.  
Generally I don't have any problems with them, just this case is a 
little more difficult. :)

Of course it's a good idea however to make your boss review the Apache 
agreement and sign it. Just gives a better feeling in your stomach, 
doesn't it. Took me about 10 minutes to get the signatures for mine. 
And  my company has around 30 employees. :-)
Maybe I just need a bigger company so I can hide it in the "to be 
signed pile" better. :)

Odi
Adrian.

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

Re: Welcome Adrian

[Ortwin Glück]

Adrian Sutton wrote:
And if anyone ever works out how a company with just 15 employees winds 
up having this much trouble approving one signature I'd love to hear the 
explanation... :)
Adrian,

Welcome, man! It's good to have you on board.

Just a few thoughts about the legal noise:
The agreement must be signed by you, not your boss. What you commit is 
your responsibility. How this integrates with your company is an issue 
only between you and your company, but not between Apache Group and your 
company. So you can just fax in the form signed by you. But you should 
have a similar agreement with your company that you are allowed to 
contribute certain code under the Apache License.

Of course it's a good idea however to make your boss review the Apache 
agreement and sign it. Just gives a better feeling in your stomach, 
doesn't it. Took me about 10 minutes to get the signatures for mine. And 
 my company has around 30 employees. :-)

Odi

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

Re: setUseCaches

[Ortwin Glück]

Omar,

Unlike a web browser, HttpClient does not do any caching unless required 
by the way you use it. For instance, setting the request body as a 
string or querying the response as a string will cause some caching to 
happen. Just make sure you work with streams, then no request / response 
will be cached internally.

To control caching at the proxy you need to set the headers yourself.

Odi

O Khalid wrote:
hey guys,

I was wondering if anyone knows how to dis-able cache using the
httpClient. I believe the HttpURLConnection class does not support
setUseCaches method yet. Does anyone know of a certain HTTP Header
that could be set in the request body to achieve this.
Thanks

Omar



- Post your free ad now! Yahoo!
Canada Personals
--
_
 NOSE applied intelligence ag
   [www]  http://www.nose.ch
 ortwin glück  [email] [EMAIL PROTECTED]
 hardturmstrasse 171   [pgp key]  0x81CF3416
 8005 zurich   [office]  +41-1-277 57 35
 switzerland   [fax] +41-1-277 57 12
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Welcome Adrian

[Wilcox, Mark]

>And if anyone ever works out how a company with just 15 employees winds
>up having this much trouble approving one signature I'd love to hear
>the explanation... :)

The answer is a song called "contracts, lawsuits and lawyers" :). 
 
Or as I like to say it -- everyone is a geek at something. Lawyers are geeks for 
contracts. Just as we get jazzed by reading/writing code, they get jazzed by 
reading/writing contracts. 
 
 
Mark

-Original Message- 
From: Adrian Sutton [mailto:[EMAIL PROTECTED] 
Sent: Mon 6/2/2003 11:56 PM 
To: Commons HttpClient Project 
Cc: 
Subject: Re: Welcome Adrian



> Once I get the contributor agreement faxed in I'll proudly add my name
> to the list of committers for the project then wait for all those
> wonderful new patches to come rolling in. :)

There's one slight hiccup in this process that I just wanted to provide
a heads up for.  My boss feels that he should get approval from the
board before I sign the apache contributor license agreement though
he's certain there won't be a problem with it.  The only time frame I
have is "that shouldn't take long" so it looks like I won't be doing
any committing for a while.  There's no issues with my actual
contributions just with the actual signing of a form so I'll stay away
from using any of my new-found Apache powers until I can happily get
that form signed.

And if anyone ever works out how a company with just 15 employees winds
up having this much trouble approving one signature I'd love to hear
the explanation... :)

Regards,

Adrian Sutton.


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

Re: Welcome Adrian

[Adrian Sutton]

Once I get the contributor agreement faxed in I'll proudly add my name 
to the list of committers for the project then wait for all those 
wonderful new patches to come rolling in. :)
There's one slight hiccup in this process that I just wanted to provide 
a heads up for.  My boss feels that he should get approval from the 
board before I sign the apache contributor license agreement though 
he's certain there won't be a problem with it.  The only time frame I 
have is "that shouldn't take long" so it looks like I won't be doing 
any committing for a while.  There's no issues with my actual 
contributions just with the actual signing of a form so I'll stay away 
from using any of my new-found Apache powers until I can happily get 
that form signed.

And if anyone ever works out how a company with just 15 employees winds 
up having this much trouble approving one signature I'd love to hear 
the explanation... :)

Regards,

Adrian Sutton.

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

Re: [REPORT] 2.0 beta 1 and Tomcat 4

[Michael Becke]

I have re-published the Beta 1 distribution to the various download  
sites.  This newer version removes the "Extension-List" manifest  
entries for commons-logging and JUnit.  I tested an HttpClient servlet  
with Tomcat 4.1.18 and all seemed well.  The jar on ibiblio has not  
been updated as of yet, but I will keep you posted.

Mike

On Monday, June 2, 2003, at 10:54 AM, Ias wrote:

The current 2.0 beta 1 distribution doesn't work with Tomcat 4.x. The
error message is
Catalina.start: LifecycleException:  Missing optional package
Extension[junit,
implementationURL=http://www.ibiblio.org/maven/junit/jars/junit- 
3.8.1.ja
r, implementationVersion=3.8.1]
LifecycleException:  Missing optional package Extension[junit,
implementationURL=http://www.ibiblio.org/maven/junit/jars/junit- 
3.8.1.ja
r, implementationVersion=3.8.1]
	at
org.apache.catalina.loader.WebappLoader.validatePackages(WebappLoader.j 
a
va:1244)
	at
org.apache.catalina.loader.WebappLoader.start(WebappLoader.java:645)
	at
org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1100)
	at
org.apache.catalina.core.StandardContext.start(StandardContext.java:334 
5
)
	at
org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1123)
	at
org.apache.catalina.core.StandardHost.start(StandardHost.java:614)
	at
org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1123)
	at
org.apache.catalina.core.StandardEngine.start(StandardEngine.java:343)
	at
org.apache.catalina.core.StandardService.start(StandardService.java:388 
)
	at
org.apache.catalina.core.StandardServer.start(StandardServer.java:506)
	at org.apache.catalina.startup.Catalina.start(Catalina.java:781)
	at
org.apache.catalina.startup.Catalina.execute(Catalina.java:681)
	at
org.apache.catalina.startup.Catalina.process(Catalina.java:179)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.ja 
v
a:39)
	at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccesso 
r
Impl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:324)
	at
org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:243)

I looked into the stack trace and found that there needed to be some
modification toward the associated
jars-commons-httpclient-2.0-beta1.jar, junit-3.8.1.jar, and
commons-logging-1.0.jar.
First, Tomcat's org.apache.catalina.loader.Extension.getRequired
distinguishes required libraries by delimiter not "," but " ".
Therefore,
Extension-List: junit,commons-logging

should be

Extension-List: junit commons-logging

in MANIFEST.MF of httpclient jar.
(http://java.sun.com/j2se/1.4.1/docs/guide/extensions/versioning.html
proves the usage.)
Next, since Tomcat's resolving algorithm for required libraries is  
quite
strict as implemented in o.a.c.l.WebappLoader.validatePackages(),
Specification-Version and Implementation-Vendor-Id of the extensions
should be defined like this:

junit-Extension-Name: junit
junit-Specification-Version: 3.8.1
junit-Implementation-Vendor-Id:
junit-Implementation-Version: 3.8.1
junit-Implementation-URL:
http://www.ibiblio.org/maven/junit/jars/junit-3.8.1.jar
commons-logging-Extension-Name: org.apache.commons.logging
commons-logging-Specification-Version: 1.0
commons-logging-Implementation-Vendor-Id:
commons-logging-Implementation-Version: 1.0.2
commons-logging-Implementation-URL:
http://www.ibiblio.org/maven/commons-logging/jars/commons-logging- 
1.0.2.
jar

In accordance with the above addition, MANIFEST of junit and
commons-logging also should be updated to comply with
commons-httpclient.
Manifest-Version: 1.0
Created-By: Ant 1.4.1
Extension-Name: junit
Specification-Version: 3.8.1
Implementation-Vendor-Id:
Implementation-Version: 3.8.1
Manifest-Version: 1.0
Created-By: Apache Ant 1.5.1beta1
Extension-Name: org.apache.commons.logging
Specification-Vendor: Apache Software Foundation
Specification-Version: 1.0
Implementation-Vendor: Apache Software Foundation
Implementation-Vendor-Id:
Implementation-Version: 1.0.2
Class-Path: log4j.jar log4j-core.jar
Otherwise, you can figure out this conflict by simply removing
Extension-List and its followings. The attached files are completely
updated MANIFESTs. Again, I'd like to remind you that this issue is now
only proved to be relevant with Tomcat and hence am not sure it can
cause a problem under other platforms. (I saw my colleague using
http-client 2.0 beta 1 on his dos prompt without trouble even though  
his
classpath didn't include junit.jar.)

Thanks for this great work, http-client 2.0,

Ias.

===
Lee, Changshin (Korean name)
Ias (International name)
   Company Web Site: http://www.tmax.co.kr
   Personal Web Site: http://www.iasandcb.pe.kr
-
-
To unsubscribe, e-mail:  
[EMAIL PROTECTED]
For additional commands, e-mail:

setUseCaches

[O Khalid]

hey guys,
 
I was wondering if anyone knows how to dis-able cache using the httpClient. I believe 
the HttpURLConnection class does not support setUseCaches method yet. Does anyone know 
of a certain HTTP Header that could be set in the request body to achieve this.
 
Thanks
 
Omar



-
Post your free ad now! Yahoo! Canada Personals

Re: Welcome Adrian

[Adrian Sutton]

Thanks to everyone for the support.  This is a wonderful team to work 
with and I look forward to continuing to create great software with you 
all.  The Apache elves (Brian Behlendorf in particular) have been busy 
over night and my account is already set up.  Once I get the 
contributor agreement faxed in I'll proudly add my name to the list of 
committers for the project then wait for all those wonderful new 
patches to come rolling in. :)

Regards,

Adrian Sutton.

On Tuesday, June 3, 2003, at 04:45  AM, Michael Becke wrote:

Please join me in welcoming Adrian Sutton as a committer for the 
HttpClient team.  His account should be setup in the very near future, 
so please send all new patches his way:)  Welcome Adrian.

Mike

-
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: [REPORT] 2.0 beta 1 and Tomcat 4

[Adrian Sutton]

Mike,
This sounds like a known issue I've seen with maven recently.  I 
believe it's fixed in the latest CVS version of maven, but it's 
probably easier and safer to just fix it by hand.

Adrian.

On Tuesday, June 3, 2003, at 02:42  AM, Michael Becke wrote:

Ias,

Thank you for submitting this one.  You are quite right, the 
MANIFEST.MF is not correct.  Not only does it have formatting 
problems, but junit should not be a runtime dependency.  This jar was 
generated with Maven so I am guessing the formatting problem is a 
Maven bug.  I'll remove the junit dependency and rebuild the 
distribution this evening.

Mike


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

Welcome Adrian

[Michael Becke]

Please join me in welcoming Adrian Sutton as a committer for the 
HttpClient team.  His account should be setup in the very near future, 
so please send all new patches his way:)  Welcome Adrian.

Mike

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

Re: Put method

[Michael Becke]

I'm guessing this is happening because the PUT's content length is not 
being set.  The request content length must be set to 
EntityEnclosingMethod.CONTENT_LENGTH_CHUNKED or to the actual size of 
the content to avoid buffering.  If the content length is not specified 
the content is buffered to memory in order to determing the length.

Mike

[EMAIL PROTECTED] wrote:
Hi,

I use PutMethod to upload files. Everything goes ok until
I try to send a big file (~ 150 Mo): I get an OutOfMemoryError.
I use a BufferedInputStream for my RequestBody.

Has anyone already had this kind of error ?

Thanks,

Cedric. 

Accédez au courrier électronique de La Poste : www.laposte.net ; 
3615 LAPOSTENET (0,34€/mn) ; tél : 08 92 68 13 50 (0,34€/mn)"



-
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: [VOTE] nominate Adrian Sutton for committer status

[Om Narayan]

+1

- Original Message -
From: "Michael Becke" <[EMAIL PROTECTED]>
To: "Commons Project" <[EMAIL PROTECTED]>
Sent: Sunday, June 01, 2003 7:29 PM
Subject: [VOTE] nominate Adrian Sutton for committer status


> Adrian Sutton has been an active contributor to HttpClient for some
> time now.  He has been a consistent and reliable contributor, and in
> particular his work with NTLM and the developer documentation has been
> invaluable.
>
> I would like to nominate Adrian Sutton for HttpClient committer status.
>
> Please vote as follows:
> +1 = Yes
> 0 = abstain
> -1 = no
>
> Mike
>
>
> -
> 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: [REPORT] 2.0 beta 1 and Tomcat 4

[Michael Becke]

Ias,

Thank you for submitting this one.  You are quite right, the MANIFEST.MF 
is not correct.  Not only does it have formatting problems, but junit 
should not be a runtime dependency.  This jar was generated with Maven 
so I am guessing the formatting problem is a Maven bug.  I'll remove the 
junit dependency and rebuild the distribution this evening.

Mike

Ias wrote:
The current 2.0 beta 1 distribution doesn't work with Tomcat 4.x. The
error message is
Catalina.start: LifecycleException:  Missing optional package
Extension[junit,
implementationURL=http://www.ibiblio.org/maven/junit/jars/junit-3.8.1.ja
r, implementationVersion=3.8.1]
LifecycleException:  Missing optional package Extension[junit,
implementationURL=http://www.ibiblio.org/maven/junit/jars/junit-3.8.1.ja
r, implementationVersion=3.8.1]
at
org.apache.catalina.loader.WebappLoader.validatePackages(WebappLoader.ja
va:1244)
at
org.apache.catalina.loader.WebappLoader.start(WebappLoader.java:645)
at
org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1100)
at
org.apache.catalina.core.StandardContext.start(StandardContext.java:3345
)
at
org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1123)
at
org.apache.catalina.core.StandardHost.start(StandardHost.java:614)
at
org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1123)
at
org.apache.catalina.core.StandardEngine.start(StandardEngine.java:343)
at
org.apache.catalina.core.StandardService.start(StandardService.java:388)
at
org.apache.catalina.core.StandardServer.start(StandardServer.java:506)
at org.apache.catalina.startup.Catalina.start(Catalina.java:781)
at
org.apache.catalina.startup.Catalina.execute(Catalina.java:681)
at
org.apache.catalina.startup.Catalina.process(Catalina.java:179)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
a:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
Impl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at
org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:243)
I looked into the stack trace and found that there needed to be some
modification toward the associated
jars-commons-httpclient-2.0-beta1.jar, junit-3.8.1.jar, and
commons-logging-1.0.jar.
First, Tomcat's org.apache.catalina.loader.Extension.getRequired
distinguishes required libraries by delimiter not "," but " ".
Therefore, 

Extension-List: junit,commons-logging

should be

Extension-List: junit commons-logging

in MANIFEST.MF of httpclient jar.
(http://java.sun.com/j2se/1.4.1/docs/guide/extensions/versioning.html
proves the usage.)
Next, since Tomcat's resolving algorithm for required libraries is quite
strict as implemented in o.a.c.l.WebappLoader.validatePackages(),
Specification-Version and Implementation-Vendor-Id of the extensions
should be defined like this:
junit-Extension-Name: junit
junit-Specification-Version: 3.8.1
junit-Implementation-Vendor-Id: 
junit-Implementation-Version: 3.8.1
junit-Implementation-URL:
http://www.ibiblio.org/maven/junit/jars/junit-3.8.1.jar
commons-logging-Extension-Name: org.apache.commons.logging
commons-logging-Specification-Version: 1.0
commons-logging-Implementation-Vendor-Id: 
commons-logging-Implementation-Version: 1.0.2
commons-logging-Implementation-URL:
http://www.ibiblio.org/maven/commons-logging/jars/commons-logging-1.0.2.
jar

In accordance with the above addition, MANIFEST of junit and
commons-logging also should be updated to comply with
commons-httpclient.
Manifest-Version: 1.0
Created-By: Ant 1.4.1
Extension-Name: junit
Specification-Version: 3.8.1
Implementation-Vendor-Id: 
Implementation-Version: 3.8.1

Manifest-Version: 1.0
Created-By: Apache Ant 1.5.1beta1
Extension-Name: org.apache.commons.logging
Specification-Vendor: Apache Software Foundation
Specification-Version: 1.0
Implementation-Vendor: Apache Software Foundation
Implementation-Vendor-Id: 
Implementation-Version: 1.0.2
Class-Path: log4j.jar log4j-core.jar

Otherwise, you can figure out this conflict by simply removing
Extension-List and its followings. The attached files are completely
updated MANIFESTs. Again, I'd like to remind you that this issue is now
only proved to be relevant with Tomcat and hence am not sure it can
cause a problem under other platforms. (I saw my colleague using
http-client 2.0 beta 1 on his dos prompt without trouble even though his
classpath didn't include junit.jar.)
Thanks for this great work, http-client 2.0,

Ias.

===
Lee, Changshin (Korean name)
Ias (International name)
   Company Web Site: http://www.tmax.co.kr
   Personal Web Site: http://www.iasandcb.pe.kr
-


---

Put method

[[EMAIL PROTECTED]]

Hi,

I use PutMethod to upload files. Everything goes ok until
I try to send a big file (~ 150 Mo): I get an OutOfMemoryError.

I use a BufferedInputStream for my RequestBody.

Has anyone already had this kind of error ?

Thanks,

Cedric. 


Accédez au courrier électronique de La Poste : www.laposte.net ; 
3615 LAPOSTENET (0,34€/mn) ; tél : 08 92 68 13 50 (0,34€/mn)"




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

RE: [REPORT] 2.0 beta 1 and Tomcat 4

[Kalnichevski, Oleg]

Ias,

Thanks for such a detailed description of the problem. We'll look into it and fix 
those things that can be fixed on the HttpClient side

Cheers

Oleg

-Original Message-
From: Ias [mailto:[EMAIL PROTECTED]
Sent: Monday, June 02, 2003 16:54
To: [EMAIL PROTECTED]
Subject: [REPORT] 2.0 beta 1 and Tomcat 4


The current 2.0 beta 1 distribution doesn't work with Tomcat 4.x. The
error message is
Catalina.start: LifecycleException:  Missing optional package
Extension[junit,
implementationURL=http://www.ibiblio.org/maven/junit/jars/junit-3.8.1.ja
r, implementationVersion=3.8.1]
LifecycleException:  Missing optional package Extension[junit,
implementationURL=http://www.ibiblio.org/maven/junit/jars/junit-3.8.1.ja
r, implementationVersion=3.8.1]
at
org.apache.catalina.loader.WebappLoader.validatePackages(WebappLoader.ja
va:1244)
at
org.apache.catalina.loader.WebappLoader.start(WebappLoader.java:645)
at
org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1100)
at
org.apache.catalina.core.StandardContext.start(StandardContext.java:3345
)
at
org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1123)
at
org.apache.catalina.core.StandardHost.start(StandardHost.java:614)
at
org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1123)
at
org.apache.catalina.core.StandardEngine.start(StandardEngine.java:343)
at
org.apache.catalina.core.StandardService.start(StandardService.java:388)
at
org.apache.catalina.core.StandardServer.start(StandardServer.java:506)
at org.apache.catalina.startup.Catalina.start(Catalina.java:781)
at
org.apache.catalina.startup.Catalina.execute(Catalina.java:681)
at
org.apache.catalina.startup.Catalina.process(Catalina.java:179)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
a:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
Impl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at
org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:243)

I looked into the stack trace and found that there needed to be some
modification toward the associated
jars-commons-httpclient-2.0-beta1.jar, junit-3.8.1.jar, and
commons-logging-1.0.jar.

First, Tomcat's org.apache.catalina.loader.Extension.getRequired
distinguishes required libraries by delimiter not "," but " ".
Therefore, 

Extension-List: junit,commons-logging

should be

Extension-List: junit commons-logging

in MANIFEST.MF of httpclient jar.
(http://java.sun.com/j2se/1.4.1/docs/guide/extensions/versioning.html
proves the usage.)

Next, since Tomcat's resolving algorithm for required libraries is quite
strict as implemented in o.a.c.l.WebappLoader.validatePackages(),
Specification-Version and Implementation-Vendor-Id of the extensions
should be defined like this:

junit-Extension-Name: junit
junit-Specification-Version: 3.8.1
junit-Implementation-Vendor-Id: 
junit-Implementation-Version: 3.8.1
junit-Implementation-URL:
http://www.ibiblio.org/maven/junit/jars/junit-3.8.1.jar
commons-logging-Extension-Name: org.apache.commons.logging
commons-logging-Specification-Version: 1.0
commons-logging-Implementation-Vendor-Id: 
commons-logging-Implementation-Version: 1.0.2
commons-logging-Implementation-URL:
http://www.ibiblio.org/maven/commons-logging/jars/commons-logging-1.0.2.
jar

In accordance with the above addition, MANIFEST of junit and
commons-logging also should be updated to comply with
commons-httpclient.

Manifest-Version: 1.0
Created-By: Ant 1.4.1
Extension-Name: junit
Specification-Version: 3.8.1
Implementation-Vendor-Id: 
Implementation-Version: 3.8.1

Manifest-Version: 1.0
Created-By: Apache Ant 1.5.1beta1
Extension-Name: org.apache.commons.logging
Specification-Vendor: Apache Software Foundation
Specification-Version: 1.0
Implementation-Vendor: Apache Software Foundation
Implementation-Vendor-Id: 
Implementation-Version: 1.0.2
Class-Path: log4j.jar log4j-core.jar

Otherwise, you can figure out this conflict by simply removing
Extension-List and its followings. The attached files are completely
updated MANIFESTs. Again, I'd like to remind you that this issue is now
only proved to be relevant with Tomcat and hence am not sure it can
cause a problem under other platforms. (I saw my colleague using
http-client 2.0 beta 1 on his dos prompt without trouble even though his
classpath didn't include junit.jar.)

Thanks for this great work, http-client 2.0,

Ias.

===
Lee, Changshin (Korean name)
Ias (International name)
   Company Web Site: http://www.tmax.co.kr
   Personal Web Site: http://www.iasandcb.pe.kr
-


-
To unsubscribe, e-mail: [

Re: [VOTE] nominate Adrian Sutton for committer status

[Your Name]

Resounding +1

> Adrian Sutton has been an active contributor to HttpClient for some 
> time now.  He has been a consistent and reliable contributor, and in 
> particular his work with NTLM and the developer documentation has 
been 
> invaluable.
> 
> I would like to nominate Adrian Sutton for HttpClient committer 
status.
> 
> Please vote as follows:
> +1 = Yes
> 0 = abstain
> -1 = no
> 
> Mike
> 
> 
> -
> To unsubscribe, e-mail: commons-httpclient-dev-
[EMAIL PROTECTED]
> For additional commands, e-mail: commons-httpclient-dev-
[EMAIL PROTECTED]
> 
> 
> 

-- 


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

Re: [VOTE] nominate Adrian Sutton for committer status

[dion]

+1
--
dIon Gillard, Multitask Consulting
Blog:  http://www.freeroller.net/page/dion/Weblog
Work:  http://www.multitask.com.au


Ortwin Glück <[EMAIL PROTECTED]> wrote on 02/06/2003 05:05:44 PM:

> +1
> 
> Adrian's work is excellent.
> 
> Michael Becke wrote:
> 
> > Adrian Sutton has been an active contributor to HttpClient for some 
time 
> > now.  He has been a consistent and reliable contributor, and in 
> > particular his work with NTLM and the developer documentation has been 

> > invaluable.
> > 
> > I would like to nominate Adrian Sutton for HttpClient committer 
status.
> > 
> > Please vote as follows:
> > +1 = Yes
> > 0 = abstain
> > -1 = no
> > 
> > Mike
> > 
> > 
> > -
> > To unsubscribe, e-mail: 
> > [EMAIL PROTECTED]
> > For additional commands, e-mail: 
> > [EMAIL PROTECTED]
> 
> -- 
> _
>   NOSE applied intelligence ag
> [www]  http://www.nose.ch
>   ortwin glück  [email] [EMAIL PROTECTED]
>   hardturmstrasse 171   [pgp key]  0x81CF3416
>   8005 zurich   [office]  +41-1-277 57 35
>   switzerland   [fax] +41-1-277 57 12
> 
> 
> -
> 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]

DO NOT REPLY [Bug 10809] - Developer documentation

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10809

Developer documentation





--- Additional Comments From [EMAIL PROTECTED]  2003-06-02 15:00 ---
Created an attachment (id=6599)
Cookies guide minor corrections

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

[REPORT] 2.0 beta 1 and Tomcat 4

[Ias]

The current 2.0 beta 1 distribution doesn't work with Tomcat 4.x. The
error message is
Catalina.start: LifecycleException:  Missing optional package
Extension[junit,
implementationURL=http://www.ibiblio.org/maven/junit/jars/junit-3.8.1.ja
r, implementationVersion=3.8.1]
LifecycleException:  Missing optional package Extension[junit,
implementationURL=http://www.ibiblio.org/maven/junit/jars/junit-3.8.1.ja
r, implementationVersion=3.8.1]
at
org.apache.catalina.loader.WebappLoader.validatePackages(WebappLoader.ja
va:1244)
at
org.apache.catalina.loader.WebappLoader.start(WebappLoader.java:645)
at
org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1100)
at
org.apache.catalina.core.StandardContext.start(StandardContext.java:3345
)
at
org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1123)
at
org.apache.catalina.core.StandardHost.start(StandardHost.java:614)
at
org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1123)
at
org.apache.catalina.core.StandardEngine.start(StandardEngine.java:343)
at
org.apache.catalina.core.StandardService.start(StandardService.java:388)
at
org.apache.catalina.core.StandardServer.start(StandardServer.java:506)
at org.apache.catalina.startup.Catalina.start(Catalina.java:781)
at
org.apache.catalina.startup.Catalina.execute(Catalina.java:681)
at
org.apache.catalina.startup.Catalina.process(Catalina.java:179)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
a:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
Impl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at
org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:243)

I looked into the stack trace and found that there needed to be some
modification toward the associated
jars-commons-httpclient-2.0-beta1.jar, junit-3.8.1.jar, and
commons-logging-1.0.jar.

First, Tomcat's org.apache.catalina.loader.Extension.getRequired
distinguishes required libraries by delimiter not "," but " ".
Therefore, 

Extension-List: junit,commons-logging

should be

Extension-List: junit commons-logging

in MANIFEST.MF of httpclient jar.
(http://java.sun.com/j2se/1.4.1/docs/guide/extensions/versioning.html
proves the usage.)

Next, since Tomcat's resolving algorithm for required libraries is quite
strict as implemented in o.a.c.l.WebappLoader.validatePackages(),
Specification-Version and Implementation-Vendor-Id of the extensions
should be defined like this:

junit-Extension-Name: junit
junit-Specification-Version: 3.8.1
junit-Implementation-Vendor-Id: 
junit-Implementation-Version: 3.8.1
junit-Implementation-URL:
http://www.ibiblio.org/maven/junit/jars/junit-3.8.1.jar
commons-logging-Extension-Name: org.apache.commons.logging
commons-logging-Specification-Version: 1.0
commons-logging-Implementation-Vendor-Id: 
commons-logging-Implementation-Version: 1.0.2
commons-logging-Implementation-URL:
http://www.ibiblio.org/maven/commons-logging/jars/commons-logging-1.0.2.
jar

In accordance with the above addition, MANIFEST of junit and
commons-logging also should be updated to comply with
commons-httpclient.

Manifest-Version: 1.0
Created-By: Ant 1.4.1
Extension-Name: junit
Specification-Version: 3.8.1
Implementation-Vendor-Id: 
Implementation-Version: 3.8.1

Manifest-Version: 1.0
Created-By: Apache Ant 1.5.1beta1
Extension-Name: org.apache.commons.logging
Specification-Vendor: Apache Software Foundation
Specification-Version: 1.0
Implementation-Vendor: Apache Software Foundation
Implementation-Vendor-Id: 
Implementation-Version: 1.0.2
Class-Path: log4j.jar log4j-core.jar

Otherwise, you can figure out this conflict by simply removing
Extension-List and its followings. The attached files are completely
updated MANIFESTs. Again, I'd like to remind you that this issue is now
only proved to be relevant with Tomcat and hence am not sure it can
cause a problem under other platforms. (I saw my colleague using
http-client 2.0 beta 1 on his dos prompt without trouble even though his
classpath didn't include junit.jar.)

Thanks for this great work, http-client 2.0,

Ias.

===
Lee, Changshin (Korean name)
Ias (International name)
   Company Web Site: http://www.tmax.co.kr
   Personal Web Site: http://www.iasandcb.pe.kr
-

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