Hello,
When I tried to use HttpClient to query a web site with a UTF-8 paramter,
it just can't match.
When I tried to Copy Paste the character into that web site, it works,
but failed to use HttpClient.
Is there any problem in HttpClient to handle UTF-8 parameters ???
Web Side:
Re: [configuration] Change Commons-Configuration getVector to getSet?Out of
curiosity, what would be a usecase for multiple duplicate config entries
that are the same? Maybe to count them or something? So, does anyone have
an opinion on List? I definitly can understand why the Set wouldn't
Eric Chow wrote:
import org.apache.commons.httpclient.*;
import org.apache.commons.httpclient.methods.*;
import org.apache.commons.httpclient.cookie.*;
import org.apache.commons.httpclient.util.*;
import java.io.*;
Hi Odi,
It works now, thanks a lot.
Best regards,
Eric
- Original Message -
From: Ortwin Glück [EMAIL PROTECTED]
To: Jakarta Commons Developers List [EMAIL PROTECTED]
Sent: Thursday, September 18, 2003 4:14 PM
Subject: Re: HttpClient UTF-8 problem !!!
Eric Chow wrote:
Is it desirable to have services defined in a single module and the
extensions to those services defined in a separate module?
Is there a difference between the following hivemodule xml?
?xml version=1.0?
module id=hivemind.examples version=1.0.0
service id=Adder
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23240.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23240.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Could someone please make the above directory on minotaur group writable?
I'm trying to deploy the site for commons jelly and am unable to.
Thanks,
--
dIon Gillard, Multitask Consulting
Blog: http://blogs.codehaus.org/people/dion/
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23241.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
No, that separation is desirable in a small number of cases. Your examples will be
identical at
runtime.
The typical usage is to define the service interface, implementation and interceptors
in a single
location.
Here's a common scenario; you define a DAO (data access object) service in module
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23242.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23242.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Harish's suggestion:
service id= -- service-point id=
extend-service service-id= -- service service-id=
extension-point id= -- configuration-point id=
extension point-id= -- configuration point-id=
Everyone seems pretty keen on this.
I have minor reservations about service not quite capturing
When you say 'single location' is that in a single jar?
Cause won't packaging the service together with the implementation prevent
people from choosing a different implementation at deploy time? And to
only allow them to add interceptors? Or have I mis-understood something?
Johan
On Thu, 18
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23246.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
On Thu, 18 Sep 2003 07:38:41 -0400, Howard M. Lewis Ship
[EMAIL PROTECTED] wrote:
Harish's suggestion:
service id= -- service-point id=
extend-service service-id= -- service service-id=
extension-point id= -- configuration-point id=
extension point-id= -- configuration point-id=
Last point was
Absolutely with Christian. For some reason I am not very comfortable
with verbs in the element names!
-Harish
Christian Essl wrote:
On Thu, 18 Sep 2003 07:38:41 -0400, Howard M. Lewis Ship
[EMAIL PROTECTED] wrote:
Harish's suggestion:
service id= -- service-point id=
extend-service
Hello,
When I am trying to process the following Jelly script I've got the error:
[java] org.apache.commons.jelly.JellyTagException:
file:/C:/Work/SDS/templates/sample1.xhtml:31:105: x:transform The node [EMAIL
PROTECTED] [Element: h1 attributes: []/] could not be added to the branch null
And may be even change
extend-service service-id= -- service for-point-id=
I think the same pattern will be helpful learning it easier and
remembering it better.
-Harish
Harish Krishnaswamy wrote:
Absolutely with Christian. For some reason I am not very comfortable
with verbs in the element
How about extension service-id= ?
- Original Message -
From: Harish Krishnaswamy [EMAIL PROTECTED]
To: Jakarta Commons Developers List [EMAIL PROTECTED]
Sent: Thursday, September 18, 2003 9:35 AM
Subject: Re: [HiveMind] naming update
And may be even change
extend-service
oglueck 2003/09/18 06:56:22
Modified:httpclient API_CHANGES_2_1.txt release_notes.txt
httpclient/src/java/org/apache/commons/httpclient/auth
DigestScheme.java
httpclient/src/test/org/apache/commons/httpclient
I think a consistency rule should be in place. When you are referring to
the id attribute value of another element, you should use the attribute
name element-name-id=yaddayadda. As in...
implementation service-id=yaddayadda
This is somewhat similar to the naming convention people use in
Option D:
service-point id=...
service-definition point-id=...
configuration-point id=...
configuration-definition point-id=...// not very sure
about this
though.
That seems off to me; service-definition is close, I think, but not quite accurate
(that's why I
like implementation,
I agree, I wasn't very inclined towards that either, just wanted to see
what others thought. But implementation is not very intuitive at least
in the following case, I think...
implementation ...
interceptor .../
/implementation
Contribution seems appropriate. So how about
On Thursday, September 18, 2003 at 11:00:29 (-0400) Howard M. Lewis Ship writes:
Current consensus:
service id= -- service-point id=
extend-service service-id= -- service for-service-id=
extension-point id= -- configuration-point id=
extension point-id= -- configuration for-point-id=
... but
Contribution seems appropriate. So how about
service-contribution and
configuration-contribution?
And, we loop full circle back to how I had it before I decided to line up with
Eclipse's naming
(what a mistaken idea).
I don't mind service-contribution, because its a very rare case.
service service-id=org.puppies.math.Adder
implementation service-id=org.puppies.math.Adder
configuration-schema service-id=org.puppies.math.Adder
configuration service-id=org.puppies.math.Adder
Did you mean point-id or config-id or something (besides service-id) in the last
two?
--
On Thursday, September 18, 2003 at 12:03:20 (-0400) Howard M. Lewis Ship writes:
service service-id=org.puppies.math.Adder
implementation service-id=org.puppies.math.Adder
configuration-schema service-id=org.puppies.math.Adder
configuration service-id=org.puppies.math.Adder
Did you mean
How about this...
service id=...
contribution service-id=...
configuration id=...
contribution configuration-id=...
How do you like this?
-Harish
Howard M. Lewis Ship wrote:
Contribution seems appropriate. So how about
service-contribution and
configuration-contribution?
And, we loop
As currently implemented, services and configurations are distinct. They are in
separate
namespaces. You can have a service and a configuration in the same module. If they
are related, it
would only be because code (or BuilderFactory) connected them.
Configurations have a schema element to
On Thursday, September 18, 2003 at 12:07:14 (-0400) Harish Krishnaswamy writes:
How about this...
service id=...
contribution service-id=...
configuration id=...
contribution configuration-id=...
How do you like this?
I still prefer consistent id naming conventions:
service service-id=...
I like it ... but I still really like the implementation idea.
It makes the XML parsing somewhat easier if the two types of contributions are
distinct (they're
content is completely different and I will have to differentiate by the presense of an
attribute).
With or without implementation,
Because implementation is not intuitive in the following, I think,
implementation..
interceptor.../
/implementation
And I don't think there is any implementation for a configuration, right?
-Harish
Bill Lear wrote:
On Thursday, September 18, 2003 at 12:07:14 (-0400) Harish Krishnaswamy
I figured the digester will have to be more intelligent.
I still don't like implementation for the reason I mentioned. If the
majority likes it, I will live with it.
-Harish
Howard M. Lewis Ship wrote:
I like it ... but I still really like the implementation idea.
It makes the XML parsing
On Thursday, September 18, 2003 at 12:17:26 (-0400) Harish Krishnaswamy writes:
Because implementation is not intuitive in the following, I think,
implementation..
interceptor.../
/implementation
Hmm, is it really?:
implementation service-id=Adder interface=hivemind.examples.Adder
The point I am trying to make is you could already have a service
implementation provided by some third party in a module and all you
could be doing is adding an interceptor to it. In that case
implementation doesn't sound appropriate, its more a contribution, I
think. What you say?!
-Harish
On Thursday, September 18, 2003 at 12:32:23 (-0400) Harish Krishnaswamy writes:
The point I am trying to make is you could already have a service
implementation provided by some third party in a module and all you
could be doing is adding an interceptor to it. In that case
implementation
The point I am trying to make is you could already have a service
implementation provided by some third party in a module and all you
could be doing is adding an interceptor to it. In that case
implementation doesn't sound appropriate, its more a contribution, I
think. What you say?!
To me implementation implies core implementation that's probably where
the disconnect is. What does it instantly mean to others?
-Harish
Howard M. Lewis Ship wrote:
The point I am trying to make is you could already have a service
implementation provided by some third party in a module and
WebDAV properties use a namespace and localname. Currently the FileContent
interface only supports a String as a name for attributes. Perhaps the
attribute handling should be revisited to support a namespace as well.
-Steve
If there are no complaints, I'd like to deprecate CursorableLinkedList for
the 3.0 collections release, to be removed in the 4.0 release.
CursorableLinkedList provides a List implementation that supports a type
of Iterator (called a Cursor) that isn't bothered by concurrent
modifications--you can
If I append something asynchronously to the end of the list while a Cursor
is open, will the cursor pick that up? Or, does a cursor merely take a
snap-shot of the underlying list and iterate over whatever is there
currently? Just curious.
- Original Message -
From: Rodney Waldhoff
Nevermind, RTFM. Sorry, folks.
- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, September 18, 2003 1:07 PM
Subject: Re: [collections] deprecate CursorableLinkedList?
If I append something asynchronously to the end of the list while a Cursor
is open,
On Thu, 18 Sep 2003 [EMAIL PROTECTED] wrote:
If I append something asynchronously to the end of the list while a Cursor
is open, will the cursor pick that up?
Yes.
Or, does a cursor merely take a
snap-shot of the underlying list and iterate over whatever is there
currently?
No. Not a
hlship 2003/09/18 12:01:01
Modified:hivemind/xdocs index.xml descriptor.xml navigation.xml
bootstrap.xml interceptors.xml case1.xml
multithreading.xml services.xml localization.xml
override.xml ioc.xml rules.xml
tor 2003-09-18 klockan 16.07 skrev Remy Maucherat:
Daniel Resare wrote:
Why is there no reload() method of the Daemon interface? It seems like
sending SIGHUP to jsvc translates to calls to stop() and start(), but
that is semantically different from how most programs other programs
handle
Ok,
I just checked in a big ass number of changes for this, along with the usual cleanups.
It's now:
service-point id=...
implementation service-id=...
configuration-point id=...
contribution configuration-id=...
Let's see how well that sits ... I'm hoping that simply nails it because it's a
tor 2003-09-18 klockan 16.23 skrev Shapira, Yoav:
Why is there no reload() method of the Daemon interface? It seems like
sending SIGHUP to jsvc translates to calls to stop() and start(), but
that is semantically different from how most programs other programs
handle SIGHUP.
Daemon was
So you stuck with implementation :'( .
Howard M. Lewis Ship wrote:
Ok,
I just checked in a big ass number of changes for this, along with the usual cleanups.
It's now:
service-point id=...
implementation service-id=...
configuration-point id=...
contribution configuration-id=...
Let's see
I really thought that dual use of contribution was going to cause headaches,
including writing
documentation, and generating the registry documentation.
--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/tapestry
Nah..., I was just looking at the site documentation and it looks very
nice to me. Let's see what others think.
Side note: what do you use to create the logos, looks cool!
-Harish
Howard M. Lewis Ship wrote:
I really thought that dual use of contribution was going to cause headaches,
Just Paint Shop Pro and a couple of free fonts. You're seeing the upper limitations
on my graphical
skills.
--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/tapestry
http://jakarta.apache.org/commons/sandbox/hivemind/
http://javatapestry.blogspot.com
hlship 2003/09/18 13:08:59
Modified:hivemind/xdocs bootstrap.xml
hivemind/framework/src/java/org/apache/commons/hivemind
HiveMind.java
hivemind/framework/src/java/org/apache/commons/hivemind/impl
Henri Yandell wrote:
There's no PROPOSAL.html or STATUS.html in there, so it's not got the
necessary requirements for a promotion to Commons proper to be considered.
There's lots of stuff which is, ahem, fragile, in particular
the XML output stuff.
Well, it seems current XML supportis more for
On Thu, 18 Sep 2003, Rodney Waldhoff wrote:
Date: Thu, 18 Sep 2003 10:03:54 -0700 (PDT)
From: Rodney Waldhoff [EMAIL PROTECTED]
Reply-To: Jakarta Commons Developers List [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [collections] deprecate CursorableLinkedList?
If there are no
On Fri, 2003-09-19 at 05:03, Rodney Waldhoff wrote:
If there are no complaints, I'd like to deprecate CursorableLinkedList for
the 3.0 collections release, to be removed in the 4.0 release.
Bugger. I was just intending to propose using this class from within
commons-digester.
It would be no
Since both Craig and you have expressed an interest in keeping this class
around, I'm more than happy to leave it.
Let's remove implements Serializable for the 3.0 release, unless someone
feels like making it work (probably a missing a transient somewhere).
On Thu, 19 Sep 2003, Simon Kitching
Bugger. I was just intending to propose using this class from within
commons-digester.
So just say so. That sounds like two -1's from people who want to use it.
--- Noel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
On Fri, 2003-09-19 at 09:38, Rodney Waldhoff wrote:
Since both Craig and you have expressed an interest in keeping this class
around, I'm more than happy to leave it.
Let's remove implements Serializable for the 3.0 release, unless someone
feels like making it work (probably a missing a
Sorry this is a long email, but it might be interesting enough to
read...I dunno...
speech
I've just had a minor breakthrough on a xml parsing framework that I'm
completing, and I feel like I owe it to the Jelly folks to share.
I've taken a page or six from both JSP and Jelly taglibs in writing
Thank you!
--
dIon Gillard, Multitask Consulting
Blog: http://blogs.codehaus.org/people/dion/
Manoj Kasichainula [EMAIL PROTECTED] wrote on 19/09/2003 07:22:52 AM:
On Thu, Sep 18, 2003 at 09:13:53PM +1000, [EMAIL PROTECTED] wrote:
Could someone please make the above directory on
On Thu, Sep 18, 2003 at 09:13:53PM +1000, [EMAIL PROTECTED] wrote:
Could someone please make the above directory on minotaur group writable?
I'm trying to deploy the site for commons jelly and am unable to.
Fixed that and found other dirs at that level that needed g+w, so I did:
chmod g+w
complementGood Ideas/complement
I had some thoughts a while back where I wanted to be able to define
schemas for my taglibraries, to provide some validation features to my
taglibrary structure for things like tag completion, etc. in XML editors.
If my jelly script could have proper namespaces,
Interceptors, as I know of them in HiveMind right now, can only be
applied across the board to all methods in the service; there is no
selectivity. But, I think, selective intercepting will be a requirement
for other kinds of interceptors (like a security interceptor or a
transactional
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23246.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
I've redeployed the jelly site, so that previously bad documentation is
now replaced by other bad documentation :-)
See it on
http://jakarta.apache.org/commons/jelly/index.html
--
dIon Gillard, Multitask Consulting
Blog: http://blogs.codehaus.org/people/dion/
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23242.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23241.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23241.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Hello Mohsin,
Status code 100 is the server's way to tell a client go on, or
don't give up yet. If the log you provided is complete, I'd guess
it's the first case. The client sends a content length of 2966,
but only one and a half lines of content are actually sent. The
server is probably waiting
Oleg Kalnichevski wrote:
Oh. well, I knew it. This is a very strange quirk on the part of Jetty,
which once was reported as a bug, but Jetty folks were not too
enthusiastic to fix.
I think we should add a test case that emulates Jetty's behaviour in
order to ensure we do not lose compatibility
Oleg Kalnichevski wrote:
Odi, the patch looks fine to me. I just dislike this part:
try {
cnonce = createCnonce();
} catch(AuthenticationException e) {
throw new RuntimeException(e.toString());
}
At the very least I would rethrow the
Odi,
I think it is OK to throw an unchecked exception from createCnonce. I just dislike the
idea of throwing plain vanilla RuntimeException. Would it be OK with you to sub-class
RuntimeException and give it a reasonably self-explanatory name
(MD5NotSupportedYouDummyRuntinmeException)?
Kalnichevski, Oleg wrote:
Odi,
I think it is OK to throw an unchecked exception from createCnonce. I just dislike the idea of throwing plain vanilla RuntimeException. Would it be OK with you to sub-class RuntimeException and give it a reasonably self-explanatory name
Sure. What about a general HttpClientError extends java.lang.Error? I
think we are missing such a thing. It would be nice to have a
NestableError but I think many people here would complain about a
dependency on Commons Lang...
HttpClientError is fine with me.
Oleg
75 matches
Mail list logo
