Re: [GUMP@brutus]: Project cocoon-block-proxy (in module cocoon) failed

[Stefano Mazzocchi]

Antonio Gallardo wrote:

Stefano Mazzocchi dijo:

Antonio Gallardo wrote:

Stefano Mazzocchi dijo:

Gump wrote:

cocoon-block-proxy-compile:
  [javac] Compiling 4 source files to
/home/gump/workspaces2/public/workspace/cocoon/build/cocoon-02112004/blocks/proxy/dest
  [javac]
/home/gump/workspaces2/public/workspace/cocoon/src/blocks/proxy/java/org/apache/cocoon/generation/HttpProxyGenerator.java:294:
cannot resolve symbol
  [javac] symbol  : method getRequestBodyAsString ()
  [javac] location: class
org.apache.commons.httpclient.methods.PostMethod
  [javac]             String body = ((PostMethod)
this.method).getRequestBodyAsString();
  [javac]                           ^
  [javac] 1 error

I don't know how to fix this one from the gump side, it needs some code
changes since httpclient change a lot since this code was created.

Any ideas?

I saw the code of httpclient 2.0.x and 3.0 and it is quite diferent.
They
are changing a lot in the new 3.0.x release. If we want gump compile
this
block, we need to add a dependency to our own distributed jar version
2.0.2.

I know this is a hack. The other way is to see more in depth and find a
way to compile code using both httpclient 2.0.2 and 3.0 too.

WDYT?

That build is against the 2.0.x branch.

Its posible in the CVS version.

In the javadocs for release 2.0.2, the PostMethod. Because is direct
derived from EntityEnclosingMethod:

http://jakarta.apache.org/commons/httpclient/apidocs/org/apache/commons/httpclient/methods/PostMethod.html

Now go to the CVS..... in the HTTPCLIENT_2_0_BRANCH We still see the
method getRequestBodyAsString() inside:

http://cvs.apache.org/viewcvs.cgi/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/methods/EntityEnclosingMethod.java?rev=1.18.2.5&only_with_tag=HTTPCLIENT_2_0_BRANCH&view=markup

...

I am not a CVS guru, but in the HEAD (3.0 release) there is not the method.

Seems like they broke a contract? I mean removing a method without
deprecate it first?

yeah, they did, but what I don't understand is why we didn't build against HTTPCLIENT_2_0_BRANCH.

puzzled.

--
Stefano.

smime.p7s

Description: S/MIME Cryptographic Signature