RE: [codec] Streamable Codec Framework

2003-11-10 Thread Gary Gregory
Agreed, I just wanted to make make a point WRT 1.4 vs = 1.4. Now, for 1.2.2
vs. 1.3.1, that's a different story. It would be interesting to pool the
various lists for the LCD JRE.

Gary

 -Original Message-
 From: Tim O'Brien [mailto:[EMAIL PROTECTED]
 Sent: Sunday, November 09, 2003 21:06
 To: Jakarta Commons Developers List
 Subject: RE: [codec] Streamable Codec Framework
 
 Well, not so fast, I thought that the general Jakarta Commons rule was
 1.2 compatibility.
 
 The reasoning here is that, if some unfortunate programmer is stuck
 working on some legacy code, they shouldn't need to upgrade to
 JDK1.4.2_02 to get a Base64 encoding.
 
 But, let's discuss.
 
 
 
 On Sun, 2003-11-09 at 22:01, Gary Gregory wrote:
   If JDK1.4 is considered a sufficient base, I could
 
  I think tha considering 1.3.1 as the base requirement is safe.
  Unfortunately, as discussed on this list under various heading, making
 1.4 a
  requirement is too aggressive.
 
  Gary
 
   -Original Message-
   From: Brett Henderson [mailto:[EMAIL PROTECTED]
   Sent: Sunday, November 09, 2003 19:26
   To: 'Jakarta Commons Developers List'
   Subject: RE: [codec] Streamable Codec Framework
  
   I think the design of the codec framework could cover
   your requirements but it will require more functionality
   than it currently has.
  
   Some of the goals I was working towards were:
   1. No memory allocation during streaming.  This eliminates
   garbage collection during large conversions.
  Cool. I got large conversions... I'm already at
  mediumblob in mysql , and it goes up/down XML
 stream
  :)

 I have a lot to learn here.  While I have some
 knowledge
 of XML (like every other developer on the planet), I
 have never used it for large data sets or used SAX
 parsing.
 Sounds like a good test to find holes in the design
 :-)
   
It's easy. You got callback, where you can gobble up
string buffers with incoming chars for element
contents.  ( and there is a lot of this stuff... )
After tag is closed, you have all the chars in a big
string buffer, and get another callback - in this
callback you have to convert data, and do whatever
necessary ( in my case, create input stream, and pass
it to database )
  
   This could be tricky, it's something I've been thinking
   about but would like feedback from others about the best
   way of going about it.
  
   The data you have available is in character format.
   The base64 codec engine operates on byte buffers.
   The writer you want to write to requires the data
   to be in character format.
  
   I have concentrated on byte processing for now because
   it is the most common requirement.  XML processing
   requires that characters be used instead.
  
   It makes no sense to perform base64 conversion on
   character arrays directly because base64 is only 8-bit
   aware (you could split each character into two bytes
   but this would blow out the result buffer size where
   chars only contain ASCII data).
  
   I think it makes more sense to perform character to
   byte conversion separately (perhaps through
   extensions to existing framework) and then perform
   base64 encoding on the result.  I guess this is a
   UTF-16 to UTF-8 conversion ...
  
   What support is there within the JDK for performing
   character to byte conversion?
   JDK1.4 has the java.nio.charset package but I can't
   see an equivalent for JDK1.3 and lower, they seem to
   use com.sun classes internally when charset conversion
   is required.
  
   If JDK1.4 is considered a sufficient base, I could
   extend the current framework to provide conversion
   engines that translate from one data representation
   to another.  I could then create a new CodecEngine
   interface to handle character buffers (eg.
   CodecEngineChar).
  
  
   3. Customisable receivers.  All codecs utilise
   receivers to
   handle conversion results.  This allows
 different
   outputs such as
   streams, in-memory buffers, etc to be supported.
 
  And writers :) Velocity directives use them.

 Do you mean java.io.Writer?  If so I haven't
 included
 direct support for them because I focused on raw
 byte
 streams.  However it shouldn't be hard to add a
 receiver to write to java.io.Writer instances.
   
   
My scenarios:
- I'm exporting information as base64 to XML with help
ov velocity. I do it through custom directive -
in this directive I get a Writer from velocity, where
I have to put my data.
   
Ideally codec would do: read input stream - encode -
put it into writer without allocating too much
memory.
   
I'm importing information:
- I have stream ( string ) of base 64 data -
codec gives me an input stream which is fed from this
source and does not allocate too much memory and
behaves polite...
   
   The current framework 

[validator] client side validation: alternative for alert()?

2003-11-10 Thread Wouter Denayer
Hello,

Currently with client side validation, when there is an error an alert() 
popup box is used to signal this to the user. By using client side DHTML 
we could get pretty much the same behavior as you get when going to the 
server and coming back, i.e. all messages grouped together above the 
form + each message repeated close to the offending field. Has there 
been any thought of implementing this functionality in validator?

regards,

Wouter Denayer

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


RE: [codec] Streamable Codec Framework

2003-11-10 Thread olegk
Tim, Gary, et al
Streamable codec framework would be a welcome addition to Commons Codec.
However, as far as we (Commons HttpClient) are concerned, the decision to
ditch java 1.2.2 support would render Codec unusable for us (and I'd guess
a few other projects that still need to maintain java 1.2.2 compatibility).
Not that we like it too much, but because lots of our users still demand
it. 

We are determined to introduce Codec as a dependency for HttpClient as of
next point release (currently designated as 2.1). However, I foresee a lot
of popular pressure to abandon these plans in favour of retaining java 1.2.2
compatibility, should Codec require Java 1.3.x.

Cheers

Oleg

 Agreed, I just wanted to make make a point WRT 1.4 vs = 1.4. Now, for
1.2.2
 vs. 1.3.1, that's a different story. It would be interesting to pool the
 various lists for the LCD JRE.
 
 Gary


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



Re: OT: Re: [ANN] hivemind has been temporarily taken offline

2003-11-10 Thread Vic Cekvenich
Noel J. Bergman wrote:

The Geronimo developers represent that
the code contributed for Geronimo does not contain any code belonging to
JBoss.  
I just wanted to underline above.

.V



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


Re: cvs commit: jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/protocol Protocol.java

2003-11-10 Thread Michael Becke
I think the addition of an instanceof test is good, but I think we  
should deprecate here instead of removing the constructor.  This  
removal causes a binary compatibility problem that I think we can  
easily avoid.

Mike

On Nov 7, 2003, at 2:34 AM, [EMAIL PROTECTED] wrote:

oglueck 2003/11/06 23:34:34

  Modified:httpclient API_CHANGES_2_1.txt

httpclient/src/java/org/apache/commons/httpclient/protocol
Protocol.java
  Log:
  fixed design error: uniform Protocol constructor for all factories

  Revision  ChangesPath
  1.4   +2 -0  jakarta-commons/httpclient/API_CHANGES_2_1.txt
  Index: API_CHANGES_2_1.txt
  ===
  RCS file: /home/cvs/jakarta-commons/httpclient/API_CHANGES_2_1.txt,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- API_CHANGES_2_1.txt	18 Sep 2003 13:56:21 -	1.3
  +++ API_CHANGES_2_1.txt	7 Nov 2003 07:34:34 -	1.4
  @@ -31,3 +31,5 @@
   state of DigestScheme:
   - createDigest(String, String)
   - createDigestHeader(String, String)
  +
  +* There is only one Protocol constructor for both secure and  
insecure socket factories.



  1.6   +6 -32  
jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/ 
protocol/Protocol.java

  Index: Protocol.java
  ===
  RCS file:  
/home/cvs/jakarta-commons/httpclient/src/java/org/apache/commons/ 
httpclient/protocol/Protocol.java,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- Protocol.java	31 Jan 2003 00:33:36 -	1.5
  +++ Protocol.java	7 Nov 2003 07:34:34 -	1.6
  @@ -194,7 +194,8 @@
   private boolean secure;

   /**
  - * Constructs a new Protocol.  The created protcol is insecure.
  + * Constructs a new Protocol. If the created protocol is secure  
depends on
  + * the class of codefactory/code.
*
* @param scheme the scheme (e.g. http, https)
* @param factory the factory for creating sockets for  
communication using
  @@ -216,36 +217,9 @@
   this.scheme = scheme;
   this.socketFactory = factory;
   this.defaultPort = defaultPort;
  -this.secure = false;
  +this.secure = (factory instanceof  
SecureProtocolSocketFactory);
   }

  -/**
  - * Constructs a new Protocol.  The created protcol is secure.
  - *
  - * @param scheme the scheme (e.g. http, https)
  - * @param factory the factory for creating sockets for  
communication using
  - * this protocol
  - * @param defaultPort the port this protocol defaults to
  - */
  -public Protocol(String scheme,
  -SecureProtocolSocketFactory factory, int defaultPort) {
  -
  -if (scheme == null) {
  -throw new IllegalArgumentException(scheme is null);
  -}
  -if (factory == null) {
  -throw new IllegalArgumentException(socketFactory is  
null);
  -}
  -if (defaultPort = 0) {
  -throw new IllegalArgumentException(port is invalid:   
+ defaultPort);
  -}
  -
  -this.scheme = scheme;
  -this.socketFactory = factory;
  -this.defaultPort = defaultPort;
  -this.secure = true;
  -}
  -
   /**
* Returns the defaultPort.
* @return int



-
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 24562] New: - PoolingDriver needs a closePool method

2003-11-10 Thread bugzilla
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=24562.
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=24562

PoolingDriver needs a closePool method

   Summary: PoolingDriver needs a closePool method
   Product: Commons
   Version: 1.1 Final
  Platform: All
OS/Version: All
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: Dbcp
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


The PoolingDriver allows the user to register connection pools using the
registerPool(String name, ObjectPool pool) method but there is no method to
close a registered pool.

A new method on PoolingDriver is needed:
public synchronized void closePool(String name) throws SQLException

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



Re: cvs commit: jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/protocol Protocol.java

2003-11-10 Thread Ortwin Glück
Michael Becke wrote:
I think the addition of an instanceof test is good, but I think we  
should deprecate here instead of removing the constructor.  This  
removal causes a binary compatibility problem that I think we can  
easily avoid.

Mike


That's why it is listed in API changes :-)

Of course we can replace the second constructor with a call to the first 
one to be 2.0 API compatible:

/**
 * @deprecated
 */
public Protocol(String scheme, SecureProtocolSocketFactory factory, int 
defaultPort) {
  this(scheme, (ProtocolSocketFactory) factory, defaultPort);
}

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


[hivemind] Multiple implementations for the same service ...

2003-11-10 Thread Johan Lindquist
Trying to construct a service that has many implementations but use the 
same interface.  I can do this by putting them into different modules, but 
that require the service points to be defined for each one of the 
implementations.

Ideally it would be nice to have one service point with several 
implementations to that service point, allowing users to select the 
correct implementation depending on some defined (meta) information (a la 
avalon).

Are there any plans of allowing this?  could this be considered a 
different service model?

Thanks,

johan

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


RE: [VOTE] Release DbUtils 1.0

2003-11-10 Thread Shapira, Yoav

Howdy,
+1, looking forward to using it in production ;)

Yoav Shapira
Millennium ChemInformatics


-Original Message-
From: Juozas Baliuka [mailto:[EMAIL PROTECTED]
Sent: Monday, November 10, 2003 12:40 AM
To: Jakarta Commons Developers List
Subject: Re: [VOTE] Release DbUtils 1.0

+1
- Original Message -
From: David Graham [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Sunday, November 09, 2003 10:25 PM
Subject: [VOTE] Release DbUtils 1.0


 DbUtils is a stable, well tested package suitable for a 1.0 release.
The
 release candidate is available here:

 http://jakarta.apache.org/~dgraham/dbutils-1.0-rc1/

 Here's my +1.

 David

 __
 Do you Yahoo!?
 Protect your identity with Yahoo! Mail AddressGuard
 http://antispam.yahoo.com/whatsnewfree

 -
 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]




This e-mail, including any attachments, is a confidential business communication, and 
may contain information that is confidential, proprietary and/or privileged.  This 
e-mail is intended only for the individual(s) to whom it is addressed, and may not be 
saved, copied, printed, disclosed or used by anyone else.  If you are not the(an) 
intended recipient, please immediately delete this e-mail from your computer system 
and notify the sender.  Thank you.


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



Re: [math] implementation of Polynomial Function

2003-11-10 Thread Mark R. Diggory
Thanks Matt,

I'll apply and test both this and the earlier patch. I've fleshed out 
more documentation on using Bugzilla. The next time the site is updated 
it should be available on the site. Until then, update your cvs checkout 
and take a look at the following document in your browser.

/commons/math/xdocs/developers.xml

It has several simple bugzilla links that make it simpler to submit a 
bug/patch into the math project bugzilla.

-Mark

Matt Cliff wrote:

Attached are two new files that implement a Polynomial as a 
UnivariateRealFunction and should be added to the 
org.apache.commons.math.analysis packages in both java and test 
respectively.

 I do not have commit privileges and would appreciate on the the math 
contributors or members to add these.

   also, I have added a patch that will remove the firstDerivative and 
secondDerivative methods from the UnivariateRealFunction interface (and 
appropriate unit test).  This item was still pending consensus.  I plan to 
write a couple classes such as UnivariateRealDifferentiator that will give 
numeric approximates using point evaluation to achieve this.  I also plan 
to contribute UnivariateRealIntegrator pattern.





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: cvs commit: jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/protocol Protocol.java

2003-11-10 Thread Michael Becke
That's why it is listed in API changes :-)

Of course we can replace the second constructor with a call to the first 
one to be 2.0 API compatible:
Yes, I think deprecation and calling the first constructor would be better.

Mike

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


cvs commit: jakarta-commons/pool project.xml

2003-11-10 Thread dirkv
dirkv   2003/11/10 06:20:15

  Modified:pool project.xml
  Log:
  start new dev version
  
  Revision  ChangesPath
  1.18  +1 -1  jakarta-commons/pool/project.xml
  
  Index: project.xml
  ===
  RCS file: /home/cvs/jakarta-commons/pool/project.xml,v
  retrieving revision 1.17
  retrieving revision 1.18
  diff -u -r1.17 -r1.18
  --- project.xml   20 Oct 2003 19:49:00 -  1.17
  +++ project.xml   10 Nov 2003 14:20:15 -  1.18
  @@ -9,7 +9,7 @@
 shortDescriptionCommons Object Pooling Library/shortDescription
 descriptionCommons Object Pooling Library/description
   
  -  currentVersion1.1/currentVersion
  +  currentVersion1.2-dev/currentVersion
 versions
   version
 id1.0/id
  
  
  

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



cvs commit: jakarta-commons/pool/src/java/org/apache/commons/pool/impl GenericObjectPool.java

2003-11-10 Thread dirkv
dirkv   2003/11/10 06:25:29

  Modified:pool/src/java/org/apache/commons/pool/impl
GenericObjectPool.java
  Log:
  Improve error message when no validated object could be created
  suggested by Chris Handorf
  
  Revision  ChangesPath
  1.30  +4 -4  
jakarta-commons/pool/src/java/org/apache/commons/pool/impl/GenericObjectPool.java
  
  Index: GenericObjectPool.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/pool/src/java/org/apache/commons/pool/impl/GenericObjectPool.java,v
  retrieving revision 1.29
  retrieving revision 1.30
  diff -u -r1.29 -r1.30
  --- GenericObjectPool.java9 Oct 2003 21:45:56 -   1.29
  +++ GenericObjectPool.java10 Nov 2003 14:25:29 -  1.30
  @@ -848,7 +848,7 @@
   // cannot destroy broken object 
   }
   if(newlyCreated) {
  -throw new NoSuchElementException(Could not create a validated 
object);
  +throw new NoSuchElementException(Could not create a validated 
object, cause:  + e.getMessage());
   } 
   else {
   continue; // keep looping
  
  
  

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



cvs commit: jakarta-commons/dbcp/src/java/org/apache/commons/dbcp PoolingDriver.java

2003-11-10 Thread dirkv
dirkv   2003/11/10 06:26:19

  Modified:dbcp/src/java/org/apache/commons/dbcp PoolingDriver.java
  Log:
  Bugzilla Bug 24562: PoolingDriver needs a closePool method
  - add requested method
  
  Revision  ChangesPath
  1.8   +19 -6 
jakarta-commons/dbcp/src/java/org/apache/commons/dbcp/PoolingDriver.java
  
  Index: PoolingDriver.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/dbcp/src/java/org/apache/commons/dbcp/PoolingDriver.java,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- PoolingDriver.java9 Oct 2003 21:04:44 -   1.7
  +++ PoolingDriver.java10 Nov 2003 14:26:19 -  1.8
  @@ -106,7 +106,7 @@
* 
* @deprecated This will be removed in a future version of DBCP.
*/
  -synchronized public ObjectPool getPool(String name) {
  +public synchronized ObjectPool getPool(String name) {
   try {
   return getConnectionPool(name);
   }
  @@ -115,7 +115,7 @@
   }
   }
   
  -synchronized protected ObjectPool getConnectionPool(String name) throws 
SQLException {
  +public synchronized ObjectPool getConnectionPool(String name) throws 
SQLException {
   ObjectPool pool = (ObjectPool)(_pools.get(name));
   if(null == pool) {
   InputStream in = 
this.getClass().getResourceAsStream(String.valueOf(name) + .jocl);
  @@ -149,8 +149,21 @@
   return pool;
   }
   
  -synchronized public void registerPool(String name, ObjectPool pool) {
  +public synchronized void registerPool(String name, ObjectPool pool) {
   _pools.put(name,pool);
  +}
  +
  +public synchronized void closePool(String name) throws SQLException {
  +ObjectPool pool = (ObjectPool) _pools.get(name);
  +if (pool != null) {
  +_pools.remove(name);
  +try {
  +pool.close();
  +}
  +catch (Exception e) {
  +throw new SQLNestedException(Error closing pool  + name, e);
  +}
  +}
   }
   
   public boolean acceptsURL(String url) throws SQLException {
  
  
  

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



cvs commit: jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/protocol Protocol.java

2003-11-10 Thread oglueck
oglueck 2003/11/10 06:33:13

  Modified:httpclient API_CHANGES_2_1.txt
   httpclient/src/java/org/apache/commons/httpclient/protocol
Protocol.java
  Log:
  re-include old constructor signature for
  backwards API compatibility
  
  Revision  ChangesPath
  1.5   +1 -1  jakarta-commons/httpclient/API_CHANGES_2_1.txt
  
  Index: API_CHANGES_2_1.txt
  ===
  RCS file: /home/cvs/jakarta-commons/httpclient/API_CHANGES_2_1.txt,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- API_CHANGES_2_1.txt   7 Nov 2003 07:34:34 -   1.4
  +++ API_CHANGES_2_1.txt   10 Nov 2003 14:33:13 -  1.5
  @@ -32,4 +32,4 @@
   - createDigest(String, String)
   - createDigestHeader(String, String)
   
  -* There is only one Protocol constructor for both secure and insecure socket 
factories.
  +* Deprecated extra Protocol constructor
  
  
  
  1.7   +20 -4 
jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/protocol/Protocol.java
  
  Index: Protocol.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/protocol/Protocol.java,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- Protocol.java 7 Nov 2003 07:34:34 -   1.6
  +++ Protocol.java 10 Nov 2003 14:33:13 -  1.7
  @@ -194,7 +194,7 @@
   private boolean secure;
 
   /**
  - * Constructs a new Protocol. If the created protocol is secure depends on
  + * Constructs a new Protocol. Whether the created protocol is secure depends on
* the class of codefactory/code.
* 
* @param scheme the scheme (e.g. http, https)
  @@ -219,6 +219,22 @@
   this.defaultPort = defaultPort;
   this.secure = (factory instanceof SecureProtocolSocketFactory);
   }
  +
  +/**
  + * Constructs a new Protocol. Whether the created protocol is secure depends on
  + * the class of codefactory/code.
  + *
  + * @param scheme the scheme (e.g. http, https)
  + * @param factory the factory for creating sockets for communication using
  + * this protocol
  + * @param defaultPort the port this protocol defaults to
  + * @deprecated Use the constructor that uses ProtocolSocketFactory, this 
version of
  + * the constructor is only kept for backwards API compatibility.
  + */
  +public Protocol(String scheme, 
  +SecureProtocolSocketFactory factory, int defaultPort) {
  +this(scheme, (ProtocolSocketFactory) factory, defaultPort);   
  +}
   
   /**
* Returns the defaultPort.
  
  
  

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



Re: cvs commit: jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/protocol Protocol.java

2003-11-10 Thread Ortwin Glück
Michael Becke wrote:
Yes, I think deprecation and calling the first constructor would be better.
Okay, I just changed it. Thanks for the hint, Mike.

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


Re: [VOTE] Release DbUtils 1.0

2003-11-10 Thread __matthewHawthorne
+1



Shapira, Yoav wrote:
Howdy,
+1, looking forward to using it in production ;)
Yoav Shapira
Millennium ChemInformatics


-Original Message-
From: Juozas Baliuka [mailto:[EMAIL PROTECTED]
Sent: Monday, November 10, 2003 12:40 AM
To: Jakarta Commons Developers List
Subject: Re: [VOTE] Release DbUtils 1.0
+1
- Original Message -
From: David Graham [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Sunday, November 09, 2003 10:25 PM
Subject: [VOTE] Release DbUtils 1.0


DbUtils is a stable, well tested package suitable for a 1.0 release.
The

release candidate is available here:

http://jakarta.apache.org/~dgraham/dbutils-1.0-rc1/

Here's my +1.

David

__
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree
-
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]




This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged.  This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else.  If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender.  Thank you.


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


cvs commit: jakarta-commons/dbutils/src/java/org/apache/commons/dbutils BasicRowProcessor.java

2003-11-10 Thread yoavs
yoavs   2003/11/10 08:16:32

  Modified:dbutils/src/java/org/apache/commons/dbutils
BasicRowProcessor.java
  Log:
  Cleaned up spelling (primitiveDefaults) and a bit of JavaDoc.
  
  Revision  ChangesPath
  1.4   +48 -23
jakarta-commons/dbutils/src/java/org/apache/commons/dbutils/BasicRowProcessor.java
  
  Index: BasicRowProcessor.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/dbutils/src/java/org/apache/commons/dbutils/BasicRowProcessor.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- BasicRowProcessor.java9 Nov 2003 18:52:18 -   1.3
  +++ BasicRowProcessor.java10 Nov 2003 16:16:32 -  1.4
  @@ -85,6 +85,7 @@
* @author Henri Yandell
* @author Juozas Baliuka
* @author David Graham
  + * @author Yoav Shapira
*/
   public class BasicRowProcessor implements RowProcessor {
   
  @@ -93,17 +94,17 @@
* is returned.  These are the same as the defaults that ResultSet get* 
* methods return in the event of a NULL column.
*/
  -private static final Map primitveDefaults = new HashMap();
  +private static final Map primitiveDefaults = new HashMap();
   
   static {
  -primitveDefaults.put(Integer.TYPE, new Integer(0));
  -primitveDefaults.put(Short.TYPE, new Short((short) 0));
  -primitveDefaults.put(Byte.TYPE, new Byte((byte) 0));
  -primitveDefaults.put(Float.TYPE, new Float(0));
  -primitveDefaults.put(Double.TYPE, new Double(0));
  -primitveDefaults.put(Long.TYPE, new Long(0));
  -primitveDefaults.put(Boolean.TYPE, Boolean.FALSE);
  -primitveDefaults.put(Character.TYPE, new Character('\u'));
  +primitiveDefaults.put(Integer.TYPE, new Integer(0));
  +primitiveDefaults.put(Short.TYPE, new Short((short) 0));
  +primitiveDefaults.put(Byte.TYPE, new Byte((byte) 0));
  +primitiveDefaults.put(Float.TYPE, new Float(0));
  +primitiveDefaults.put(Double.TYPE, new Double(0));
  +primitiveDefaults.put(Long.TYPE, new Long(0));
  +primitiveDefaults.put(Boolean.TYPE, Boolean.FALSE);
  +primitiveDefaults.put(Character.TYPE, new Character('\u'));
   }
   
   /**
  @@ -119,6 +120,8 @@
   
   /**
* Returns the Singleton instance of this class.
  + *
  + * @return The single instance of this class.
*/
   public static BasicRowProcessor instance() {
   return instance;
  @@ -135,7 +138,8 @@
* Convert a codeResultSet/code row into an codeObject[]/code.
* This implementation copies column values into the array in the same 
* order they're returned from the codeResultSet/code.  Array elements
  - * will be set to codenull/code if the column was SQL NULL. 
  + * will be set to codenull/code if the column was SQL NULL.
  + *
* @see org.apache.commons.dbutils.RowProcessor#toArray(java.sql.ResultSet)
*/
   public Object[] toArray(ResultSet rs) throws SQLException {
  @@ -241,13 +245,14 @@
   
   /**
* Creates a new object and initializes its fields from the ResultSet.
  - * @param rs
  - * @param type
  - * @param props
  - * @param columnToProperty
  - * @param cols
  + *
  + * @param rs The result set
  + * @param type The bean type (the return type of the object)
  + * @param props The property descriptors
  + * @param columnToProperty The column indices in the result set
  + * @param cols The number of columns
* @return An initialized object.
  - * @throws SQLException
  + * @throws SQLException If a database error occurs
*/
   private Object createBean(
   ResultSet rs,
  @@ -271,7 +276,7 @@
   Class propType = prop.getPropertyType();
   
   if (propType != null  value == null  propType.isPrimitive()) {
  -value = primitveDefaults.get(propType);
  +value = primitiveDefaults.get(propType);
   }
   
   this.callSetter(bean, prop, value);
  @@ -286,10 +291,12 @@
* for the bean property that matches the column name.  If no bean property
* was found for a column, the position is set to PROPERTY_NOT_FOUND.
* 
  + * @param rsmd The result set meta data containing column information
  + * @param props The bean property descriptors
* @return An int[] with column index to property index mappings.  The 0th 
* element is meaningless as column indexing starts at 1.
* 
  - * @throws SQLException
  + * @throws SQLException If a database error occurs
*/
   private int[] mapColumnsToProperties(
   ResultSetMetaData rsmd,
  @@ -385,6 +392,7 @@
* 
* @param value The value to be passed into the setter method.
* @param type 

cvs commit: jakarta-commons/dbutils STATUS.html

2003-11-10 Thread yoavs
yoavs   2003/11/10 08:18:42

  Modified:dbutils  STATUS.html
  Log:
  
  
  Revision  ChangesPath
  1.2   +2 -1  jakarta-commons/dbutils/STATUS.html
  
  Index: STATUS.html
  ===
  RCS file: /home/cvs/jakarta-commons/dbutils/STATUS.html,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- STATUS.html   2 Nov 2003 19:15:23 -   1.1
  +++ STATUS.html   10 Nov 2003 16:18:42 -  1.2
  @@ -34,6 +34,7 @@
   lia href=mailto:[EMAIL PROTECTED]Steven Caswell/a/li
   lia href=mailto:[EMAIL PROTECTED]Juozas Baliuka/a/li
   lia href=mailto:[EMAIL PROTECTED]David Graham/a/li
  +lia href=mailto:[EMAIL PROTECTED]Yoav Shapira/a/li
   liFancy volunteering?  We need you!/li
   /ul
   
  
  
  

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



cvs commit: jakarta-commons/dbutils project.xml

2003-11-10 Thread yoavs
yoavs   2003/11/10 08:28:05

  Modified:dbutils  project.xml
  Log:
  Added myself.
  
  Revision  ChangesPath
  1.4   +9 -0  jakarta-commons/dbutils/project.xml
  
  Index: project.xml
  ===
  RCS file: /home/cvs/jakarta-commons/dbutils/project.xml,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- project.xml   9 Nov 2003 19:38:07 -   1.3
  +++ project.xml   10 Nov 2003 16:28:05 -  1.4
  @@ -92,6 +92,15 @@
   roleJava Developer/role
 /roles
   /developer
  +developer
  +  nameYoav Shapira/name
  +  idyoavs/id
  +  email[EMAIL PROTECTED]/email
  +  organization/organization
  +  roles
  +roleJava Developer/role
  +  /roles
  +/developer
 /developers
   
   
  
  
  

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



[DbUtils] Commit flag on QueryRunner

2003-11-10 Thread Shapira, Yoav

Hi,
I have a request from a coworker who uses DbUtils to add a flag to turn
of auto-commit in the QueryRunner.  The text of his request is below.
What do you think, is it too big to get into DbUtils 1.0?

There needs to be an option on QueryRunner to turn off the commit()
calls on the updates that use a datasource.  I would like to use it to
build DAOs which will be used in the context of the JTA.  This might be
through either EJB beans or more directly using UserTransaction.  The
presence of the commit calls setAutoCommit, commit, rollback) in the
update methods that use a datasource make this impossible with those
methods.  What I would like to do is instantiate a QueryRunner with a
flag to turn this off.

Yoav Shapira
Millennium ChemInformatics





This e-mail, including any attachments, is a confidential business communication, and 
may contain information that is confidential, proprietary and/or privileged.  This 
e-mail is intended only for the individual(s) to whom it is addressed, and may not be 
saved, copied, printed, disclosed or used by anyone else.  If you are not the(an) 
intended recipient, please immediately delete this e-mail from your computer system 
and notify the sender.  Thank you.


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



cvs commit: jakarta-commons/dbutils/xdocs examples.xml

2003-11-10 Thread yoavs
yoavs   2003/11/10 08:45:45

  Added:   dbutils/xdocs examples.xml
  Log:
  Initial version of Examples page.
  
  Revision  ChangesPath
  1.1  jakarta-commons/dbutils/xdocs/examples.xml
  
  Index: examples.xml
  ===
  ?xml version=1.0?
  
  document
  
   properties
titleJDBC Utility Component -- Examples/title
author email=[EMAIL PROTECTED]Yoav Shapira/author
   /properties
  
  body
  
  section name=DbUtils: JDBC Utility Component Examples
  p
  This page provides examples that show how the DbUtils component
  may be used.
  /p
  /section
  
  section name=Basic Usage
  p
  The core classes/interfaces in DbUtils are 
  codea 
href=apidocs/org/apache/commons/dbutils/QueryRunner.htmlQueryRunner/a/code
  and
  codea 
href=apidocs/org/apache/commons/dbutils/ResultSetHandler.htmlResultSetHandler/a/code.
  The following example demonstrates how these classes are used together.
  /p
  
  pre
  DataSource ds = // somehow get DataSource;
  
  // Step 1.
  QueryRunner run = new QueryRunner(ds);
  
  // Step 2.
  ResultSetHandler h = new BeanHandler(Person.class);
  
  // Step 3.
  Person p = (Person) run.query(SELECT * FROM Person WHERE name=?, John Doe, h); 
  
  /pre
  
  pExplanation/p
  ol
  li
  Configure QueryRunner with the DataSource.
  Note that QueryRunner has methods that take a 
  java.sql.Connection so you are not required to
  use DataSources.
  /li
  li
  Implement the ResultSetHandler interface or use
  one of the provided implementations.  This one converts a 
  ResultSet row into a bean.
  /li
  li
  Execute the SQL statement with one replacement parameter and
  return the results in a new Person object (generated by the handler
  in step 2).
  /li
  /ol
  
  /section
  
  /body
  /document
  
  
  
  

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



cvs commit: jakarta-commons/dbutils/xdocs navigation.xml

2003-11-10 Thread yoavs
yoavs   2003/11/10 08:46:29

  Modified:dbutils/xdocs navigation.xml
  Log:
  Added Examples page.
  
  Revision  ChangesPath
  1.2   +1 -0  jakarta-commons/dbutils/xdocs/navigation.xml
  
  Index: navigation.xml
  ===
  RCS file: /home/cvs/jakarta-commons/dbutils/xdocs/navigation.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- navigation.xml2 Nov 2003 19:15:24 -   1.1
  +++ navigation.xml10 Nov 2003 16:46:29 -  1.2
  @@ -6,6 +6,7 @@
 body
   menu name=DbUtils
 item name=Overview href=/index.html/
  +  item name=Examples href=/examples.html /
 item name=Downloads href=/downloads.html/
 item name=To Do List href=/todo.html/
   /menu
  
  
  

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



Re: cvs commit: jakarta-commons/dbutils/src/java/org/apache/commons/dbutils BasicRowProcessor.java

2003-11-10 Thread David Graham
-1 on the change at the bottom of the file:
// End of class: BasicRowProcessor.java

This is redundant and insults my intelligence :-).

David



--- [EMAIL PROTECTED] wrote:
 yoavs   2003/11/10 08:16:32
 
   Modified:dbutils/src/java/org/apache/commons/dbutils
 BasicRowProcessor.java
   Log:
   Cleaned up spelling (primitiveDefaults) and a bit of JavaDoc.
   
   Revision  ChangesPath
   1.4   +48 -23   

jakarta-commons/dbutils/src/java/org/apache/commons/dbutils/BasicRowProcessor.java
   
   Index: BasicRowProcessor.java
   ===
   RCS file:

/home/cvs/jakarta-commons/dbutils/src/java/org/apache/commons/dbutils/BasicRowProcessor.java,v
   retrieving revision 1.3
   retrieving revision 1.4
   diff -u -r1.3 -r1.4
   --- BasicRowProcessor.java  9 Nov 2003 18:52:18 -   1.3
   +++ BasicRowProcessor.java  10 Nov 2003 16:16:32 -  1.4
   @@ -85,6 +85,7 @@
 * @author Henri Yandell
 * @author Juozas Baliuka
 * @author David Graham
   + * @author Yoav Shapira
 */
public class BasicRowProcessor implements RowProcessor {

   @@ -93,17 +94,17 @@
 * is returned.  These are the same as the defaults that
 ResultSet get* 
 * methods return in the event of a NULL column.
 */
   -private static final Map primitveDefaults = new HashMap();
   +private static final Map primitiveDefaults = new HashMap();

static {
   -primitveDefaults.put(Integer.TYPE, new Integer(0));
   -primitveDefaults.put(Short.TYPE, new Short((short) 0));
   -primitveDefaults.put(Byte.TYPE, new Byte((byte) 0));
   -primitveDefaults.put(Float.TYPE, new Float(0));
   -primitveDefaults.put(Double.TYPE, new Double(0));
   -primitveDefaults.put(Long.TYPE, new Long(0));
   -primitveDefaults.put(Boolean.TYPE, Boolean.FALSE);
   -primitveDefaults.put(Character.TYPE, new
 Character('\u'));
   +primitiveDefaults.put(Integer.TYPE, new Integer(0));
   +primitiveDefaults.put(Short.TYPE, new Short((short) 0));
   +primitiveDefaults.put(Byte.TYPE, new Byte((byte) 0));
   +primitiveDefaults.put(Float.TYPE, new Float(0));
   +primitiveDefaults.put(Double.TYPE, new Double(0));
   +primitiveDefaults.put(Long.TYPE, new Long(0));
   +primitiveDefaults.put(Boolean.TYPE, Boolean.FALSE);
   +primitiveDefaults.put(Character.TYPE, new
 Character('\u'));
}

/**
   @@ -119,6 +120,8 @@

/**
 * Returns the Singleton instance of this class.
   + *
   + * @return The single instance of this class.
 */
public static BasicRowProcessor instance() {
return instance;
   @@ -135,7 +138,8 @@
 * Convert a codeResultSet/code row into an
 codeObject[]/code.
 * This implementation copies column values into the array in the
 same 
 * order they're returned from the codeResultSet/code.  Array
 elements
   - * will be set to codenull/code if the column was SQL NULL. 
   + * will be set to codenull/code if the column was SQL NULL.
   + *
 * @see
 org.apache.commons.dbutils.RowProcessor#toArray(java.sql.ResultSet)
 */
public Object[] toArray(ResultSet rs) throws SQLException {
   @@ -241,13 +245,14 @@

/**
 * Creates a new object and initializes its fields from the
 ResultSet.
   - * @param rs
   - * @param type
   - * @param props
   - * @param columnToProperty
   - * @param cols
   + *
   + * @param rs The result set
   + * @param type The bean type (the return type of the object)
   + * @param props The property descriptors
   + * @param columnToProperty The column indices in the result set
   + * @param cols The number of columns
 * @return An initialized object.
   - * @throws SQLException
   + * @throws SQLException If a database error occurs
 */
private Object createBean(
ResultSet rs,
   @@ -271,7 +276,7 @@
Class propType = prop.getPropertyType();

if (propType != null  value == null 
 propType.isPrimitive()) {
   -value = primitveDefaults.get(propType);
   +value = primitiveDefaults.get(propType);
}

this.callSetter(bean, prop, value);
   @@ -286,10 +291,12 @@
 * for the bean property that matches the column name.  If no
 bean property
 * was found for a column, the position is set to
 PROPERTY_NOT_FOUND.
 * 
   + * @param rsmd The result set meta data containing column
 information
   + * @param props The bean property descriptors
 * @return An int[] with column index to property index mappings.
  The 0th 
 * element is meaningless as column indexing starts at 1.
 * 
   - * 

cvs commit: jakarta-commons/dbutils/xdocs index.xml

2003-11-10 Thread yoavs
yoavs   2003/11/10 08:47:30

  Modified:dbutils/xdocs index.xml
  Log:
  Removed basic example and added link to examples.
  
  Revision  ChangesPath
  1.3   +1 -40 jakarta-commons/dbutils/xdocs/index.xml
  
  Index: index.xml
  ===
  RCS file: /home/cvs/jakarta-commons/dbutils/xdocs/index.xml,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- index.xml 5 Nov 2003 04:52:42 -   1.2
  +++ index.xml 10 Nov 2003 16:47:30 -  1.3
  @@ -86,47 +86,8 @@
   
   section name=Example Usage
   p
  -The core classes/interfaces in DbUtils are 
  -codea 
href=apidocs/org/apache/commons/dbutils/QueryRunner.htmlQueryRunner/a/code
  -and
  -codea 
href=apidocs/org/apache/commons/dbutils/ResultSetHandler.htmlResultSetHandler/a/code.
  -The following example demonstrates how these classes are used together.
  +Please see a href=examples.htmlExamples Page/a.
   /p
  -
  -pre
  -DataSource ds = // somehow get DataSource;
  -
  -// Step 1.
  -QueryRunner run = new QueryRunner(ds);
  -
  -// Step 2.
  -ResultSetHandler h = new BeanHandler(Person.class);
  -
  -// Step 3.
  -Person p = (Person) run.query(SELECT * FROM Person WHERE name=?, John Doe, h); 
  -
  -/pre
  -
  -pExplanation/p
  -ol
  -li
  -Configure QueryRunner with the DataSource.
  -Note that QueryRunner has methods that take a 
  -java.sql.Connection so you are not required to
  -use DataSources.
  -/li
  -li
  -Implement the ResultSetHandler interface or use
  -one of the provided implementations.  This one converts a 
  -ResultSet row into a bean.
  -/li
  -li
  -Execute the SQL statement with one replacement parameter and
  -return the results in a new Person object (generated by the handler
  -in step 2).
  -/li
  -/ol
  -
   /section
   
   section name=Interaction With Other Packages
  
  
  

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



RE: OT: Re: [ANN] hivemind has been temporarily taken offline

2003-11-10 Thread Noel J. Bergman
Vic Cekvenich wrote:
 Noel J. Bergman wrote:
  The Geronimo developers represent that the code
  contributed for Geronimo does not contain any code
  belonging to JBoss.

 I just wanted to underline above.

Every Apache Committer represents that they own the right to contribute
their code to the ASF.  That is not unique to Geronimo.  In Howard's case,
he did so in good faith, and then discovered otherwise, which resulted in
HiveMind being removed pending resolution.

Are you claiming that the Geromino developers are falsely representing their
rights and the origin of the code?  Is it your claim that they are violating
their CLA?

Speak plainly, if you've a claim to make.

--- Noel


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



Re: [DbUtils] Commit flag on QueryRunner

2003-11-10 Thread David Graham

--- Shapira, Yoav [EMAIL PROTECTED] wrote:
 
 Hi,
 I have a request from a coworker who uses DbUtils to add a flag to turn
 of auto-commit in the QueryRunner.  The text of his request is below.
 What do you think, is it too big to get into DbUtils 1.0?
 
 There needs to be an option on QueryRunner to turn off the commit()
 calls on the updates that use a datasource.  I would like to use it to
 build DAOs which will be used in the context of the JTA.  This might be
 through either EJB beans or more directly using UserTransaction.  The
 presence of the commit calls setAutoCommit, commit, rollback) in the
 update methods that use a datasource make this impossible with those
 methods.  What I would like to do is instantiate a QueryRunner with a
 flag to turn this off.

The methods using a DataSource were designed to execute in a single
transaction.  If you disabled the commit and rollback in these methods,
how would you handle the transactions manually without access to the
Connection?

If you want to control Connections with commit and rollback you can just
use the update() methods that take a Connection as the first argument.

David

 
 Yoav Shapira
 Millennium ChemInformatics
 
 
 
 
 
 This e-mail, including any attachments, is a confidential business
 communication, and may contain information that is confidential,
 proprietary and/or privileged.  This e-mail is intended only for the
 individual(s) to whom it is addressed, and may not be saved, copied,
 printed, disclosed or used by anyone else.  If you are not the(an)
 intended recipient, please immediately delete this e-mail from your
 computer system and notify the sender.  Thank you.
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 


__
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree

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



[HiveMind] Is interceptor creation on threaded model unnecceseraly slow?

2003-11-10 Thread Christian Essl
For the threaded model as I see interceptors are created for each core- 
impl. Wouldn't it be enough that interceptors wrap the proxy. This would 
certainly be more performant. Or maybe have interceptors under order lets 
say 1000 wrap the core-impl (and be created each time) and others wrap the 
proxy?

It think it should also be commented that InterceptorFactories should cache 
their interceptor-classes by service-id (as AbstractInterceptorFactory 
does). Otherwise you may have a memory leak. As I see the referenced 
example on how an InterceptorFactory uses config elements 
(hivemind.test.services.impl.FilterLoggingInterceptor) does not do that.



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


RE: [codec] Streamable Codec Framework

2003-11-10 Thread Gary Gregory
Yes, no problem, 1.2.2.

Gary

 -Original Message-
 From: Tim O'Brien [mailto:[EMAIL PROTECTED]
 Sent: Monday, November 10, 2003 08:10
 To: Jakarta Commons Developers List
 Subject: RE: [codec] Streamable Codec Framework
 
 Oleg, this is understood - 1.2.2 should be our LCD for codec.
 
 Tim
 
 
 On Mon, 10 Nov 2003 [EMAIL PROTECTED] wrote:
 
  Tim, Gary, et al
  Streamable codec framework would be a welcome addition to Commons Codec.
  However, as far as we (Commons HttpClient) are concerned, the decision
 to
  ditch java 1.2.2 support would render Codec unusable for us (and I'd
 guess
  a few other projects that still need to maintain java 1.2.2
 compatibility).
  Not that we like it too much, but because lots of our users still demand
  it.
 
  We are determined to introduce Codec as a dependency for HttpClient as
 of
  next point release (currently designated as 2.1). However, I foresee a
 lot
  of popular pressure to abandon these plans in favour of retaining java
 1.2.2
  compatibility, should Codec require Java 1.3.x.
 
  Cheers
 
  Oleg
 
   Agreed, I just wanted to make make a point WRT 1.4 vs = 1.4. Now, for
  1.2.2
   vs. 1.3.1, that's a different story. It would be interesting to pool
 the
   various lists for the LCD JRE.
  
   Gary
 
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 
 
 --
 --
 Tim O'Brien
 Evanston, IL
 (847) 863-7045
 [EMAIL PROTECTED]
 
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]


Commons Validator Limitation

2003-11-10 Thread Moyer, Janet

I recently reported bug in Jakarta Commons validation
(http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24369).  I want to ask
whether this is actually a permanent limitation on the product, or is it
likely to be corrected? 

Here's the background:  I wanted to use Commons Validator for business
object validation.  Using Commons validator is great in that it allows us to
easily manage and apply sets of validation rules, and provides a consistent
way of handling validation errors.  We're pretty sure all or most of our
rules can be expressed with Validator's XML rules. So far the proof of
concept works well. 

The problem we have is in how the Validator handles exceptions.  Our rules
access databases and backend systems for data needed during validation. If a
system problem occurs, such as a database is down, our rules try to throw a
ValidatorException. Since the plugin methods are invoked by reflection, our
exceptions are wrapped in InvocationTargetExceptions. Validator.validate()
treats this as a validator error rather than a ValidatorException.  This
means all our system exceptions are treated the same as data problems.  For
example, we have a rule that validates a duplicate add of a customer
account.  The validation plugin reads a database to check whether the
account exists.  The problem is that if the database is down, the
Validator.validate() masks the exception, and tells us that the account
already exists.

Are we using the validation framework inappropriately? Should commons
validation only be used for lightweight validation such as Struts, or is
this an issue that is likely to be addressed? 

Thanks for your attention.

Regards,
Janet



CONFIDENTIALITY NOTICE: This E-Mail is intended only 
for the use of the individual or entity to which it is addressed and may contain 
information that is privileged, confidential and exempt from disclosure under 
applicable law. If you have received this communication in error, please do not 
distribute and delete the original message.  Please notify the sender by E-Mail at the 
address shown. Thank you for your compliance..



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



Re: [Chain] ContextToRequestCommand

2003-11-10 Thread Craig R. McClanahan
Quoting Jeff Caddel [EMAIL PROTECTED]:

 
 If your application uses WebContext (or one of it's subclasses) as the
 Context
 object being passed down the chain, you already have access to the request
 attributes via the getRequestScope() method.  There's also other
 Map-returning
 methods on WebContext for lots of other useful stuff (headers, cookies,
 session
 attributes, context attributes, context init parameters, ...).
 
 A.  Brain cells starting to click now.  One huge benefit of exposing 
 them as map's being that you can make use of generic bean manipulating 
 code to mess with them, right?  Instead of making API specific calls 
 like getAttribute/setAttribute.
 

That is certainly one benefit.  A second benefit is the concept of request
attributes works across both servlet and portlet environments, without tying
your application code to one or the other underying API for accessing the
request object (and the same principle applies on session and application
scope).

 
 On the attribute collections in particular, the Map implementation is
 two-way
 ... for example, usage like this:
 
   public boolean execute(Context context) throws Exception {
 ...
 WebContext wcontext = (WebContext) context;
 // Following is equivalent to request.getAttribute(foo)
 String fooValue = wcontext.getRequestScope().get(foo);
 // Following is equivalent to request.setAttribute(foo, bar)
 wcontext.getRequestScope().put(foo, bar);
 ...
   }
 
 Which is better since nothing in this implementation makes a servlet 
 specific API call.  If I needed the value bar to be present under the 
 attribute foo in a portlet environment (for example), this command 
 could be re-used.
 

Yep.

I should have noted that you can also leverage the attribute-property
transparency built in to the base Context implementation, and say:

  Map requestScope = (Map) context.get(requestScope);

without needing the explicit cast to WebContext.

 
 makes a request attribute named foo with value bar visible to a JSP page
 (or
 whatever) that will ultimately create the response.
 
 If I'm getting this right, I could also place bar into the request 
 under the attribute foo (in an API independent manner, nonetheless) by 
 simply configuring a CopyCommand:
 
 command className=org.apache.commons.chain.generic.CopyCommand 
 toKey=requestScope.foo from=foo/
 

Right now this wouldn't work -- it would put the object into the Context itself
under key requestScope.foo -- but one could certainly create a Copy command
that interpreted the keys as expressions.

 (Assuming that some other previous bit of logic had placed bar into 
 the context under the key foo.)
 
 Holy smokes...how easy is that!!
 

:-)

 
 Does this satisfy the sorts of requirements you were after?
 
 Fit's the bill quite nicely, Craig.  Thanks.
 

Craig


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



cvs commit: jakarta-commons/math/src/java/org/apache/commons/math/analysis PolynomialFunction.java CubicSplineFunction.java UnivariateRealFunction.java

2003-11-10 Thread mdiggory
mdiggory2003/11/10 09:34:03

  Modified:math/src/test/org/apache/commons/math/analysis
SinFunction.java InterpolatorTest.java
QuinticFunction.java
   math/src/java/org/apache/commons/math/analysis
CubicSplineFunction.java
UnivariateRealFunction.java
  Added:   math/src/test/org/apache/commons/math/analysis
PolynomialFunctionTest.java
   math/src/java/org/apache/commons/math/analysis
PolynomialFunction.java
  Log:
  PR: http://www.mail-archive.com/[EMAIL PROTECTED]/msg29959.html
  Submitted by: Matt Cliff
  Reviewed by:  Mark Diggory
  
  Revision  ChangesPath
  1.2   +1 -10 
jakarta-commons/math/src/test/org/apache/commons/math/analysis/SinFunction.java
  
  Index: SinFunction.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/math/src/test/org/apache/commons/math/analysis/SinFunction.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- SinFunction.java  1 Nov 2003 16:04:12 -   1.1
  +++ SinFunction.java  10 Nov 2003 17:34:03 -  1.2
  @@ -75,18 +75,9 @@
   }
   
   /* First derivative of sinus function
  - * @see org.apache.commons.math.UnivariateRealFunction#firstDerivative(double)
*/
   public double firstDerivative(double x) throws MathException {
   return Math.cos(x);
  -}
  -
  -/* Second derivative of sinus function.
  - * Unsupported.
  - * @see org.apache.commons.math.UnivariateRealFunction#secondDerivative(double)
  - */
  -public double secondDerivative(double x) throws MathException {
  -throw new UnsupportedOperationException();
   }
   
   }
  
  
  
  1.2   +41 -106   
jakarta-commons/math/src/test/org/apache/commons/math/analysis/InterpolatorTest.java
  
  Index: InterpolatorTest.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/math/src/test/org/apache/commons/math/analysis/InterpolatorTest.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- InterpolatorTest.java 1 Nov 2003 16:04:12 -   1.1
  +++ InterpolatorTest.java 10 Nov 2003 17:34:03 -  1.2
  @@ -89,31 +89,21 @@
   x=
   + x
   +  y=
  -+ f.value(x)
  -+  y'=
  -+ f.firstDerivative(x)
  -+  y''=
  -+ f.secondDerivative(x));
  ++ f.value(x));
  +
   x = 0.5;
   System.out.println(
   x=
   + x
   +  y=
  -+ f.value(x)
  -+  y'=
  -+ f.firstDerivative(x)
  -+  y''=
  -+ f.secondDerivative(x));
  ++ f.value(x));
  +
   x = 1 - 1E-6;
   System.out.println(
   x=
   + x
   +  y=
  -+ f.value(x)
  -+  y'=
  -+ f.firstDerivative(x)
  -+  y''=
  -+ f.secondDerivative(x));
  ++ f.value(x));
   }
   
   public void testInterpolateLinearDegenerateThreeSegment()
  @@ -129,61 +119,43 @@
   x=
   + x
   +  y=
  -+ f.value(x)
  -+  y'=
  -+ f.firstDerivative(x)
  -+  y''=
  -+ f.secondDerivative(x));
  ++ f.value(x));
  +
   x = 0.5 - 1E-6;
   System.out.println(
   x=
   + x
   +  y=
  -+ f.value(x)
  -+  y'=
  -+ f.firstDerivative(x)
  -+  y''=
  -+ f.secondDerivative(x));
  ++ f.value(x));
  +
   x = 0.5;
   System.out.println(
   x=
   + x
   +  y=
  -+ f.value(x)
  -+  y'=
  -+ f.firstDerivative(x)
  -+  y''=
  -+ f.secondDerivative(x));
  ++ f.value(x));
  +
   x = 1 - 1E-6;
   System.out.println(
   x=
   + x
   +  y=
  -+ f.value(x)
  -+  y'=
  -+ f.firstDerivative(x)
  -+  y''=
  -+ f.secondDerivative(x));
  ++ f.value(x));
  +
   x = 1;
   System.out.println(
   x=
   + x
   +  y=
  -+ f.value(x)
  -+  y'=
  -+ f.firstDerivative(x)
  -+  y''=
  -+ 

Re: Commons Validator Limitation

2003-11-10 Thread David Graham
FYI, when posting to commons-dev or commons-user you should prefix the
subject line with the component name like [validator].  This allows people
to filter out messages for components they're not interested in.

David

--- Moyer, Janet [EMAIL PROTECTED] wrote:
 
 I recently reported bug in Jakarta Commons validation
 (http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24369).  I want to
 ask
 whether this is actually a permanent limitation on the product, or is it
 likely to be corrected? 
 
 Here's the background:  I wanted to use Commons Validator for business
 object validation.  Using Commons validator is great in that it allows
 us to
 easily manage and apply sets of validation rules, and provides a
 consistent
 way of handling validation errors.  We're pretty sure all or most of our
 rules can be expressed with Validator's XML rules. So far the proof of
 concept works well. 
 
 The problem we have is in how the Validator handles exceptions.  Our
 rules
 access databases and backend systems for data needed during validation.
 If a
 system problem occurs, such as a database is down, our rules try to
 throw a
 ValidatorException. Since the plugin methods are invoked by reflection,
 our
 exceptions are wrapped in InvocationTargetExceptions.
 Validator.validate()
 treats this as a validator error rather than a ValidatorException.  This
 means all our system exceptions are treated the same as data problems. 
 For
 example, we have a rule that validates a duplicate add of a customer
 account.  The validation plugin reads a database to check whether the
 account exists.  The problem is that if the database is down, the
 Validator.validate() masks the exception, and tells us that the account
 already exists.
 
 Are we using the validation framework inappropriately? Should commons
 validation only be used for lightweight validation such as Struts, or is
 this an issue that is likely to be addressed? 
 
 Thanks for your attention.
 
 Regards,
 Janet
 
 
 
 CONFIDENTIALITY NOTICE: This E-Mail is intended only 
 for the use of the individual or entity to which it is addressed and may
 contain information that is privileged, confidential and exempt from
 disclosure under applicable law. If you have received this communication
 in error, please do not distribute and delete the original message. 
 Please notify the sender by E-Mail at the address shown. Thank you for
 your compliance..
 
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 


__
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree

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



cvs commit: jakarta-commons/math/src/java/org/apache/commons/math/distribution - New directory

2003-11-10 Thread mdiggory
mdiggory2003/11/10 09:40:43

  jakarta-commons/math/src/java/org/apache/commons/math/distribution - New directory

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



cvs commit: jakarta-commons/math/src/test/org/apache/commons/math/distribution - New directory

2003-11-10 Thread mdiggory
mdiggory2003/11/10 09:43:21

  jakarta-commons/math/src/test/org/apache/commons/math/distribution - New directory

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



cvs commit: jakarta-commons/math/src/java/org/apache/commons/math/stat/univariate StorelessUnivariateStatistic.java

2003-11-10 Thread mdiggory
mdiggory2003/11/10 09:43:34

  Modified:math/src/java/org/apache/commons/math/random
EmpiricalDistribution.java
EmpiricalDistributionImpl.java
   math/src/java/org/apache/commons/math/stat
TestStatisticImpl.java TestStatistic.java
BivariateRegression.java
   math/src/test/org/apache/commons/math/stat
StatUtilsTest.java StoreUnivariateImplTest.java
MixedListUnivariateImplTest.java
CertifiedDataTest.java TestStatisticTest.java
BeanListUnivariateImplTest.java
ListUnivariateImplTest.java
   math/src/test/org/apache/commons/math/random
ValueServerTest.java RandomDataTest.java
EmpiricalDistributionTest.java
   math/src/java/org/apache/commons/math/util
TransformerMap.java DefaultTransformer.java
   math/src/test/org/apache/commons/math/util
DefaultTransformerTest.java
BeanTransformerTest.java
   math/src/java/org/apache/commons/math/stat/univariate
StorelessUnivariateStatistic.java
  Added:   math/src/java/org/apache/commons/math/stat
DescriptiveStatistics.java
AbstractStorelessDescriptiveStatistics.java
StorelessDescriptiveStatisticsImpl.java
DescriptiveStatisticsImpl.java
AbstractDescriptiveStatistics.java
   math/src/java/org/apache/commons/math/distribution
FDistribution.java DistributionFactory.java
DiscreteDistribution.java
HypergeometricDistribution.java
ContinuousDistribution.java package.html
AbstractDiscreteDistribution.java
TDistributionImpl.java
HypergeometricDistributionImpl.java
ChiSquaredDistributionImpl.java
BinomialDistributionImpl.java
BinomialDistribution.java FDistributionImpl.java
DistributionFactoryImpl.java
ExponentialDistribution.java TDistribution.java
ExponentialDistributionImpl.java
GammaDistributionImpl.java
AbstractContinuousDistribution.java
GammaDistribution.java ChiSquaredDistribution.java
   math/src/test/org/apache/commons/math/stat
DescriptiveStatisticsFuture.java
DescriptiveStatisticsTest.java
ListUnivariateImpl.java BeanListUnivariateImpl.java
   math/src/test/org/apache/commons/math/distribution
TDistributionTest.java
DistributionFactoryImplTest.java
BinomialDistributionTest.java
GammaDistributionTest.java
ExponentialDistributionTest.java
HypergeometricDistributionTest.java
FDistributionTest.java
ChiSquareDistributionTest.java
   math/src/test/org/apache/commons/math/util
BeanTransformer.java
   math/src/test/org/apache/commons/math/stat/univariate
UnivariateImplTest.java
  Removed: math/src/test/org/apache/commons/math/stat/distribution
DistributionFactoryImplTest.java
GammaDistributionTest.java TDistributionTest.java
ExponentialDistributionTest.java
BinomialDistributionTest.java
ChiSquareDistributionTest.java
FDistributionTest.java
HypergeometricDistributionTest.java
   math/src/java/org/apache/commons/math/stat
UnivariateImpl.java AbstractStoreUnivariate.java
Univariate.java Applyable.java
ListUnivariateImpl.java BeanListUnivariateImpl.java
StoreUnivariate.java AbstractUnivariate.java
StoreUnivariateImpl.java
   math/src/test/org/apache/commons/math/stat
UnivariateImplTest.java
   math/src/java/org/apache/commons/math/stat/distribution
AbstractContinuousDistribution.java
BinomialDistribution.java
HypergeometricDistributionImpl.java
TDistributionImpl.java ContinuousDistribution.java
FDistribution.java 

[DbUtils] Commit flag on QueryRunner

2003-11-10 Thread Shapira, Yoav

Hi,
I'll forward to the list -- let's continue the discussion there ;)

Yoav Shapira
Millennium ChemInformatics


-Original Message-
From: Robinson, Jim
Sent: Monday, November 10, 2003 12:46 PM
To: Shapira, Yoav
Subject: RE: [DbUtils] Commit flag on QueryRunner

Yoav, I will subscribe.  I clicked a link for the mailing list on the
site
and it was dead, I will try again.

I'm not sure David understands how the container managed transactions
or
the JTA works.  When using either of these you don't want to manage
commit
at the connection level, this largely defeats there purpose.  In the
case
of container managed transactions (EJB bean) the container makes the
commit() calls when exiting the method demarcating the transaction.  If
a
runtime (uncaught) exception occurs the container rolls back the
transaction.  The user can also control this but that's usually not
recommended.

In the case of the JTA. The user starts a transaction and ends it
explicitly, but in between many updates might be performed.  (This only
works with a transaction data source where connections are wrapped and
closing simply makes them available again).

I realize that I can do this by using the method that passes in the
connection but this is ugly and really shouldn't be necessary.  This
package would be much more useful to EJB  JTA developers if the
commits,
etc, could be turned off.  As it is it assumes that either (1) the user
will manage the transaction by explicitly managing connections, or (2)
a
transaction will not span multiple updates.

To answer David's question explicitly ...

 If you disabled the commit and rollback in these methods,
how would you handle the transactions manually without access to the
Connection?..

The answer is you don't need to.  The container will do that for you
when
the transaction ends, assuming you are using the container managed
Datasource of course.

If I haven't explained this very very well come on down, I can do a
better
job at the whiteboard.




This e-mail, including any attachments, is a confidential business communication, and 
may contain information that is confidential, proprietary and/or privileged.  This 
e-mail is intended only for the individual(s) to whom it is addressed, and may not be 
saved, copied, printed, disclosed or used by anyone else.  If you are not the(an) 
intended recipient, please immediately delete this e-mail from your computer system 
and notify the sender.  Thank you.


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



DO NOT REPLY [Bug 24369] - Validator.validate() exception handling for ValidatorException

2003-11-10 Thread bugzilla
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=24369.
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=24369

Validator.validate() exception handling for ValidatorException





--- Additional Comments From [EMAIL PROTECTED]  2003-11-10 17:56 ---
Validator.getIndexedProperty() looks like the only method that generates 
ValidatorExceptions.  Validator.executeValidationMethod() catches Exception; if 
it's a ValidatorException it rethrows it, else it returns false.

Maybe this is a problem that was fixed after 1.0.2.  You could try a nightly 
build to see if that fixes it.

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



cvs commit: jakarta-commons/math/src/test/org/apache/commons/math/stat DescriptiveStatisticsTest.java DescriptiveStatisticsFuture.java

2003-11-10 Thread mdiggory
mdiggory2003/11/10 10:00:25

  Modified:math/src/test/org/apache/commons/math/stat
DescriptiveStatisticsTest.java
  Removed: math/src/test/org/apache/commons/math/stat
DescriptiveStatisticsFuture.java
  Log:
  Refactoring Error on my part, this class should not have been added and the Test 
shouldn't have used it.
  
  Revision  ChangesPath
  1.2   +13 -10
jakarta-commons/math/src/test/org/apache/commons/math/stat/DescriptiveStatisticsTest.java
  
  Index: DescriptiveStatisticsTest.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/math/src/test/org/apache/commons/math/stat/DescriptiveStatisticsTest.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- DescriptiveStatisticsTest.java10 Nov 2003 17:43:31 -  1.1
  +++ DescriptiveStatisticsTest.java10 Nov 2003 18:00:25 -  1.2
  @@ -80,7 +80,7 @@
   private double max = 3;
   private double skewness = 0;
   private double kurtosis = 0.5;
  -private int kClass = DescriptiveStatisticsFuture.LEPTOKURTIC;
  +private int kClass = DescriptiveStatistics.LEPTOKURTIC;
   private double tolerance = 10E-15;
   
   public DescriptiveStatisticsTest(String name) {
  @@ -98,7 +98,7 @@
   
   /** test stats */
   public void testStats() {
  -DescriptiveStatisticsFuture u = new DescriptiveStatisticsFuture(); 
  +DescriptiveStatistics u = DescriptiveStatistics.newInstance(); 
   assertEquals(total count,0,u.getN(),tolerance);
   u.addValue(one);
   u.addValue(two);
  @@ -117,7 +117,7 @@
   } 
   
   public void testN0andN1Conditions() throws Exception {
  - DescriptiveStatisticsFuture u = new DescriptiveStatisticsFuture();
  + DescriptiveStatistics u = DescriptiveStatistics.newInstance();

   assertTrue(Mean of n = 0 set should be NaN, 
   Double.isNaN( u.getMean() ) );
  @@ -137,7 +137,7 @@
   }
   
   public void testSkewAndKurtosis() {
  - DescriptiveStatisticsFuture u = new DescriptiveStatisticsFuture();
  + DescriptiveStatistics u = DescriptiveStatistics.newInstance();

double[] testArray = 
   { 12.5, 12, 11.8, 14.2, 14.9, 14.5, 21, 8.2, 10.3, 11.3, 14.1,
  @@ -153,8 +153,8 @@
   }
   
   public void testProductAndGeometricMean() throws Exception {
  - DescriptiveStatisticsFuture u = new DescriptiveStatisticsFuture(10);
  -//u.setWindow(10);
  + DescriptiveStatistics u = DescriptiveStatistics.newInstance();
  +u.setWindowSize(10);

   u.addValue( 1.0 );
   u.addValue( 2.0 );
  @@ -183,7 +183,8 @@
double[] test1 = {5,4,3,2,1,0};
double[] test2 = {5,2,1,0,4,3};
   
  - DescriptiveStatisticsFuture stats = new 
DescriptiveStatisticsFuture(12);
  + DescriptiveStatistics stats = DescriptiveStatistics.newInstance();
  + stats.setWindowSize(12);

for(int i = 0; i  test1.length; i++){
stats.addValue(test1[i]);
  @@ -260,7 +261,8 @@
   
   
   private void tstGetSortedValues(double[] test) {
  -DescriptiveStatisticsFuture u = new 
DescriptiveStatisticsFuture(test.length);
  +DescriptiveStatistics u = DescriptiveStatistics.newInstance();
  +u.setWindowSize(test.length);
   for (int i = 0; i  test.length; i++) {
   u.addValue(test[i]);
   }
  @@ -277,7 +279,8 @@
   
   public void testPercentiles() {
   double[] test = {5,4,3,2,1};
  -DescriptiveStatisticsFuture u = new DescriptiveStatisticsFuture(110);
  +DescriptiveStatistics u = DescriptiveStatistics.newInstance();
  +u.setWindowSize(110);
   for (int i = 0; i  test.length; i++) {
   u.addValue(test[i]);
   }
  
  
  

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



DO NOT REPLY [Bug 24369] - Validator.validate() exception handling for ValidatorException

2003-11-10 Thread bugzilla
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=24369.
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=24369

Validator.validate() exception handling for ValidatorException





--- Additional Comments From [EMAIL PROTECTED]  2003-11-10 18:08 ---
I include below a portion of Janet Moyer's message which I consider essential 
for this discussion.  The core of the issue is not the masking of 
ValidatorExceptions raised by the validation framework, but whether or not 
ValidatorExceptions ought to be raised by the validation rule implementations 
themselves.  

Janet's requirements is that some means of notification regarding system level 
errors (not invalid data - currently handled in a usable fashion by the 
framework - but inability to validate the data - currently masked as 
equivalent to invalid data) is required.  A reasonable means of doing this 
seems to be for validation rule implementations to throw ValidatorException.  
However, because the rule methods are invoked using reflection, these 
exceptions are wrapped into InvocationTargetException.  The framework 
currently makes no effort to unwrap these exceptions and examine them to 
determine whether or not they are ValidatorExceptions.  (The catch clause 
David points out should do this, if it is to be done.)  

Assuming this is appropriate behaviour, I'll attach a patch shortly.  

-Original Message-
From: Moyer, Janet [mailto:[EMAIL PROTECTED] 
Sent: Monday, November 10, 2003 9:05 AM
To: '[EMAIL PROTECTED]'
Subject: Commons Validator Limitation

SNIP /

The problem we have is in how the Validator handles exceptions.  Our rules 
access databases and backend systems for data needed during validation. If a 
system problem occurs, such as a database is down, our rules try to throw a 
ValidatorException. Since the plugin methods are invoked by reflection, our 
exceptions are wrapped in InvocationTargetExceptions. Validator.validate() 
treats this as a validator error rather than a ValidatorException.  This means 
all our system exceptions are treated the same as data problems.  For example, 
we have a rule that validates a duplicate add of a customer account.  The 
validation plugin reads a database to check whether the account exists.  The 
problem is that if the database is down, the Validator.validate() masks the 
exception, and tells us that the account already exists.

SNIP /

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



Re: [DbUtils] Commit flag on QueryRunner

2003-11-10 Thread David Graham

--- Shapira, Yoav [EMAIL PROTECTED] wrote:
 
 Hi,
 I'll forward to the list -- let's continue the discussion there ;)
 
 Yoav Shapira
 Millennium ChemInformatics
 
 
 -Original Message-
 From: Robinson, Jim
 Sent: Monday, November 10, 2003 12:46 PM
 To: Shapira, Yoav
 Subject: RE: [DbUtils] Commit flag on QueryRunner
 
 Yoav, I will subscribe.  I clicked a link for the mailing list on the
 site
 and it was dead, I will try again.
 
 I'm not sure David understands how the container managed transactions
 or
 the JTA works.  When using either of these you don't want to manage
 commit
 at the connection level, this largely defeats there purpose.  In the
 case
 of container managed transactions (EJB bean) the container makes the
 commit() calls when exiting the method demarcating the transaction.  If
 a
 runtime (uncaught) exception occurs the container rolls back the
 transaction.  The user can also control this but that's usually not
 recommended.

You're right, I've never used EJB or JTA so this information is helpful. 
How would the update() method look for JTA use?  

Obviously, QueryRunner isn't currently designed for this use case.  One
reason we changed these methods to normal members instead of statics is to
allow subclasses to override their behavior.  Wouldn't it be trivial to
create a JTA enabled QueryRunner subclass that just overrides the update()
method for your purposes?  

I'm not a big fan of flags changing class behavior like the proposed
solution because it leads to messy if/else statements.

David 

 
 In the case of the JTA. The user starts a transaction and ends it
 explicitly, but in between many updates might be performed.  (This only
 works with a transaction data source where connections are wrapped and
 closing simply makes them available again).
 
 I realize that I can do this by using the method that passes in the
 connection but this is ugly and really shouldn't be necessary.  This
 package would be much more useful to EJB  JTA developers if the
 commits,
 etc, could be turned off.  As it is it assumes that either (1) the user
 will manage the transaction by explicitly managing connections, or (2)
 a
 transaction will not span multiple updates.
 
 To answer David's question explicitly ...
 
  If you disabled the commit and rollback in these methods,
 how would you handle the transactions manually without access to the
 Connection?..
 
 The answer is you don't need to.  The container will do that for you
 when
 the transaction ends, assuming you are using the container managed
 Datasource of course.
 
 If I haven't explained this very very well come on down, I can do a
 better
 job at the whiteboard.


__
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree

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



RE: [DbUtils] Commit flag on QueryRunner

2003-11-10 Thread Robinson, Jim

David, I agree with you regarding flags.  This is a very nice package, I
didn't mean to be critical.

I've only used EJBs and JTA, I've not been a developer so I may have
some details wrong.  Others on this list can no doubt correct me.  To
use either of these you need a transactionally aware data source.  I use
JBoss which includes such a datasource.  All EJB containers provide one.
For Tomcat I think you can use Tyrex, never tried.

At any rate transactional aspects of connections (commit, rollback) are
managed by the container.  A transaction is started either upon entry of
a demarcated EJB method (container managed transaction) or by explicit
use of the UserTransaction interface
(http://java.sun.com/products/jta/javadocs-1.0.1/javax/transaction/UserT
ransaction.html). In the latter case you do something like

userTransaction.begin();

The transaction is completed upon exit of the demarcated EJB method
(container managed) or, if doing explicity transactions, by something
like

userTransaction.commit()   or   userTransaction.rollback()

Any database updates performed in between these events are associated
with the transaction and will be committed or rolled back together.  You
can, and often do, make many calls to datasource.getConnection() and
connection.close() in between.  So you have decoupled the connection
management from transaction management.  This is a very nice model to
work with, especially the container managed version.  In that case there
is no explicit transaction management in the code and you can rearrange,
split, group transactions with ease.  The explicit version
(UserTransaction) is slightly less nice because the explicity boundaries
are in the code, but still much more flexible than doing it at an
individual connection/update level.

So how does this work since ultimately it is done at the jdbc connection
level?  Well, as I said I have not worked on implementation of
containers.  I have however worked on emulations of them for development
test frameworks.  One way to accomplish this is to keep a map of
connections in your DataSource implementation with the thread as the
key.  When a transaction is started you get a connection from the pool
and store it in the map.  When the transaction ends you remove the
thread key from the map.  In between getConnection() looks in the map
for a connection and if it finds one that is returned.  I've left out
some details and real Containers are surely more sophisticated, but that
is a possible implementation.

Of course none of this works if you do explict calls to setAutoCommit,
commit, rollback, etc.  In fact, you will get an exception if using some
of these methods with a transactionally aware datasource if within a
managed transaction.

Hopefully I've not mangled this explanation beyond comprehension. If I
have perhaps someone could clarify.  Basically you cannot hijack
container managed transactions by doing explict commits.  Removing the
calls to commit, rollback, and setAutocommit would make the update
methods perfectly compatible with either EJB managed transactions or
UserTransaction.  If you can figure out a way to get this it would be
very helpful to those of use using containers for transactions.  In the
meantime I will probably try to subclass QueryRunner and override the
update methods.

Regards,

Jim




You're right, I've never used EJB or JTA so this information is
helpful.
How would the update() method look for JTA use?

Obviously, QueryRunner isn't currently designed for this use case.  One
reason we changed these methods to normal members instead of statics is
to
allow subclasses to override their behavior.  Wouldn't it be trivial to
create a JTA enabled QueryRunner subclass that just overrides the
update()
method for your purposes?

I'm not a big fan of flags changing class behavior like the proposed
solution because it leads to messy if/else statements.

David





This e-mail, including any attachments, is a confidential business communication, and 
may contain information that is confidential, proprietary and/or privileged.  This 
e-mail is intended only for the individual(s) to whom it is addressed, and may not be 
saved, copied, printed, disclosed or used by anyone else.  If you are not the(an) 
intended recipient, please immediately delete this e-mail from your computer system 
and notify the sender.  Thank you.


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



Re: [validator] EmailTest failing

2003-11-10 Thread Peter Courcoux
Rob,

Thanks for the reply.

I'll have to look up RFC822...

Regards,

Peter

On Mon, 2003-11-10 at 04:27, Robert Leland wrote:
 Peter Courcoux wrote:
 
 Hi all,
 
 I did a fresh checkout of validator this evening and the EmailTest
 failed. 
 
 Your correct, those tests were added as a reminder to review the 
 RFC822.txt and handle cases of specialized
 characters in the users name. Most of the time the character string 
 needs to be commented. Unfortunately, I have not
 had time lately to go back and added this to the regular expressions.
 
 I'll look into this myself when I have a moment. However, I
   
 
 Patches or code review is always welcome !
 
 thought I'd ask if this is a known issue? I didn't see anything in the
 archives.
 
 Regards,
   
 
 -Rob
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
-- 
Peter Courcoux [EMAIL PROTECTED]

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



RE: [betwixt] Betwixt troubles...

2003-11-10 Thread Mike Stanley
here is a zipped up eclipse project (minus the jar dependencies).  There is
a unit test that demonstrates the bug that I'm talking about.  The unit test
has to test methods, testGetAsXml which passes, and testParseMsg which
fails.

Aside from the betwixt dependencies, this project is also dependent on
log4j, and commons-lang.  Hope this provides a decent enough demo of the
bugs.

Note: I've tried this with the alpha release of betwixt, as well as the
snapshot from 2/11/2003.  When using the snapshot, the testGetAsXml fails
with a null pointer exception.  The alpha release shows the
marshalling/unmarshalling behavior noted in this thread.  I also tried
variations on the parser configurations.

Thanks for the help.
- Mike

 -Original Message-
 From: Martin van den Bemt [mailto:[EMAIL PROTECTED]
 Sent: Sunday, November 09, 2003 12:14 PM
 To: Jakarta Commons Developers List
 Subject: RE: Betwixt troubles...


 Can you supply us with a tescase that shows us the bahaviour (esp that
 you believe it is a bug), since there is too little info in the mail to
 test this (we needs the beans / bean. One thing I know is that eg
 Bean.betwixt files only supplies beaninfo for Bean.java and not for any
 classes embedded in Bean.java.

 Mvgr,
 Martin

 On Fri, 2003-11-07 at 19:51, Mike Stanley wrote:
  Please note: I sent this to the developers list and not the users list,
  because I believe it to be a bug, and if confirmed - I may patch it.
 
  - Mike
 
   -Original Message-
   From: Mike Stanley [mailto:[EMAIL PROTECTED]
   Sent: Friday, November 07, 2003 1:26 PM
   To: Jakarta Commons Dev
   Subject: Betwixt troubles...
  
  
   Hey everyone,
  
   I'm running into an issue with some Betwixt code.  I'm trying to
   Write/Read
   a bean associated with .betwixt file.
  
   I can't seem to get attributes to be set when reading in the
 xml.  writing
   works fine.  I've tried several ways (including defaulting to
   primitiveTypes
   and specificing an updater method).  Here is the content of the file:
  
   ?xml version=1.0 encoding=UTF-8?
   info primitiveTypes=attribute
   element name=rcss
   attribute property=type/
   element name=requests
   element name=isValid
   element name=agent-id
   attribute name=value property=agentId/
   /element
   !-- element name=agent-id property=agentId
   updater=setAgentId/ --
   /element
   /element
   /element
   /info
  
   
   Results form a write:
  
   ?xml version='1.0' ?
   rcss type=request src=167.154.203.22 requestor=install_app
   requests
   isValid cert=Z0123456789
   agent-id value=01/
   /isValid
   /requests
   /rcss
  
   ---
   Results from read:
  
   ?xml version='1.0' ?
   rcss type=request src=167.154.203.22 requestor=install_app
   requests
   isValid
   agent-id/
   /isValid
   /requests
   /rcss
  
   ---
   What is going wrong?  What can I do to fix this problem?
 modifying the
   format of the XML is not an option.  Also note - using the
 Commented out
   element in the betwixt file instead of specifically specifying the
   attribute, results in agent-id01/agent-id which isn't
 correct either.
  
   Thanks for your help.
   - Mike
  
 
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 --
 Martin van den Bemt [EMAIL PROTECTED]
 mvdb.com


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



BetwixtTest.zip
Description: Zip compressed data
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 24369] - Validator.validate() exception handling for ValidatorException

2003-11-10 Thread bugzilla
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=24369.
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=24369

Validator.validate() exception handling for ValidatorException





--- Additional Comments From [EMAIL PROTECTED]  2003-11-10 19:11 ---
Well,  I'm about to attach two patches.  The first is for the test cases, to 
generate exceptions during the test process.  The second, of course, is for 
the source, to properly handle those exceptions.  

The assumptions I made:
1) Validator.validate SHOULD ONLY return false if the data proved to be 
invalid, not if there was an exception in the process of validating the data.
2) Runtime exceptions are propagated as is.  
3) ValidatorExceptions are propagated as is.
4) Other checked exceptions are transformed to ValidatorExceptions

I wasn't able to remove instanceof checks completely - I have to use them when 
examining the TargetException wrapped by the InvocationTargetException.  

Take a look

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



DO NOT REPLY [Bug 24369] - Validator.validate() exception handling for ValidatorException

2003-11-10 Thread bugzilla
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=24369.
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=24369

Validator.validate() exception handling for ValidatorException





--- Additional Comments From [EMAIL PROTECTED]  2003-11-10 19:12 ---
Created an attachment (id=9030)
Testcase to generate exceptions during validation and check handling

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



DO NOT REPLY [Bug 24369] - Validator.validate() exception handling for ValidatorException

2003-11-10 Thread bugzilla
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=24369.
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=24369

Validator.validate() exception handling for ValidatorException





--- Additional Comments From [EMAIL PROTECTED]  2003-11-10 19:12 ---
Created an attachment (id=9031)
Code change to handle exceptions generated during validation

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



Re: [DbUtils] Commit flag on QueryRunner

2003-11-10 Thread Juozas Baliuka

Hi,
I do not think Commit flag is a good idea.
It must be better to remove transaction demarcation code form QueryRunner.

The best known way is to map connection to Thread (java.langThreadLocal),
JTA uses this way too.

ThreadLocal localConnections = new ThreadLocal();

 public Connection QueryRunner.currentConnection() throws SQLException  {

Connection c = (Connection)localConnections.get();
if( c == null ){
c = ds.getConnection();
localConnections.set();
  }
return c;

 }

More transparent way is to use Datasource decorator to return ThreadLocal
connections.

It is usefull in container and in standalone application.

I use this way for stanalone web and JMS applications, transactions are
managed by command or
message dispatcher.

More abstract way to wrapp connection in Transaction:

 void dispatch( Message msg ) throws Exception{

try{

  Transaction tx = txManager.currentTransaction();

  Handler h = findHandler(msg.getParameter(HANDLER_NAME));

  tx.begin();

  h.handleMessage(msg);

  tx.commit();

}finally{
   tx.rollback();
}

 }



 --- Shapira, Yoav [EMAIL PROTECTED] wrote:
 
  Hi,
  I'll forward to the list -- let's continue the discussion there ;)
 
  Yoav Shapira
  Millennium ChemInformatics
 
 
  -Original Message-
  From: Robinson, Jim
  Sent: Monday, November 10, 2003 12:46 PM
  To: Shapira, Yoav
  Subject: RE: [DbUtils] Commit flag on QueryRunner
  
  Yoav, I will subscribe.  I clicked a link for the mailing list on the
  site
  and it was dead, I will try again.
  
  I'm not sure David understands how the container managed transactions
  or
  the JTA works.  When using either of these you don't want to manage
  commit
  at the connection level, this largely defeats there purpose.  In the
  case
  of container managed transactions (EJB bean) the container makes the
  commit() calls when exiting the method demarcating the transaction.  If
  a
  runtime (uncaught) exception occurs the container rolls back the
  transaction.  The user can also control this but that's usually not
  recommended.

 You're right, I've never used EJB or JTA so this information is helpful.
 How would the update() method look for JTA use?

 Obviously, QueryRunner isn't currently designed for this use case.  One
 reason we changed these methods to normal members instead of statics is to
 allow subclasses to override their behavior.  Wouldn't it be trivial to
 create a JTA enabled QueryRunner subclass that just overrides the update()
 method for your purposes?

 I'm not a big fan of flags changing class behavior like the proposed
 solution because it leads to messy if/else statements.

 David

  
  In the case of the JTA. The user starts a transaction and ends it
  explicitly, but in between many updates might be performed.  (This only
  works with a transaction data source where connections are wrapped and
  closing simply makes them available again).
  
  I realize that I can do this by using the method that passes in the
  connection but this is ugly and really shouldn't be necessary.  This
  package would be much more useful to EJB  JTA developers if the
  commits,
  etc, could be turned off.  As it is it assumes that either (1) the user
  will manage the transaction by explicitly managing connections, or (2)
  a
  transaction will not span multiple updates.
  
  To answer David's question explicitly ...
  
   If you disabled the commit and rollback in these methods,
  how would you handle the transactions manually without access to the
  Connection?..
  
  The answer is you don't need to.  The container will do that for you
  when
  the transaction ends, assuming you are using the container managed
  Datasource of course.
  
  If I haven't explained this very very well come on down, I can do a
  better
  job at the whiteboard.


 __
 Do you Yahoo!?
 Protect your identity with Yahoo! Mail AddressGuard
 http://antispam.yahoo.com/whatsnewfree

 -
 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]



R: [VOTE] Release DbUtils 1.0

2003-11-10 Thread Angelo Guido
+1

Angelo


-Messaggio originale-
Da: David Graham [mailto:[EMAIL PROTECTED]
Inviato: domenica 9 novembre 2003 21.25
A: [EMAIL PROTECTED]
Oggetto: [VOTE] Release DbUtils 1.0


DbUtils is a stable, well tested package suitable for a 1.0 release.  The
release candidate is available here:

http://jakarta.apache.org/~dgraham/dbutils-1.0-rc1/

Here's my +1.

David

-



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



DO NOT REPLY [Bug 24369] - Validator.validate() exception handling for ValidatorException

2003-11-10 Thread bugzilla
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=24369.
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=24369

Validator.validate() exception handling for ValidatorException





--- Additional Comments From [EMAIL PROTECTED]  2003-11-10 19:32 ---
I agree with the proposed approach but it is an incompatible behavior change.  
The problem is that Validator was initially written without much regard to 
RuntimeExceptions.  We have done much to improve the situation but there may be 
places in the code where RuntimExceptions are known to be thrown and caught by 
the generic catch Exception block to be translated as a failure.  For example, 
a piece of code was throwing NullPointerException that wasn't noticed because of 
a catch Exception block.  After discovering and fixing this, performance 
improved by 50%.  IMO, a thorough analysis of the exception situation in 
Validator is needed before making this change.

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



RE: [DbUtils] Commit flag on QueryRunner

2003-11-10 Thread David Graham

--- Robinson, Jim [EMAIL PROTECTED] wrote:
 
 David, I agree with you regarding flags.  This is a very nice package, I
 didn't mean to be critical.

I wasn't offended; we need as many people reviewing the code as possible. 
Thanks for your input.

 
 I've only used EJBs and JTA, I've not been a developer so I may have
 some details wrong.  Others on this list can no doubt correct me.  To
 use either of these you need a transactionally aware data source.  I use
 JBoss which includes such a datasource.  All EJB containers provide one.
 For Tomcat I think you can use Tyrex, never tried.
 
 At any rate transactional aspects of connections (commit, rollback) are
 managed by the container.  A transaction is started either upon entry of
 a demarcated EJB method (container managed transaction) or by explicit
 use of the UserTransaction interface
 (http://java.sun.com/products/jta/javadocs-1.0.1/javax/transaction/UserT
 ransaction.html). In the latter case you do something like
 
 userTransaction.begin();
 
 The transaction is completed upon exit of the demarcated EJB method
 (container managed) or, if doing explicity transactions, by something
 like
 
 userTransaction.commit()   or   userTransaction.rollback()
 
 Any database updates performed in between these events are associated
 with the transaction and will be committed or rolled back together.  You
 can, and often do, make many calls to datasource.getConnection() and
 connection.close() in between.  

That answered my next question :-).

 So you have decoupled the connection
 management from transaction management.  This is a very nice model to
 work with, especially the container managed version.  In that case there
 is no explicit transaction management in the code and you can rearrange,
 split, group transactions with ease.  The explicit version
 (UserTransaction) is slightly less nice because the explicity boundaries
 are in the code, but still much more flexible than doing it at an
 individual connection/update level.
 
 So how does this work since ultimately it is done at the jdbc connection
 level?  Well, as I said I have not worked on implementation of
 containers.  I have however worked on emulations of them for development
 test frameworks.  One way to accomplish this is to keep a map of
 connections in your DataSource implementation with the thread as the
 key.  When a transaction is started you get a connection from the pool
 and store it in the map.  When the transaction ends you remove the
 thread key from the map.  In between getConnection() looks in the map
 for a connection and if it finds one that is returned.  I've left out
 some details and real Containers are surely more sophisticated, but that
 is a possible implementation.
 
 Of course none of this works if you do explict calls to setAutoCommit,
 commit, rollback, etc.  In fact, you will get an exception if using some
 of these methods with a transactionally aware datasource if within a
 managed transaction.
 
 Hopefully I've not mangled this explanation beyond comprehension. If I
 have perhaps someone could clarify.  Basically you cannot hijack
 container managed transactions by doing explict commits.  Removing the
 calls to commit, rollback, and setAutocommit would make the update
 methods perfectly compatible with either EJB managed transactions or
 UserTransaction.  If you can figure out a way to get this it would be
 very helpful to those of use using containers for transactions.  In the
 meantime I will probably try to subclass QueryRunner and override the
 update methods.

So maybe the best thing to do is remove those calls.  The Connection will
have to be in auto-commit mode or you must be using something like JTA
that handles transactions.  There's nothing to rollback anyways since it's
only a single update statement executing.  If an SQLException is thrown
during the update it obviously won't be committed and there are no other
changes to rollback.

Comments?

David

 
 Regards,
 
 Jim
 
 
 
 
 You're right, I've never used EJB or JTA so this information is
 helpful.
 How would the update() method look for JTA use?
 
 Obviously, QueryRunner isn't currently designed for this use case.  One
 reason we changed these methods to normal members instead of statics is
 to
 allow subclasses to override their behavior.  Wouldn't it be trivial to
 create a JTA enabled QueryRunner subclass that just overrides the
 update()
 method for your purposes?
 
 I'm not a big fan of flags changing class behavior like the proposed
 solution because it leads to messy if/else statements.
 
 David
 


__
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree

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



RE: [VOTE] Release DbUtils 1.0

2003-11-10 Thread Steven Caswell
+1


Steven Caswell
Sun Certified Java Programmer
[EMAIL PROTECTED]
a.k.a Mungo Knotwise of Michel Delving
One ring to rule them all, one ring to find them...


 -Original Message-
 From: David Graham [mailto:[EMAIL PROTECTED] 
 Sent: Sunday, November 09, 2003 3:25 PM
 To: [EMAIL PROTECTED]
 Subject: [VOTE] Release DbUtils 1.0
 
 
 DbUtils is a stable, well tested package suitable for a 1.0 
 release.  The release candidate is available here:
 
 http://jakarta.apache.org/~dgraham/dbutils-1.0-rc1/
 
 Here's my +1.
 
 David
 
 __
 Do you Yahoo!?
 Protect your identity with Yahoo! Mail AddressGuard 
 http://antispam.yahoo.com/whatsnewfree
 
 
 -
 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: OT: Re: [ANN] hivemind has been temporarily taken offline

2003-11-10 Thread John Keyes
Vic,

You should drop the attitude as it provides no benefit to
the discussion.
A simple statement of fact would have been perfectly
acceptable.  This issue should have been raised on
the appropriate Geronimo mailing list and not in the
manner it was presented.
-John K

On 10 Nov 2003, at 20:40, Vic Cekvenich wrote:


Are you claiming that the Geromino developers are falsely 
representing their
rights and the origin of the code?  Is it your claim that they are 
violating
their CLA?
Speak plainly, if you've a claim to make.
	--- Noel


This was posted on the Server Side TODAY, I had nothing to do with it:

http://theserverside.com/home/thread.jsp?thread_id=22337

Shame on the developers that steal code!

.V



-
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: [codec] Streamable Codec Framework

2003-11-10 Thread Christopher (siege) O'Brien

Apologies, that was not intended for the entire list. But since it went
there, may as well elaborate.

The ChunkedInputStream used a call-back system to provide a data written
to the stream back in consistently-sized chunks (except for the last
data written, which would be sized appropriately). This was useful in
MD5 for obvious reasons in the streaming implementation. I factored it
into its own class because I figured it could also be used in the SHA1
implementation that was in the works, and perhaps other registers-based
hashes or checksumming codecs.

Ryan, the original ChunkedInputStream should be a part of the package I
put together for the MD5 package, as you correctly recalled. I had
posted a note at one point offering the idea up to the IO folks, but I
never got a response on that.


- siege

On Mon, 2003-11-10 at 19:12, Christopher (siege) O'Brien wrote:
 I don't have CVS access! But you do, and you should have a copy of the
 code...
 
 - siege
 
 On Mon, 2003-11-10 at 15:27, Ryan Hoegg wrote:
  IIRC, Chris O'Brien had a ChunkedInputStream for the MD5 digest code he 
  put together.  If it's not in CVS, Chris, put it there!
  
  --
  Ryan Hoegg
  ISIS Networks
  http://www.isisnetworks.net
  
  
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
-- 
Christopher (siege) O'Brien [EMAIL PROTECTED]


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



RE: [DbUtils] Commit flag on QueryRunner

2003-11-10 Thread Steven Caswell
Looks like a good solution. +1


Steven Caswell
Sun Certified Java Programmer
[EMAIL PROTECTED]
a.k.a Mungo Knotwise of Michel Delving
One ring to rule them all, one ring to find them...


 -Original Message-
 From: Robinson, Jim [mailto:[EMAIL PROTECTED] 
 Sent: Monday, November 10, 2003 3:05 PM
 To: Jakarta Commons Developers List
 Subject: RE: [DbUtils] Commit flag on QueryRunner
 
 
 
 
 
 -Original Message-
 From: David Graham [mailto:[EMAIL PROTECTED]
 Sent: Monday, November 10, 2003 2:44 PM
 To: Jakarta Commons Developers List
 Subject: RE: [DbUtils] Commit flag on QueryRunner
 
 
 --- Robinson, Jim [EMAIL PROTECTED] wrote:
 
  David, I agree with you regarding flags.  This is a very nice
 package, I
  didn't mean to be critical.
 
 I wasn't offended; we need as many people reviewing the code as
 possible.
 Thanks for your input.
 
 
  I've only used EJBs and JTA, I've not been a developer so 
 I may have 
  some details wrong.  Others on this list can no doubt 
 correct me.  To 
  use either of these you need a transactionally aware data 
 source.  I
 use
  JBoss which includes such a datasource.  All EJB containers provide
 one.
  For Tomcat I think you can use Tyrex, never tried.
 
  At any rate transactional aspects of connections (commit, rollback)
 are
  managed by the container.  A transaction is started either 
 upon entry
 of
  a demarcated EJB method (container managed transaction) or by
 explicit
  use of the UserTransaction interface
 
 (http://java.sun.com/products/jta/javadocs-1.0.1/javax/transac
 tion/UserT
  ransaction.html). In the latter case you do something like
 
  userTransaction.begin();
 
  The transaction is completed upon exit of the demarcated 
 EJB method 
  (container managed) or, if doing explicity transactions, 
 by something 
  like
 
  userTransaction.commit()   or   userTransaction.rollback()
 
  Any database updates performed in between these events are 
 associated 
  with the transaction and will be committed or rolled back together.
 You
  can, and often do, make many calls to 
 datasource.getConnection() and
  connection.close() in between.
 
 That answered my next question :-).
 
  So you have decoupled the connection
  management from transaction management.  This is a very 
 nice model to 
  work with, especially the container managed version.  In that case
 there
  is no explicit transaction management in the code and you can
 rearrange,
  split, group transactions with ease.  The explicit version
  (UserTransaction) is slightly less nice because the explicity
 boundaries
  are in the code, but still much more flexible than doing it at an 
  individual connection/update level.
 
  So how does this work since ultimately it is done at the jdbc
 connection
  level?  Well, as I said I have not worked on implementation of 
  containers.  I have however worked on emulations of them for
 development
  test frameworks.  One way to accomplish this is to keep a map of 
  connections in your DataSource implementation with the 
 thread as the 
  key.  When a transaction is started you get a connection from the
 pool
  and store it in the map.  When the transaction ends you remove the 
  thread key from the map.  In between getConnection() looks 
 in the map 
  for a connection and if it finds one that is returned.  
 I've left out 
  some details and real Containers are surely more sophisticated, but
 that
  is a possible implementation.
 
  Of course none of this works if you do explict calls to
 setAutoCommit,
  commit, rollback, etc.  In fact, you will get an exception if using
 some
  of these methods with a transactionally aware datasource 
 if within a 
  managed transaction.
 
  Hopefully I've not mangled this explanation beyond 
 comprehension. If
 I
  have perhaps someone could clarify.  Basically you cannot hijack 
  container managed transactions by doing explict commits.  Removing
 the
  calls to commit, rollback, and setAutocommit would make the update 
  methods perfectly compatible with either EJB managed 
 transactions or 
  UserTransaction.  If you can figure out a way to get this 
 it would be 
  very helpful to those of use using containers for transactions.  In
 the
  meantime I will probably try to subclass QueryRunner and 
 override the 
  update methods.
 
 So maybe the best thing to do is remove those calls.  The Connection
 will
 have to be in auto-commit mode or you must be using 
 something like JTA 
 that handles transactions.  There's nothing to rollback anyways since
 it's
 only a single update statement executing.  If an 
 SQLException is thrown 
 during the update it obviously won't be committed and there are no
 other
 changes to rollback.
 
 Comments?
 
 David
 
 
 Brilliant, I think that is the solution.  
 
 Jim
 
 
 
 
 This e-mail, including any attachments, is a confidential 
 business communication, and may contain information that is 
 confidential, proprietary and/or privileged.  This e-mail is 
 

RE: [codec] Streamable Codec Framework

2003-11-10 Thread Brett Henderson
1.2.2 it is then :-)

I agree with maintaining 1.2.2 compatibility, it
is a bit harsh to require 1.4 to perform base64 encoding.
Unfortunately it would make life a lot easier with regards
to charset encoding ...

It should be possible to use OutputStreamWriter and
InputStreamReader internally to perform the conversions
without incurring much of a performance overhead.
For example a CharByteEngine??? could use OutputStreamWriter
internally to perform charset encoding.

In many cases OutputStreamWriter and InputStreamReader
can be used directly, it is the cases where byte to char
conversion is required during output streaming that require
an encoder for transforming between chars and bytes.
Perhaps I'm missing something here though ...

I also think it would be useful to be able to perform
charset conversion without depending on streams.

 -Original Message-
 From: Gary Gregory [mailto:[EMAIL PROTECTED] 
 Sent: Tuesday, 11 November 2003 4:19 AM
 To: 'Jakarta Commons Developers List'
 Subject: RE: [codec] Streamable Codec Framework
 
 
 Yes, no problem, 1.2.2.
 
 Gary
 
  -Original Message-
  From: Tim O'Brien [mailto:[EMAIL PROTECTED]
  Sent: Monday, November 10, 2003 08:10
  To: Jakarta Commons Developers List
  Subject: RE: [codec] Streamable Codec Framework
  
  Oleg, this is understood - 1.2.2 should be our LCD for codec.
  
  Tim
  
  
  On Mon, 10 Nov 2003 [EMAIL PROTECTED] wrote:
  
   Tim, Gary, et al
   Streamable codec framework would be a welcome addition to Commons 
   Codec. However, as far as we (Commons HttpClient) are 
 concerned, the 
   decision
  to
   ditch java 1.2.2 support would render Codec unusable for 
 us (and I'd
  guess
   a few other projects that still need to maintain java 1.2.2
  compatibility).
   Not that we like it too much, but because lots of our users still 
   demand it.
  


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



Re: HiveMind and Spring Framework comparison

2003-11-10 Thread David Graham
I haven't used either framework but from the reading I've done on both of them 
HiveMind is focused on doing one thing well and Spring is trying to be everything to 
everyone.  Spring wants to replace Struts and WebWork in the view layer, provide a 
DAO/JDBC framework, an IoC container, AOP, and wash your dishes.  You might also 
notice that not all Spring developers are created equal.  Take a look at the copyright 
at the bottom of the javadoc...
 
David

[EMAIL PROTECTED] wrote:

Check out my Blob for a lot of background on HiveMind:

http://javatapestry.blogspot.com

Spring is a little more vertical than HiveMind. HiveMind allows for a much richer 
service environment and the XML is much simpler. HiveMind integrates a distributed 
configuration model (inspired by Eclipse plugins) that is unique among the major 
microkernels.

--
[EMAIL PROTECTED]

Creator, Tapestry: Java Web 
Components
http://jakarta.apache.org/tapestry
 Hello,
 
 While HiveMind is currently out of CVS, I thought I'd ask a
 newbie question here, since I couldn't find any answers via
 Google.
 
 Could anyone compare HiveMind and Spring Framework?
 Aren't they trying to solve the same problems, use very similar
 approach, and allow very similar usage?
 
 I have not used either one of them, although I have read/heard
 various presentations, code samples, for both of them.
 
 Thanks,
 Otis
 
 
 
 Get your own 800 number
 Voicemail, fax, email, and a lot more
 http://www.ureach.com/reg/tag
 
 -
 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 you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard

cvs commit: jakarta-commons/dbutils/src/java/org/apache/commons/dbutils QueryRunner.java

2003-11-10 Thread dgraham
dgraham 2003/11/10 16:49:44

  Modified:dbutils/src/java/org/apache/commons/dbutils QueryRunner.java
  Log:
  Fixed javadoc on wrap() method.
  
  Revision  ChangesPath
  1.3   +5 -5  
jakarta-commons/dbutils/src/java/org/apache/commons/dbutils/QueryRunner.java
  
  Index: QueryRunner.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/dbutils/src/java/org/apache/commons/dbutils/QueryRunner.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- QueryRunner.java  3 Nov 2003 00:38:21 -   1.2
  +++ QueryRunner.java  11 Nov 2003 00:49:44 -  1.3
  @@ -442,7 +442,7 @@
* set in the constructor.
* 
* @param sql The SQL statement to execute.
  - * @param params Initializes the PreparedStatement's IN (ie. '?') 
  + * @param params Initializes the PreparedStatement's IN (i.e. '?') 
* parameters.
* @throws SQLException
* @return The number of rows updated.
  @@ -479,7 +479,7 @@
* /p
* pre 
* QueryRunner run = new QueryRunner() {
  - * protected void wrap(ResultSet rs) {
  + * protected ResultSet wrap(ResultSet rs) {
* return StringTrimmedResultSet.wrap(rs);
* }
* };
  
  
  

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



cvs commit: jakarta-commons/dbutils/src/java/org/apache/commons/dbutils BasicRowProcessor.java

2003-11-10 Thread dgraham
dgraham 2003/11/10 16:53:19

  Modified:dbutils/src/java/org/apache/commons/dbutils
BasicRowProcessor.java
  Log:
  Removed tabs.
  
  Revision  ChangesPath
  1.5   +20 -20
jakarta-commons/dbutils/src/java/org/apache/commons/dbutils/BasicRowProcessor.java
  
  Index: BasicRowProcessor.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/dbutils/src/java/org/apache/commons/dbutils/BasicRowProcessor.java,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- BasicRowProcessor.java10 Nov 2003 16:16:32 -  1.4
  +++ BasicRowProcessor.java11 Nov 2003 00:53:19 -  1.5
  @@ -482,30 +482,31 @@
* databases don't consistenly handle the casing of column names. 
*/
   private static class CaseInsensitiveHashMap extends HashMap {
  - /**
  -  * @see java.util.Map#containsKey(java.lang.Object)
  -  */
  +
  +/**
  + * @see java.util.Map#containsKey(java.lang.Object)
  + */
   public boolean containsKey(Object key) {
   return super.containsKey(key.toString().toLowerCase());
   }
   
  - /**
  -  * @see java.util.Map#get(java.lang.Object)
  -  */
  +/**
  + * @see java.util.Map#get(java.lang.Object)
  + */
   public Object get(Object key) {
   return super.get(key.toString().toLowerCase());
   }
   
  - /**
  -  * @see java.util.Map#put(java.lang.Object, java.lang.Object)
  -  */
  +/**
  + * @see java.util.Map#put(java.lang.Object, java.lang.Object)
  + */
   public Object put(Object key, Object value) {
   return super.put(key.toString().toLowerCase(), value);
   }
   
  - /**
  -  * @see java.util.Map#putAll(java.util.Map)
  -  */
  +/**
  + * @see java.util.Map#putAll(java.util.Map)
  + */
   public void putAll(Map m) {
   Iterator iter = m.keySet().iterator();
   while (iter.hasNext()) {
  @@ -515,13 +516,12 @@
   }
   }
   
  - /**
  -  * @see java.util.Map#remove(java.lang.ObjecT)
  -  */
  +/**
  + * @see java.util.Map#remove(java.lang.ObjecT)
  + */
   public Object remove(Object key) {
   return super.remove(key.toString().toLowerCase());
   }
   }
  +
   }
  -
  -// End of class: BasicRowProcessor.java
  
  
  

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



Re: [codec] Streamable Codec Framework

2003-11-10 Thread Ryan Hoegg
My apologies as well, I didn't realize you weren't a committer, nor that 
the MD5 stuff never made it into the release.

Tim, everyone, now that codec is a released component, might we create a 
contrib directory or a codec-sandbox?  Chris's MD5 stuff has been done 
for ages now.

I am not a commons committer, or I'd take some action myself.

This was previously tracked in Bug 17091 
(http://issues.apache.org/bugzilla/show_bug.cgi?id=17091) but was CLOSED 
with resolution LATER.  See Chris's attachment on 6/12/03.

--
Ryan Hoegg
ISIS Networks
http://www.isisnetworks.net
Christopher (siege) O'Brien wrote:

Apologies, that was not intended for the entire list. But since it went
there, may as well elaborate.
The ChunkedInputStream used a call-back system to provide a data written
to the stream back in consistently-sized chunks (except for the last
data written, which would be sized appropriately). This was useful in
MD5 for obvious reasons in the streaming implementation. I factored it
into its own class because I figured it could also be used in the SHA1
implementation that was in the works, and perhaps other registers-based
hashes or checksumming codecs.
Ryan, the original ChunkedInputStream should be a part of the package I
put together for the MD5 package, as you correctly recalled. I had
posted a note at one point offering the idea up to the IO folks, but I
never got a response on that.
- siege

On Mon, 2003-11-10 at 19:12, Christopher (siege) O'Brien wrote:
 

I don't have CVS access! But you do, and you should have a copy of the
code...
- siege
   



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


cvs commit: jakarta-commons/dbutils/src/java/org/apache/commons/dbutils QueryRunner.java

2003-11-10 Thread dgraham
dgraham 2003/11/10 17:26:25

  Modified:dbutils/src/java/org/apache/commons/dbutils QueryRunner.java
  Log:
  Removed calls to setAutoCommit(), commit() and rollback() from DataSource
  version of update().  This doesn't really change the current behavior but 
  allows JTA database transaction management.
  
  Revision  ChangesPath
  1.4   +4 -13 
jakarta-commons/dbutils/src/java/org/apache/commons/dbutils/QueryRunner.java
  
  Index: QueryRunner.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/dbutils/src/java/org/apache/commons/dbutils/QueryRunner.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- QueryRunner.java  11 Nov 2003 00:49:44 -  1.3
  +++ QueryRunner.java  11 Nov 2003 01:26:25 -  1.4
  @@ -450,22 +450,13 @@
   public int update(String sql, Object[] params) throws SQLException {
   
   Connection conn = this.ds.getConnection();
  -int rows = 0;
   
   try {
  -conn.setAutoCommit(false); // single transaction.
  -rows = this.update(conn, sql, params);
  -conn.commit();
  -
  -} catch (SQLException e) {
  -DbUtils.rollback(conn);
  -throw e;
  +return this.update(conn, sql, params);
   
   } finally {
   DbUtils.close(conn);
   }
  -
  -return rows;
   }
   
   /**
  
  
  

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



Re: math to apache commons was Re: [all] Separate email list for math development?

2003-11-10 Thread Mark R. Diggory


J.Pietschmann wrote:
Tim O'Brien wrote:

so - is there a positive alternative? i'd like to propose that 
common-maths continues to be affiliated with jakarta-commons but 
becomes managed by apache commons.



+1, I think that now is the right time to move commons math to
Apache Commons. 


As long as [math] focuses on Java, I don't see what this will
buy.
If it's simply the commons list becoming too crowded, decide
where [math] should go:
1. A companion to [lang], [logging] and [cli], valuing small
 over completeness and focusing on common tasks - stay at
 jakarta-commons


2. Grow into a full fledged library or even a system of apps
 related to numerical calculations - become a stand-alone
 Jakarta subproject, or even go top-level.
J.Pietschmann
I suppose I should clarify my opinion on this. Sorry if this is long 
winded and somewhat confusing. Also, it is just opinion...

Most Commons projects have arisen from either top level apache projects, 
xml apache projects or jakarta apache projects. As such they are 
basically refactorings of codebases within those projects. As such, they 
provide a unique subset of functionality from those projects 
refactored and made available to the community as a whole via the 
Jakarta Commons. This is a very powerful mechanism and one which the 
Jakarta Commons is highly tailored for.

To stick my neck out there: While some projects within the Jakarta 
Commons are uniquely evolved out the sandbox, it is clear that 
ultimately the best refactorings tend to arise after some considerable 
mucking about in larger projects with pre-existing applications of 
those code bases as working proofs of concept.

Interestingly, this mucking about tends to be a bit more revolutionary 
when one is an independent project with room to both evolve and reinvent 
its codebase. This, in my opinion is what the math project is lacking by 
being only within the commons, some wonderful inventions could arise if 
theres more room to experiment and redesign, if theres room for Math 
subprojects and experimental endeavors such as Interpreter Frameworks, 
GUI Tools, MathML/OpenMath experimental implementations, usage byte code 
optimization tools...

These are all things, which in my mind, don't have the space to grow as 
a simple jakarta commons library, but are vehicles for which a simple 
jakarta commons library would take its best shape through the 
experimentation with. So what I suggest is that Jakarta Commons Math 
would benefit from having a parent project where there are applications 
to offer strong working proofs of concept of its usage.

Since Jakarta in and of itself has considerable focus on Server Side 
Java and specifically, tools that work well in its flagship Tomcat 
platform, there is concern as to if Jakarta is the right place for a 
project which may include adventures into Swing GUI's bridges with other 
programming languages and mathematical platforms, etc. I might suggest 
that there is really a very artificial and illusionary boundary between 
the concept of application and server. Is a Tomcat instance installed on 
my desktop a server platform or an application platform. Really, all 
I know is its a damn good platform for doing just about anything to do 
with java on!

I think a great deal of thought has to go into why this sort of 
perceived bifurcation is occurring between Apache Commons and Jakarta 
Commons. Is there a problem here? Are groups disagreeing with one 
anothers written mandates? Or perceived mandates? Do people just not 
like working together? Maybe Jakarta needs to issue a more uptodate 
position on its content? There certainly are allot of non-server 
oriented tools in it, (CLI, Jelly, BCEL, BSF, Gump, Log4j, ORO, Regexp, 
JMeter . . .) and there really isn't anything that suggest Jakarta or 
the Jakarta Commons are only for Server related packages. What I do see 
are different groups of programmers forming separate schools or clicks.

IMHO, the focus now should be on a release of our current efforts in 
Jakarta Commons, this will provide a point of reference which we can 
grow off of and others can experiment with. It will also get us onto a 
more solid release schedule.

We should also consider that we may be working other open source 
codebases and projects into the Apache project in the future. We should 
expect we are going to eventually need more room to work on such 
integration and experimentation outside the scope of what we will want 
to make modular and available via the Jakarta Commons. I'm convinced I'd 
like to see a parent project for the Jakarta Commons Math API, I'm not 
convinced yet that it should be outside Jakarta. I think initially, as 
least, any parent project of math is going to be very Java centric, we 
should take things one step at a time and make changes as they are needed.

Getting off my soapbox now (time for dinner),

Mark
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://osprey.hmdc.harvard.edu

cvs commit: jakarta-commons/dbutils/src/java/org/apache/commons/dbutils QueryRunner.java

2003-11-10 Thread dgraham
dgraham 2003/11/10 19:24:27

  Modified:dbutils/src/java/org/apache/commons/dbutils QueryRunner.java
  Log:
  javadoc changes only.
  
  Revision  ChangesPath
  1.5   +7 -13 
jakarta-commons/dbutils/src/java/org/apache/commons/dbutils/QueryRunner.java
  
  Index: QueryRunner.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/dbutils/src/java/org/apache/commons/dbutils/QueryRunner.java,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- QueryRunner.java  11 Nov 2003 01:26:25 -  1.4
  +++ QueryRunner.java  11 Nov 2003 03:24:27 -  1.5
  @@ -405,10 +405,8 @@
   
   /**
* Executes the given INSERT, UPDATE, or DELETE SQL statement without
  - * any replacement parameters.  The statement is executed in its own 
  - * transaction that will be committed or rolled back depending on any 
  - * SQLExceptions thrown.  The codeConnection/code is retrieved from the
  - * codeDataSource/code set in the constructor.
  + * any replacement parameters. The codeConnection/code is retrieved 
  + * from the codeDataSource/code set in the constructor.
* 
* @param sql The SQL statement to execute.
* @throws SQLException
  @@ -420,10 +418,8 @@
   
   /**
* Executes the given INSERT, UPDATE, or DELETE SQL statement with
  - * a single replacement parameter.  The statement is executed in its own 
  - * transaction that will be committed or rolled back depending on any 
  - * SQLExceptions thrown.  The codeConnection/code is retrieved from the
  - * codeDataSource/code set in the constructor.
  + * a single replacement parameter.  The codeConnection/code is 
  + * retrieved from the codeDataSource/code set in the constructor.
* 
* @param sql The SQL statement to execute.
* @param param The replacement parameter.
  @@ -436,8 +432,6 @@
   
   /**
* Executes the given INSERT, UPDATE, or DELETE SQL statement.  The 
  - * statement is executed in its own transaction that will be committed or 
  - * rolled back depending on any SQLExceptions thrown.  The 
* codeConnection/code is retrieved from the codeDataSource/code 
* set in the constructor.
* 
  
  
  

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



[general] Updating 'whoweare.html'

2003-11-10 Thread Henri Yandell

[in case it's not obvious, this email pertains only to Jakarta committers]

http://jakarta.apache.org/site/whoweare.html is the informal way for
Jakarta to let the users know who we are.

When you become a Jakarta committer, it is hoped that you will add your
name and even a description if you so wish, but it can be a pain as
jakarta-site2 is a bit of a barrier to build and you have to get access to
the web-server directory, though I believe that now they are the same
machine it is easier.

That said, I am offering a one-time, no rainchecks, by the end of the
week, no-refunds, no-smallprint, service to add either your name, or your
name and a description.

Please either mail from your apache account or include your apache
username so I can doublecheck.

I'll also remove names and/or move them to 'Alumni' or some other
suggested section if anyone would like.

Hen


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



[BeanUtils] BasicDynaBean properties Map

2003-11-10 Thread Robert
I thought that BasicDynaBean was going to have a getMap() method on it, 
but a quick look at the online CVS view shows that it doesn't. Here is 
the thread from a year ago concerning this:
http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]msgId=537856

I certainly don't mind sending a quick patch if needed. If so, should 
the returned map be unmodifiable?

Thanks,
Robert McIntosh


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


DO NOT REPLY [Bug 24598] New: - [math] remove derivative methods from distribution annonymous class

2003-11-10 Thread bugzilla
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=24598.
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=24598

[math] remove derivative methods from distribution annonymous class

   Summary: [math] remove derivative methods from distribution
annonymous class
   Product: Commons
   Version: 1.0 Alpha
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: Math
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]

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



DO NOT REPLY [Bug 24598] - [math] remove derivative methods from distribution annonymous class

2003-11-10 Thread bugzilla
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=24598.
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=24598

[math] remove derivative methods from distribution annonymous class





--- Additional Comments From [EMAIL PROTECTED]  2003-11-11 04:49 ---
Created an attachment (id=9050)
patch file

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



[digester] repost : patch for plugins

2003-11-10 Thread Simon Kitching
Hi,

I sent a patch to allow users of the plugins module to select the xml
attribute which specifies the plugin declaration or class.

This was sent 2003-11-03. Would someone please have a look and commit it
unless there are objections?

This patch *only* affects the plugins module. It's also the last patch I
have lined up for the plugins module.


http://marc.theaimsgroup.com/?l=jakarta-commons-devm=106784768220233w=2

Thanks,

Simon


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



Re: Socket to create HttpClient

2003-11-10 Thread Ortwin Glück
Maarten Bodewes wrote:
As HTTP is actually a layer on top of TCP/IP sockets, would it not be 
better to be able to provide the HttpClient / HttpConnection with a 
socket, or even with an input- and output stream when it is created? 
There seems to be no way to create an HTTP session with  a socket as 
parameter.

Otherwise, dynamic class loading could be used to return a specific / 
configurable SSL or plain socket implementation instead of the ones 
provided with this project.
Maarten, I don't agree. HttpClient wants to completely hide away the 
connection management from the user. This is successfully accomplished 
by using a custom SocketFactory.

PS I've changed Protocol.java and provided my own SocketFactory as was 
described in the above guide. Just to make sure: I do not need to donate 
any software to the apache foundation for doing this, don't I? Not that 
it would be helpful - it's very JCA provider and project specific.
There should be no need to tweak Protocol.java. You can always register 
a custom SocketFactory with the default protocols.

If you have modified any HttpClient library classes you must provide the 
source code of your changes in addition to the binary distribution of 
your product. There is no need to send that code to the Apache 
Foundation though.

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


Re: [Https proxy] Impossible to connect

2003-11-10 Thread Ortwin Glück


Oleg Kalnichevski wrote:

I am +1 on this change. I think it is well justified.

Oleg


The patch has been committed.

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


DO NOT REPLY [Bug 16729] - Allow redirects between hosts and ports

2003-11-10 Thread bugzilla
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=16729.
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=16729

Allow redirects between hosts and ports





--- Additional Comments From [EMAIL PROTECTED]  2003-11-10 08:51 ---
Mike,
Curiously enough, TestHttpConnectionManager.testConnectMethodFailureRelease()
works just fine for me with and without the patch. I do not have a slightest
idea as to why it fails on you. It must be some sort of local setting of yours.
What kind of setup are you running?

Oleg

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



DO NOT REPLY [Bug 24560] New: - HttpClient loops endlessly while trying to retrieve status line

2003-11-10 Thread bugzilla
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=24560.
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=24560

HttpClient loops endlessly while trying to retrieve status line

   Summary: HttpClient loops endlessly while trying to retrieve
status line
   Product: Commons
   Version: Nightly Builds
  Platform: All
   URL: http://localhost:19
OS/Version: All
Status: NEW
  Severity: Normal
  Priority: Other
 Component: HttpClient
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


When fed with the wrong URL, for example http://localhost:19/ (chargen port),
HttpClient will loop endlessly while attempting to read the status line.

This is caused by a bug in HttpMethodBase.readStatusLine(HttpState, HttpConnection)

(while loop without any exceptional abort condition).

wire log excerpt:

2003/11/10 12:33:04:085 CET [DEBUG] HttpMethodDirector - -Execute loop try 1
2003/11/10 12:33:04:312 CET [DEBUG] wire - - GET / HTTP/1.1[\r][\n]
2003/11/10 12:33:04:351 CET [DEBUG] HttpMethodBase - -Adding Host request header
2003/11/10 12:33:04:532 CET [DEBUG] wire - - User-Agent: Jakarta
Commons-HttpClient[\r][\n]
2003/11/10 12:33:04:554 CET [DEBUG] wire - - Host: localhost:19[\r][\n]
2003/11/10 12:33:04:559 CET [DEBUG] wire - - [\r][\n]
2003/11/10 12:33:04:639 CET [DEBUG] wire - -
!#$%'()*+,-./0123456789:;=[EMAIL PROTECTED]
2003/11/10 12:33:04:669 CET [DEBUG] wire - -
#$%'()*+,-./0123456789:;=[EMAIL PROTECTED]
2003/11/10 12:33:04:673 CET [DEBUG] wire - -
#$%'()*+,-./0123456789:;=[EMAIL PROTECTED]
2003/11/10 12:33:04:692 CET [DEBUG] wire - -
$%'()*+,-./0123456789:;=[EMAIL PROTECTED]
2003/11/10 12:33:04:698 CET [DEBUG] wire - -
%'()*+,-./0123456789:;=[EMAIL PROTECTED]
2003/11/10 12:33:04:703 CET [DEBUG] wire - -
'()*+,-./0123456789:;=[EMAIL PROTECTED]
snip

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



DO NOT REPLY [Bug 24560] - HttpClient loops endlessly while trying to retrieve status line

2003-11-10 Thread bugzilla
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=24560.
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=24560

HttpClient loops endlessly while trying to retrieve status line





--- Additional Comments From [EMAIL PROTECTED]  2003-11-10 12:50 ---
Created an attachment (id=9016)
Test connection on localhost's chargen port (and echo), if open

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



DO NOT REPLY [Bug 24560] - HttpClient loops endlessly while trying to retrieve status line

2003-11-10 Thread bugzilla
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=24560.
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=24560

HttpClient loops endlessly while trying to retrieve status line





--- Additional Comments From [EMAIL PROTECTED]  2003-11-10 12:54 ---
Created an attachment (id=9018)
Suggested patch for HttpMethodBase.readStatusLine

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



DO NOT REPLY [Bug 24560] - HttpClient loops endlessly while trying to retrieve status line

2003-11-10 Thread bugzilla
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=24560.
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=24560

HttpClient loops endlessly while trying to retrieve status line





--- Additional Comments From [EMAIL PROTECTED]  2003-11-10 12:55 ---
Please ignore attachment id=9017 (source instead of patch).
Look at id=9018 instead.

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



Re: Socket to create HttpClient

2003-11-10 Thread Michael Becke
On Nov 10, 2003, at 3:41 AM, Ortwin Glück wrote:
If you have modified any HttpClient library classes you must provide 
the source code of your changes in addition to the binary distribution 
of your product. There is no need to send that code to the Apache 
Foundation though.
Whoa.  Quick correction here.  The Apache license does not require 
source distribution in any circumstances.  The only requirements are 
the following:

  1. Redistributions of source code must retain the above copyright
 notice, this list of conditions and the following disclaimer.
  2. Redistributions in binary form must reproduce the above copyright
 notice, this list of conditions and the following disclaimer in
 the documentation and/or other materials provided with the
 distribution.
  3. The end-user documentation included with the redistribution, if
 any, must include the following acknowlegement:
This product includes software developed by the
 Apache Software Foundation (http://www.apache.org/).
 Alternately, this acknowlegement may appear in the software itself,
 if and wherever such third-party acknowlegements normally appear.
  4. The names The Jakarta Project, HttpClient, and Apache Software
 Foundation must not be used to endorse or promote products derived
 from this software without prior written permission. For written
 permission, please contact [EMAIL PROTECTED]
  5. Products derived from this software may not be called Apache
 nor may Apache appear in their names without prior written
 permission of the Apache Group.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: cvs commit: jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/protocol Protocol.java

2003-11-10 Thread Michael Becke
I think the addition of an instanceof test is good, but I think we  
should deprecate here instead of removing the constructor.  This  
removal causes a binary compatibility problem that I think we can  
easily avoid.

Mike


On Nov 7, 2003, at 2:34 AM, [EMAIL PROTECTED] wrote:

oglueck 2003/11/06 23:34:34

  Modified:httpclient API_CHANGES_2_1.txt

httpclient/src/java/org/apache/commons/httpclient/protocol
Protocol.java
  Log:
  fixed design error: uniform Protocol constructor for all factories

  Revision  ChangesPath
  1.4   +2 -0  jakarta-commons/httpclient/API_CHANGES_2_1.txt
  Index: API_CHANGES_2_1.txt
  ===
  RCS file: /home/cvs/jakarta-commons/httpclient/API_CHANGES_2_1.txt,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- API_CHANGES_2_1.txt	18 Sep 2003 13:56:21 -	1.3
  +++ API_CHANGES_2_1.txt	7 Nov 2003 07:34:34 -	1.4
  @@ -31,3 +31,5 @@
   state of DigestScheme:
   - createDigest(String, String)
   - createDigestHeader(String, String)
  +
  +* There is only one Protocol constructor for both secure and  
insecure socket factories.



  1.6   +6 -32  
jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/ 
protocol/Protocol.java

  Index: Protocol.java
  ===
  RCS file:  
/home/cvs/jakarta-commons/httpclient/src/java/org/apache/commons/ 
httpclient/protocol/Protocol.java,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- Protocol.java	31 Jan 2003 00:33:36 -	1.5
  +++ Protocol.java	7 Nov 2003 07:34:34 -	1.6
  @@ -194,7 +194,8 @@
   private boolean secure;

   /**
  - * Constructs a new Protocol.  The created protcol is insecure.
  + * Constructs a new Protocol. If the created protocol is  
secure depends on
  + * the class of codefactory/code.
*
* @param scheme the scheme (e.g. http, https)
* @param factory the factory for creating sockets for  
communication using
  @@ -216,36 +217,9 @@
   this.scheme = scheme;
   this.socketFactory = factory;
   this.defaultPort = defaultPort;
  -this.secure = false;
  +this.secure = (factory instanceof  
SecureProtocolSocketFactory);
   }

  -/**
  - * Constructs a new Protocol.  The created protcol is secure.
  - *
  - * @param scheme the scheme (e.g. http, https)
  - * @param factory the factory for creating sockets for  
communication using
  - * this protocol
  - * @param defaultPort the port this protocol defaults to
  - */
  -public Protocol(String scheme,
  -SecureProtocolSocketFactory factory, int defaultPort) {
  -
  -if (scheme == null) {
  -throw new IllegalArgumentException(scheme is null);
  -}
  -if (factory == null) {
  -throw new IllegalArgumentException(socketFactory is  
null);
  -}
  -if (defaultPort = 0) {
  -throw new IllegalArgumentException(port is invalid:   
+ defaultPort);
  -}
  -
  -this.scheme = scheme;
  -this.socketFactory = factory;
  -this.defaultPort = defaultPort;
  -this.secure = true;
  -}
  -
   /**
* Returns the defaultPort.
* @return int



-
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]


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


DO NOT REPLY [Bug 24560] - HttpClient loops endlessly while trying to retrieve status line

2003-11-10 Thread bugzilla
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=24560.
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=24560

HttpClient loops endlessly while trying to retrieve status line





--- Additional Comments From [EMAIL PROTECTED]  2003-11-10 14:14 ---
Christian,
Could you, please, parameterize 'maxLinesToInspect' value using HttpMethodParams
class and resubmit the patch?

Oleg

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



Re: Socket to create HttpClient

2003-11-10 Thread Ortwin Glück


Michael Becke wrote:
Whoa.  Quick correction here.  The Apache license does not require 
source distribution in any circumstances. 
Uh, right! I wasn't aware of that difference to other OS licences...

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


RE: Socket to create HttpClient

2003-11-10 Thread Kalnichevski, Oleg
And that's quite a fundamental one.

Oleg

-Original Message-
From: Ortwin Glück [mailto:[EMAIL PROTECTED]
Sent: Monday, November 10, 2003 15:36
To: Commons HttpClient Project
Subject: Re: Socket to create HttpClient




Michael Becke wrote:
 Whoa.  Quick correction here.  The Apache license does not require 
 source distribution in any circumstances. 

Uh, right! I wasn't aware of that difference to other OS licences...


-
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: cvs commit: jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/protocol Protocol.java

2003-11-10 Thread Ortwin Glück


Roland Weber wrote:
Consider this:

SecureProtocolSocketFactory spsf = ...;
... = new Protocol(myscheme, spsf, 666);
There is nothing in the SecureProtocolSocketFactory interface that 
should be called by the user.
So the user should write:

ProtocolSocketFactory spsf = ...;
 ... = new Protocol(myscheme, spsf, 666);
Of course if you write your own SPSF this may lead to code like this:

MySecureProtocolSocketFactory foo = MySecureProtocolSocketFactory();
f.callsomeMethod(...);
... = new Protocol(https, (ProtocolSocketFactory)foo, 443);
or even:

ProtocolSocketFactory foo = MySecureProtocolSocketFactory();
((MySecureProtocolSocketFactory)f).callsomeMethod(...);
... = new Protocol(https, foo, 443);
Odi



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


DO NOT REPLY [Bug 24352] - NLTM Proxy and basic host authorization

2003-11-10 Thread bugzilla
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=24352.
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=24352

NLTM Proxy and basic host authorization





--- Additional Comments From [EMAIL PROTECTED]  2003-11-10 17:43 ---
Folks, any objections to committing this one?

Oleg

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



DO NOT REPLY [Bug 24352] - NLTM Proxy and basic host authorization

2003-11-10 Thread bugzilla
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=24352.
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=24352

NLTM Proxy and basic host authorization





--- Additional Comments From [EMAIL PROTECTED]  2003-11-10 19:14 ---
Oleg,

I haven't had a chance to try this patch out, but if it works for you that's
good enough for me.

Mike

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



DO NOT REPLY [Bug 24352] - NLTM Proxy and basic host authorization

2003-11-10 Thread bugzilla
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=24352.
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=24352

NLTM Proxy and basic host authorization





--- Additional Comments From [EMAIL PROTECTED]  2003-11-10 22:37 ---
Mike,
It all can wait. There is no rush. I'd feel better if someone else had a look.

Oleg

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



DO NOT REPLY [Bug 16729] - Allow redirects between hosts and ports

2003-11-10 Thread bugzilla
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=16729.
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=16729

Allow redirects between hosts and ports





--- Additional Comments From [EMAIL PROTECTED]  2003-11-10 23:24 ---
Mike, I checked in the patch. I feel, however, that the code still needs a bit
more polish. Another patch is to follow. I will also retest all the combinations
of proxy + target server authentication.

Oleg

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



file upload (PUT method) progress report

2003-11-10 Thread Yong Chen


Hi,

I'm using putmethod to put (large size) file on server. After calling executeMethod(), 
I want to know the progress or the percentage of file uploaded so I can report it to 
UI.

1. Is there any to do it now?
2. If not, are there any plans for adding it to the future release?

Thanks,
Yong Chen

SPECIAL NOTICE 

All information transmitted hereby is intended only for the use of the 
addressee(s) named  above and may contain confidential and privileged 
information. Any unauthorized  review, use, disclosure or distribution
of confidential and privileged information is prohibited. If the reader of
this message is not the intended recipient(s) or the employee or agent 
responsible for delivering the message to the intended recipient, you
are herby notified that you must not read this transmission and that
disclosure, copying, printing, distribution or use of any of the
information contained in or attached to this transmission is STRICTLY 
PROHIBITED.

Anyone who receives confidential and privileged information in error should 
notify us immediately by telephone and mail the original message to us at the
above address and destroy all copies.  To the extent any portion of this
communication contains public information, no such restrictions 
apply to that information. (gate01)

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



500 Server Error from IIS 4.0 with large Content-Length

2003-11-10 Thread Kaufmann, Scott
I'm using 2.0-rc2 of http client to mimic a form based application.
Everything works fine until the Content-Length of my post gets above ~45K.
Then I get an IIS 4.0 genereated 500 Server Error with the response body
reading:
 
htmlheadtitleError/title/headbodyNot enough storage is available
to complete this operation. /body/html
 
However, if I use the GUI based form to post the same content from IE, it
works without problems.  Any ideas?
 
Thanks,
Scott

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



Re: cvs commit: jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/protocol Protocol.java

2003-11-10 Thread Michael Becke
Hi Roland,

You bring up a good point.  Having the one constructor deprecated might  
be a little annoying for users.  Fortunately, creating protocols is a  
fairly rare event.  Given that, I think the annoyance is worth it for  
the backwards compatibility.  My other intention is to try to keep the  
API breaks to a minimum.  Though this one is pretty minor I think it's  
worth keeping compatibility wherever possible.

Mike

On Nov 10, 2003, at 10:18 AM, Roland Weber wrote:

Hello Mike,

I have considered deprecation as well. But the problem is that folks  
will
get deprecation warnings although their code is perfectly ok. They  
don't
have to change a bit, as soon as the deprecated constructor is removed,
the very same code will compile without a warning. Consider this:

SecureProtocolSocketFactory spsf = ...;
... = new Protocol(myscheme, spsf, 666);
When the constructor is deprecated, you will get a warning. To get
rid of that warning, you have to use the other constructor explicitly:
... = new Protocol(myscheme, (ProtocolSocketFactory)spsf, 666);

Once the deprecated constructor is removed, nobody is
going to understand why the argument was ever casted...
Breaking binary compatibility isn't nice, but I don't think people
should have to screw up their code like this to get rid of
deprecation warnings.
regards,
  Roland




Michael Becke [EMAIL PROTECTED]
10.11.2003 14:26
Please respond to Commons HttpClient Project
To: Commons HttpClient Project
[EMAIL PROTECTED]
cc:
Subject:Re: cvs commit:
jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/ 
protocol
Protocol.java

I think the addition of an instanceof test is good, but I think we
should deprecate here instead of removing the constructor.  This
removal causes a binary compatibility problem that I think we can
easily avoid.
Mike


On Nov 7, 2003, at 2:34 AM, [EMAIL PROTECTED] wrote:

oglueck 2003/11/06 23:34:34

  Modified:httpclient API_CHANGES_2_1.txt

httpclient/src/java/org/apache/commons/httpclient/protocol
Protocol.java
  Log:
  fixed design error: uniform Protocol constructor for all factories
  Revision  ChangesPath
  1.4   +2 -0  jakarta-commons/httpclient/API_CHANGES_2_1.txt
  Index: API_CHANGES_2_1.txt
  ===
  RCS file:  
/home/cvs/jakarta-commons/httpclient/API_CHANGES_2_1.txt,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- API_CHANGES_2_1.txt 18 Sep 2003 13:56:21 -  1.3
  +++ API_CHANGES_2_1.txt 7 Nov 2003 07:34:34 -  1.4
  @@ -31,3 +31,5 @@
   state of DigestScheme:
   - createDigest(String, String)
   - createDigestHeader(String, String)
  +
  +* There is only one Protocol constructor for both secure and
insecure socket factories.



  1.6   +6 -32
jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/
protocol/Protocol.java
  Index: Protocol.java
  ===
  RCS file:
/home/cvs/jakarta-commons/httpclient/src/java/org/apache/commons/
httpclient/protocol/Protocol.java,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- Protocol.java   31 Jan 2003 00:33:36 - 1.5
  +++ Protocol.java   7 Nov 2003 07:34:34 - 1.6
  @@ -194,7 +194,8 @@
   private boolean secure;
   /**
  - * Constructs a new Protocol.  The created protcol is  
insecure.
  + * Constructs a new Protocol. If the created protocol is
secure depends on
  + * the class of codefactory/code.
*
* @param scheme the scheme (e.g. http, https)
* @param factory the factory for creating sockets for
communication using
  @@ -216,36 +217,9 @@
   this.scheme = scheme;
   this.socketFactory = factory;
   this.defaultPort = defaultPort;
  -this.secure = false;
  +this.secure = (factory instanceof
SecureProtocolSocketFactory);
   }

  -/**
  - * Constructs a new Protocol.  The created protcol is secure.
  - *
  - * @param scheme the scheme (e.g. http, https)
  - * @param factory the factory for creating sockets for
communication using
  - * this protocol
  - * @param defaultPort the port this protocol defaults to
  - */
  -public Protocol(String scheme,
  -SecureProtocolSocketFactory factory, int defaultPort) {
  -
  -if (scheme == null) {
  -throw new IllegalArgumentException(scheme is null);
  -}
  -if (factory == null) {
  -throw new IllegalArgumentException(socketFactory is
null);
  -}
  -if (defaultPort = 0) {
  -throw new IllegalArgumentException(port is invalid: 
+ defaultPort);
  -}
  -
  -this.scheme = scheme;
  -this.socketFactory = factory;
  -this.defaultPort = defaultPort;
  -

SOCKS5 Support

2003-11-10 Thread sven_loberg
Hi All,

I need to send an HTTP request across a SOCKS proxy and would like to use
the HTTPClient and need to use SOCKS 5.

The site's Features mentions that HTTPClient supports transparent
connections through SOCKS proxies (version 4  5) using native Java socket
support.

Does the HTTPClient support SOCKS5? Though Innovation's site
(http://www.innovation.ch/java/HTTPClient/) supports SOCKS 5, I'd rather
use the Jakarta project.

If the HTTPClient does support SOCKS5, can you provide some sample code on
how the HTTPClient implements setting SOCKS proxy configurations (I'm using
JDK 1.3.1)?

Much appreciated...

Thanks,

Sven




This transmission may contain information that is privileged, confidential and/or 
exempt from disclosure under applicable law. If you are not the intended recipient, 
you are hereby notified that any disclosure, copying, distribution, or use of the 
information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. 
If you received this transmission in error, please immediately contact the sender and 
destroy the material in its entirety, whether in electronic or hard copy format. Thank 
you.


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



DO NOT REPLY [Bug 24309] - MultiThreadedHttpConnectionManager daemon Thread never GC'd

2003-11-10 Thread bugzilla
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=24309.
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=24309

MultiThreadedHttpConnectionManager daemon Thread never GC'd





--- Additional Comments From [EMAIL PROTECTED]  2003-11-11 03:18 ---
Created an attachment (id=9047)
Patch 4

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



Re: SOCKS5 Support

2003-11-10 Thread Michael Becke
Hi Sven,

HttpClient can make use of Java's native support for SOCKS proxies.  
There is a little documentation on this at Sun's site at 
http://java.sun.com/j2se/1.4.1/docs/guide/net/properties.html.  The 
docs for pre 1.4 JVMs are pretty sparse, but I'm pretty sure that it's 
supported.  Please let us know if you discover anything useful.

Mike

On Nov 10, 2003, at 9:51 PM, [EMAIL PROTECTED] wrote:

Hi All,

I need to send an HTTP request across a SOCKS proxy and would like to 
use
the HTTPClient and need to use SOCKS 5.

The site's Features mentions that HTTPClient supports transparent
connections through SOCKS proxies (version 4  5) using native Java 
socket
support.

Does the HTTPClient support SOCKS5? Though Innovation's site
(http://www.innovation.ch/java/HTTPClient/) supports SOCKS 5, I'd 
rather
use the Jakarta project.

If the HTTPClient does support SOCKS5, can you provide some sample 
code on
how the HTTPClient implements setting SOCKS proxy configurations (I'm 
using
JDK 1.3.1)?

Much appreciated...

Thanks,

Sven



This transmission may contain information that is privileged, 
confidential and/or exempt from disclosure under applicable law. If 
you are not the intended recipient, you are hereby notified that any 
disclosure, copying, distribution, or use of the information contained 
herein (including any reliance thereon) is STRICTLY PROHIBITED. If you 
received this transmission in error, please immediately contact the 
sender and destroy the material in its entirety, whether in electronic 
or hard copy format. Thank you.

-
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: file upload (PUT method) progress report

2003-11-10 Thread Michael Becke
Hi Yong,

The only way to get progress at the moment is to track the reads on the 
InputStream given to PostMethod.setRequestBody(InputStream).

Mike

On Nov 10, 2003, at 7:02 PM, Yong Chen wrote:



Hi,

I'm using putmethod to put (large size) file on server. After calling 
executeMethod(), I want to know the progress or the percentage of file 
uploaded so I can report it to UI.

1. Is there any to do it now?
2. If not, are there any plans for adding it to the future release?
Thanks,
Yong Chen
SPECIAL NOTICE

All information transmitted hereby is intended only for the use of the
addressee(s) named  above and may contain confidential and privileged
information. Any unauthorized  review, use, disclosure or distribution
of confidential and privileged information is prohibited. If the 
reader of
this message is not the intended recipient(s) or the employee or agent
responsible for delivering the message to the intended recipient, you
are herby notified that you must not read this transmission and that
disclosure, copying, printing, distribution or use of any of the
information contained in or attached to this transmission is STRICTLY
PROHIBITED.

Anyone who receives confidential and privileged information in error 
should
notify us immediately by telephone and mail the original message to us 
at the
above address and destroy all copies.  To the extent any portion of 
this
communication contains public information, no such restrictions
apply to that information. (gate01)

-
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: 500 Server Error from IIS 4.0 with large Content-Length

2003-11-10 Thread Michael Becke
Hi Scott,

If you are performing a file upload, the browser is probably using a  
multipart post.  HttpClient supports multipart posts.  Please take a  
look at  
http://jakarta.apache.org/commons/httpclient/methods/ 
multipartpost.html and  
http://cvs.apache.org/viewcvs.cgi/jakarta-commons/httpclient/src/ 
examples/?only_with_tag=HTTPCLIENT_2_0_BRANCH for some examples.

Mike

On Nov 10, 2003, at 5:07 PM, Kaufmann, Scott wrote:

I'm using 2.0-rc2 of http client to mimic a form based application.
Everything works fine until the Content-Length of my post gets above  
~45K.
Then I get an IIS 4.0 genereated 500 Server Error with the response  
body
reading:

htmlheadtitleError/title/headbodyNot enough storage is  
available
to complete this operation. /body/html

However, if I use the GUI based form to post the same content from IE,  
it
works without problems.  Any ideas?

Thanks,
Scott
-
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: 500 Server Error from IIS 4.0 with large Content-Length

2003-11-10 Thread Kaufmann, Scott
Not using a multipart post.  The application I'm replicating uses a textbox
for the input.   My original data is coming from a file, but I'm reading it
in, doing some text rewriting, and then adding the new text to a cdata block
of a larger xml string passed as a form parameter.   
 
-Original Message- 
From: Michael Becke [mailto:[EMAIL PROTECTED] 
Sent: Mon 11/10/2003 9:00 PM 
To: Commons HttpClient Project 
Cc: 
Subject: Re: 500 Server Error from IIS 4.0 with large Content-Length



Hi Scott,

If you are performing a file upload, the browser is probably using a 
multipart post.  HttpClient supports multipart posts.  Please take a 
look at 
http://jakarta.apache.org/commons/httpclient/methods/ 
multipartpost.html and 
http://cvs.apache.org/viewcvs.cgi/jakarta-commons/httpclient/src/ 
examples/?only_with_tag=HTTPCLIENT_2_0_BRANCH for some examples.

Mike

On Nov 10, 2003, at 5:07 PM, Kaufmann, Scott wrote:

 I'm using 2.0-rc2 of http client to mimic a form based application.
 Everything works fine until the Content-Length of my post gets above 
 ~45K.
 Then I get an IIS 4.0 genereated 500 Server Error with the response 
 body
 reading:

 htmlheadtitleError/title/headbodyNot enough storage is 
 available
 to complete this operation. /body/html

 However, if I use the GUI based form to post the same content from IE, 
 it
 works without problems.  Any ideas?

 Thanks,
 Scott

 -
 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]




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