Re: [launcher] ordered system properties

[Craig McClanahan]

I am not a participant in the [launcher] project at Jakarta Commons,
but if I were, I would vote against such a proposal on general
principles -- dependence on behavior like this is *incredibly*
fragile, and is pretty much guaranteed to break the next time someone
tweaks your persistence strategy (or you upgrade to a new JVM that
iterates HashMap keys in a different order ... :-).

By far the better strategy would be to arrange the lifecycle of your
service objects so that they had (at least) two phases:

* Configuration -- property settings can occur in any desired order.
  This is really critical if you expect your component to be supported
  by development tools, and is required for maintainability even if you
  do not care about tools support.

* Lifecycle -- some sort of a start() method that is guaranteed to not
  be invoked until *after* all the relevant properties have been set from
  the configuration information.

Even if you can craft an order-dependent solution now, you are really
going to kick yourself in the rear end a year from now -- my strong
recommendation is to avoid that kind of pain and embarrasement :-),
and start with a strategy that is scalable over the long term.

Craig

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

RE: Jakarta Commons Structure rehashed

[Tim O'Brien]

 

> -Original Message-
> From: Noel J. Bergman [mailto:[EMAIL PROTECTED] 
> Sent: Saturday, December 18, 2004 11:12 PM
> To: Jakarta Commons Developers List
> Subject: RE: Jakarta Commons Structure rehashed 
> 
> > I also prefer the flatter layout:
> > jakarta/commons/tags/
> >/branches
> >/trunk
> 
> We don't version Commons as a single component, and I don't 
> know that we want to force everyone to always take every 
> single component.  Someone wanting to build all of Commons is 
> not the norm.
> 

Agreed, we also don't want to go through the acrobatics of maintaining a
jakarta/commons/tags directory with hundreds of subdirectories.  Think
about just how many tags we have in commons and then contemplate a
single directory with every - combination, that's
going to get silly very fast.  Likewise for branches.

Each component in commons proper is a component digester has a trunk, it
gets tagged, and branches independently of latka.




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

RE: Jakarta Commons Structure rehashed

[Noel J. Bergman]

> I also prefer the flatter layout:
> jakarta/commons/tags/
>/branches
>/trunk

We don't version Commons as a single component, and I don't know that we
want to force everyone to always take every single component.  Someone
wanting to build all of Commons is not the norm.

--- Noel


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

Re: Jakarta Commons Structure rehashed

[Daniel F. Savarese]

In message <[EMAIL PROTECTED]>, Henri Yandell writes:
>On Sun, 19 Dec 2004 00:00:20 +1300, Simon Kitching
><[EMAIL PROTECTED]> wrote:
>> svn 1.1 (released 2004-09-29) supports "symbolic links". Perhaps that
>> would resolve the issue by allowing us to (manually) build an
>> alternative directory containing just symbolic links to the "trunk"
>> directory of each subproject? Of course whenever a new subproject was
>> created, a symbolic link would need to be manually added - but that is
>> no great problem. Possibly that could even be automated; I'm willing to
>> try to get that working.
>
>Cool. I knew such a feature was in the planning but hadn't realised it
>was out yet. I'm +1 on option A + sym-links or script depending on
>which feels best.
>
>As long as there's a simple way to check out the head of all of commons :)

I haven't read the entire thread, but if I understand what's being
discussed, checking in symbolic links won't do what you want (assuming
we're talking about ln -s symbolic links).  Setting the svn:externals
property will do what I think you're talking about.  For example, you
could set svn:externals in a directory to:

lang https://svn.apache.org/repos/asf/jakarta/commons/proper/lang/trunk
math https://svn.apache.org/repos/asf/jakarta/commons/proper/math/trunk
...

That way when you check out the directory, subdirectories lang, math,
etc. are created with the contents of the urls checked out.

I prefer the idea of using a script instead because it's more flexible
for doing things like checking out personalized subsets of commons.
Anyway, I may have misunderstood the intent from the get go.

I also prefer the flatter layout:
jakarta/commons/tags/
/attributes-1.0.1
/attributes-1.0.2
/beanutils-0.9.7
/sandbox/altrmi-x.x.x
...
   /branches
/lang-foo
/math-bar
   /trunk
 /attributes
 ...
 /sandbox
 /altrmi
 /amend
 ...
 /site
 ...
 /validator

I can't offer a reason why it's technically better because it just
amounts to personal preference.  Also, I see how doing having
proper/ and sandbox/ parent trees makes certain things easier
(like generating commit message subject headers).  However, it does
make it easier to check out the trunk of commons all at once.  I'm
sure I missed the original discussion about this, so don't reraise the
issue on my account.  It doesn't really matter anyway because layouts
can be changed after the fact if there's some compelling reason to do
so.  I only wanted to convey the bit about svn:externals vis a vis
symbolic links since it caught my eye.

daniel



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

DO NOT REPLY [Bug 31977] - [dbutils] New ResultSetHandler - ObjectHandler

[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=31977





--- Additional Comments From [EMAIL PROTECTED]  2004-12-19 05:04 ---
Since BeanProcessor.newInstance() is protected it's quite straightforward to
implement a handler that does this.  Below is, for lack of a better name,
ObjectBeanHandler that fills the object given to it rather than creating a new
instance.

public class ObjectBeanHandler implements ResultSetHandler {
private Object fill = null;
public ObjectBeanHandler(Object fill) {
this.fill = fill;
}
public Object handle(ResultSet rs) throws SQLException {
BeanProcessor p = new BeanProcessor() {
protected Object newInstance(Class c) {
return fill;
}
};
return rs.next() ? p.toBean(rs, fill.getClass()) : null;
}
}

The nice thing about BeanHandler creating a new instance each time is that it's
thread safe so only one instance of the handler needs to be created.  I
typically store this shared handler instance in a static variable.  By its very
nature ObjectBeanHandler can only work on the object given to it so a new
handler *and* a new BeanProcessor must be created for each object.

I guess it's the difference between saying:
Person p = new Person(id);
p.load();

and

Person p = Person.load(id);

-- 
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: Jakarta Commons Structure rehashed

[Henri Yandell]

Do we want to clean  the sandbox up before an svn migration?

Hen

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

cvs commit: jakarta-commons/lang/src/test/org/apache/commons/lang/time DurationFormatUtilsTest.java

[bayard]

bayard  2004/12/18 19:30:38

  Modified:lang/src/test/org/apache/commons/lang/time
DurationFormatUtilsTest.java
  Log:
  should now run the last bit of code
  
  Revision  ChangesPath
  1.16  +1 -1  
jakarta-commons/lang/src/test/org/apache/commons/lang/time/DurationFormatUtilsTest.java
  
  Index: DurationFormatUtilsTest.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/lang/src/test/org/apache/commons/lang/time/DurationFormatUtilsTest.java,v
  retrieving revision 1.15
  retrieving revision 1.16
  diff -u -r1.15 -r1.16
  --- DurationFormatUtilsTest.java  19 Dec 2004 03:23:00 -  1.15
  +++ DurationFormatUtilsTest.java  19 Dec 2004 03:30:38 -  1.16
  @@ -326,7 +326,7 @@
   new DurationFormatUtils.Token( new Object() )
   ) );
   assertFalse( "Token equal to Token with different count. ", 
token.equals(
  -new DurationFormatUtils.Token( new Object(), 1 )
  +new DurationFormatUtils.Token( DurationFormatUtils.y, 1 )
   ) );
   DurationFormatUtils.Token numToken = new DurationFormatUtils.Token( 
new Integer(1), 4 );
   assertTrue( "Token with Number value not equal to itself. ", 
numToken.equals( numToken ) );
  
  
  

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

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

[dgraham]

dgraham 2004/12/18 19:25:06

  Modified:dbutils/src/java/org/apache/commons/dbutils
ResultSetIterator.java
  Log:
  Removed TODOs.
  
  Revision  ChangesPath
  1.5   +0 -9  
jakarta-commons/dbutils/src/java/org/apache/commons/dbutils/ResultSetIterator.java
  
  Index: ResultSetIterator.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/dbutils/src/java/org/apache/commons/dbutils/ResultSetIterator.java,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- ResultSetIterator.java28 Feb 2004 00:12:23 -  1.4
  +++ ResultSetIterator.java19 Dec 2004 03:25:06 -  1.5
  @@ -66,10 +66,7 @@
   public boolean hasNext() {
   try {
   return !rs.isLast();
  -
   } catch (SQLException e) {
  -// TODO Logging?
  -//e.printStackTrace();
   return false;
   }
   }
  @@ -84,10 +81,7 @@
   try {
   rs.next();
   return this.convert.toArray(rs);
  -
   } catch (SQLException e) {
  -// TODO Logging?
  -//e.printStackTrace();
   return null;
   }
   }
  @@ -99,10 +93,7 @@
   public void remove() {
   try {
   this.rs.deleteRow();
  -
   } catch (SQLException e) {
  -// TODO Logging?
  -//e.printStackTrace();
   }
   }
   
  
  
  

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

cvs commit: jakarta-commons/lang/src/test/org/apache/commons/lang/time DurationFormatUtilsTest.java

[bayard]

bayard  2004/12/18 19:23:00

  Modified:lang/src/test/org/apache/commons/lang/time
DurationFormatUtilsTest.java
  Log:
  few more tests to get 100% coverage for Token
  
  Revision  ChangesPath
  1.15  +12 -0 
jakarta-commons/lang/src/test/org/apache/commons/lang/time/DurationFormatUtilsTest.java
  
  Index: DurationFormatUtilsTest.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/lang/src/test/org/apache/commons/lang/time/DurationFormatUtilsTest.java,v
  retrieving revision 1.14
  retrieving revision 1.15
  diff -u -r1.14 -r1.15
  --- DurationFormatUtilsTest.java  15 Oct 2004 23:11:31 -  1.14
  +++ DurationFormatUtilsTest.java  19 Dec 2004 03:23:00 -  1.15
  @@ -318,6 +318,18 @@
 }, 
 
DurationFormatUtils.lexx(DurationFormatUtils.ISO_EXTENDED_FORMAT_PATTERN)
   );
  +
  +// test failures in equals
  +DurationFormatUtils.Token token = new DurationFormatUtils.Token( 
DurationFormatUtils.y, 4 );
  +assertFalse( "Token equal to non-Token class. ", token.equals(new 
Object()) );
  +assertFalse( "Token equal to Token with wrong value class. ", 
token.equals(
  +new DurationFormatUtils.Token( new Object() )
  +) );
  +assertFalse( "Token equal to Token with different count. ", 
token.equals(
  +new DurationFormatUtils.Token( new Object(), 1 )
  +) );
  +DurationFormatUtils.Token numToken = new DurationFormatUtils.Token( 
new Integer(1), 4 );
  +assertTrue( "Token with Number value not equal to itself. ", 
numToken.equals( numToken ) );
   }
   private void assertArrayEquals(DurationFormatUtils.Token[] obj1, 
DurationFormatUtils.Token[] obj2) {
   assertEquals( "Arrays are unequal length. ", obj1.length, 
obj2.length );
  
  
  

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

cvs commit: jakarta-commons/transaction/xdocs/style basic.xsl

[ozeigermann]

ozeigermann2004/12/18 19:11:06

  Modified:transaction/xdocs/style basic.xsl
  Log:
  Fixed wrong reference to project.xml
  
  Revision  ChangesPath
  1.2   +2 -2  jakarta-commons/transaction/xdocs/style/basic.xsl
  
  Index: basic.xsl
  ===
  RCS file: /home/cvs/jakarta-commons/transaction/xdocs/style/basic.xsl,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- basic.xsl 19 Nov 2004 23:58:46 -  1.1
  +++ basic.xsl 19 Dec 2004 03:11:06 -  1.2
  @@ -28,7 +28,7 @@
 
 
   
  +select="document('../../project.xml')/project"/>
   
   
- 
  
  
  

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

cvs commit: jakarta-commons/transaction/src/test/org/apache/commons/transaction/locking GenericLockTest.java

[ozeigermann]

ozeigermann2004/12/18 19:07:23

  Modified:transaction/src/test/org/apache/commons/transaction/locking
GenericLockTest.java
  Log:
  Added test for global timeouts
  
  Revision  ChangesPath
  1.7   +74 -7 
jakarta-commons/transaction/src/test/org/apache/commons/transaction/locking/GenericLockTest.java
  
  Index: GenericLockTest.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/transaction/src/test/org/apache/commons/transaction/locking/GenericLockTest.java,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- GenericLockTest.java  18 Dec 2004 23:15:08 -  1.6
  +++ GenericLockTest.java  19 Dec 2004 03:07:23 -  1.7
  @@ -49,7 +49,7 @@
   
   private static final int CONCURRENT_TESTS = 25;
   
  -protected static final long TIMEOUT = Long.MAX_VALUE;
  +protected static final long TIMEOUT = 100;
   
   private static int deadlockCnt = 0;
   private static String first = null;
  @@ -168,7 +168,7 @@
   
   for (int i = 0; i < CONCURRENT_TESTS; i++) {
   
  -//System.out.print(".");
  +   System.out.print(".");
   
   final RendezvousBarrier deadlockBarrier1 = new 
RendezvousBarrier("deadlock1" + i,
   TIMEOUT, sLogger);
  @@ -224,7 +224,7 @@
   }
   }
   
  -assertEquals(deadlockCnt, 1);
  +assertEquals(1, deadlockCnt);
   deadlockCnt = 0;
   }
   }
  @@ -473,6 +473,73 @@
   lock.release(owner1);
   }
   cb.count(7);
  +synchronized (restart) {
  +restart.meet();
  +restart.reset();
  +}
  +
  +cb.reset();
  +}
  +
  +}
  +
  +public void testGlobalTimeout() throws Throwable {
  +
  +sLogger.logInfo("\n\nChecking global timeouts\n\n");
  +
  +final String owner1 = "owner1";
  +final String owner2 = "owner2";
  +
  +final String res1 = "res1";
  +
  +final GenericLockManager manager = new GenericLockManager(1, 
sLogger, TIMEOUT, -1);
  +
  +final RendezvousBarrier restart = new RendezvousBarrier("restart", 
2, TIMEOUT, sLogger);
  +
  +final CounterBarrier cb = new CounterBarrier("cb1", TIMEOUT, 
sLogger);
  +
  +for (int i = 0; i < CONCURRENT_TESTS; i++) {
  +
  +System.out.print(".");
  +
  +Thread t1 = new Thread(new Runnable() {
  +public void run() {
  +try {
  +cb.count(2);
  +manager.lock(owner2, res1, 1, true);
  +cb.count(3);
  +manager.releaseAll(owner2);
  +synchronized (restart) {
  +restart.meet();
  +restart.reset();
  +}
  +} catch (InterruptedException ie) {
  +}
  +}
  +}, "Thread #1");
  +
  +t1.start();
  +
  +cb.count(0);
  +manager.setGlobalTimeout(owner1, 500);
  +manager.lock(owner1, res1, 1, true);
  +cb.count(1);
  +cb.count(4);
  +boolean failed = false;
  +try {
  +manager.tryLock(owner1, res1, 1, true);
  +} catch (LockException le) {
  +failed = true;
  +}
  +assertTrue(failed);
  +manager.releaseAll(owner1);
  +failed = false;
  +try {
  +manager.tryLock(owner1, res1, 1, true);
  +} catch (LockException le) {
  +failed = true;
  +}
  +assertFalse(failed);
   synchronized (restart) {
   restart.meet();
   restart.reset();
  
  
  

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

cvs commit: jakarta-commons/transaction/src/java/org/apache/commons/transaction/locking GenericLockManager.java

[ozeigermann]

ozeigermann2004/12/18 19:07:04

  Modified:transaction/src/java/org/apache/commons/transaction/locking
GenericLockManager.java
  Log:
  Added global timeouts and means for deferred (more performing)
  deadlock checking
  
  Revision  ChangesPath
  1.6   +170 -40   
jakarta-commons/transaction/src/java/org/apache/commons/transaction/locking/GenericLockManager.java
  
  Index: GenericLockManager.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/transaction/src/java/org/apache/commons/transaction/locking/GenericLockManager.java,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- GenericLockManager.java   17 Dec 2004 16:36:21 -  1.5
  +++ GenericLockManager.java   19 Dec 2004 03:07:04 -  1.6
  @@ -41,6 +41,7 @@
   public class GenericLockManager implements LockManager {
   
   public static final long DEFAULT_TIMEOUT = 3;
  +public static final long DEFAULT_CHECK_THRESHHOLD = 500;
   
   /** Maps lock to ownerIds waiting for it. */
   protected Map waitsForLock = Collections.synchronizedMap(new HashMap());
  @@ -51,30 +52,47 @@
   /** Maps resourceId to lock. */
   protected Map globalLocks = new HashMap();
   
  +/** Maps onwerId to global time outs. */
  +protected Map globalTimeouts = Collections.synchronizedMap(new 
HashMap());
  +
  +protected Set timedOutOwners = Collections.synchronizedSet(new 
HashSet());
  +
   protected int maxLockLevel = -1;
   protected LoggerFacade logger;
   protected long globalTimeoutMSecs;
  +protected long checkThreshhold;
   
   /**
* Creates a new generic lock manager.
* 
* @param maxLockLevel
  - *highest allowed lock level as described in [EMAIL 
PROTECTED] GenericLock}'s class intro
  + *highest allowed lock level as described in [EMAIL 
PROTECTED] GenericLock}
  + *'s class intro
* @param logger
*generic logger used for all kind of debug logging
* @param timeoutMSecs
*specifies the maximum time to wait for a lock in 
milliseconds
  + * @param checkThreshholdMSecs
  + *specifies a special wait threshhold before deadlock and
  + *timeout detection come into play or -1 switch
  + *it off and check for directly
* @throws IllegalArgumentException
* if maxLockLevel is less than 1
*/
  -public GenericLockManager(int maxLockLevel, LoggerFacade logger, long 
timeoutMSecs)
  -throws IllegalArgumentException {
  +public GenericLockManager(int maxLockLevel, LoggerFacade logger, long 
timeoutMSecs,
  +long checkThreshholdMSecs) throws IllegalArgumentException {
   if (maxLockLevel < 1)
   throw new IllegalArgumentException("The maximum lock level must 
be at least 1 ("
   + maxLockLevel + " was specified)");
   this.maxLockLevel = maxLockLevel;
   this.logger = logger.createLogger("Locking");
   this.globalTimeoutMSecs = timeoutMSecs;
  +this.checkThreshhold = checkThreshholdMSecs;
  +}
  +
  +public GenericLockManager(int maxLockLevel, LoggerFacade logger, long 
timeoutMSecs)
  +throws IllegalArgumentException {
  +this(maxLockLevel, logger, timeoutMSecs, DEFAULT_CHECK_THRESHHOLD);
   }
   
   public GenericLockManager(int maxLockLevel, LoggerFacade logger)
  @@ -82,10 +100,24 @@
   this(maxLockLevel, logger, DEFAULT_TIMEOUT);
   }
   
  +
  +public void setGlobalTimeout(Object ownerId, long timeoutMSecs) {
  +long now = System.currentTimeMillis();
  +long timeout = now + timeoutMSecs;
  +globalTimeouts.put(ownerId, new Long(timeout));
  +}
  +
  +public long getGlobalTimeoutTime(Object ownerId) {
  +Long timeout = (Long) globalTimeouts.get(ownerId);
  +return timeout.longValue();
  +}
  +
   /**
* @see LockManager#tryLock(Object, Object, int, boolean)
*/
   public boolean tryLock(Object ownerId, Object resourceId, int 
targetLockLevel, boolean reentrant) {
  +timeoutCheck(ownerId);
  +
   GenericLock lock = (GenericLock) atomicGetOrCreateLock(resourceId);
   boolean acquired = lock.tryLock(ownerId, targetLockLevel,
   reentrant ? GenericLock.COMPATIBILITY_REENTRANT : 
GenericLock.COMPATIBILITY_NONE,
  @@ -111,6 +143,11 @@
   public void lock(Object ownerId, Object resourceId, int targetLockLevel, 
boolean reentrant,
   long timeoutMSecs) throws LockException {
   
  +timeoutCheck(ownerId);
  +
  +long now = System.currentTimeMillis();
  +long waitEnd = now + timeoutMSecs;
  +
   GenericLock lock = (GenericLock) atomic

DO NOT REPLY [Bug 31446] - [dbutils] Proposal for a set of new ResultSetHandlers

[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=31446


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2004-12-19 04:03 ---
I added a KeyedHandler based on your MapMapHandler but customizable for possible
implementations other than Maps.  Thanks for the test case!

-- 
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/dbutils project.xml

[dgraham]

dgraham 2004/12/18 18:59:49

  Modified:dbutils/xdocs changes.xml
   dbutils/src/test/org/apache/commons/dbutils
BaseTestCase.java
   dbutils  project.xml
  Added:   dbutils/src/test/org/apache/commons/dbutils/handlers
KeyedHandlerTest.java
   dbutils/src/java/org/apache/commons/dbutils/handlers
KeyedHandler.java
  Log:
  Added KeyedHandler to create a Map of Maps from a ResultSet.
  PR: 31446
  
  Revision  ChangesPath
  1.1  
jakarta-commons/dbutils/src/test/org/apache/commons/dbutils/handlers/KeyedHandlerTest.java
  
  Index: KeyedHandlerTest.java
  ===
  /*
   * 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.
   */
  package org.apache.commons.dbutils.handlers;
  
  import java.sql.SQLException;
  import java.util.Iterator;
  import java.util.Map;
  
  import org.apache.commons.dbutils.BaseTestCase;
  import org.apache.commons.dbutils.ResultSetHandler;
  
  public class KeyedHandlerTest extends BaseTestCase {
  
  public KeyedHandlerTest(String name) {
  super(name);
  }
  
  public void testHandle() throws SQLException {
  ResultSetHandler h = new KeyedHandler();
  
  Map results = (Map) h.handle(this.rs);
  
  assertNotNull(results);
  assertEquals(ROWS, results.size());
  
  Iterator iter = results.keySet().iterator();
  Map row = null;
  while (iter.hasNext()) {
  Object key = iter.next();
  assertNotNull(key);
  row = (Map) results.get(key);
  assertNotNull(row);
  assertEquals(COLS, row.keySet().size());
  }
  
  row = (Map) results.get("1");
  assertEquals("1", row.get("one"));
  assertEquals("2", row.get("TWO"));
  assertEquals("3", row.get("Three"));
  }
  
  public void testColumnIndexHandle() throws SQLException {
  ResultSetHandler h = new KeyedHandler(2);
  Map results = (Map) h.handle(this.rs);
  
  assertNotNull(results);
  assertEquals(ROWS, results.size());
  
  Iterator iter = results.keySet().iterator();
  Map row = null;
  while (iter.hasNext()) {
  Object key = iter.next();
  assertNotNull(key);
  row = (Map) results.get(key);
  assertNotNull(row);
  assertEquals(COLS, row.keySet().size());
  }
  
  row = (Map) results.get("5");
  assertEquals("4", row.get("one"));
  assertEquals("5", row.get("TWO"));
  assertEquals("6", row.get("Three"));
  }
  
  public void testColumnNameHandle() throws SQLException {
  ResultSetHandler h = new KeyedHandler("three");
  Map results = (Map) h.handle(this.rs);
  
  assertNotNull(results);
  assertEquals(ROWS, results.size());
  
  Iterator iter = results.keySet().iterator();
  Map row = null;
  while (iter.hasNext()) {
  Object key = iter.next();
  assertNotNull(key);
  row = (Map) results.get(key);
  assertNotNull(row);
  assertEquals(COLS, row.keySet().size());
  }
  
  row = (Map) results.get("6");
  assertEquals("4", row.get("one"));
  assertEquals("5", row.get("TWO"));
  assertEquals("6", row.get("Three"));
  }
  
  public void testEmptyResultSetHandle() throws SQLException {
  ResultSetHandler h = new KeyedHandler();
  Map results = (Map) h.handle(this.emptyResultSet);
  assertNotNull(results);
  assertTrue(results.isEmpty());
  }
  }
  
  
  1.1  
jakarta-commons/dbutils/src/java/org/apache/commons/dbutils/handlers/KeyedHandler.java
  
  Index: KeyedHandler.java
  ===
  /*
   * 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

DO NOT REPLY [Bug 31446] - [dbutils] Proposal for a set of new ResultSetHandlers

[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=31446


[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]




--- Additional Comments From [EMAIL PROTECTED]  2004-12-19 03:51 ---
*** Bug 32449 has been marked as a duplicate of this 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 32449] - [dbutils] Create handler to return a Map of Maps

[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=32449


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE




--- Additional Comments From [EMAIL PROTECTED]  2004-12-19 03:51 ---
Thanks for the code and idea but bug 31446 addresses this same issue and
provides a test case so I'm marking this as a duplicate.  I'll be committing the
code for bug 31446 soon.

*** This bug has been marked as a duplicate of 31446 ***

-- 
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/dbutils/src/test/org/apache/commons/dbutils/wrappers SqlNullCheckedResultSetTest.java

[dgraham]

dgraham 2004/12/18 18:42:24

  Modified:dbutils/src/test/org/apache/commons/dbutils/wrappers
SqlNullCheckedResultSetTest.java
  Log:
  Removed unnecessary casts.
  
  Revision  ChangesPath
  1.5   +13 -29
jakarta-commons/dbutils/src/test/org/apache/commons/dbutils/wrappers/SqlNullCheckedResultSetTest.java
  
  Index: SqlNullCheckedResultSetTest.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/dbutils/src/test/org/apache/commons/dbutils/wrappers/SqlNullCheckedResultSetTest.java,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- SqlNullCheckedResultSetTest.java  28 Feb 2004 00:12:24 -  1.4
  +++ SqlNullCheckedResultSetTest.java  19 Dec 2004 02:42:24 -  1.5
  @@ -290,24 +290,21 @@
* Tests the getFloat implementation.
*/
   public void testGetFloat() throws SQLException {
  -
  -assertEquals((float) 0, rs.getFloat(1), 0.0);
  +assertEquals(0, rs.getFloat(1), 0.0);
   assertTrue(rs.wasNull());
  -assertEquals((float) 0, rs.getFloat("column"), 0.0);
  +assertEquals(0, rs.getFloat("column"), 0.0);
   assertTrue(rs.wasNull());
   // Set what gets returned to something other than the default
  -float f = (float) 10.0;
  +float f = 10;
   rs2.setNullFloat(f);
   assertEquals(f, rs.getFloat(1), 0.0);
   assertEquals(f, rs.getFloat("column"), 0.0);
  -
   }
   
   /**
* Tests the getInt implementation.
*/
   public void testGetInt() throws SQLException {
  -
   assertEquals(0, rs.getInt(1));
   assertTrue(rs.wasNull());
   assertEquals(0, rs.getInt("column"));
  @@ -317,24 +314,21 @@
   rs2.setNullInt(i);
   assertEquals(i, rs.getInt(1));
   assertEquals(i, rs.getInt("column"));
  -
   }
   
   /**
* Tests the getLong implementation.
*/
   public void testGetLong() throws SQLException {
  -
  -assertEquals((long) 0, rs.getLong(1));
  +assertEquals(0, rs.getLong(1));
   assertTrue(rs.wasNull());
  -assertEquals((long) 0, rs.getLong("column"));
  +assertEquals(0, rs.getLong("column"));
   assertTrue(rs.wasNull());
   // Set what gets returned to something other than the default
  -long l = (long) 10;
  +long l = 10;
   rs2.setNullLong(l);
   assertEquals(l, rs.getLong(1));
   assertEquals(l, rs.getLong("column"));
  -
   }
   
   /**
  @@ -648,67 +642,58 @@
* Tests the setNullDouble implementation.
*/
   public void testSetNullDouble() throws SQLException {
  -
  -assertEquals((double) 0.0, rs2.getNullDouble(), 0.0);
  +assertEquals(0.0, rs2.getNullDouble(), 0.0);
   // Set what gets returned to something other than the default
  -double d = (double) 10.0;
  +double d = 10.0;
   rs2.setNullDouble(d);
   assertEquals(d, rs.getDouble(1), 0.0);
   assertEquals(d, rs.getDouble("column"), 0.0);
  -
   }
   
   /**
* Tests the setNullFloat implementation.
*/
   public void testSetNullFloat() throws SQLException {
  -
   assertEquals((float) 0.0, rs2.getNullFloat(), 0.0);
   // Set what gets returned to something other than the default
   float f = (float) 10.0;
   rs2.setNullFloat(f);
   assertEquals(f, rs.getFloat(1), 0.0);
   assertEquals(f, rs.getFloat("column"), 0.0);
  -
   }
   
   /**
* Tests the setNullInt implementation.
*/
   public void testSetNullInt() throws SQLException {
  -
   assertEquals(0, rs2.getNullInt());
  -assertEquals((int) 0, rs.getInt(1));
  +assertEquals(0, rs.getInt(1));
   assertTrue(rs.wasNull());
  -assertEquals((int) 0, rs.getInt("column"));
  +assertEquals(0, rs.getInt("column"));
   assertTrue(rs.wasNull());
   // Set what gets returned to something other than the default
  -int i = (int) 10;
  +int i = 10;
   rs2.setNullInt(i);
   assertEquals(i, rs.getInt(1));
   assertEquals(i, rs.getInt("column"));
  -
   }
   
   /**
* Tests the setNullLong implementation.
*/
   public void testSetNullLong() throws SQLException {
  -
  -assertEquals((long) 0, rs2.getNullLong());
  +assertEquals(0, rs2.getNullLong());
   // Set what gets returned to something other than the default
  -long l = (long) 10;
  +long l = 10;
   rs2.setNullLong(l);
   assertEquals(l, rs.getLong(1));
   assertEquals(l, rs.getLong("column"));
  -
   }
   
   /**
* Tests the setNullObject implementation.
*/
   public void testSetNullObject() throws SQLExc

cvs commit: jakarta-commons/dbutils/src/test/org/apache/commons/dbutils/handlers ScalarHandlerTest.java

[dgraham]

dgraham 2004/12/18 18:38:19

  Modified:dbutils/src/test/org/apache/commons/dbutils/handlers
ScalarHandlerTest.java
  Log:
  Removed unnecessary casts to Object.
  
  Revision  ChangesPath
  1.4   +31 -41
jakarta-commons/dbutils/src/test/org/apache/commons/dbutils/handlers/ScalarHandlerTest.java
  
  Index: ScalarHandlerTest.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/dbutils/src/test/org/apache/commons/dbutils/handlers/ScalarHandlerTest.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- ScalarHandlerTest.java28 Feb 2004 00:12:23 -  1.3
  +++ ScalarHandlerTest.java19 Dec 2004 02:38:19 -  1.4
  @@ -20,47 +20,37 @@
   import org.apache.commons.dbutils.BaseTestCase;
   import org.apache.commons.dbutils.ResultSetHandler;
   
  -/**
  - * ScalarHandlerTest
  - */
   public class ScalarHandlerTest extends BaseTestCase {
   
  - /**
  -  * Constructor for ScalarHandlerTest.
  -  */
  - public ScalarHandlerTest(String name) {
  - super(name);
  - }
  -
  - public void testHandle() throws SQLException {
  - ResultSetHandler h = new ScalarHandler();
  - Object results = (Object) h.handle(this.rs);
  -
  - assertNotNull(results);
  - assertEquals("1", results);
  - }
  -
  - public void testColumnIndexHandle() throws SQLException {
  - ResultSetHandler h = new ScalarHandler(2);
  - Object results = (Object) h.handle(this.rs);
  -
  - assertNotNull(results);
  - assertEquals("2", results);
  - }
  -
  - public void testColumnNameHandle() throws SQLException {
  - ResultSetHandler h = new ScalarHandler("THree");
  - Object results = (Object) h.handle(this.rs);
  -
  - assertNotNull(results);
  - assertEquals("3", results);
  - }
  -
  - public void testEmptyResultSetHandle() throws SQLException {
  - ResultSetHandler h = new ScalarHandler();
  - Object results = (Object) h.handle(this.emptyResultSet);
  +public ScalarHandlerTest(String name) {
  +super(name);
  +}
  +
  +public void testHandle() throws SQLException {
  +ResultSetHandler h = new ScalarHandler();
  +Object results = h.handle(this.rs);
  +assertNotNull(results);
  +assertEquals("1", results);
  +}
  +
  +public void testColumnIndexHandle() throws SQLException {
  +ResultSetHandler h = new ScalarHandler(2);
  +Object results = h.handle(this.rs);
  +assertNotNull(results);
  +assertEquals("2", results);
  +}
  +
  +public void testColumnNameHandle() throws SQLException {
  +ResultSetHandler h = new ScalarHandler("THree");
  +Object results = h.handle(this.rs);
  +assertNotNull(results);
  +assertEquals("3", results);
  +}
  +
  +public void testEmptyResultSetHandle() throws SQLException {
  +ResultSetHandler h = new ScalarHandler();
  +Object results = h.handle(this.emptyResultSet);
  +assertNull(results);
  +}
   
  - assertNull(results);
  - }
  -
  -}
  +}
  \ No newline at end of file
  
  
  

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

Re: Jakarta Commons Structure rehashed

[Martin Cooper]

On Sat, 18 Dec 2004 20:34:47 -0500, Henri Yandell <[EMAIL PROTECTED]> wrote:
> Use case for wanting to get all tags and branches for one component is
> promotion from sandbox->proper, proper->jakarta, jakarta->TLP. Or the
> opposite, which I hesitate to call demotion :)

Yah, good point. Then I guess I like Option A as long as someone can
come up with a viable way of checking out all the trunks at once.

--
Martin Cooper


> Hen
> 
> 
> On Sat, 18 Dec 2004 14:13:49 -0800, Martin Cooper <[EMAIL PROTECTED]> wrote:
> > On Sat, 18 Dec 2004 21:22:12 +0100, Emmanuel Bourg <[EMAIL PROTECTED]> 
> > wrote:
> > > Tim O'Brien wrote:
> > > > Not following this one, this implies that ASF has one trunk.  Even
> > > > though copies are cheap I wouldn't want to create a copy of the entire
> > > > SVN tree for every release.
> > >
> > > Err I thought Jakarta would have its own SVN repository, thus the trunk
> > > would be "Jakata-wide" and not "ASF-wide".
> >
> > No, as Noel indicated, the repo is ASF-wide.
> >
> > > Also I don't think we have to
> > > copy the entire tree when tagging/branching, the copy just the component
> > > tree :
> > >
> > > tags/
> > > digester-1.8/
> > > commons/
> > > digester/
> > > configuration-1.1/
> > > commons/
> > > configuration/
> >
> > If this works, this might be a very good option. (I have no reason to
> > think it wouldn't work, but I don't know SVN well enough to be sure
> > one way or the other.) It would make it simple to check out everything
> > in Commons, and easy to tag and branch. The only disadvantage I can
> > think of is that it wouldn't be easy to get all tags and branches for
> > just one component, but I'm not sure I see a use case for that anyway.
> >
> > --
> > Martin Cooper
> >
> >
> > > Emmanuel Bourg
> > >
> > >
> > >
> > 
> > -
> > 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: Jakarta Commons Structure rehashed

[Henri Yandell]

Use case for wanting to get all tags and branches for one component is
promotion from sandbox->proper, proper->jakarta, jakarta->TLP. Or the
opposite, which I hesitate to call demotion :)

Hen


On Sat, 18 Dec 2004 14:13:49 -0800, Martin Cooper <[EMAIL PROTECTED]> wrote:
> On Sat, 18 Dec 2004 21:22:12 +0100, Emmanuel Bourg <[EMAIL PROTECTED]> wrote:
> > Tim O'Brien wrote:
> > > Not following this one, this implies that ASF has one trunk.  Even
> > > though copies are cheap I wouldn't want to create a copy of the entire
> > > SVN tree for every release.
> >
> > Err I thought Jakarta would have its own SVN repository, thus the trunk
> > would be "Jakata-wide" and not "ASF-wide".
> 
> No, as Noel indicated, the repo is ASF-wide.
> 
> > Also I don't think we have to
> > copy the entire tree when tagging/branching, the copy just the component
> > tree :
> >
> > tags/
> > digester-1.8/
> > commons/
> > digester/
> > configuration-1.1/
> > commons/
> > configuration/
> 
> If this works, this might be a very good option. (I have no reason to
> think it wouldn't work, but I don't know SVN well enough to be sure
> one way or the other.) It would make it simple to check out everything
> in Commons, and easy to tag and branch. The only disadvantage I can
> think of is that it wouldn't be easy to get all tags and branches for
> just one component, but I'm not sure I see a use case for that anyway.
> 
> --
> Martin Cooper
> 
> 
> > Emmanuel Bourg
> >
> >
> >
> 
> -
> 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]

cvs commit: jakarta-commons/dbutils project.xml

[dgraham]

dgraham 2004/12/18 17:22:55

  Modified:dbutils  project.xml
  Log:
  Added Markus Khouri to list of contributors for bug 32414.
  
  Revision  ChangesPath
  1.18  +9 -0  jakarta-commons/dbutils/project.xml
  
  Index: project.xml
  ===
  RCS file: /home/cvs/jakarta-commons/dbutils/project.xml,v
  retrieving revision 1.17
  retrieving revision 1.18
  diff -u -r1.17 -r1.18
  --- project.xml   1 Nov 2004 03:08:11 -   1.17
  +++ project.xml   19 Dec 2004 01:22:55 -  1.18
  @@ -136,6 +136,15 @@
 
   
   
  +  Markus Khouri
  +  
  +  [EMAIL PROTECTED]
  +  
  +  
  +Documentation
  +  
  +
  +
 Corby Page
 
 
  
  
  

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

DO NOT REPLY [Bug 32414] - [dbutils] Updated docs for example.html page (select AS)

[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=32414


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2004-12-19 02:16 ---
Fixed.

-- 
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/dbutils/xdocs examples.xml

[dgraham]

dgraham 2004/12/18 17:15:33

  Modified:dbutils/xdocs examples.xml
  Log:
  Added tips for mapping strange column names to bean properties.
  PR: 32414
  
  Revision  ChangesPath
  1.7   +20 -0 jakarta-commons/dbutils/xdocs/examples.xml
  
  Index: examples.xml
  ===
  RCS file: /home/cvs/jakarta-commons/dbutils/xdocs/examples.xml,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- examples.xml  19 Mar 2004 00:25:39 -  1.6
  +++ examples.xml  19 Dec 2004 01:15:33 -  1.7
  @@ -149,6 +149,26 @@
   your application.  The provided implementation delegates datatype conversion 
to 
   the JDBC driver.
   
  +
  +BeanProcessor maps columns to bean properties as documented in the 
  +BeanProcessor.toBean()
 javadoc.  
  +Column names must match the bean's property names case insensitively.  
  +For example, the firstname column would be stored in the bean 
  +by calling its setFirstName() method.  However, many database 
  +column names include characters that either can't be used or are not 
typically 
  +used in Java method names.  You can do one of the following to map 
  +these columns to bean properties:
  +
  +
  +Alias the column names in the SQL so they match the Java names:  
  +select social_sec# as socialSecurityNumber from person
  +
  +
  +Subclass BeanProcessor and override the mapColumnsToProperties()
 
  +method to strip out the offending characters.
  +
  +
  +
   
   
   
  
  
  

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

[jira] Updated: (JELLY-178) jetty tag lib can't be used with jetty 5.0

[Marc DeXeT (JIRA)]

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

Marc DeXeT updated JELLY-178:
-

Attachment: patch.jetty.passage.5.0.-2.txt

Patch with updated build.xml.
All unit tests go through.

> jetty tag lib can't  be used with jetty 5.0
> ---
>
>  Key: JELLY-178
>  URL: http://nagoya.apache.org/jira/browse/JELLY-178
>  Project: jelly
> Type: New Feature
> Versions: 1.0-beta-5
>  Environment: JDK 1.4.2_04 XP
> Reporter: Marc DeXeT
>  Attachments: patch.jetty.passage.5.0.-2.txt
>
> Jetty tag lib uses deprecated feature in jetty 5.0 like 
> "org.mortbay.http.SecurityConstraint.Authenticator"
> and some more.

-- 
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: Commons Mapper: scope/roadmap?

[David Graham]

--- Max Rudman <[EMAIL PROTECTED]> wrote:

> 
> On Dec 17, 2004, at 8:52 PM, David Graham wrote:
> 
> > There aren't any reusable implementations that I can think of.  What
> do
> > you picture the Hibernate mapper implementation looking like?
> Well, I am not too familiar with other O/R implementations but at least 
> in Hibernate you don't need a separate Data Access Object (DAO) 
> implementation for each value object. Everything needed to persist and 
> load Person is captured in Person.hbm.xml mapping file.
> 
> What I have in mind for Hibernate implementation is HibernateMapper 
> class which will hold on to Hibernate Session object and Class of the 
> entity being persisted. HibernateMapperFactory then would simply pass 
> through entity class to the Mapper so it can in turn use it in its 
> calls to Hibernate Session. It would look something like this:
> 
> public class HibernateMapper implements Mapper {
>private net.sf.hibernate.Session session;
>private Class type;
> 
>public HibernateMapper(Session session, Class type) {
>  this.session = session;
>  this.type = type;
>}
> 
>public Object findByUniqueId(Object id) {
>  return session.get(type, id);
>}
> 
>.
> 
> }
> 
> This is probably very oversimplified and there is a fair amount of 
> "housekeeping" code; hence, the value of providing an implementation as 
> part of the Mapper project instead of forcing users to re-invent the 
> wheel so to speak.
> 
> In addition, we could provide an implementation which works with Spring 
> Framework, for example, which is an IoC container I am very fond of. 
> That way, the whole MapperFactory configuration can be done out of XML 
> config files and provided to business logic classes in the "Injection 
> of Dependency" manner. As a bonus, Spring integrates with Hibernate to 
> provide automatic transaction management and such.
> 
> I imagine something similar can be done for other O/R frameworks; I am 
> just not familiar enough with them to give you more details.
> 
> > Mapper really saved me on one project where we designed a new db
> schema
> > and wrote a bunch of code to access it and then mgmt. decided to use 
> > the
> > old schema at the last minute.  All I had to do was implement the 
> > mappers
> > differently and the rest of the app. never changed.
> 
> I agree, O/R tools are great but being able to switch to a different DB 
> schema is a virtue of the O/R mapping tool itself not the abstraction 
> API like Mapper. In other words, it seems to me I could have achieved 
> the same result by using Hibernate directly as opposed to hard-coding 
> DB schema in JDBC calls. 

In my particular example certain tables did not exist in the old schema so
I had to simulate them with XML files.  The mapper implementation read
from XML instead of the database.  Hibernate is a wonderful tool but it
needs database tables :-).

> If I understood the project's goal correctly, 
> it is to abstract various O/R implementations in a manner similar to 
> how Commons Logging abstracts various Logging implementations.

The idea behind Mapper is insulating the application from the details of
data retrieval including SQL, HQL, etc.  The app. just calls
PersonMapper.findByFirstName() and the implementation uses SQL, HQL, or
queries XML as needed.  The implementation may not be using a relational
database at all.

David

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


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

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

Re: [jelly] commons-jelly-SNAPSHOT.jar on ibilio is old ?

[Brett Porter]

Paul Libbrecht wrote:
Hi,
I thought there was an automatic communication between the Gump runs 
and the ibiblio repository ?
Nope
In any cases, currently, the state of the build at
http://brutus.apache.org/gump/public/jakarta-commons/commons-jelly/
is success but the jar on 
http://www.ibiblio.org/maven/commons-jelly/jars/ seems to be of 
september and the last file there is RC1!

Who can explain or help on this ?
SNAPSHOT actually shouldn't be there. As far as the ASF repo goes, it 
has been recommended to use http://cvs.apache.org/repository for 
SNAPSHOTs and http://www.apache.org/dist/java-repository/ for releases 
(Which is mirrored to ibiblio).

As far as Maven goes, we are discussing actually codifying separate 
repositories for snapshots and releases, but haven't resolved it 
completely yet. Of course, you are able to do this by picking the 
appropriate properties depending on the release type, eg:
http://svn.apache.org/viewcvs.cgi/maven/maven-1/plugins/trunk/plugin-parent/project.properties?rev=116299&view=markup
then run
maven -Dmaven.repo.list=apachecvs jar:deploy-snapshot
for example.

As far as correcting it on ibiblio - it can be updated by dropping it 
into java-repository, or a decision made to remove it. I'm not sure if 
deletes are propogated - if not, then we can help you out - probably 
best to make a "MAVENUPLOAD" JIRA request.

Cheers,
Brett

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

cvs commit: jakarta-commons/transaction project.xml

[ozeigermann]

ozeigermann2004/12/18 15:23:43

  Modified:transaction project.xml
  Log:
  Added Antranig Basman to the contributors
  
  Revision  ChangesPath
  1.5   +7 -0  jakarta-commons/transaction/project.xml
  
  Index: project.xml
  ===
  RCS file: /home/cvs/jakarta-commons/transaction/project.xml,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- project.xml   17 Dec 2004 12:09:32 -  1.4
  +++ project.xml   18 Dec 2004 23:23:43 -  1.5
  @@ -98,6 +98,13 @@
   
 
 
  +  
  +
  +  Antranig Basman
  +
  +  
  +
  +
 
   
 geronimo-spec
  
  
  

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

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

[Scott Deboy]

Enter and exit should not be defined as severities.  This is useful 
information, but orthogonal to a logging event's severity attribute.

One way to provide entry/exit information is to overload the logger methods to 
take a map, and require the user to adhere to use-case specific conventions for 
keys and values.

For example, to track entry and exit as we cross component boundaries, these 
entries might be sufficient to identify an event:

Key Name Value
-
boundary.type component
boundary.stateentry

Similarly, to track entry and exit as we cross class boundaries:

Key Name Value
-
boundary.type class
boundary.stateexit

This provides a general mechanism for extending what information an event 
provides - without codifying use-case specific attributes as methods in 
commons-logging.

Again, the user would be responsible for conforming to naming conventions for 
the map entries (possibly with the aid of helper methods to build the map) in 
order to discover these use-case specific events.


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

cvs commit: jakarta-commons/transaction/src/java/org/apache/commons/transaction/file JDK14URLEncodeIdMapper.java ResourceIdToPathMapper.java URLEncodeIdMapper.java FileResourceManager.java

[ozeigermann]

ozeigermann2004/12/18 15:19:09

  Modified:transaction build.xml RELEASE-NOTES.txt
   transaction/src/java/org/apache/commons/transaction/file
FileResourceManager.java
  Added:   transaction/src/java/org/apache/commons/transaction/file
JDK14URLEncodeIdMapper.java
ResourceIdToPathMapper.java URLEncodeIdMapper.java
  Log:
  Added support for configurable resource id to path mapping as
  proposed by Antranig Basman
  
  Revision  ChangesPath
  1.9   +2 -1  jakarta-commons/transaction/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/jakarta-commons/transaction/build.xml,v
  retrieving revision 1.8
  retrieving revision 1.9
  diff -u -r1.8 -r1.9
  --- build.xml 17 Dec 2004 12:09:32 -  1.8
  +++ build.xml 18 Dec 2004 23:19:08 -  1.9
  @@ -155,13 +155,14 @@
 === 
 -->
   
  -  
  +  
   
 
  +  
 
 
   
  
  
  
  1.8   +6 -2  jakarta-commons/transaction/RELEASE-NOTES.txt
  
  Index: RELEASE-NOTES.txt
  ===
  RCS file: /home/cvs/jakarta-commons/transaction/RELEASE-NOTES.txt,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- RELEASE-NOTES.txt 17 Dec 2004 00:33:38 -  1.7
  +++ RELEASE-NOTES.txt 18 Dec 2004 23:19:08 -  1.8
  @@ -27,16 +27,20 @@
   ENHANCEMENTS FROM 1.0
   -
   
  +Locking:
   - Extended and less excentric lock manager
  -- Deadlock detection for all lock managers, file store, and pessimistic map
  -- Flexible preference mechanism 
   
  +File:
  +- Confiburable resource id to path mapping
   
   NEW FEATURES FROM 1.0
   -
   
  +Locking:
   - new ReadWriteLockManager for most intuitive read/write lock usage
   - new read/write/upgrade locking mechanism
  +- Deadlock detection for all lock managers, file store, and pessimistic map
  +- Flexible preference locking mechanism 
   
   MINOR INCOMPATIBILITIES TO 1.0
   -
  
  
  
  1.5   +29 -25
jakarta-commons/transaction/src/java/org/apache/commons/transaction/file/FileResourceManager.java
  
  Index: FileResourceManager.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/transaction/src/java/org/apache/commons/transaction/file/FileResourceManager.java,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- FileResourceManager.java  16 Dec 2004 17:33:53 -  1.4
  +++ FileResourceManager.java  18 Dec 2004 23:19:09 -  1.5
  @@ -34,8 +34,6 @@
   import java.io.InputStreamReader;
   import java.io.OutputStream;
   import java.io.OutputStreamWriter;
  -import java.io.UnsupportedEncodingException;
  -import java.net.URLEncoder;
   import java.util.ArrayList;
   import java.util.Collection;
   import java.util.HashMap;
  @@ -44,7 +42,6 @@
   import java.util.Iterator;
   import java.util.Collections;
   
  -import org.apache.commons.codec.binary.Base64;
   import org.apache.commons.transaction.locking.GenericLock;
   import org.apache.commons.transaction.locking.GenericLockManager;
   import org.apache.commons.transaction.locking.LockException;
  @@ -185,7 +182,6 @@
   
   protected String workDir;
   protected String storeDir;
  -protected boolean urlEncodePath = false;
   protected boolean cleanUp = true;
   protected boolean dirty = false;
   protected int operationMode = OPERATION_MODE_STOPPED;
  @@ -197,6 +193,8 @@
   protected Map globalTransactions;
   protected List globalOpenResources;
   protected LockManager lockManager;
  +
  +protected ResourceIdToPathMapper idMapper = null;
   
   /*
* --- ctor and general getter / setter methods ---
  @@ -231,11 +229,29 @@
   boolean urlEncodePath,
   LoggerFacade logger,
   boolean debug) {
  +this(storeDir, workDir, urlEncodePath ? new URLEncodeIdMapper() : 
null, logger, false);
  +}
  +
  +/**
  + * Creates a new resouce manager operation on the specified directories.
  + * 
  + * @param storeDir directory where main data should go after commit
  + * @param workDir directory where transactions store temporary data 
  + * @param idMapper mapper for resourceId to path
  + * @param logger the logger to be used by this store
  + * @param debug if set to true logs all locking information 
to "transaction.log" for debugging inspection 
  + */
  +public FileResourceManager(
  +String storeDir,
  +String workDir,
  +ResourceIdToPathMapper idMapper,
  +LoggerFacade logger,
  +boolean debug) {
   this.workDir = workDir;
   this.

[jelly] commons-jelly-SNAPSHOT.jar on ibilio is old ?

[Paul Libbrecht]

Hi,
I thought there was an automatic communication between the Gump runs 
and the ibiblio repository ?
In any cases, currently, the state of the build at
http://brutus.apache.org/gump/public/jakarta-commons/commons-jelly/
is success but the jar on 
http://www.ibiblio.org/maven/commons-jelly/jars/ seems to be of 
september and the last file there is RC1!

Who can explain or help on this ?
thanks
paul
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-commons/transaction/src/test/org/apache/commons/transaction/locking GenericLockTest.java

[ozeigermann]

ozeigermann2004/12/18 15:15:08

  Modified:transaction/src/test/org/apache/commons/transaction/locking
GenericLockTest.java
  Log:
  Minor
  
  Revision  ChangesPath
  1.6   +5 -5  
jakarta-commons/transaction/src/test/org/apache/commons/transaction/locking/GenericLockTest.java
  
  Index: GenericLockTest.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/transaction/src/test/org/apache/commons/transaction/locking/GenericLockTest.java,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- GenericLockTest.java  17 Dec 2004 16:37:07 -  1.5
  +++ GenericLockTest.java  18 Dec 2004 23:15:08 -  1.6
  @@ -417,7 +417,7 @@
   
   for (int i = 0; i < CONCURRENT_TESTS; i++) {
   
  -System.out.print(".");
  +//System.out.print(".");
   
   Thread t1 = new Thread(new Runnable() {
   public void run() {
  
  
  

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

commons-beanutils-1.6.1 fails with junit test

[Jan Brinkmann]

Hi,

I'm currently trying to figure out why the commons-beanutils 1.6.1 
release fails while doing junit tests. Maybe someone on this list
can help me. See the following output:

What can I do to fix this?

compile.tests:
[javac] Compiling 42 source files to 
/var/tmp/portage/commons-beanutils-1.6.1-r1/work/commons-beanutils-1.6.1-src/target/tests
[javac] 
/var/tmp/portage/commons-beanutils-1.6.1-r1/work/commons-beanutils-1.6.1-src/src/test/org/apache/commons/beanutils/PropertyUtilsTestCase.java:1694:
 warning: non-varargs call of varargs method with inexact argument type for 
last parameter;
[javac] cast to java.lang.Object for a varargs call
[javac] cast to java.lang.Object[] for a non-varargs call and to suppress 
this warning
[javac] value = reader.invoke(beanPrivate, new Class[0]);
[javac]^
[javac] 
/var/tmp/portage/commons-beanutils-1.6.1-r1/work/commons-beanutils-1.6.1-src/src/test/org/apache/commons/beanutils/PropertyUtilsTestCase.java:3453:
 warning: non-varargs call of varargs method with inexact argument type for 
last parameter;
[javac] cast to java.lang.Object for a varargs call
[javac] cast to java.lang.Object[] for a non-varargs call and to suppress 
this warning
[javac] reader.invoke(bean, new Class[0]);
[javac] ^
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[javac] 2 warnings

test.basic.dynabean:
 [echo] Running BasicDynaBean tests ...
 [java] ...
 [java] Time: 0.113

 [java] OK (35 tests)


test.wrap.dynabean:
 [echo] Running WrapDynaBean tests ...
 [java] ...
 [java] Time: 0.081

 [java] OK (35 tests)


test.dyna.property:
 [echo] Running DynaBean PropertyUtils tests ...
 [java] .
 [java] ..
 [java] Time: 0.117

 [java] OK (55 tests)


test.property:
 [echo] Running PropertyUtils tests ...
 [java] .
 [java] .
 [java] ..
 [java] Time: 0.223

 [java] OK (88 tests)


test.dyna.bean:
 [echo] Running DynaBean BeanUtils tests ...
 [java] ..
 [java] Time: 0.148

 [java] OK (26 tests)


test.bean:
 [echo] Running BeanUtils tests ...
 [java] ..
 [java] Time: 0.162

 [java] OK (34 tests)


test.convert:
 [echo] Running ConvertUtils tests ...
 [java] .
 [java] Time: 0.103

 [java] OK (9 tests)


test.method:
 [echo] Running MethodUtils tests ...
 [java] 
 [java] Time: 0.053

 [java] OK (8 tests)


test.dyna.result:
 [echo] Running DynaBean ResultSet tests ...
 [java] ..
 [java] Time: 0.032

 [java] OK (6 tests)


test.dyna.row:
 [echo] Running DynaBean RowSet tests ...
 [java] ..
 [java] Time: 0.041

 [java] OK (6 tests)


test.bean.comparator:
 [echo] Running BeanComparator tests ...
 [java] ...F.
 [java] Time: 0.079
 [java] There was 1 failure:
 [java] 1) 
testCompareOnBooleanProperty(org.apache.commons.beanutils.BeanComparatorTestCase)junit.framework.AssertionFailedError:
 BeanComparator should throw an exception when comparing two booleans.
 [java] at 
org.apache.commons.beanutils.BeanComparatorTestCase.testCompareOnBooleanProperty(BeanComparatorTestCase.java:260)
 [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 [java] at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 [java] at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

 [java] FAILURES!!!
 [java] Tests run: 8,  Failures: 1,  Errors: 0


BUILD FAILED
/var/tmp/portage/commons-beanutils-1.6.1-r1/work/commons-beanutils-1.6.1-src/build.xml:424:
 Java returned: 1

Total time: 9 seconds


Any ideas ? 


-- Jan


pgpY8CBSYZGB3.pgp
Description: PGP signature

Re: Jakarta Commons Structure rehashed

[Martin Cooper]

On Sat, 18 Dec 2004 21:22:12 +0100, Emmanuel Bourg <[EMAIL PROTECTED]> wrote:
> Tim O'Brien wrote:
> > Not following this one, this implies that ASF has one trunk.  Even
> > though copies are cheap I wouldn't want to create a copy of the entire
> > SVN tree for every release.
> 
> Err I thought Jakarta would have its own SVN repository, thus the trunk
> would be "Jakata-wide" and not "ASF-wide".

No, as Noel indicated, the repo is ASF-wide.

> Also I don't think we have to
> copy the entire tree when tagging/branching, the copy just the component
> tree :
> 
> tags/
> digester-1.8/
> commons/
> digester/
> configuration-1.1/
> commons/
> configuration/

If this works, this might be a very good option. (I have no reason to
think it wouldn't work, but I don't know SVN well enough to be sure
one way or the other.) It would make it simple to check out everything
in Commons, and easy to tag and branch. The only disadvantage I can
think of is that it wouldn't be easy to get all tags and branches for
just one component, but I'm not sure I see a use case for that anyway.

--
Martin Cooper


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

[Richard Sitze]

Developers of open source components that are expected to be plugged into 
different projects simply cannot and should not assume that Log4J, JSR-47, 
Avalon, or any other logger IS present.  This may severely limit the 
logging capabilities that may be used by such components.  This is the 
price we pay to be able to go into a customers shop, install an open 
source solution, and map the logger to their own internal infrastructure 
with minimal code overhead AND minimal impact on their deployment and 
administrative processes.

It's good to know Log4J is growing so strongly, it is an excellent 
project.  I've enjoyed using it myself a few times.


Ceki Gülcü <[EMAIL PROTECTED]> wrote on 12/18/2004 11:34:14 AM:

> At 05:44 PM 12/18/2004, Matt Sgarlata wrote:
> >Noel J. Bergman wrote:
> >>
> >>Actually, I agree.  I'd prefer to see that semantic state encoded in 
the log
> >>message, which I feel is much cleaner.
> >> --- Noel
> >
> >+1.  Just because the JDK 1.4 log does this, doesn't mean that we have 
to 
> >enforce this behavior on all logging implementations.  Why not just 
leave 
> >it generic?  If someone wants enter/exit methods, they can define their 
own:
> >
> >public static void enter(Log log, Class clazz, String method);
> >public static void exit(Log log, Class clazz, String method);
> >
> >Personally, I am against introducing logging that is more specific than 

> >TRACE.  In practice, I think it's hard to explain even the distinction 
> >between TRACE and DEBUG (i.e. - the projects I've seen tend to use one 
or 
> >the other almost exclusively if they're not using INFO or higher for 
the 
> >message).  Again, just because JDK 1.4 offers FINEST, FINER doesn't 
mean 
> >JCL has to.  What happens when the next implementation comes along that 

> >offers 42 different logging levels, including TINY, VERYTINY, 
> >EXTREMLYTINY, TINIEST, SUPPERTINY and SPLITTINGHAIRS logging levels?
> 
> Log4j version 1.4 or 2.0 is likely to introduce the notion of multiple
> domains for categorizing logging statements. When that happens, the
> notion of logging levels will be looked at very differently.
> 
> Commons-logging promises to abstract different logging APIs such as
> log4j, Avalon logkit and java.util.logging API. However, such a task
> is near impossible to fulfill, while Avalon Logkit is nowhere to be
> seen. In the history of software, no one has ever managed to abstract
> competing and divergent APIs without their active cooperation. Chances
> are it won't happen this time around either.
> 
> User who currently use commons-logging are likely to go through a
> lengthy and painful conversion process when they realize that log4j
> offers must-have features.
> 
> 
> >Matt
> 
> -- 
> Ceki Gülcü
> 
>The complete log4j manual: http://qos.ch/log4j/
> 
> 
> 
> -
> 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]

[Jakarta Commons Wiki] Updated: SubversionConversion

[commons-dev]

   Date: 2004-12-18T11:39:36
   Editor: 67.160.210.111 <>
   Wiki: Jakarta Commons Wiki
   Page: SubversionConversion
   URL: http://wiki.apache.org/jakarta-commons/SubversionConversion

   A couple of minor textual fixups.

Change Log:

--
@@ -43,7 +43,7 @@
  subsequently been moved out of the sandbox.  Two examples include
  jakarta-commons-sandbox/altrmi which is no longer a part of the
  commons and jakarta-commons-sandbox/digester which was promoted to
- the commons proper three years ago. We would prefer to perserve
+ the commons proper three years ago. We would prefer to preserve
  history and remove these components from Subversion ourselves.
 
  We would also like to preserve the .cvsignore files spread throughout
@@ -71,7 +71,6 @@
   /site/   (only HEAD, commons-build had no tags or branches)
 
  2: convert only the files in jakarta-commons/ to SVN without copying
-
  subdirectories.  Only HEAD of the following files ".cvsignore",
  "BUILD_DOCS.txt", "LICENSE", "LICENSE.txt", "anakia-project.xml",
  "build.properties.sample", "build.xml", and "charter.xml"
@@ -90,7 +89,6 @@
  "attributes" is used as an example, but this process needs to be
  completed for the following subdirectories of jakarta-commons: (Note:
  commons-build is duplicated - some projects may still have a lateral
-
  dependency on commons-build)
 
attributes/

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

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

[Curt Arnold]

On Dec 18, 2004, at 2:18 PM, Richard Sitze wrote:
+1.  Just because the JDK 1.4 log does this, doesn't mean that we have
to enforce this behavior on all logging implementations.  Why not just
leave it generic?  If someone wants enter/exit methods, they can 
define
their own:

public static void enter(Log log, Class clazz, String method);
public static void exit(Log log, Class clazz, String method);
The proposal is for more than a the simple helper methods, it is for 
the
[potential] underlying implementation below.  Where possible, these 
SHOULD
be mapped to a finer level than 'debug', but not as fine as 'trace'.

By naming them 'enter/exit' instead of 'finer', we encourage their use 
in
a particular fashion...  if you feel that such strong "best-practice"
enforcement is inappropriate, then let's not throw the dog [and I know
it's a dog ;)] out with the bath water.

We'd like at least one more trace level, see below.

Maybe the tension is a manifestation of the problem of trying to assign 
one common severity to entering and exiting messages.  Some entries 
have to be more significant than others, the only mechanism to 
distinguish them in the JSR-47 is to not instrument the less 
significant entry points.

Maybe adding a
entering(Level level, String...)
The JSR-47 adapter could map this the JSR's entering if level was the 
equivalent of FINER or lower and fabricate a similar message if the 
level were higher than finer.

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

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

[Curt Arnold]

On Dec 18, 2004, at 12:24 PM, Richard Sitze wrote:
As you pointed out earlier, much of this depends on how the logger is
used.  Class category names for code logging, other "application 
category"
logger names for the other would be a reasonable approach.

However, for our stated *GOAL*, JCL's primary purpose is for 
instrumenting
components that are expected to plug into larger 
applications/frameworks.
It's not clear to me what it means to start instrumenting such 
components
for "administrative" or "application" level logging events.  Not to 
say it
couldn't be done.  This is a "best-practice" issue for the most part...
something for the users guide.

If there are specific issues to be addressed by the API's, please raise
them?  Examples?  It's not clear to me what course of action you 
advocate.

I was trying to give examples that the localized messages are not 
needed because the system is "enterprise" level or because the message 
is significant, but due to the audience and nature of the message.  
Enterprise level systems may have more messages that need to be 
localized, but that doesn't mean that non-enterprise level systems 
would not benefit.

log4j and JSR-47 was designed and optimized for diagnostic logging, 
however they can be applied effectively for administrative logging.  
However when they do, there are some aspects (like localization) that 
may be lacking.  However if I was designed a system that needed 
configurable routing of administrative messages, then I could do worse 
than using log4j or JSR-47 and working within their constraints or 
evolving them.

There are a couple of issues with the resource bundle proposals that
I
have seen previously.  I haven't had time to review those presented
here so they may or may not apply.
Resource bundle approaches are sufficiently demanding of developers
that they will likely substantially reduce the density of diagnostic
messages if only a resource bundle approach is available.
What are our (simple) options.  Again remember that we expect to be a
thin-wrapper over existing log implementations.
Depends on the requirements.  All I have to go on is what was in the 
thread and there didn't seem to be a huge amount of elaboration.

If the requirement is to support localization of logging messages, then 
there are multiple ways of attacking that problem.  If the requirement 
is to provide a facade to mimic JSR-47's resource bundle approach, then 
that is very achievable, however I think it is likely to not be a 
deeply satisfactory solution to localizing logging messages without 
some accomodation in the implementations.

You seem to be arguing against [pervious statements in your original
post], and against [your new statements.  What is your point?
I am trying to say that the severity of the message is independent of 
the intended audience of the message and the need for localization.  
You can have an ERROR message targeted to a diagnostician that should 
be locale-neutral and a DEBUG message targeted to an administrator that 
needs to be localized.



If I was using a logging system to report, say
employee status to a store manager, an employee arriving or leaving
might be assigned an INFO status, i. e. lowest severity that is
typically reported.  If I was trying to diagnose a drop in
productivity, I might want to be able to configure that I should get
DEBUG severity events, like door swipes or cash register logins and I
would still want these in my preferred language.
Then the designer must be aware of the distinction between trace level
logging, as intended for application debugging, and for message level
logging.  Everything you describe is message level logging.
I think I'm starting to see where you are going with this... and would
start by arguing that "independent pluggable components" are not
necessarily the right place to start making assumptions of this sort, 
or
even the right place to be logging this level of information.
I was trying to provide reasonable use case sub-INFO severity message 
would need localization.

The primary requirements that drove log4j were diagnostic logging 
requirements and localization was not a significant design concern.  
Developers have applied in many uses, like administrative logging, that 
weren't in the initial set of requirements.  The questions is if these 
two types of "logging" are incompatible and need two distinct API's or 
if one API can acceptably handle both.

If you are saying that log4j and JCL should ignore requirements from 
people who are using it for administrative logging, then were are the 
requirements for localization coming.


That a single log request can be rendered for more than one locale
would either require having a localizable object passing through the
logging dispatch system, being able to translate the log request at 
the
appender or some other approach internal to the logging system.
Constructing a message using resource bundles and passing a rendered
message on to log4j 

[all] svn conversion instructions for infrastructure

[Tim O'Brien]

The first step to moving to SVN is telling infrastructure exactly what
we need.   The process is as follows:

1. We tell infrastructure what we need (and volunteer to help)

2. jakarta-commons and jakarta-commons-sandbox are migrated to a test
repository

3. If we are happy with what we have after a few days, we can perform
the migration to the real repository and lock the CVS module.

I have some experience with cvs2svn, but the instructions at
http://www.apache.org/dev simply call for a set of instructions which
I've included below.  Because we have an involved migration process I'll
volunteer to help infrastructure.

 Please review the conversion instructions here:
http://wiki.apache.org/jakarta-commons/SubversionConversion


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

cvs commit: jakarta-commons/transaction/src/java/org/apache/commons/transaction/locking GenericLock.java

[ozeigermann]

ozeigermann2004/12/18 12:02:05

  Modified:transaction/src/java/org/apache/commons/transaction/locking
GenericLock.java
  Log:
  Added simple means to count the number of waiters
  
  Revision  ChangesPath
  1.7   +39 -32
jakarta-commons/transaction/src/java/org/apache/commons/transaction/locking/GenericLock.java
  
  Index: GenericLock.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/transaction/src/java/org/apache/commons/transaction/locking/GenericLock.java,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- GenericLock.java  17 Dec 2004 16:36:21 -  1.6
  +++ GenericLock.java  18 Dec 2004 20:02:05 -  1.7
  @@ -140,7 +140,8 @@
   protected Map owners = new HashMap();
   private int maxLockLevel;
   protected LoggerFacade logger;
  -
  +protected int waiters = 0;
  +
   /**
* Creates a new lock.
* 
  @@ -280,36 +281,41 @@
+ System.currentTimeMillis());
   }
   
  -if (preferred) {
  -// while waiting we already make our claim we are 
next
  -LockOwner oldLock = null;
  -try {
  -// we need to remember it to restore it after 
waiting
  -oldLock = (LockOwner) owners.get(ownerId);
  -// this creates a new owner, so we do not need to
  -// copy the old one
  -setLockLevel(ownerId, null, targetLockLevel, 
preferred);
  -
  -// finally wait
  -wait(remaining);
  -
  -} finally {
  -// we need to restore the old lock in order not 
to
  -// interfere with the intention lock in the
  -// following check
  -// and not to have it in case of success either
  -// as there will be an ordinary lock then
  -if (oldLock != null) {
  -owners.put(ownerId, oldLock);
  -} else {
  -owners.remove(ownerId);
  +try {
  +waiters++;
  +if (preferred) {
  +// while waiting we already make our claim we 
are next
  +LockOwner oldLock = null;
  +try {
  +// we need to remember it to restore it 
after waiting
  +oldLock = (LockOwner) owners.get(ownerId);
  +// this creates a new owner, so we do not 
need to
  +// copy the old one
  +setLockLevel(ownerId, null, targetLockLevel, 
preferred);
  +
  +// finally wait
  +wait(remaining);
  +
  +} finally {
  +// we need to restore the old lock in order 
not to
  +// interfere with the intention lock in the
  +// following check
  +// and not to have it in case of success 
either
  +// as there will be an ordinary lock then
  +if (oldLock != null) {
  +owners.put(ownerId, oldLock);
  +} else {
  +owners.remove(ownerId);
  +}
   }
  +
  +} else {
  +wait(remaining);
   }
  -
  -} else {
  -wait(remaining);
  +} finally {
  +waiters--;
   }
  -
  +
   if (tryLock(ownerId, targetLockLevel, compatibility, 
preferred)) {
   
   if (logger.isFinerEnabled()) {
  @@ -401,6 +407,7 @@
   buf.append("- ").append(owner.ownerId.toString()).append(": 
").append(owner.lockLevel)
   .append(owner.intention ? " intention" : " 
acquired").append("\n");
   }
  +buf.append(waiters).append(" waiting\n");
   return buf.toString();
   
   }
  
  
  

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

RE: Jakarta Commons Structure rehashed

[Noel J. Bergman]

> I thought Jakarta would have its own SVN repository

Not a chance.

--- Noel

smime.p7s
Description: S/MIME cryptographic signature

Re: [configuration]XMLConfigurations

[Emmanuel Bourg]

Oliver Heger wrote:
I have now made HierarchicalXMLConfiguration fully compatible with 
XMLConfiugration. All tests for XMLConfiguration now run also with 
HierarchicalXMLConfiguration.
Well done !
A thing that bothers me a bit is the fact that it is not too trivial to 
implement all the features of file based configurations (e.g. auto save, 
constructors) for HierarchicalXMLConfiguration because it cannot inherit 
from AbstractFileConfiguration. Maybe someone comes up with a more 
elegant solution?
Maybe we could make it extend AbstractFileConfiguration and have a 
helper class working with hierarchical configurations to walk the tree. 
That is how I implemented my TreeConfiguration prototype but I don't 
know if it would work well with HierarchicalConfiguration.


If noone objects I will now go ahead and make 
HierarchicalXMLConfiguration the one and only XMLConfiguration we have.
It's ok for me.
Emmanuel Bourg


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Jakarta Commons Structure rehashed

[Emmanuel Bourg]

Tim O'Brien wrote:
Not following this one, this implies that ASF has one trunk.Even
though copies are cheap I wouldn't want to create a copy of the entire
SVN tree for every release.
Err I thought Jakarta would have its own SVN repository, thus the trunk 
would be "Jakata-wide" and not "ASF-wide". Also I don't think we have to 
copy the entire tree when tagging/branching, the copy just the component 
tree :

tags/
digester-1.8/
commons/
digester/
configuration-1.1/
commons/
configuration/
Emmanuel Bourg


smime.p7s
Description: S/MIME Cryptographic Signature

RE: [logging] ECL: pluggable message resolution

[Richard Sitze]

[forgive me for changing the subject, I'm trying to take steps to try to 
help us focus on separate issues]

"Noel J. Bergman" <[EMAIL PROTECTED]> wrote on 12/17/2004 09:10:34 PM:

> Richard Sitze wrote:
> 
> > As a real example, the axis community uses globalized messages.
> 
> A lot of products do, as I see on a regular basis, so I definitely 
support
> your interest in this feature.
> 
> However, I view logging as separate from content generation.  I'd like 
to
> see the mechanism pluggable.  That could be done by providing a message
> factory to the logging layer, so that it does the lookup rather than 
your
> example:
> 
> > log.error(Message.getMessage("MSGID", new String { arg1, ..., argN 
}));
> 
> Doing so would still permit your facade:
> 
>   log.error(this.getClass(), "thisMethodName", "MSGID", new String 
{...});
> 
> but the factory that the logger uses to construct the message would be
> pluggable and distinct from the role of bridging to an underlying log
> mechanism.

I would claim that for a first shot let's keep this simple.  It is 
pluggable in that you may plug in your own Log implementation that does 
what you need.

That aside, how do you propose to reconcile this "pluggable" mechanism 
with the underlying logger that DOES accept "MSGID" and Object[] directly?

I'm of the opinion that IF a reasonable proposal can be produced, then it 
can be introduced at a later point in time [evolution].


> And I'd like to see a Java 5 versiion of this interface that takes 
advantage
> of variable argument lists, rather than the String[].

Unlikely in the JCL.

> 
>--- Noel


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

While acknowledging that while we all orbit the same sun, we also stand in 
different time zones and see it differently... :-)


news <[EMAIL PROTECTED]> wrote on 12/18/2004 10:44:11 AM:

> Noel J. Bergman wrote:
> > Simon Kitching wrote:
> >>I've been convinced by the arguments put forward in this thread that
> >>explicit enter/exit methods taking class+method strings should not
> >>be encouraged
> > 
> > 
> > Actually, I agree.  I'd prefer to see that semantic state encoded in 
the log
> > message, which I feel is much cleaner.
> > 
> >--- Noel
> 
> +1.  Just because the JDK 1.4 log does this, doesn't mean that we have 
> to enforce this behavior on all logging implementations.  Why not just 
> leave it generic?  If someone wants enter/exit methods, they can define 
> their own:
> 
> public static void enter(Log log, Class clazz, String method);
> public static void exit(Log log, Class clazz, String method);

The proposal is for more than a the simple helper methods, it is for the 
[potential] underlying implementation below.  Where possible, these SHOULD 
be mapped to a finer level than 'debug', but not as fine as 'trace'.

By naming them 'enter/exit' instead of 'finer', we encourage their use in 
a particular fashion...  if you feel that such strong "best-practice" 
enforcement is inappropriate, then let's not throw the dog [and I know 
it's a dog ;)] out with the bath water.

We'd like at least one more trace level, see below.

 
> Personally, I am against introducing logging that is more specific than 
> TRACE.  In practice, I think it's hard to explain even the distinction 
> between TRACE and DEBUG (i.e. - the projects I've seen tend to use one 
> or the other almost exclusively if they're not using INFO or higher for 
> the message).  Again, just because JDK 1.4 offers FINEST, FINER doesn't 
> mean JCL has to.  What happens when the next implementation comes along 
> that offers 42 different logging levels, including TINY, VERYTINY, 
> EXTREMLYTINY, TINIEST, SUPPERTINY and SPLITTINGHAIRS logging levels?

There are many uses for different levels of trace logging [general term, 
not JCL trace].  One such for which I advocate better support is:

1.  Tracing as we cross component boundries [currently this would be JCL 
debug on classes representing component API's].  I want to log information 
that helps me understand what's coming in, and what's going out, at a 
COMPONENT level [component TBD as you like].

2.  Tracing as we cross class/method boundries [currently we propose this 
with enter/exit].

3.  Tracing of additional low level information [currently this would be 
JCL trace].

Two trace levels is simply not enough.  Granted we can play games with 
loggerNames, but feel this unnecessarily imposes multiple "logger name" 
schemes where the "class name" is more than sufficient for most uses.  IN 
PARTICULAR, if we want to document this as a "best-practice" in the users 
guide, then we need also to ensure that there is a consistent "logger 
name" scheme being used across components, that there are no [or minimal] 
collisions...  class name really simplifies this.


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

Excellent!

Chris Lambrou <[EMAIL PROTECTED]> wrote on 12/17/2004 04:32:28 PM:

> 
> >Someone suggested that for Log, it would be appropriate to make it an 
> >abstract class rather than an interface, so we can make these kinds of 
> >changes easier in the future.  I think the risks for this are low, and 
> >probably better [less problems for the majority of users] than just 
adding 
> >new methods to the existing interface.  Other thoughts on this 
direction?
> > 
> >
> I think the risk of annoying quite a number of users by changing Log 
> from an interface to an abstract class is actually quite high. For sure, 

> one of the default logging implementations provided by JCL would 
> probably suffice for the majority. However, there are groups who will 
> have chosen, for whatever reason, to provide their own logging 
> implementations. I've certainly worked on a couple of projects where 
> this has been the case. One of them could probably cope with the change 
> relatively easiliy, but such a change could be a real pain for the 
> other. Whilst the proportion of JCL users in this situation is probably 
> quite small, in terms of actual numbers, such a change could cause quite 

> a lot of grief.

IF we went down this road [no such proposal has yet been made], you would 
be required to make SOME code change.

a. Change the 'implements' to an 'extends', pick up default impls for the 
new methods.
b. Supply new methods all your existing code that implements Log.

You advocate that (a) is a bigger hit to you.  I would have thought (b) 
would be more difficult, UNLESS your current Log implementations extend 
some other class.  I would have thought Log classes extending other [non 
Log] classes would be very unlikely.


***
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?

[robert burrell donkin]

On 17 Dec 2004, at 01:56, Richard Sitze wrote:
robert burrell donkin <[EMAIL PROTECTED]> wrote on
12/16/2004 04:38:34 PM:

the solution i've been considering is to separate the base
application-environmental configuration from the sophisticated
discovery process required to ensure proper isolation in complex
managed server environments. (i'm not going to describe this in detail
right now: i should post a code example but i'm tired so that'll have
to wait.)
I will eagerly await, and will compare your thoughts to what is 
described
in the original proposal.  For reference, please note that the proposal
can be found here:

http://issues.apache.org/bugzilla/show_bug.cgi?id=32618
i've added some thoughts onto some new wiki pages linked from 
http://wiki.apache.org/jakarta-commons/Logging.

where does byte-code engineering come in? well, there are certain
things that users want that are just not going to be feasible no 
matter
how sophisticated a discovery process is employed. too much complexity
leads to fragility in the discovery code: providing rewiring at the
byte-code level would allow users great control and relieve the
commons-logging development team of the burden of creating every more
complex discovery code.
And other teams... this *must* be addressed independently from Logging.
+1
- robert
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [doc] First attempt at update to release.html

[Phil Steitz]

Phil Steitz wrote:
One more general comment that I did not know what to do with.  Steps 6 
and 7 (checksums and sigs) and 11 (upload) involve quite a bit of manual 
typing that is time consuming and can lead to errors.  For 6 and 7, I 
used the script below (please do not make fun of my limited bash skills 
;-).  I have another one that does verification separately (presumably 
from a different user ID). It would be nice to also have a script to 
create the symlinks in 11 automatically.  Does anyone have this?  Should 
these scripts a) go in committers/tools  b) be housed somewhere in j-c 
c) be summarized / embedded / linked in the instructions or d) none of 
the above?

I just committed three shell scripts to committers/tools/releases:
sign_and_hash.sh -- creates checksums and sigs
symlinks.sh -- generates symlinks
verify_sigs.sh -- verifies checksums and sigs
NB: committers has moved to svn.  The URI is
https://svn.apache.org/repos/private/committers
If you haven't used the ASF svn repo, you will need to run svnpasswd 
from ssh to get set up.

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

Re: [i18n] Introduced pluggable MessageProviders and new ResourceBundleMessageProvider

[Martin Cooper]

On Sat, 18 Dec 2004 17:11:27 +0100, Daniel Florey <[EMAIL PROTECTED]> wrote:
> Hi folks,
> I've added some nice features requested by users to the upcoming i18n
> component in the sandbox:
> You can now easily plug-in your own custom message provider. This is very
> useful if you already have tons of localized messages on weird places (e.g.
> databases).
> Writing a message provider is as simple as implementing a single method.
> I've also added a ResourceBundle-based message provider that uses the
> built-in Java functionality for locating and handling resource bundles.

Would it make sense to add a message provider that uses Commons
Resources, similar to the ResourceBundle one?

--
Martin Cooper


> This one is very useful if you already have tons of localized messages in
> some property files and nevertheless want to use the i18n component to take
> advantage of late localization binding, localized exception handling and
> message bundles.
> 
> Cheers,
> Daniel
> 
> -
> 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]

[Jakarta Commons Wiki] New: Logging/ConfigurationAndDiscovery

[commons-dev]

   Date: 2004-12-18T11:16:44
   Editor: 82.38.65.173 <>
   Wiki: Jakarta Commons Wiki
   Page: Logging/ConfigurationAndDiscovery
   URL: http://wiki.apache.org/jakarta-commons/Logging/ConfigurationAndDiscovery

   no comment

New Page:

= Configuration And Discovery =

Configuration and discovery is the process used by commons-logging to determine 
the correct Log implementation to call. 

== The Current Situation ==

=== Discover And Configuration ===

Code calls the commons-logging API to request a Log instances. This call is 
made to a LogFactory class method. This class method attempts to discover which 
LogFactory instance should be used to service this request. This discovery 
process involves various classloader gymnastics intended to give correct 
isolation for applications run in certain container environments.

These gymnastics work well in only a limited number of container environments. 
There is a definite limit to the improvements that can be made to this 
discovery code whilst it is contained with an API class. The code is also both 
complex and fragile. 

=== Layers ===

There is no compile time dependency from the API classes to the implementation 
ones. However, it is not practical to distribution the implementation code 
separately from the API since the API code will fail unless the implementation 
classes are present. 

== A Road Forward ==

(I'll try to present not the results but the reasoning which lead in this 
direction. Hopefully, this should make it easier for the community to 
understand, involve itself and find any better alternative routes that have 
been missed.)

=== Improved Layering ===

It is generally acknowledge that commons logging needs a small, functional API 
for components to compile and run against. LogFactory is too complex. It 
includes complex discovery code which limits the usefulness of subclassing. 
(For example, for use in a J2ME environment.) It's size limits it's usefulness 
in applets. 

A suitable API layer could be created by pushing the discovery code (includig 
LogFactory) into a separate, subsidary layer. The role of LogFactory in the API 
would be replaced by a small, simple class called Logger, say. 

The discovery process has many problems. The current implementation works well 
in some containers, less well in other containers and not at all in some 
environments. It has become clear that no one discovery mechanism can work well 
in the range of environments in which commons-logging may find itself deployed. 
This points towards a need for the discovery mechanism to be pluggable. 

The process of discovery should be encapsulated entirely within the discovery 
layer. Therefore, there seems to be nothing to gain by adding a separate 
interface for discovery. So, the discovery component should have a facade which 
extends Logger.

The choice of the appropriate discovery implementation should be common 
throughout a particular environment. For example, though a discovery 
implementation that knows how to isolate applications is needed for a container 
environment, there is no need for the discovery process to vary per 
application. Therefore, the neccessary configuration can be stripped down to 
the minimal: a system property. This would give the name of the Logger 
implementation to be loaded and used.

Backwards compatibility could be maintained by defaulting to the use of 
LogFactory when this class is present and no other configuration is. By making 
Logger a superclass of LogFactory, it should be possible to use the existing 
system property without breaking existing systems. New discovery mechanisms 
could override Logger (rather than the bulkier LogFactory).

The current API is that it is not useable by itself at run time by itself: it 
fails when suitable implementations cannot be discovered. This dramatically 
increases the effective size of a runnable API jar. Since the dominent paradigm 
involves hold Log references as class variables, this behaviour can be very 
annoying at times since classes cannot be loaded unless commons logging is 
correctly configured. So, rather than fail, Logger should provide some sort of 
very basic Log even when no system property has been set and LogFactory cannot 
be loaded. This would probably log messages with Error and Fatal serverity to 
System.err. 

The Logger API should be minimal and compact. The current LogFactory provides a 
number of methods which are  small variations on each other. These can and 
should be consolidated. The primary use case for Logger is to provide a log 
appropriate for a configuration. The use of Class (in addition to String) has 
proved a useful innovation. I propose that Logger extends this further by 
allowing any object to be passed in. The discovery layer would have the freedom 
to process these in whatever fashion they choose. The LogFactory implementation 
would convert all objects toString other than Class's. 

We therefore arrive at the following signature for Logger

[Jakarta Commons Wiki] Updated: Logging/ConfigurationAndDiscovery

[commons-dev]

   Date: 2004-12-18T11:22:57
   Editor: 82.38.65.173 <>
   Wiki: Jakarta Commons Wiki
   Page: Logging/ConfigurationAndDiscovery
   URL: http://wiki.apache.org/jakarta-commons/Logging/ConfigurationAndDiscovery

   no comment

Change Log:

--
@@ -49,4 +49,4 @@
 
 
 
-Up to [:logging]
+Up to [:Logging]

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

[Jakarta Commons Wiki] Updated: Logging/ConfigurationAndDiscovery

[commons-dev]

   Date: 2004-12-18T11:22:27
   Editor: 82.38.65.173 <>
   Wiki: Jakarta Commons Wiki
   Page: Logging/ConfigurationAndDiscovery
   URL: http://wiki.apache.org/jakarta-commons/Logging/ConfigurationAndDiscovery

   no comment

Change Log:

--
@@ -26,6 +26,8 @@
 
 The discovery process has many problems. The current implementation works well 
in some containers, less well in other containers and not at all in some 
environments. It has become clear that no one discovery mechanism can work well 
in the range of environments in which commons-logging may find itself deployed. 
This points towards a need for the discovery mechanism to be pluggable. 
 
+http://www.apache.org/~rdonkin/layers.png
+
 The process of discovery should be encapsulated entirely within the discovery 
layer. Therefore, there seems to be nothing to gain by adding a separate 
interface for discovery. So, the discovery component should have a facade which 
extends Logger.
 
 The choice of the appropriate discovery implementation should be common 
throughout a particular environment. For example, though a discovery 
implementation that knows how to isolate applications is needed for a container 
environment, there is no need for the discovery process to vary per 
application. Therefore, the neccessary configuration can be stripped down to 
the minimal: a system property. This would give the name of the Logger 
implementation to be loaded and used.
@@ -43,6 +45,7 @@
 public Log getLog(Object parameter) throws LogConfigurationException
 }}}
 
+http://www.apache.org/~rdonkin/logging-classes.png
 
 
 

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

[Jakarta Commons Wiki] Updated: Logging

[commons-dev]

   Date: 2004-12-18T10:30:03
   Editor: 82.38.65.173 <>
   Wiki: Jakarta Commons Wiki
   Page: Logging
   URL: http://wiki.apache.org/jakarta-commons/Logging

   no comment

Change Log:

--
@@ -20,8 +20,11 @@
 
 
 
-== Design ==
+== Enterprise Logging/Logging 2.0 Design Ideas ==
 
- * /ConfigurationDesign
+Just a place to pull some stuff together...
+
+ * /ConfigurationAndDiscover
+ * /ByteCodeEngineering
 
 

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

[jira] Created: (JELLY-178) jetty tag lib can't be used with jetty 5.0

[Marc DeXeT (JIRA)]

jetty tag lib can't  be used with jetty 5.0
---

 Key: JELLY-178
 URL: http://nagoya.apache.org/jira/browse/JELLY-178
 Project: jelly
Type: New Feature
Versions: 1.0-beta-5
 Environment: JDK 1.4.2_04 XP
Reporter: Marc DeXeT


Jetty tag lib uses deprecated feature in jetty 5.0 like 
"org.mortbay.http.SecurityConstraint.Authenticator"
and some more.

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

[Jakarta Commons Wiki] New: Logging/ByteCodeEngineering

[commons-dev]

   Date: 2004-12-18T10:38:28
   Editor: 82.38.65.173 <>
   Wiki: Jakarta Commons Wiki
   Page: Logging/ByteCodeEngineering
   URL: http://wiki.apache.org/jakarta-commons/Logging/ByteCodeEngineering

   no comment

New Page:

= Byte Code Engineering =

Over a long period, it's become clear that no matter how complex and 
sophisticated commons logging discovery code becomes, it cannot satisfy every 
need. For example, a framework may require a specific configuration to ensure 
that components feed logging back into it's framework. 

There are also some use cases where the environment cannot be controlled so 
that configuration information can be reliably fed into commons logging. For 
example,  a self-contained EJB application where the deployer has insufficient 
control over the container it will be deployed to or an applet. 

Alternative configuration solutions are required to address these use cases. 

It should be possible to use byte code engineering to hard wire the 
configuration directly in the classes: bypassing the configuration and 
discovery code. Each call to Logger.getLog() would be modified to call a 
specific implementation.

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

[all] svn migration proposal

[Tim O'Brien]

The first step to moving to SVN is telling infrastructure exactly what
we need.   The process is as follows:

 

1. We tell infrastructure what we need (and volunteer to help)

2. jakarta-commons and jakarta-commons-sandbox are migrated to a test
repository

3. If we are happy with what we have after a few days, we can perform
the migration to the real repository and lock the CVS module.

 

I have some experience with cvs2svn, but the instructions at
http://www.apache.org/dev simply call for a set of instructions which
I've included below.  Because we have an involved migration process I'll
volunteer to help infrastructure.

 

Please review the conversion instructions here:
http://wiki.apache.org/jakarta-commons/SubversionConversion

[Jakarta Commons Wiki] Updated: Logging/ByteCodeEngineering

[commons-dev]

   Date: 2004-12-18T10:39:20
   Editor: 82.38.65.173 <>
   Wiki: Jakarta Commons Wiki
   Page: Logging/ByteCodeEngineering
   URL: http://wiki.apache.org/jakarta-commons/Logging/ByteCodeEngineering

   no comment

Change Log:

--
@@ -7,3 +7,7 @@
 Alternative configuration solutions are required to address these use cases. 
 
 It should be possible to use byte code engineering to hard wire the 
configuration directly in the classes: bypassing the configuration and 
discovery code. Each call to Logger.getLog() would be modified to call a 
specific implementation.
+
+
+
+Up to [:Logging]

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

[Jakarta Commons Wiki] Updated: Logging

[commons-dev]

   Date: 2004-12-18T10:30:23
   Editor: 82.38.65.173 <>
   Wiki: Jakarta Commons Wiki
   Page: Logging
   URL: http://wiki.apache.org/jakarta-commons/Logging

   no comment

Change Log:

--
@@ -24,7 +24,7 @@
 
 Just a place to pull some stuff together...
 
- * /ConfigurationAndDiscover
+ * /ConfigurationAndDiscovery
  * /ByteCodeEngineering
 
 

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

[Jakarta Commons Wiki] Updated: SubversionConversion

[commons-dev]

   Date: 2004-12-18T10:34:22
   Editor: TimObrien <[EMAIL PROTECTED]>
   Wiki: Jakarta Commons Wiki
   Page: SubversionConversion
   URL: http://wiki.apache.org/jakarta-commons/SubversionConversion

   no comment

Change Log:

--
@@ -1,6 +1,6 @@
 This is the proposed text of the SVN conversion instructions for 
infrastructure.  Please review this document, and note especially that 
commons-build is migrated to /site and also to /proper/commons-build
 
-{ { {
+{{{
 The Jakarta Commons sub-project has decided to move to subversion, so
 we need your help, along with an indication about when it can be
 done.
@@ -262,6 +262,6 @@
 
  
 
-} } } 
+}}} 
 
 

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

Re: Jakarta Commons Structure rehashed

[Henri Yandell]

On Sun, 19 Dec 2004 00:00:20 +1300, Simon Kitching
<[EMAIL PROTECTED]> wrote:
> svn 1.1 (released 2004-09-29) supports "symbolic links". Perhaps that
> would resolve the issue by allowing us to (manually) build an
> alternative directory containing just symbolic links to the "trunk"
> directory of each subproject? Of course whenever a new subproject was
> created, a symbolic link would need to be manually added - but that is
> no great problem. Possibly that could even be automated; I'm willing to
> try to get that working.
> 
> Regards,
> 
> Simon

Cool. I knew such a feature was in the planning but hadn't realised it
was out yet. I'm +1 on option A + sym-links or script depending on
which feels best.

As long as there's a simple way to check out the head of all of commons :)

What about the sandbox? I think earlier suggestions included it but
Tim's latest didn't.

Hen

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

[Jakarta Commons Wiki] New: SubversionConversion

[commons-dev]

   Date: 2004-12-18T10:33:28
   Editor: TimObrien <[EMAIL PROTECTED]>
   Wiki: Jakarta Commons Wiki
   Page: SubversionConversion
   URL: http://wiki.apache.org/jakarta-commons/SubversionConversion

   Just adding the preliminary conversion instructions.

New Page:

This is the proposed text of the SVN conversion instructions for 
infrastructure.  Please review this document, and note especially that 
commons-build is migrated to /site and also to /proper/commons-build

{ { {
The Jakarta Commons sub-project has decided to move to subversion, so
we need your help, along with an indication about when it can be
done.


We need to export

  jakarta-commons
  jakarta-commons-sandbox

to SVN and then lock these CVS modules.

The resulting repo we need is:

  /jakarta/
/commons/
  /site/  (jakarta-commons/commons-build HEAD)
  /proper/(jakarta-commons HEAD (non-recursive))
/attributes/
  /trunk/ (jakarta-commons/attributes HEAD)
  /tags/  (jakarta-commons/attributes tags)
  /branches/  (jakarta-commons/attributes branches)
/*/   (NOTE: Likewise for all commons components)
  /sandbox/   (jakarta-commons-sandbox HEAD (non-recursive))
/altrmi/
  /trunk/ (jakarta-commons-sandbox/altrmi HEAD)
  /tags/  (jakarta-commons-sandbox/altrmi tags)
  /branches/  (jakarta-commons-sandbox/altrmi branches)
/*/   (NOTE: Likewise for all sandbox components)




 Currently Commons  has these repositories:

 jakarta-commons
 jakarta-commons-sandbox

 Jakarta Commons Sandbox contains a number of components which have
 subsequently been moved out of the sandbox.  Two examples include
 jakarta-commons-sandbox/altrmi which is no longer a part of the
 commons and jakarta-commons-sandbox/digester which was promoted to
 the commons proper three years ago. We would prefer to perserve
 history and remove these components from Subversion ourselves.

 We would also like to preserve the .cvsignore files spread throughout
 this module.  We will write an automated process to search for the
 presence of a .cvsignore file and set the svn:ignore property after
 we have migrated to Subversion.

 The modules we need to move are:

 jakarta-commons/   ->  Commons Proper and Commons Site
 jakarta-commons-sandbox/   ->  Commons Sandbox

 Basically, this is what we need:

 1: convert jakarta-commons/commons-build to SVN.  commons-build will
 be used as the project for the commons website

   jakarta-commons/commons-build CVS

|
|
V
   /jakarta/
/commons/
  /site/   (only HEAD, commons-build had no tags or branches)

 2: convert only the files in jakarta-commons/ to SVN without copying

 subdirectories.  Only HEAD of the following files ".cvsignore",
 "BUILD_DOCS.txt", "LICENSE", "LICENSE.txt", "anakia-project.xml",
 "build.properties.sample", "build.xml", and "charter.xml"


   jakarta-commons/* CVS

|
|
V
   /jakarta/
/commons/
  /proper/*

 3: convert all commons proper components in jakarta-commons to SVN.
 "attributes" is used as an example, but this process needs to be
 completed for the following subdirectories of jakarta-commons: (Note:
 commons-build is duplicated - some projects may still have a lateral

 dependency on commons-build)

   attributes/
   beanutils/
   betwixt/
   cactus/
   chain/
   cli/
   codec/
   collections/
   combo/
   commons-build/
   configuration/
   daemon/
   dbcp/
   dbutils/
   digester/
   discovery/
   docs/
   el/
   email/
   fileupload/
   httpclient/
   io/
   jelly/
   jexl/
   jxpath/
   lang/
   latka/
   launcher/
   logging/
   math/
   modeler/
   net/
   pool/
   primitives/
   resources/
   transaction/
   validator/

   jakart-commons/attributes CVS

|
|
V
   /jakarta/
/commons/
  /proper/
/attributes/
  /trunk/ (jakarta-commons/attributes HEAD)
  /tags/  (jakarta-commons/attributes tags)
  /branches/  (jakarta-commons/attributes branches)

 4: convert only the files in jakarta-commons-sandbox/ to SVN without copying
 subdirectories.  Only HEAD of the following files ".cvsignore",
 "LICENSE", "LICENSE.txt", "NOTICE.txt", "build.sh"

   jakarta-commons-sandbox/* CVS

|
|
V
   /jakarta/
/commons/
  /sandbox/*

 5: convert all commons sandbox components in jakarta-commons-sandbox
 to SVN (even components no longer in the sandbox) "altrmi" is used as
 an example, but this process needs to be completed for the following
 subdirectories of jakarta-commons-sandbox:

   altrmi/
   amend/
   armi/
   attributes/
   betwixt/
   bzip2/
   cache/
   cadastre/
   chain/
   cjan/
   clazz/
   cli/
   codec/
   codec-multipart/
   compress/
   configuration/
   contract/
   convert/
   daemon/
   dbutils/
   digester/
   discovery/
   el/
   email/
   events/
   feedparser/
   fileupload/
   filters/
   

[Jakarta Commons Wiki] Updated: FrontPage

[commons-dev]

   Date: 2004-12-18T10:29:24
   Editor: TimObrien <[EMAIL PROTECTED]>
   Wiki: Jakarta Commons Wiki
   Page: FrontPage
   URL: http://wiki.apache.org/jakarta-commons/FrontPage

   no comment

Change Log:

--
@@ -61,6 +61,8 @@
  * ComponentTemplate - Use this template when creating the main wiki page for 
a component.
 
  * AutomatedIdeas - some ideas on how increased automation could help us 
(HenriYandell)
+
+ * SubversionConversion - a proposed set of svn instructions for 
infrastructure.
 
 {{{
 *Q:* Little request: Can we PLEASE have a single javadoc tree for all commons 
components?  

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

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

[robert burrell donkin]

On 18 Dec 2004, at 16:25, Matt Sgarlata wrote:

robert burrell donkin wrote:
> does anyone think that there is any real need for implementations to
> belong to a second type hierarchy?
I don't think it's a good idea to *preclude* logs from participating 
in two different type hierarchies because it's hard to anticipate new 
use cases.
it's a tradeoff :)
it's hard to anticipate new use cases. this means that it's hard to 
future-proof any interface. Log isn't too bad but (had it been an 
abstract class) i think that it would have had at least one more method 
added (to improve support for IoC frameworks). it's important to keep 
in mind that these interfaces are likely to have to maintain 
compatibility for several years.

But to answer your question, remember how Richard proposed that the 
generation of exception messages be possible with Logs?  Well I think 
the community struck that idea down, but what if someone *did* decide 
they wanted to combine that functionality with their logger.  In that 
case they would probably want to extend some type of message 
resolution base class rather than being forced to extend a Log 
abstract class.
(i wasn't the first to note this but) inheritance is often overused in 
java. an equally good design could use delegation (to the message 
resolution class) or a nested implementation. i don't mind forcing 
users to choose a particular design provided that this design is as 
good or better than the original.

the only use case (where alternative, equitable designs do not exist) i 
can think of would be a Log proxy. i'm not sure how useful that would 
be.

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

Curt Arnold <[EMAIL PROTECTED]> wrote on 12/16/2004 11:13:25 PM:

> 
> On Dec 16, 2004, at 7:56 PM, Richard Sitze wrote:
> 
> > Good comments, thanks.
> >
> >
> > Curt Arnold <[EMAIL PROTECTED]> wrote on 12/16/2004 05:34:58 PM:
> >
> >> Sorry to come in on this late.  I just read the archives after Ceki
> >> posted a link on log4j-dev.
> >>
> >> First, I agree Enterprise is a poor name.  I tend to think in terms 
of
> >
> > Back to the issue of names, assuming we don't play some of the other 
> > games
> > mentioned above, other name suggestions are welcome.
> >
> 
> I wasn't terribly concerned about the eventual class names.  More try 
> to make the observation that the major tension is between the intended 
> audience for the message not the scope of the system.  A debug or trace 
> level message in a handheld app has more in common with a trace level 
> message in a enterprise system than either has with a "out of stock" 
> warning in either system.
> 
> >
> >> diagnostic versus administrative logging.  Diagnostic logging 
intended
> >> to diagnose an issue where log requests are generally discarded 
> >> (unless
> >> actively researching a problem) and fluency with internal program
> >> structure and with the human language used in the implementation is
> >> assumed.  Logger names based on class names would be appropriate here
> >> since the audience is likely familiar with the code base.
> >
> > Agreed.
> >
> > JCL [as well as Log4J and JSR-47 logging] supports "trace level" [JCL
> > debug, trace] logging which I believe equates to what you term 
> > "diagnostic
> > logging".  We do *not* propose to 'internationalize' these... I would
> > resist such efforts.
> >
> >>
> >> Administrative logging (in lack of a better term, but at least it is
> >> better than Enterprise) are messages intended for a difference 
> >> audience
> >> where knowledge of internal program structure and the human language 
> >> of
> >> the implementation is not given.  These difference audiences have
> >> resulted in different API on some platforms, for example, Windows has
> >> OutputDebugString (for diagnostic messages) and the Event log methods
> >> for administrative messages.  Logger names here would likely be
> >> business process related.
> >
> > Reasonable, not sure if your intention is to relate this type of 
> > logging
> > to the "message level" logging of JCL [fatal, error, warn, info].
> 
> I don't think that was my intention.  Platform provided diagnostic 
> logging, like Win32 OutputDebugString, may be very simplistic and 
> provide no support for prioritization, persistence, or 
> internationalization.  Platform provided administrative logging, like 
> the NT event log, would likely support some of those.  Both a 
> diagnostic and a administrative system may have a concept of a WARN 
> severity, however the business significance of a WARN severity may be 
> orders of magnitude different depending on the context.   I would not 
> think it common that, for example, inventory messages would switch from 
> using a diagnostic to an administrative type API based on message 
> severity.

As you pointed out earlier, much of this depends on how the logger is 
used.  Class category names for code logging, other "application category" 
logger names for the other would be a reasonable approach.

However, for our stated *GOAL*, JCL's primary purpose is for instrumenting 
components that are expected to plug into larger applications/frameworks. 
It's not clear to me what it means to start instrumenting such components 
for "administrative" or "application" level logging events.  Not to say it 
couldn't be done.  This is a "best-practice" issue for the most part... 
something for the users guide.

If there are specific issues to be addressed by the API's, please raise 
them?  Examples?  It's not clear to me what course of action you advocate.

> >
> >> There are a couple of issues with the resource bundle proposals that 
I
> >> have seen previously.  I haven't had time to review those presented
> >> here so they may or may not apply.
> >>
> >> Resource bundle approaches are sufficiently demanding of developers
> >> that they will likely substantially reduce the density of diagnostic
> >> messages if only a resource bundle approach is available.

What are our (simple) options.  Again remember that we expect to be a 
thin-wrapper over existing log implementations.


> >>
> >> Using the locale settings of the user or system is likely 
> >> inappropriate
> >> for diagnostic messages.  A diagnostician reviewing log files or
> >> receiving networked log messages should not be forced to read log
> >> messages in the user's native language.  A worse case scenario would 
> >> be
> >> a internationalized web site log where the language in the log file 
> >> was
> >> constantly changing.
> >
> > Agreed.  Again, the current proposal does not provide I18N enabled 
> > logging
> > for JCL debug or trace methods.
> 
> If I was a diagnostician

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

[Ceki Gülcü]

At 05:44 PM 12/18/2004, Matt Sgarlata wrote:
Noel J. Bergman wrote:
Actually, I agree.  I'd prefer to see that semantic state encoded in the log
message, which I feel is much cleaner.
--- Noel
+1.  Just because the JDK 1.4 log does this, doesn't mean that we have to 
enforce this behavior on all logging implementations.  Why not just leave 
it generic?  If someone wants enter/exit methods, they can define their own:

public static void enter(Log log, Class clazz, String method);
public static void exit(Log log, Class clazz, String method);
Personally, I am against introducing logging that is more specific than 
TRACE.  In practice, I think it's hard to explain even the distinction 
between TRACE and DEBUG (i.e. - the projects I've seen tend to use one or 
the other almost exclusively if they're not using INFO or higher for the 
message).  Again, just because JDK 1.4 offers FINEST, FINER doesn't mean 
JCL has to.  What happens when the next implementation comes along that 
offers 42 different logging levels, including TINY, VERYTINY, 
EXTREMLYTINY, TINIEST, SUPPERTINY and SPLITTINGHAIRS logging levels?
Log4j version 1.4 or 2.0 is likely to introduce the notion of multiple
domains for categorizing logging statements. When that happens, the
notion of logging levels will be looked at very differently.
Commons-logging promises to abstract different logging APIs such as
log4j, Avalon logkit and java.util.logging API. However, such a task
is near impossible to fulfill, while Avalon Logkit is nowhere to be
seen. In the history of software, no one has ever managed to abstract
competing and divergent APIs without their active cooperation. Chances
are it won't happen this time around either.
User who currently use commons-logging are likely to go through a
lengthy and painful conversion process when they realize that log4j
offers must-have features.

Matt
--
Ceki Gülcü
  The complete log4j manual: http://qos.ch/log4j/

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

RE: Jakarta Commons Structure rehashed

[Tim O'Brien]

> -Original Message-
> From: Henri Yandell [mailto:[EMAIL PROTECTED]
> 
> And yet option A is going to be impossible (?) to check out as one
whole
> blob.
> 

We could store two scripts (sh and bat) at the /jakarta/commons level
that would only grab the trunks of every component.  So, I'd forsee the
process as

svn co -N http:///jakarta/commons
cd commons
./get-trunks.sh

Or, we could rely on symlinks, but I'm unsure how win clients would
handle this.


> I wonder if there's any magic coming from the SVN guys that'll let us
> do option B and yet provide a link of some kind to automatically be
> able to check out all the trunks in one go.
> 
> Hen
> 
> On Fri, 17 Dec 2004 14:01:53 -0700, Kris Nuttycombe
> <[EMAIL PROTECTED]> wrote:
> > Option A makes the projects look a lot more atomic, which seems like
a
> > good idea when one contemplates what will be necessary when
promoting
> > projects from the sandbox.
> >
> > Kris
> >
> > Tim O'Brien wrote:
> >
> > >I don't think we ever settled this question.
> > >
> > >Which SVN structure are we interested in?
> > >
> > >** Option A:
> > >
> > >jakarta/
> > >commons/
> > >digester/
> > >trunk/
> > >tags/
> > >branches/
> > >beanutils/
> > >trunk/
> > >tags/
> > >branches/
> > >
> > >OR
> > >
> > >** Option B:
> > >
> > >jakarta/
> > >commons/
> > >trunk/
> > >digester/
> > >beanutils/
> > >tags/
> > >digester/
> > >beanutils/
> > >branches/
> > >digester/
> > >beanutils/
> > >
> > >
> > >
> >
> > --
> > =
> > Kris Nuttycombe
> > Associate Scientist
> > Geospatial Data Services Group
> > CIRES, National Geophysical Data Center/NOAA
> > (303) 497-6337
> > [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]
> 



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

RE: Jakarta Commons Structure rehashed

[Tim O'Brien]

Not following this one, this implies that ASF has one trunk.Even
though copies are cheap I wouldn't want to create a copy of the entire
SVN tree for every release.

I think you may have mean to propose that we have one trunk in commons.
If commons components were frequently released as a group, this may make
sense, but commons components have wildly varied release cycles.

> -Original Message-
> From: Emmanuel Bourg [mailto:[EMAIL PROTECTED]
> Sent: Saturday, December 18, 2004 5:10 AM
> To: Jakarta Commons Developers List
> Subject: Re: Jakarta Commons Structure rehashed
> 
> Henri Yandell wrote:
> 
> > And yet option A is going to be impossible (?) to check out as one
whole
> blob.
> 
> And what about this option ? Let say option C :
> 
> trunk/
>  jakarta/
>  commons/
>  digester/
>  beanutils/
> tags/
> branches/
> 
> Emmanuel Bourg



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

RE: Jakarta Commons Structure rehashed

[Tim O'Brien]

> Another reason for Option A other than those already listed is that it
> is consistent with what other projects have already started to adopt
> (that I've seen), and that goes a long way to ease of use in itself.
> 

That's my feeling as well.  Even though we could use Option B, I'm more
comfortable using what has become an accepted practice.  And, I'd expect
future tools like subclipse to start looking for "trunk", "tags", and
"branches".


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

Re: [lang] 2.1...

[Matt Sgarlata]

One thing under the "Seeking Opinions" section of the Wiki...
# [WWW]26056 [lang] Add methods to ArrayUtils: add at end and 
insert-like ops - DONE - add(Object[], Object) is overloaded for all the 
primitives, but add(Object[], int, Object) and addAll(Object[], 
Object[]) are not overloaded for primitives. Should they be?

There are two alternatives:
1) Overload for each primitive.  This approach enforces type safety at 
compile time for users of [lang] but means duplicate code in [lang] 
itself.  This is the approach currently taken by EqualsBuilder in 
EqualsBuilder's append methods.
2) Use Object in the signature instead of Object[], int[], long[], etc. 
 This approach does not enforce type satefy for users of [lang] at 
compile time, but can enforce type safety at runtime by including code 
like this at the beginning of the method

If !(objectToAdd.getClass().isArray()) then throw IllegalArgumentException
This approach makes use of the Array class 
(http://java.sun.com/j2se/1.4.2/docs/api/java/lang/reflect/Array.html)
for the implementation.

I personally opt for approach #2 in my work, but you could certainly 
make a valid argument that #1 is better for a library like [lang].

Henri Yandell wrote:
Sorry for the silence from me. As I've probably said a million times,
baby happened.
I hadn't heard... congrats!
I'm full of coding energy, or perhaps the need to 'have coded' that
leads to coding happening and looking to direct some of it to Lang
2.1.
Looking at the wiki and bugzilla, we were nearly there as far as I
recall. Not a lot has cropped up in the 2 months or so that have
passed, couple of bugs I've easily closed out and a couple of trickier
ones.
Gary seems to have taken care of
http://issues.apache.org/bugzilla/show_bug.cgi?id=32625. Is it ready
for closure Gary? Despite Matt Blum's comment on a work-around, it
still sounds like a fine change to the library.
Thanks for including this for me :)
As per my comments above, are we sure we want all the duplicate append() 
methods in EqualsBuilder?

Also, what would you guys think of including deep comparisons of Maps 
and Collections to the EqualsBuilder?  I wrote similar code in Morph's 
TestUtils.equals class which could probably be ported to EqualsBuilder 
for lang 2.2.  Should I open an enhancement ticket?  The Morph code is 
avail under the Apache license so feel free to steal it.

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

Re: Commons Mapper: scope/roadmap?

[Matt Sgarlata]

Max Rudman wrote:

Specifically, I'm not exactly planning on a Query-by-Example API, but 
rather a dynamic SQL statement builder API (also insert, update, 
delete, etc.).  I run into this problem all the time where the user is 
specifying what they'd like to search for, and so you need to build a 
SQL statement on-the-fly.

Yes, dynamic SQL/OQL generation is exactly what I am talking about. 
Perhaps I chose Query-By-Example terminology poorly in that it's not QBE 
itself but rather the API that enables QBE-type functionality.


If you're curious, take a look at the DynamicSqlSelectStatment interface.

I looked at your code (DynamicSqlSelectStatement) and it looks very much 
like something I had built (I call it QueryBuilder). Do you plan support 
for functions, GROUP BY and ORDER BY clauses? You might have that in the 
rest of your API as I didn't look thoroughly.
Actually the original version I did for my old firm for v1.0 was called 
QueryBuilder.  Then when I was exposed to HQL I renamed it 
SqlQueryBuilder and introduced an HqlQueryBuilder.  We're definitely 
thinking along the same lines :)  I've never implemented a GROUP BY 
clause before, but I certainly think it's valuable.

Let me know if you have any comments, questions, etc!

So, are you planning a persistence (O/R mapping) layer like Apache 
ObjectBridge and Hibernate or an abstraction API like Mapper?
Actually, I'm planning on using Morph (morph.sourceforge.net) to provide 
the functionality that Mapper does.  I was planning on having this wait 
until Morph 1.1, but so you can see what I'm talking about I'll try to 
get it out the door this weekend.  The nice thing with using Morph will 
be if you have a ResultSet like this

StartDate (String), EndDate (String), MyNumber (Number)
that needs to be mapped to an object with properties
Date getStartDate();
Date getEndDate();
int myNumber();
You will be able to do it all declaratively with an IoC framework, 
including the type conversions!

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

Re: [configuration]XMLConfigurations

[Oliver Heger]

Emmanuel Bourg wrote:
Oliver Heger wrote:
If this is accepted, we can close the bugs related to 
XMLConfiguration messing up files on saving (31429, 32240). What do 
you think?

The last time I pondered if HierarchicalXMLConfiguration could replace 
XMLConfiguration there was something blocking but I can't remember 
exactly what, maybe the lack of a save() implementation you fixed 
earlier, I'll have to check. Do all tests for XMLConfiguration pass 
with HierarchicalXMLConfiguration ?

Emmanuel Bourg
I have now made HierarchicalXMLConfiguration fully compatible with 
XMLConfiugration. All tests for XMLConfiguration now run also with 
HierarchicalXMLConfiguration.

A thing that bothers me a bit is the fact that it is not too trivial to 
implement all the features of file based configurations (e.g. auto save, 
constructors) for HierarchicalXMLConfiguration because it cannot inherit 
from AbstractFileConfiguration. Maybe someone comes up with a more 
elegant solution?

If noone objects I will now go ahead and make 
HierarchicalXMLConfiguration the one and only XMLConfiguration we have.

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

Noel J. Bergman wrote:
Simon Kitching wrote:
I've been convinced by the arguments put forward in this thread that
explicit enter/exit methods taking class+method strings should not
be encouraged

Actually, I agree.  I'd prefer to see that semantic state encoded in the log
message, which I feel is much cleaner.
	--- Noel
+1.  Just because the JDK 1.4 log does this, doesn't mean that we have 
to enforce this behavior on all logging implementations.  Why not just 
leave it generic?  If someone wants enter/exit methods, they can define 
their own:

public static void enter(Log log, Class clazz, String method);
public static void exit(Log log, Class clazz, String method);
Personally, I am against introducing logging that is more specific than 
TRACE.  In practice, I think it's hard to explain even the distinction 
between TRACE and DEBUG (i.e. - the projects I've seen tend to use one 
or the other almost exclusively if they're not using INFO or higher for 
the message).  Again, just because JDK 1.4 offers FINEST, FINER doesn't 
mean JCL has to.  What happens when the next implementation comes along 
that offers 42 different logging levels, including TINY, VERYTINY, 
EXTREMLYTINY, TINIEST, SUPPERTINY and SPLITTINGHAIRS logging levels?

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

cvs commit: jakarta-commons/configuration/src/test/org/apache/commons/configuration TestHierarchicalXMLConfiguration.java

[oheger]

oheger  2004/12/18 08:33:03

  Modified:configuration/src/java/org/apache/commons/configuration
HierarchicalXMLConfiguration.java
HierarchicalConfiguration.java
   configuration/src/test/org/apache/commons/configuration
TestHierarchicalXMLConfiguration.java
  Log:
  Made HierarchicalXMLConfiguration fully compatible with XMLConfiguration: 
fixed an issue with attribute handling, implemented the auto save feature, 
added the constructors for file based configurations.
  
  Revision  ChangesPath
  1.8   +160 -43   
jakarta-commons/configuration/src/java/org/apache/commons/configuration/HierarchicalXMLConfiguration.java
  
  Index: HierarchicalXMLConfiguration.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/configuration/src/java/org/apache/commons/configuration/HierarchicalXMLConfiguration.java,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- HierarchicalXMLConfiguration.java 13 Dec 2004 16:40:13 -  1.7
  +++ HierarchicalXMLConfiguration.java 18 Dec 2004 16:33:03 -  1.8
  @@ -25,6 +25,7 @@
   import java.util.ArrayList;
   import java.util.Collection;
   import java.util.Iterator;
  +import java.util.List;
   
   import javax.xml.parsers.DocumentBuilder;
   import javax.xml.parsers.DocumentBuilderFactory;
  @@ -63,13 +64,15 @@
* @author mailto:[EMAIL PROTECTED]">Oliver Heger 
* @version $Revision$, $Date$
*/
  -public class HierarchicalXMLConfiguration extends HierarchicalConfiguration 
implements
  -FileConfiguration
  +public class HierarchicalXMLConfiguration extends HierarchicalConfiguration 
implements FileConfiguration
   {
   /** Constant for the default root element name. */
   private static final String DEFAULT_ROOT_NAME = "configuration";
   
  -private FileConfiguration delegate = new FileConfigurationDelegate();
  +/** Delimiter character for attributes. */
  +private static char ATTR_DELIMITER = ',';
  +
  +private FileConfigurationDelegate delegate = new 
FileConfigurationDelegate();
   
   /** The document from this configuration's data source. */
   private Document document;
  @@ -78,6 +81,59 @@
   private String rootElementName;
   
   /**
  + * Creates a new instance of HierarchicalXMLConfiguration.
  + */
  +public HierarchicalXMLConfiguration()
  +{
  +super();
  +}
  +
  +/**
  + * Creates a new instance of HierarchicalXMLConfiguration.
  + * The configuration is loaded from the specified file
  + * 
  + * @param fileName the name of the file to load
  + * @throws ConfigurationException if the file cannot be loaded
  + */
  +public HierarchicalXMLConfiguration(String fileName) throws 
ConfigurationException
  +{
  +this();
  +setFileName(fileName);
  +load();
  +}
  +
  +/**
  + * Creates a new instance of HierarchicalXMLConfiguration.
  + * The configuration is loaded from the specified file.
  + * 
  + * @param file the file
  + * @throws ConfigurationException if an error occurs while loading the 
file
  + */
  +public HierarchicalXMLConfiguration(File file) throws 
ConfigurationException
  +{
  +this();
  +setFile(file);
  +if (file.exists())
  +{
  +load();
  +}
  +}
  +
  +/**
  + * Creates a new instance of HierarchicalXMLConfiguration.
  + * The configuration is loaded from the specified URL.
  + * 
  + * @param url the URL
  + * @throws ConfigurationException if loading causes an error
  + */
  +public HierarchicalXMLConfiguration(URL url) throws 
ConfigurationException
  +{
  +this();
  +setURL(url);
  +load();
  +}
  +
  +/**
* Returns the name of the root element.
* 
* @return the name of the root element
  @@ -89,8 +145,8 @@
   
   /**
* Sets the name of the root element. This name is used when this
  - * configuration object is stored in an XML file. Note that setting the
  - * name of the root element works only if this configuration has been 
newly
  + * configuration object is stored in an XML file. Note that setting the 
name
  + * of the root element works only if this configuration has been newly
* created. If the configuration was loaded from an XML file, the name
* cannot be changed.
* 
  @@ -102,6 +158,33 @@
   }
   
   /**
  + * @inheritDoc
  + */
  +protected void addPropertyDirect(String key, Object obj)
  +{
  +super.addPropertyDirect(key, obj);
  +delegate.possiblySave();
  +}
  +
  +/**
  + * @inheritDoc
  + */
  +public void clearProperty(String key)
  +{
  +super.clearProperty(key);
  +   

Re: [proposal] avoiding jar version nightmares

[Matt Sgarlata]

Emmanuel Bourg wrote:
Matt Sgarlata wrote:
This seems to me that this isn't just a problem with commons; it is a 
problem with Java itself that .NET already has a very nice solution 
for.  I'm wondering if this isn't something that should be taken care 
of at the JVM level i.e. - in Java 1.6.  The obvious solution seems to 
be that we need to fix classloaders.  They're already a huge nightmare 
in EJB containers.

How do we go about petitioning Sun for something like this?

Isn't the isolate API (JSR 121) supposed to address this issue ?
It looks like more information can be found here
http://www.jcp.org/en/jsr/detail?id=121
Unfortunately, I personally find the page incomprehensible.  It sounds 
like maybe it will address these issues, but it seems like their focus 
is more on enhancing performance through multitasking than it is on 
solving JAR dependency nightmares.  Is there anyone that can comprehend 
that page? ;)

I see in section 2.11 that the goal was to include the specification in 
J2SE 1.5.  I guess it didn't make it.  Does that mean the spec is dead?

Emmanuel Bourg
Matt
-
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]

Simon Kitching wrote:
Suppose for a moment that we were to choose between adding methods to
the Log interface, and turning it into an abstract class with some
methods; I don't understand what "real pain" would be incurred by having
custom logging adapters be declared as:
The pain (as Robert pointed out) is that you preclude FooLog from 
extending any other class.  (More below)

  public class FooLog extends Logger {...}
instead of the existing
  public class FooLog implements Log {...}
Sure there would be some inconvenience, but wouldn't it be the same as
having to update the existing log implementation to add implementations
for the new methods added to a Log interface?
Ideally instead of changing the existing Log interface, any new methods 
you want to add you introduce in a new interface (e.g. - EnterpriseLog).
If it's possible for EnterpriseLog to be implemented in terms of Log, 
all the better: existing implementations can have an EnterpriseLog 
exposed by using the Decorator pattern.

I really like this approach because it allows you to keep programming to 
interfaces rather than classes.  For example, let's say that I had my 
own legacy CustomLogger that had some nice features I would like to keep 
when I migrate to JCL.  CustomLogger participates in its own type 
hierarchy.  All I have to do to integrate it with JCL is make it 
implement the Log interface.  If Log is an abstract class, I have to 
take a sledgehammer to my CustomLogger to make it extend from Log and 
delegate calls to a SledgeHammeredCustomLogger.

I took this approach in Morph and I think it works quite well.  Users 
only implement a simple Converter interface (similar to the one in 
BeanUtils).  I have a separate interface called DecoratedConverter that 
exposes lots of extra methods that can all be implemented in terms of 
the basic Converter interface.  If someone wants to expose their 
plain-old Converter as a DecoratedConverter, all they have to do is 
DecoratedConverter decorated = new ConverterDecorator(converter).  This 
way, if I have an old Converter that participates in a type hierarchy 
already (say one that I wrote for BeanUtils), I can easily plug it into 
Morph by just implementing a new interface.

More below...

robert burrell donkin wrote:
> does anyone think that there is any real need for implementations to
> belong to a second type hierarchy?
I don't think it's a good idea to *preclude* logs from participating in 
two different type hierarchies because it's hard to anticipate new use 
cases.

But to answer your question, remember how Richard proposed that the 
generation of exception messages be possible with Logs?  Well I think 
the community struck that idea down, but what if someone *did* decide 
they wanted to combine that functionality with their logger.  In that 
case they would probably want to extend some type of message resolution 
base class rather than being forced to extend a Log abstract class.

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

[contract] Moved to i18n

[Daniel Florey]

Hi folks,
I've updated the sandbox contract component to work with the new i18n (0.3).
Cheers,
Daniel


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

cvs commit: jakarta-commons-sandbox/contract project.properties project.xml

[dflorey]

dflorey 2004/12/18 08:14:50

  Modified:contract project.properties project.xml
  Log:
  Moved to i18n-0.3
  
  Revision  ChangesPath
  1.4   +2 -2  jakarta-commons-sandbox/contract/project.properties
  
  Index: project.properties
  ===
  RCS file: /home/cvs/jakarta-commons-sandbox/contract/project.properties,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- project.properties17 Oct 2004 17:18:06 -  1.3
  +++ project.properties18 Dec 2004 16:14:50 -  1.4
  @@ -28,5 +28,5 @@
   # 
   # Jars set explicity by path.
   # 
  -maven.jar.commons-i18n = ${basedir}/lib/commons-i18n-0.2.jar
  -maven.jar.commons-xmlio = ${basedir}/lib/commons-xmlio-0.1pre.jar
  \ No newline at end of file
  +maven.jar.commons-i18n = ${basedir}/lib/commons-i18n-0.3.jar
  +maven.jar.commons-xmlio = ${basedir}/lib/commons-xmlio-0.1pre.jar
  
  
  
  1.6   +1 -1  jakarta-commons-sandbox/contract/project.xml
  
  Index: project.xml
  ===
  RCS file: /home/cvs/jakarta-commons-sandbox/contract/project.xml,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- project.xml   7 Dec 2004 20:52:17 -   1.5
  +++ project.xml   18 Dec 2004 16:14:50 -  1.6
  @@ -42,7 +42,7 @@
 
   
 commons-i18n
  -  0.2
  +  0.3
   
   
 commons-xmlio
  
  
  

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

[i18n] Introduced pluggable MessageProviders and new ResourceBundleMessageProvider

[Daniel Florey]

Hi folks,
I've added some nice features requested by users to the upcoming i18n
component in the sandbox:
You can now easily plug-in your own custom message provider. This is very
useful if you already have tons of localized messages on weird places (e.g.
databases).
Writing a message provider is as simple as implementing a single method.
I've also added a ResourceBundle-based message provider that uses the
built-in Java functionality for locating and handling resource bundles.
This one is very useful if you already have tons of localized messages in
some property files and nevertheless want to use the i18n component to take
advantage of late localization binding, localized exception handling and
message bundles.

Cheers,
Daniel


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

cvs commit: jakarta-commons-sandbox/i18n/xdocs quickstart.xml

[dflorey]

dflorey 2004/12/18 08:00:37

  Modified:i18n/xdocs quickstart.xml
  Log:
  Added docs for new ResourceBundleMessageProvider
  
  Revision  ChangesPath
  1.4   +1 -5  jakarta-commons-sandbox/i18n/xdocs/quickstart.xml
  
  Index: quickstart.xml
  ===
  RCS file: /home/cvs/jakarta-commons-sandbox/i18n/xdocs/quickstart.xml,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- quickstart.xml18 Dec 2004 15:56:28 -  1.3
  +++ quickstart.xml18 Dec 2004 16:00:37 -  1.4
  @@ -127,11 +127,7 @@
   In case of the brand new ResourceBundleMessageProvider 
initialization looks even simpler:
   
   ...
  -try {
  - ResourceBundleMessageProvider.install("myMessages");
  -} catch ( FileNotFoundException e ) {
  - // handle exception
  -}
  +ResourceBundleMessageProvider.install("myMessages");
   ...
   
   It's this simple, because the ResourceBundleMessageProvider 
uses the build-in features of Java to locate 
  
  
  

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

cvs commit: jakarta-commons-sandbox/i18n/xdocs index.xml

[dflorey]

dflorey 2004/12/18 07:58:12

  Modified:i18n/xdocs index.xml
  Log:
  Added docs for new ResourceBundleMessageProvider
  
  Revision  ChangesPath
  1.3   +5 -4  jakarta-commons-sandbox/i18n/xdocs/index.xml
  
  Index: index.xml
  ===
  RCS file: /home/cvs/jakarta-commons-sandbox/i18n/xdocs/index.xml,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- index.xml 5 Oct 2004 17:47:55 -   1.2
  +++ index.xml 18 Dec 2004 15:58:12 -  1.3
  @@ -14,10 +14,11 @@
   This package adds the feature of localized message bundles that consist of 
one or many localized
   texts that belong together. Think of an error message that consists of 
title, text, summary and
   error details. These localized texts are bundled to a localized error and 
can be referenced easily.
  - Based on this concept localized exceptions are introduced that make 
dealing with internationalization a pleasure...
  - A message manager takes care of initializing the messages from an 
XML document. 
  - It can handle a number of different message resource so that you can 
quickly reload messages based
  - on a single resource.
  +To get started go here. 
  +Based on this concept localized exceptions are introduced that make 
dealing with internationalization a pleasure...
  +A message manager takes care of handling different pluggable message 
providers that enable you to easily migrate to the i18n-component.
  +It can handle a number of different message resources so that you can 
quickly reload messages based
  +on a single resource.
   
   
   
  
  
  

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

cvs commit: jakarta-commons-sandbox/i18n/xdocs quickstart.xml

[dflorey]

dflorey 2004/12/18 07:56:28

  Modified:i18n/xdocs quickstart.xml
  Log:
  Added docs for new ResourceBundleMessageProvider
  
  Revision  ChangesPath
  1.3   +18 -4 jakarta-commons-sandbox/i18n/xdocs/quickstart.xml
  
  Index: quickstart.xml
  ===
  RCS file: /home/cvs/jakarta-commons-sandbox/i18n/xdocs/quickstart.xml,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- quickstart.xml18 Dec 2004 15:39:08 -  1.2
  +++ quickstart.xml18 Dec 2004 15:56:28 -  1.3
  @@ -12,17 +12,17 @@
   
   In order to get an impression of how this component works, we will start 
with an
example showing the capabilities of this package.
  -To get started you need at least the jar of this component and the 
dependent xmlio-jar for reading
  +To get started you need at least the jar of this component and the 
dependent xmlio-x.x.jar for reading
xml documents in your classpath.
   
   
   Since version 0.3 of this component you can add your own custom message 
providers.
   This is a big plus if you already have your localized messages in a 
database for example.
You do not have to convert them into the supported XML or 
property-based format, but you
  - can write a simple MessageProvider by implementing a single method and 
plug it in.
  + can write a simple MessageProvider by implementing a 
single method and plug it in.
   
   
  - A new message provider made it into this component: The 
ResourceBundleMessageProvider.
  + A new message provider made it into this component: The 
ResourceBundleMessageProvider.
This one enables you to keep your property files that may 
contain localized messages.
You can group entries messages by adding the key at the end of the 
existing message key. The
following example shows how a property file should look like to 
work as the following XML example:
  @@ -105,7 +105,9 @@
   
   
   Now that we created a file containing the desired messages, we want to 
make use of them.
  -To do so we have to initialize the MessageManager with these 
messages.
  +To do so we have to initialize the MessageProvider with these 
messages.
  + Initializing messages depends on the MessageProvider 
that you are using. In case of 
  + an XMLMessageProvider initialization looks like 
this:
   
   ...
   try {
  @@ -122,6 +124,18 @@
where you want probably load messages from you .war archive. So an 
input stream is much
more flexible, even if it is a little bit more unconvenient than using
a file name in our use case.
  +In case of the brand new ResourceBundleMessageProvider 
initialization looks even simpler:
  +
  +...
  +try {
  + ResourceBundleMessageProvider.install("myMessages");
  +} catch ( FileNotFoundException e ) {
  + // handle exception
  +}
  +...
  +
  +It's this simple, because the ResourceBundleMessageProvider 
uses the build-in features of Java to locate 
  + and load the appropriate property files or resource bundle classes.
   
   
Now we are ready to go! First of all we want to print out a simple 
localized welcome
  
  
  

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

cvs commit: jakarta-commons-sandbox/i18n/xdocs/images i18n-logo-white.psd

[dflorey]

dflorey 2004/12/18 07:39:08

  Modified:i18n/xdocs quickstart.xml
  Added:   i18n/xdocs/images i18n-logo-white.psd
  Log:
  Added support for pluggable MessageProviders and added 
ResourceBundleMessageProvider
  to enable migration from resource bundle based applications to i18n.
  
  Revision  ChangesPath
  1.2   +43 -3 jakarta-commons-sandbox/i18n/xdocs/quickstart.xml
  
  Index: quickstart.xml
  ===
  RCS file: /home/cvs/jakarta-commons-sandbox/i18n/xdocs/quickstart.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- quickstart.xml5 Oct 2004 17:47:55 -   1.1
  +++ quickstart.xml18 Dec 2004 15:39:08 -  1.2
  @@ -12,10 +12,50 @@
   
   In order to get an impression of how this component works, we will start 
with an
example showing the capabilities of this package.
  -To get started you need at least the jar of this component and the 
dependent xml-importer-jar for reading
  +To get started you need at least the jar of this component and the 
dependent xmlio-jar for reading
xml documents in your classpath.
   
  -
  +
  +Since version 0.3 of this component you can add your own custom message 
providers.
  +This is a big plus if you already have your localized messages in a 
database for example.
  + You do not have to convert them into the supported XML or 
property-based format, but you
  + can write a simple MessageProvider by implementing a single method and 
plug it in.
  +
  +
  + A new message provider made it into this component: The 
ResourceBundleMessageProvider.
  + This one enables you to keep your property files that may 
contain localized messages.
  + You can group entries messages by adding the key at the end of the 
existing message key. The
  + following example shows how a property file should look like to 
work as the following XML example:
  +As you know you'll need two files, each containing the messages for a 
specific locale. This one might be
  + the default one calld myMessages.properties:
  + 
  +welcome.text=Welcome
  +usage.title=Usage
  +usage.text=The application requires the following parameters:
  +validationFailed.title=Parameter {0} invalid
  +validationFailed.text=The given value of the parameter {0} is invalid
  +validationFailed.summary=Value of parameter {0} invalid
  +validationFailed.details=The given value {1} of parameter {0} is invalid.
  +
  +The following one would contain the corresponding german translations in 
a file called myMessages_de.properties:
  + 
  +welcome.text=Willkommen
  +usage.title=Benutzung
  +usage.text=Die folgenden Parameter werden erwartet:
  +validationFailed.title=Parametervalidierung fehlgeschlagen.
  +validationFailed.text=Die Validierung des Parameters {0} ist fehlgeschlagen.
  +validationFailed.summary=Validierung des Parameters {0} fehlgeschlagen.
  +validationFailed.details=Der Wert {1} des Parameters {0} ist ungültig.
  +
  +
  +
  + Using XML based files has many advantages:
  + 
  + You can use the XML-editor of your choice to get assistance 
by typing the messages
  + All entries that belong together are grouped into a single 
XML element
  + All languages reside in a single file, so it is simpler to 
add a new language (matter of taste?)
  + As the whole file gets parsed at initialization time, the 
localization is much faster
  + 
You have to initialize the message manager with an input stream 
giving access to 
the xml document containing the localized messages.

  @@ -70,7 +110,7 @@
   ...
   try {
FileInputStream inputStream = new FileInputStream("myMessages.xml");
  - MessageManager.install("myMessages", inputStream);
  + XMLMessageProvider.install("myMessages", inputStream);
   } catch ( FileNotFoundException e ) {
// handle exception
   }
  
  
  
  1.1  
jakarta-commons-sandbox/i18n/xdocs/images/i18n-logo-white.psd
  
<>
  
  

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

cvs commit: jakarta-commons-sandbox/i18n/src/examples/org/apache/i18n/examples - New directory

[dflorey]

dflorey 2004/12/18 07:22:57

  jakarta-commons-sandbox/i18n/src/examples/org/apache/i18n/examples - New 
directory

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

cvs commit: jakarta-commons-sandbox/i18n/src/java/org/apache/commons/i18n ResourceBundleMessageProvider.java

[dflorey]

dflorey 2004/12/18 07:23:01

  Modified:i18n/src/java/org/apache/commons/i18n
ResourceBundleMessageProvider.java
  Added:   i18n/src/examples/org/apache/i18n/examples
ResourceBundleExample.java
   i18n/src/examples messageBundle_de.properties
messageBundle.properties
  Log:
  Added support for pluggable MessageProviders and added 
ResourceBundleMessageProvider
  to enable migration from resource bundle based applications to i18n.
  
  Revision  ChangesPath
  1.1  
jakarta-commons-sandbox/i18n/src/examples/org/apache/i18n/examples/ResourceBundleExample.java
  
  Index: ResourceBundleExample.java
  ===
  /*
  *
  * 
  *
  * 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.
  *
  */
  package org.apache.i18n.examples;
  
  import org.apache.commons.i18n.LocalizedMessage;
  import org.apache.commons.i18n.ResourceBundleMessageProvider;
  
  /**
   * @author Daniel Florey
   *
   */
  public class ResourceBundleExample {
  public static void main(String[] args) {
  ResourceBundleMessageProvider.install("messageBundle");
  LocalizedMessage testMessage = new LocalizedMessage("helloWorld");
  System.out.println(testMessage.getTitle());
  System.out.println(testMessage.getText());
  }
  }
  
  
  
  1.1  
jakarta-commons-sandbox/i18n/src/examples/messageBundle_de.properties
  
  Index: messageBundle_de.properties
  ===
  # Example for using message bundles using a flat properties-file
  helloWorld.title=Hallo Welt
  helloWorld.text=Ich wünsche Dir alles Gute und ein frohes Fest!
  
  
  1.1  
jakarta-commons-sandbox/i18n/src/examples/messageBundle.properties
  
  Index: messageBundle.properties
  ===
  # Example for using message bundles using a flat properties-file
  helloWorld.title=Hello World
  helloWorld.text=I wish you a merry christmas!
  
  
  1.2   +1 -1  
jakarta-commons-sandbox/i18n/src/java/org/apache/commons/i18n/ResourceBundleMessageProvider.java
  
  Index: ResourceBundleMessageProvider.java
  ===
  RCS file: 
/home/cvs/jakarta-commons-sandbox/i18n/src/java/org/apache/commons/i18n/ResourceBundleMessageProvider.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- ResourceBundleMessageProvider.java18 Dec 2004 15:08:49 -  
1.1
  +++ ResourceBundleMessageProvider.java18 Dec 2004 15:23:01 -  
1.2
  @@ -54,7 +54,7 @@
   }
   } catch ( MissingResourceException e ) {
   logger.log(Level.WARNING, "Could not find resource bundle 
with base name '"+baseName+"', uninstalling it...");
  -uninstall(baseName);
  +i.remove();
   }
   }
   throw new MessageNotFoundException("Message with id "+id+" not 
found");
  
  
  

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

cvs commit: jakarta-commons-sandbox/i18n/src/examples/org - New directory

[dflorey]

dflorey 2004/12/18 07:22:57

  jakarta-commons-sandbox/i18n/src/examples/org - New directory

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

cvs commit: jakarta-commons-sandbox/i18n/src/examples/org/apache/i18n - New directory

[dflorey]

dflorey 2004/12/18 07:22:57

  jakarta-commons-sandbox/i18n/src/examples/org/apache/i18n - New directory

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

cvs commit: jakarta-commons-sandbox/i18n/src/examples - New directory

[dflorey]

dflorey 2004/12/18 07:22:57

  jakarta-commons-sandbox/i18n/src/examples - New directory

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

cvs commit: jakarta-commons-sandbox/i18n/src/examples/org/apache - New directory

[dflorey]

dflorey 2004/12/18 07:22:57

  jakarta-commons-sandbox/i18n/src/examples/org/apache - New directory

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

cvs commit: jakarta-commons-sandbox/i18n build.xml

[dflorey]

dflorey 2004/12/18 07:22:42

  Modified:i18n build.xml
  Log:
  Added support for pluggable MessageProviders and added 
ResourceBundleMessageProvider
  to enable migration from resource bundle based applications to i18n.
  
  Revision  ChangesPath
  1.3   +1 -1  jakarta-commons-sandbox/i18n/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/jakarta-commons-sandbox/i18n/build.xml,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- build.xml 16 Oct 2004 17:35:01 -  1.2
  +++ build.xml 18 Dec 2004 15:22:42 -  1.3
  @@ -18,7 +18,7 @@


   
  - 
  + 

[Jakarta Commons Wiki] Updated: Logging

[commons-dev]

   Date: 2004-12-18T07:12:53
   Editor: 82.38.65.173 <>
   Wiki: Jakarta Commons Wiki
   Page: Logging
   URL: http://wiki.apache.org/jakarta-commons/Logging

   no comment

Change Log:

--
@@ -19,3 +19,9 @@
  * Ever get irratated with enclosing your log statements in conditionals?  
[http://just4log.sourceforge.net/ Just4Log] engineers the bytecode so that 
every log statements has a conditional wrapper!
 
 
+
+== Design ==
+
+ * /ConfigurationDesign
+
+

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

cvs commit: jakarta-commons-sandbox/i18n/src/java/org/apache/commons/i18n XMLMessageProvider.java MessageProvider.java ResourceBundleMessageProvider.java LocalizedBundle.java MessageManager.java

[dflorey]

dflorey 2004/12/18 07:08:50

  Modified:i18n/src/java/org/apache/commons/i18n LocalizedBundle.java
MessageManager.java
  Added:   i18n/src/java/org/apache/commons/i18n
XMLMessageProvider.java MessageProvider.java
ResourceBundleMessageProvider.java
  Log:
  Added support for pluggable MessageProviders and added 
ResourceBundleMessageProvider
  to enable migration from resource bundle based applications to i18n.
  
  Revision  ChangesPath
  1.2   +41 -3 
jakarta-commons-sandbox/i18n/src/java/org/apache/commons/i18n/LocalizedBundle.java
  
  Index: LocalizedBundle.java
  ===
  RCS file: 
/home/cvs/jakarta-commons-sandbox/i18n/src/java/org/apache/commons/i18n/LocalizedBundle.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- LocalizedBundle.java  4 Oct 2004 13:41:09 -   1.1
  +++ LocalizedBundle.java  18 Dec 2004 15:08:49 -  1.2
  @@ -25,6 +25,13 @@
   
   import java.util.Locale;
   
  +/**
  + * @author Daniel Florey
  + * 
  + * The LocalizedBundle class represents a bundle of localized messages that
  + * belong together.
  + * 
  + */
   public class LocalizedBundle {
   public final static String ID = "id";
   public final static String ARGUMENTS = "arguments";
  @@ -32,28 +39,59 @@
   protected String id;
   protected Object[] arguments;
   
  +/**
  + * @param messageId The messageId refers the corresponding bundle in the 
file containing
  + * the localized messages. The format of the message file depends on the 
implementation of the 
  + * MessageManager.
  + */
   public LocalizedBundle(String messageId) {
   this.id = messageId;
   this.arguments = new Object[0];
   }
   
  +/**
  + * @param messageId The messageId refers the corresponding bundle in the 
file containing
  + * the localized messages. The format of the message file depends on the 
implementation of the 
  + * MessageManager.
  + * @param arguments An array of objects containing argument for the 
messages. These arguments
  + * are used to insert dynamic values into the localized messages.
  + */
   public LocalizedBundle(String messageId, Object[] arguments) {
   this.id = messageId;
   this.arguments = arguments;
   }
   
  +/**
  + * @return returns the id of this bundle
  + */
   public String getId() {
   return id;
   }
   
  +/**
  + * @return returns the arguments associated with this message bundle
  + */
   public Object[] getArguments() {
return arguments;
   }
   
  +/**
  + * @param key the key of the specific message entry in the message bundle
  + * @param locale the locale for that this message should be rendered
  + * @return returns the localized text  
  + * @throws MessageNotFoundException if an entry with the given key can 
not be found
  + * in this bundle
  + */
   public String getText(String key, Locale locale) throws 
MessageNotFoundException {
   return MessageManager.getText(id, key, arguments, locale);
   }
   
  +/**
  + * @param key the key of the specific message entry in the message bundle
  + * @param locale the locale for that this message should be rendered
  + * @param defaultText the text to be returned if no entry was found for 
the given key
  + * @return returns the localized text  
  + */
   public String getText(String key, String defaultText, Locale locale) {
   return MessageManager.getText(id, key, arguments, locale, 
defaultText);
   }
  
  
  
  1.3   +45 -184   
jakarta-commons-sandbox/i18n/src/java/org/apache/commons/i18n/MessageManager.java
  
  Index: MessageManager.java
  ===
  RCS file: 
/home/cvs/jakarta-commons-sandbox/i18n/src/java/org/apache/commons/i18n/MessageManager.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- MessageManager.java   16 Oct 2004 17:41:16 -  1.2
  +++ MessageManager.java   18 Dec 2004 15:08:49 -  1.3
  @@ -1,201 +1,62 @@
   /*
  - * $Header$
  - * $Revision$
  - * $Date$
  - *
  - * 
  - *
  - * 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

cvs commit: jakarta-commons-sandbox/contract/src/java/org/apache/commons/contract/util MainWrapper.java

[dflorey]

dflorey 2004/12/18 07:07:54

  Modified:contract/src/examples/org/apache/commons/contract/example
TestLogin.java TestSpeedCalculator.java
   contract/src/java/org/apache/commons/contract Executor.java
   contract/src/java/org/apache/commons/contract/util
MainWrapper.java
  Log:
  Updated contract to i18n 0.3
  
  Revision  ChangesPath
  1.2   +2 -2  
jakarta-commons-sandbox/contract/src/examples/org/apache/commons/contract/example/TestLogin.java
  
  Index: TestLogin.java
  ===
  RCS file: 
/home/cvs/jakarta-commons-sandbox/contract/src/examples/org/apache/commons/contract/example/TestLogin.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- TestLogin.java18 Dec 2004 13:52:16 -  1.1
  +++ TestLogin.java18 Dec 2004 15:07:53 -  1.2
  @@ -21,11 +21,11 @@
   
   import org.apache.commons.contract.Result;
   import org.apache.commons.contract.util.InteractiveMainWrapper;
  -import org.apache.commons.i18n.MessageManager;
  +import org.apache.commons.i18n.XMLMessageProvider;
   
   public class TestLogin {
   public static void main(String[] args) {
  -MessageManager.install("contract/example", 
Thread.currentThread().getContextClassLoader().getResourceAsStream("example.xml"));
  +XMLMessageProvider.install("contract/example", 
Thread.currentThread().getContextClassLoader().getResourceAsStream("example.xml"));
   Result result = InteractiveMainWrapper.main(args, new 
LoginProcessor());
   if ( result != Result.OK ) {
   System.out.println("Login ist fehlgeschlagen.");
  
  
  
  1.2   +2 -2  
jakarta-commons-sandbox/contract/src/examples/org/apache/commons/contract/example/TestSpeedCalculator.java
  
  Index: TestSpeedCalculator.java
  ===
  RCS file: 
/home/cvs/jakarta-commons-sandbox/contract/src/examples/org/apache/commons/contract/example/TestSpeedCalculator.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- TestSpeedCalculator.java  18 Dec 2004 13:52:16 -  1.1
  +++ TestSpeedCalculator.java  18 Dec 2004 15:07:53 -  1.2
  @@ -21,11 +21,11 @@
   
   import org.apache.commons.contract.Result;
   import org.apache.commons.contract.util.InteractiveMainWrapper;
  -import org.apache.commons.i18n.MessageManager;
  +import org.apache.commons.i18n.XMLMessageProvider;
   
   public class TestSpeedCalculator {
   public static void main(String[] args) {
  -MessageManager.install("contract/example", 
Thread.currentThread().getContextClassLoader().getResourceAsStream("example.xml"));
  +XMLMessageProvider.install("contract/example", 
Thread.currentThread().getContextClassLoader().getResourceAsStream("example.xml"));
   Result result = InteractiveMainWrapper.main(args, new 
SpeedCalculator());
   if ( result != null ) {
   System.out.println("Speed: 
"+result.getResultEntries().get(SpeedCalculator.SPEED));
  
  
  
  1.4   +3 -3  
jakarta-commons-sandbox/contract/src/java/org/apache/commons/contract/Executor.java
  
  Index: Executor.java
  ===
  RCS file: 
/home/cvs/jakarta-commons-sandbox/contract/src/java/org/apache/commons/contract/Executor.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- Executor.java 7 Dec 2004 20:52:18 -   1.3
  +++ Executor.java 18 Dec 2004 15:07:53 -  1.4
  @@ -9,12 +9,12 @@
   import org.apache.commons.contract.descriptor.ResultDescriptor;
   import org.apache.commons.contract.descriptor.ResultEntryDescriptor;
   import org.apache.commons.i18n.LocalizedError;
  -import org.apache.commons.i18n.MessageManager;
  +import org.apache.commons.i18n.XMLMessageProvider;
   
   public class Executor {
   static {
  -MessageManager.install("contract/exceptions", 
Thread.currentThread().getContextClassLoader().getResourceAsStream("exceptions.xml"));
  -MessageManager.install("contract/constraints", 
Thread.currentThread().getContextClassLoader().getResourceAsStream("constraints.xml"));
  +XMLMessageProvider.install("contract/exceptions", 
Thread.currentThread().getContextClassLoader().getResourceAsStream("exceptions.xml"));
  +XMLMessageProvider.install("contract/constraints", 
Thread.currentThread().getContextClassLoader().getResourceAsStream("constraints.xml"));
   }
   
   public static void init() {};
  
  
  
  1.5   +2 -2  
jakarta-commons-sandbox/contract/src/java/org/apache/commons/contract/util/MainWrapper.java
  
  Index: MainWrapper.java
  ===
  RCS file: 
/home/cvs/jakarta-commons-sandbox/contract/src/java/org/apache/com

cvs commit: jakarta-commons-sandbox/contract/lib commons-i18n-0.3.jar commons-i18n-0.2.jar

[dflorey]

dflorey 2004/12/18 07:07:44

  Added:   contract/lib commons-i18n-0.3.jar
  Removed: contract/lib commons-i18n-0.2.jar
  Log:
  Updated contract to i18n 0.3
  
  Revision  ChangesPath
  1.1  jakarta-commons-sandbox/contract/lib/commons-i18n-0.3.jar
  
<>
  
  

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

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

[robert burrell donkin]

On 17 Dec 2004, at 22:32, Chris Lambrou wrote:
Someone suggested that for Log, it would be appropriate to make it an 
abstract class rather than an interface, so we can make these kinds 
of changes easier in the future.  I think the risks for this are low, 
and probably better [less problems for the majority of users] than 
just adding new methods to the existing interface.  Other thoughts on 
this direction?

I think the risk of annoying quite a number of users by changing Log 
from an interface to an abstract class is actually quite high. For 
sure, one of the default logging implementations provided by JCL would 
probably suffice for the majority. However, there are groups who will 
have chosen, for whatever reason, to provide their own logging 
implementations. I've certainly worked on a couple of projects where 
this has been the case. One of them could probably cope with the 
change relatively easiliy, but such a change could be a real pain for 
the other. Whilst the proportion of JCL users in this situation is 
probably quite small, in terms of actual numbers, such a change could 
cause quite a lot of grief.
i think that simon was suggesting the new logical interface proposed is 
implemented (in java) as an empty abstract class as opposed to a 
interface. this would allow new methods to be added without breaking 
compatibility but at the cost of preventing implementations belonging 
to another type hierarchy.

does anyone think that there is any real need for implementations to 
belong to a second type hierarchy?

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

[jira] Commented: (JELLY-177) In JellyServlet, the procedure used to determine the script's location is too simplistic

[Marc DeXeT (JIRA)]

 [ 
http://nagoya.apache.org/jira/browse/JELLY-177?page=comments#action_56841 ]
 
Marc DeXeT commented on JELLY-177:
--

I use your modification for a couple of days. It's working fine indeed.
It solves suffix context mapping problem I have encoutered by past.
Really great stuff.
I'm not HTTP/Servlet/JSP expert, but it's looking to be promoted. 

> In JellyServlet, the procedure used to determine the script's location is too 
> simplistic
> 
>
>  Key: JELLY-177
>  URL: http://nagoya.apache.org/jira/browse/JELLY-177
>  Project: jelly
> Type: Bug
>   Components: core / taglib.core
> Versions: 1.0
>  Environment: Servlet, 1.0RC1
> Reporter: Denis Robert
> Priority: Minor

>
> In JellyServlet, the procedure used to determine the script's location is too 
> simplistic; it misses simple cases like the a *.jelly servlet-mapping.
> I suggest replacing the getScript method with something like (taken in part 
> from the Freemarker servlet):
> protected URL getScript(HttpServletRequest req)
>   throws MalformedURLException {
>   String scriptUrl = null;
>   
>   String includedPath = (String) 
> req.getAttribute("javax.servlet.include.servlet_path");
>   if (includedPath != null) { //This is the result of a 
> RequestDispatcher include...
>   String includedPathInfo = (String) 
> req.getAttribute("javax.servlet.include.path_info");
>   if (includedPathInfo != null) {
>   scriptUrl = includedPathInfo;
>   } else {
>   scriptUrl = includedPath;
>   }
>   } else {
>   scriptUrl = req.getParameter("script");
>   if (scriptUrl == null) {
>   scriptUrl = req.getPathInfo();
>   }
>   if (scriptUrl == null) {
>   scriptUrl = req.getServletPath();
>   }
>   }
>   
>   URL url = getServletContext().getResource(scriptUrl);
>   if (url == null) {
>   throw new IllegalArgumentException("Invalid script url:"
>   + scriptUrl);
>   }
>   return url;
>   }

-- 
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-sandbox/contract/src/java/org/apache/commons/contract/util MainWrapper.java InteractiveMainWrapper.java

[dflorey]

dflorey 2004/12/18 05:52:16

  Modified:contract/src/examples/org/apache/commons/contract/example
SpeedCalculator.java
   contract/src/config constraints.xml example.xml
   contract/src/java/org/apache/commons/contract/constraints
BooleanConstraints.java Unconstrained.java
MapConstraints.java DateConstraints.java
ArrayConstraints.java ListConstraints.java
LocaleConstraints.java
   contract/src/java/org/apache/commons/contract/util
MainWrapper.java InteractiveMainWrapper.java
  Added:   contract/src/examples/org/apache/commons/contract/example
TestLogin.java LoginProcessor.java
TestSpeedCalculator.java
  Removed: contract/src/examples/org/apache/commons/contract/example
SimpleMain.java
  Log:
  Improved constraint classes
  
  Revision  ChangesPath
  1.2   +21 -17
jakarta-commons-sandbox/contract/src/examples/org/apache/commons/contract/example/SpeedCalculator.java
  
  Index: SpeedCalculator.java
  ===
  RCS file: 
/home/cvs/jakarta-commons-sandbox/contract/src/examples/org/apache/commons/contract/example/SpeedCalculator.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- SpeedCalculator.java  8 Oct 2004 10:44:57 -   1.1
  +++ SpeedCalculator.java  18 Dec 2004 13:52:16 -  1.2
  @@ -43,35 +43,39 @@
   private final static String MINUTES = "min";
   private final static String HOURS = "h";
   
  -ParameterDescriptor[] parameterDescriptors = new ParameterDescriptor[]{
  -new ParameterDescriptor(DISTANCE, new 
ParameterMessage("computeSpeed/parameter/distance"), 
  -new NumberConstraints(
  +private ParameterDescriptor[] parameterDescriptors = new 
ParameterDescriptor[]{
  +new ParameterDescriptor(DISTANCE, new ParameterMessage(
  +"computeSpeed/parameter/distance"), new 
NumberConstraints(
   new Integer(0), null, true)),
  -new ParameterDescriptor(UNIT, new 
ParameterMessage("computeSpeed/parameter/unit"), 
  -new StringConstraints(
  +new ParameterDescriptor(UNIT, new ParameterMessage(
  +"computeSpeed/parameter/unit"), new StringConstraints(
   new String[]{SECONDS, MINUTES, HOURS})),
  -new ParameterDescriptor(TIME, new 
ParameterMessage("computeSpeed/parameter/time"), 
  -NumberConstraints.POSITIVE)};
  -
  -ResultDescriptor[] resultDescriptors = new ResultDescriptor[]{new 
ResultDescriptor(
  +new ParameterDescriptor(TIME, new ParameterMessage(
  +"computeSpeed/parameter/time"), 
NumberConstraints.POSITIVE)};
  +
  +private ResultDescriptor[] resultDescriptors = new 
ResultDescriptor[]{new ResultDescriptor(
   StateDescriptor.OK_DESCRIPTOR,
   new ResultEntryDescriptor[]{new ResultEntryDescriptor(SPEED,
   new LocalizedMessage("computeSpeed/result/speed"),
  -new NumberConstraints(new Float(0.1), new 
Integer(Integer.MAX_VALUE)))})};
  -
  +new NumberConstraints(new Float(0.1), new Integer(
  +Integer.MAX_VALUE)))})};
  +
   /**
* Computes the speed in meter per second from the given distance and 
time.
* The time can be given in seconds, minutes or hours, depending on the
* content of timeUnit.
*/
   public Result process(Map parameters, Context context) {
  -float distance = ((Number)parameters.get(DISTANCE)).floatValue();
  -float time = ((Number)parameters.get(TIME)).floatValue();
  -String timeUnit = (String)parameters.get(UNIT);
  +float distance = ((Number) parameters.get(DISTANCE)).floatValue();
  +float time = ((Number) parameters.get(TIME)).floatValue();
  +String timeUnit = (String) parameters.get(UNIT);
   float speed;
  -if (timeUnit.equals("s")) speed = distance / time;
  -else if (timeUnit.equals("min")) speed = distance*60 / time;
  -else speed = distance*3600 / time;
  +if (timeUnit.equals("s"))
  +speed = distance / time;
  +else if (timeUnit.equals("min"))
  +speed = distance * 60 / time;
  +else
  +speed = distance * 3600 / time;
   return new Result(StateDescriptor.OK, SPEED, new Float(speed));
   }
   
  
  
  
  1.1  
jakarta-commons-sandbox/contract/src/examples/org/apache/commons/contract/example/TestLogin.java
  
  Index: TestLogin.java
  ===
  /*

DO NOT REPLY [Bug 32756] - [digester] Exact patterns overwrite patterns with wildcards

[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=32756


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |ASSIGNED




--- Additional Comments From [EMAIL PROTECTED]  2004-12-18 12:19 ---
This behaviour is deliberate, and not a bug. Wildcard patterns are ignored if an
explicit match can be found (and when multiple wildcard patterns match, only the
longest, ie most explicit, pattern is considered a match).

The intent is that rules can be added for "an  tag anywhere", but then for
that behaviour to be explicitly overridden for specific cases, eg "but not an
 that is a direct child of an ".

If you have rules A and B registered for pattern "*/a", then want to add an
additional rule C for pattern "x/a" only, then what you need to do is add
*three* rules for "x/a": A,B and C.

Note that by using
  Rule ruleA = new ObjectCreateRule();
  Rule ruleB = new SetNextRule();
  Rule ruleC = new SetPropertiesRule();

  digester.addRule("*/a", ruleA);
  digester.addRule("*/a", ruleB);
  digester.addRule("x/a", ruleA);
  digester.addRule("x/a", ruleB);
  digester.addRule("x/a", ruleC);

you have associated the same rule instances A and B with multiple patterns, thus
avoiding creating extra rule object instances.

I agree this behaviour (explicit rules override wildcard rules in the default
RulesBase rule-matching class) is not properly documented, and will leave this
bug open as a reminder to add proper javadocs on this subject.

Sorry if this caused any confusion...

NB1: I don't see why your datadecriptor/.../property patterns didn't match. They
should as far as I can see.

NB2: In general, I think SetRootRule should be avoided as it *generally* implies
that the xml's explicit nesting is not being properly respected. I suggest using
alternative rules if possible.

-- 
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: Jakarta Commons Structure rehashed

[Brett Porter]

Option A + some sort of symlink structure sounds like a good idea. Does 
subversion have some way of creating module aliases like what could be 
done for CVS? This makes sense to be able to do this natively without 
having to create symlinks. Maybe a feature request :)

Another reason for Option A other than those already listed is that it 
is consistent with what other projects have already started to adopt 
(that I've seen), and that goes a long way to ease of use in itself.

Cheers,
Brett
Simon Kitching wrote:
svn 1.1 (released 2004-09-29) supports "symbolic links". Perhaps that
would resolve the issue by allowing us to (manually) build an
alternative directory containing just symbolic links to the "trunk"
directory of each subproject? Of course whenever a new subproject was
created, a symbolic link would need to be manually added - but that is
no great problem. Possibly that could even be automated; I'm willing to
try to get that working.
Regards,
Simon
On Sat, 2004-12-18 at 12:10, Henri Yandell wrote:
 

And yet option A is going to be impossible (?) to check out as one whole blob.
I wonder if there's any magic coming from the SVN guys that'll let us
do option B and yet provide a link of some kind to automatically be
able to check out all the trunks in one go.
Hen
On Fri, 17 Dec 2004 14:01:53 -0700, Kris Nuttycombe
<[EMAIL PROTECTED]> wrote:
   

Option A makes the projects look a lot more atomic, which seems like a
good idea when one contemplates what will be necessary when promoting
projects from the sandbox.
Kris
Tim O'Brien wrote:
 

I don't think we ever settled this question.
Which SVN structure are we interested in?
** Option A:
jakarta/
  commons/
  digester/
  trunk/
  tags/
  branches/
  beanutils/
  trunk/
  tags/
  branches/
OR
** Option B:
jakarta/
  commons/
  trunk/
  digester/
  beanutils/
  tags/
  digester/
  beanutils/
  branches/
  digester/
  beanutils/

   


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

Re: Jakarta Commons Structure rehashed

[Emmanuel Bourg]

Henri Yandell wrote:
And yet option A is going to be impossible (?) to check out as one whole blob.
And what about this option ? Let say option C :
trunk/
jakarta/
commons/
digester/
beanutils/
tags/
branches/
Emmanuel Bourg


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [proposal] avoiding jar version nightmares

[Emmanuel Bourg]

Matt Sgarlata wrote:
This seems to me that this isn't just a problem with commons; it is a 
problem with Java itself that .NET already has a very nice solution for. 
 I'm wondering if this isn't something that should be taken care of at 
the JVM level i.e. - in Java 1.6.  The obvious solution seems to be that 
we need to fix classloaders.  They're already a huge nightmare in EJB 
containers.

How do we go about petitioning Sun for something like this?
Isn't the isolate API (JSR 121) supposed to address this issue ?
Emmanuel Bourg


smime.p7s
Description: S/MIME Cryptographic Signature

[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 28 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-18122004.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-18122004 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-18122004.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/dist/junit/junit.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-18122004.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-18122004.jar:/usr/local/gump/public/workspace/jakarta-commons/lang/dist/commons-lang-18122004.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/jakarta-commons/cli/target/commons-cli-18122004.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-18122004.jar:/usr/local/gump/public/workspace/jelly-tags/junit/target/commons-jelly-tags-junit-18122004.jar:/usr/local/gump/public/workspace/jelly-tags/ant/target/commons-jelly-tags-ant-18122004.jar:/usr/local/gump/public/workspace/jakarta-commons-sandbox/grant/target/commons-grant-18122004.jar:/usr/local/gump/public/workspace/jelly-tags/log/target/commons-jelly-tags-log-18122004.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]   ^
[javac] 
/home/gu