Don't know if somebody else has suggested this before, but wouldn't it
be quite easy to implement this default configuration feature in a
generic way as a decorator?
Oliver
Emmanuel Bourg schrieb:
Does this change address the complexity of the default configuration use
case with a composite
Um.. Yeah.. I guess so.. Although an arguement can be made that most
behaviors can be done as Decorators.. For that matter,
CompositeConfiguration is basicaly just a big fat decorator.
I do think that at somepoint we are going to have many classes in
Following a private email with Eric.
There is an underlying problem in configuration regarding the handling of
comma delimited properties.
As of now, a comma delimited string is considered a list of values, so
something like:
java.naming.provider.url=ldap://server:390/ou=something,o=else,c=here
I agree, i noticed this issue last month and suggested a patch :
http://www.mail-archive.com/[EMAIL PROTECTED]/msg33704.html
Basically it adds a setSplitString(boolean) method in the
AbstractConfiguration class that enable or disable property splitting.
Emmanuel Bourg
Stephane Bailliez wrote:
Is that going to be generic enough... I guess one of my concerns is that as
we have more providers, like DatabaseConfiguration, that the changes we make
stay generic...
I guess, in this case, that the DatabaseConfiguration returns a string, and
then that gets converted to a list/array by
Yes, maybe a year too late, but better late than never.
The whole groupID/ArtifactId thing just really came into existence. I'm
not really convinced its stable yet... We are just now getting a
hierarchical globalized site build together. Eventually, it would be
nice to see these all in one
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=27231.
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=27232.
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=27232.
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=27232.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Hi,
First of all let me apologize for the delayed response.
Unforeseen circumstances have kept me away from anything
electronic for days now.
Since the original post there has been some extensive feedback for
which I'm greatful and wish I could have responded to in a timely
fashion. I
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=26954.
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=27231.
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=27231.
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=27231.
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=27231.
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=27231.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Hi,
Let's take the simplest topic first which is the Exception issue.
From: Tim O'Brien [mailto:[EMAIL PROTECTED]
I think the introduction of EncoderException and DecoderException in and
of itself was a mistake in the first place. Creating hierarchies of
exception just for the hell of
Brett,
In general, I have long preferred the pipeline/event model to the approach
that Alex had, where it would give data to the codec, and then poll it for
state. However, I don't see something in your implementation that I think
we want. We want to be able to have structured content handlers
In the documentation for MultiHashMap, it claims Getting a value will
always return a Collection, holding all the values put to that key.
However, the following code fails...
final MultiHashMap map = new MultiHashMap();
assertNotNull( map.get( Hello ) );
From the documentation, I would
From: Tim O'Brien [mailto:[EMAIL PROTECTED]
Alex Karasulu wrote:
Hi,
I've been working on the idea of stateful Decoders designed for use with
non-blocking reads where buffers are read from channels and used by
decoders. As you know you don't always get the complete PDU in a single
scolebourne2004/02/25 11:11:19
Added: daemon NOTICE.txt
Log:
Change to Apache License 2.0
Revision ChangesPath
1.1 jakarta-commons/daemon/NOTICE.txt
Index: NOTICE.txt
===
This
Yes, this will need a javadoc fix. The null is returned to indicate that
there are no values mapped to this key (as per normal Map API).
Stephen
- Original Message -
From: James Carman [EMAIL PROTECTED]
In the documentation for MultiHashMap, it claims Getting a value will
always return a
scolebourne2004/02/25 11:26:12
Added: httpclient NOTICE.txt
Log:
Change to Apache License 2.0
Revision ChangesPath
1.1 jakarta-commons/httpclient/NOTICE.txt
Index: NOTICE.txt
===
scolebourne2004/02/25 11:28:40
Added: math NOTICE.txt
Log:
Change to Apache License 2.0
Revision ChangesPath
1.1 jakarta-commons/math/NOTICE.txt
Index: NOTICE.txt
===
This
luehe 2004/02/25 11:51:44
Modified:el/src/java/org/apache/commons/el ImplicitObjects.java
el/src/java/org/apache/commons/el/parser ELParser.java
Log:
Fixed JDK 1.5 compilation error (enum is considered a reserved
keyword in JDK 1.5)
[Patch provided by Ryan
On Tue, 24 Feb 2004, Ryan Hoegg wrote:
In order to promote the reuse of commons-codec instead of the
source-code-copy reuse strategy, I propose modifying the codec build to
create certain additional artifacts that might be more palatable to
developers in this situation.
Ryan, this is a
Hi,
Noel's description is correct. Please see my additional comments below:
-Original Message-
From: Noel J. Bergman [mailto:[EMAIL PROTECTED]
How does your proposal contrast/differs/combines with what has
been referred to on this list as streamable codecs?
See
Hi,
-Original Message-
From: Gary Gregory [mailto:[EMAIL PROTECTED]
public java.util.List operation(java.nio.ByteBuffer buffer);
This brings up an interesting issue: How do we potentially package and
deliver some code that depends on Java 1.4. In a second [codec] jar? I
think
I think the introduction of EncoderException and DecoderException
in and of itself was a mistake in the first place.
Encoder and Decoder are similar to Reader and Writer which both
throw IOException.
I agree fully.
I disagree fully, as I will explain.
Decode and encode operations are
scolebourne2004/02/25 12:38:25
Modified:primitives build.properties.sample
Log:
Change to Apache License 2.0
Revision ChangesPath
1.4 +14 -0 jakarta-commons/primitives/build.properties.sample
Index: build.properties.sample
scolebourne2004/02/25 12:42:18
Modified:primitives/xdocs faq.xml index.xml navigation.xml
primitives project.xml maven.xml PROPOSAL.html build.xml
LICENSE.txt project.properties checkstyle.xml
Added: primitives NOTICE.txt
Log:
Change to
Hello all,
Since the current discussions around stateful and streamable decoders all
involve introducing a new and better architecture I am wondering if we
should:
(1) Release a version 1.3 soon to gather all of the fixes and improvements
since the November 1.2 release and
(2) then work on the
Noel,
You have some very interesting ideas here which I need to process
and consider in depth. Expect more interfaces for discussion soon.
From: Noel J. Bergman [EMAIL PROTECTED]
Date: 2004/02/25 Wed PM 03:27:43 EST
To: Jakarta Commons Developers List [EMAIL PROTECTED]
Subject: RE:
scolebourne2004/02/25 13:30:32
Modified:fileupload/xdocs navigation.xml index.xml
fileupload project.xml
Log:
Update to new website design
Revision ChangesPath
1.7 +1 -1 jakarta-commons/fileupload/xdocs/navigation.xml
Index: navigation.xml
Emmanuel Bourg [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
[...]
imho the multiple lines syntax is cleaner and easier to handle.
I'm ok for this as it is close to what you would do with an xml element.
Though...
What do you think about a getObjectList(Class primitive, char delim)
olegk 2004/02/25 14:30:49
jakarta-commons/httpclient/src/test/org/apache/commons/httpclient/auth - New
directory
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
olegk 2004/02/25 14:33:59
Modified:httpclient/src/test/org/apache/commons/httpclient/server
SimpleHttpServerConnection.java
Added: httpclient/src/test/org/apache/commons/httpclient
HttpClientTestBase.java
Log:
* Base class
scolebourne2004/02/25 14:40:49
Modified:el/src/java/org/apache/commons/el ArraySuffix.java
PropertySuffix.java
GreaterThanOrEqualsOperator.java
ImplicitObjects.java UnaryOperatorExpression.java
dion2004/02/25 15:47:35
Modified:jelly/jelly-tags/html/src/test/org/apache/commons/jelly/html
index.html example2.jelly example.jelly
radioToPDA.jelly suite.jelly
jelly/jelly-tags/html project.xml gump.xml
dion2004/02/25 15:50:08
Modified:jelly/jelly-tags/http/src/test/org/apache/commons/jelly/google
defineTags.jelly search.jelly
jelly/jelly-tags/http project.properties maven.xml build.xml
project.xml gump.xml
Hi,
I think I found a potential problem in commons dbcp and can't find where
I should report it..
If you use the setCatalog function of JDBC you have an issue with the
Prepared Statement Cache, since the cache considers that two statements
with different catalogs are the same, and therefore
dion2004/02/25 16:16:30
Modified:jelly/jelly-tags/interaction project.xml maven.xml build.xml
project.properties
jelly/jelly-tags/interaction/src/java/org/apache/commons/jelly/tags/interaction
package.html
Hi Emmanuel,
Re your comments on bugzilla
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12997
I'd like to transfer this discussion to email rather than bugzilla form,
if that's ok. It's a pain typing and reading bugzilla comments :-)
I guess the problem is that the bugzilla entry is now
http://jakarta.apache.org/commons/patches.html
Every time I apply patches I have to go read the manual again,
and there isn't a wealth of examples.
A meager but helpful reference is:
http://www.network-theory.co.uk/articles/patchintro.html
Probably the best advice is to first try:
the
To whom it may engage...
This is an automated request, but not an unsolicited one. For help understanding the
request please visit http://jakarta.apache.org/gump/nagged.html, and/or contact [EMAIL
PROTECTED]
Project commons-jelly-tags-junit has an issue affecting it's community
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=27243.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
John Keyes wrote:
My point here is that if I have X requests then there can be
X * CONTENT_LENGTH_CHUNKED
bytes in memory at one time.
I see what you mean. But the above calculation does not make sense:
CONTENT_LENGTH_CHUNKED is a (negative) integer that signals to
HttpClient that you do not
I tried numerous suggestions from the list on how
to authenticate via proxy when you try the httpclient. But noe worked. Then i
ended up using these steps...
/
*/
HttpClient
Hello to all!
Forgive me, if I have made a mistake, by posting my question to an
irrelevant list, but this is my first try to use the benefits of the mailing
list.
I have just downloaded (from http://jakarta.apache.org/site/binindex.cgi)
version 2 (final) of httpclient and I am trying to create
Hi Saifadam,
that may depend upon the proxy also. If it is a Microsoft proxy you need
to use NTLM authentification which requires NTCredentials.
http://jakarta.apache.org/commons/httpclient/authentication.html
contains some further infos. At least that was what I needed.
Just my two cents,
Just one (relatively minor) addition: only Basic authentication can be used
preemptively. NTLM authentication scheme is stateful (that is, NTLM authentication
process spans across several requests/responses) and therefore NTLM credentials cannot
be used outside a valid authentication context.
On 25 Feb 2004, at 14:43, Ortwin Glück wrote:
John Keyes wrote:
My point here is that if I have X requests then there can be
X * CONTENT_LENGTH_CHUNKED
bytes in memory at one time.
I see what you mean. But the above calculation does not make sense:
CONTENT_LENGTH_CHUNKED is a (negative)
It's always good to have things configurable :-)
John, feel free to file a feature request with the Bugzilla if you want to keep track
of the issue resolution and provide us with some feedback.
http://nagoya.apache.org/bugzilla/enter_bug.cgi?product=Commons
I deem this feature fairly easy to
Koutsomboris,
Your servlet code appears to be causing the problem
ServletInputStream servInStream = null;
ByteArrayOutputStream baos = null;
ByteArrayInputStream bais = null;
byte[] bufByteArray = null;
String msgIN = null;
servInStream =
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=27237.
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=27237.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Hi Oleg,
1) Thanks for responding. I am new to using httpclient, but in our case, I
observed that if i do comment the preemptive authentication code, then the
executeMethod( ) causes a HttpRecoverableException exception to be thrown.
Also I observed the following line at the console where the
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=27237.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Hi Saifadam,
1) Thanks for responding. I am new to using httpclient, but in our
case, I
observed that if i do comment the preemptive authentication code, then
the
executeMethod( ) causes a HttpRecoverableException exception to be
thrown.
Also I observed the following line at the console where
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=27242.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Hi everyone,
can someone please help me to do the
following:
I wish to create a connection and send a request to
an website(using get or post ,etc methods). bUt most importantly, i dont know is
how do i form The header and the parameters and etc... for the request and then
send it.
Any
62 matches
Mail list logo
