[ANNOUNCEMENT] Commons Chain 1.0 Released

[Martin Cooper]

The Commons Chain team is pleased to announce the final release of Commons 
Chain 1.0. This is the first official release of the Chain component from The 
Apache Software Foundation.

Commons Chain is an implementation of the "Chain of Responsibility" 
pattern, as described in the classic "Gang of Four" design patterns book.

The binary distribution is available at:
http://jakarta.apache.org/site/binindex.cgi
and the source distribution is available at:
http://jakarta.apache.org/site/sourceindex.cgi
When downloading from a mirror site, please remember to verify the 
signatures of the distribution using the keys found on the main Apache web 
site:

http://www.apache.org/dist/jakarta/commons/chain/KEYS
For more information on Commons Chain, see the Chain web site:
http://jakarta.apache.org/commons/chain/
--
Martin Cooper
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (JELLY-172) util:properties locks the file forever

[dion gillard (JIRA)]

 [ http://nagoya.apache.org/jira/browse/JELLY-172?page=history ]
 
dion gillard resolved JELLY-172:


 Resolution: Fixed
Fix Version: 1.0

Committed

> util:properties locks the file forever
> --
>
>  Key: JELLY-172
>  URL: http://nagoya.apache.org/jira/browse/JELLY-172
>  Project: jelly
> Type: Bug
>   Components: taglib.util
>  Environment: windows, util-taglib version that comes with maven 1.0.2
> Reporter: Matthias Kerkhoff
>  Fix For: 1.0
>  Attachments: PropertiesTag.java, suite.jelly
>
> The following code (taken from a maven script) will always fail:
> 
> 
> 
> From looking tinto the source, I would guess that the problem is an 
> InputStream which is opened, but never closed. 
> The problem definitly appears on windows, can't test on other platforms.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira


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

cvs commit: jakarta-commons/jelly/jelly-tags/util/src/test/org/apache/commons/jelly/tags/util suite.jelly

[dion]

dion2004/12/09 22:26:14

  Modified:jelly/jelly-tags/util/src/test/org/apache/commons/jelly/tags/util
suite.jelly
  Log:
  *** keyword substitution change ***
  
  Revision  ChangesPath
  1.8   +218 -218  
jakarta-commons/jelly/jelly-tags/util/src/test/org/apache/commons/jelly/tags/util/suite.jelly
  
  Index: suite.jelly
  ===
  RCS file: 
/home/cvs/jakarta-commons/jelly/jelly-tags/util/src/test/org/apache/commons/jelly/tags/util/suite.jelly,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- suite.jelly   10 Dec 2004 06:25:49 -  1.7
  +++ suite.jelly   10 Dec 2004 06:26:14 -  1.8
  @@ -1,218 +1,218 @@
  -

  -

  -

  -

  -  

  -

  -Test1,Test2,Test3,Test4

  -

  -

  -

  -

  -

  -

  -

  -

  -

  -

  -

  -

  -

  -

  -

  -

  -

  -

  -  

  -

  -  

  -

  -  

  -  

  -  

  -  

  -

  -  

  -

  -  

  -  

  -  

  -

  -

  -  

  -  Should have found the file via the file $${base.dir}/project.xml 
with base.dir=${base.dir}

  -  

  -

  -  

  -  The file ${base.dir}/doesNotExist.xml should not 
exist

  -  

  -

  -  

  -

  -  

  -

  -  

  -

  -

  -

  -  

  -  

  -  

  -

  -  

  -Should have found the file via the URI dummy.xml

  -  

  -

  -  

  -

  -  The URI doesNotExist.xml should not exist!

  -  

  -

  -  

  -  

  -  

  -

  -A\B

  -

  -  Should have replaced a back slash with a forward one

  -

  -

  -

  -A\B

  -

  -  Should have replaced a back slash with a forward one

  -  and placed the result into output

  -

  -

  -

  -

  -  Should have replaced a slash with a back slash from a variable

  -  and placed the result into a variable

  -

  -

  -

  -

  -

  -  Should have only substituted the 1 for the A, since the

  -  old/newChar attributes were used.

  -

  -

  -

  -

  -Should have substituted the string "black" for "brown"

  -

  -

  -  

  -

  -  

  -  

  -  

  -  

  -  

  -

  -  

  -

  -  

  -  

  -  

  -  

  -  

  -

  -  Loaded properties value ${props}

  -

  -  

  -

  -  

  -  

  -  

  -  

  -  

  -  

  -  

  -

  -  

  -  

  -${f.delete()}

  -  

  -

  -  The file ${name} should no 
longer exist

  -

  -  

  -

  -

  -  

  -  

  -  The suite should 
exist

  -  

  -  

  -  

  -

  -

  -

  - ${testCollection.add('Hello')}

  - ${testCollection.add('World')}

  - ${testCollection.add('Jelly')}

  -

  -

  -

  -

  -

  -  

  -  

  -  

  -

  -

  -

  -

  -

  -

  - ${testCollection.add(cust1)}

  - ${testCollection.add(cust2)}

  - ${testCollection.add(cust3)}

  -

  -

  -

  -

  -

  -

  -

  -

  -

  -

  -

  -

  -

  -  

  -  

  -

  -

  -

  +
  +
  +
  +
  +  
  +
  +Test1,Test2,Test3,Test4
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +  
  +
  +  
  +
  +  
  +  
  +  
  +  
  +
  +  
  +
  +  
  +  
  +  
  +
  +
  +  
  +  Should have found the file via the file $${base.dir}/project.xml 
with base.dir=${base.dir}
  +  
  +
  +  
  +  The file ${base.dir}/doesNotExist.xml should not 
exist
  +  
  +
  +  
  +
  +  
  +
  +  
  +
  +
  +
  +  
  +  
  +  
  +
  +  
  +Should have found the file via the URI dummy.xml
  +  
  +
  +  
  +
  +  The URI doesNotExist.xml should not exist!
  +  
  +
  +  
  +  
  +  
  +
  +A\B
  +
  +  Should have replaced a back slash with a forward one
  +
  +
  +
  +A\B
  +
  +  Should have replaced a back slash with a forward one
  +  and placed the result into output
  +
  +
  +
  +
  +  Should have replaced a slash with a back slash from a variable
  +  and placed the result into a variable
  +
  +
  +
  +
  +
  +  Should have only substituted the 1 for the A, since the
  +  old/newChar attributes were used.
  +
  +
  +
  +
  +

cvs commit: jakarta-commons/jelly/jelly-tags/util/src/java/org/apache/commons/jelly/tags/util PropertiesTag.java

[dion]

dion2004/12/09 22:25:50

  Modified:jelly/jelly-tags/util/src/test/org/apache/commons/jelly/tags/util
suite.jelly
   jelly/jelly-tags/util/src/java/org/apache/commons/jelly/tags/util
PropertiesTag.java
  Added:   jelly/jelly-tags/util/src/test/org/apache/commons/jelly/tags/util
deletable.properties
  Log:
  Jelly-172. properties tag doesn't close files
  
  Revision  ChangesPath
  1.7   +27 -0 
jakarta-commons/jelly/jelly-tags/util/src/test/org/apache/commons/jelly/tags/util/suite.jelly
  
  Index: suite.jelly
  ===
  RCS file: 
/home/cvs/jakarta-commons/jelly/jelly-tags/util/src/test/org/apache/commons/jelly/tags/util/suite.jelly,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- suite.jelly   26 Oct 2004 16:42:56 -  1.6
  +++ suite.jelly   10 Dec 2004 06:25:49 -  1.7
  @@ -33,6 +33,7 @@
   

   

   -->

  +

   

   

   

  @@ -64,6 +65,7 @@
 

 

 

  +

   

 

 Should have found the file via the file $${base.dir}/project.xml 
with base.dir=${base.dir}

  @@ -90,6 +92,7 @@
 

   

 

  +

 The URI doesNotExist.xml should not exist!

 

   

  @@ -101,6 +104,7 @@
   

 Should have replaced a back slash with a forward one

   

  +

   

   A\B

   

  @@ -115,6 +119,7 @@
   

   

   

  +

   

 Should have only substituted the 1 for the A, since the

 old/newChar attributes were used.

  @@ -144,7 +149,25 @@
 Loaded properties value ${props}

   

 

  +

 

  +  

  +  

  +  

  +  

  +  

  +  

  +

  +  

  +  

  +${f.delete()}

  +  

  +

  +  The file ${name} should no 
longer exist

  +

  +  

  +

  +

 

 

  @@ -154,6 +177,7 @@
 

   

   

  +

${testCollection.add('Hello')}

${testCollection.add('World')}

${testCollection.add('Jelly')}

  @@ -166,6 +190,7 @@
 

 

   

  +

   

   

   

  @@ -177,6 +202,7 @@
   

   

   

  +

   

   

   

  @@ -187,5 +213,6 @@
   

 

 

  +

   

   

  
  
  
  1.1  
jakarta-commons/jelly/jelly-tags/util/src/test/org/apache/commons/jelly/tags/util/deletable.properties
  
  Index: deletable.properties
  ===
  # Copyright 2002-2004 The Apache Software Foundation
  #
  # Licensed under the Apache License, Version 2.0 (the "License");
  # you may not use this file except in compliance with the License.
  # You may obtain a copy of the License at
  #
  # http://www.apache.org/licenses/LICENSE-2.0
  #
  # Unless required by applicable law or agreed to in writing, software
  # distributed under the License is distributed on an "AS IS" BASIS,
  # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
  # See the License for the specific language governing permissions and
  # limitations under the License.
  
  foo=ABC
  
  bar=XYZ
  
  
  1.7   +11 -2 
jakarta-commons/jelly/jelly-tags/util/src/java/org/apache/commons/jelly/tags/util/PropertiesTag.java
  
  Index: PropertiesTag.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/jelly/jelly-tags/util/src/java/org/apache/commons/jelly/tags/util/PropertiesTag.java,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- PropertiesTag.java9 Sep 2004 12:22:43 -   1.6
  +++ PropertiesTag.java10 Dec 2004 06:25:50 -  1.7
  @@ -75,7 +75,16 @@
   } catch (IOException e) {
   throw new JellyTagException("properties tag could not load from 
file",e);
   }
  -
  +finally {
  +if (is != null) {
  +try {
  +is.close();
  +} catch (IOException ioe) {
  +;
  +}   
  +}
  +}   
  +
   if (var != null) {
   context.setVariable(var, props);
   }
  
  
  

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

[math] R verification tests

[Phil Steitz]

I just committed some R programs to /experimental/R that verify that R 
gives similar values to [math] for some test cases. If there are any R 
programmers out there (or anyone interested in learning enough R to be 
dangerous ;-) who would like to contribute to this or who can provide 
feedback / suggestions for improvement on the approach, that would be 
much appreciated.

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

cvs commit: jakarta-commons/math/src/experimental/R README.txt binomialTestCases chiSquareTestCases exponentialTestCases hypergeometricTestCases normalTestCases poissonTestCases regressionTestCases testAll testFunctions

[psteitz]

psteitz 2004/12/09 21:47:18

  Added:   math/src/experimental/R README.txt binomialTestCases
chiSquareTestCases exponentialTestCases
hypergeometricTestCases normalTestCases
poissonTestCases regressionTestCases testAll
testFunctions
  Log:
  Initial commit - R verification tests.
  
  Revision  ChangesPath
  1.1  jakarta-commons/math/src/experimental/R/README.txt
  
  Index: README.txt
  ===
  #   Copyright 2004 The Apache Software Foundation
  #
  #   Licensed under the Apache License, Version 2.0 (the "License");
  #   you may not use this file except in compliance with the License.
  #   You may obtain a copy of the License at
  #
  #   http://www.apache.org/licenses/LICENSE-2.0
  #
  #   Unless required by applicable law or agreed to in writing, software
  #   distributed under the License is distributed on an "AS IS" BASIS,
  #   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
  #   See the License for the specific language governing permissions and
  #   limitations under the License.
  #
  
#--
  
  INTRODUCTION
  
  The purpose of the R programs included in this directory is to validate 
  the target values used in jakarta commons math unit tests. Success running 
the 
  R and commons-math tests on a platform (OS and R version) means that R and 
  commons-math give results for the test cases that are close in value.  The 
  tests include configurable tolerance levels; but care must be taken in 
changing 
  these, since in most cases the pre-set tolerance is close to the number of 
  decimal digits used in expressing the expected values (both here and in the 
  corresponding commons-math unit tests).
  
  Of course it is always possible that both R and commons-math give incorrect 
  values for test cases, so these tests should not be interpreted as definitive 
  in any absolute sense. The value of developing and running the tests is 
really  
  to generate questions (and answers!) when the two systems give different 
  results.
  
  Contributions of additional test cases (both R and Junit code) or just 
  R programs to validate commons-math tests that are not covered here would be 
  greatly appreciated.
  
  SETUP
  
  0) Download and install R.  You can get R here
  http://www.r-project.org/
  Follow the install instructions and make sure that you can launch R from this 
 
  (i.e., either explitly add R to your OS path or let the install package do it 
  for you).  
  
  1) Launch R from this directory and type 
  > source("testAll")
  to an R prompt.  This should produce output to the console similar to this:
  
  Binomial test cases
  Density test n = 10, p = 
0.7...SUCCEEDED
  Distribution test n = 10, p = 
0.7..SUCCEEDED
  Inverse Distribution test n = 10, p = 
0.7..SUCCEEDED
  Density test n = 5, p = 
0..SUCCEEDED
  Distribution test n = 5, p = 
0.SUCCEEDED
  Density test n = 5, p = 
1..SUCCEEDED
  Distribution test n = 5, p = 
1.SUCCEEDED
  

  Normal test cases
  Distribution test mu = 2.1, sigma = 
1.4SUCCEEDED
  Distribution test mu = 2.1, sigma = 
1.4SUCCEEDED
  Distribution test mu = 0, sigma = 
1SUCCEEDED
  Distribution test mu = 0, sigma = 
0.1..SUCCEEDED
  

  ...
  
  
  
  WORKING WITH THE TESTS
  
  The R distribution comes with online manuals that you can view by launching 
  a browser instance and then entering
  
  > help.start()
  
  at an R prompt. Poking about in the test case files and the online docs 
should 
  bring you up to speed fairly quickly.  Here are some basic things to get 
  you started. I should note at this point that I by no means an expert R 
  programmer, so some things may not be implemented in the the nicest way. 
  Comments / suggestions for improvement are welcome!
  
  All of the test cases use some basic functions and global constants (screen
  width and success / failure strings) defined in "testFunctions." The  
  R "source" function is used to "import" these functions into each of the test 
  programs.  The "testAll" program pulls together and executes all of the 
  individual test programs.  You can execute any one of them by just entering
  
  > source().
  
  The "assertEquals" function in the testFunction

cvs commit: jakarta-commons/math/src/experimental/R - New directory

[psteitz]

psteitz 2004/12/09 21:44:30

  jakarta-commons/math/src/experimental/R - New directory

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

cvs commit: jakarta-commons/math/src/test/org/apache/commons/math/stat/regression SimpleRegressionTest.java

[psteitz]

psteitz 2004/12/09 21:18:16

  Modified:math/src/test/org/apache/commons/math/stat/inference
ChiSquareTestTest.java
   math/src/test/org/apache/commons/math/stat/regression
SimpleRegressionTest.java
  Log:
  Increased precision of target values used in tests.
  
  Revision  ChangesPath
  1.5   +9 -7  
jakarta-commons/math/src/test/org/apache/commons/math/stat/inference/ChiSquareTestTest.java
  
  Index: ChiSquareTestTest.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/math/src/test/org/apache/commons/math/stat/inference/ChiSquareTestTest.java,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- ChiSquareTestTest.java4 Dec 2004 20:52:43 -   1.4
  +++ ChiSquareTestTest.java10 Dec 2004 05:18:16 -  1.5
  @@ -47,16 +47,16 @@
   // Target values computed using R version 1.8.1 
   // Some assembly required ;-)  
   //  Use sum((obs - exp)^2/exp) for the chi-square statistic and
  -//  1 - pchisq(sum((obs - exp)^2/exp), obs.length - 1) for the 
p-value
  +//  1 - pchisq(sum((obs - exp)^2/exp), length(obs) - 1) for the 
p-value
   
   long[] observed = {10, 9, 11};
   double[] expected = {10, 10, 10};
   assertEquals("chi-square statistic", 0.2,  
testStatistic.chiSquare(expected, observed), 10E-12);
  -assertEquals("chi-square p-value", 0.9048374, 
testStatistic.chiSquareTest(expected, observed), 1E-7);
  +assertEquals("chi-square p-value", 0.904837418036, 
testStatistic.chiSquareTest(expected, observed), 1E-10);
   
   long[] observed1 = { 500, 623, 72, 70, 31 };
   double[] expected1 = { 485, 541, 82, 61, 37 };
  -assertEquals( "chi-square test statistic", 16.41311, 
testStatistic.chiSquare(expected1, observed1), 1E-5);
  +assertEquals( "chi-square test statistic", 16.4131070362, 
testStatistic.chiSquare(expected1, observed1), 1E-10);
   assertEquals("chi-square p-value", 0.002512096, 
testStatistic.chiSquareTest(expected1, observed1), 1E-9);
   assertTrue("chi-square test reject", 
testStatistic.chiSquareTest(expected1, observed1, 0.003));
   assertTrue("chi-square test accept", 
!testStatistic.chiSquareTest(expected1, observed1, 0.002));
  @@ -114,13 +114,13 @@
   
   long[][] counts = { {40, 22, 43}, {91, 21, 28}, {60, 10, 22}};
   assertEquals( "chi-square test statistic", 22.709027688, 
testStatistic.chiSquare(counts), 1E-9);
  -assertEquals("chi-square p-value", 0.0001448, 
testStatistic.chiSquareTest(counts), 1E-7);
  +assertEquals("chi-square p-value", 0.000144751460134, 
testStatistic.chiSquareTest(counts), 1E-9);
   assertTrue("chi-square test reject", 
testStatistic.chiSquareTest(counts, 0.0002));
   assertTrue("chi-square test accept", 
!testStatistic.chiSquareTest(counts, 0.0001));
   
   long[][] counts2 = {{10, 15}, {30, 40}, {60, 90} };
  -assertEquals( "chi-square test statistic", 0.169, 
testStatistic.chiSquare(counts2), 1E-3);
  -assertEquals("chi-square p-value", 0.919, 
testStatistic.chiSquareTest(counts2), 1E-3);
  +assertEquals( "chi-square test statistic", 0.168965517241, 
testStatistic.chiSquare(counts2), 1E-9);
  +assertEquals("chi-square p-value",0.918987499852, 
testStatistic.chiSquareTest(counts2), 1E-9);
   assertTrue("chi-square test accept", 
!testStatistic.chiSquareTest(counts2, 0.1)); 
   
   // ragged input array
  @@ -179,6 +179,8 @@
   new org.apache.commons.math.stat.inference.ChiSquareTestImpl(); 
   double cst = csti.chiSquareTest(exp, obs); 
   assertEquals("chi-square p-value", 0.0, cst, 1E-3);
  +assertEquals( "chi-square test statistic", 
  +3624883.342907764, testStatistic.chiSquare(exp, obs), 1E-9);
   }
   
   /** Contingency table containing zeros - PR # 32531 */
  
  
  
  1.4   +4 -4  
jakarta-commons/math/src/test/org/apache/commons/math/stat/regression/SimpleRegressionTest.java
  
  Index: SimpleRegressionTest.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/math/src/test/org/apache/commons/math/stat/regression/SimpleRegressionTest.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- SimpleRegressionTest.java 24 Oct 2004 21:47:16 -  1.3
  +++ SimpleRegressionTest.java 10 Dec 2004 05:18:16 -  1.4
  @@ -117,7 +117,7 @@
   regression.addData(corrData);
   assertEquals("number of observations", 17, regression.getN());
   assertEquals("r-square", .896123, regression.getRSquare(), 10E-6);
  -assertEquals("r", -.946638, regression.getR(), 10E-6);
  +assertEqua

cvs commit: jakarta-commons/math/src/test/org/apache/commons/math/distribution ExponentialDistributionTest.java

[psteitz]

psteitz 2004/12/09 21:16:52

  Modified:math/src/test/org/apache/commons/math/distribution
ExponentialDistributionTest.java
  Log:
  Fixed error in comment.
  
  Revision  ChangesPath
  1.16  +2 -2  
jakarta-commons/math/src/test/org/apache/commons/math/distribution/ExponentialDistributionTest.java
  
  Index: ExponentialDistributionTest.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/math/src/test/org/apache/commons/math/distribution/ExponentialDistributionTest.java,v
  retrieving revision 1.15
  retrieving revision 1.16
  diff -u -r1.15 -r1.16
  --- ExponentialDistributionTest.java  6 Jun 2004 16:39:06 -   1.15
  +++ ExponentialDistributionTest.java  10 Dec 2004 05:16:52 -  1.16
  @@ -25,7 +25,7 @@
   public class ExponentialDistributionTest extends 
ContinuousDistributionAbstractTest {
   
   /**
  - * Constructor for ChiSquareDistributionTest.
  + * Constructor for ExponentialDistributionTest.
* @param name
*/
   public ExponentialDistributionTest(String name) {
  
  
  

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

cvs commit: jakarta-commons/math project.xml build.xml

[psteitz]

psteitz 2004/12/09 21:12:52

  Modified:math project.xml build.xml
  Log:
  Post-1.0 update.
  
  Revision  ChangesPath
  1.55  +13 -2 jakarta-commons/math/project.xml
  
  Index: project.xml
  ===
  RCS file: /home/cvs/jakarta-commons/math/project.xml,v
  retrieving revision 1.54
  retrieving revision 1.55
  diff -u -r1.54 -r1.55
  --- project.xml   5 Dec 2004 17:21:30 -   1.54
  +++ project.xml   10 Dec 2004 05:12:52 -  1.55
  @@ -21,7 +21,7 @@
 3
 Math
 commons-math
  -  1.0
  +  1.1-dev
 2003
 Jakarta Commons Math
 The Math project is a library of lightweight, self-contained 
mathematics and statistics components addressing the most common practical 
problems not immediately available in the Java programming language or 
commons-lang.
  @@ -65,8 +65,19 @@
 
 
   
  +  1.0-RC1
  +  1.0
  +  MATH_1_0_RC1
  +
  +
  +  1.0-RC2
  +  1.0
  +  MATH_1_0_RC2
  +
  +
 1.0
 1.0
  +  MATH_1_0
   
 
 
  
  
  
  1.23  +4 -4  jakarta-commons/math/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/jakarta-commons/math/build.xml,v
  retrieving revision 1.22
  retrieving revision 1.23
  diff -u -r1.22 -r1.23
  --- build.xml 5 Dec 2004 17:34:27 -   1.22
  +++ build.xml 10 Dec 2004 05:12:52 -  1.23
  @@ -1,7 +1,7 @@
   
   
  -
  +
   
   
 
  @@ -20,7 +20,7 @@
 
 
 
  -  
  +  
 
 
   
  @@ -142,7 +142,7 @@
   
   
   
  -
  +
   
   
 
  
  
  

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

DO NOT REPLY [Bug 32625] New: - [lang] Can't subclass EqualsBuilder because isEquals is private

[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://issues.apache.org/bugzilla/show_bug.cgi?id=32625

   Summary: [lang] Can't subclass EqualsBuilder because isEquals is
private
   Product: Commons
   Version: 2.0 Final
  Platform: All
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Lang
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I want to create my own version of EqualsBuilder that not only goes through
arrays and checks if array contents are equal, but also goes through Maps,
Lists, Sets, etc.  I can't because isEquals is private and there is no setEquals
method.  Please make isEquals protected or add a setEquals method.  Thanks!

Matt

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

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

[martinc]

martinc 2004/12/09 21:11:55

  Modified:chainproject.properties
   chain/xdocs index.xml
  Log:
  Tweaks to the web site in preparation for 1.0 release.
  
  Revision  ChangesPath
  1.7   +2 -2  jakarta-commons/chain/project.properties
  
  Index: project.properties
  ===
  RCS file: /home/cvs/jakarta-commons/chain/project.properties,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- project.properties1 Jul 2004 21:46:45 -   1.6
  +++ project.properties10 Dec 2004 05:11:55 -  1.7
  @@ -44,7 +44,7 @@
   # commons site L&F
   ##
   maven.xdoc.jsl=../commons-build/commons-site.jsl
  -maven.xdoc.date=bottom
  +maven.xdoc.date=left
   maven.xdoc.poweredby.image=maven-feather.png
   maven.xdoc.version=${pom.currentVersion}
   
maven.xdoc.developmentProcessUrl=http://jakarta.apache.org/commons/charter.html
  
  
  
  1.7   +44 -39jakarta-commons/chain/xdocs/index.xml
  
  Index: index.xml
  ===
  RCS file: /home/cvs/jakarta-commons/chain/xdocs/index.xml,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- index.xml 17 Nov 2004 08:05:39 -  1.6
  +++ index.xml 10 Dec 2004 05:11:55 -  1.7
  @@ -17,16 +17,16 @@
   
   
   
  - 
  -  Overview
  -  Commons Documentation 
Team
  -  Martin Cooper
  -  Craig McClanahan
  - 
  +  
  +Overview
  +Commons Documentation 
Team
  +Martin Cooper
  +Craig McClanahan
  +  
   
  - 
  +  
   
  -
  +  
   
 A popular technique for organizing the execution of complex
 processing flows is the "Chain of Responsibility" pattern, as
  @@ -81,38 +81,43 @@
 can be directly measured by observing the corresponding state
 changes in the context that is supplied.
   
  -
  -
  -  The latest release of Apache Jakarta Commons Chain is version 1.0. It is 
available (from mirrors) in http://jakarta.apache.org/site/binindex.cgi";>binary  and http://jakarta.apache.org/site/sourceindex.cgi";>source  downloads. 
  -
  -
  -
  -
  -
  -
  -
  -
  - 
  -  The Javadoc of the latest CVS
  -  The Cookbook containing "recipes" for 
using the chain.
  -  The http://cvs.apache.org/viewcvs/jakarta-commons/chain/";>CVS 
repository can be browsed.
  - 
  -
  -
  -
  -
  -
  -
  - 
  -  http://www.apache.org/dist/jakarta/commons/chain/";>Version 
1.0
  -  
  -
  -
  -Unofficial http://cvs.apache.org/builds/jakarta-commons/nightly/commons-chain/";>nightly
 builds
  -are available, however these should be treated with care.
  -
  +  
   
  -
  +  
  +
  +  
  +The Javadoc of the latest 
CVS.
  +The Cookbook containing "recipes" 
for using the chain.
  +The http://cvs.apache.org/viewcvs/jakarta-commons/chain/";>CVS repository 
can be browsed.
  +  
  +
  +  
  +
  +  
  +
  +  
  +Chain 1.0 - 9 Dec 2004
  +
  +  Download the binary distribution from a mirror site
  +here
  +  
  +  Download the source distribution from a mirror site
  +here
  +  
  +
  +  
  +
  +   
  +  
  +Nightly builds are built every day from the current CVS HEAD. This 
is 
  +the latest code and so should be treated with caution!
  +  
  +  
  +Download nightly builds from 
  +here.
  +  
  +
  +  
   
   
   
  
  
  

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

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[Matt Sgarlata]

Martin Cooper wrote:
This sure doesn't sound like Commons Logging would be "an ultra-thin
bridge between different logging libraries" any more.
http://jakarta.apache.org/commons/logging/
This sounds more like a different package altogether. IMO, we have
enough trouble as it is with some people resisting adding a dependency
on Commons Logging that the last thing I want to see is a bunch more
functionality - and size - added to this component.
--
Martin Cooper
 

I think Log4J does support internationalization of log messages, so I 
think the (important) goal of remaining an "ultra-thin bridge" is 
maintained.  To support this added functionality, perhaps a 
sub-interface of Log could be used like this:

private static final LocalLog = (LocalLog) LogFactory.getLog(MyClass.class);
If the underlying logging implementation is not able to return a 
LocalLog, a runtime exception is thrown.

(Here's the JavaDoc that leads me to believe i18n is supported by Log4J)
http://logging.apache.org/log4j/docs/api/org/apache/log4j/Category.html#l7dlog(org.apache.log4j.Priority,%20java.lang.String,%20java.lang.Object[],%20java.lang.Throwable)
Also, regarding David's post (below), I couldn't agree more.  I think a 
generic log.finest is more appropriate than forcing log messages to 
contain class and method information.  If you want log.enter and 
log.exit, make your own wrapper Log implementation or a simple static 
utility function like MyLogHelper.enter(log, "MyClass", "MyMethod", 
"Entering memthod")

Regarding the addition of "entry/exit" logging APIs, I'm also in favour.
The code seems trivial, and it can be mapped to "TRACE" level for
logging implementations that don't provide "FINER" equivalents. It also
seems to me that:
  log.enter("MyClass", "MyMethod", "Entering method");
is nice and readable.

Until you refactor the class name or method name.  Then your logging code
is completely misleading.  Considering the fact that IDEs allow you to
rename things without even looking at their implementation code, the
chance of the logging not keeping up with the names is high.
I would personally never use the enter/exit methods for those reasons.  If
I wanted that kind of detail, I would use AspectJ.
David


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

Re: cvs commit: jakarta-commons/jelly/src/java/org/apache/commons/jelly/util CommandLineParser.java

[Dion Gillard]

More tabs?

And how about a simple test case for this? Is it possible?


On 8 Dec 2004 10:00:29 -, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> polx2004/12/08 02:00:29
> 
>   Modified:jelly/src/java/org/apache/commons/jelly/util
> CommandLineParser.java
>   Log:
>   Passing a property with "=" sign in the value was giving an "invalid" system
>   property! Fixed.
>   paul
> 
>   Revision  ChangesPath
>   1.8   +5 -10 
> jakarta-commons/jelly/src/java/org/apache/commons/jelly/util/CommandLineParser.java
> 
>   Index: CommandLineParser.java
>   ===
>   RCS file: 
> /home/cvs/jakarta-commons/jelly/src/java/org/apache/commons/jelly/util/CommandLineParser.java,v
>   retrieving revision 1.7
>   retrieving revision 1.8
>   diff -u -r1.7 -r1.8
>   --- CommandLineParser.java9 Sep 2004 15:10:05 -   1.7
>   +++ CommandLineParser.java8 Dec 2004 10:00:28 -   1.8
>   @@ -146,15 +146,10 @@
>// -D args will not be copied into the filteredArgList.
>if (arg.startsWith("-D") && (arg.length() > 2)) {
>arg = arg.substring(2);
>   -StringTokenizer toks = new StringTokenizer(arg, "=");
>   -
>   -if (toks.countTokens() == 2) {
>   -// add the tokens to the system properties
>   -sysProps.setProperty(toks.nextToken(), 
> toks.nextToken());
>   -} else {
>   -System.err.println("Invalid system property: " + arg);
>   -}
>   -
>   + int ePos = arg.indexOf("=");
>   + if(ePos==-1 || ePos==0 || 
> ePos==arg.length()-1)
>   + System.err.println("Invalid system 
> property: \"" + arg + "\".");
>   + sysProps.setProperty(arg.substring(0,ePos), 
> arg.substring(ePos+1));
>} else {
>// add this to the filtered list of arguments
>filteredArgList.add(arg);
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 


-- 
http://www.multitask.com.au/people/dion/

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

Re: cvs commit: jakarta-commons/jelly maven.xml

[Dion Gillard]

Looks like some tabs crept in.


On 8 Dec 2004 10:02:17 -, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> polx2004/12/08 02:02:17
> 
>   Modified:jellymaven.xml
>   Log:
>   Pack-fat-jar now always includes the jelly in snapshot form... otherwise
>   mismatches occur...
>   paul
> 
>   Revision  ChangesPath
>   1.88  +4 -1  jakarta-commons/jelly/maven.xml
> 
>   Index: maven.xml
>   ===
>   RCS file: /home/cvs/jakarta-commons/jelly/maven.xml,v
>   retrieving revision 1.87
>   retrieving revision 1.88
>   diff -u -r1.87 -r1.88
>   --- maven.xml 16 Sep 2004 05:59:27 -  1.87
>   +++ maven.xml 8 Dec 2004 10:02:17 -   1.88
>   @@ -400,7 +400,10 @@
>  
> 
>  
>   - items="${reactorProject.dependencies}">${deps.add(dep)}
>   +
>   + ${dep.setVersion("SNAPSHOT")}
>   + ${deps.add(dep)}
>   + 
>  
>  
>
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 


-- 
http://www.multitask.com.au/people/dion/

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

RE: [logging] Enterprise Common Logging... dare we say 2.0?

[Richard Sitze]

We don't globalize trace level messaging [debug, entry/exit, trace]

Simon Kitching <[EMAIL PROTECTED]> wrote on 12/09/2004 07:23:54 
PM:

> On Fri, 2004-12-10 at 13:20, Charles Daniels wrote:
> > > -Original Message-
> > > From: Emmanuel Bourg [mailto:[EMAIL PROTECTED] 
> > > Sent: Thursday, December 09, 2004 4:54 PM
> > > To: Jakarta Commons Developers List
> > > Subject: Re: [logging] Enterprise Common Logging... dare we say 2.0?
> > > 
> > > I'm not a logging expert, but couldn't the internationalized 
> > > logger be 
> > > just a specific Log implementation ? You would just log the 
> > > key of the 
> > > message with the existing methods :
> > > 
> > > log.warn("key");
> > > 
> > > The Locale would be a configuration parameter. There is just an 
issue 
> > > with the message's parameters :) This will require at least an 
> > > additional method like warn(String, Object[]).
> > 
> > Since all of the logging methods (fatal, error, etc.) accept a message
> > of type Object, you could support i18n/l10n by doing something like 
the
> > following:
> > 
> > log.warn(new Message("key", params));
> > 
> > where params is an Object[].  Of course, Message could have additional
> > constructors.
> > 
> > The Message class would encapsulate all l10n functionality.  This way,
> > you probably wouldn't even have to create any new implementations
> > specifically for handling i18n/l10n.  Further, you probably wouldn't
> > even have to modify existing Log implementations since most of them
> > (perhaps all?) just end up doing something like 
String.valueOf(message)
> > to get the actual text to log.  Therefore, the new Message class would
> > simply implement toString to properly construct the localized message.
> 
> Alas, I don't think that is efficient enough. This approach would
> require a new Message object to be created *before* each call,
> regardless of whether that logging level was enabled or not.
> 
> Of course, each call could be wrapped in:
>   if (log.isWarnEnabled()) {
> log.warn(new Message());
>   }
> but that would get tiring very quickly!
> 
> Actually, for warn/error/fatal, this approach is probably not too bad.
> After all, there won't be a whole lot of such calls, and they *are*
> likely to have logging enabled.
> 
> It's only for debug/trace levels that this approach would have problems.
> Is it really important to "globalize" debug and trace messages?
> 
> Regardless of the performance, though, there is still the matter of
> exactly where the messagekey+params gets converted to a message string.
> Having a user-provided Message object do it delegates the responsibility
> of locating the i18n resource bundle to the logging app, which may or
> may not be appropriate. Having an underlying log adapter class do it (a
> kind of "i18n decorator" pattern?) raises the issue of how it would
> locate the bundle. Log adaptor classes don't currently deal with
> configuration in any way AFAIK; they just pass the message down.
> 
> Regards,
> 
> Simon
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 



***
Richard A. Sitze
IBM WebSphere WebServices Development


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

RE: [logging] Enterprise Common Logging... dare we say 2.0?

[Richard Sitze]

"Charles Daniels" <[EMAIL PROTECTED]> wrote on 12/09/2004 07:42:47 PM:

> 8<
> 
> > > 
> > > Since all of the logging methods (fatal, error, etc.) 
> > accept a message
> > > of type Object, you could support i18n/l10n by doing 
> > something like the
> > > following:
> > > 
> > > log.warn(new Message("key", params));
> > > 
> > > where params is an Object[].  Of course, Message could have 
> > additional
> > > constructors.
> > > 
> > > The Message class would encapsulate all l10n functionality. 
> >  This way,
> > > you probably wouldn't even have to create any new implementations
> > > specifically for handling i18n/l10n.  Further, you probably wouldn't
> > > even have to modify existing Log implementations since most of them
> > > (perhaps all?) just end up doing something like 
> > String.valueOf(message)
> > > to get the actual text to log.  Therefore, the new Message 
> > class would
> > > simply implement toString to properly construct the 
> > localized message.
> > 
> > Alas, I don't think that is efficient enough. This approach would
> > require a new Message object to be created *before* each call,
> > regardless of whether that logging level was enabled or not.
> > 
> > Of course, each call could be wrapped in:
> >   if (log.isWarnEnabled()) {
> > log.warn(new Message());
> >   }
> > but that would get tiring very quickly!
> 
> That's what you should be doing already, even without the proposed
> Message class, unless you are passing only a string literal (i.e., not a
> string constructed via concatenation), otherwise you take a performance
> hit regardless.  For example:
> 
>   log.warn("No such object: " + name);
> 
> You would want a code guard around this to avoid unnecessary
> concatenation.  Even the new internationalized logging methods (as
> proposed earlier in this thread) were add, you would still want to use a
> code guard when passing multiple message parameters:
> 
>   log.warn("key", new Object[] { param1, param2 });
> 
> Otherwise you might unnecessarily create the object array.  So you
> should really be using code guards as a matter of practice anyway.
> 
> > 
> > Actually, for warn/error/fatal, this approach is probably not too bad.
> > After all, there won't be a whole lot of such calls, and they *are*
> > likely to have logging enabled.
> > 
> > It's only for debug/trace levels that this approach would 
> > have problems.
> > Is it really important to "globalize" debug and trace messages?
> 
> JCL User Guide proposes that debug and trace messages NOT be localized.
> Only warn/error/fatal messages are to be localized.  Therefore, in the
> case of debug/trace messages, no Message instances would be used, so
> there is no problem.
> 
> > 
> > Regardless of the performance, though, there is still the matter of
> > exactly where the messagekey+params gets converted to a 
> > message string.
> > Having a user-provided Message object do it delegates the 
> > responsibility
> > of locating the i18n resource bundle to the logging app, which may or
> > may not be appropriate. Having an underlying log adapter 
> > class do it (a
> > kind of "i18n decorator" pattern?) raises the issue of how it would
> > locate the bundle. Log adaptor classes don't currently deal with
> > configuration in any way AFAIK; they just pass the message down.
> 
> Yes, I agree, the trick then becomes locating the resource bundle.
> Perhaps one way to do this is to have the Message class locate it based
> upon a property in commons-logging.properties.  The Message.toString
> method would then lookup the  resource and construct the message.  This
> way, neither the application nor the Log implementation would have to
> deal with it.

The resource bundle is named on the EnterpriseLogFactory factory methods 
that produce the EnterpriseLog.  It's up the the wrapper/implementation to 
determine what to do with the resource bundle name and keys.

Keep it simple

> 
> > 
> > Regards,
> > 
> > Simon


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

RE: [logging] Enterprise Common Logging... dare we say 2.0?

[Richard Sitze]

"Charles Daniels" <[EMAIL PROTECTED]> wrote on 12/09/2004 06:20:14 PM:

> > -Original Message-
> > From: Emmanuel Bourg [mailto:[EMAIL PROTECTED] 
> > Sent: Thursday, December 09, 2004 4:54 PM
> > To: Jakarta Commons Developers List
> > Subject: Re: [logging] Enterprise Common Logging... dare we say 2.0?
> > 
> > I'm not a logging expert, but couldn't the internationalized 
> > logger be 
> > just a specific Log implementation ? You would just log the 
> > key of the 
> > message with the existing methods :
> > 
> > log.warn("key");
> > 
> > The Locale would be a configuration parameter. There is just an issue 
> > with the message's parameters :) This will require at least an 
> > additional method like warn(String, Object[]).

I think there is value in an explicit contract between the component 
developer and the logger... if the logger doesn't support i18n, then that 
logger can't be used.

> 
> Since all of the logging methods (fatal, error, etc.) accept a message
> of type Object, you could support i18n/l10n by doing something like the
> following:
> 
> log.warn(new Message("key", params));
> 
> where params is an Object[].  Of course, Message could have additional
> constructors.
> 
> The Message class would encapsulate all l10n functionality.  This way,
> you probably wouldn't even have to create any new implementations
> specifically for handling i18n/l10n.  Further, you probably wouldn't
> even have to modify existing Log implementations since most of them
> (perhaps all?) just end up doing something like String.valueOf(message)
> to get the actual text to log.  Therefore, the new Message class would
> simply implement toString to properly construct the localized message.

We considered that, and it can certainly be discussed here... the problem 
with this approach is

a) the overhead of newing up objects
b) more "work" for the developer, we want to "enable" globalization by 
more direct support

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



***
Richard A. Sitze
IBM WebSphere WebServices Development


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

RE: [logging] Enterprise Common Logging... dare we say 2.0?

[Charles Daniels]

 

> -Original Message-
> From: Simon Kitching [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, December 09, 2004 6:39 PM
> To: Jakarta Commons Developers List
> Subject: RE: [logging] Enterprise Common Logging... dare we say 2.0?
> 
> On Fri, 2004-12-10 at 14:23, Simon Kitching wrote:
> 
> > Alas, I don't think that is efficient enough. This approach would
> > require a new Message object to be created *before* each call,
> > regardless of whether that logging level was enabled or not.
> > 
> > Of course, each call could be wrapped in:
> >   if (log.isWarnEnabled()) {
> > log.warn(new Message());
> >   }
> > but that would get tiring very quickly!
> 
> Not to mention that it is pretty much equivalent to:
>   if (log.isWarnEnabled()) {  
> // compute internationalised message by hand
> // using a resource bundle, key + params
> log.warn(msgString);
>   }

Not really.  The code that should go where your comment exists is not as
trivial as a couple lines of code.  Also, as I mentioned in my other
reply, using such code guards should really be common practice, usually
to avoid unnecessary string concatenation when constructing the message
to be logged.

Further, as mentioned earlier in this thread, by putting the i18n/l10n
functionality within the JCL, you avoid reinventing the wheel across
projects.

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


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

RE: [logging] Enterprise Common Logging... dare we say 2.0?

[Charles Daniels]

8<

> > 
> > Since all of the logging methods (fatal, error, etc.) 
> accept a message
> > of type Object, you could support i18n/l10n by doing 
> something like the
> > following:
> > 
> > log.warn(new Message("key", params));
> > 
> > where params is an Object[].  Of course, Message could have 
> additional
> > constructors.
> > 
> > The Message class would encapsulate all l10n functionality. 
>  This way,
> > you probably wouldn't even have to create any new implementations
> > specifically for handling i18n/l10n.  Further, you probably wouldn't
> > even have to modify existing Log implementations since most of them
> > (perhaps all?) just end up doing something like 
> String.valueOf(message)
> > to get the actual text to log.  Therefore, the new Message 
> class would
> > simply implement toString to properly construct the 
> localized message.
> 
> Alas, I don't think that is efficient enough. This approach would
> require a new Message object to be created *before* each call,
> regardless of whether that logging level was enabled or not.
> 
> Of course, each call could be wrapped in:
>   if (log.isWarnEnabled()) {
> log.warn(new Message());
>   }
> but that would get tiring very quickly!

That's what you should be doing already, even without the proposed
Message class, unless you are passing only a string literal (i.e., not a
string constructed via concatenation), otherwise you take a performance
hit regardless.  For example:

  log.warn("No such object: " + name);

You would want a code guard around this to avoid unnecessary
concatenation.  Even the new internationalized logging methods (as
proposed earlier in this thread) were add, you would still want to use a
code guard when passing multiple message parameters:

  log.warn("key", new Object[] { param1, param2 });

Otherwise you might unnecessarily create the object array.  So you
should really be using code guards as a matter of practice anyway.

> 
> Actually, for warn/error/fatal, this approach is probably not too bad.
> After all, there won't be a whole lot of such calls, and they *are*
> likely to have logging enabled.
> 
> It's only for debug/trace levels that this approach would 
> have problems.
> Is it really important to "globalize" debug and trace messages?

JCL User Guide proposes that debug and trace messages NOT be localized.
Only warn/error/fatal messages are to be localized.  Therefore, in the
case of debug/trace messages, no Message instances would be used, so
there is no problem.

> 
> Regardless of the performance, though, there is still the matter of
> exactly where the messagekey+params gets converted to a 
> message string.
> Having a user-provided Message object do it delegates the 
> responsibility
> of locating the i18n resource bundle to the logging app, which may or
> may not be appropriate. Having an underlying log adapter 
> class do it (a
> kind of "i18n decorator" pattern?) raises the issue of how it would
> locate the bundle. Log adaptor classes don't currently deal with
> configuration in any way AFAIK; they just pass the message down.

Yes, I agree, the trick then becomes locating the resource bundle.
Perhaps one way to do this is to have the Message class locate it based
upon a property in commons-logging.properties.  The Message.toString
method would then lookup the  resource and construct the message.  This
way, neither the application nor the Log implementation would have to
deal with it.

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


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

RE: [logging] Enterprise Common Logging... dare we say 2.0?

[Simon Kitching]

On Fri, 2004-12-10 at 14:23, Simon Kitching wrote:

> Alas, I don't think that is efficient enough. This approach would
> require a new Message object to be created *before* each call,
> regardless of whether that logging level was enabled or not.
> 
> Of course, each call could be wrapped in:
>   if (log.isWarnEnabled()) {
> log.warn(new Message());
>   }
> but that would get tiring very quickly!

Not to mention that it is pretty much equivalent to:
  if (log.isWarnEnabled()) {  
// compute internationalised message by hand
// using a resource bundle, key + params
log.warn(msgString);
  }



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

RE: [logging] Enterprise Common Logging... dare we say 2.0?

[Simon Kitching]

On Fri, 2004-12-10 at 13:20, Charles Daniels wrote:
> > -Original Message-
> > From: Emmanuel Bourg [mailto:[EMAIL PROTECTED] 
> > Sent: Thursday, December 09, 2004 4:54 PM
> > To: Jakarta Commons Developers List
> > Subject: Re: [logging] Enterprise Common Logging... dare we say 2.0?
> > 
> > I'm not a logging expert, but couldn't the internationalized 
> > logger be 
> > just a specific Log implementation ? You would just log the 
> > key of the 
> > message with the existing methods :
> > 
> > log.warn("key");
> > 
> > The Locale would be a configuration parameter. There is just an issue 
> > with the message's parameters :) This will require at least an 
> > additional method like warn(String, Object[]).
> 
> Since all of the logging methods (fatal, error, etc.) accept a message
> of type Object, you could support i18n/l10n by doing something like the
> following:
> 
> log.warn(new Message("key", params));
> 
> where params is an Object[].  Of course, Message could have additional
> constructors.
> 
> The Message class would encapsulate all l10n functionality.  This way,
> you probably wouldn't even have to create any new implementations
> specifically for handling i18n/l10n.  Further, you probably wouldn't
> even have to modify existing Log implementations since most of them
> (perhaps all?) just end up doing something like String.valueOf(message)
> to get the actual text to log.  Therefore, the new Message class would
> simply implement toString to properly construct the localized message.

Alas, I don't think that is efficient enough. This approach would
require a new Message object to be created *before* each call,
regardless of whether that logging level was enabled or not.

Of course, each call could be wrapped in:
  if (log.isWarnEnabled()) {
log.warn(new Message());
  }
but that would get tiring very quickly!

Actually, for warn/error/fatal, this approach is probably not too bad.
After all, there won't be a whole lot of such calls, and they *are*
likely to have logging enabled.

It's only for debug/trace levels that this approach would have problems.
Is it really important to "globalize" debug and trace messages?

Regardless of the performance, though, there is still the matter of
exactly where the messagekey+params gets converted to a message string.
Having a user-provided Message object do it delegates the responsibility
of locating the i18n resource bundle to the logging app, which may or
may not be appropriate. Having an underlying log adapter class do it (a
kind of "i18n decorator" pattern?) raises the issue of how it would
locate the bundle. Log adaptor classes don't currently deal with
configuration in any way AFAIK; they just pass the message down.

Regards,

Simon


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

DO NOT REPLY [Bug 32623] - [net] FTP component: FTPFile does not initialize miliseconds correctly

[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://issues.apache.org/bugzilla/show_bug.cgi?id=32623


[EMAIL PROTECTED] changed:

   What|Removed |Added

 OS/Version|Windows 2000|All
   Platform|PC  |All
Summary|FTP component: FTPFile does |[net] FTP component: FTPFile
   |not initialize miliseconds  |does not initialize
   |correctly   |miliseconds correctly




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[David Graham]

--- simon <[EMAIL PROTECTED]> wrote:
 

> Regarding the addition of "entry/exit" logging APIs, I'm also in favour.
> The code seems trivial, and it can be mapped to "TRACE" level for
> logging implementations that don't provide "FINER" equivalents. It also
> seems to me that:
>   log.enter("MyClass", "MyMethod", "Entering method");
> is nice and readable.

Until you refactor the class name or method name.  Then your logging code
is completely misleading.  Considering the fact that IDEs allow you to
rename things without even looking at their implementation code, the
chance of the logging not keeping up with the names is high.

I would personally never use the enter/exit methods for those reasons.  If
I wanted that kind of detail, I would use AspectJ.

David

> 
> Simon




__ 
Do you Yahoo!? 
Yahoo! Mail - You care about security. So do we. 
http://promotions.yahoo.com/new_mail

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

DO NOT REPLY [Bug 32623] New: - FTP component: FTPFile does not initialize miliseconds correctly

[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://issues.apache.org/bugzilla/show_bug.cgi?id=32623

   Summary: FTP component: FTPFile does not initialize miliseconds
correctly
   Product: Commons
   Version: 1.2 Final
  Platform: PC
OS/Version: Windows 2000
Status: NEW
  Severity: normal
  Priority: P2
 Component: Net
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Hi, I have been working with the FTP utilities and was saving the filename and 
lastModifiedTime (as taken from FTPFile.lastModifiedTime()) and had a problem 
where I would query a directory, save those two parameters for each of the 
files, then later on query the same directory (which in my test case has not 
changed any) and I would find that the FTPFile.lastModifiedTime() objects did 
not match. 

In looking furthur into it I found that the calendar objects returned by this 
function were off by a some random number of milliseconds, however it looked 
like the hour, minutes, and all other times of the calendar were correct, it 
was only the milliseconds.

Drilling furthur into the source code for the Commons FTP components I think I 
see what was overlooked to cause this condition.

In version 1.2.2 if you look at the UnixFTPEntryParser.java source (I believe 
this is the parser being used for my WSFTP server I am running, you can 
download this ftp server from download.com, I am using this for my development 
environment), looking on line 185 you have the following code:

Calendar cal = Calendar.getInstance();
cal.set(Calendar.SECOND, 0);
cal.set(Calendar.MINUTE, 0);
cal.set(Calendar.HOUR_OF_DAY, 0);

I see that you are initially creating a new calendar instance, which, by 
default sets the calendar to the current time. Then you update the seconds, 
minutes, and hour of dat, however you are not initializing the miliseconds, 
hence the miliseconds vary between different instantiations of the same ftp 
entry.  This causes the Calendar.equals() function to indicate that the two 
times are different, though they should be equal.

If you add:
cal.set(Calendar.MILLISECOND, 0);

I think you eliminate this problem.

Best regards,
David

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 32423] - [net] FTP component fails to throw error when ftp site fails to list contents 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://issues.apache.org/bugzilla/show_bug.cgi?id=32423





--- Additional Comments From [EMAIL PROTECTED]  2004-12-10 01:29 ---
Hi, actually the dir listing I did was a bad example. The directory which gave 
a 0 size array had over 100 files in it, I provided the example shown on a 
directory with less files in it just so I could show the 200/425 errors that I 
was receiving without cluttering the screen with a ton of files when it worked. 
I did very carefully walk through my side of the code and am sure it was doing 
a query on a directory with many files (or at least many directories) in it.


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[simon]

On Fri, 2004-12-10 at 10:29, David Graham wrote:
> "Enterprise" is marketing speak for "expensive".  It has no technical
> meaning so including that word in class names is rather confusing.  It
> looks like the new functionality is related to i18n of messages so naming
> the classes something like I18NLog or GlobalizedLog would be more
> appropriate.
> 

+1 from me. Enterprise seems rather too grand a word for the fairly
simple proposed changes.

Actually, I would suggest a classname of "Logger" rather than Log. This
brings it even more in line with JSR-47.

And I would suggest making the new interface (currently "EnterpriseLog")
an abstract class rather than an interface. This means that in future
new functionality *can* be added without introducing a new interface +
associated factory. Several commons projects are moving away from
interfaces and towards abstract classes for this reason. Of course this
must be used appropriately, but I can't see anyone wanting to subclass
from both EnterpriseLog *and* some other base class.


Regarding the "Globalisation" changes, I'm generally in favour of the
proposal. In particular, using MessageFormat-style strings eg "a {0}
problem occurred" allows the underlying implementation to perform the
string formatting only after checking whether the loglevel is enabled,
thus allowing some of the
  if (log.isDebugEnabled()) {
log.debug("a " + description + " problem occurred.");
  }
type code to be simplified. I am a little concerned about how the
resource-bundle gets selected, though. As mentioned later,
commons-logging currently needs *no* configuration, and I think that is
a big feature.

Regarding the addition of "entry/exit" logging APIs, I'm also in favour.
The code seems trivial, and it can be mapped to "TRACE" level for
logging implementations that don't provide "FINER" equivalents. It also
seems to me that:
  log.enter("MyClass", "MyMethod", "Entering method");
is nice and readable.

== discovery

Regarding changes to the commons-log "discovery" process, I'm far less
convinced. I personally like the fact that commons-logging works fine
without any commons-logging-specific configuration. Essentially, a
person deploying an application built with commons-logging doesn't need
to know that commons-logging is used by the application. They just
configure whatever logging library is available in the environment the
application is being deployed into, and commons-logging auto-detects
that library and uses it.

Having an "override" option so that commons-logging can be *forced* to
use a specific logging implementation is not a bad idea - but there is
such a feature already. Users can set system property
org.apache.commons.logging.LogFactory, or use standard Service
Discovery, or place a commons-logging.properties file in the classpath,
as described in the javadocs for LogFactory.getFactory(). 

Can you explain what functionality you need for controlling "discovery"
that is not provided by the above?

== Class Loaders

I haven't read this thoroughly yet, but I see you talk about walking
classpaths to find config files. I presume you are *not* talking about
configuration files to be processed by the underlying log
implementation? Commons-logging has *never* been involved in configuring
concrete log implementations, merely about determining which concrete
logging implementation to delegate logged messages to. Ok, it does have
configuration for the SimpleLog logger, but that is a special case.

== Repackaging

Separating out the various adapters to the concrete logging
implementations has been proposed before. I'm not wildly keen on the
idea myself, as it break the principle that deployers of an application
using commons-logging don't need to care that the app uses
commons-logging, as long as the concrete log implementation available
has an adapter already bundled with commons-logging.

== Misc

Being able to query the logger implementation: you can do this already
via "log.getClass().getName()" -->
"org.apache.commons.logging.impl.Log4jLog" or whatever. But if you can
provide a use-case where a nicer string would be useful, then I can't
seen any major problem with a getLogImplName() method on the new
EnterpriseLog/Logger/whatever interface.

By "an Assert", do you mean:
  log.assert(1+1==2, "Mathematics has failed");
If so, I'm neutral on this. Clearly, after logging the message, some
kind of error would need to be thrown. It can't be
java.lang.AssertionError, because that is only available in java 1.4+.
And any other type would bind the application to commons-logging at the
point it tried to handle the error, even if that class wasn't otherwise
using commons-logging.

I don't understand your point re "naming" loggers. Can you clarify?

Regards,

Simon


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

RE: [logging] Enterprise Common Logging... dare we say 2.0?

[Charles Daniels]

> -Original Message-
> From: Emmanuel Bourg [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, December 09, 2004 4:54 PM
> To: Jakarta Commons Developers List
> Subject: Re: [logging] Enterprise Common Logging... dare we say 2.0?
> 
> I'm not a logging expert, but couldn't the internationalized 
> logger be 
> just a specific Log implementation ? You would just log the 
> key of the 
> message with the existing methods :
> 
> log.warn("key");
> 
> The Locale would be a configuration parameter. There is just an issue 
> with the message's parameters :) This will require at least an 
> additional method like warn(String, Object[]).

Since all of the logging methods (fatal, error, etc.) accept a message
of type Object, you could support i18n/l10n by doing something like the
following:

log.warn(new Message("key", params));

where params is an Object[].  Of course, Message could have additional
constructors.

The Message class would encapsulate all l10n functionality.  This way,
you probably wouldn't even have to create any new implementations
specifically for handling i18n/l10n.  Further, you probably wouldn't
even have to modify existing Log implementations since most of them
(perhaps all?) just end up doing something like String.valueOf(message)
to get the actual text to log.  Therefore, the new Message class would
simply implement toString to properly construct the localized message.

> 
> Emmanuel Bourg
> 
> 


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

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[simon]

On Fri, 2004-12-10 at 09:40, Matt Sgarlata wrote:
> Richard Sitze wrote:
> 
> >  - For message level logging, support globalized
> >variants on the new EnterpriseLog interface:
> >
> >info(Class callingClass,
> > String methodName,
> > String messageID);
> >
> >info(Class callingClass,
> > String methodName,
> > String messageID,
> > Object messageParam);
> >
> >info(Class callingClass,
> > String methodName,
> > String messageID,
> > Object[] messageParams);
> >
> >same for warn, error, fatal.
> >  
> >
> I don't understand why the calling class and method name are included.  
> Can't this information simply be retrieved from the current stack trace 
> by the underlying logging implementation?  I would think a cleaner 
> approach would be one of the alternatives below (note we have to avoid 
> conflicting with the existing info, warn, error, etc. methods)
> 
> info(String defaultMessage, String messageKey);
> info(String defaultMessage, String messageKey, Object param);
> info(String defaultMessage, String messageKey, Object[] params);

Unfortunately, when optimisation has been applied to java code, class
and method information is not always available via stack traces. I
expect that if pre-compilation (eg gcj) has been applied then the
problem will be even worse. This is (presumably) why the JSR-47
java.util.logging API takes class/method parameters.

> Also, I don't want to type
> 
> private static final EnterpriseLog log = 
> EnterpriseLogFactory.getClass(MyVeryLongClassName.class);
> 
> I would think this new functionality could be added directly to the 
> existing Log and LogFactory classes.

Log is an interface. Because of this, it is not possible to add methods
to it without breaking binary compatibility. The proposed approach of
adding the EnterpriseLog interface (and associated factory) is an
attempt to "enhance" the existing log library rather than break
compatibility.

Regards,

Simon


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

DO NOT REPLY [Bug 32619] - [lang] Minor tweak to fix of bug # 26616

[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://issues.apache.org/bugzilla/show_bug.cgi?id=32619


[EMAIL PROTECTED] changed:

   What|Removed |Added

 OS/Version|Windows 2000|All
   Platform|PC  |All
Summary|Minor tweak to fix of bug # |[lang] Minor tweak to fix of
   |26616   |bug # 26616




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[Emmanuel Bourg]

I'm not a logging expert, but couldn't the internationalized logger be 
just a specific Log implementation ? You would just log the key of the 
message with the existing methods :

log.warn("key");
The Locale would be a configuration parameter. There is just an issue 
with the message's parameters :) This will require at least an 
additional method like warn(String, Object[]).

Emmanuel Bourg


smime.p7s
Description: S/MIME Cryptographic Signature

RE: [logging] Enterprise Common Logging... dare we say 2.0?

[Charles Daniels]

Aha!  Now it's all becoming quite clear ;-) 

> -Original Message-
> From: Richard Sitze [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, December 09, 2004 4:29 PM
> To: Jakarta Commons Developers List
> Subject: RE: [logging] Enterprise Common Logging... dare we say 2.0?
> 
> Huh... is this where I hide in the corner and pretend that I 
> didn't write 
> that section of the user's guide?
> 
> 
> "Charles Daniels" <[EMAIL PROTECTED]> wrote on 12/09/2004 05:20:24 PM:
> 
> 
> 
> > Further, the JCL User Guide has a section labeled "National Language
> > Support And Internationalization", in which the following excerpt
> > appears:
> > 
> > "NLS internationalization SHOULD be strongly considered for used for
> > fatal, error, warn, and info messages. It is generally considered
> > optional for debug and trace messages. 
> > 
> > Perhaps more direct support for internationalizing log 
> messages can be
> > introduced in a future or alternate version of the Log interface."
> > 
> > So it seems to me that the suggestion from IBM is not 
> necessarily making
> > the "thin bridge" any fatter.  Rather, it is simply 
> following up on what
> > is already suggested in the User Guide.
> 
> 
> 
> ***
> Richard A. Sitze
> IBM WebSphere WebServices Development
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 


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

RE: [logging] Enterprise Common Logging... dare we say 2.0?

[Richard Sitze]

Huh... is this where I hide in the corner and pretend that I didn't write 
that section of the user's guide?


"Charles Daniels" <[EMAIL PROTECTED]> wrote on 12/09/2004 05:20:24 PM:



> Further, the JCL User Guide has a section labeled "National Language
> Support And Internationalization", in which the following excerpt
> appears:
> 
> "NLS internationalization SHOULD be strongly considered for used for
> fatal, error, warn, and info messages. It is generally considered
> optional for debug and trace messages. 
> 
> Perhaps more direct support for internationalizing log messages can be
> introduced in a future or alternate version of the Log interface."
> 
> So it seems to me that the suggestion from IBM is not necessarily making
> the "thin bridge" any fatter.  Rather, it is simply following up on what
> is already suggested in the User Guide.



***
Richard A. Sitze
IBM WebSphere WebServices Development


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

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[Richard Sitze]

The discovery process is a concern.  It's not trivial.  It only gets worse 
over time.  Enough said.

To be quite frank, here is what I believe to be the right strategy

1.  Implement a "workable" discovery mechanism where it belongs... in 
Commons Discovery.

2.  Have the existing LogFactory attempt to use Commons Discovery, and 
failing that fall back to...

3.  Clean up [for 2.0] the LogFactory mechanisms... simplify, simplify, 
simplify...  minimize, minimize..  I'm advocating regressive behavior with 
this statement.  This is necessary to "fix" the problems we had with 
1.0.x.

If you *want* solid discovery, the price should be bringing that it your 
environment.  I think a simple J2SE [single classloader] discovery is 
reasonable for the LogFactory, should hit the 80% user mark.  For those 
that want the 20%, let's please solve the problem in Discovery, and resist 
duplicating the solution in many Jakarta components.




simon <[EMAIL PROTECTED]> wrote on 12/09/2004 05:18:37 PM:

> On Fri, 2004-12-10 at 11:52, Martin Cooper wrote:
> > This sure doesn't sound like Commons Logging would be "an ultra-thin
> > bridge between different logging libraries" any more.
> > 
> > http://jakarta.apache.org/commons/logging/
> > 
> > This sounds more like a different package altogether. IMO, we have
> > enough trouble as it is with some people resisting adding a dependency
> > on Commons Logging that the last thing I want to see is a bunch more
> > functionality - and size - added to this component.
> 
> It looks to me like the changes will be just a couple of fairly simple
> new classes for globalisation, and a couple of trivial methods to
> support the JSR-47 "finer" log level. I don't think that's a big deal.
> 
> The "repackaging" of the logging library to separate the "interfaces"
> from the log-library-specific adapters is something that has already
> been proposed on this list, and clearly will *reduce* jar file size
> (though add complexity by forcing users to deploy two jars instead of
> one).
> 
> It is less clear how the proposed changes to the 'discovery' process
> would affect code size/complexity, and I agree a close eye needs to be
> kept on this to make sure commons-logging stays the "thin bridge" it was
> always meant to be.
> 
> Regards,
> 
> Simon
> 

***
Richard A. Sitze
IBM WebSphere WebServices Development


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

RE: [logging] Enterprise Common Logging... dare we say 2.0?

[Charles Daniels]

> -Original Message-
> From: simon [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, December 09, 2004 4:19 PM
> To: Jakarta Commons Developers List
> Subject: Re: [logging] Enterprise Common Logging... dare we say 2.0?
> 
> On Fri, 2004-12-10 at 11:52, Martin Cooper wrote:
> > This sure doesn't sound like Commons Logging would be "an ultra-thin
> > bridge between different logging libraries" any more.
> > 
> > http://jakarta.apache.org/commons/logging/
> > 
> > This sounds more like a different package altogether. IMO, we have
> > enough trouble as it is with some people resisting adding a 
> dependency
> > on Commons Logging that the last thing I want to see is a bunch more
> > functionality - and size - added to this component.
> 
> It looks to me like the changes will be just a couple of fairly simple
> new classes for globalisation, and a couple of trivial methods to
> support the JSR-47 "finer" log level. I don't think that's a big deal.
> 
> The "repackaging" of the logging library to separate the "interfaces"
> from the log-library-specific adapters is something that has already
> been proposed on this list, and clearly will *reduce* jar file size
> (though add complexity by forcing users to deploy two jars instead of
> one).
> 
> It is less clear how the proposed changes to the 'discovery' process
> would affect code size/complexity, and I agree a close eye needs to be
> kept on this to make sure commons-logging stays the "thin 
> bridge" it was
> always meant to be.

Further, the JCL User Guide has a section labeled "National Language
Support And Internationalization", in which the following excerpt
appears:

"NLS internationalization SHOULD be strongly considered for used for
fatal, error, warn, and info messages. It is generally considered
optional for debug and trace messages. 

Perhaps more direct support for internationalizing log messages can be
introduced in a future or alternate version of the Log interface."

So it seems to me that the suggestion from IBM is not necessarily making
the "thin bridge" any fatter.  Rather, it is simply following up on what
is already suggested in the User Guide.

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


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

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[Richard Sitze]

Good point.  Which is why we elected to begin our proposal as an extension 
to the existing Log interface, rather than making any immediate 
adaptations to it.  Any component based on the the existing interface [JCL 
1.0.X] will be able to execute with JCL 2.  Likewise, component developers 
make choose to remain in their corner of the world.

For users using Log implementations, or the Log interface methods on an 
EnterpriseLog implementation, the runtime overhead wouldn't be any 
different than it is today.

For those components that are ready to step out to a broader audience, and 
are looking for the desired level of function [and there IS a need, these 
requirements aren't just hot air], there is the additional methods.  As a 
real example, the axis community uses globalized messages.  They translate 
in-place prior to every log invocation that they want globalized... and it 
gets VERY old having to implement something like:

 log.error(Message.getMessage("MSGID", new String { arg1, ..., argN 
}));

Never mind that every component that needs to globalize needs to come up 
with something on their own that is equivalent to Message.  Yes, the 
proposal takes this a few steps further, but it's an improvement:

 log.error(ThisClass.getName(), "thisMethodName", "MSGID", new String 
{arg1, ..., argN } );


Size... is that really an issue?

Perhaps so.  And this IS the time to reconsider alternate packaging.  I 
don't want Log4J and Avalan and I-don't-know-what enabled simply because 
they're all packaged with commons-logging.jar.  And the impls happen to be 
on a classpath.  As a component developer, the packaging should NOT 
matter.  As an application developer, I want to use commons-logging in MY 
environment, and don't need the overhead of all the other logger impls 
laying around [size or runtime discover tricks].  Most importantly, I want 
to *know* which logger implementation I'm going to be using.

One proposal is that we build N number of utility commons jar files, one 
for each logger implementation we support:

 commons-logging-log4j.jar
 commons-logging-avalon.jar
 commons-logging-jsr47.jar

etc.  The standard LogFactory/Log & EnterpriseLogFactory/EnterpriseLog 
interface/classes would be packaged with each.  A generic

commons-logging-core.jar

would contain ONLY the core classes, and would be reasonably useful in 
those environments where the application developer [infrastructure owner] 
would be providing their own implementation.  And.. I suppose for those 
who really WANT it all... they can still have the old commons-logging.jar 
file.


Martin Cooper <[EMAIL PROTECTED]> wrote on 12/09/2004 04:52:15 PM:

> This sure doesn't sound like Commons Logging would be "an ultra-thin
> bridge between different logging libraries" any more.
> 
> http://jakarta.apache.org/commons/logging/
> 
> This sounds more like a different package altogether. IMO, we have
> enough trouble as it is with some people resisting adding a dependency
> on Commons Logging that the last thing I want to see is a bunch more
> functionality - and size - added to this component.
> 
> --
> Martin Cooper



> >B.2.  Fix fragile configuration problems.
> > 
> >  This area is more discussion, and less is
> >  currently represented in any proposed
> >  interface/class changes.
> > 
> >  Two things can/should be done here:
> > 
> >  a. tighten the 'discovery' process to minimize
> > "non-deterministic behavior".
> > 
> >  b. give *serious* consideration to how we
> > package commons logging.
> > 
> >- Declarative Configuration:
> > 
> >  Now, regarding 'fragile' configurations, a
> >  declarative configuration driven programmatically
> >  by the "target framework" into which a component
> >  might be installed/executing within would resolve
> >  a lot of the problems.
> > 
> >  In such a solution, we should guard against
> >  any multiplicity of such "declarations".  Throw
> >  exception, something, to if multiple occur in the
> >  runtime.
> > 
> >- ONE Configuration
> > 
> >  Even in a dynamic "discovery" process, we
> >  should adopt a strategy of allowing only ONE
> >  configuration to exist.
> > 
> >  - In absense of an explicit declaration, if there
> >is only one logger available, use it.
> > 
> >  - In absense of an explicit declaration, if there
> >are multiple loadable loggers available,
> >then configurable preference list could be
> >consulted.  Such a list MUST NOT be packaged with
> >the commons logging distributable.
> > 
> >  - In presense of an explicit declaration, if that
> >is NOT available, then fall back to a default
> >logger (preference list or simple logger) AND
> >log warning/info.
> >

DO NOT REPLY [Bug 32619] New: - Minor tweak to fix of bug # 26616

[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://issues.apache.org/bugzilla/show_bug.cgi?id=32619

   Summary: Minor tweak to fix of bug # 26616
   Product: Commons
   Version: Nightly Builds
  Platform: PC
OS/Version: Windows 2000
Status: NEW
  Severity: trivial
  Priority: P5
 Component: Lang
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Looking at the code, the comments in Enum.build still seem to assume that the
parameter will always be an enumeration.  The code, however, is correct (at
least for the enums version -- the other version looks correct with a worse
performance)

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[simon]

On Fri, 2004-12-10 at 11:52, Martin Cooper wrote:
> This sure doesn't sound like Commons Logging would be "an ultra-thin
> bridge between different logging libraries" any more.
> 
> http://jakarta.apache.org/commons/logging/
> 
> This sounds more like a different package altogether. IMO, we have
> enough trouble as it is with some people resisting adding a dependency
> on Commons Logging that the last thing I want to see is a bunch more
> functionality - and size - added to this component.

It looks to me like the changes will be just a couple of fairly simple
new classes for globalisation, and a couple of trivial methods to
support the JSR-47 "finer" log level. I don't think that's a big deal.

The "repackaging" of the logging library to separate the "interfaces"
from the log-library-specific adapters is something that has already
been proposed on this list, and clearly will *reduce* jar file size
(though add complexity by forcing users to deploy two jars instead of
one).

It is less clear how the proposed changes to the 'discovery' process
would affect code size/complexity, and I agree a close eye needs to be
kept on this to make sure commons-logging stays the "thin bridge" it was
always meant to be.

Regards,

Simon


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

DO NOT REPLY [Bug 32618] - [logging] Enterprise Commons Logging : Globalization & more

[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://issues.apache.org/bugzilla/show_bug.cgi?id=32618


[EMAIL PROTECTED] changed:

   What|Removed |Added

 OS/Version|Windows XP  |All
   Platform|PC  |All




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[Martin Cooper]

This sure doesn't sound like Commons Logging would be "an ultra-thin
bridge between different logging libraries" any more.

http://jakarta.apache.org/commons/logging/

This sounds more like a different package altogether. IMO, we have
enough trouble as it is with some people resisting adding a dependency
on Commons Logging that the last thing I want to see is a bunch more
functionality - and size - added to this component.

--
Martin Cooper


On Thu, 9 Dec 2004 13:21:24 -0700, Richard Sitze <[EMAIL PROTECTED]> wrote:
> IBM would like to open a discussion within the Jakarta commons community
> on evolving the Jakarta Commons Logging (JCL) API's to support Enterprise
> level logging functionality.  We recognize the value that a "logging
> implementation independent API" brings to open source component
> development, and would like to work with the community to accomplish this
> goal.
> 
> We present a set of requirements as a baseline for the discussion, a
> proposal for meeting these requirements, a number of points of discussion,
> and attached are two Java source files that correspond to the discussion
> below.
> 
> Requirements:
> 
>  We recognize that the community has an overriding
>  requirement:
> 
>A.1.  Evolution: maintain compatibility with the
>  current LogFactory/Log interfaces.
> 
>  We have ONE primary requirement:
> 
>A.2.  Globalization
> 
>  Having opened the door, we'd also like to propose a few
>  other requirements:
> 
>B.1.  Functional alignment with JSR-47 concepts.
> 
>B.2.  Fix fragile configuration problems - Currently
>  the user has NO idea which impl is in effect.
>  All the default/fall back behavior means that in
>  the end we have an apparent non-deterministic
>  logging implementation.  Errors in config file
>  names, classpath errors, classpath ordering,
>  etc., can all change the behavior... with no
>  idea which is in effect.
> 
>  The fundamental problem with the current factory
>  is that it is dependent on "passively"
>  identifying a logging implementation.
> 
>  We propose one solution below, but would ask a
>  more general question: any new bright ideas?
> 
> Proposals:
> 
>A.1.  Evolution: Maintain compatibility with the
>  current LogFactory/Log interfaces BY PROVIDING
> 
>  - Drop-in replacement of commons-logging.jar
>version 1.x with a version 2.x variant.
> 
>  - EnterpriseLogFactory class that extends the
>existing LogFactory.
> 
>  - EnterpriseLog interface that extends the
>existing Log interface.
> 
>A.2.  Globalization.  For the enterprise logging we
>  need globalized messages (translated) for message
>  level logging API's: info, warn, error, fatal.
>  The remaining logging API's are considered trace
>  level logging API's, and do not require message
>  translation.
> 
>  - For message level logging, support globalized
>variants on the new EnterpriseLog interface:
> 
>info(Class callingClass,
> String methodName,
> String messageID);
> 
>info(Class callingClass,
> String methodName,
> String messageID,
> Object messageParam);
> 
>info(Class callingClass,
> String methodName,
> String messageID,
> Object[] messageParams);
> 
>same for warn, error, fatal.
> 
>  - Utility function to support formatting for
>other purposes (exception strings):
> 
>formatMessage(String messageID);
>formatMessage(String messageID, Object messageParam);
>formatMessage(String messageID, Object[] messageParams);
> 
>  Ensure that component has an assurance that the
>  message will be translated/formatted as expected:
> 
>  - ALL message translation must be done using
>the standard java.util.ResourceBundle class,
>or functional equivalent.
> 
>  - ALL message formatting must be done using
>the standard java.text.MessageFormat class,
>or functional equivalent.
> 
>  - Bind a ResourceBundleName to an EnterpriseLog
>instance.
> 
>  - Expects that the named ResourceBundle is
>available to the logger.
> 
>B.1.  Functional alignment with JSR-47 concepts.
>  JSR-47 has 3 trace levels:  FINE, FINER, FINEST
>  JCL has 2 trace levels defined today: debug,
>  trace which corresponds to JSR-47 FINE and
>  FINEST in the current implementation.
> 
>  The JSR-47 FINER level has no corresponding APIs
>  in JCL.  The expectation is that the FINER level
>  be used for "class/method level flow".
> 
>  We propose a set of API's that wo

DO NOT REPLY [Bug 32618] - [logging] Enterprise Commons Logging : Globalization & more

[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://issues.apache.org/bugzilla/show_bug.cgi?id=32618


[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|Enterprise Commons Logging :|[logging] Enterprise Commons
   |Globalization & more|Logging : Globalization &
   ||more




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

Re: AW: [logging] Enterprise Common Logging... dare we say 2.0?

[Richard Sitze]

I'm very interested in any insight into how to leverage the existing i18n 
project... that said, I have no interest in mandating use of i18n. Commons 
logging is lightweight, needs to remain as lightweight as possible.

For i18n, my perspective is that Jakarta Commons Logging (JCL) must adhere 
to the most simple/standard mechanisms supported by Java.  If your 
application uses i18n on a GUI, then perhaps Jakarta i18n is reasonable 
for that use... but I'm not sure it's appropriate for the behind the 
scenes work that logging represents.




[EMAIL PROTECTED] wrote on 12/09/2004 03:46:26 PM:

> Have you had a look at the commons-sandbox i18n project? This might be a
> solution to enable localized logging with fine grained messages.
> Methods would look like this:
> LogMessage logMessage = new LogMessage("someMessakeKey", new String[] {
> "param1", "param2" }

In particular, I don't like having to new up an object here.  What have I 
gained?  Please remember that for logging implementations that support 
i18n, the expectation is that we pass the key & params straight through.


> EnterpriseLogger.info(String messageName, LogMessage logMessage);
> Log message class could have similar attributes as the ErrorMessage 
class.
> Regards,
> Daniel
> 
> > -Ursprüngliche Nachricht-
> > Von: [EMAIL PROTECTED]
> > 
[mailto:[EMAIL PROTECTED]
> > Im Auftrag von Richard Sitze
> > Gesendet: Donnerstag, 9. Dezember 2004 21:21
> > An: [EMAIL PROTECTED]
> > Betreff: [logging] Enterprise Common Logging... dare we say 2.0?
> > 
> > IBM would like to open a discussion within the Jakarta commons 
community
> > on evolving the Jakarta Commons Logging (JCL) API's to support 
Enterprise
> > level logging functionality.  We recognize the value that a "logging
> > implementation independent API" brings to open source component
> > development, and would like to work with the community to accomplish 
this
> > goal.
> > 
> > We present a set of requirements as a baseline for the discussion, a
> > proposal for meeting these requirements, a number of points of 
discussion,
> > and attached are two Java source files that correspond to the 
discussion
> > below.
> > 
> > 
> > Requirements:
> > 
> >   We recognize that the community has an overriding
> >   requirement:
> > 
> > A.1.  Evolution: maintain compatibility with the
> >   current LogFactory/Log interfaces.
> > 
> >   We have ONE primary requirement:
> > 
> > A.2.  Globalization
> > 
> > 
> >   Having opened the door, we'd also like to propose a few
> >   other requirements:
> > 
> > B.1.  Functional alignment with JSR-47 concepts.
> > 
> > B.2.  Fix fragile configuration problems - Currently
> >   the user has NO idea which impl is in effect.
> >   All the default/fall back behavior means that in
> >   the end we have an apparent non-deterministic
> >   logging implementation.  Errors in config file
> >   names, classpath errors, classpath ordering,
> >   etc., can all change the behavior... with no
> >   idea which is in effect.
> > 
> >   The fundamental problem with the current factory
> >   is that it is dependent on "passively"
> >   identifying a logging implementation.
> > 
> >   We propose one solution below, but would ask a
> >   more general question: any new bright ideas?
> > 
> > 
> > 
> > Proposals:
> > 
> > A.1.  Evolution: Maintain compatibility with the
> >   current LogFactory/Log interfaces BY PROVIDING
> > 
> >   - Drop-in replacement of commons-logging.jar
> > version 1.x with a version 2.x variant.
> > 
> >   - EnterpriseLogFactory class that extends the
> > existing LogFactory.
> > 
> >   - EnterpriseLog interface that extends the
> > existing Log interface.
> > 
> > 
> > A.2.  Globalization.  For the enterprise logging we
> >   need globalized messages (translated) for message
> >   level logging API's: info, warn, error, fatal.
> >   The remaining logging API's are considered trace
> >   level logging API's, and do not require message
> >   translation.
> > 
> >   - For message level logging, support globalized
> > variants on the new EnterpriseLog interface:
> > 
> > info(Class callingClass,
> >  String methodName,
> >  String messageID);
> > 
> > info(Class callingClass,
> >  String methodName,
> >  String messageID,
> >  Object messageParam);
> > 
> > info(Class callingClass,
> >  String methodName,
> >  String messageID,
> >  Object[] messageParams);
> > 
> > same for warn, error, fatal.
> > 
> > 
> >   - Utility function to support formatting for
> > other purposes (exception strings):
> > 
> >   

DO NOT REPLY [Bug 32618] - Enterprise Commons Logging : Globalization & more

[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://issues.apache.org/bugzilla/show_bug.cgi?id=32618





--- Additional Comments From [EMAIL PROTECTED]  2004-12-09 23:50 ---
B.2.  Fix fragile configuration problems.

  This area is more discussion, and less is
  currently represented in any proposed
  interface/class changes.

  Two things can/should be done here:

  a. tighten the 'discovery' process to minimize
 "non-deterministic behavior".

  b. give *serious* consideration to how we
 package commons logging.


- Declarative Configuration:
 
  Now, regarding 'fragile' configurations, a
  declarative configuration driven programmatically
  by the "target framework" into which a component
  might be installed/executing within would resolve
  a lot of the problems.

  In such a solution, we should guard against
  any multiplicity of such "declarations".  Throw
  exception, something, to if multiple occur in the
  runtime.


- ONE Configuration

  Even in a dynamic "discovery" process, we
  should adopt a strategy of allowing only ONE
  configuration to exist.

  - In absense of an explicit declaration, if there
is only one logger available, use it.

  - In absense of an explicit declaration, if there
are multiple loadable loggers available,
then configurable preference list could be
consulted.  Such a list MUST NOT be packaged with
the commons logging distributable.

  - In presense of an explicit declaration, if that
is NOT available, then fall back to a default
logger (preference list or simple logger) AND
log warning/info.

  - NO configuration of explicit/default loggers in
ANY resource packaged with the logger.


- Detailed diagnostics

  Detailed Internal analysis and dump on
  error/warning. Explain what has failed, why,
  and what should be done about it.  References
  to a user guide would be acceptable I think.

  If there is ANY ambiguity, then WARN or INFO at
  a minimum.


- Improve relationship with ClassLoader hierarchies

  The parent-first class loader mechanism causes
  problems with in some situations.  Specifically,
  J2EE environments where applications attempt to
  use commons logging, AND where the runtime also
  supports it.

  The apparent solution is both a more
  deterministic discovery process for
  *configuration* data, and a more flexible
  config model.

  More deterministic ClassLoader behavior with
  respect to configuration files:

  - Force adherence to the parent-first ClassLoader
precedence even if the ClassLoaders attempt
to circumvent [force deterministic behavior].

- Walk ClassLoader hierarchy from top to
  bottom, discover and track WHERE resources
  [config files] are available.

  - Always defer to configuration found in lowest
[closest to app] classloader.

  - Look for multiple copies of config resource
loaded by any *one* classloader, throw a
configuration exception or warning w/ fall-back
to consistent default behavior in such an event
OR warn and fall-back to behavior configured by
PARENT classloader.

  - NO configuration file to be packed with
commons-logging.jar


  Flexible config model:

  - Allow PARENT config to define a *default*
attribute [such as logger] which applies to
current classloader, and as a default to any
child loader.  These attributes are always
considered in order of PARENT LAST.

  - Allow PARENT config to define a *must-use*
attribute [such as logger] which forces
behavior of child loaders.  These attributes
are always considered in order of PARENT FIRST,
and override a corresponding *default*
attribute.

  - The distinction between *default* and
*must-use* to be made by different attribute
names.


- Repackaging

  Separate Interface from Implementations.  Yes,
  this means TWO jar files (default).  We
  might produce "utility" jar files that contain
  an interface with ONE implementation, and config
  for that implementation.  We MUST eliminate
  packagi

DO NOT REPLY [Bug 32618] - Enterprise Commons Logging : Globalization & more

[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://issues.apache.org/bugzilla/show_bug.cgi?id=32618





--- Additional Comments From [EMAIL PROTECTED]  2004-12-09 23:49 ---
B.1.  Functional alignment with JSR-47 concepts.
  JSR-47 has 3 trace levels:  FINE, FINER, FINEST
  JCL has 2 trace levels defined today: debug,
  trace which corresponds to JSR-47 FINE and
  FINEST in the current implementation.

  The JSR-47 FINER level has no corresponding APIs
  in JCL.  The expectation is that the FINER level
  be used for "class/method level flow".

  We propose a set of API's that would correspond
  to the JSR-47 FINER LEVEL, but more generally
  support the "class/method level flow" logging.

  - enter(Class clazz, String methodName,
  Object message);

  - enter(Class clazz, String methodName,
  Object methodArg,
  Object message)

  - enter(Class clazz, String methodName,
  Object[] methodArgs,
  Object message);

  - exit(Class clazz, String methodName,
 Object result,
 Object message);

  - exit(Class clazz, String methodName,
 Throwable exception,
 Object message);

  These being "new" API's, it is reasonable to have
  'Log' level behavior... updating Log or only
  supporting in EnterpriseLog might be an interesting
  discussion point.

  The JCL debug level is described (in the user's
  guide) as appropriate for "detailed information
  on the flow through the system."  As a best
  practice, would like to suggest that this be
  for "component level flow", i.e. crossing
  component boundries.  This being a guideline,
  we see no conflict with current usage.
  This is in-line with current JSR-47 expectations.
  This does raise a question: would a set of
  API's to support this notion be appropriate?
  Something along the order of:

  - enterComponent(String componentName,
   Class clazz,
   String methodName,
   ...);

  - etc.


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 32618] - Enterprise Commons Logging : Globalization & more

[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://issues.apache.org/bugzilla/show_bug.cgi?id=32618





--- Additional Comments From [EMAIL PROTECTED]  2004-12-09 23:49 ---
A.2.  Globalization.  For the enterprise logging we
  need globalized messages (translated) for message
  level logging API's: info, warn, error, fatal.
  The remaining logging API's are considered trace
  level logging API's, and do not require message
  translation.

  - For message level logging, support globalized
variants on the new EnterpriseLog interface:

info(Class callingClass,
 String methodName,
 String messageID);

info(Class callingClass,
 String methodName,
 String messageID,
 Object messageParam);

info(Class callingClass,
 String methodName,
 String messageID,
 Object[] messageParams);

same for warn, error, fatal.


  - Utility function to support formatting for
other purposes (exception strings):

formatMessage(String messageID);
formatMessage(String messageID, Object messageParam);
formatMessage(String messageID, Object[] messageParams);


  Ensure that component has an assurance that the
  message will be translated/formatted as expected:

  - ALL message translation must be done using
the standard java.util.ResourceBundle class,
or functional equivalent.

  - ALL message formatting must be done using
the standard java.text.MessageFormat class,
or functional equivalent.

  - Bind a ResourceBundleName to an EnterpriseLog
instance.

  - Expects that the named ResourceBundle is
available to the logger.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 32618] - Enterprise Commons Logging : Globalization & more

[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://issues.apache.org/bugzilla/show_bug.cgi?id=32618





--- Additional Comments From [EMAIL PROTECTED]  2004-12-09 23:47 ---
A.1.  Evolution: Maintain compatibility with the
  current LogFactory/Log interfaces BY PROVIDING

  - Drop-in replacement of commons-logging.jar
version 1.x with a version 2.x variant.

  - EnterpriseLogFactory class that extends the
existing LogFactory.

  - EnterpriseLog interface that extends the
existing Log interface.


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 32618] - Enterprise Commons Logging : Globalization & more

[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://issues.apache.org/bugzilla/show_bug.cgi?id=32618





--- Additional Comments From [EMAIL PROTECTED]  2004-12-09 23:46 ---
Created an attachment (id=13715)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=13715&action=view)
Initial proposed EnterpriseLogFactory.java


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 32618] - Enterprise Commons Logging : Globalization & more

[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://issues.apache.org/bugzilla/show_bug.cgi?id=32618





--- Additional Comments From [EMAIL PROTECTED]  2004-12-09 23:46 ---
Created an attachment (id=13714)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=13714&action=view)
Initial proposed EnterpriseLog.java


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 32618] New: - Enterprise Commons Logging : Globalization & more

[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://issues.apache.org/bugzilla/show_bug.cgi?id=32618

   Summary: Enterprise Commons Logging : Globalization & more
   Product: Commons
   Version: unspecified
  Platform: PC
OS/Version: Windows XP
Status: NEW
  Severity: enhancement
  Priority: P2
 Component: Logging
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


IBM would like to open a discussion within the Jakarta commons community 
on evolving the Jakarta Commons Logging (JCL) API's to support Enterprise 
level logging functionality.  We recognize the value that a "logging 
implementation independent API" brings to open source component 
development, and would like to work with the community to accomplish this 
goal.

We present a set of requirements as a baseline for the discussion, a 
proposal for meeting these requirements, a number of points of discussion, 
and attached are two Java source files that correspond to the discussion 
below.


Requirements:

  We recognize that the community has an overriding
  requirement:

A.1.  Evolution: maintain compatibility with the
  current LogFactory/Log interfaces.

  We have ONE primary requirement:

A.2.  Globalization


  Having opened the door, we'd also like to propose a few
  other requirements:

B.1.  Functional alignment with JSR-47 concepts.

B.2.  Fix fragile configuration problems - Currently
  the user has NO idea which impl is in effect.
  All the default/fall back behavior means that in
  the end we have an apparent non-deterministic
  logging implementation.  Errors in config file
  names, classpath errors, classpath ordering,
  etc., can all change the behavior... with no
  idea which is in effect.

  The fundamental problem with the current factory
  is that it is dependent on "passively"
  identifying a logging implementation.

  We propose one solution below, but would ask a
  more general question: any new bright ideas?

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 32614] - Change the properties HashMap of the RequestUtils.populate method to a LinkedHashMap

[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://issues.apache.org/bugzilla/show_bug.cgi?id=32614


[EMAIL PROTECTED] changed:

   What|Removed |Added

 AssignedTo|commons-|[EMAIL PROTECTED]
   |[EMAIL PROTECTED]  |




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 32614] - Change the properties HashMap of the RequestUtils.populate method to a LinkedHashMap

[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://issues.apache.org/bugzilla/show_bug.cgi?id=32614


[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|[beanutils] Change the  |Change the properties
   |properties HashMap of the   |HashMap of the
   |RequestUtils.populate method|RequestUtils.populate method
   |to a LinkedHashMap  |to a LinkedHashMap




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 32614] - [beanutils] Change the properties HashMap of the RequestUtils.populate method to a LinkedHashMap

[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://issues.apache.org/bugzilla/show_bug.cgi?id=32614


[EMAIL PROTECTED] changed:

   What|Removed |Added

  Component|Bean Utilities  |Unknown
Product|Commons |Struts
Version|4.0 |Unknown




--- Additional Comments From [EMAIL PROTECTED]  2004-12-09 23:10 ---
Err.. this is a Struts issue, right ? I'm reaffecting the bug.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 32614] - [beanutils] Change the properties HashMap of the RequestUtils.populate method to a LinkedHashMap

[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://issues.apache.org/bugzilla/show_bug.cgi?id=32614


[EMAIL PROTECTED] changed:

   What|Removed |Added

 OS/Version|Windows 2000|All
   Platform|PC  |All
Summary|Change the properties   |[beanutils] Change the
   |HashMap of the  |properties HashMap of the
   |RequestUtils.populate method|RequestUtils.populate method
   |to a LinkedHashMap  |to a LinkedHashMap




--- Additional Comments From [EMAIL PROTECTED]  2004-12-09 23:07 ---
LinkedHashMap is a JDK 1.4 class, I believe beanutils targets 1.3 compatibility
this may be an issue.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 32614] New: - Change the properties HashMap of the RequestUtils.populate method to a LinkedHashMap

[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://issues.apache.org/bugzilla/show_bug.cgi?id=32614

   Summary: Change the properties HashMap of the
RequestUtils.populate method to a LinkedHashMap
   Product: Commons
   Version: 4.0
  Platform: PC
OS/Version: Windows 2000
Status: NEW
  Severity: major
  Priority: P2
 Component: Bean Utilities
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


The populate method of org.apache.struts.util.RequestUtils with the following
signature

public static void populate(
Object bean,
String prefix,
String suffix, 
HttpServletRequest request)
throws ServletException {
..
}

uses a "properties" HashMap for storing request parameters passed in from an 
HTTP request.

Please change this to an java.util.LinkedHashMap so that the
order of the parameters (when posted through an HTML form) is retained. 
The "properties" map is eventually passed to the BeanUtils.populate(...) 
method. Since this method calls indexed setter/getter methods in the order of 
the entries in the map passed to it. It only makes sense to have this order
in line with whats submitted. 

Not doing so, is causing erratic behavior when dealing with indexed properties
in Struts.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

AW: [logging] Enterprise Common Logging... dare we say 2.0?

[Daniel Florey]

Have you had a look at the commons-sandbox i18n project? This might be a
solution to enable localized logging with fine grained messages.
Methods would look like this:
LogMessage logMessage = new LogMessage("someMessakeKey", new String[] {
"param1", "param2" }
EnterpriseLogger.info(String messageName, LogMessage logMessage);
Log message class could have similar attributes as the ErrorMessage class.
Regards,
Daniel

> -Ursprüngliche Nachricht-
> Von: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
> Im Auftrag von Richard Sitze
> Gesendet: Donnerstag, 9. Dezember 2004 21:21
> An: [EMAIL PROTECTED]
> Betreff: [logging] Enterprise Common Logging... dare we say 2.0?
> 
> IBM would like to open a discussion within the Jakarta commons community
> on evolving the Jakarta Commons Logging (JCL) API's to support Enterprise
> level logging functionality.  We recognize the value that a "logging
> implementation independent API" brings to open source component
> development, and would like to work with the community to accomplish this
> goal.
> 
> We present a set of requirements as a baseline for the discussion, a
> proposal for meeting these requirements, a number of points of discussion,
> and attached are two Java source files that correspond to the discussion
> below.
> 
> 
> Requirements:
> 
>   We recognize that the community has an overriding
>   requirement:
> 
> A.1.  Evolution: maintain compatibility with the
>   current LogFactory/Log interfaces.
> 
>   We have ONE primary requirement:
> 
> A.2.  Globalization
> 
> 
>   Having opened the door, we'd also like to propose a few
>   other requirements:
> 
> B.1.  Functional alignment with JSR-47 concepts.
> 
> B.2.  Fix fragile configuration problems - Currently
>   the user has NO idea which impl is in effect.
>   All the default/fall back behavior means that in
>   the end we have an apparent non-deterministic
>   logging implementation.  Errors in config file
>   names, classpath errors, classpath ordering,
>   etc., can all change the behavior... with no
>   idea which is in effect.
> 
>   The fundamental problem with the current factory
>   is that it is dependent on "passively"
>   identifying a logging implementation.
> 
>   We propose one solution below, but would ask a
>   more general question: any new bright ideas?
> 
> 
> 
> Proposals:
> 
> A.1.  Evolution: Maintain compatibility with the
>   current LogFactory/Log interfaces BY PROVIDING
> 
>   - Drop-in replacement of commons-logging.jar
> version 1.x with a version 2.x variant.
> 
>   - EnterpriseLogFactory class that extends the
> existing LogFactory.
> 
>   - EnterpriseLog interface that extends the
> existing Log interface.
> 
> 
> A.2.  Globalization.  For the enterprise logging we
>   need globalized messages (translated) for message
>   level logging API's: info, warn, error, fatal.
>   The remaining logging API's are considered trace
>   level logging API's, and do not require message
>   translation.
> 
>   - For message level logging, support globalized
> variants on the new EnterpriseLog interface:
> 
> info(Class callingClass,
>  String methodName,
>  String messageID);
> 
> info(Class callingClass,
>  String methodName,
>  String messageID,
>  Object messageParam);
> 
> info(Class callingClass,
>  String methodName,
>  String messageID,
>  Object[] messageParams);
> 
> same for warn, error, fatal.
> 
> 
>   - Utility function to support formatting for
> other purposes (exception strings):
> 
> formatMessage(String messageID);
> formatMessage(String messageID, Object messageParam);
> formatMessage(String messageID, Object[] messageParams);
> 
> 
>   Ensure that component has an assurance that the
>   message will be translated/formatted as expected:
> 
>   - ALL message translation must be done using
> the standard java.util.ResourceBundle class,
> or functional equivalent.
> 
>   - ALL message formatting must be done using
> the standard java.text.MessageFormat class,
> or functional equivalent.
> 
>   - Bind a ResourceBundleName to an EnterpriseLog
> instance.
> 
>   - Expects that the named ResourceBundle is
> available to the logger.
> 
> 
> B.1.  Functional alignment with JSR-47 concepts.
>   JSR-47 has 3 trace levels:  FINE, FINER, FINEST
>   JCL has 2 trace levels defined today: debug,
>   trace which corresponds to JSR-47 FINE and
>   FINES

RE: [logging] Enterprise Common Logging... dare we say 2.0?

[Noel J. Bergman]

Matt Sgarlata wrote:

> Richard Sitze wrote:

> >info(Class callingClass,
> > String methodName,
> > String messageID);

> I don't understand why the calling class and method name are included.

Probably because the overhead of getting them from the stack trace might be
a tad on the brutal side.

I suspect I know why you added the defaultMessage parameter, but I'd avoid
it in order to force programmers to start using message bundles.  Otherwise
they won't, which won't facilitate localization.

IBM's goal with their proposal is to support/require localization, introduce
improved consistency in behavior, and support additional emerging logging
requirements in the Java community.  Nothing says that there can't be better
ways to achieve their goals, which are certainly worth looking at, and we
should make sure to invite the Logging PMC to do so with us.

--- Noel


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

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[David Graham]

"Enterprise" is marketing speak for "expensive".  It has no technical
meaning so including that word in class names is rather confusing.  It
looks like the new functionality is related to i18n of messages so naming
the classes something like I18NLog or GlobalizedLog would be more
appropriate.

David

--- Richard Sitze <[EMAIL PROTECTED]> wrote:

> IBM would like to open a discussion within the Jakarta commons community
> 
> on evolving the Jakarta Commons Logging (JCL) API's to support
> Enterprise 
> level logging functionality.  We recognize the value that a "logging 
> implementation independent API" brings to open source component 
> development, and would like to work with the community to accomplish
> this 
> goal.
> 
> We present a set of requirements as a baseline for the discussion, a 
> proposal for meeting these requirements, a number of points of
> discussion, 
> and attached are two Java source files that correspond to the discussion
> 
> below.
> 
> 
> Requirements:
> 
>   We recognize that the community has an overriding
>   requirement:
> 
> A.1.  Evolution: maintain compatibility with the
>   current LogFactory/Log interfaces.
> 
>   We have ONE primary requirement:
> 
> A.2.  Globalization
> 
> 
>   Having opened the door, we'd also like to propose a few
>   other requirements:
> 
> B.1.  Functional alignment with JSR-47 concepts.
> 
> B.2.  Fix fragile configuration problems - Currently
>   the user has NO idea which impl is in effect.
>   All the default/fall back behavior means that in
>   the end we have an apparent non-deterministic
>   logging implementation.  Errors in config file
>   names, classpath errors, classpath ordering,
>   etc., can all change the behavior... with no
>   idea which is in effect.
> 
>   The fundamental problem with the current factory
>   is that it is dependent on "passively"
>   identifying a logging implementation.
> 
>   We propose one solution below, but would ask a
>   more general question: any new bright ideas?
> 
> 
> 
> Proposals:
> 
> A.1.  Evolution: Maintain compatibility with the
>   current LogFactory/Log interfaces BY PROVIDING
> 
>   - Drop-in replacement of commons-logging.jar
> version 1.x with a version 2.x variant.
> 
>   - EnterpriseLogFactory class that extends the
> existing LogFactory.
> 
>   - EnterpriseLog interface that extends the
> existing Log interface.
> 
> 
> A.2.  Globalization.  For the enterprise logging we
>   need globalized messages (translated) for message
>   level logging API's: info, warn, error, fatal.
>   The remaining logging API's are considered trace
>   level logging API's, and do not require message
>   translation.
> 
>   - For message level logging, support globalized
> variants on the new EnterpriseLog interface:
> 
> info(Class callingClass,
>  String methodName,
>  String messageID);
> 
> info(Class callingClass,
>  String methodName,
>  String messageID,
>  Object messageParam);
> 
> info(Class callingClass,
>  String methodName,
>  String messageID,
>  Object[] messageParams);
> 
> same for warn, error, fatal.
> 
> 
>   - Utility function to support formatting for
> other purposes (exception strings):
> 
> formatMessage(String messageID);
> formatMessage(String messageID, Object messageParam);
> formatMessage(String messageID, Object[] messageParams);
> 
> 
>   Ensure that component has an assurance that the
>   message will be translated/formatted as expected:
> 
>   - ALL message translation must be done using
> the standard java.util.ResourceBundle class,
> or functional equivalent.
> 
>   - ALL message formatting must be done using
> the standard java.text.MessageFormat class,
> or functional equivalent.
> 
>   - Bind a ResourceBundleName to an EnterpriseLog
> instance.
> 
>   - Expects that the named ResourceBundle is
> available to the logger.
> 
> 
> B.1.  Functional alignment with JSR-47 concepts.
>   JSR-47 has 3 trace levels:  FINE, FINER, FINEST
>   JCL has 2 trace levels defined today: debug,
>   trace which corresponds to JSR-47 FINE and
>   FINEST in the current implementation.
> 
>   The JSR-47 FINER level has no corresponding APIs
>   in JCL.  The expectation is that the FINER level
>   be used for "class/method level flow".
> 
>   We propose a set of API's that would correspond
>   to the JSR-47 FINER LEVEL, but

RE: [Vote] Moving commons-sql to db.apache.org (repost)

[Daniel Rall]

+1

On Wed, 2004-12-08 at 21:46 -0500, Tim O'Brien wrote:
> +1 for commons-sql to db.apache.org
> 
> And, I'd be +1 for moving commons-dbutils to db.apache.org 
> 
> > -Original Message-
> > From: Thomas Dudziak [mailto:[EMAIL PROTECTED] 
> > Sent: Wednesday, December 08, 2004 2:33 PM
> > To: [EMAIL PROTECTED]; Jakarta Project Management Committee 
> > List; [EMAIL PROTECTED]
> > Subject: [Vote] Moving commons-sql to db.apache.org (repost)
> > 
> > (This is a repost from a vote that I started earlier today, 
> > but where I did not include commons-dev. This omission has 
> > been pointed out to me, and I agree that including 
> > commons-dev is important, so I repost the vote hereby)
> > 
> > 
> > Hi all,
> > 
> > I'd like to start a cross-vote (Jakarta PMC and commons-dev, 
> > DB PMC) about moving the jakarta sandbox project commons-sql
> > (http://jakarta.apache.org/commons/sandbox/sql/) over to 
> > db.apache.org, for instance into the currently vacant 
> > db-commons space (http://db.apache.org/commons/).
> > 
> > The reasons why we want to move commons-sql, are twofold:
> > 
> > * The two active committers (Martin KalÃn and myself) are DB 
> > comitters, but not comitters to another Jakarta project. As a 
> > result we would rather not subscribe to 
> > commons-dev/commons-user because very few mails there deal 
> > with commons-sql (one or two per month). Also, db-commons 
> > already has all setup'd (mailing lists, CVS space etc.), not 
> > to mention that the exposure of the project would be much greater.
> > 
> > * No other Jakarta project that I'm aware of, uses 
> > commons-sql. In contrast, OJB will do so (beginning with the 
> > upcoming 1.1 version), and so it would be good to provide 
> > access to the commons-sql repository to the OJB comitters. 
> > The same might also be true for Torque as commons-sql's 
> > functionality overlaps in some parts with Torque 
> > functionality, which opens up an opportunity to combine this 
> > functionality into a base component which both OJB and Torque 
> > could use.
> > 
> > Please post your opinion until next wednesday, the 15th of 
> > december, and please reply to all recipients.
> > 
> > 
> > Votes cast so far:
> > 
> > +1 Brian McCallister
> > +1 Henri Yandell
> > (though with objections regarding moving it into db-commons,
> >  http://db.apache.org/commons)
> > +1 Henning Schmiedehausen
> > 
> > 
> > regards,
> > Thomas Dudziak
> > 
> > 
> > PS: I'm not sure if this is the correct procedure, but I 
> > thought a vote 
> > is at least a good way to get the ball rolling, so to speak. 
> > If there is 
> > a defined way to handle movement of projects, then please let me know.
> > 
> > 


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

Re: [logging] Common Logging 2.0? EnterpriseLogFactory.java

[Niall Pemberton]

Better (IMO) to open an "enhancement" bugzilla ticket and attach the classes
to that - also you could layout your proposal there and it won't get "lost"
in the list.

Niall

- Original Message - 
From: "Richard Sitze" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, December 09, 2004 8:28 PM
Subject: [logging] Common Logging 2.0? EnterpriseLogFactory.java


> [Looks like the attachments got lost...  Let's try them separately]
>
>
> package org.apache.commons.logging;
>
>
> /**
>  * Factory for creating [EMAIL PROTECTED] Log} and [EMAIL PROTECTED] 
> EnterpriseLog}
> instances,
>  * with discovery and configuration features similar to that employed by
>  * standard Java APIs such as JAXP.
>  *
>  * Please note that a specific implementation of Commons Logging can
> choose
>  * to support either the simple logging interface defined by [EMAIL 
> PROTECTED] Log})
> or
>  * the advanced logging interface defined by [EMAIL PROTECTED] 
> EnterpriseLog}.  A
> user
>  * of a Common Logging implementation that supports only the simple
> logging
>  * interface will not be able to instantiate a EnterpriseLog.
>
>  * Conversely, a user of a Common Logging implementation that supports the
>
>  * advanced logging interface will be able to instantiate either a
> Log
>  * or EnterpriseLog.
>  *
>  */
> public abstract class EnterpriseLogFactory extends LogFactory{
>
>
> // - Manifest
> Constants
>
> // --- 
> Constructors
>
>
> /**
>  * Protected constructor that is not available for public use.
>  */
> protected EnterpriseLogFactory()
> {
> // TBD
> }
>
>
> // - Public
> Methods
>
> /**
>  * Construct (if necessary) and return a EnterpriseLog
> instance,
>  * using the factory's current set of configuration attributes.
>  *
>  * NOTE - Depending upon the implementation of
>  * the EnterpriseLogFactory you are using, the
>  * EnterpriseLog instance you are returned may or may
>  * not be local to the current application, and may or may not be
>  *returned again on a subsequent call with the same name argument.
>  *
>  * @param name Logical name of the EnterpriseLog instance
> to be
>  *  returned (the meaning of this name is only known to the underlying
>  *  logging implementation that is being wrapped)
>  *
>  * @param resourceBundleName Logical name of the repository to use
> when
>  *  retrieving internationalized message text (the meaning of this
> name is
>  *  only known to the underlying logging implementation that is being
> wrapped,
>  *  but a common usage would be the name of a Java resources bundle)
>  *
>  * @exception LogConfigurationException if a suitable Log
>  *  instance cannot be returned
>  */
> public abstract EnterpriseLog getEnterpriseInstance(String name,
>  String resourceBundleName) throws LogConfigurationException;
>
>
> // - Static
> Methods
>
>
> /**
>  * Construct (if necessary) and return a
> EnterpriseLogFactory
>  * instance, using the following ordered lookup procedure to determine
>  * the name of the implementation class to be loaded.
>  * 
>  * The org.apache.commons.logging.LogFactory system
>  * property.
>  * The JDK 1.3 Service Discovery mechanism
>  * Use the properties file commons-logging.properties
>  * file, if found in the class path of this class.  The
> configuration
>  * file is in standard java.util.Properties format
> and
>  * contains the fully qualified name of the implementation class
>  * with the key being the system property defined above.
>  * Fall back to a default implementation class
>  *
>
(org.apache.commons.logging.impl.EnterpriseLogFactoryImpl).
>  * 
>  *
>  * NOTE - If the properties file method of identifying the
>  * EnterpriseLogFactory implementation class is utilized,
> all of the
>  * properties defined in this file will be set as configuration
> attributes
>  * on the corresponding EnterpriseLogFactory
> instance.
>  *
>  * @exception LogConfigurationException if the implementation class is
> not
>  *  available or cannot be instantiated.
>  */
> public static EnterpriseLogFactory getEnterpriseFactory()
>   throws LogConfigurationException
> {
> // TBD
> }
>
>
> /**
>  * Convenience method to return a named enterprise logger, without the
>
>  * application having to care about factories.
>  *
>  * @param name Logical name of the EnterpriseLog instance
> to be
>  *  returned (the meaning of this name is only known to the underlying
>  *  logging implementation that is being wrapped)
>  *
>   

[Jakarta Commons Wiki] Updated: FrontPage

[commons-dev]

   Date: 2004-12-09T12:57:40
   Editor: MatthewSgarlata <[EMAIL PROTECTED]>
   Wiki: Jakarta Commons Wiki
   Page: FrontPage
   URL: http://wiki.apache.org/jakarta-commons/FrontPage

   no comment

Change Log:

--
@@ -48,7 +48,7 @@
 == Third Party Resources  ==
 
  * [JakartaCommonsResources]
- * [http://morph.sourceforge.net Morph] - pre-alpha framework based on ideas 
from BeanUtils, CommonsConvert and CommonsChain
+ * [http://morph.sourceforge.net Morph] - alpha framework based on ideas from 
BeanUtils ([http://morph.sourceforge.net/alternatives/beanutils.html read 
comparison to Morph]), CommonsConvert and CommonsChain.  Also will support 
functionality in [:JEXL] ([http://morph.sourceforge.net/alternatives/jexl.html 
read comparison to Morph]).
 
 == Developer Documentation ==
 

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

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[matthew.hawthorne]

I think it may be better to post the requirements and code on the wiki 
(so they don't get lost in the shuffle), and then let the discussion 
commence here.

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

Re: [logging] Enterprise Common Logging... dare we say 2.0?

[Matt Sgarlata]

Richard Sitze wrote:
 - For message level logging, support globalized
   variants on the new EnterpriseLog interface:
   info(Class callingClass,
String methodName,
String messageID);
   info(Class callingClass,
String methodName,
String messageID,
Object messageParam);
   info(Class callingClass,
String methodName,
String messageID,
Object[] messageParams);
   same for warn, error, fatal.
 

I don't understand why the calling class and method name are included.  
Can't this information simply be retrieved from the current stack trace 
by the underlying logging implementation?  I would think a cleaner 
approach would be one of the alternatives below (note we have to avoid 
conflicting with the existing info, warn, error, etc. methods)

info(String defaultMessage, String messageKey);
info(String defaultMessage, String messageKey, Object param);
info(String defaultMessage, String messageKey, Object[] params);
or
i18nInfo(String messageKey);
i18nInfo(String messageKey, Object param);
i18nInfo(String defaultMessage, String messageKey, Object[] params);
Also, I don't want to type
private static final EnterpriseLog log = 
EnterpriseLogFactory.getClass(MyVeryLongClassName.class);

I would think this new functionality could be added directly to the 
existing Log and LogFactory classes.

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

[logging] Common Logging 2.0? EnterpriseLog.java

[Richard Sitze]

package org.apache.commons.logging;

/**
 * An advanced logging interface abstracting logging APIs.  This 
interface
 * extends the simple logging interface decribed by [EMAIL PROTECTED] Log}, 
providing
 * the following additional capabilities:
 * 
 * the ability to capture internationalized data (e.g. translated 
messages)
 * ability to identify the software capturing the event 
 * (i.e. class and method name)
 * ability to capture the execution of a program by tracing method 
entry
 * and exit.
 * 
 * This interface is instantiated using [EMAIL PROTECTED] 
EnterpriseLogFactory}. 
The
 * classes that implement this interface must have a constructor that 
takes 
 * a single String parameter representing the "name" of this 
 * EnterpriseLog.  Please note that a specific implementation 
of
 * Commons Logging can choose to support either the simple logging 
interface
 * (represented by [EMAIL PROTECTED] Log}) or the advanced logging interface 
(represented 
 * by this interface).  A user of a Common Logging implementation that 
supports
 * only the simple logging interface will not be able to instantiate a 
 * EnterpriseLog.  Conversely, a user of a Common Logging 
 * implementation that supports the advanced logging interface will be 
able to 
 * instantiate either a Log or EnterpriseLog.
 *
 * Configuration of the underlying logging system will generally be 
done
 * external to the Logging APIs, through whatever mechanism is supported 
by
 * that system.
 *
 */

public interface EnterpriseLog extends Log 
{
// - Logging 
Properties


// - Logging 
Methods

/**
 *  Log a locale-specific (internationalized) error message with 
 * no message substitution values. 
 *
 * @param clazz   The class containing the method
 * @param method  The name of the method logging the message
 * @param key The key used to retrieve the message text 
 *(e.g. from a Java ResourceBundle (@link 
ResourceBundle)
 */

public void error(Class  clazz,
  String method,
  String key);

   /**
 *  Log a locale-specific (internationalized) error message with 
 * one message substitution value. 
 *
 * @param clazz   The class containing the method
 * @param method  The name of the method logging the message
 * @param key The key used to retrieve the message text 
 *(e.g. from a Java ResourceBundle (@link 
ResourceBundle))
 * @param parmThe value to insert into the message text 
 *(e.g. when formatting a Java massage (@link 
MessageFormat))
 */

public void error(Class  clazz,
  String method,
  String key,
  Object parm);

   /**
 *  Log a locale-specific (internationalized) error message with 
 * multiple message substitution values. 
 *
 * @param clazz   The class containing the method
 * @param method  The name of the method logging the message
 * @param key The key used to retrieve the message text 
 *(e.g. from a Java ResourceBundle (@link 
ResourceBundle))
 * @param parms   The list of values to insert into the message text 
 *(e.g. when formatting a Java massage (@link 
MessageFormat))
 */

public void error(Classclazz,
  String   method,
  String   key,
  Object[] parms);


/**
 *  Log a locale-specific (internationalized) fatal error message 
with 
 * no message substitution values. 
 *
 * @param clazz   The class containing the method
 * @param method  The name of the method logging the message
 * @param key The key used to retrieve the message text 
 *(e.g. from a Java ResourceBundle (@link 
ResourceBundle)
 */

public void fatal(Class  clazz,
  String method,
  String key);

   /**
 *  Log a locale-specific (internationalized) fatal error message 
with 
 * one message substitution value. 
 *
 * @param clazz   The class containing the method
 * @param method  The name of the method logging the message
 * @param key The key used to retrieve the message text 
 *(e.g. from a Java ResourceBundle (@link 
ResourceBundle))
 * @param parmThe value to insert into the message text 
 *(e.g. when formatting a Java massage (@link 
MessageFormat))
 */

public void fatal(Class  clazz,
  String method,
  String key,
  Object parm);

   /**
 *  Log a locale-specific (internationalized) fatal error message 
with 
 * multiple message substitution values. 
 *
 * @param clazz   The class containing the me

[logging] Common Logging 2.0? EnterpriseLogFactory.java

[Richard Sitze]

[Looks like the attachments got lost...  Let's try them separately]


package org.apache.commons.logging;


/**
 * Factory for creating [EMAIL PROTECTED] Log} and [EMAIL PROTECTED] 
EnterpriseLog} 
instances, 
 * with discovery and configuration features similar to that employed by 
 * standard Java APIs such as JAXP.
 *
 * Please note that a specific implementation of Commons Logging can 
choose 
 * to support either the simple logging interface defined by [EMAIL PROTECTED] 
Log}) 
or 
 * the advanced logging interface defined by [EMAIL PROTECTED] EnterpriseLog}.  
A 
user 
 * of a Common Logging implementation that supports only the simple 
logging 
 * interface will not be able to instantiate a EnterpriseLog. 
 
 * Conversely, a user of a Common Logging implementation that supports the 

 * advanced logging interface will be able to instantiate either a 
Log
 * or EnterpriseLog.
 *
 */
public abstract class EnterpriseLogFactory extends LogFactory{


// - Manifest 
Constants

// --- 
Constructors


/**
 * Protected constructor that is not available for public use.
 */
protected EnterpriseLogFactory()
{
// TBD
}


// - Public 
Methods

/**
 * Construct (if necessary) and return a EnterpriseLog 
instance,
 * using the factory's current set of configuration attributes.
 *
 * NOTE - Depending upon the implementation of
 * the EnterpriseLogFactory you are using, the 
 * EnterpriseLog instance you are returned may or may 
 * not be local to the current application, and may or may not be 
 *returned again on a subsequent call with the same name argument.
 *
 * @param name Logical name of the EnterpriseLog instance 
to be
 *  returned (the meaning of this name is only known to the underlying
 *  logging implementation that is being wrapped)
 * 
 * @param resourceBundleName Logical name of the repository to use 
when
 *  retrieving internationalized message text (the meaning of this 
name is 
 *  only known to the underlying logging implementation that is being 
wrapped,
 *  but a common usage would be the name of a Java resources bundle)
 *
 * @exception LogConfigurationException if a suitable Log
 *  instance cannot be returned
 */
public abstract EnterpriseLog getEnterpriseInstance(String name,
 String resourceBundleName) throws LogConfigurationException;


// - Static 
Methods


/**
 * Construct (if necessary) and return a 
EnterpriseLogFactory
 * instance, using the following ordered lookup procedure to determine
 * the name of the implementation class to be loaded.
 * 
 * The org.apache.commons.logging.LogFactory system
 * property.
 * The JDK 1.3 Service Discovery mechanism
 * Use the properties file commons-logging.properties
 * file, if found in the class path of this class.  The 
configuration
 * file is in standard java.util.Properties format 
and
 * contains the fully qualified name of the implementation class
 * with the key being the system property defined above.
 * Fall back to a default implementation class
 * 
(org.apache.commons.logging.impl.EnterpriseLogFactoryImpl).
 * 
 *
 * NOTE - If the properties file method of identifying the
 * EnterpriseLogFactory implementation class is utilized, 
all of the
 * properties defined in this file will be set as configuration 
attributes
 * on the corresponding EnterpriseLogFactory 
instance.
 *
 * @exception LogConfigurationException if the implementation class is 
not
 *  available or cannot be instantiated.
 */
public static EnterpriseLogFactory getEnterpriseFactory() 
  throws LogConfigurationException
{
// TBD
}


/**
 * Convenience method to return a named enterprise logger, without the 

 * application having to care about factories.
 *
 * @param name Logical name of the EnterpriseLog instance 
to be
 *  returned (the meaning of this name is only known to the underlying
 *  logging implementation that is being wrapped)
 * 
 * 
 * @param resourceBundleName Logical name of the repository to use 
when
 *  retrieving internationalized message text (the meaning of this 
name is 
 *  only known to the underlying logging implementation that is being 
wrapped,
 *  but a common usage would be the name of a Java resources bundle)
 *
 * @exception LogConfigurationException if a suitable Log
 *  instance cannot be returned
 */
public static EnterpriseLog getEnterpriseLog(String name, String 
resourceBundleName)
throws LogConfigurationException
{

return (getEnterpr

[logging] Enterprise Common Logging... dare we say 2.0?

[Richard Sitze]

IBM would like to open a discussion within the Jakarta commons community 
on evolving the Jakarta Commons Logging (JCL) API's to support Enterprise 
level logging functionality.  We recognize the value that a "logging 
implementation independent API" brings to open source component 
development, and would like to work with the community to accomplish this 
goal.

We present a set of requirements as a baseline for the discussion, a 
proposal for meeting these requirements, a number of points of discussion, 
and attached are two Java source files that correspond to the discussion 
below.


Requirements:

  We recognize that the community has an overriding
  requirement:

A.1.  Evolution: maintain compatibility with the
  current LogFactory/Log interfaces.

  We have ONE primary requirement:

A.2.  Globalization


  Having opened the door, we'd also like to propose a few
  other requirements:

B.1.  Functional alignment with JSR-47 concepts.

B.2.  Fix fragile configuration problems - Currently
  the user has NO idea which impl is in effect.
  All the default/fall back behavior means that in
  the end we have an apparent non-deterministic
  logging implementation.  Errors in config file
  names, classpath errors, classpath ordering,
  etc., can all change the behavior... with no
  idea which is in effect.

  The fundamental problem with the current factory
  is that it is dependent on "passively"
  identifying a logging implementation.

  We propose one solution below, but would ask a
  more general question: any new bright ideas?



Proposals:

A.1.  Evolution: Maintain compatibility with the
  current LogFactory/Log interfaces BY PROVIDING

  - Drop-in replacement of commons-logging.jar
version 1.x with a version 2.x variant.

  - EnterpriseLogFactory class that extends the
existing LogFactory.

  - EnterpriseLog interface that extends the
existing Log interface.


A.2.  Globalization.  For the enterprise logging we
  need globalized messages (translated) for message
  level logging API's: info, warn, error, fatal.
  The remaining logging API's are considered trace
  level logging API's, and do not require message
  translation.

  - For message level logging, support globalized
variants on the new EnterpriseLog interface:

info(Class callingClass,
 String methodName,
 String messageID);

info(Class callingClass,
 String methodName,
 String messageID,
 Object messageParam);

info(Class callingClass,
 String methodName,
 String messageID,
 Object[] messageParams);

same for warn, error, fatal.


  - Utility function to support formatting for
other purposes (exception strings):

formatMessage(String messageID);
formatMessage(String messageID, Object messageParam);
formatMessage(String messageID, Object[] messageParams);


  Ensure that component has an assurance that the
  message will be translated/formatted as expected:

  - ALL message translation must be done using
the standard java.util.ResourceBundle class,
or functional equivalent.

  - ALL message formatting must be done using
the standard java.text.MessageFormat class,
or functional equivalent.

  - Bind a ResourceBundleName to an EnterpriseLog
instance.

  - Expects that the named ResourceBundle is
available to the logger.


B.1.  Functional alignment with JSR-47 concepts.
  JSR-47 has 3 trace levels:  FINE, FINER, FINEST
  JCL has 2 trace levels defined today: debug,
  trace which corresponds to JSR-47 FINE and
  FINEST in the current implementation.

  The JSR-47 FINER level has no corresponding APIs
  in JCL.  The expectation is that the FINER level
  be used for "class/method level flow".

  We propose a set of API's that would correspond
  to the JSR-47 FINER LEVEL, but more generally
  support the "class/method level flow" logging.

  - enter(Class clazz, String methodName,
  Object message);

  - enter(Class clazz, String methodName,
  Object methodArg,
  Object message)

  - enter(Class clazz, String methodName,
  Object[] methodArgs,
  Object message);

  - exit(Class clazz, String methodName,
 Object result,
 Object message);

  - exit(Class clazz, String methodName,
 Throwable exception,
   

Re: [Vote] Moving commons-sql to db.apache.org (repost)

[robert burrell donkin]

On 9 Dec 2004, at 16:09, Oliver Zeigermann wrote:
I meant +1 to jakarta-commons going TLP
an opportunity arose about a year ago but there was no general 
enthusiasm. i was one of those who tried pretty hard to talk the 
community into this move but i think now i understand and agree with 
those who objected. in many ways, commons is the most jakarta of all 
the jakarta sub-projects. it is one positive vision for the future of 
jakarta: one single community - busy, vibrant, argumentation without 
artificial divisions.

many of the applications nurtured by jakarta have now outgrowing it's 
structures. i (and many others) hope to see them wish us a fond goodbye 
and start to make their own way in the world as fully graduated top 
level projects. the commons (though) fits well into the flat future.

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

Re: [Vote] Moving commons-sql to db.apache.org (repost)

[robert burrell donkin]

On 9 Dec 2004, at 17:52, Martin Cooper wrote:

commons-sql must IMHO focus better. Should it be just the "single set 
of
beans" as mentioned at the top page of the project? Or an all 
enclosing
"XML -> SQL and back" mapper? Then you definitely will touch the realm
of other "XML -> something" mappers. And there are already a lot of
these out there.

If you really insist on moving commons-sql to Apache DB in its current
state, then I would beg you to really think _more_ about the design of
your SQL generator than the parents of torque-gen did. torque-gen has
huge problems, trying to get stuff like "MySQL, version 4" and "MySQL,
version 3" done and struggles from a restrictive XML syntax (using the
short cuts for the ID generators was a _HUGE_ mistake).
PMFJI, but wouldn't moving Commons SQL to db@ provide the community 
with the right environment in which to learn all these things you're 
talking about, and thereby improve the component immensely?

Rather than require it to improve *before* a move, perhaps we should 
focus on how such a move would benefit the community *and* the 
component.
i think maybe martin has something here.
sql hasn't really thrived here in the commons (unlike some other 
database related components) and may benefit from a move. in some ways, 
i'm not really sure what moving sql means in practical terms since it's 
a sandbox component. i suspect that it might be better to talk about 
building a better sql as a db.apache.org sub-project taking the 
existing sql codebase as the bit of grit  around which the pearl will 
hopefully grow. (stafano used to describe this kind of thing much 
better but the basic essence is this: it's best to start a new project 
with a good community and flawed code.)

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

Re: [Vote] Moving commons-sql to db.apache.org (repost)

[Thomas Dudziak]

Henning Schmiedehausen wrote:
Yeah, but _what_ low-level db stuff?
commons-sql has already a lot of overlap with the torque-generator. And
torque-gen contains templates for
  - SQL generation (like commons-sql, but better (?) organized)
  - Torque Peer and Class Source generation
  - OJB Source generation 

In its current form, commons-sql is a step backwards from torque-gen,
because it _only_ does SQL code generation. It does it better than
torque-gen, no discussion here, but it does _only_ SQL code.
To elaborate this a bit further: The structure of a code generator like
commons-sql and torque-gen can (IMHO) be split into three parts:
- data model (currently just database/table/column. Where are other 
  parts of a database that are needed to model? Sequences? Views?)

- data output (set of templates that use the model to generate code)
  In commons-sql, there is only one set of templates around (in
  src/templates) and already there are function templates 
  (database-create, database-load, database-store) mixed up with
  control  or definition templates (db2, hsqldb and so on).

  How would one plug in another template set if the defaults do not
  suffice? How can I create custom templates and outputs? Can you split
  templates from the generator (e.g. load templates from class path or
  a give directory like torque-gen does)?
- A driver which controls the output generation. There is a rudimentary,
  Velocity only driver with Texen in the Velocity project
From these three parts, only the first two are really database centric
and only because they are hard coded into commons-sql. You could bundle
abstract representations of "data model" and "data output" together with
a generic driver and it would be a nice sub-project for Jakarta and then
bundle up a concrete implementation of the data model representing a
database with a set of templates for SQL and/or Source code generation
to become a part of DB. 

An example: One of the lessons _not_ learned from torque-gen is the db
type definition split into a textual representation (e.g. in
src/templates/oracle/9i/types.xml) and a code representation (e.g.
src/java/org/apache/commons/sql/builder/OracleBuilder.java). You will
either have to juggle two files to contain similar information or get
out of sync. (BTW: about the internal structures: Well, I'd prefer to
move StringBuffers around instead of the whole print()/println() shebang
but that is just a matter of taste).
You do need an unified representation. We learned this in torque the
hard way. One file (preferably an XML file) which contains all the
information and a loader for programmatic representation.
Building yet another torque-generator (which could easily be split out
of the Torque project, because it contains almost no torque-runtime
related code) with just another technology (Jelly) that is not even
liked by the people who use it heavily and started commons-sql (e.g. see
http://www.mail-archive.com/users@maven.apache.org/msg13893.html) is
IMHO a bird that will not fly very far.
commons-sql must IMHO focus better. Should it be just the "single set of
beans" as mentioned at the top page of the project? Or an all enclosing
"XML -> SQL and back" mapper? Then you definitely will touch the realm
of other "XML -> something" mappers. And there are already a lot of
these out there. 

If you really insist on moving commons-sql to Apache DB in its current
state, then I would beg you to really think _more_ about the design of
your SQL generator than the parents of torque-gen did. torque-gen has
huge problems, trying to get stuff like "MySQL, version 4" and "MySQL,
version 3" done and struggles from a restrictive XML syntax (using the
short cuts for the ID generators was a _HUGE_ mistake). 
I agree with a lot of your points, and disagree with a few others, 
however there are two things that made me start this vote now:

* In OJB, we only need SQL generation, and Torque is not exactly easy to 
use: the build script is complicated for a user (though it got better 
since 3.0), and Torque cannot be easily used at runtime, which is 
something that works really well in commons-sql. Also, AFAIK Torque 
cannot deal with existing databases (alter table).
However, having commons-sql in jakarta instead of db means more hassle 
for us. In db, all OJB (and Torque) committers could easily have commit 
rights to the moved commons-sql.

* Of course there is a lot of overlap with Torque, but a strategic 
discussion will take another half of a year or more before (if) anything 
gets done (and even more when putting commons-sql into incubation). I 
prefer the pragmatic approach and start working on commons-sql now, so 
it can be used by OJB and others.

That being said, I'd really like a merge of functionality with the 
corresponding Torque part, but that should not be a big-bang action, I 
think (and probably not a topic for this vote either). I'd like to 
discuss this off-topic though, if you want ?!

And in the end, you do want

Re: [Vote] Moving commons-sql to db.apache.org (repost)

[Martin Cooper]

On Thu, 9 Dec 2004, Henning Schmiedehausen wrote:
On Thu, 2004-12-09 at 17:38, Thomas Dudziak wrote:
Henning Schmiedehausen wrote:
+1 Henning Schmiedehausen

This is for the principal vote to get commons-sql into the DB project.
Personally, I'd like to see commons-sql through incubation to get the
scope of the project defined. See my other mail on the commons-dev list.

commons-sql must IMHO focus better. Should it be just the "single set of
beans" as mentioned at the top page of the project? Or an all enclosing
"XML -> SQL and back" mapper? Then you definitely will touch the realm
of other "XML -> something" mappers. And there are already a lot of
these out there.
If you really insist on moving commons-sql to Apache DB in its current
state, then I would beg you to really think _more_ about the design of
your SQL generator than the parents of torque-gen did. torque-gen has
huge problems, trying to get stuff like "MySQL, version 4" and "MySQL,
version 3" done and struggles from a restrictive XML syntax (using the
short cuts for the ID generators was a _HUGE_ mistake).
PMFJI, but wouldn't moving Commons SQL to db@ provide the community with 
the right environment in which to learn all these things you're talking 
about, and thereby improve the component immensely?

Rather than require it to improve *before* a move, perhaps we should focus 
on how such a move would benefit the community *and* the component.

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

Re: [Vote] Moving commons-sql to db.apache.org (repost)

[Henning Schmiedehausen]

On Thu, 2004-12-09 at 17:38, Thomas Dudziak wrote:
> Henning Schmiedehausen wrote:
> 
> >>+1 Henning Schmiedehausen
> >>
> >>
> >
> >This is for the principal vote to get commons-sql into the DB project.
> >Personally, I'd like to see commons-sql through incubation to get the
> >scope of the project defined. See my other mail on the commons-dev list.
> >  
> >
> I don't think that this would be a good idea, because I think its 
> purpose and place is clear (low-level db stuff like creating and 
> altering tables in a db-independent way). Of course the doc needs 
> rework, but this already an item on the to-do list.
> Btw, to what email do you refer (could you give a link to gmane/nagoya) ?

Yeah, but _what_ low-level db stuff?

commons-sql has already a lot of overlap with the torque-generator. And
torque-gen contains templates for
  - SQL generation (like commons-sql, but better (?) organized)
  - Torque Peer and Class Source generation
  - OJB Source generation 

In its current form, commons-sql is a step backwards from torque-gen,
because it _only_ does SQL code generation. It does it better than
torque-gen, no discussion here, but it does _only_ SQL code.

To elaborate this a bit further: The structure of a code generator like
commons-sql and torque-gen can (IMHO) be split into three parts:

- data model (currently just database/table/column. Where are other 
  parts of a database that are needed to model? Sequences? Views?)

- data output (set of templates that use the model to generate code)
  In commons-sql, there is only one set of templates around (in
  src/templates) and already there are function templates 
  (database-create, database-load, database-store) mixed up with
  control  or definition templates (db2, hsqldb and so on).

  How would one plug in another template set if the defaults do not
  suffice? How can I create custom templates and outputs? Can you split
  templates from the generator (e.g. load templates from class path or
  a give directory like torque-gen does)?

- A driver which controls the output generation. There is a rudimentary,
  Velocity only driver with Texen in the Velocity project

>From these three parts, only the first two are really database centric
and only because they are hard coded into commons-sql. You could bundle
abstract representations of "data model" and "data output" together with
a generic driver and it would be a nice sub-project for Jakarta and then
bundle up a concrete implementation of the data model representing a
database with a set of templates for SQL and/or Source code generation
to become a part of DB. 

An example: One of the lessons _not_ learned from torque-gen is the db
type definition split into a textual representation (e.g. in
src/templates/oracle/9i/types.xml) and a code representation (e.g.
src/java/org/apache/commons/sql/builder/OracleBuilder.java). You will
either have to juggle two files to contain similar information or get
out of sync. (BTW: about the internal structures: Well, I'd prefer to
move StringBuffers around instead of the whole print()/println() shebang
but that is just a matter of taste).
You do need an unified representation. We learned this in torque the
hard way. One file (preferably an XML file) which contains all the
information and a loader for programmatic representation.

Building yet another torque-generator (which could easily be split out
of the Torque project, because it contains almost no torque-runtime
related code) with just another technology (Jelly) that is not even
liked by the people who use it heavily and started commons-sql (e.g. see
http://www.mail-archive.com/users@maven.apache.org/msg13893.html) is
IMHO a bird that will not fly very far.

commons-sql must IMHO focus better. Should it be just the "single set of
beans" as mentioned at the top page of the project? Or an all enclosing
"XML -> SQL and back" mapper? Then you definitely will touch the realm
of other "XML -> something" mappers. And there are already a lot of
these out there. 

If you really insist on moving commons-sql to Apache DB in its current
state, then I would beg you to really think _more_ about the design of
your SQL generator than the parents of torque-gen did. torque-gen has
huge problems, trying to get stuff like "MySQL, version 4" and "MySQL,
version 3" done and struggles from a restrictive XML syntax (using the
short cuts for the ID generators was a _HUGE_ mistake). 

And in the end, you do want your XML data representations to contain
metadata that describes the O/R mapping when using things like Torque or
OJB. The worst possible solution would be our users having to maintain
_two_ XML files (one for SQL representation, one for the O/R
representation).

BTW: Hibernate got this surprisingly well worked out. We can learn from
them here.

Regards
Henning

-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen  INTERMETA GmbH
[EMAIL PROTECTED]+49 9131 50 654 0   http://www.intermeta.de/
 

[jira] Updated: (JELLY-175) patch for jelly-tags-interaction

[Ryan Christanson (JIRA)]

 [ http://nagoya.apache.org/jira/browse/JELLY-175?page=history ]

Ryan Christanson updated JELLY-175:
---

Attachment: patch.txt

here is the patch to add jline support

> patch for jelly-tags-interaction
> 
>
>  Key: JELLY-175
>  URL: http://nagoya.apache.org/jira/browse/JELLY-175
>  Project: jelly
> Type: Improvement
>  Environment: I've tested this in windows with and without cygwin.
> Reporter: Ryan Christanson
> Priority: Minor
>  Attachments: patch.txt
>
> I've attached a patch to the commons-jelly-tags-interaction jar. This
> patch makes it so the interaction task will try to use jline:
> http://jline.sourceforge.net/
> Jline makes it so a java console will have tab completion, and
> history, and other goodies.
> This is great, because the maven-console plugin uses the
> commons-jelly-tags-interaction jar. So if you update the
> commons-jelly-tags-interaction jar, and then tell the maven console
> plugin to use the new jar, then your maven console will have history,
> and tab completion.
> I've set it up to remember all of the commands typed in any console,
> further it uses that history as the tab completion source - so you can
> tab complete past commands.
> I've tested this in windows and it works great, but in windows with
> cygwin, it doesn't do the fancy completion, but still works.
> By the way, in windows, jline's lib doesn't support arrows for
> history, so use CONTROL+P and CONTROL+N.
> Its possible that there might be a better way to integrate jline into
> this lib, i've just done what looked like the quickest way to get it
> working so my maven console would have history and tab completion.
> Maybe this feature could be enabled with a tag attribute?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira


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

[jira] Created: (JELLY-175) patch for jelly-tags-interaction

[Ryan Christanson (JIRA)]

patch for jelly-tags-interaction


 Key: JELLY-175
 URL: http://nagoya.apache.org/jira/browse/JELLY-175
 Project: jelly
Type: Improvement
 Environment: I've tested this in windows with and without cygwin.
Reporter: Ryan Christanson
Priority: Minor
 Attachments: patch.txt

I've attached a patch to the commons-jelly-tags-interaction jar. This
patch makes it so the interaction task will try to use jline:
http://jline.sourceforge.net/

Jline makes it so a java console will have tab completion, and
history, and other goodies.

This is great, because the maven-console plugin uses the
commons-jelly-tags-interaction jar. So if you update the
commons-jelly-tags-interaction jar, and then tell the maven console
plugin to use the new jar, then your maven console will have history,
and tab completion.

I've set it up to remember all of the commands typed in any console,
further it uses that history as the tab completion source - so you can
tab complete past commands.

I've tested this in windows and it works great, but in windows with
cygwin, it doesn't do the fancy completion, but still works.

By the way, in windows, jline's lib doesn't support arrows for
history, so use CONTROL+P and CONTROL+N.

Its possible that there might be a better way to integrate jline into
this lib, i've just done what looked like the quickest way to get it
working so my maven console would have history and tab completion.
Maybe this feature could be enabled with a tag attribute?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira


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

Re: [Vote] Moving commons-sql to db.apache.org (repost)

[Thomas Dudziak]

Henri Yandell wrote:
 To repeat my objections slightly more in full:
 I think commons-sql should become db.apache.org/sql or some new name.
 Unless there are a lot of components at db.apache.org; I think we
 should be careful before kicking another commons repository into
 action and increasing confusion.
You're right, and as I already said, for us the name is not important at 
all, nor the place in db-commons. All we would like to achieve is that 
commons-sql will be moved to db.apache.org. We don't want another 
commons repository in db.apache.org, we only saw that 
db.apache.org/commons is present but vacant. There is no problem to 
define a new name for commons-sql, though the db-commons place should 
probably be closed, as well.

 If the commons part is really important, but being inside Jakarta is
 a problem, I think we should start thinking again about asking for
 TLP for Jakarta Commons, bringing Xml Commons into it and dealing
 with the growth/scope issues as they happen.
I agree that this would be a useful and necessary thing to discuss, but 
could we split that from this vote please ?

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

Re: [Vote] Moving commons-sql to db.apache.org (repost)

[Thomas Dudziak]

Henning Schmiedehausen wrote:
+1 Henning Schmiedehausen
   

This is for the principal vote to get commons-sql into the DB project.
Personally, I'd like to see commons-sql through incubation to get the
scope of the project defined. See my other mail on the commons-dev list.
 

I don't think that this would be a good idea, because I think its 
purpose and place is clear (low-level db stuff like creating and 
altering tables in a db-independent way). Of course the doc needs 
rework, but this already an item on the to-do list.
Btw, to what email do you refer (could you give a link to gmane/nagoya) ?

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

Re: [Vote] Moving commons-sql to db.apache.org (repost)

[Oliver Zeigermann]

Ooops, you indeed confuse me, but now I get it :)  

However, I think the scope of the project might be defined without incubation.

Oliver


On Thu, 09 Dec 2004 17:11:26 +0100, Henning Schmiedehausen
<[EMAIL PROTECTED]> wrote:
> Just to confuse you any further:
> 
> --- cut ---
> 
> > +1 Henning Schmiedehausen
> 
> This is for the principal vote to get commons-sql into the DB project.
> Personally, I'd like to see commons-sql through incubation to get the
> scope of the project defined. See my other mail on the commons-dev list.
> 
> Regards
> Henning
> 
> --
> Dipl.-Inf. (Univ.) Henning P. Schmiedehausen  INTERMETA GmbH
> [EMAIL PROTECTED]+49 9131 50 654 0   http://www.intermeta.de/
> 
> RedHat Certified Engineer -- Jakarta Turbine Development  -- hero for hire
>Linux, Java, perl, Solaris -- Consulting, Training, Development
> 
> "Fighting for one's political stand is an honorable action, but re-
>  fusing to acknowledge that there might be weaknesses in one's
>  position - in order to identify them so that they can be remedied -
>  is a large enough problem with the Open Source movement that it
>  deserves to be on this list of the top five problems."
>--Michelle Levesque, "Fundamental Issues with
> Open Source Software Development"
> 
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

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

Re: [Vote] Moving commons-sql to db.apache.org (repost)

[Henning P. Schmiedehausen]

Oliver Zeigermann <[EMAIL PROTECTED]> writes:

>I meant +1 to jakarta-commons going TLP

>Concerning incubation: Why? Which of the things that should be cleared
>up while being incubated is missing in commons-sql?

I wrote this a bit further down:

[...]
>> commons-sql IMHO must show into which direction it wants to
>> evolve:
>> 
>> - Being an abstract data model for a database (then we lack things
>>   like sequence or view representations) which can be used in things
>>   like a code or SQL generator
>> 
>> - Being an SQL code generator, thus omitting the possible distinction
>> 
>> - Being an all-purpose SQL swiss knife.

Regards
Henning

-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen  INTERMETA GmbH
[EMAIL PROTECTED]+49 9131 50 654 0   http://www.intermeta.de/

RedHat Certified Engineer -- Jakarta Turbine Development  -- hero for hire
   Linux, Java, perl, Solaris -- Consulting, Training, Development

What is more important to you...
   [ ] Product Security
or [ ] Quality of Sales and Marketing Support
  -- actual question from a Microsoft customer survey

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

Re: [Vote] Moving commons-sql to db.apache.org (repost)

[Henning Schmiedehausen]

Just to confuse you any further:

--- cut ---

> +1 Henning Schmiedehausen

This is for the principal vote to get commons-sql into the DB project.
Personally, I'd like to see commons-sql through incubation to get the
scope of the project defined. See my other mail on the commons-dev list.



Regards
Henning

-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen  INTERMETA GmbH
[EMAIL PROTECTED]+49 9131 50 654 0   http://www.intermeta.de/
 
RedHat Certified Engineer -- Jakarta Turbine Development  -- hero for hire
   Linux, Java, perl, Solaris -- Consulting, Training, Development

"Fighting for one's political stand is an honorable action, but re-
 fusing to acknowledge that there might be weaknesses in one's
 position - in order to identify them so that they can be remedied -
 is a large enough problem with the Open Source movement that it
 deserves to be on this list of the top five problems."
   --Michelle Levesque, "Fundamental Issues with
Open Source Software Development"


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

Re: [Vote] Moving commons-sql to db.apache.org (repost)

[Oliver Zeigermann]

I meant +1 to jakarta-commons going TLP

Concerning incubation: Why? Which of the things that should be cleared
up while being incubated is missing in commons-sql?

Oliver

On Thu, 9 Dec 2004 15:59:44 + (UTC), Henning P. Schmiedehausen
<[EMAIL PROTECTED]> wrote:
> Oliver Zeigermann <[EMAIL PROTECTED]> writes:
> 
> >Jakarta Commons is so huge that I'd be +1 to make it a TLP.
> 
> What? Jakarta-Commons or commons-sql?
> 
> +0 to jakarta-commons going TLP
> 
> -1 to commons-sql
> 
> -0 to put common-sql directly into DB
> 
> I skimmed the commons-sql code a bit and IMHO this needs
> incubation. The code sat in the CVS for quite a while until recently a
> few people started hacking on it.
> 
> The structure is quite similar to some of the SQL generation parts of
> the torque-generator so limiting this project to SQL generation would
> IMHO be a bad move.
> 
> I fact, commons-sql could even be split into multiple parts:
> 
> - a data model (currently focused on database, table, column)
> 
> - a templating backend that builds output files from the data
>   model (currently commons-sql just builds SQL files; the
>   torque-generator can build SQL files and source for Torque and OJB)
> 
> - a driver which controls the generation process. There is a
>   limited driver with the Texen part of Velocity
> 
> In fact, only the implementation of the first two parts is really DB
> scope.
> 
> commons-sql IMHO must show into which direction it wants to
> evolve:
> 
> - Being an abstract data model for a database (then we lack things
>   like sequence or view representations) which can be used in things
>   like a code or SQL generator
> 
> - Being an SQL code generator, thus omitting the possible distinction
> 
> - Being an all-purpose SQL swiss knife.
> 
> In any case, IMHO it should go through incubation.
> 
> Regards
> Henning
> 
> 
> 
> 
> >Oliver
> 
> >On Wed, 8 Dec 2004 18:04:08 -0500, Henri Yandell <[EMAIL PROTECTED]> wrote:
> >> To repeat my objections slightly more in full:
> >>
> >> I think commons-sql should become db.apache.org/sql or some new name.
> >> Unless there are a lot of components at db.apache.org; I think we
> >> should be careful before kicking another commons repository into
> >> action and increasing confusion.
> >>
> >> If the commons part is really important, but being inside Jakarta is a
> >> problem, I think we should start thinking again about asking for TLP
> >> for Jakarta Commons, bringing Xml Commons into it and dealing with the
> >> growth/scope issues as they happen.
> >>
> >> Hen
> >>
> >>
> >>
> >> On Wed, 08 Dec 2004 21:32:30 +0100, Thomas Dudziak <[EMAIL PROTECTED]> 
> >> wrote:
> >> > (This is a repost from a vote that I started earlier today, but where I
> >> > did not include commons-dev. This omission has been pointed out to me,
> >> > and I agree that including commons-dev is important, so I repost the
> >> > vote hereby)
> >> >
> >> > Hi all,
> >> >
> >> > I'd like to start a cross-vote (Jakarta PMC and commons-dev, DB PMC)
> >> > about moving the jakarta sandbox project commons-sql
> >> > (http://jakarta.apache.org/commons/sandbox/sql/) over to db.apache.org,
> >> > for instance into the currently vacant db-commons space
> >> > (http://db.apache.org/commons/).
> >> >
> >> > The reasons why we want to move commons-sql, are twofold:
> >> >
> >> > * The two active committers (Martin Kalén and myself) are DB comitters,
> >> > but not comitters to another Jakarta project. As a result we would
> >> > rather not subscribe to commons-dev/commons-user because very few mails
> >> > there deal with commons-sql (one or two per month). Also, db-commons
> >> > already has all setup'd (mailing lists, CVS space etc.), not to mention
> >> > that the exposure of the project would be much greater.
> >> >
> >> > * No other Jakarta project that I'm aware of, uses commons-sql. In
> >> > contrast, OJB will do so (beginning with the upcoming 1.1 version), and
> >> > so it would be good to provide access to the commons-sql repository to
> >> > the OJB comitters. The same might also be true for Torque as
> >> > commons-sql's functionality overlaps in some parts with Torque
> >> > functionality, which opens up an opportunity to combine this
> >> > functionality into a base component which both OJB and Torque could use.
> >> >
> >> > Please post your opinion until next wednesday, the 15th of december, and
> >> > please reply to all recipients.
> >> >
> >> > Votes cast so far:
> >> >
> >> > +1 Brian McCallister
> >> > +1 Henri Yandell
> >> > (though with objections regarding moving it into db-commons,
> >> >  http://db.apache.org/commons)
> >> > +1 Henning Schmiedehausen
> >> >
> >> > regards,
> >> > Thomas Dudziak
> >> >
> >> > PS: I'm not sure if this is the correct procedure, but I thought a vote
> >> > is at least a good way to get the ball rolling, so to speak. If there is
> >> > a defined way to handle movement of projects, then please let me know.
> >> >
> >> > 

Re: [Vote] Moving commons-sql to db.apache.org (repost)

[Henning P. Schmiedehausen]

Oliver Zeigermann <[EMAIL PROTECTED]> writes:

>Jakarta Commons is so huge that I'd be +1 to make it a TLP.

What? Jakarta-Commons or commons-sql? 

+0 to jakarta-commons going TLP

-1 to commons-sql

-0 to put common-sql directly into DB

I skimmed the commons-sql code a bit and IMHO this needs
incubation. The code sat in the CVS for quite a while until recently a
few people started hacking on it.

The structure is quite similar to some of the SQL generation parts of
the torque-generator so limiting this project to SQL generation would
IMHO be a bad move.

I fact, commons-sql could even be split into multiple parts:

- a data model (currently focused on database, table, column)

- a templating backend that builds output files from the data
  model (currently commons-sql just builds SQL files; the
  torque-generator can build SQL files and source for Torque and OJB)

- a driver which controls the generation process. There is a 
  limited driver with the Texen part of Velocity

In fact, only the implementation of the first two parts is really DB
scope.

commons-sql IMHO must show into which direction it wants to
evolve:

- Being an abstract data model for a database (then we lack things
  like sequence or view representations) which can be used in things
  like a code or SQL generator

- Being an SQL code generator, thus omitting the possible distinction 

- Being an all-purpose SQL swiss knife.

In any case, IMHO it should go through incubation.

Regards
Henning



>Oliver

>On Wed, 8 Dec 2004 18:04:08 -0500, Henri Yandell <[EMAIL PROTECTED]> wrote:
>> To repeat my objections slightly more in full:
>> 
>> I think commons-sql should become db.apache.org/sql or some new name.
>> Unless there are a lot of components at db.apache.org; I think we
>> should be careful before kicking another commons repository into
>> action and increasing confusion.
>> 
>> If the commons part is really important, but being inside Jakarta is a
>> problem, I think we should start thinking again about asking for TLP
>> for Jakarta Commons, bringing Xml Commons into it and dealing with the
>> growth/scope issues as they happen.
>> 
>> Hen
>> 
>> 
>> 
>> On Wed, 08 Dec 2004 21:32:30 +0100, Thomas Dudziak <[EMAIL PROTECTED]> wrote:
>> > (This is a repost from a vote that I started earlier today, but where I
>> > did not include commons-dev. This omission has been pointed out to me,
>> > and I agree that including commons-dev is important, so I repost the
>> > vote hereby)
>> >
>> > Hi all,
>> >
>> > I'd like to start a cross-vote (Jakarta PMC and commons-dev, DB PMC)
>> > about moving the jakarta sandbox project commons-sql
>> > (http://jakarta.apache.org/commons/sandbox/sql/) over to db.apache.org,
>> > for instance into the currently vacant db-commons space
>> > (http://db.apache.org/commons/).
>> >
>> > The reasons why we want to move commons-sql, are twofold:
>> >
>> > * The two active committers (Martin Kalén and myself) are DB comitters,
>> > but not comitters to another Jakarta project. As a result we would
>> > rather not subscribe to commons-dev/commons-user because very few mails
>> > there deal with commons-sql (one or two per month). Also, db-commons
>> > already has all setup'd (mailing lists, CVS space etc.), not to mention
>> > that the exposure of the project would be much greater.
>> >
>> > * No other Jakarta project that I'm aware of, uses commons-sql. In
>> > contrast, OJB will do so (beginning with the upcoming 1.1 version), and
>> > so it would be good to provide access to the commons-sql repository to
>> > the OJB comitters. The same might also be true for Torque as
>> > commons-sql's functionality overlaps in some parts with Torque
>> > functionality, which opens up an opportunity to combine this
>> > functionality into a base component which both OJB and Torque could use.
>> >
>> > Please post your opinion until next wednesday, the 15th of december, and
>> > please reply to all recipients.
>> >
>> > Votes cast so far:
>> >
>> > +1 Brian McCallister
>> > +1 Henri Yandell
>> > (though with objections regarding moving it into db-commons,
>> >  http://db.apache.org/commons)
>> > +1 Henning Schmiedehausen
>> >
>> > regards,
>> > Thomas Dudziak
>> >
>> > PS: I'm not sure if this is the correct procedure, but I thought a vote
>> > is at least a good way to get the ball rolling, so to speak. If there is
>> > a defined way to handle movement of projects, then please let me know.
>> >
>> > -
>> > To unsubscribe, e-mail: [EMAIL PROTECTED]
>> > For additional commands, e-mail: [EMAIL PROTECTED]
>> >
>> >
>> 
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>> 
>>

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

Re: [Vote] Moving commons-sql to db.apache.org (repost)

[Oliver Zeigermann]

+1 for commons-sql to db.apache.org

Oliver


On Wed, 08 Dec 2004 21:32:30 +0100, Thomas Dudziak <[EMAIL PROTECTED]> wrote:
> (This is a repost from a vote that I started earlier today, but where I
> did not include commons-dev. This omission has been pointed out to me,
> and I agree that including commons-dev is important, so I repost the
> vote hereby)
> 
> Hi all,
> 
> I'd like to start a cross-vote (Jakarta PMC and commons-dev, DB PMC)
> about moving the jakarta sandbox project commons-sql
> (http://jakarta.apache.org/commons/sandbox/sql/) over to db.apache.org,
> for instance into the currently vacant db-commons space
> (http://db.apache.org/commons/).
> 
> The reasons why we want to move commons-sql, are twofold:
> 
> * The two active committers (Martin Kalén and myself) are DB comitters,
> but not comitters to another Jakarta project. As a result we would
> rather not subscribe to commons-dev/commons-user because very few mails
> there deal with commons-sql (one or two per month). Also, db-commons
> already has all setup'd (mailing lists, CVS space etc.), not to mention
> that the exposure of the project would be much greater.
> 
> * No other Jakarta project that I'm aware of, uses commons-sql. In
> contrast, OJB will do so (beginning with the upcoming 1.1 version), and
> so it would be good to provide access to the commons-sql repository to
> the OJB comitters. The same might also be true for Torque as
> commons-sql's functionality overlaps in some parts with Torque
> functionality, which opens up an opportunity to combine this
> functionality into a base component which both OJB and Torque could use.
> 
> Please post your opinion until next wednesday, the 15th of december, and
> please reply to all recipients.
> 
> Votes cast so far:
> 
> +1 Brian McCallister
> +1 Henri Yandell
> (though with objections regarding moving it into db-commons,
>  http://db.apache.org/commons)
> +1 Henning Schmiedehausen
> 
> regards,
> Thomas Dudziak
> 
> PS: I'm not sure if this is the correct procedure, but I thought a vote
> is at least a good way to get the ball rolling, so to speak. If there is
> a defined way to handle movement of projects, then please let me know.
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

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

Re: [Vote] Moving commons-sql to db.apache.org (repost)

[Oliver Zeigermann]

Jakarta Commons is so huge that I'd be +1 to make it a TLP.

Oliver

On Wed, 8 Dec 2004 18:04:08 -0500, Henri Yandell <[EMAIL PROTECTED]> wrote:
> To repeat my objections slightly more in full:
> 
> I think commons-sql should become db.apache.org/sql or some new name.
> Unless there are a lot of components at db.apache.org; I think we
> should be careful before kicking another commons repository into
> action and increasing confusion.
> 
> If the commons part is really important, but being inside Jakarta is a
> problem, I think we should start thinking again about asking for TLP
> for Jakarta Commons, bringing Xml Commons into it and dealing with the
> growth/scope issues as they happen.
> 
> Hen
> 
> 
> 
> On Wed, 08 Dec 2004 21:32:30 +0100, Thomas Dudziak <[EMAIL PROTECTED]> wrote:
> > (This is a repost from a vote that I started earlier today, but where I
> > did not include commons-dev. This omission has been pointed out to me,
> > and I agree that including commons-dev is important, so I repost the
> > vote hereby)
> >
> > Hi all,
> >
> > I'd like to start a cross-vote (Jakarta PMC and commons-dev, DB PMC)
> > about moving the jakarta sandbox project commons-sql
> > (http://jakarta.apache.org/commons/sandbox/sql/) over to db.apache.org,
> > for instance into the currently vacant db-commons space
> > (http://db.apache.org/commons/).
> >
> > The reasons why we want to move commons-sql, are twofold:
> >
> > * The two active committers (Martin Kalén and myself) are DB comitters,
> > but not comitters to another Jakarta project. As a result we would
> > rather not subscribe to commons-dev/commons-user because very few mails
> > there deal with commons-sql (one or two per month). Also, db-commons
> > already has all setup'd (mailing lists, CVS space etc.), not to mention
> > that the exposure of the project would be much greater.
> >
> > * No other Jakarta project that I'm aware of, uses commons-sql. In
> > contrast, OJB will do so (beginning with the upcoming 1.1 version), and
> > so it would be good to provide access to the commons-sql repository to
> > the OJB comitters. The same might also be true for Torque as
> > commons-sql's functionality overlaps in some parts with Torque
> > functionality, which opens up an opportunity to combine this
> > functionality into a base component which both OJB and Torque could use.
> >
> > Please post your opinion until next wednesday, the 15th of december, and
> > please reply to all recipients.
> >
> > Votes cast so far:
> >
> > +1 Brian McCallister
> > +1 Henri Yandell
> > (though with objections regarding moving it into db-commons,
> >  http://db.apache.org/commons)
> > +1 Henning Schmiedehausen
> >
> > regards,
> > Thomas Dudziak
> >
> > PS: I'm not sure if this is the correct procedure, but I thought a vote
> > is at least a good way to get the ball rolling, so to speak. If there is
> > a defined way to handle movement of projects, then please let me know.
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

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

[Announcement] Commons Math 1.0 Released

[Phil Steitz]

The Jakarta Commons Math team is pleased to announce the release of 
Commons Math 1.0. Commons Math is a library of lightweight, 
self-contained mathematics and statistics components.

This is the first official release of Commons Math.  A list of changes 
since the first release candidate can be found here:

http://jakarta.apache.org/commons/math/changes-report.html
Both binary and source distributions are available from the usual mirror 
sites. Please remember to verify the signatures of the files you 
download using the keys found on the main apache web site when 
downloading from a mirror site.

binaries: http://jakarta.apache.org/site/binindex.cgi#commons-math
source: http://jakarta.apache.org/site/sourceindex.cgi#commons-math
For more information on Commons Math, see the Math web site:
http://jakarta.apache.org/commons/math/
---
Phil Steitz (on behalf of the Commons Math team)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (JELLY-174) does not use onlyWait as maximum wait time for thread groups

[Matthias Kerkhoff (JIRA)]

 [ http://nagoya.apache.org/jira/browse/JELLY-174?page=history ]

Matthias Kerkhoff updated JELLY-174:


Attachment: WaitForTag.java

Small code change which makes onlyWait to act as a strict upper bound for the 
total time spent waiting on all threads of given thread group.

>  does not use onlyWait as maximum wait time for thread groups
> --
>
>  Key: JELLY-174
>  URL: http://nagoya.apache.org/jira/browse/JELLY-174
>  Project: jelly
> Type: Bug
> Reporter: Matthias Kerkhoff
>  Attachments: WaitForTag.java
>
> Consider 
>   
> How long will this tag wait at most? Well, it depends. It depends on how many 
> threads are in the group. The worst case will be onlyWait * tg.size(). Each 
> thread, however, may not take longer than onlyWait to complete.
> From my experience when a timeout like onlyWait is needed, one usually wants 
> to set an upper limit for the _group_ as a whole. How this timeout is spread 
> among the threads in the group often doesn't matter. 
> In the current implementation, the limit is a per-thread timeout even if a 
> group is specified.
> I would suggest a small code change, which changes the behaviour of waitFor 
> in a way that when a group is specified the timeout specifies the time that 
> _all_ threads in the group may take to end or to reach the specified status.
> The old behaviour can easily be achieved by iterating over each thread in the 
> group and calling  for that thread.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira


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

[jira] Created: (JELLY-174) does not use onlyWait as maximum wait time for thread groups

[Matthias Kerkhoff (JIRA)]

 does not use onlyWait as maximum wait time for thread groups
--

 Key: JELLY-174
 URL: http://nagoya.apache.org/jira/browse/JELLY-174
 Project: jelly
Type: Bug
Reporter: Matthias Kerkhoff


Consider 
  

How long will this tag wait at most? Well, it depends. It depends on how many 
threads are in the group. The worst case will be onlyWait * tg.size(). Each 
thread, however, may not take longer than onlyWait to complete.

>From my experience when a timeout like onlyWait is needed, one usually wants 
>to set an upper limit for the _group_ as a whole. How this timeout is spread 
>among the threads in the group often doesn't matter. 
In the current implementation, the limit is a per-thread timeout even if a 
group is specified.

I would suggest a small code change, which changes the behaviour of waitFor in 
a way that when a group is specified the timeout specifies the time that _all_ 
threads in the group may take to end or to reach the specified status.

The old behaviour can easily be achieved by iterating over each thread in the 
group and calling  for that thread.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira


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

[GUMP@brutus]: Project commons-jelly-tags-jsl (in module jelly-tags) failed

[Morgan Delagrange]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project commons-jelly-tags-jsl has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 7 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-jelly-tags-jsl :  The Jelly Stylesheet Library (JSL)


Full details are available at:

http://brutus.apache.org/gump/public/jelly-tags/commons-jelly-tags-jsl/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole output [commons-jelly-tags-jsl-09122004.jar] identifier set to 
project name
 -INFO- Failed with reason build failed
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://brutus.apache.org/gump/public/jelly-tags/commons-jelly-tags-jsl/gump_work/build_jelly-tags_commons-jelly-tags-jsl.html
Work Name: build_jelly-tags_commons-jelly-tags-jsl (Type: Build)
Work ended in a state of : Failed
Elapsed: 2 secs
Command Line: java -Djava.awt.headless=true -Dbuild.clonevm=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar
 org.apache.tools.ant.Main 
-Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only -Dfinal.name=commons-jelly-tags-jsl-09122004 jar 
[Working Directory: /usr/local/gump/public/workspace/jelly-tags/jsl]
CLASSPATH: 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/jelly-tags/jsl/target/classes:/usr/local/gump/public/workspace/jelly-tags/jsl/target/test-classes:/usr/local/gump/public/workspace/jakarta-commons/jelly/target/commons-jelly-09122004.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-stylebook.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-09122004.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-09122004.jar:/usr/local/gump/public/workspace/jakarta-commons/lang/dist/commons-lang-09122004.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar:/usr/local/gump/packages/dom4j-1.4/dom4j-full.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-09122004.jar:/usr/local/gump/public/workspace/jakarta-commons/discovery/dist/commons-discovery.jar:/usr/local/gump/public/workspace/jakarta-servletapi-5/jsr154/dist/lib/servlet-api.jar:/usr/local/gump/public/workspace/jakarta-servletapi-5/jsr152/dist/lib/jsp-api.jar:/usr/local/gump/public/workspace/jakarta-taglibs/dist/standard/lib/standard.jar:/usr/local/gump/public/workspace/jakarta-taglibs/dist/standard/lib/jstl.jar:/usr/local/gump/packages/nekohtml-0.9.3/nekohtmlXni.jar:/usr/local/gump/packages/nekohtml-0.9.3/nekohtml.jar:/usr/local/gump/public/workspace/jelly-tags/xml/target/commons-jelly-tags-xml-09122004.jar:/usr/local/gump/public/workspace/jelly-tags/junit/target/commons-jelly-tags-junit-09122004.jar:/usr/local/gump/public/workspace/jelly-tags/ant/target/commons-jelly-tags-ant-09122004.jar:/usr/local/gump/public/workspace/commons-grant/target/commons-grant-09122004.jar:/usr/local/gump/public/workspace/jelly-tags/log/target/commons-jelly-tags-log-09122004.jar
-
Buildfile: build.xml

init:
[mkdir] Created dir: 
/home/gump/workspaces2/public/workspace/jelly-tags/jsl/target/lib

get-deps:

compile:
[mkdir] Created dir: 
/home/gump/workspaces2/public/workspace/jelly-tags/jsl/target/classes
[javac] Compiling 7 source files to 
/home/gump/workspaces2/public/workspace/jelly-tags/jsl/target/classes
[javac] 
/home/gump/workspaces2/public/workspace/jelly-tags/jsl/src/java/org/apache/commons/jelly/tags/jsl/ApplyTemplatesTag.java:67:
 cannot resolve symbol
[javac] symbol  : method applyTemplates 
(java.lang.Object,org.jaxen.XPath,java.lang.String)
[javac] location: class org.dom4j.rule.Stylesheet
[javac] stylesheet.applyTemplates( source, select, mode );
[javac]   

[jira] Updated: (JELLY-172) util:properties locks the file forever

[Matthias Kerkhoff (JIRA)]

 [ http://nagoya.apache.org/jira/browse/JELLY-172?page=history ]

Matthias Kerkhoff updated JELLY-172:


Attachment: PropertiesTag.java
suite.jelly

Proposed fix and testcase for JELLY-172.

> util:properties locks the file forever
> --
>
>  Key: JELLY-172
>  URL: http://nagoya.apache.org/jira/browse/JELLY-172
>  Project: jelly
> Type: Bug
>   Components: taglib.util
>  Environment: windows, util-taglib version that comes with maven 1.0.2
> Reporter: Matthias Kerkhoff
>  Attachments: PropertiesTag.java, suite.jelly
>
> The following code (taken from a maven script) will always fail:
> 
> 
> 
> From looking tinto the source, I would guess that the problem is an 
> InputStream which is opened, but never closed. 
> The problem definitly appears on windows, can't test on other platforms.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira


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