cvs commit: jakarta-commons-sandbox/dbutils/src/test/org/apache - New directory

[bayard]

bayard  2002/11/08 15:47:19

  jakarta-commons-sandbox/dbutils/src/test/org/apache - New directory

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-commons-sandbox/dbutils/src/java/org/apache/commons/dbutils - New directory

[bayard]

bayard  2002/11/08 15:47:19

  jakarta-commons-sandbox/dbutils/src/java/org/apache/commons/dbutils - New directory

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-commons-sandbox/dbutils/src/test/org - New directory

[bayard]

bayard  2002/11/08 15:47:19

  jakarta-commons-sandbox/dbutils/src/test/org - New directory

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-commons-sandbox/dbutils/src/test/org/apache/commons/dbutils - New directory

[bayard]

bayard  2002/11/08 15:47:19

  jakarta-commons-sandbox/dbutils/src/test/org/apache/commons/dbutils - New directory

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-commons-sandbox/dbutils/src/java/org/apache/commons - New directory

[bayard]

bayard  2002/11/08 15:47:19

  jakarta-commons-sandbox/dbutils/src/java/org/apache/commons - New directory

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-commons-sandbox/dbutils/src/test/org/apache/commons - New directory

[bayard]

bayard  2002/11/08 15:47:19

  jakarta-commons-sandbox/dbutils/src/test/org/apache/commons - New directory

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-commons-sandbox/dbutils/src/java/org/apache - New directory

[bayard]

bayard  2002/11/08 15:47:19

  jakarta-commons-sandbox/dbutils/src/java/org/apache - New directory

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-commons-sandbox/dbutils/src/conf - New directory

[bayard]

bayard  2002/11/08 15:41:47

  jakarta-commons-sandbox/dbutils/src/conf - New directory

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-commons-sandbox/dbutils/src/java - New directory

[bayard]

bayard  2002/11/08 15:41:47

  jakarta-commons-sandbox/dbutils/src/java - New directory

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-commons-sandbox/dbutils/src/test - New directory

[bayard]

bayard  2002/11/08 15:41:47

  jakarta-commons-sandbox/dbutils/src/test - New directory

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-commons-sandbox/dbutils/src - New directory

[bayard]

bayard  2002/11/08 15:40:22

  jakarta-commons-sandbox/dbutils/src - New directory

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-commons-sandbox/dbutils - New directory

[bayard]

bayard  2002/11/08 15:39:32

  jakarta-commons-sandbox/dbutils - New directory

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [jdbc] JdbcUtil etc

[Craig R. McClanahan]

On Fri, 8 Nov 2002, Henri Yandell wrote:

> Date: Fri, 8 Nov 2002 18:05:08 -0500 (EST)
> From: Henri Yandell <[EMAIL PROTECTED]>
> Reply-To: Jakarta Commons Developers List <[EMAIL PROTECTED]>
> To: Jakarta Commons Developers List <[EMAIL PROTECTED]>
> Subject: RE: [jdbc] JdbcUtil etc
>
>
>
> > On Fri, 8 Nov 2002 [EMAIL PROTECTED] wrote:
> > >
> > > For beans, the solution was to call it beanutil, so perhaps we should
> > > call it jdbcutil.
> > >
> >
> > Looking at the Sun website, the JDBC acronym is clearly trademarked on its
> > webpage so we need another name.
> >
> > I'll ask the question on General as do we even know if jdbcutil is ok?
> > [Beans isn't trademarked, JavaBeans is].
>
> Looking at it, and thinking in the usual stop-start way, we have a
> jdbc2pool project, so assuming that is okay, then jdbcutils is okay [to
> match beanutils].
>

I think we'd actually be better off if we didn't include "jdbc" in the
name of anything (including the existing jdbc2pool project) because of the
trademark.  There is precedent for this -- what is now Cactus was
originally called "J2EEUnit" and this raised issues.

> Hen

Craig


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [jxpath] setValue calling getValue

[Dmitri Plotnikov]

You are right, I looked again and sure enough I'd forgotten that it does
call getValue().  Actually, changing that would be quite a challenge because
of some internal logic of the interpretSimpleLocationPath method.  The code
is written in a generic fashion to accomodate cases like Container-valued
properties, which need to be open unconditionally.  I'll see what I can do,
but I cannot promise a quick fix.

How critical is it that the get method throw an exception?  Can it simply
return null?

- Dmitri


- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Friday, November 08, 2002 4:08 PM
Subject: RE: [jxpath] setValue calling getValue


Hi Dmitri,

I retried with the the version at the URL you sent. Different stack trace,
but the field still gets read.

java.lang.Exception
at
com.nokia.b2t.dna.graphmap.MockDomainObject.getStringField(MockDomainObject.
java:51)
at java.lang.reflect.Method.invoke(Native Method)
at org.apache.commons.jxpath.util.ValueUtils.getValue(ValueUtils.java:287)
at
org.apache.commons.jxpath.ri.model.beans.BeanPropertyPointer.getBaseValue(Be
anPropertyPointer.java:155)
at
org.apache.commons.jxpath.ri.model.beans.BeanPropertyPointer.getNode(BeanPro
pertyPointer.java:179)
at
org.apache.commons.jxpath.ri.model.beans.PropertyPointer.getValuePointer(Pro
pertyPointer.java:168)
at
org.apache.commons.jxpath.ri.axes.SimplePathInterpreter.valuePointer(SimpleP
athInterpreter.java:675)
at
org.apache.commons.jxpath.ri.axes.SimplePathInterpreter.interpretSimpleLocat
ionPath(SimplePathInterpreter.java:114)
at
org.apache.commons.jxpath.ri.compiler.Path.getSingleNodePointerForSteps(Path
.java:172)
at
org.apache.commons.jxpath.ri.compiler.LocationPath.computeValue(LocationPath
.java:137)
at
org.apache.commons.jxpath.ri.JXPathContextReferenceImpl.setValue(JXPathConte
xtReferenceImpl.java:363)
at
org.apache.commons.jxpath.ri.JXPathContextReferenceImpl.createPathAndSetValu
e(JXPathContextReferenceImpl.java:354)
at
org.apache.commons.jxpath.ri.JXPathContextReferenceImpl.createPathAndSetValu
e(JXPathContextReferenceImpl.java:349)
at
com.nokia.b2t.dna.graphmap.ObjectGraphMapper.performMapping(ObjectGraphMappe
r.java:92)
at
com.nokia.b2t.dna.graphmap.ObjectGraphMapper.toDomainGraph(ObjectGraphMapper
.java:57)
at
com.nokia.b2t.dna.graphmap.ObjectGraphMapperJUnitTest.main(ObjectGraphMapper
JUnitTest.java:136)

> -Original Message-
> From: ext Dmitri Plotnikov [mailto:dplotnik@;yahoo.com]
> Sent: 08. November 2002 19:53
> To: Jakarta Commons Developers List
> Subject: Re: [jxpath] setValue calling getValue
>
>
> Mike,
>
> You are right, it really should not do that.
>
> The line numbers in the stack trace indicate that you are using a
> pretty old version of jxpath. Could you upgrade to the current version
> and let me know if the problem persists?
>
> The binary download is available at
> www.plotnix.com/jxpath/commons-jxpath.zip
>
> Thank you,
>
> - Dmitri
>
> --- [EMAIL PROTECTED] wrote:
> > Hi,
> >
> > When JXPath is setting a property, it first gets the
> properties value
> > (computeValue()).  I have an throwing an exception in the getter
> > method in my class to show the stack trace, below.
> >
> > Why does JXPath read the value before setting it, and is there any
> > way to avoid it?
> >
> > Thanks,
> > Mike.
> >
> > java.lang.Exception: Reading field
> > at
> >
> com.nokia.b2t.dna.graphmap.MockDomainObject$MockNestedDomainOb
> ject.getStringField(MockDomainObject.java:76)
> > at java.lang.reflect.Method.invoke(Native Method)
> > at
> >
> org.apache.commons.jxpath.util.ValueUtils.getValue(ValueUtils.
> java:287)
> > at
> >
> org.apache.commons.jxpath.ri.model.beans.BeanPropertyPointer.g
> etNodeValue(BeanPropertyPointer.java:187)
> > at
> >
> org.apache.commons.jxpath.ri.model.beans.PropertyPointer.getVa
> luePointer(PropertyPointer.java:152)
> > at
> >
> org.apache.commons.jxpath.ri.axes.SimplePathInterpreter.single
> Step(SimplePathInterpreter.java:246)
> > at
> >
> org.apache.commons.jxpath.ri.axes.SimplePathInterpreter.interp
> retPath(SimplePathInterpreter.java:119)
> > at
> >
> org.apache.commons.jxpath.ri.compiler.Path.getSingleNodePointe
> rForSteps(Path.java:162)
> > at
> >
> org.apache.commons.jxpath.ri.compiler.LocationPath.computeValu
> e(LocationPath.java:137)
> > at
> >
> org.apache.commons.jxpath.ri.JXPathContextReferenceImpl.setVal
> ue(JXPathContextReferenceImpl.java:329)
> > at
> >
> org.apache.commons.jxpath.ri.JXPathContextReferenceImpl.create
> PathAndSetValue(JXPathContextReferenceImpl.java:320)
> > at
> >
> org.apache.commons.jxpath.ri.JXPathContextReferenceImpl.create
> PathAndSetValue(JXPathContextReferenceImpl.java:315)
> > at
> >
> com.nokia.b2t.dna.graphmap.ObjectGraphMapper.performMapping(Ob
> jectGraphMapper.java:88)
> > at
> >
> com.nokia.b2t.dna.graphmap.ObjectGraphMapper.toDomainGraph(Obj
> ectGraphMapper.java:57)
> > at
> >
> com.nokia.b2t.dna.graphmap.ObjectGraphMapperJUnitTest.main(Obj
> ectGraphMapperJUnitT

cvs commit: jakarta-commons/betwixt/src/conf MANIFEST.MF

[mvdb]

mvdb2002/11/08 15:25:55

  Modified:betwixt/src/conf MANIFEST.MF
  Log:
  Updated implementation version
  
  Revision  ChangesPath
  1.3   +1 -1  jakarta-commons/betwixt/src/conf/MANIFEST.MF
  
  Index: MANIFEST.MF
  ===
  RCS file: /home/cvs/jakarta-commons/betwixt/src/conf/MANIFEST.MF,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- MANIFEST.MF   27 Jun 2002 13:05:59 -  1.2
  +++ MANIFEST.MF   8 Nov 2002 23:25:55 -   1.3
  @@ -2,5 +2,5 @@
   Specification-Vendor: Apache Software Foundation
   Specification-Version: 1.0
   Implementation-Vendor: Apache Software Foundation
  -Implementation-Version: 1.0-dev
  +Implementation-Version: 1.0-beta-1
   

  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: installing jakarta code Was: using commons components andlog ging

[Martin Cooper]

> -Original Message-
> From: Steven Caswell [mailto:steven@;caswell.name]
> Sent: Friday, November 08, 2002 3:11 PM
> To: 'Henri Yandell'
> Cc: Jakarta Commons Developers List
> Subject: RE: installing jakarta code Was: using commons components and
> logging
> 
> 
> 
> 
> > -Original Message-
> > From: Henri Yandell [mailto:bayard@;generationjava.com] 
> > Sent: Friday, November 08, 2002 5:04 PM
> > To: Steven Caswell
> > Cc: 'Henri Yandell'
> > Subject: RE: installing jakarta code Was: using commons 
> > components and logging
> > 
> > 
> > 
> > 
> > On Fri, 8 Nov 2002, Steven Caswell wrote:
> > 
> > > Confused the user how?
> > >
> > > I guess I don't understand how using a library like lang 
> can cause 
> > > heartburn for a project like Collections. I've never had 
> a problem 
> > > adding another jar to the classpath. Seems to me that the "user" 
> > > (which, we should keep in mind, are supposedly intelligent 
> > developers) 
> > > should easily understand an additional dependency. As 
> long as it is 
> > > documented in a clear manner.
> > 
> > Maybe that's the nub. Without really sitting down with users 
> > to find out why they didn't install XXX library, it's hard to 
> > tell. But I can quite happily goto the Jakarta front page, 
> > click on a news item or click on Binary Releases, and 
> > download the zip without realising.
> 
> That is a good point. I've had on blinders thinking more along
> the lines of the initial installation of a project, but your point
> About getting a later release is well taken. Unless I explicitly look
> at the docs, I may miss an important dependency. And today Maven
> doesn't really help this situation.

I think a *big* help to users would be simply stating the dependencies for
each component on the corresponding download page, in a README.html file.
That will show up right below the links for downloading. Simple, and the
user is bound to see it.

If you're not familiar with this, take a look here:

http://jakarta.apache.org/builds/jakarta-struts/release/v1.1-b2/

The text below the file list comes from a README.html file in the same
directory.

--
Martin Cooper


> 
> > 
> > Especially as I expect to have an INSTALL.txt or README.txt 
> > [or html] which tells me what I need. We tend to put it on 
> > the website, which a lot of people probably don't bother to check.
> > 
> > So, maybe Maven could be generating out an INSTALL.txt as 
> > part of its build or some such. Or maybe the current download 
> > method of using the default Apache directory is wrong, we 
> > need a lot of index.html's throughout the build/ directory.
> 
> Could get real messy.
> 
> > 
> > Or we have an xml file in the releases directory called 
> > requires.xml which an Apache module reads, shows a custom 
> > Apache directory-page to remind people where to go to get the 
> > requirements.
> > 
> > I like that idea, it's not java, but neither is Jakarta's 
> > site. What do you think? [Maven can still generate this xml 
> > file out as part of the build]
> > 
> 
> I think this would be a reasonable short-term solution. I'd really
> Like to see things move toward a neutral (i.e.,
> project-comprehension-tool-agnostic)
> xml description of dependencies that could be used by Maven 
> or whatever
> to
> Figure out what else needs to be gotten and go get it.
> 
> > Hen
> > 
> > 
> 
> 
> 
> --
> To unsubscribe, e-mail:   

For additional commands, e-mail:




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [jdbc] JdbcUtil etc

[Steven Caswell]

Or maybe dbcutils?


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


> -Original Message-
> From: Henri Yandell [mailto:bayard@;generationjava.com] 
> Sent: Friday, November 08, 2002 5:57 PM
> To: Jakarta Commons Developers List
> Subject: RE: [jdbc] JdbcUtil etc
> 
> 
> 
> DbUtils?
> 
> On Fri, 8 Nov 2002 [EMAIL PROTECTED] wrote:
> 
> > Given all the recent issues about our responsibilities wrt legal 
> > issues, I think that using a Sun Trademark (is it a trademark?) for 
> > one of our released products could cause problems. If jdbc is 
> > preferred, I think that it should be checked with our official PMC 
> > (Jakarta) or the board.
> >
> > For beans, the solution was to call it beanutil, so perhaps 
> we should 
> > call it jdbcutil.
> >
> > Stephen
> >
> > >  from:Henri Yandell <[EMAIL PROTECTED]>
> > >  date:Fri, 08 Nov 2002 22:05:53
> > >  to:  [EMAIL PROTECTED], [EMAIL PROTECTED]
> > >  subject: RE: [jdbc] JdbcUtil etc
> > >
> > > On Fri, 8 Nov 2002, Steven Caswell wrote:
> > >
> > > > I don't know of anything that already exists, and I've looked 
> > > > around Jakarta a little bit to find one. I'd love to see a jdbc 
> > > > subproject. I've got a few things I could throw in as 
> well. So I'm  
> > > > 1 that such a thing should exist,  1 for calling it jdbc and  1 
> > > > for separating this kind of stuff from the current sql 
> project (I 
> > > > agree, the sql project is different stuff).
> > >
> > > Works for me as a sanity check :) I'm not insane! woo. maybe.
> > >
> > > I'll write a proposal and add a jdbc project with some 
> initial code 
> > > tonight/this w/e. You okay to be an initial committer on it?
> > >
> > > Hen
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:   
>  [EMAIL PROTECTED]>
> > > For 
> additional commands, e-mail: 
> > > 
> > >
> >
> >
> > --
> > To unsubscribe, e-mail:   
>  [EMAIL PROTECTED]>
> > For 
> additional commands, 
> e-mail: 
> > 
> >
> >
> 
> 
> --
> To unsubscribe, e-mail:   
>  [EMAIL PROTECTED]>
> For 
> additional commands, 
> e-mail: 
> 
> 



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-commons/httpclient/src/test/org/apache/commons/httpclient TestResponseHeaders.java

[jsdever]

jsdever 2002/11/08 15:14:31

  Modified:httpclient/src/java/org/apache/commons/httpclient
HttpMethodBase.java
   httpclient/src/test/org/apache/commons/httpclient
TestResponseHeaders.java
  Log:
  Fix handling of multiple Content-Length headers.
  
  Reported by Joerg Heinicke
  Contributed by: Mike Becke
  
  Revision  ChangesPath
  1.78  +27 -6 
jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/HttpMethodBase.java
  
  Index: HttpMethodBase.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/HttpMethodBase.java,v
  retrieving revision 1.77
  retrieving revision 1.78
  diff -u -r1.77 -r1.78
  --- HttpMethodBase.java   8 Nov 2002 22:25:07 -   1.77
  +++ HttpMethodBase.java   8 Nov 2002 23:14:30 -   1.78
  @@ -1597,12 +1597,33 @@
   result = new ChunkedInputStream(is, this);
   }
   } else if (null != lengthHeader) {
  +
  +// we're using this just in case the content length is duplicated
  +// i.e. '57, 57'
  +HeaderElement[] lengthElements = lengthHeader.getValues();
  +String lengthValue = null;
  +
  +if ( lengthElements.length > 1 ) {
  +// looks like the content length header was duplicated. if so
  +// they won't be key=value pairs so we just want to get
  +// the name not the value (which should be null)
  +// take the first value and ignore any others
  +lengthValue = lengthElements[0].getName();
  +} else {
  +lengthValue = lengthHeader.getValue();
  +}
  +
   try {
  -int expectedLength = Integer.parseInt(lengthHeader.getValue());
  +int expectedLength = Integer.parseInt(lengthValue);
   result = new ContentLengthInputStream(is, expectedLength);
   } catch(NumberFormatException e) {
  -// ignored
  +throw new HttpException( 
  +"Unable to parse server response content length: '" 
  ++ lengthValue + "'"
  +);
  +
   }
  +
   } else if(canResponseHaveBody(statusLine.getStatusCode()) 
   && !getName().equals(ConnectMethod.NAME)){
   result = is;
  
  
  
  1.4   +22 -4 
jakarta-commons/httpclient/src/test/org/apache/commons/httpclient/TestResponseHeaders.java
  
  Index: TestResponseHeaders.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/httpclient/src/test/org/apache/commons/httpclient/TestResponseHeaders.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- TestResponseHeaders.java  6 Aug 2002 19:47:29 -   1.3
  +++ TestResponseHeaders.java  8 Nov 2002 23:14:30 -   1.4
  @@ -132,6 +132,24 @@
   assertEquals("UserLand Frontier/7.0-WinNT", 
method.getResponseHeader("Server").getValue());
   }
   
  +/**
  + * Tests that having a duplicate content length causes no problems.
  + */
  +public void testDuplicateContentLength() throws Exception {
  +
  +String body = "XXX\r\nYYY\r\nZZZ";
  +String headers =
  +"HTTP/1.1 200 OK\r\n" +
  +"Content-Length: " + body.length() + "\r\n" +
  +"Content-Length: " + body.length() + "\r\n";
  +HttpState state = new HttpState();
  +HttpMethod method = new SimpleHttpMethod();
  +SimpleHttpConnection conn = new SimpleHttpConnection(headers, body);
  +method.execute(state, conn);
  +assertNotNull( "Response body is null.", method.getResponseBodyAsStream() );
  +
  +}
  +
   public void testNullHeaders() throws Exception {
   String body = "XXX\r\nYYY\r\nZZZ";
   String headers =
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [jdbc] JdbcUtil etc

[Steven Caswell]

> -Original Message-
> From: Henri Yandell [mailto:bayard@;generationjava.com] 
> Sent: Friday, November 08, 2002 5:06 PM
> To: Jakarta Commons Developers List; [EMAIL PROTECTED]
> Subject: RE: [jdbc] JdbcUtil etc
> 
> 
> 
> 
> On Fri, 8 Nov 2002, Steven Caswell wrote:
> 
> > I don't know of anything that already exists, and I've 
> looked around 
> > Jakarta a little bit to find one. I'd love to see a jdbc 
> subproject. 
> > I've got a few things I could throw in as well. So I'm +1 
> that such a 
> > thing should exist, +1 for calling it jdbc and +1 for 
> separating this 
> > kind of stuff from the current sql project (I agree, the 
> sql project 
> > is different stuff).
> 
> Works for me as a sanity check :) I'm not insane! woo. maybe.
> 
> I'll write a proposal and add a jdbc project with some 
> initial code tonight/this w/e. You okay to be an initial 
> committer on it?
> 

+1

> Hen
> 
> 



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: installing jakarta code Was: using commons components and logging

[Steven Caswell]

> -Original Message-
> From: Henri Yandell [mailto:bayard@;generationjava.com] 
> Sent: Friday, November 08, 2002 5:04 PM
> To: Steven Caswell
> Cc: 'Henri Yandell'
> Subject: RE: installing jakarta code Was: using commons 
> components and logging
> 
> 
> 
> 
> On Fri, 8 Nov 2002, Steven Caswell wrote:
> 
> > Confused the user how?
> >
> > I guess I don't understand how using a library like lang can cause 
> > heartburn for a project like Collections. I've never had a problem 
> > adding another jar to the classpath. Seems to me that the "user" 
> > (which, we should keep in mind, are supposedly intelligent 
> developers) 
> > should easily understand an additional dependency. As long as it is 
> > documented in a clear manner.
> 
> Maybe that's the nub. Without really sitting down with users 
> to find out why they didn't install XXX library, it's hard to 
> tell. But I can quite happily goto the Jakarta front page, 
> click on a news item or click on Binary Releases, and 
> download the zip without realising.

That is a good point. I've had on blinders thinking more along
the lines of the initial installation of a project, but your point
About getting a later release is well taken. Unless I explicitly look
at the docs, I may miss an important dependency. And today Maven
doesn't really help this situation.

> 
> Especially as I expect to have an INSTALL.txt or README.txt 
> [or html] which tells me what I need. We tend to put it on 
> the website, which a lot of people probably don't bother to check.
> 
> So, maybe Maven could be generating out an INSTALL.txt as 
> part of its build or some such. Or maybe the current download 
> method of using the default Apache directory is wrong, we 
> need a lot of index.html's throughout the build/ directory.

Could get real messy.

> 
> Or we have an xml file in the releases directory called 
> requires.xml which an Apache module reads, shows a custom 
> Apache directory-page to remind people where to go to get the 
> requirements.
> 
> I like that idea, it's not java, but neither is Jakarta's 
> site. What do you think? [Maven can still generate this xml 
> file out as part of the build]
> 

I think this would be a reasonable short-term solution. I'd really
Like to see things move toward a neutral (i.e.,
project-comprehension-tool-agnostic)
xml description of dependencies that could be used by Maven or whatever
to
Figure out what else needs to be gotten and go get it.

> Hen
> 
> 



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-commons/betwixt/src/java/org/apache/commons/betwixt/strategy DefaultPluralStemmer.java

[mvdb]

mvdb2002/11/08 15:08:31

  Modified:betwixt/src/java/org/apache/commons/betwixt/strategy
DefaultPluralStemmer.java
  Log:
  More usefull warning, since keyfound is mostly empty..
  
  Revision  ChangesPath
  1.4   +6 -6  
jakarta-commons/betwixt/src/java/org/apache/commons/betwixt/strategy/DefaultPluralStemmer.java
  
  Index: DefaultPluralStemmer.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/betwixt/src/java/org/apache/commons/betwixt/strategy/DefaultPluralStemmer.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- DefaultPluralStemmer.java 20 Sep 2002 14:00:41 -  1.3
  +++ DefaultPluralStemmer.java 8 Nov 2002 23:08:31 -   1.4
  @@ -131,7 +131,7 @@
   }
   }
   if (foundKeyCount > 1) {
  -log.warn("More than one type matches, using closest match "+keyFound);
  +log.warn("More than one type matches, using closest match 
"+answer.getQualifiedName());
   }
   return answer;
   
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [jdbc] JdbcUtil etc

[Martin Cooper]

> -Original Message-
> From: Henri Yandell [mailto:bayard@;generationjava.com]
> Sent: Friday, November 08, 2002 2:42 PM
> To: Jakarta Commons Developers List
> Subject: RE: [jdbc] JdbcUtil etc
> 
> 
> 
> 
> 
> On Fri, 8 Nov 2002 [EMAIL PROTECTED] wrote:
> 
> > Given all the recent issues about our responsibilities wrt legal
> > issues, I think that using a Sun Trademark (is it a trademark?) for
> > one of our released products could cause problems. If jdbc is
> > preferred, I think that it should be checked with our official PMC
> > (Jakarta) or the board.
> >
> > For beans, the solution was to call it beanutil, so perhaps 
> we should
> > call it jdbcutil.
> >
> 
> Looking at the Sun website, the JDBC acronym is clearly 
> trademarked on its
> webpage so we need another name.
> 
> [A friend suggested JDBS... He's had some bad times with JDBC :) ]
> 
> I'll ask the question on General as do we even know if jdbcutil is ok?
> [Beans isn't trademarked, JavaBeans is].

In its early days, Vincent Massol had trouble with Cactus. It was originally
called J2EEUnit, but he had to change the name because of the J2EE part. So
I'd say that makes jdbcutil unworkable too. ;-{

--
Martin Cooper


> 
> Hen
> 
> 
> --
> To unsubscribe, e-mail:   

For additional commands, e-mail:




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [jdbc] JdbcUtil etc

[Tomasz Pik]

> 5) 

public static Long readLong(ResultSet rs, int index) throws SQLException {
  Long result = new Long(rs.getLong(index));
  if (rs.wasNull()) {
return null;
  } else {
return result;
  }
}

public static void setLong(PreparedStatement pstmt, int index, Long value) throws 
SQLException {
  if (value == null) {
pstmt.setNull(index,  Types.NUMBER);
  } else {
pstmt.setLong(index, value.longValue();
  }
}

And similar methods for the rest of supported types?

Regards
Tomek Pik
[EMAIL PROTECTED]

> Hen

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [jdbc] JdbcUtil etc

[Henri Yandell]

> On Fri, 8 Nov 2002 [EMAIL PROTECTED] wrote:
> >
> > For beans, the solution was to call it beanutil, so perhaps we should
> > call it jdbcutil.
> >
>
> Looking at the Sun website, the JDBC acronym is clearly trademarked on its
> webpage so we need another name.
>
> I'll ask the question on General as do we even know if jdbcutil is ok?
> [Beans isn't trademarked, JavaBeans is].

Looking at it, and thinking in the usual stop-start way, we have a
jdbc2pool project, so assuming that is okay, then jdbcutils is okay [to
match beanutils].

Hen


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [jdbc] JdbcUtil etc

[Henri Yandell]

DbUtils?

On Fri, 8 Nov 2002 [EMAIL PROTECTED] wrote:

> Given all the recent issues about our responsibilities wrt legal issues, I think 
>that using a Sun Trademark (is it a trademark?) for one of our released products 
>could cause problems. If jdbc is preferred, I think that it should be checked with 
>our official PMC (Jakarta) or the board.
>
> For beans, the solution was to call it beanutil, so perhaps we should call it 
>jdbcutil.
>
> Stephen
>
> >  from:Henri Yandell <[EMAIL PROTECTED]>
> >  date:Fri, 08 Nov 2002 22:05:53
> >  to:  [EMAIL PROTECTED], [EMAIL PROTECTED]
> >  subject: RE: [jdbc] JdbcUtil etc
> >
> > On Fri, 8 Nov 2002, Steven Caswell wrote:
> >
> > > I don't know of anything that already exists, and I've looked around
> > > Jakarta a little bit to find one. I'd love to see a jdbc subproject.
> > > I've got a few things I could throw in as well. So I'm  1 that such
> > > a thing should exist,  1 for calling it jdbc and  1 for separating
> > > this kind of stuff from the current sql project (I agree, the sql
> > > project is different stuff).
> >
> > Works for me as a sanity check :) I'm not insane! woo. maybe.
> >
> > I'll write a proposal and add a jdbc project with some initial code
> > tonight/this w/e. You okay to be an initial committer on it?
> >
> > Hen
> >
> >
> > --
> > To unsubscribe, e-mail:   
> > For additional commands, e-mail: 
> >
>
>
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
>
>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 14398] - Add an email validator

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=14398

Add an email validator

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2002-11-08 22:56 ---
Look again there *is* an email validator :-)
Try
  depends="required,email"

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [jdbc] JdbcUtil etc

[Henri Yandell]

On Fri, 8 Nov 2002 [EMAIL PROTECTED] wrote:

> Given all the recent issues about our responsibilities wrt legal
> issues, I think that using a Sun Trademark (is it a trademark?) for
> one of our released products could cause problems. If jdbc is
> preferred, I think that it should be checked with our official PMC
> (Jakarta) or the board.
>
> For beans, the solution was to call it beanutil, so perhaps we should
> call it jdbcutil.
>

Looking at the Sun website, the JDBC acronym is clearly trademarked on its
webpage so we need another name.

[A friend suggested JDBS... He's had some bad times with JDBC :) ]

I'll ask the question on General as do we even know if jdbcutil is ok?
[Beans isn't trademarked, JavaBeans is].

Hen


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [jdbc] JdbcUtil etc

[scolebourne]

Given all the recent issues about our responsibilities wrt legal issues, I think that 
using a Sun Trademark (is it a trademark?) for one of our released products could 
cause problems. If jdbc is preferred, I think that it should be checked with our 
official PMC (Jakarta) or the board.

For beans, the solution was to call it beanutil, so perhaps we should call it jdbcutil.

Stephen

>  from:Henri Yandell <[EMAIL PROTECTED]>
>  date:Fri, 08 Nov 2002 22:05:53
>  to:  [EMAIL PROTECTED], [EMAIL PROTECTED]
>  subject: RE: [jdbc] JdbcUtil etc
> 
> On Fri, 8 Nov 2002, Steven Caswell wrote:
> 
> > I don't know of anything that already exists, and I've looked around
> > Jakarta a little bit to find one. I'd love to see a jdbc subproject.
> > I've got a few things I could throw in as well. So I'm  1 that such
> > a thing should exist,  1 for calling it jdbc and  1 for separating
> > this kind of stuff from the current sql project (I agree, the sql
> > project is different stuff).
> 
> Works for me as a sanity check :) I'm not insane! woo. maybe.
> 
> I'll write a proposal and add a jdbc project with some initial code
> tonight/this w/e. You okay to be an initial committer on it?
> 
> Hen
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-commons-sandbox/proposal PROPOSAL.html

[bayard]

bayard  2002/11/08 14:26:13

  Modified:proposal PROPOSAL.html
  Log:
  Fixed error with hardcoded 'IO'.
  
  Revision  ChangesPath
  1.2   +1 -1  jakarta-commons-sandbox/proposal/PROPOSAL.html
  
  Index: PROPOSAL.html
  ===
  RCS file: /home/cvs/jakarta-commons-sandbox/proposal/PROPOSAL.html,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- PROPOSAL.html 22 Feb 2002 17:38:40 -  1.1
  +++ PROPOSAL.html 8 Nov 2002 22:26:13 -   1.2
  @@ -58,7 +58,7 @@
   
   (4) Initial Committers
   
  -The initial committers on the IO component shall be:
  +The initial committers on the @package@ component shall be:
   
 Your name here
   
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-commons/httpclient/src/test/org/apache/commons/httpclient TestMethodsRedirectNoHost.java

[jsdever]

jsdever 2002/11/08 14:25:08

  Modified:httpclient/src/java/org/apache/commons/httpclient
HttpMethodBase.java
   httpclient/src/test/org/apache/commons/httpclient
TestMethodsRedirectNoHost.java
  Log:
  Fix HttpUrlException being thrown incorrectly on redirects.
  Reported by Danny Burkes.
  
  Revision  ChangesPath
  1.77  +8 -7  
jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/HttpMethodBase.java
  
  Index: HttpMethodBase.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/HttpMethodBase.java,v
  retrieving revision 1.76
  retrieving revision 1.77
  diff -u -r1.76 -r1.77
  --- HttpMethodBase.java   31 Oct 2002 07:45:34 -  1.76
  +++ HttpMethodBase.java   8 Nov 2002 22:25:07 -   1.77
  @@ -904,7 +904,7 @@
   URL currentUrl = null; 
   
   try {
  -currentUrl = new URL(conn.getProtocol(), 
  +currentUrl = new URL(conn.getProtocol().toLowerCase(), 
   conn.getHost(), conn.getPort(), "");
   redirectUrl = new URL(location);
   } catch (MalformedURLException e) {
  @@ -914,6 +914,7 @@
   return false; 
   } else { //location is incomplete, use current values for defaults
   try {
  +log.debug("Redirect URL is not absolute - parsing as relative");
   redirectUrl = new URL(currentUrl, location);
   } catch (MalformedURLException ex) {
   log.warn("Redirected location '" + location
  @@ -959,8 +960,8 @@
   throws HttpException {
   log.trace("enter HttpMethodBase.checkValidRedirect(HttpConnection, URL)");
   
  -String oldProtocol = currentUrl.getProtocol().toLowerCase();
  -String newProtocol = redirectUrl.getProtocol().toLowerCase();
  +String oldProtocol = currentUrl.getProtocol();
  +String newProtocol = redirectUrl.getProtocol();
   if (! oldProtocol.equals(newProtocol)) {
   throw new HttpException("Redirect from protocol " + oldProtocol
   + " to " + newProtocol + " is not supported");
  
  
  
  1.2   +17 -4 
jakarta-commons/httpclient/src/test/org/apache/commons/httpclient/TestMethodsRedirectNoHost.java
  
  Index: TestMethodsRedirectNoHost.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/httpclient/src/test/org/apache/commons/httpclient/TestMethodsRedirectNoHost.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- TestMethodsRedirectNoHost.java31 Oct 2002 07:45:35 -  1.1
  +++ TestMethodsRedirectNoHost.java8 Nov 2002 22:25:08 -   1.2
  @@ -126,6 +126,19 @@
   assertEquals("/newfile", method.getPath());
   
   }
  +public void testRedirectIgnoreCase() throws Exception {
  +addRedirectResponse("HtTP://localhost/newfile";);
  +addOkResponse();
  +conn.open();
  +
  +HttpMethod method = new SimpleHttpMethod("/oldfile");
  +method.setFollowRedirects(true);
  +method.execute(new HttpState(), conn);
  +Header locationHeader = method.getResponseHeader("Location");
  +assertEquals(200, method.getStatusCode());
  +assertEquals("/newfile", method.getPath());
  +
  +}
   
   
   public void testPostRedirect() throws Exception {
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-commons-sandbox/proposal HOW-TO-USE.txt

[bayard]

bayard  2002/11/08 14:24:38

  Added:   proposal HOW-TO-USE.txt
  Log:
  Added a quick piece of documentation telling people how to run the
  proposal generator. Just so they don't have to go hunting into build.xml and
  realise it's not a template like the other classes etc.
  
  Revision  ChangesPath
  1.1  jakarta-commons-sandbox/proposal/HOW-TO-USE.txt
  
  Index: HOW-TO-USE.txt
  ===
  The Proposal project is used to generate out new proejcts in the 
  commons-sandbox. It is run by invoking:
  
  ant -Dpackage=name_of_project
  
  where name_of_project is replaced with your project name.
  
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 14262] - SAXBeanWriter produces invalid XML

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=14262

SAXBeanWriter produces invalid XML

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2002-11-08 22:18 ---
Fixed in cvs.. 
Harald can you please confirm this works ok for you?
Notes :
The SAXBeanWriter was incorrectly creating xml content, esp. body text was 
misplaced. Fixed this  and added a SAXContentHanlder and TestSaxBeanWriter.
Many thanks go to Harald Dietrich (contact at hdietrich.net) for providing the 
test cases and a use scenario. 
I removed the dependency on XMLSerializer (for people using Crimson ;) and made 
another ContentHandler to prove it is working.
(the code with XMLSerializer also works though). I also removed a failure 
taking place on the #text node, since those nodes cannot be avoided (thnx jt..)

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 14263] - BeanReader returns no object when used with SAXParser

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=14263

BeanReader returns no object when used with SAXParser

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||WORKSFORME



--- Additional Comments From [EMAIL PROTECTED]  2002-11-08 22:16 ---
I will put this on worksforme. If you can come with a reproducable testcase 
again which failes, then reopen it. You can always contact the mailinglist to 
further narrow down your problem.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/io SAXContentHandler.java TestSAXBeanWriter.java

[mvdb]

mvdb2002/11/08 14:09:01

  Modified:betwixt/src/java/org/apache/commons/betwixt/io
SAXBeanWriter.java
  Added:   betwixt/src/test/org/apache/commons/betwixt/io
SAXContentHandler.java TestSAXBeanWriter.java
  Log:
  The SAXBeanWriter was incorrectly creating xml content, esp. body text was 
misplaced. Fixed this  and added a SAXContentHanlder and TestSaxBeanWriter.
  Many thanks go to Harald Dietrich (contact at hdietrich.net) for providing the test 
cases and a use scenario. 
  I removed the dependency on XMLSerializer (for people using Crimson ;) and made 
another ContentHandler to prove it is working.
  (the code with XMLSerializer also works though). I also removed a failure taking 
place on the #text node, since those nodes cannot be avoided (thnx jt..)
  
  Revision  ChangesPath
  1.4   +32 -35
jakarta-commons/betwixt/src/java/org/apache/commons/betwixt/io/SAXBeanWriter.java
  
  Index: SAXBeanWriter.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/betwixt/src/java/org/apache/commons/betwixt/io/SAXBeanWriter.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- SAXBeanWriter.java19 Jul 2002 00:54:55 -  1.3
  +++ SAXBeanWriter.java8 Nov 2002 22:09:01 -   1.4
  @@ -61,26 +61,10 @@
*/
   package org.apache.commons.betwixt.io;
   
  -import java.beans.IntrospectionException;
  -import java.io.BufferedWriter;
  -import java.io.IOException;
  -import java.io.OutputStream;
  -import java.io.OutputStreamWriter;
  -import java.io.Writer;
  -import java.util.Iterator;
  -import java.util.HashMap;
  +import java.util.Stack;
   
   import org.apache.commons.logging.Log;
   import org.apache.commons.logging.LogFactory;
  -
  -import org.apache.commons.betwixt.AttributeDescriptor;
  -import org.apache.commons.betwixt.ElementDescriptor;
  -import org.apache.commons.betwixt.XMLBeanInfo;
  -import org.apache.commons.betwixt.XMLIntrospector;
  -import org.apache.commons.betwixt.expression.Context;
  -import org.apache.commons.betwixt.expression.Expression;
  -import org.apache.commons.betwixt.io.id.SequentialIDGenerator;
  -
   import org.xml.sax.ContentHandler;
   import org.xml.sax.SAXException;
   import org.xml.sax.helpers.AttributesImpl;
  @@ -100,10 +84,15 @@
   /** Where the output goes */
   private ContentHandler contentHandler;
   /** Log used for logging (Doh!) */
  -private Log log = LogFactory.getLog( BeanWriter.class );
  +private Log log = LogFactory.getLog( SAXBeanWriter.class );
   
   private String lastElementName;
   
  +/**
  + * Place holder for elements that are started.
  + */
  +private Stack elementStack;
  +
   private AttributesImpl attributes;
   
   private boolean elementWaiting = false;
  @@ -141,12 +130,15 @@
   
   /** Express an element tag start using given qualified name */
   protected void expressElementStart(String qualifiedName) throws SAXException  {
  -// make sure any previous elements have been sent
  -sendElementStart();
  -// ok prepare for new one
  -elementWaiting = true;
  +if (elementStack == null) {
  +elementStack = new Stack();
  +}
  +if (elementWaiting) {
  +sendElementStart();
  +}
   attributes = new AttributesImpl();
  -lastElementName = qualifiedName;
  +elementStack.push(qualifiedName);
  +elementWaiting = true;
   }
   
   protected void expressTagClose() {
  @@ -156,8 +148,10 @@
   
   /** Express an element end tag using given qualifiedName */
   protected void expressElementEnd(String qualifiedName) throws SAXException  {
  -// make sure that we sent the last element to be handled
  -sendElementStart();
  +if (elementWaiting) {
  +elementWaiting = false;
  +sendElementStart();
  +}
   // can't handle namespaces yet
   contentHandler.endElement("","",qualifiedName);
   }
  @@ -165,7 +159,8 @@
   /** Express an empty element end */
   protected void expressElementEnd() throws SAXException  {
   // last element name must be correct since there haven't been any tag in 
between
  -contentHandler.endElement("","",lastElementName);
  +String lastElement = (String) elementStack.peek();
  +contentHandler.endElement("","",lastElement);
   }
   
   /** Express body text */
  @@ -173,6 +168,10 @@
   // FIX ME
   // CHECK UNICODE->CHAR CONVERSION!
   // THIS WILL QUITE POSSIBLY BREAK FOR NON-ROMAN
  +if (elementWaiting) {
  +elementWaiting = false;
  +sendElementStart();
  +}
   char[] body = text.toCharArray();
   contentHandler.chara

RE: [jdbc] JdbcUtil etc

[Henri Yandell]

On Fri, 8 Nov 2002, Steven Caswell wrote:

> I don't know of anything that already exists, and I've looked around
> Jakarta a little bit to find one. I'd love to see a jdbc subproject.
> I've got a few things I could throw in as well. So I'm +1 that such
> a thing should exist, +1 for calling it jdbc and +1 for separating
> this kind of stuff from the current sql project (I agree, the sql
> project is different stuff).

Works for me as a sanity check :) I'm not insane! woo. maybe.

I'll write a proposal and add a jdbc project with some initial code
tonight/this w/e. You okay to be an initial committer on it?

Hen


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [jdbc] JdbcUtil etc

[Steven Caswell]

> -Original Message-
> From: Henri Yandell [mailto:bayard@;generationjava.com] 
> Sent: Friday, November 08, 2002 1:17 PM
> To: Jakarta Commons Developers List
> Subject: [jdbc] JdbcUtil etc
> 
> 
> 
> Does anyone know of a good apache-style license set of 
> classes for helping with JDBC stuff?
> 
> I'm thinking of things like:
> 
> 1) A JdbcUtils which helps with closing rs, stat, conn. That 
> simplifies MetaData work, that has a ResultSetIterator [yes I 
> know BeanUtils has one of these, it's misplaced I think].
> 
> 2) A sequence-number handler. Something that is very generic 
> and configurable at runtime. The code is out there it seems, 
> but stuck inside things like object-bridge and other large projects.
> 
> 3) Possibly a continuation of the ResultSetIterator. A 
> java.util.Collection structure for viewing a JDBC connection.
> 
> 4) An empty Driver wrapper set for people wanting to make 
> quick hacks to their driver. For example, Oracle's latest 
> driver has some crap with Timestamp. Easiest solution for me 
> would be to take Commons JDBC Standard Wrapper Driver, extend 
> ResultSet and convert an oracle.sql.Timestamp to 
> java.sql.Timestamp without anyone noticing.
> 
> 5) ??
> 
> Does such a thing exist?
> Should it exist?
> 
> Should it be in sql? [I think not, unless the current sql 
> wants a new name
> :) sql seems to be concerned with other things]
> 
> Should ti be called jdbc?
> 
> I've got some bits that I can start with, so am happy to make 
> a proposal in sandbox, but thought I'd check no one has 
> invented the wheel before.

I don't know of anything that already exists, and I've looked around
Jakarta a little bit to find one. I'd love to see a jdbc subproject.
I've got a few things I could throw in as well. So I'm +1 that such
a thing should exist, +1 for calling it jdbc and +1 for separating
this kind of stuff from the current sql project (I agree, the sql
project is different stuff).

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



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 14398] New: - Add an email validator

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=14398

Add an email validator

   Summary: Add an email validator
   Product: Commons
   Version: unspecified
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: Validator
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Even if it may sound simple to implement, it would be a good thing to add an 
email validator such as there is already a credit card validator.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/io - New directory

[mvdb]

mvdb2002/11/08 13:45:12

  jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/io - New directory

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-commons-sandbox/jrcs/src/java/org/apache/commons/jrcs/rcs Archive.java

[juanco]

juanco  2002/11/08 13:29:34

  Modified:jrcs/src/java/org/apache/commons/jrcs/rcs Archive.java
  Log:
  Added method to retreive log message associated with a given revision.
  
  Submitted by:Kyrre Kristiansen [[EMAIL PROTECTED]]
  Reviewed by:  [EMAIL PROTECTED]
  
  Revision  ChangesPath
  1.4   +30 -1 
jakarta-commons-sandbox/jrcs/src/java/org/apache/commons/jrcs/rcs/Archive.java
  
  Index: Archive.java
  ===
  RCS file: 
/home/cvs/jakarta-commons-sandbox/jrcs/src/java/org/apache/commons/jrcs/rcs/Archive.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- Archive.java  8 Oct 2002 19:06:24 -   1.3
  +++ Archive.java  8 Nov 2002 21:29:34 -   1.4
  @@ -1194,6 +1194,35 @@
   
   return (Node[]) result.toArray(new Node[result.size()]);
   }
  +
  +
  +/** Returns the log message associated with the given revision.
  + *  @param version - the version to get the log message for
  + *   @return the log message for the version.
  + *  @exception - if the version does not exist for the archive.
  + */
  +public String getLog(Version version) 
  +throws NodeNotFoundException
  +{
  +Node node = this.findNode(version);
  +if (node == null) 
  +{
  +throw new NodeNotFoundException("There's no version " + version);
  +}
  +return node.getLog();
  +}
  +
  +/** Returns the log message associated with the given revision.
  + *  @param version - the version to get the log message for
  + *   @return the log message for the version.
  + *  @exception - if the version does not exist for the archive.
  + */
  +public String getLog(String vernum) 
  +throws InvalidVersionNumberException, NodeNotFoundException
  +{
  +return getLog(new Version(vernum));
  +}
  +
   }
   
   
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: installing jakarta code Was: using commons components and logging

[Henri Yandell]

On Fri, 8 Nov 2002, Steven Caswell wrote:

>
> > -Original Message-
> > From: Henri Yandell [mailto:bayard@;generationjava.com]
> >
> > So you suggest that we no longer create zips/tar.gz's and
> > just put jars on a Maven repository and tell everyone that to
> > use a library they must build with Maven?
>
> Maven will generate the zips/tar.gz's, so others can still download the
> full distribution. Having [lang] mavenized would not force other
> projects to mavenize just to use the [lang] library.

That's the rub. Full distribution. I want something downloads the
dependencies as well, not just the lang distro but also anything that lang
is dependent on.

Maybe this means a better page than the current download page where users
just click from a list, something where you select something to download
and after you click on that it takes you to a page which lists the
dependencies and says 'do you have all of these?'.



> > What I'm looking for are ideas that will work with the
> > existing structure and not revolutions :) So, how can we
> > re-package our current code so that user's don't plough
> > every-time into the dependency hunt.
> >
>
> I believe Maven provides a great solution to this issue. The site that
> Maven generates does contain a list of a project release's dependencies
> (not that [lang] has any, but this is a nice standard place for a
> project to publish it's dependency list). Personally I'd love to see all
> of commons migrate toward Maven, for this very reason. It provides
> standard documentation and a standard way to build projects.

It still is far away in this respect though. The site has no standardised
download ability. [I'd love to add such a thing, and hope that a thread
like this could decide what that standardised downloading is.]

> And for a project like [lang], Maven is not all that revolutionary. I
> Mavenized a similar commons-type project at my work with very little
> effort. And the bang for the buck was incredible.

Agreed. Lang is mavenised, I use maven at work now accross the board.
Gotta learn reactor though still.

However, Maven isn't really the solution here. We have to assume that our
users are not using Maven. Thus we need to offer a download/install
process which handles the dependency issue without forcing them to enter
the maven-user world.

The fact that thigns like Collections are not wanting to be dependent on
another project [ie Lang] because it confuses the user is a sign that
somethign is very wrong.

Hen


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: installing jakarta code Was: using commons components and logging

[Steven Caswell]

> -Original Message-
> From: Henri Yandell [mailto:bayard@;generationjava.com] 
> Sent: Friday, November 08, 2002 3:55 PM
> To: Jakarta Commons Developers List
> Subject: Re: installing jakarta code Was: using commons 
> components and logging
> 
> 
> 
> So you suggest that we no longer create zips/tar.gz's and 
> just put jars on a Maven repository and tell everyone that to 
> use a library they must build with Maven?

Maven will generate the zips/tar.gz's, so others can still download the
full distribution. Having [lang] mavenized would not force other
projects to mavenize just to use the [lang] library.

> 
> I think Maven could help with this, or a similar tool, but in 
> a different way. When the tool creates our distribution, it 
> also creates an ant file which contains the dependencies that 
> are needed and can be run.
> 
> ant -f get_dependencies.xml
> 
> this sucks each dependency down [no project.xml remember, 
> it's just a part of the tar.gz] and puts them in a directory 
> called 'dependencies' or 'lib' or something.
> 
> It can happily use the maven biblio, though that implies that 
> a much faster build -> maven repo turn around is needed.
> 
> What I'm looking for are ideas that will work with the 
> existing structure and not revolutions :) So, how can we 
> re-package our current code so that user's don't plough 
> every-time into the dependency hunt.
> 

I believe Maven provides a great solution to this issue. The site that
Maven generates does contain a list of a project release's dependencies
(not that [lang] has any, but this is a nice standard place for a
project to publish it's dependency list). Personally I'd love to see all
of commons migrate toward Maven, for this very reason. It provides
standard documentation and a standard way to build projects.

And for a project like [lang], Maven is not all that revolutionary. I
Mavenized a similar commons-type project at my work with very little
effort. And the bang for the buck was incredible.

> 
> Hen
> 
> On Sat, 9 Nov 2002 [EMAIL PROTECTED] wrote:
> 
> > Henri Yandell <[EMAIL PROTECTED]> wrote on 
> 08/11/2002 01:28:26 
> > PM:
> >
> > >
> > > There has got to be a better way for us to handle installs and 
> > > cross-dependencies, withing Commons and within Jakarta 
> projects. It 
> > > has
> > to
> > > be the number one problem that users have.
> >
> > Hence the development of Maven.
> >
> > >
> > > Hen
> > --
> > dIon Gillard, Multitask Consulting
> > Work:  http://www.multitask.com.au
> > Developers: http://adslgateway.multitask.com.au/developers
> >
> >
> > --
> > To unsubscribe, e-mail:   
>  [EMAIL PROTECTED]>
> > For 
> additional commands, 
> e-mail: 
> > 
> >
> >
> 
> 
> --
> To unsubscribe, e-mail:   
>  [EMAIL PROTECTED]>
> For 
> additional commands, 
> e-mail: 
> 
> 

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



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [jxpath] setValue calling getValue

[Ext-Mike.Hogan]

Hi Dmitri,

I retried with the the version at the URL you sent. Different stack trace, but the 
field still gets read.

java.lang.Exception
at 
com.nokia.b2t.dna.graphmap.MockDomainObject.getStringField(MockDomainObject.java:51)
at java.lang.reflect.Method.invoke(Native Method)
at org.apache.commons.jxpath.util.ValueUtils.getValue(ValueUtils.java:287)
at 
org.apache.commons.jxpath.ri.model.beans.BeanPropertyPointer.getBaseValue(BeanPropertyPointer.java:155)
at 
org.apache.commons.jxpath.ri.model.beans.BeanPropertyPointer.getNode(BeanPropertyPointer.java:179)
at 
org.apache.commons.jxpath.ri.model.beans.PropertyPointer.getValuePointer(PropertyPointer.java:168)
at 
org.apache.commons.jxpath.ri.axes.SimplePathInterpreter.valuePointer(SimplePathInterpreter.java:675)
at 
org.apache.commons.jxpath.ri.axes.SimplePathInterpreter.interpretSimpleLocationPath(SimplePathInterpreter.java:114)
at 
org.apache.commons.jxpath.ri.compiler.Path.getSingleNodePointerForSteps(Path.java:172)
at 
org.apache.commons.jxpath.ri.compiler.LocationPath.computeValue(LocationPath.java:137)
at 
org.apache.commons.jxpath.ri.JXPathContextReferenceImpl.setValue(JXPathContextReferenceImpl.java:363)
at 
org.apache.commons.jxpath.ri.JXPathContextReferenceImpl.createPathAndSetValue(JXPathContextReferenceImpl.java:354)
at 
org.apache.commons.jxpath.ri.JXPathContextReferenceImpl.createPathAndSetValue(JXPathContextReferenceImpl.java:349)
at 
com.nokia.b2t.dna.graphmap.ObjectGraphMapper.performMapping(ObjectGraphMapper.java:92)
at 
com.nokia.b2t.dna.graphmap.ObjectGraphMapper.toDomainGraph(ObjectGraphMapper.java:57)
at 
com.nokia.b2t.dna.graphmap.ObjectGraphMapperJUnitTest.main(ObjectGraphMapperJUnitTest.java:136)

> -Original Message-
> From: ext Dmitri Plotnikov [mailto:dplotnik@;yahoo.com]
> Sent: 08. November 2002 19:53
> To: Jakarta Commons Developers List
> Subject: Re: [jxpath] setValue calling getValue
> 
> 
> Mike,
> 
> You are right, it really should not do that.
> 
> The line numbers in the stack trace indicate that you are using a
> pretty old version of jxpath. Could you upgrade to the current version
> and let me know if the problem persists?
> 
> The binary download is available at
> www.plotnix.com/jxpath/commons-jxpath.zip
> 
> Thank you,
> 
> - Dmitri
> 
> --- [EMAIL PROTECTED] wrote:
> > Hi,
> > 
> > When JXPath is setting a property, it first gets the 
> properties value
> > (computeValue()).  I have an throwing an exception in the getter
> > method in my class to show the stack trace, below.
> > 
> > Why does JXPath read the value before setting it, and is there any
> > way to avoid it?
> > 
> > Thanks,
> > Mike.
> > 
> > java.lang.Exception: Reading field
> > at
> >
> com.nokia.b2t.dna.graphmap.MockDomainObject$MockNestedDomainOb
> ject.getStringField(MockDomainObject.java:76)
> > at java.lang.reflect.Method.invoke(Native Method)
> > at
> >
> org.apache.commons.jxpath.util.ValueUtils.getValue(ValueUtils.
> java:287)
> > at
> >
> org.apache.commons.jxpath.ri.model.beans.BeanPropertyPointer.g
> etNodeValue(BeanPropertyPointer.java:187)
> > at
> >
> org.apache.commons.jxpath.ri.model.beans.PropertyPointer.getVa
> luePointer(PropertyPointer.java:152)
> > at
> >
> org.apache.commons.jxpath.ri.axes.SimplePathInterpreter.single
> Step(SimplePathInterpreter.java:246)
> > at
> >
> org.apache.commons.jxpath.ri.axes.SimplePathInterpreter.interp
> retPath(SimplePathInterpreter.java:119)
> > at
> >
> org.apache.commons.jxpath.ri.compiler.Path.getSingleNodePointe
> rForSteps(Path.java:162)
> > at
> >
> org.apache.commons.jxpath.ri.compiler.LocationPath.computeValu
> e(LocationPath.java:137)
> > at
> >
> org.apache.commons.jxpath.ri.JXPathContextReferenceImpl.setVal
> ue(JXPathContextReferenceImpl.java:329)
> > at
> >
> org.apache.commons.jxpath.ri.JXPathContextReferenceImpl.create
> PathAndSetValue(JXPathContextReferenceImpl.java:320)
> > at
> >
> org.apache.commons.jxpath.ri.JXPathContextReferenceImpl.create
> PathAndSetValue(JXPathContextReferenceImpl.java:315)
> > at
> >
> com.nokia.b2t.dna.graphmap.ObjectGraphMapper.performMapping(Ob
> jectGraphMapper.java:88)
> > at
> >
> com.nokia.b2t.dna.graphmap.ObjectGraphMapper.toDomainGraph(Obj
> ectGraphMapper.java:57)
> > at
> >
> com.nokia.b2t.dna.graphmap.ObjectGraphMapperJUnitTest.main(Obj
> ectGraphMapperJUnitTest.java:122)
> > 
> > --
> > To unsubscribe, e-mail:  
> > 
> > For additional commands, e-mail:
> > 
> > 
> 
> 
> __
> Do you Yahoo!?
> U2 on LAUNCH - Exclusive greatest hits videos
> http://launch.yahoo.com/u2
> 
> --
> To unsubscribe, e-mail:   
> 
> For additional commands, e-mail: 
> 

RE: [Lang] Release 1.1? [wasRe: [Lang] Please fix this]

[Martin Cooper]

> -Original Message-
> From: Henri Yandell [mailto:bayard@;generationjava.com]
> Sent: Friday, November 08, 2002 11:49 AM
> To: Jakarta Commons Developers List
> Subject: Re: [Lang] Release 1.1? [wasRe: [Lang] Please fix this]
> 
> 
> 
> 
> On Fri, 8 Nov 2002, Steve Downey wrote:
> 
> > If we'd spotted the maximum() bug before release, it would 
> have stopped the
> > release. Fixing showstopper bugs is good cause for a bug 
> fix release. And
> > it's not that hard:
> >
> > cvs tag -b -r LANG_1_0 LANG_1_0_BRANCH lang
> 
> Ah. I've always branched HEAD, so was gonna have to look up how to do
> this. Thanks :)
> 
> 
> So that's a positive reply for a 1.0.1 rather than a 1.1. Any 
> other views?

+1 (non-binding, of course :) for a 1.0.1 bug-fix release ASAP.

--
Martin Cooper


> 
> Hen
> 
> 
> --
> To unsubscribe, e-mail:   

For additional commands, e-mail:




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [Lang] Release 1.1? [wasRe: [Lang] Please fix this]

[Steven Caswell]

+1 for choice #2


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


> -Original Message-
> From: Henri Yandell [mailto:bayard@;generationjava.com] 
> Sent: Friday, November 08, 2002 10:49 AM
> To: Jakarta Commons Developers List
> Subject: Re: [Lang] Release 1.1? [wasRe: [Lang] Please fix this]
> 
> 
> 
> They seem to be the choices.
> 
> We have:
> 
> 1)
> 1.0.1 release asap. This includes the NumericRange bugfix and 
> any other bugfixes that can be dredged together. A branch 
> would be made of tag LANG_1_0 and the bugfixes retroactively applied.
> 
> 2)
> 
> 1.1 release in slightly more time. We look to make a release 
> with new functionality. We ignore certain elements if they 
> are not wanting to go out, ie) functor/reflect, but 
> everything else goes out.
> 
> 
> Postives for 1) are, we get it out quicker, but it's a lot 
> more fiddly and involves a fair amount of time.
> 
> Positives for 2) are, we continue our desire to release 
> often, and we get other fixes out etc. Rather than fiddling 
> around branching we spend time learning our process for a 2nd 
> release [ie) a lot of the 1.0 release things were special as 
> they were the first time].
> 
> 
> I'm +1 for 2).
> 
> Hen
> 
> 
> 
> 
> On Fri, 8 Nov 2002 [EMAIL PROTECTED] wrote:
> 
> > I would support a release (1.1 or 1.0.1?)
> >
> > I haven't yet had a chance to review the functor package now its in 
> > [lang] (I'm away from home on business ATM).
> >
> > ClassUtils, ArrayUtils and all of the reflect package should be 
> > excluded at present.
> >
> > A few other bugs have been sorted too. It would be good to 
> see a list 
> > of changes from 1.0.
> >
> > IMHO, we should wait a week or so to allow more chance to look at 
> > functor, and then make a 1.1 release if its all OK.
> >
> > Stephen
> >
> >
> > >  from:robert burrell donkin 
> <[EMAIL PROTECTED]>
> > >  date:Thu, 07 Nov 2002 20:08:09
> > >  to:  [EMAIL PROTECTED]
> > >  subject: Re: [Lang] Please fix this
> > >
> > > i feel very strongly that the code in reflect is not ready to be 
> > > released.
> > >
> > > in particular, i would not like to see the current method 
> names and 
> > > structure become fixed by future requirements for backwards 
> > > compatibility
> > > (just) yet.
> > >
> > > (gorden bennett! i've only made one commit and i'm 
> already sounding 
> > > like i own the shop ;)
> > >
> > > - robert
> > >
> > > On Thursday, November 7, 2002, at 07:15 PM, Steve Downey wrote:
> > >
> > > > I agree that CVS head is not in a releaseable state. 
> But the bug 
> > > > is fairly compelling. I think releasing off a branch from the 
> > > > release tag is the best solution.
> > > >
> > > > On Thursday 07 November 2002 12:05 pm, Henri Yandell wrote:
> > > >> Fixed in CVS, so will be in the nightly build tonight 
> at the very 
> > > >> least. And UnitTest made so Max and Min are being tested.
> > > >>
> > > >> Any views out there on the merits of a release?
> > > >>
> > > >> My judgement is that the current CVS tree is not 
> releasable, so 
> > > >> it would be a question of releasing against the tag.
> > > >>
> > > >> Any other bugs that should be included?
> > > >>
> > > >> Hen
> > > >>
> > > >> On Thu, 7 Nov 2002, [ISO-8859-1] Kasper Rönning wrote:
> > > >>> Quite a bug in Commons-Lang: class NumberRange, method 
> > > >>> geMaximum() returns minimum. Could you make a new release?
> > > >>>
> > > >>> /Kasper Ronning
> > > >>>
> > > >>>
> > > >>> --
> > > >>> To unsubscribe, e-mail: 
> > > >>>  For 
> > > >>> additional commands, e-mail: 
> > > >>> 
> > > >
> > > >
> > > > --
> > > > To unsubscribe, e-mail:   
>  [EMAIL PROTECTED]
> > > > org>
> > 
> > > For additional 
> commands, e-mail: 
> > > >  > > > org>
> > > >
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:   
>  [EMAIL PROTECTED]>
> > > For 
> additional commands, e-mail: 
> > > 
> > >
> >
> >
> > --
> > To unsubscribe, e-mail:   
>  [EMAIL PROTECTED]>
> > For 
> additional commands, 
> e-mail: 
> > 
> >
> >
> 
> 
> --
> To unsubscribe, e-mail:   
>  [EMAIL PROTECTED]>
> For 
> additional commands, 
> e-mail: 
> 
> 



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: installing jakarta code Was: using commons components and logging

[Henri Yandell]

So you suggest that we no longer create zips/tar.gz's and just put jars on
a Maven repository and tell everyone that to use a library they must build
with Maven?

I think Maven could help with this, or a similar tool, but in a different
way. When the tool creates our distribution, it also creates an ant file
which contains the dependencies that are needed and can be run.

ant -f get_dependencies.xml

this sucks each dependency down [no project.xml remember, it's just a part
of the tar.gz] and puts them in a directory called 'dependencies' or 'lib'
or something.

It can happily use the maven biblio, though that implies that a much
faster build -> maven repo turn around is needed.

What I'm looking for are ideas that will work with the existing structure
and not revolutions :) So, how can we re-package our current code so that
user's don't plough every-time into the dependency hunt.


Hen

On Sat, 9 Nov 2002 [EMAIL PROTECTED] wrote:

> Henri Yandell <[EMAIL PROTECTED]> wrote on 08/11/2002 01:28:26 PM:
>
> >
> > There has got to be a better way for us to handle installs and
> > cross-dependencies, withing Commons and within Jakarta projects. It has
> to
> > be the number one problem that users have.
>
> Hence the development of Maven.
>
> >
> > Hen
> --
> dIon Gillard, Multitask Consulting
> Work:  http://www.multitask.com.au
> Developers: http://adslgateway.multitask.com.au/developers
>
>
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
>
>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: installing jakarta code Was: using commons components and logging

[dion]

Henri Yandell <[EMAIL PROTECTED]> wrote on 08/11/2002 01:28:26 PM:

> 
> There has got to be a better way for us to handle installs and
> cross-dependencies, withing Commons and within Jakarta projects. It has 
to
> be the number one problem that users have.

Hence the development of Maven.

> 
> Hen
--
dIon Gillard, Multitask Consulting
Work:  http://www.multitask.com.au
Developers: http://adslgateway.multitask.com.au/developers


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [Lang] Release 1.1? [wasRe: [Lang] Please fix this]

[Henri Yandell]

On Fri, 8 Nov 2002, Steve Downey wrote:

> If we'd spotted the maximum() bug before release, it would have stopped the
> release. Fixing showstopper bugs is good cause for a bug fix release. And
> it's not that hard:
>
> cvs tag -b -r LANG_1_0 LANG_1_0_BRANCH lang

Ah. I've always branched HEAD, so was gonna have to look up how to do
this. Thanks :)


So that's a positive reply for a 1.0.1 rather than a 1.1. Any other views?

Hen


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 14394] New: - Excessive exceptions log under security manager

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=14394

Excessive exceptions log under security manager

   Summary: Excessive exceptions log under security manager
   Product: Commons
   Version: 1.5 Final
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Bean Utilities
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I'm currently forced to use BeanUtils/Struts under the J2EE-RI server, which by
default has much a stricter security policy than Tomcat etc. To my surprise,
this resulted in an initial 400+kB of logs generated, filled with
AccessControlExceptions including stack traces, and always the same. Apparently
during Struts parsing it's config file using Digester, and thus BeanUtils.

However, the problem does *not* at all hurt the functionality of the
application. IMHO, the exception should just be logged once (on first
encounter). There could be a static boolean variable to indicated the situation
for further invocations.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 13235] - referenced UserPassKey instances get erroneously returned to the pool and subsequently reinitialized

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=13235

referenced UserPassKey instances get erroneously returned to the pool and subsequently 
reinitialized





--- Additional Comments From [EMAIL PROTECTED]  2002-11-08 19:39 ---
There are several aspects of Jdbc2PoolDataSource that I'm not sure I fully 
grok, and your analysis makes sense to me, but I'm having trouble reproducing 
an actual problem here (and I'm loathe to change this without some test case 
that fails).

Can you provide details on the configuration and driver program that leads to 
the output you posted?

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-commons/dbcp/src/test/org/apache/commons/dbcp/jdbc2pool TestJdbc2PoolDataSource.java

[rwaldhoff]

rwaldhoff2002/11/08 11:37:26

  Modified:dbcp/src/test/org/apache/commons/dbcp
TestConnectionPool.java
   dbcp/src/test/org/apache/commons/dbcp/jdbc2pool
TestJdbc2PoolDataSource.java
  Log:
  additional tests (attempting unsuccessfully to recreate bug # 13235)
  
  Revision  ChangesPath
  1.3   +19 -4 
jakarta-commons/dbcp/src/test/org/apache/commons/dbcp/TestConnectionPool.java
  
  Index: TestConnectionPool.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/dbcp/src/test/org/apache/commons/dbcp/TestConnectionPool.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- TestConnectionPool.java   8 Nov 2002 19:17:24 -   1.2
  +++ TestConnectionPool.java   8 Nov 2002 19:37:26 -   1.3
  @@ -169,6 +169,21 @@
   conn.close();
   }
   
  +public void testRepeatedBorrowAndReturn() throws Exception {
  +for(int i=0;i<100;i++) {
  +Connection conn = getConnection();
  +assertTrue(null != conn);
  +PreparedStatement stmt = conn.prepareStatement("select * from dual");
  +assertTrue(null != stmt);
  +ResultSet rset = stmt.executeQuery();
  +assertTrue(null != rset);
  +assertTrue(rset.next());
  +rset.close();
  +stmt.close();
  +conn.close();
  +}
  +}
  +
   public void testSimple2() throws Exception {
   Connection conn = getConnection();
   assertTrue(null != conn);
  
  
  
  1.3   +9 -7  
jakarta-commons/dbcp/src/test/org/apache/commons/dbcp/jdbc2pool/TestJdbc2PoolDataSource.java
  
  Index: TestJdbc2PoolDataSource.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/dbcp/src/test/org/apache/commons/dbcp/jdbc2pool/TestJdbc2PoolDataSource.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- TestJdbc2PoolDataSource.java  8 Nov 2002 18:51:07 -   1.2
  +++ TestJdbc2PoolDataSource.java  8 Nov 2002 19:37:26 -   1.3
  @@ -87,7 +87,7 @@
   }
   
   protected Connection getConnection() throws Exception {
  -return ds.getConnection();
  +return ds.getConnection("foo","bar");
   }
   
   private DataSource ds;
  @@ -97,12 +97,14 @@
   pcds.setDriver("org.apache.commons.dbcp.TesterDriver");
   pcds.setUrl("jdbc:apache:commons:testdriver");
   pcds.setUser("foo");
  -pcds.setPassword(null);
  +pcds.setPassword("bar");
   
   Jdbc2PoolDataSource tds = new Jdbc2PoolDataSource();
   tds.setConnectionPoolDataSource(pcds);
   tds.setDefaultMaxActive(getMaxActive());
  -tds.setDefaultMaxWait((int) (getMaxWait()));
  +tds.setDefaultMaxWait((int)(getMaxWait()));
  +tds.setPerUserMaxActive("foo",new Integer(getMaxActive()));
  +tds.setPerUserMaxWait("foo",new Integer((int)(getMaxWait(;
   
   ds = tds;
   }
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [Lang] Release 1.1? [wasRe: [Lang] Please fix this]

[Steve Downey]

StringUtils is binary incompatible with the 1.0 version of StringUtils, so it 
certainly isn't 1.0.1. 

Plus, I've never liked mixing bugfix releases in with new functionality, which 
always imply new bugs. 

If we'd spotted the maximum() bug before release, it would have stopped the 
release. Fixing showstopper bugs is good cause for a bug fix release. And 
it's not that hard:

cvs tag -b -r LANG_1_0 LANG_1_0_BRANCH lang

cvs co -r LANG_1_0_BRANCH -d lang_1_0_branch lang

cd lang_1_0_branch


ant build
ant test
cvs commit


cvs commit

then it's like doing any release. Tag it with LANG_1_0_1. 


On Friday 08 November 2002 10:07 am, [EMAIL PROTECTED] wrote:
> I would support a release (1.1 or 1.0.1?)
>
> I haven't yet had a chance to review the functor package now its in [lang]
> (I'm away from home on business ATM).
>
> ClassUtils, ArrayUtils and all of the reflect package should be excluded at
> present.
>
> A few other bugs have been sorted too. It would be good to see a list of
> changes from 1.0.
>
> IMHO, we should wait a week or so to allow more chance to look at functor,
> and then make a 1.1 release if its all OK.
>
> Stephen
>
> >  from:robert burrell donkin <[EMAIL PROTECTED]>
> >  date:Thu, 07 Nov 2002 20:08:09
> >  to:  [EMAIL PROTECTED]
> >  subject: Re: [Lang] Please fix this
> >
> > i feel very strongly that the code in reflect is not ready to be
> > released.
> >
> > in particular, i would not like to see the current method names and
> > structure become fixed by future requirements for backwards compatibility
> > (just) yet.
> >
> > (gorden bennett! i've only made one commit and i'm already sounding like
> > i own the shop ;)
> >
> > - robert
> >
> > On Thursday, November 7, 2002, at 07:15 PM, Steve Downey wrote:
> > > I agree that CVS head is not in a releaseable state. But the bug is
> > > fairly compelling. I think releasing off a branch from the release tag
> > > is the best
> > > solution.
> > >
> > > On Thursday 07 November 2002 12:05 pm, Henri Yandell wrote:
> > >> Fixed in CVS, so will be in the nightly build tonight at the very
> > >> least. And UnitTest made so Max and Min are being tested.
> > >>
> > >> Any views out there on the merits of a release?
> > >>
> > >> My judgement is that the current CVS tree is not releasable, so it
> > >> would be a question of releasing against the tag.
> > >>
> > >> Any other bugs that should be included?
> > >>
> > >> Hen
> > >>
> > >> On Thu, 7 Nov 2002, [ISO-8859-1] Kasper Rönning wrote:
> > >>> Quite a bug in Commons-Lang: class NumberRange, method geMaximum()
> > >>> returns minimum. Could you make a new release?
> > >>>
> > >>> /Kasper Ronning
> > >>>
> > >>>
> > >>> --
> > >>> To unsubscribe, e-mail:
> > >>>  For additional
> > >>> commands, e-mail: 
> > >
> > > --
> > > To unsubscribe, e-mail:  
> > > 
> > > For additional commands, e-mail:
> > > 
> >
> > --
> > To unsubscribe, e-mail:  
> >  For additional
> > commands, e-mail: 


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-commons/dbcp/src/test/org/apache/commons/dbcp TestBasicDataSource.java TestAll.java TestConnectionPool.java

[rwaldhoff]

rwaldhoff2002/11/08 11:17:24

  Modified:dbcp/src/java/org/apache/commons/dbcp PoolingDataSource.java
PoolingDriver.java
   dbcp/src/java/org/apache/commons/dbcp/jdbc2pool
Jdbc2PoolDataSource.java
   dbcp/src/test/org/apache/commons/dbcp TestAll.java
TestConnectionPool.java
  Added:   dbcp/src/test/org/apache/commons/dbcp
TestBasicDataSource.java
  Log:
  add TestBasicDataSource
  ensure we throw SQLException when the pool is exhausted, rather than NoSuchElement
  
  Revision  ChangesPath
  1.4   +11 -11
jakarta-commons/dbcp/src/java/org/apache/commons/dbcp/PoolingDataSource.java
  
  Index: PoolingDataSource.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/dbcp/src/java/org/apache/commons/dbcp/PoolingDataSource.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- PoolingDataSource.java16 May 2002 21:25:38 -  1.3
  +++ PoolingDataSource.java8 Nov 2002 19:17:23 -   1.4
  @@ -61,16 +61,14 @@
   
   package org.apache.commons.dbcp;
   
  -import org.apache.commons.pool.ObjectPool;
  -import java.util.Properties;
  +import java.io.PrintWriter;
   import java.sql.Connection;
  -import java.sql.Driver;
  -import java.sql.Statement;
  -import java.sql.ResultSet;
   import java.sql.SQLException;
  -import java.io.PrintWriter;
  +import java.util.NoSuchElementException;
  +
   import javax.sql.DataSource;
  -import java.util.Enumeration;
  +
  +import org.apache.commons.pool.ObjectPool;
   
   /**
* A simple {@link DataSource} implementation that obtains
  @@ -110,6 +108,8 @@
   return (Connection)(_pool.borrowObject());
   } catch(SQLException e) {
   throw e;
  +} catch(NoSuchElementException e) {
  +throw new SQLException(e.toString());
   } catch(RuntimeException e) {
   throw e;
   } catch(Exception e) {
  
  
  
  1.4   +13 -10
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.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- PoolingDriver.java20 Jul 2002 22:55:34 -  1.3
  +++ PoolingDriver.java8 Nov 2002 19:17:23 -   1.4
  @@ -61,17 +61,18 @@
   
   package org.apache.commons.dbcp;
   
  -import org.apache.commons.pool.ObjectPool;
  -import org.apache.commons.jocl.JOCLContentHandler;
  +import java.io.InputStream;
  +import java.sql.Connection;
   import java.sql.Driver;
   import java.sql.DriverManager;
   import java.sql.DriverPropertyInfo;
  -import java.sql.Connection;
   import java.sql.SQLException;
  -import java.util.Properties;
   import java.util.HashMap;
  -import java.util.Enumeration;
  -import java.io.InputStream;
  +import java.util.NoSuchElementException;
  +import java.util.Properties;
  +
  +import org.apache.commons.jocl.JOCLContentHandler;
  +import org.apache.commons.pool.ObjectPool;
   
   
   /**
  @@ -146,6 +147,8 @@
   return (Connection)(pool.borrowObject());
   } catch(SQLException e) {
   throw e;
  +} catch(NoSuchElementException e) {
  +throw new SQLException(e.toString());
   } catch(RuntimeException e) {
   throw e;
   } catch(Exception e) {
  
  
  
  1.6   +48 -37
jakarta-commons/dbcp/src/java/org/apache/commons/dbcp/jdbc2pool/Jdbc2PoolDataSource.java
  
  Index: Jdbc2PoolDataSource.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/dbcp/src/java/org/apache/commons/dbcp/jdbc2pool/Jdbc2PoolDataSource.java,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- Jdbc2PoolDataSource.java  7 Nov 2002 21:31:19 -   1.5
  +++ Jdbc2PoolDataSource.java  8 Nov 2002 19:17:24 -   1.6
  @@ -54,39 +54,40 @@
* .
*/

  +import java.io.ByteArrayOutputStream;
  +import java.io.IOException;
  +import java.io.ObjectOutputStream;
  +import java.io.PrintWriter;
  +import java.io.Serializable;
  +import java.sql.Connection;
  +import java.sql.SQLException;
   import java.util.HashMap;
  +import java.util.Hashtable;
   import java.util.Iterator;
   import java.util.Map;
  +import java.util.NoSuchElementException;
   import java.util.Properties;
   
  -import java.util.Hashtable;
  -import java.io.PrintWriter;
  -import java.io.Serializable;
  -import java.io.ByteArrayOutputStream;
  -import java.io.ObjectOutputStream;
  -import java.io.IOException;
  -import java.sql.Connection;
  

cvs commit: jakarta-commons/dbcp/src/test/org/apache/commons/dbcp/jdbc2pool TestJdbc2PoolDataSource.java

[rwaldhoff]

rwaldhoff2002/11/08 10:51:07

  Modified:dbcp build.xml maven.xml
   dbcp/doc test.jocl
   dbcp/src/java/org/apache/commons/dbcp/cpdsadapter
ConnectionImpl.java
PoolablePreparedStatementStub.java
PooledConnectionImpl.java
   dbcp/src/test/org/apache/commons/dbcp TestAll.java
TestJOCLed.java TestManual.java
TesterStatement.java
   dbcp/src/test/org/apache/commons/dbcp/jdbc2pool
TestJdbc2PoolDataSource.java
  Added:   dbcp/src/test testpool.jocl
   dbcp/src/test/org/apache/commons/dbcp
TestConnectionPool.java
  Log:
  refactor/cleanup test suite a bit
  apply generic tests to more configurations
  fix a couple of bugs that revealed
  
  Revision  ChangesPath
  1.16  +6 -1  jakarta-commons/dbcp/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/jakarta-commons/dbcp/build.xml,v
  retrieving revision 1.15
  retrieving revision 1.16
  diff -u -r1.15 -r1.16
  --- build.xml 5 Sep 2002 23:38:49 -   1.15
  +++ build.xml 8 Nov 2002 18:51:06 -   1.16
  @@ -239,6 +239,11 @@
debug="true"
deprecation="true"
optimize="true"/>
  +  
  +
  +  
  +
  +  
  
   
  
  
  
  
  1.2   +9 -2  jakarta-commons/dbcp/maven.xml
  
  Index: maven.xml
  ===
  RCS file: /home/cvs/jakarta-commons/dbcp/maven.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- maven.xml 23 Jul 2002 16:43:14 -  1.1
  +++ maven.xml 8 Nov 2002 18:51:06 -   1.2
  @@ -1,4 +1,11 @@
  -
  +
  +
  +
  +  
  +
  +  
  +
  +  
  +
   
   
  
  
  
  1.2   +2 -2  jakarta-commons/dbcp/doc/test.jocl
  
  Index: test.jocl
  ===
  RCS file: /home/cvs/jakarta-commons/dbcp/doc/test.jocl,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- test.jocl 14 Apr 2001 17:16:57 -  1.1
  +++ test.jocl 8 Nov 2002 18:51:07 -   1.2
  @@ -19,10 +19,10 @@
  
  
 
  -  
  +  
 
 
  -  
  +  
 
 
 
  
  
  
  1.2   +3 -2  
jakarta-commons/dbcp/src/java/org/apache/commons/dbcp/cpdsadapter/ConnectionImpl.java
  
  Index: ConnectionImpl.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/dbcp/src/java/org/apache/commons/dbcp/cpdsadapter/ConnectionImpl.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- ConnectionImpl.java   5 Aug 2002 06:42:01 -   1.1
  +++ ConnectionImpl.java   8 Nov 2002 18:51:07 -   1.2
  @@ -3,7 +3,7 @@
   /* 
* The Apache Software License, Version 1.1
*
  - * Copyright (c) 2001 The Apache Software Foundation.  All rights
  + * Copyright (c) 2001-2002 The Apache Software Foundation.  All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
  @@ -170,6 +170,7 @@
   public void close()
   throws SQLException
   {
  +assertOpen();
   isClosed = true;
   pooledConnection.notifyListeners();
   }
  
  
  
  1.2   +8 -8  
jakarta-commons/dbcp/src/java/org/apache/commons/dbcp/cpdsadapter/PoolablePreparedStatementStub.java
  
  Index: PoolablePreparedStatementStub.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/dbcp/src/java/org/apache/commons/dbcp/cpdsadapter/PoolablePreparedStatementStub.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- PoolablePreparedStatementStub.java5 Aug 2002 06:42:01 -   1.1
  +++ PoolablePreparedStatementStub.java8 Nov 2002 18:51:07 -   1.2
  @@ -1,5 +1,5 @@
   /*
  - * $Header$
  + * $Id$
* $Revision$
* $Date$
*
  @@ -7,7 +7,7 @@
*
* The Apache Software License, Version 1.1
*
  - * Copyright (c) 1999-2001 The Apache Software Foundation.  All rights
  + * Copyright (c) 2001-2002 The Apache Software Foundation.  All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
  @@ -80,10 +80,10 @@
   
   /**
* Constructor
  - * @param stmt my underlying {*link PreparedStatement}
  - * @param key my key" as used by {*link KeyedObjectPool}
  - * @param pool the {*link KeyedObjectPool} from which I was obtained.
  - * @param conn the {*link Connection} from which I wa

cvs commit: jakarta-commons-sandbox/jelly/src/test/org/apache/commons/jelly/junit suite.jelly

[jstrachan]

jstrachan2002/11/08 10:35:06

  Modified:jelly/src/test/org/apache/commons/jelly/junit suite.jelly
  Log:
  enhanced test case to demonstrate that XPath should not find elements in a document 
with a namespace URI but no prefix - unless the XPath expression has a prefix. 
  This is a very common XPath gotcha.
  
  Revision  ChangesPath
  1.5   +5 -1  
jakarta-commons-sandbox/jelly/src/test/org/apache/commons/jelly/junit/suite.jelly
  
  Index: suite.jelly
  ===
  RCS file: 
/home/cvs/jakarta-commons-sandbox/jelly/src/test/org/apache/commons/jelly/junit/suite.jelly,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- suite.jelly   8 Nov 2002 18:27:52 -   1.4
  +++ suite.jelly   8 Nov 2002 18:35:06 -   1.5
  @@ -54,7 +54,11 @@

We should have created an 
exception

  - The exception was: ${ex.message}
  +
  +   This should always fail, since foo 
is not in the empty namespace
  +   
  + 
  + We should have created an 
exception
 
   
   
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/tags/jsl JSLTagLibrary.java

[jstrachan]

jstrachan2002/11/08 10:27:52

  Modified:jelly/src/java/org/apache/commons/jelly TagLibrary.java
   jelly/src/java/org/apache/commons/jelly/parser
XMLParser.java
   jelly/src/java/org/apache/commons/jelly/impl TagScript.java
   jelly/src/java/org/apache/commons/jelly/tags/junit
JUnitTagLibrary.java
   jelly/src/java/org/apache/commons/jelly/tags/xml
XMLTagLibrary.java XPathExpression.java
   jelly/src/test/org/apache/commons/jelly/junit suite.jelly
   jelly/src/java/org/apache/commons/jelly/tags/jsl
JSLTagLibrary.java
  Added:   jelly/src/java/org/apache/commons/jelly
NamespaceAwareTag.java
  Log:
  Added support for NamespaceAwareTags. This allows Tag implementations to be given 
the namespace context in which they are used. 
  This allows tags to, for example, map namespace qualified names to namespace URIs 
using namespace prefixes.
  
  For example in XSD or SOAP or BPEL styles of languages, qualified names like "x:foo" 
can be used. The 'x' is a prefix. The namespace context maps prefixes 'x' to the URI.
  
  This patch also means that all the XPath expressions in the XML library, JSL and 
JellyUnit can also make use of the XPath prefixes that are available.
  This allows full namespace-based XPath to be used.
  
  Revision  ChangesPath
  1.17  +6 -6  
jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/TagLibrary.java
  
  Index: TagLibrary.java
  ===
  RCS file: 
/home/cvs/jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/TagLibrary.java,v
  retrieving revision 1.16
  retrieving revision 1.17
  diff -u -r1.16 -r1.17
  --- TagLibrary.java   30 Oct 2002 19:16:26 -  1.16
  +++ TagLibrary.java   8 Nov 2002 18:27:51 -   1.17
  @@ -155,7 +155,7 @@
   /** Allows taglibs to use their own expression evaluation mechanism */
   public Expression createExpression(
   ExpressionFactory factory,
  -String tagName,
  +TagScript tagScript,
   String attributeName,
   String attributeValue)
   throws Exception {
  
  
  
  1.1  
jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/NamespaceAwareTag.java
  
  Index: NamespaceAwareTag.java
  ===
  /*
   * $Header: 
/home/cvs/jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/DynaTag.java,v
 1.6 2002/10/30 19:16:26 jstrachan Exp $
   * $Revision: 1.6 $
   * $Date: 2002/10/30 19:16:26 $
   *
   * 
   *
   * The Apache Software License, Version 1.1
   *
   * Copyright (c) 2002 The Apache Software Foundation.  All rights
   * reserved.
   *
   * Redistribution and use in source and binary forms, with or without
   * modification, are permitted provided that the following conditions
   * are met:
   *
   * 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", "Commons", 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.
   *
   * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
   * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
   * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
   * DISCLAIMED.  IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
   * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
   * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
   * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
   * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
   * ON ANY THEORY OF LIABILITY, WHETHER IN

[jdbc] JdbcUtil etc

[Henri Yandell]

Does anyone know of a good apache-style license set of classes for helping
with JDBC stuff?

I'm thinking of things like:

1) A JdbcUtils which helps with closing rs, stat, conn. That simplifies
MetaData work, that has a ResultSetIterator [yes I know BeanUtils has one
of these, it's misplaced I think].

2) A sequence-number handler. Something that is very generic and
configurable at runtime. The code is out there it seems, but stuck inside
things like object-bridge and other large projects.

3) Possibly a continuation of the ResultSetIterator. A
java.util.Collection structure for viewing a JDBC connection.

4) An empty Driver wrapper set for people wanting to make quick hacks to
their driver. For example, Oracle's latest driver has some crap with
Timestamp. Easiest solution for me would be to take Commons JDBC Standard
Wrapper Driver, extend ResultSet and convert an oracle.sql.Timestamp to
java.sql.Timestamp without anyone noticing.

5) ??

Does such a thing exist?
Should it exist?

Should it be in sql? [I think not, unless the current sql wants a new name
:) sql seems to be concerned with other things]

Should ti be called jdbc?

I've got some bits that I can start with, so am happy to make a proposal
in sandbox, but thought I'd check no one has invented the wheel before.

Hen


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[clazz] draft reflect implementation

[Dmitri Plotnikov]

I am not really done with the first draft yet, but since I will have to
take about a week off from clazz, I wanted to commit what
I have done so far and give you a chance to look it over.

My initial focus was on implementing functionality equivalent to
that of java.beans.Introspector. There are several pretty cool 
improvements over the Introspector:

1. Highly customizable design.  

- You can add new ClazzLibraries for new kinds of Clazzes. So far
there is only one such library, ReflectClazzLibrary, but more are
coming.

- You can add new ClazzLoaders to customize Clazz generation for
individual clazzes or groups of clazzes.

- In the case of Reflected clazzes, you can change the way accessor
methods are bound to properties.  For example, if you want to make 
read methods look like "readFoo()" instead of "getFoo()", it is a matter
of overriding one method on ReflectScalarPropertyIntrospector.

- In the case of Reflected clazzes, you can add new categories of
properties.  The default list of categories consists of List (which 
works for Lists as well as arrays), Mapped and Scalar properties.

2. In the case of ReflectedClazzes, richer mapping of accessors to
properties: methods like getFoo(int), setBar(key,value), getFooKeySet()
etc are recognized.

3. If a property is Mapped, the corresponding clazzProperty.get()
returns a Map, even if all the bean defines is a bunch of accessor
methods like getFoo(key).  The Map implementation returned by
clazzProperty will invoke those accessors if they exist (see the 
ReflectedMap).

4. Similarly, if a property is a List or an array, the corresponding
value is a List (see ReflectedList).

5. Powerful diagnostic facility that optionally prints details of
introspection.  You won't have to wonder any more: "how come it does
not see my property 'foo'".  I have attached a sample diagnostic log.
Check it out, it's pretty cool.

The implemented functionality comes with tests, but as you will see not
all functionality is implemented yet.

Don't look for ATTRIBUTES, DELEGATORS or BEAN stuff yet - I'll get to
that in a week or so.


- Dmitri


[Clazz: org.apache.commons.clazz.reflect.ReflectableInstance
[baseProperty
  [type]   java.lang.String
  [accessor methods:
[get~()]   public java.lang.String 
org.apache.commons.clazz.reflect.ReflectedSuperclazzInstance.getBaseProperty()
[set~(v)]  public void 
org.apache.commons.clazz.reflect.ReflectedSuperclazzInstance.setBaseProperty(java.lang.String)
  ]
]
[booleanProperty
  [type]   boolean
  [accessor methods:
[get~()]   public boolean 
org.apache.commons.clazz.reflect.ReflectableInstance.isBooleanProperty()
[set~(v)]  public void 
org.apache.commons.clazz.reflect.ReflectableInstance.setBooleanProperty(boolean)
  ]
]
[halfProperty
  [type]   java.lang.String
  [accessor methods:
[get~()]   public java.lang.String 
org.apache.commons.clazz.reflect.ReflectableInstance.getHalfProperty()
[set~(v)]  public void 
org.apache.commons.clazz.reflect.ReflectedSuperclazzInstance.setHalfProperty(java.lang.String)
  ]
]
[intArray (list)
  [type]   [I
  [accessor methods:
[get~()]   public int[] 
org.apache.commons.clazz.reflect.ReflectableInstance.getIntArray()
[set~(v)]  public void 
org.apache.commons.clazz.reflect.ReflectableInstance.setIntArray(int[])
  ]
]
[integerProperty
  [type]   int
  [accessor methods:
[get~()]   public int 
org.apache.commons.clazz.reflect.ReflectableInstance.getIntegerProperty()
[set~(v)]  public void 
org.apache.commons.clazz.reflect.ReflectableInstance.setIntegerProperty(int)
  ]
]
[mappedBooleans (mapped)
  [type]   java.util.Map
  [accessor methods:
[get~()]   public java.util.Map 
org.apache.commons.clazz.reflect.ReflectableInstance.getMappedBooleans()
[set~(v)]  public void 
org.apache.commons.clazz.reflect.ReflectableInstance.setMappedBooleans(java.util.Map)
  ]
]
[*mappedInteger - NOT a list property
 - Does not have either get() or get(int) method
  [content type]   java.lang.Integer
  [accessor methods:
[remove~(v)]   public void 
org.apache.commons.clazz.reflect.ReflectableInstance.removeMappedInteger(java.lang.Integer)
  ]
]
[mappedInteger (mapped)
  [key type]   java.lang.Integer
  [content type]   java.lang.Integer
  [accessor methods:
[get~(key)]public java.lang.Integer 
org.apache.commons.clazz.reflect.ReflectableInstance.getMappedInteger(java.lang.Integer)
[set~(key,v)]  public void 
org.apache.commons.clazz.reflect.ReflectableInstance.setMappedInteger(java.lang.Integer,java.lang.Integer)
[remove~(key)] public void 
org.apache.commons.clazz.reflect.ReflectableInstance.removeMappedInteger(java.lang.Integer)
[get~KeySet()] public java.lang.Integer[] 
org.apache.commons.clazz.reflect.ReflectableInstance.getMappedIntegerKeys()
  ]
]
[mappedIntegerKeys (list)
  [type]   [Ljava.lang.Integer;
  [accessor meth

cvs commit: jakarta-commons-sandbox/clazz/src/test/org/apache/commons/clazz/reflect - New directory

[dmitri]

dmitri  2002/11/08 06:23:31

  jakarta-commons-sandbox/clazz/src/test/org/apache/commons/clazz/reflect - New 
directory

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-commons-sandbox/clazz/src/test/org/apache/commons/clazz - New directory

[dmitri]

dmitri  2002/11/08 06:23:29

  jakarta-commons-sandbox/clazz/src/test/org/apache/commons/clazz - New directory

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-commons-sandbox/clazz/src/test/org/apache - New directory

[dmitri]

dmitri  2002/11/08 06:23:25

  jakarta-commons-sandbox/clazz/src/test/org/apache - New directory

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-commons-sandbox/clazz/src/test/org/apache/commons - New directory

[dmitri]

dmitri  2002/11/08 06:23:27

  jakarta-commons-sandbox/clazz/src/test/org/apache/commons - New directory

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-commons-sandbox/clazz/src/test - New directory

[dmitri]

dmitri  2002/11/08 06:23:20

  jakarta-commons-sandbox/clazz/src/test - New directory

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-commons-sandbox/clazz/src/test/org - New directory

[dmitri]

dmitri  2002/11/08 06:23:23

  jakarta-commons-sandbox/clazz/src/test/org - New directory

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-commons-sandbox/clazz/src/java/org/apache/commons/clazz/reflect - New directory

[dmitri]

dmitri  2002/11/08 06:23:16

  jakarta-commons-sandbox/clazz/src/java/org/apache/commons/clazz/reflect - New 
directory

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 14263] - BeanReader returns no object when used with SAXParser

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=14263

BeanReader returns no object when used with SAXParser

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |



--- Additional Comments From [EMAIL PROTECTED]  2002-11-08 14:11 ---
Further explanation:

I want to use an XML Database as source for my Beans. The database API provides 
functions like query(queryString) which returns a class of type Resource. 
Resource can be read via:
Resource.getContent() returning a String
Resource.getContentAsDOM() return a DOM Node object
Resource.getContentAsSAX(ContentHandler) passing the result to a SAX 
ContentHandler

The first and second method work well with Betwixt, the third method doesn't 
(see TestCase).
The reason to use the ContentHandler is simply a performance issue (creating a 
String or a Node object from raw XML takes some time, where ContentHandler just 
passes the required information and is therefore much faster).

Martin: What you are describing is excactly the way I want to do it, but it 
does not work.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[modeler] Modeler does not handle generic Descriptors (bug 14361)

[Roberts George E (Ed) NPRI]

Hi,

I have been looking at the modeler for a project I am working on... I communicated 
with Craig and he suggested that I bring our conversation to this email group... 

The modeler as it stands now does not have full compliance with the spec 
(unfortunately I have been reading JMX 1.1 instead of JMX 1.0.1 but I took a peek and 
it did not seem to change between those releases)... basically the problem is this... 
the specs says that one can add any number of descriptor fields that one wants, right 
now the DTD does not allow you to do that (only the standard ones) nor does the parser 
take care of that.  I have a DTD that I have posted as an attachment to bug 14361
that I want to purpose as a DTD that will take care of this problem... it will be 
backward compatible with the current DTD but I have deprecated some of the attribute 
entries

... there is a lot of metadata that I wanted added into the Descriptor for my class' 
parts and if one looks at the spec (even the 1.0.1 spec) there are Descriptor items 
such as for ModelMBeanAttributeInfo

The fields in the descriptor are defined, but not limited to, the following: 
 name   : attribute name  
 descriptorType : must be "attribute"   
 value  : current value for attribute 
 default: default value for attribute 
 displayName: name of attribute to be used in displays 
 getMethod  : name of operation descriptor for get method  
 setMethod  : name of operation descriptor for set method 
 protocolMap: object which implements the ProtocolMap interface: map of protocol 
names and protocol hints 
 persistPolicy  : Update|OnTime|NoMoreOftenThan|Always|Never  
 persistPeriod  : seconds - frequency of persist cycle. Used when persistPolicy 
is"OnTime" or "NoMoreOftenThan".  
 currencyTimeLimit : how long value is valid, <0 never, =0 always, >0 seconds  
 lastUpdatedTimeStamp : when value was set  
 iterable   : T - object value supports Iterable interface, F - does not support 
Iterable interface   
 visibility : 1-4 where 1: always visible 4: rarely visible  
 presentationString : xml formatted string to allow presentation of data 

there is no way in the present DTD to account for this information... one way that 
could be done is 
through attributes but then one could not have a general object as the field value 
allows... I think 
I have accounted for that in the DTD...

ed roberts

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 14361] - support for general descriptors

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=14361

support for general descriptors





--- Additional Comments From [EMAIL PROTECTED]  2002-11-08 13:17 ---
Created an attachment (id=3777)
new DTD with Generalized Descriptors

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 14384] - ValidatorResources.get-method not working properly

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=14384

ValidatorResources.get-method not working properly





--- Additional Comments From [EMAIL PROTECTED]  2002-11-08 13:09 ---
Created an attachment (id=3775)
Patch of the get-method

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 14384] - ValidatorResources.get-method not working properly

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=14384

ValidatorResources.get-method not working properly





--- Additional Comments From [EMAIL PROTECTED]  2002-11-08 13:08 ---
Created an attachment (id=3774)
Patch of the get-method

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 14263] - BeanReader returns no object when used with SAXParser

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=14263

BeanReader returns no object when used with SAXParser





--- Additional Comments From [EMAIL PROTECTED]  2002-11-08 12:39 ---
I think what Herald meant (based on the discussion we had on commons mllist), 
that he doesn't control the source and doesn't know it and can just call read 
on eg foo (and get the parser).
Depending on what the foo does parse,
you can try parser.getXMLReader().setContentHandler(reader);
and then do foo.read(). Although I don't know what the foo.read() in your 
scenario does)

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 14384] New: - ValidatorResources.get-method not working properly

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=14384

ValidatorResources.get-method not working properly

   Summary: ValidatorResources.get-method not working properly
   Product: Commons
   Version: 1.0 Final
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Major
  Priority: Other
 Component: Validator
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


The get-method in the ValidatorResources is not working properly as it returns 
always null if the exact combination of language, country and variant is not 
found in the formset-declaration of the validation.xml. I expected it to work 
like the struts PropertyMessageResource class trying to retrieve first the most 
specific formset and at last retrieving the most general formset.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Réf. : Re: Réf. : RE: Réf. : Re: Commons Validator

[loic . lefevre]

Hello,
It's me again, well, I've had a look too to the Java implementation
of the isByte method and I took care of your remarks to reimplement
it (thank you). So here are the results:

old method from Commons Validator :
public static boolean isByte(String value) {
   return formatByte(value) != null;
}

public static Byte formatByte(String value) {
   Byte result = null;

   try {
  result = new Byte(value);
   } catch (Exception e) {
   }

   return result;
}

And the new one which do exactly what is needed, that's to
say return true or false and doesn't throw any exception:

public static final boolean isByte( String s )
{
  // should never happen in JOE
  if( s == null )
  return false;

  int result = 0;
  boolean negative = false;
  int i = 0;
  int max = s.length();
  int limit;
  int multmin;
  int digit;

  if( max > 0 )
  {
  if( s.charAt( 0 ) == '-' )
  {
negative = true;
limit = Integer.MIN_VALUE;
i++;
  }
  else
  {
limit = -Integer.MAX_VALUE;
  }

  multmin = limit / 10; // radix
  if( i < max )
  {
digit = Character.digit( s.charAt( i++ ), 10 ); // radix
if( digit < 0 )
return false;
else
result = -digit;
  }

  while( i < max )
  {
// Accumulating negatively avoids surprises near MAX_VALUE
digit = Character.digit(s.charAt(i++),10); // radix
if( digit < 0 )
return false;

if( result < multmin )
return false;

result *= 10; // radix

if( result < limit + digit )
return false;

result -= digit;
  }
  }
  else
  return false;

  if( negative )
  {
  if( i > 1 )
return !(result < Byte.MIN_VALUE || result > Byte.MAX_VALUE );
  else
return false; /* Only got "-" */
  }
  else
  return !(-result < Byte.MIN_VALUE || -result > Byte.MAX_VALUE );
}

And the results for this test:

System.out.println((new java.util.Date()).getTime()+"");
for( int i = 0; i < 10; i++ )
{
isByteApache( "300" );
isByteApache( "5" );
}
System.out.println((new java.util.Date()).getTime()+"");
for( int i = 0; i < 10; i++ )
{
isByte( "300" );
isByte( "5" );
}
System.out.println((new java.util.Date()).getTime()+"");
if( isByteApache( "300" ) )
throw new IllegalStateException("problem");
if( !isByteApache( "5" ))
throw new IllegalStateException("problem");
if( isByte( "300" ) )
throw new IllegalStateException("problem");
if( !isByte( "5" ))
throw new IllegalStateException("problem");
if( isByte( "-300" ) )
throw new IllegalStateException("problem");
if( !isByte( "-5" ))
throw new IllegalStateException("problem");


2093ms for the first loop and... 90ms for the second one => 25 times
faster!

Thank you again :-)
Loïc

> ps: If you should read something about Knuth, read only his most famous
> quote. really.

Which is...? (the title please)

> With Joe, you're taking the optimization step by the wrong end IMHO

What do you mean by this? Tell me please :-)




Extranet
[EMAIL PROTECTED] - 07/11/2002 17:19


Veuillez répondre à [EMAIL PROTECTED]
Pour : ant-dev

cc :


Objet : Re: Réf. : RE: Réf. : Re: Commons Validator


- Original Message -
From: <[EMAIL PROTECTED]>

>Well it's just about 8% faster:
[...]

ah.

Byte.parseByte(String) is faster, you avoid an allocation.
Byte.parseByte(String, 10) is even faster you avoid a method call

 int i = Integer.parseInt(s, radix);
 return  !(i < Byte.MIN_VALUE || i > MAX_VALUE)
is even more faster. you avoid a method call and and an exception

and yet I suggest to copy/paste the Integer.parseInt method and use your
own
by remove the exceptions to make it even more faster by removing yet
another
method call and exception.

>ps: don't have the time to make a patch (sorry)

I see. Time problem.

ps: If you should read something about Knuth, read only his most famous
quote. really.
With Joe, you're taking the optimization step by the wrong end IMHO


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 










This message and any attachments (the "message") is
intended solely for the addres

Re: [httpclient]-timeout-> i found a small but important bug.

[Ortwin Glück]

Noam,

You misunderstood the meaning of the setTimeout() method. This sets the 
SO_TIMEOUT property of a socket, which is the maximum time that must 
pass between data packets sent through this socket. If no traffic occurs 
on the socket for this duration the socket automatically disconnects.

This is very different from a connection timeout (as in your code).

Unfortunately connection timeouts are a feature of JDK 1.4 and are not 
backwards compatible to 1.3. So we can not use this feature at the moment.

There is already a feature request for this in Bugzilla:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10973
scheduled for the 2.0 release.

I feel that this is a major requirement and I can try and post a 
solution shortly.

Thanks for trying to contribute. However you are strongly encouraged to 
use CVS / diff to submit patches. Posting whole files without a diff is 
not feasible because we can not easily spot the changes. More coding 
rules can be found here:

http://jakarta.apache.org/site/getinvolved.html

Kind regards to Israel

Odi

p.s. Please post HttpClient issues directly to 
[EMAIL PROTECTED] and *not* to the commons list, 
as your email may easily missed by the committers (depending on how good 
our filters are...). You can ommit the [HttpClient] prefix then. Patches 
should have the [PATCH] prefix in the subject line.

Noam Berg wrote:

Hello,
I need to use http connections with timeouts, since it is not part of the
release i downloaded 7th Nov 2002 sources, but
using HttpClient.setTimeout didnt help. i checked out the code and 
find out
that when you create the sockets using host+port
it immediately connects so setting the timeout after that does not change
(at least in my case where i dont reuse them
and its important in first connect for a timeout to be set).

The changes:
line 350:
	 _socket = new Socket();
	_socket.connect(new
java.net.InetSocketAddress(host,port),_so_timeout);

line 781:
	Socket s = sslSocketFactory.createSocket();
	s.connect(new java.net.InetSocketAddress(host, port), _so_timeout);
return s;

and the whole file :
 <>

i'm sorry but i dont have CVS ...
10x.

P.S.
Another small thing (suggestion) ...
When i first started using this package i wanted to do a very simple
httpconnection ...
what would have help me _a lot_ would have been a few small source 
examples
for usage
(maybe a bit like your test classes).
10x

Noam Berg
R&D
SofaWare Technologies Ltd.
3 Hahilazon St. Ramat-Gan Israel
Tel:  +972-3-6128989 ext 102
Fax: +972-3-5755442
E-mail: [EMAIL PROTECTED]
Web: http://www.sofaware.com





--
To unsubscribe, e-mail:
For additional commands, e-mail: 


--
_
 NOSE applied intelligence ag
   [www]  http://www.nose.ch
 ortwin glück  [email] [EMAIL PROTECTED]
 hardturmstrasse 171   [pgp key]  0x81CF3416
 8005 zurich   [office]  +41-1-277 57 35
 switzerland   [fax] +41-1-277 57 12


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: hello to u all

[Ola Berg]

> I would like to know - what shell I do in order to
> contribute to the Common project?

First of all, a warm welcome, share and enjoy! :-)

Then a suggestion on one way to help out:

a) Use one, some, or all of the components (as per the latest release) in RealCode of 
your own.

b) Get impressed of what the components can do, or what the documentation tells you.

c) Get irritated over what some component cannot do, or what the documentation doesn't 
tell you.

d) Check out the latest CVS version of the component and see if it is fixed there.

e) If not: tell people on the list that you intend to fix it, or at least point the 
annoyance out.

...and you're into it! I guess that a) (use the stuff) is the important point.

/O




--
To unsubscribe, e-mail:   
For additional commands, e-mail: