Applied. Thanks Michael. Hope your account gets setup soon!
I've changed the licences for all source files to the proper long form and
ensured all copyright notices are up to the year 2002.
James
- Original Message -
From: Michael Smith [EMAIL PROTECTED]
To: Jakarta Commons Developers
Applied. Thanks Michael.
I've also been pondering a solution to the LRU issue that preserves the
efficiency of the bubble list (and avoids expensive tree or count-indexing
data structuers) but solves the problem that Aaron found. Still not had any
bright ideas yet :-(
Maybe renaming it to
Applied.
James
- Original Message -
From: Michael Smith [EMAIL PROTECTED]
To: Jakarta Commons Developers List [EMAIL PROTECTED]
Sent: Sunday, February 10, 2002 5:53 AM
Subject: [collections][PATCH] FilterIterator
Updated to proper long license
Removed duplicated line (probably as a
Hi Juozas,
do we need the Reachable and Swap interface. I believe
not. Because we do it without swapping and that stuff.
Yes or no?
We dont need Swap at this time, we will need it for Pool but not for Cashe.
It is better to remove this code, but ideas we will reause for Pool.
skip
Hi,
TODO for simplestore :
1. Code cleanup
(Remove some unused code, ideas are good, but they are for the next project,
I wil try to write proposal later )
Remove : Reacheble and Swap interfaces, cleanup package,JISP, MRUMap.
TODO for sample :
1. Add IODGenerator interfaceand default impl.
Juozas,
From: Juozas Baliuka [mailto:[EMAIL PROTECTED]]
Hi Juozas,
do we need the Reachable and Swap interface. I believe
not. Because we do it without swapping and that stuff.
Yes or no?
We dont need Swap at this time, we will need it for Pool but not for Cashe.
It is better to remove
Juozas,
From: Juozas Baliuka [mailto:[EMAIL PROTECTED]]
skip
Hi,
TODO for simplestore :
1. Code cleanup
(Remove some unused code, ideas are good, but they are for the next project,
I wil try to write proposal later )
Remove : Reacheble and Swap interfaces, cleanup package,JISP, MRUMap.
Already
froehlich02/02/10 03:25:46
Modified:simplestore README.txt
Log:
fixed typos
Revision ChangesPath
1.9 +10 -10jakarta-commons-sandbox/simplestore/README.txt
Index: README.txt
===
RCS file:
Hi Juozas,
why did you removed the methods
containsKey,
isEmpty
size
clear
Ok maybe they are not meaningful anymore but then they
shouldn't be implemented in the SoftRefMemoryStore!
Could you please explain me your thoughts here.
~Gerhard
I just found
the way that i read the xml spec, though 'id' and 'idref' are the most
commonly chosen (conventional) attribute names for the unique attributes
of type ID and IDREF, it is possible that each element could have
different names. for example, in the same document an element alpha
might have
baliuka 02/02/10 02:00:12
Modified:simplestore/src/java/org/apache/commons/simplestore
SoftRefMemoryStore.java Store.java
SynchronizedStore.java
simplestore/src/sample/org/apache/commons/simplestore/persistence
baliuka 02/02/10 02:48:34
Modified:simplestore/src/sample/org/apache/commons/simplestore/jdbc
DBStorage.java
simplestore/src/sample/org/apache/commons/simplestore/persistence
MetaObject.java PersistentProxy.java
Yes thats right. The only way to specify the ID and IDREF types is to use
DTDs or some other schema language. Its a shame this kinda stuff wasn't in
straight XML without the DTD/Schema layer being required but thats another
story...
From betwixt's perspective I guess the XMLBeanInfo should know
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Updated all the licences to the full long form and ensured
that the copyright notice extends to 2002. Also applied
Michael Smith's patch for FilterIterator, Closure,
DefaultMapEntry and LRUMap
Thanks James! Hopefully someone will still
From: James Strachan [mailto:[EMAIL PROTECTED]]
I've also been pondering a solution to the LRU issue that
preserves the
efficiency of the bubble list (and avoids expensive tree or
count-indexing
data structuers) but solves the problem that Aaron found.
Still not had any
bright ideas yet
The original message was received at Sun, 10 Feb 2002 13:14:19 0500
- The following addresses had permanent fatal errors -
[EMAIL PROTECTED]
- Transcript of session follows -
... while talking to mail.s1.com:
RCPT To:[EMAIL PROTECTED]
550 [EMAIL PROTECTED]... User
On Sunday, February 10, 2002, at 04:11 PM, James Strachan wrote:
Yes thats right. The only way to specify the ID and IDREF types is to use
DTDs or some other schema language. Its a shame this kinda stuff wasn't in
straight XML without the DTD/Schema layer being required but thats another
rdonkin 02/02/10 11:18:42
Modified:betwixt/src/java/org/apache/commons/betwixt/io
BeanWriter.java
Log:
Added code to escape text in attribute values and element body text
Revision ChangesPath
1.13 +85 -7
rdonkin 02/02/10 11:19:39
Modified:betwixt/src/test/org/apache/commons/betwixt
TestBeanWriter.java
Log:
Not very good test code for escaping
Revision ChangesPath
1.10 +25 -6
Sean C. Sullivan wrote:
What is the minimum supported JDK version for
the HttpClient class library?
From status.html, JDK 1.2 for run time, although the 'external'
interface is 1.1 compliant.
Will HttpClient run on JDK 1.1.x?
Not sure. I'm certain it won't compile on it. Use of List
Sean C. Sullivan wrote:
Jakarta-commons HttpClient inquiry:
Why does the NameValuePair constructor allow
null parameters?
This is how the code currently looks:
NameValuePair.java
--
/**
* Constructor.
*/
public NameValuePair(String name, String
Sean C. Sullivan wrote:
jakarta-commons httpclient inquiry:
Currently, HttpMethod.java (an interface) defines a
method called getResponseBody:
/**
* Return my response body, if any,
* as a byte array.
* Otherwise return ttnull/tt.
*/
public byte[]
From: dIon Gillard [mailto:[EMAIL PROTECTED]]
my call would be if these are illegal arguments, it should throw
IllegalArgumentException, not NullPointerException.
NullPointerException makes perfect sense in that case. The API
documentation for NullPointerException specifically states it
From: dIon Gillard [EMAIL PROTECTED]
Sean C. Sullivan wrote:
NameValuePair.java
--
/**
* Constructor.
*/
public NameValuePair(String name, String value) {
this.name = name;
this.value = value;
}
From: dIon Gillard [EMAIL PROTECTED]
Sean C. Sullivan wrote:
Currently, HttpMethod.java (an interface) defines a
method called getResponseBody:
/**
* Return my response body, if any,
* as a byte array.
* Otherwise return ttnull/tt.
*/
public byte[]
craigmcc02/02/10 15:12:36
Modified:services PROPOSAL.html
services/src/java/org/apache/commons/services
ServiceManager.java
Log:
Fix compile-time errors related to commons-logging caused by changes in the
logging packaging. Along the way,
jstrachan02/02/10 16:12:05
jakarta-commons-sandbox/jelly - New directory
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
jstrachan02/02/10 16:14:31
jakarta-commons-sandbox/jelly/src - New directory
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
jstrachan02/02/10 16:15:36
jakarta-commons-sandbox/jelly/src/java - New directory
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
jstrachan02/02/10 16:17:08
jakarta-commons-sandbox/jelly/src/test/org - New directory
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
jstrachan02/02/10 16:17:42
jakarta-commons-sandbox/jelly/src/java/org/apache/commons - New directory
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
jstrachan02/02/10 16:18:27
jakarta-commons-sandbox/jelly/src/test/org/apache/commons - New directory
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
jstrachan02/02/10 16:18:27
jakarta-commons-sandbox/jelly/src/test/org/apache/commons/jelly - New directory
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
jstrachan02/02/10 16:18:35
jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/parser - New
directory
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
jstrachan02/02/10 16:18:35
jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/impl - New directory
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
jstrachan02/02/10 16:23:04
jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/tags/xml - New
directory
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Why does the NameValuePair constructor allow
null parameters?
1. IIRC, there are times we use null attributes. For example,
NameValuePair(foo,null) is represents foo (as a query string or header
element) while NameValuePair(foo,) represtents foo=.
2. If NameValuePair(String,String) doesn't
I want the behavior of
getResponseBody to be consistent with
the behavior of other
standard (java.*) classes.
Example 1: java.util.Vector.toArray
The return value, Object[], will never be null.
Example 2: java.lang.String.getBytes
The return value, byte[], will never be null.
38 matches
Mail list logo