Re: [jelly] failure since RC1

[Dion Gillard]

This seems fine.


On Tue, 28 Dec 2004 13:48:22 +1100, Brett Porter <[EMAIL PROTECTED]> wrote:
> It appears the call to output.flush() was added and output was always null.
> 
> I've added an if(output !=null) around the flush call - can someone let
> me know if this isn't a valid state and requires further investigation.
> 
> THanks,
> Brett
> 
> Brett Porter wrote:
> 
> > I just updated the Jelly dependency on Maven's CVS HEAD from beta-4
> > (which I verified as working) to the latest and got a failure. Going
> > back, I found the same problem with Jelly RC1.
> >
> > The call to output.flush() currently on line 242 of TagScript.java is
> > throwing a NullPointerException. Any ideas how output gets to be null?
> >
> > I'll investigate some more.
> >
> > - Brett
> >
> > -
> > 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]
> 
> 


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

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

cvs commit: jakarta-commons/jelly/src/java/org/apache/commons/jelly/impl TagScript.java

[brett]

brett   2004/12/27 20:07:34

  Modified:jelly/src/java/org/apache/commons/jelly/impl TagScript.java
  Log:
  allow output to be null
  
  Revision  ChangesPath
  1.48  +4 -2  
jakarta-commons/jelly/src/java/org/apache/commons/jelly/impl/TagScript.java
  
  Index: TagScript.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/jelly/src/java/org/apache/commons/jelly/impl/TagScript.java,v
  retrieving revision 1.47
  retrieving revision 1.48
  diff -u -r1.47 -r1.48
  --- TagScript.java28 Dec 2004 01:39:22 -  1.47
  +++ TagScript.java28 Dec 2004 04:07:34 -  1.48
  @@ -239,7 +239,9 @@
   }
   
   tag.doTag(output);
  -output.flush();
  +if (output != null) {
  +output.flush();
  +}
   }
   catch (JellyTagException e) {
   handleException(e);
  
  
  

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

Re: [CLI] Status

[David Morris]

Rob,

Thanks for applying all of the patches and getting CLI into shape. I
will supply a test case for 32533. I have been working on an XMLBuilder
that uses an XML document to describe Options, Arguements, and Groups.
Hopefully it will be useful to CLI. While working on this I found that
not all properties are exposed from Groups and Arguements through the
current builders. Do you expect that to change? If it won't change then
I will go with the properties exposed by the current builders. If it
will/could, I will go to the base classes. An example is id for group.

It also looks like some values like an argument validator are singletons
but the ArgumentBuilder doesn't seem to enforce this. In the case of
validator, it seems useful to allow more than one.

Could you look this empty XML document and schema and let me know if it
seems reasonable:


http://www.w3.org/2001/XMLSchema-instance";>
  



  




  
  

  


  
  

  



http://www.w3.org/2001/XMLSchema";>


















































--David

>>> [EMAIL PROTECTED] 12/23/2004 5:55:18 AM >>>
Hi,

Sorry for the lack of response to your patch, I've been really busy
with the 
day job lately and CLI2 has effectively stalled in the meantime. 
Hopefully 
I'll find some time between xmas and new year to get things in motion
again. 
The main thing that needs doing is to go through bugzilla reviewing
patches 
and deciding how to resolve/when to target the other bugs.

Once that is done then its just a case of going through the release
process:
http://jakarta.apache.org/commons/releases/index.html 

Obviously it'd be great to have you on hand to discuss any 
thoughts/implications regarding your patch (might even get time to look
at 
that this afternoon); but if you have any thoughts / patches regarding
other 
issues or documentation then please let me know!  Also if anything in
the 
releases doc looks doable then you're welcome to take it on.

Thanks,

Rob

David Morris wrote:
> I used the COMMONS CLI package for a couple of recent projects and I
ran
> into some serious problems and submitted some patches. Next, I tried
> version 2, which appears to be a ground up rewrite. It worked a lot
> better after a couple of minor tweaks and a patch. I don't see much
> activity lately in CVS. I need this to be a released product. In
> addition to patches for the outstanding issues, is there anything
else I
> can do to help this get moving?
> 
> David

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

Re: Distributions to include dependencies?

[Henri Yandell]

> On Mon, 27 Dec 2004 15:48:00 -0800, Martin Cooper <[EMAIL PROTECTED]> wrote:
> 
> > Not me. Doing this will lead to people having multiple copies of
> > various component jars lying around on their disks, and will
> > unnecessarily increase the amount of stuff that people need to
> > download.
 
 Definitely true, but it's petty change however. The people who have
 this problem (clutter) are likely to have this problem already.
 
> > For example, suppose I use Digester and Betwixt. I download them both,
> > and now I have two copies of Digester, BeanUtils and Logging. But if I
> > actually wanted to use BeanUtils itself, I'd need to download it
> > again, because I only have the jar file, and not the JavaDocs or other
> > contents of the distro.
 
 This partly leads me on to a different issue that I think we need to
 improve; Javadoc management; but I don't think this is a very big
 deal.
 
> > It's also not clear to me that every component is going to comprise a
> > single jar for the purposes of inclusion into another distro. In such
> > cases, there would need to be some well-defined structure for the
> > additional files.
 
 This is already solved in the project.xml.
 
> > One more: How do you define dependencies? What happens in cases such
> > as Resources, where there are multiple optional implementations? Do we
> > include all of them, or just some of them, and how would we decide?
> 
 project.xml. You add a property to each dependency that you wish to
 include in the distribution. For an example like Resources, I've no
 idea. I imagine it would depend on the particular situation.
 
 Hen

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

Re: [jelly] failure since RC1

[Brett Porter]

It appears the call to output.flush() was added and output was always null.
I've added an if(output !=null) around the flush call - can someone let 
me know if this isn't a valid state and requires further investigation.

THanks,
Brett
Brett Porter wrote:
I just updated the Jelly dependency on Maven's CVS HEAD from beta-4 
(which I verified as working) to the latest and got a failure. Going 
back, I found the same problem with Jelly RC1.

The call to output.flush() currently on line 242 of TagScript.java is 
throwing a NullPointerException. Any ideas how output gets to be null?

I'll investigate some more.
- Brett
-
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]

[jelly] failure since RC1

[Brett Porter]

I just updated the Jelly dependency on Maven's CVS HEAD from beta-4 
(which I verified as working) to the latest and got a failure. Going 
back, I found the same problem with Jelly RC1.

The call to output.flush() currently on line 242 of TagScript.java is 
throwing a NullPointerException. Any ideas how output gets to be null?

I'll investigate some more.
- Brett
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-commons/jelly/jelly-tags/xml project.xml

[brett]

brett   2004/12/27 17:59:41

  Modified:jellyproject.xml
   jelly/jelly-tags/xml project.xml
  Log:
  bump version
  
  Revision  ChangesPath
  1.158 +1 -1  jakarta-commons/jelly/project.xml
  
  Index: project.xml
  ===
  RCS file: /home/cvs/jakarta-commons/jelly/project.xml,v
  retrieving revision 1.157
  retrieving revision 1.158
  diff -u -r1.157 -r1.158
  --- project.xml   5 Dec 2004 04:07:53 -   1.157
  +++ project.xml   28 Dec 2004 01:59:41 -  1.158
  @@ -20,7 +20,7 @@
 3
 commons-jelly
 commons-jelly
  -  1.0-RC1
  +  1.0-RC2-SNAPSHOT
 
   Apache Software Foundation
   http://jakarta.apache.org
  
  
  
  1.15  +2 -2  jakarta-commons/jelly/jelly-tags/xml/project.xml
  
  Index: project.xml
  ===
  RCS file: /home/cvs/jakarta-commons/jelly/jelly-tags/xml/project.xml,v
  retrieving revision 1.14
  retrieving revision 1.15
  diff -u -r1.14 -r1.15
  --- project.xml   30 Nov 2004 10:42:35 -  1.14
  +++ project.xml   28 Dec 2004 01:59:41 -  1.15
  @@ -18,7 +18,7 @@
 ${basedir}/../tag-project.xml
 commons-jelly-tags-xml
 commons-jelly-tags-xml
  -  1.0
  +  1.1-SNAPSHOT
   
 org.apache.commons.jelly.tags.xml
   
  @@ -44,7 +44,7 @@
   
 commons-jelly
 commons-jelly
  -  1.0-RC1
  +  1.0-RC2-SNAPSHOT
   
 
   
  
  
  

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

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

[Brett Porter]

The test is failing for me. Is that to be expected?
[EMAIL PROTECTED] wrote:
polx2004/12/27 17:39:23
 Modified:jelly/src/java/org/apache/commons/jelly/impl
   StaticTagScript.java TagScript.java
  jelly/src/java/org/apache/commons/jelly JellyContext.java
  jelly/jelly-tags/xml/src/test/org/apache/commons/jelly/tags/xml
   TestParser.java
  jelly/jelly-tags/xml/src/java/org/apache/commons/jelly/tags/xml
   TransformTag.java
  jelly/src/java/org/apache/commons/jelly/util TagUtils.java
 Added:   jelly/src/test/org/apache/commons/jelly/core
   TestCoreMemoryLeak.java BaseMemoryLeakTest.java
 Removed: jelly/src/java/org/apache/commons/jelly/impl
   WeakReferenceWrapperScript.java
 Log:
 Tag caching is now done in the JellyContext.
 The TestCoreMemoryLeak shows that, at least with some usage of JellyContext.clear(), one avoids leaks.
 Removing Tag-caching flag. Also, removing the WeakReferenceWrapperScript, both were in the era of ThreadLocal which is to be finished.
 
 Have tested these with an amount of the tag-libs... had to change the XML one but otherwise apparently none.
 
 Feedback and testing eagerly welcome!
 paul
 
 Revision  ChangesPath
 1.25  +2 -2  jakarta-commons/jelly/src/java/org/apache/commons/jelly/impl/StaticTagScript.java
 
 Index: StaticTagScript.java
 ===
 RCS file: /home/cvs/jakarta-commons/jelly/src/java/org/apache/commons/jelly/impl/StaticTagScript.java,v
 retrieving revision 1.24
 retrieving revision 1.25
 diff -u -r1.24 -r1.25
 --- StaticTagScript.java	16 Sep 2004 01:12:11 -	1.24
 +++ StaticTagScript.java	28 Dec 2004 01:39:22 -	1.25
 @@ -59,14 +59,14 @@
  
  Tag tag = null;
  try {
 -tag = getTag();
 +tag = getTag(context);
  
  // lets see if we have a dynamic tag
  if (tag instanceof StaticTag) {
  tag = findDynamicTag(context, (StaticTag) tag);
  }
  
 -setTag(tag);
 +setTag(tag,context);
  } catch (JellyException e) {
  throw new JellyTagException(e);
  }
 
 
 
 1.47  +12 -31jakarta-commons/jelly/src/java/org/apache/commons/jelly/impl/TagScript.java
 
 Index: TagScript.java
 ===
 RCS file: /home/cvs/jakarta-commons/jelly/src/java/org/apache/commons/jelly/impl/TagScript.java,v
 retrieving revision 1.46
 retrieving revision 1.47
 diff -u -r1.46 -r1.47
 --- TagScript.java	27 Oct 2004 21:50:53 -	1.46
 +++ TagScript.java	28 Dec 2004 01:39:22 -	1.47
 @@ -61,15 +61,6 @@
  /** The Log to which logging calls will be made. */
  private static final Log log = LogFactory.getLog(TagScript.class);
  
 -/**
 - * Thread local storage for the tag used by the current thread.
 - * This allows us to pool tag instances, per thread to reduce object construction
 - * over head, if we need it.
 - *
 - * Note that we could use the stack and create a new tag for each invocation
 - * if we made a slight change to the Script API to pass in the parent tag.
 - */
 -private ThreadLocal tagHolder = new ThreadLocal();
  
  /** The attribute expressions that are created */
  protected Map attributes = new Hashtable();
 @@ -194,11 +185,8 @@
  public void run(JellyContext context, XMLOutput output) throws JellyTagException {
  URL rootURL = context.getRootURL();
  URL currentURL = context.getCurrentURL();
 -if ( ! context.isCacheTags() ) {
 -clearTag();
 -}
  try {
 -Tag tag = getTag();
 +Tag tag = getTag(context);
  if ( tag == null ) {
  return;
  }
 @@ -295,15 +283,15 @@
  /**
   * @return the tag to be evaluated, creating it lazily if required.
   */
 -public Tag getTag() throws JellyException {
 -Tag tag = (Tag) tagHolder.get();
 +public Tag getTag(JellyContext context) throws JellyException {
 +Tag tag = context.getTagOfTagScript(this);
  if ( tag == null ) {
  tag = createTag();
  if ( tag != null ) {
 -tagHolder.set(tag);
 +context.setTagForScript(this,tag);
  }
  }
 -configureTag(tag);
 +configureTag(tag,context);
  return tag;
  }
  
 @@ -494,21 +482,20 @@
  return null;
  }
  
 -
 +	
  /**
   * Compiles a newly created tag if required, sets its parent and body.
   */
 -protected void configureTag(Tag tag) throws JellyException {
 +protected void configureTag(Tag tag, JellyContext context) throws JellyException {
  if (tag instanceof CompilableTag) {
  ((CompilableTag) tag).c

cvs commit: jakarta-commons/jelly/src/test/org/apache/commons/jelly/core BaseMemoryLeakTest.java

[polx]

polx2004/12/27 17:46:36

  Modified:jelly/src/test/org/apache/commons/jelly/core
BaseMemoryLeakTest.java
  Log:
  The tagHolderMap size was reported way too often...
  paul
  
  Revision  ChangesPath
  1.2   +5 -5  
jakarta-commons/jelly/src/test/org/apache/commons/jelly/core/BaseMemoryLeakTest.java
  
  Index: BaseMemoryLeakTest.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/jelly/src/test/org/apache/commons/jelly/core/BaseMemoryLeakTest.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- BaseMemoryLeakTest.java   28 Dec 2004 01:39:23 -  1.1
  +++ BaseMemoryLeakTest.java   28 Dec 2004 01:46:36 -  1.2
  @@ -114,11 +114,10 @@
   
   script = parser.parse(scriptISource);
   script.run(jc, output);
  - log.info("TagHolderMap has " + 
jc.getTagHolderMap().size() + " entries.");
  - // PL: I don't see why but removing the clear here 
  - // does make the test fail!
  - // As if the WeakHashMap wasn't weak enough...
  - jc.clear();
  +// PL: I don't see why but removing the clear here 
  +// does make the test fail!
  +// As if the WeakHashMap wasn't weak enough...
  +jc.clear();
   
   if (outputEveryXIterations != 0 && i % outputEveryXIterations == 
0) {
   parser = null;
  @@ -127,6 +126,7 @@
   rt.runFinalization();
   rt.gc();
   long middle = rt.totalMemory() - rt.freeMemory();
  +log.info("TagHolderMap has " + jc.getTagHolderMap().size() + 
" entries.");
   log.info("Memory test after " + i + " runs: "
   + (middle - start));
   }
  
  
  

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

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

[polx]

polx2004/12/27 17:39:23

  Modified:jelly/src/java/org/apache/commons/jelly/impl
StaticTagScript.java TagScript.java
   jelly/src/java/org/apache/commons/jelly JellyContext.java
   jelly/jelly-tags/xml/src/test/org/apache/commons/jelly/tags/xml
TestParser.java
   jelly/jelly-tags/xml/src/java/org/apache/commons/jelly/tags/xml
TransformTag.java
   jelly/src/java/org/apache/commons/jelly/util TagUtils.java
  Added:   jelly/src/test/org/apache/commons/jelly/core
TestCoreMemoryLeak.java BaseMemoryLeakTest.java
  Removed: jelly/src/java/org/apache/commons/jelly/impl
WeakReferenceWrapperScript.java
  Log:
  Tag caching is now done in the JellyContext.
  The TestCoreMemoryLeak shows that, at least with some usage of 
JellyContext.clear(), one avoids leaks.
  Removing Tag-caching flag. Also, removing the WeakReferenceWrapperScript, 
both were in the era of ThreadLocal which is to be finished.
  
  Have tested these with an amount of the tag-libs... had to change the XML one 
but otherwise apparently none.
  
  Feedback and testing eagerly welcome!
  paul
  
  Revision  ChangesPath
  1.25  +2 -2  
jakarta-commons/jelly/src/java/org/apache/commons/jelly/impl/StaticTagScript.java
  
  Index: StaticTagScript.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/jelly/src/java/org/apache/commons/jelly/impl/StaticTagScript.java,v
  retrieving revision 1.24
  retrieving revision 1.25
  diff -u -r1.24 -r1.25
  --- StaticTagScript.java  16 Sep 2004 01:12:11 -  1.24
  +++ StaticTagScript.java  28 Dec 2004 01:39:22 -  1.25
  @@ -59,14 +59,14 @@
   
   Tag tag = null;
   try {
  -tag = getTag();
  +tag = getTag(context);
   
   // lets see if we have a dynamic tag
   if (tag instanceof StaticTag) {
   tag = findDynamicTag(context, (StaticTag) tag);
   }
   
  -setTag(tag);
  +setTag(tag,context);
   } catch (JellyException e) {
   throw new JellyTagException(e);
   }
  
  
  
  1.47  +12 -31
jakarta-commons/jelly/src/java/org/apache/commons/jelly/impl/TagScript.java
  
  Index: TagScript.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/jelly/src/java/org/apache/commons/jelly/impl/TagScript.java,v
  retrieving revision 1.46
  retrieving revision 1.47
  diff -u -r1.46 -r1.47
  --- TagScript.java27 Oct 2004 21:50:53 -  1.46
  +++ TagScript.java28 Dec 2004 01:39:22 -  1.47
  @@ -61,15 +61,6 @@
   /** The Log to which logging calls will be made. */
   private static final Log log = LogFactory.getLog(TagScript.class);
   
  -/**
  - * Thread local storage for the tag used by the current thread.
  - * This allows us to pool tag instances, per thread to reduce object 
construction
  - * over head, if we need it.
  - *
  - * Note that we could use the stack and create a new tag for each 
invocation
  - * if we made a slight change to the Script API to pass in the parent 
tag.
  - */
  -private ThreadLocal tagHolder = new ThreadLocal();
   
   /** The attribute expressions that are created */
   protected Map attributes = new Hashtable();
  @@ -194,11 +185,8 @@
   public void run(JellyContext context, XMLOutput output) throws 
JellyTagException {
   URL rootURL = context.getRootURL();
   URL currentURL = context.getCurrentURL();
  -if ( ! context.isCacheTags() ) {
  -clearTag();
  -}
   try {
  -Tag tag = getTag();
  +Tag tag = getTag(context);
   if ( tag == null ) {
   return;
   }
  @@ -295,15 +283,15 @@
   /**
* @return the tag to be evaluated, creating it lazily if required.
*/
  -public Tag getTag() throws JellyException {
  -Tag tag = (Tag) tagHolder.get();
  +public Tag getTag(JellyContext context) throws JellyException {
  +Tag tag = context.getTagOfTagScript(this);
   if ( tag == null ) {
   tag = createTag();
   if ( tag != null ) {
  -tagHolder.set(tag);
  +context.setTagForScript(this,tag);
   }
   }
  -configureTag(tag);
  +configureTag(tag,context);
   return tag;
   }
   
  @@ -494,21 +482,20 @@
   return null;
   }
   
  -
  + 
   /**
* Compiles a newly created tag if required, sets its parent and body.
*/
  -protected void configureTag(Tag tag) throws JellyException {
  +protected void configureTag(Tag tag, JellyContext context) throws 
J

Re: commons-logging auto-detection WAS: [logging] Enterprise Common Logging... dare we say 2.0?

[Matt Sgarlata]

I think often JCL will be used as you describe, but not always.
For example, let's say I am developing a component that monitors 
database activity and monitors usage statistics (this is a hypothetical 
example).  The main purpose of this component is to log messages to be 
processed later by a human.  I use JCL and put a 
commons-logging.properties in my org.dbmonitor package that says "use 
Log4J and display INFO and higher messages".

This component may be deployed in many different environments.  Here are 
two examples:
1) Standalone on a server.  In this case, the default settings specified 
at the component level should be used.
2) As a component of another application.  In this case, the overall 
application specifies logging properties that overwrite those in the 
component.  To do this, the application specifies a 
commons-logging.properties in the default package, which overwrites the 
properties specified at the component level.  In this example, the 
application chooses it only wants WARN and higher messages and that it 
wants the messages rendered with JDK 1.4 logging.

My point is that one overall configuration of logging for the entire JVM 
may be too restrictive.  I think we could benefit from multiple JCL 
configurations, each targeted at different parts of a system.

Matt
Ceki Gülcü wrote:
Matt,
JCL exists mainly for the purpose of libraries wishing to *integrate*
with the logging API chosen by the user by deferring the selection of
the logging impl to runtime. The author of library "net.sf.morph"
probably does *not* wish to impose any logging related property on the
end-user. Consequently, it does not make sense to have package
specific properties at the JCL level. Would you agree?
At 08:26 PM 12/27/2004, Matt Sgarlata wrote:
Couldn't this be refined even further by incorporating a change to JCL 
I proposed earlier?  Here's a copy of my original post:

I have an idea... All logging implementations for Java configure 
logging by package, right?  What if we allow component developers to 
include their own commons-logging.properties that's not at the root of 
the source tree?  For example, if Morph suddenly decided it was very 
important to have certain messages logged, I just drop a 
commons-logging.properties in net.sf.morph that specifies the logging 
settings for net.sf.morph and all subpackages (e.g. which log factory 
to use, whether my messages *must* be heard, etc).  If JCL detects 
such a file it ensure the component that the logging it specifies is 
happening.  If an application developer, assembler or deployer decides 
later that Morph really isn't as important as I'd like, then they just 
delete the commons-logging.properties or put their own version in the 
WEB-INF/classes directory.  (Forgive me if this is a great show of my 
ignorance of classloading, but I think this is at least how things 
work for Tomcat).

Searching for a file like this on the classpath would certainly have 
performance implications.  However, search cost is incurred only on 
startup and there is precedent (see below), so it can't be too bad. 
It's certainly worth a try.

http://java.sun.com/j2se/1.4.2/docs/api/java/beans/PropertyEditorManager.html 



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

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

[Ceki Gülcü]

On 2004-12-16 18:09:36, Richard Sitze wrote:
> ok, without going back to review exactly what I said in an earlier note, I
> had in mind something like:
>
>   commons-logging-core.jar   - core interface & factory class, NO config
>   commons-logging.jar- core + all helpers, NO config
>   commons-logging-.jar - core + ONE helper, ONE config
>
> With this scheme, I believe we can scrub the code from LogFactory that
> looks for an attempts to load specific logger impls [Log4J, Avalon, ?],
> and instead depend entirely on the config.
In commons-logging-.jar, I suppose by "ONE helper, ONE config"
you mean the necessary wiring to let commons-logging know that it
should use  and skip automatic discovery. This simple and robust
approach would probably alleviate many of the classloader problems
users have been hitting.
--
Ceki Gülcü
  The complete log4j manual: http://www.qos.ch/log4j/

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

Re: Distributions to include dependencies?

[Martin Cooper]

On Mon, 27 Dec 2004 16:38:03 -0500, Henri Yandell <[EMAIL PROTECTED]> wrote:
> Not a huge issue for things like Lang which have no dependencies, but
> for other things like Digester I think it would be a lot better if the
> binary tar.gz contained the jars it depends on?
> 
> So when I download digester-1.6, the tar.gz contains jars for
> logging-1.0.3 and beanutils-1.7. We're not forcing those versions on
> people, just providing them to save lots of searching around or
> waiting while iBiblio responds.
> 
> It seems pretty easy to do too from a maven.xml point of view:
> 
> 
> 
>  
>  
>
>
>  
> file="${maven.repo.local}/${dep.getGroupId()}/jars/${dep.getArtifact()}"/>
>  
>
>  
> 
> 
> You'd just add:
> 
> 
>  true
> 
> 
> to a dependency.
> 
> Anyone interested?

Not me. Doing this will lead to people having multiple copies of
various component jars lying around on their disks, and will
unnecessarily increase the amount of stuff that people need to
download.

For example, suppose I use Digester and Betwixt. I download them both,
and now I have two copies of Digester, BeanUtils and Logging. But if I
actually wanted to use BeanUtils itself, I'd need to download it
again, because I only have the jar file, and not the JavaDocs or other
contents of the distro.

It's also not clear to me that every component is going to comprise a
single jar for the purposes of inclusion into another distro. In such
cases, there would need to be some well-defined structure for the
additional files.

One more: How do you define dependencies? What happens in cases such
as Resources, where there are multiple optional implementations? Do we
include all of them, or just some of them, and how would we decide?

--
Martin Cooper


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

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

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

[Ceki Gülcü]

At 2004-12-16 16:51:31, Richard Sitze wrote:
> I do not advocate a fail-on-no-config or fail-on-ambiguous-config.
>
> I advocate a *warn* or *error* on either, using the simple default logger.
> The warning will be visible on the console, which suffices for my
> immediate concerns.  How that warning/error (in general) is managed is up
> to the application environment.
Log4j 1.3 can use itself for its own logging. So, when appender A
fails, it can report errors using appender B. Appender B could alert the
system admin if that is the desired behavior.
The same goes for configuration errors which are also accessible
programmatically. For example,
  Configurator c = new SomeLog4jConfigurator();
  c.configure("some file");
  List el = c.getErrorList();
  if(el.size > 0) {
if(analyzeErrors(el)) {
  // errors during logging configuration
  throw new IllegalStateException("Can't proceed withour logging");
}
  }
  boolean analyzeErrors(List el) {
// custom analysis of the errors go here
return true/false;
  }
It seems to me that log4j already fulfills Richard's requirements wrt
logging errors and logging configuration.
--
Ceki Gülcü
  The complete log4j manual: http://www.qos.ch/log4j/

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

Re: Distributions to include dependencies?

[Steven Caswell]

I'm +1 to Henri's idea for this reason:

When I'm using a package that requires other jars, I typically install the 
package on my development platform way ahead of the time when I'll be running 
maven. On some projects I never even run maven on the development box. Having 
the dependent jars as part of the distro is very convenient for setting up the 
development environment. I'd otherwise have to go manually find each one.

Steven Caswell
[EMAIL PROTECTED]


-- Original Message --
From: Phil Steitz <[EMAIL PROTECTED]>
Reply-To: "Jakarta Commons Developers List" 
Date:  Mon, 27 Dec 2004 16:09:01 -0500

>Henri Yandell wrote:
>> On Mon, 27 Dec 2004 15:14:36 -0500, Phil Steitz <[EMAIL PROTECTED]> wrote:
>> 
>>>Henri Yandell wrote:
>>>
Not a huge issue for things like Lang which have no dependencies, but
for other things like Digester I think it would be a lot better if the
binary tar.gz contained the jars it depends on?
>>>
>>>Just my HO, but to me that defeats the purpose of
>>>ibiblio/java-repository.  It also bloats distros and adds to the
>>>effective contract of the distro and responsibility of the RM needlessly
>>>(Would doing this effectively require us to store whatever jars were
>>>grabbed at release time in cvs/svn?)  
>> 
>> 
>> Nope. The jars come from the ibiblio/java-repo at dist-time.
>
>That's what I mean.  The release would depend on jars grabbed from 
>external sources at dist-time.  Some would argue that everything 
>necessary to generate the release distribution should be under revision 
>control, so the exact contents of the release could be reproduced (or 
>verified) at a later time by checking out the tagged sources and 
>rebuilding.
>> 
>> A maven user would still use it in the same way, but maven users do
>> not use the tar.gz distributions, they use the jars in the repos.
>> 
>> 
>>>I may be in the minority here, but I have never liked the "bundle all
>>>dependencies for convenience" approach -- either as a user or as a
>>>developer.  As a user, I am never sure exactly what I am getting "in the
>>>bundled version"  
>> 
>> 
>> dependencies/commons-logging-1.0.3.jar
>> dependencies/commons-beanutils-1.7.jar
>> 
>> 
>>> I understand that for complex products like
>>>  struts or tomcat, it may be impractical *not* to bundle dependencies;
>>>but I do not see it as necessary for commons components.
>> 
>> 
>> If I download the digester.tar.gz, I then need to download the
>> logging.tar.gz and the beanutils.tar.gz.
>
>Personally, I do not see this as a big deal.  Our mirrors are fast :-) 
>Maven handles it all seamlessly and for ant builds or web app 
>deployments, you generally want to place the jars manually anyway.
>
>Phil
>> 
>> Hen
>> 
>> -
>> 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: Distributions to include dependencies?

[David Graham]

It would certainly be helpful to our users to include the dependencies in
the distro.  Otherwise, it's like trying to drive a car without the
wheels.

David

--- Henri Yandell <[EMAIL PROTECTED]> wrote:

> Not a huge issue for things like Lang which have no dependencies, but
> for other things like Digester I think it would be a lot better if the
> binary tar.gz contained the jars it depends on?
> 
> So when I download digester-1.6, the tar.gz contains jars for
> logging-1.0.3 and beanutils-1.7. We're not forcing those versions on
> people, just providing them to save lots of searching around or
> waiting while iBiblio responds.
> 
> It seems pretty easy to do too from a maven.xml point of view:
> 
> 
> 
>   
>   
> 
> 
>   
> 
file="${maven.repo.local}/${dep.getGroupId()}/jars/${dep.getArtifact()}"/>
>   
> 
>   
> 
> 
> You'd just add:
> 
> 
>   true
> 
> 
> to a dependency.
> 
> Anyone interested?
> 
> Hen
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 


=
Get Firefox!
http://www.mozilla.org/firefox/

__
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: commons-logging auto-detection WAS: [logging] Enterprise Common Logging... dare we say 2.0?

[Ceki Gülcü]

Matt,
JCL exists mainly for the purpose of libraries wishing to *integrate*
with the logging API chosen by the user by deferring the selection of
the logging impl to runtime. The author of library "net.sf.morph"
probably does *not* wish to impose any logging related property on the
end-user. Consequently, it does not make sense to have package
specific properties at the JCL level. Would you agree?
At 08:26 PM 12/27/2004, Matt Sgarlata wrote:
Couldn't this be refined even further by incorporating a change to JCL I 
proposed earlier?  Here's a copy of my original post:

I have an idea... All logging implementations for Java configure logging 
by package, right?  What if we allow component developers to include their 
own commons-logging.properties that's not at the root of the source 
tree?  For example, if Morph suddenly decided it was very important to 
have certain messages logged, I just drop a commons-logging.properties in 
net.sf.morph that specifies the logging settings for net.sf.morph and all 
subpackages (e.g. which log factory to use, whether my messages *must* be 
heard, etc).  If JCL detects such a file it ensure the component that the 
logging it specifies is happening.  If an application developer, assembler 
or deployer decides later that Morph really isn't as important as I'd 
like, then they just delete the commons-logging.properties or put their 
own version in the WEB-INF/classes directory.  (Forgive me if this is a 
great show of my ignorance of classloading, but I think this is at least 
how things work for Tomcat).

Searching for a file like this on the classpath would certainly have 
performance implications.  However, search cost is incurred only on 
startup and there is precedent (see below), so it can't be too bad. It's 
certainly worth a try.

http://java.sun.com/j2se/1.4.2/docs/api/java/beans/PropertyEditorManager.html
--
Ceki Gülcü
  The complete log4j manual: http://www.qos.ch/log4j/

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

Re: Distributions to include dependencies?

[Phil Steitz]

Henri Yandell wrote:
On Mon, 27 Dec 2004 15:14:36 -0500, Phil Steitz <[EMAIL PROTECTED]> wrote:
Henri Yandell wrote:
Not a huge issue for things like Lang which have no dependencies, but
for other things like Digester I think it would be a lot better if the
binary tar.gz contained the jars it depends on?
Just my HO, but to me that defeats the purpose of
ibiblio/java-repository.  It also bloats distros and adds to the
effective contract of the distro and responsibility of the RM needlessly
(Would doing this effectively require us to store whatever jars were
grabbed at release time in cvs/svn?)  

Nope. The jars come from the ibiblio/java-repo at dist-time.
That's what I mean.  The release would depend on jars grabbed from 
external sources at dist-time.  Some would argue that everything 
necessary to generate the release distribution should be under revision 
control, so the exact contents of the release could be reproduced (or 
verified) at a later time by checking out the tagged sources and 
rebuilding.
A maven user would still use it in the same way, but maven users do
not use the tar.gz distributions, they use the jars in the repos.

I may be in the minority here, but I have never liked the "bundle all
dependencies for convenience" approach -- either as a user or as a
developer.  As a user, I am never sure exactly what I am getting "in the
bundled version"  

dependencies/commons-logging-1.0.3.jar
dependencies/commons-beanutils-1.7.jar

 I understand that for complex products like
 struts or tomcat, it may be impractical *not* to bundle dependencies;
but I do not see it as necessary for commons components.

If I download the digester.tar.gz, I then need to download the
logging.tar.gz and the beanutils.tar.gz.
Personally, I do not see this as a big deal.  Our mirrors are fast :-) 
Maven handles it all seamlessly and for ant builds or web app 
deployments, you generally want to place the jars manually anyway.

Phil
Hen
-
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: Distributions to include dependencies?

[Oliver Zeigermann]

I am with Henri here...

Oliver


On Mon, 27 Dec 2004 17:36:02 -0500, Henri Yandell <[EMAIL PROTECTED]> wrote:
> On Mon, 27 Dec 2004 15:14:36 -0500, Phil Steitz <[EMAIL PROTECTED]> wrote:
> > Henri Yandell wrote:
> > > Not a huge issue for things like Lang which have no dependencies, but
> > > for other things like Digester I think it would be a lot better if the
> > > binary tar.gz contained the jars it depends on?
> >
> > Just my HO, but to me that defeats the purpose of
> > ibiblio/java-repository.  It also bloats distros and adds to the
> > effective contract of the distro and responsibility of the RM needlessly
> > (Would doing this effectively require us to store whatever jars were
> > grabbed at release time in cvs/svn?)
> 
> Nope. The jars come from the ibiblio/java-repo at dist-time.
> 
> A maven user would still use it in the same way, but maven users do
> not use the tar.gz distributions, they use the jars in the repos.
> 
> > I may be in the minority here, but I have never liked the "bundle all
> > dependencies for convenience" approach -- either as a user or as a
> > developer.  As a user, I am never sure exactly what I am getting "in the
> > bundled version"  
> 
> dependencies/commons-logging-1.0.3.jar
> dependencies/commons-beanutils-1.7.jar
> 
> >  I understand that for complex products like
> >   struts or tomcat, it may be impractical *not* to bundle dependencies;
> > but I do not see it as necessary for commons components.
> 
> If I download the digester.tar.gz, I then need to download the
> logging.tar.gz and the beanutils.tar.gz.
> 
> Hen
> 
> -
> 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: Distributions to include dependencies?

[Henri Yandell]

On Mon, 27 Dec 2004 15:14:36 -0500, Phil Steitz <[EMAIL PROTECTED]> wrote:
> Henri Yandell wrote:
> > Not a huge issue for things like Lang which have no dependencies, but
> > for other things like Digester I think it would be a lot better if the
> > binary tar.gz contained the jars it depends on?
> 
> Just my HO, but to me that defeats the purpose of
> ibiblio/java-repository.  It also bloats distros and adds to the
> effective contract of the distro and responsibility of the RM needlessly
> (Would doing this effectively require us to store whatever jars were
> grabbed at release time in cvs/svn?)  

Nope. The jars come from the ibiblio/java-repo at dist-time.

A maven user would still use it in the same way, but maven users do
not use the tar.gz distributions, they use the jars in the repos.

> I may be in the minority here, but I have never liked the "bundle all
> dependencies for convenience" approach -- either as a user or as a
> developer.  As a user, I am never sure exactly what I am getting "in the
> bundled version"  

dependencies/commons-logging-1.0.3.jar
dependencies/commons-beanutils-1.7.jar

>  I understand that for complex products like
>   struts or tomcat, it may be impractical *not* to bundle dependencies;
> but I do not see it as necessary for commons components.

If I download the digester.tar.gz, I then need to download the
logging.tar.gz and the beanutils.tar.gz.

Hen

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

cvs commit: jakarta-commons/cli project.properties

[roxspring]

roxspring2004/12/27 14:22:02

  Modified:cli  project.properties
  Log:
  Force 1.3 compatibility even when compiling under 5.0
  
  Revision  ChangesPath
  1.12  +5 -0  jakarta-commons/cli/project.properties
  
  Index: project.properties
  ===
  RCS file: /home/cvs/jakarta-commons/cli/project.properties,v
  retrieving revision 1.11
  retrieving revision 1.12
  diff -u -r1.11 -r1.12
  --- project.properties2 Sep 2004 13:57:06 -   1.11
  +++ project.properties27 Dec 2004 22:22:02 -  1.12
  @@ -6,6 +6,9 @@
   compile.optimize = off
   compile.deprecation = off
   
  +maven.compile.source=1.3
  +maven.compile.target=1.3
  +
   maven.jarResources.basedir=${basedir}/src/java
   
   # Reset the checkstyle properties to use the default sun settings
  @@ -24,3 +27,5 @@
   maven.jar.manifest=${basedir}/src/conf/MANIFEST.MF
   
   maven.pdf.navigationFile=navigation-pdf.xml
  +
  +maven.svg.executeOnload=true
  
  
  

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

Re: Distributions to include dependencies?

[Phil Steitz]

Henri Yandell wrote:
Not a huge issue for things like Lang which have no dependencies, but
for other things like Digester I think it would be a lot better if the
binary tar.gz contained the jars it depends on?
Just my HO, but to me that defeats the purpose of 
ibiblio/java-repository.  It also bloats distros and adds to the 
effective contract of the distro and responsibility of the RM needlessly 
(Would doing this effectively require us to store whatever jars were 
grabbed at release time in cvs/svn?)  This is what maven or Ant get-deps 
tasks are supposed to do for us. Also, if maven (or Ant) users wanted to 
use the bundled jars, they would still have to kludge the local repo to 
place the jars if we bundled them. For maven users, at least, this would 
be more hassle than just letting maven grab the jars.

I may be in the minority here, but I have never liked the "bundle all 
dependencies for convenience" approach -- either as a user or as a 
developer.  As a user, I am never sure exactly what I am getting "in the 
bundled version" and as a developer, I want to limit dependencies to 
versioned release binaries available from definitive locations (now de 
facto ibiblio for many things -- we need to sort out how exactly apache 
jars are maintained there).  I understand that for complex products like 
 struts or tomcat, it may be impractical *not* to bundle dependencies; 
but I do not see it as necessary for commons components.

Phil

So when I download digester-1.6, the tar.gz contains jars for
logging-1.0.3 and beanutils-1.7. We're not forcing those versions on
people, just providing them to save lots of searching around or
waiting while iBiblio responds.
It seems pretty easy to do too from a maven.xml point of view:


  
  


  

  

  

You'd just add:

  true

to a dependency.
Anyone interested?
Hen
-
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]

Distributions to include dependencies?

[Henri Yandell]

Not a huge issue for things like Lang which have no dependencies, but
for other things like Digester I think it would be a lot better if the
binary tar.gz contained the jars it depends on?

So when I download digester-1.6, the tar.gz contains jars for
logging-1.0.3 and beanutils-1.7. We're not forcing those versions on
people, just providing them to save lots of searching around or
waiting while iBiblio responds.

It seems pretty easy to do too from a maven.xml point of view:



  
  


  

  

  


You'd just add:


  true


to a dependency.

Anyone interested?

Hen

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

Re: commons-logging auto-detection WAS: [logging] Enterprise Common Logging... dare we say 2.0?

[Richard Sitze]

Martin Cooper <[EMAIL PROTECTED]> wrote on 12/27/2004 01:07:28 PM:

> On Mon, 27 Dec 2004 12:41:56 -0600, Richard Sitze <[EMAIL PROTECTED]> 
wrote:
> > Ceki Gülcü <[EMAIL PROTECTED]> wrote on 12/27/2004 05:49:45 AM:
> > 
> > > At 03:05 AM 12/27/2004, Charles Daniels wrote:
> > >
> > > >If I understand the JCL discovery mechanism correctly, it actually
> > > >should work just fine in the scenario you describe above.  For it 
to
> > > >work, you would not set the org.apache.commons.logging.LogFactory
> > system
> > > >property, because, as you pointed out, system properties are 
JVM-wide.
> > > >Rather, for individual applications to use distinct underlying 
logging
> > > >implementations, you can simply place a commons-logging.properties 
file
> > > >in each application context (in WEB-INF/classes), setting the
> > > >org.apache.commons.logging.LogFactory property as appropriate in 
each
> > > >distinct commons-logging.properties file.  Since these properties 
files
> > > >will be loaded via distinct context class loaders, each application 
can
> > > >use distinct logging implementations.
> > >
> > > Good point. This will require some understanding by the user about 
the
> > > classloader delegation mechanism used by the app server, which 
varies
> > > from vendor to vendor or even from version to version of an app 
server
> > > by the same vendor.  Nevertheless, I stand corrected.
> > 
> > I wish :-(
> > 
> > In fact, this works ONLY if JCL is *not* available in a "common"
> > classloader higher up the hierarchy.  In that case, the config file
> > packaged in commons-logging.jar is found and used.
> > 
> > If JCL *is* packaged as a shared library in a parent classloader, then 
the
> > work around is typically a non-standard feature offered by some J2EE
> > hosts, for switching the search order within the classloader hierarchy
> > from parent first to parent last.  This allows the config file 
packaged
> > with the app to be located first.
> 
> I think you have this backwards. The standard J2EE class loader lookup
> order is local first and then parents (i.e. parent last), as opposed
> to the standard Java 2 order, which is the reverse. The non-standard
> feature provided by some containers is to use the Java 2 order instead
> of the J2EE order. See:
> 
> http://jakarta.apache.org/tomcat/tomcat-5.0-doc/class-loader-howto.html

Excellent point.  However, these are recommendations, not requirements. 
The problem, as described, is real enough.  Also, more importantly, I tend 
to use J2EE to demonstrate the issues surrounding more sophisticated 
ClassLoader hierarchies, but it should never be assumed that it is the 
only one.

We all agree that the problem is real enough in various environments.

> --
> Martin Cooper
> 
> 
> > Part of the proposal for "new discovery" is to circumvent the 
classloader
> > hierarchy [at a cost] and for picking up configs from the lowest point 
in
> > the hierarchy.
> > 
> > >
> > > --
> > > 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]
> > 
> >
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 

***
Richard A. Sitze
IBM WebSphere WebServices Development


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

Re: commons-logging auto-detection WAS: [logging] Enterprise Common Logging... dare we say 2.0?

[Matt Sgarlata]

Ceki Gülcü wrote:
At 03:05 AM 12/27/2004, Charles Daniels wrote:
If I understand the JCL discovery mechanism correctly, it actually
should work just fine in the scenario you describe above.  For it to
work, you would not set the org.apache.commons.logging.LogFactory system
property, because, as you pointed out, system properties are JVM-wide.
Rather, for individual applications to use distinct underlying logging
implementations, you can simply place a commons-logging.properties file
in each application context (in WEB-INF/classes), setting the
org.apache.commons.logging.LogFactory property as appropriate in each
distinct commons-logging.properties file.  Since these properties files
will be loaded via distinct context class loaders, each application can
use distinct logging implementations.

Good point. This will require some understanding by the user about the
classloader delegation mechanism used by the app server, which varies
from vendor to vendor or even from version to version of an app server
by the same vendor.  Nevertheless, I stand corrected.

Couldn't this be refined even further by incorporating a change to JCL I 
proposed earlier?  Here's a copy of my original post:

I have an idea... All logging implementations for Java configure logging 
by package, right?  What if we allow component developers to include 
their own commons-logging.properties that's not at the root of the 
source tree?  For example, if Morph suddenly decided it was very 
important to have certain messages logged, I just drop a 
commons-logging.properties in net.sf.morph that specifies the logging 
settings for net.sf.morph and all subpackages (e.g. which log factory to 
use, whether my messages *must* be heard, etc).  If JCL detects such a 
file it ensure the component that the logging it specifies is happening. 
 If an application developer, assembler or deployer decides later that 
Morph really isn't as important as I'd like, then they just delete the 
commons-logging.properties or put their own version in the 
WEB-INF/classes directory.  (Forgive me if this is a great show of my 
ignorance of classloading, but I think this is at least how things work 
for Tomcat).

Searching for a file like this on the classpath would certainly have 
performance implications.  However, search cost is incurred only on 
startup and there is precedent (see below), so it can't be too bad. It's 
certainly worth a try.

http://java.sun.com/j2se/1.4.2/docs/api/java/beans/PropertyEditorManager.html
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 32533] - [cli] CLI2 Group Parser skips arguments

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

   Target Milestone|--- |2.0 Final




-- 
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 31151] - [cli] Setting description of a Option

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||LATER




--- Additional Comments From [EMAIL PROTECTED]  2004-12-27 20:10 ---
Don't see an immediate need for this... will think more post 2.0

-- 
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: commons-logging auto-detection WAS: [logging] Enterprise Common Logging... dare we say 2.0?

[Martin Cooper]

On Mon, 27 Dec 2004 12:41:56 -0600, Richard Sitze <[EMAIL PROTECTED]> wrote:
> Ceki Gülcü <[EMAIL PROTECTED]> wrote on 12/27/2004 05:49:45 AM:
> 
> > At 03:05 AM 12/27/2004, Charles Daniels wrote:
> >
> > >If I understand the JCL discovery mechanism correctly, it actually
> > >should work just fine in the scenario you describe above.  For it to
> > >work, you would not set the org.apache.commons.logging.LogFactory
> system
> > >property, because, as you pointed out, system properties are JVM-wide.
> > >Rather, for individual applications to use distinct underlying logging
> > >implementations, you can simply place a commons-logging.properties file
> > >in each application context (in WEB-INF/classes), setting the
> > >org.apache.commons.logging.LogFactory property as appropriate in each
> > >distinct commons-logging.properties file.  Since these properties files
> > >will be loaded via distinct context class loaders, each application can
> > >use distinct logging implementations.
> >
> > Good point. This will require some understanding by the user about the
> > classloader delegation mechanism used by the app server, which varies
> > from vendor to vendor or even from version to version of an app server
> > by the same vendor.  Nevertheless, I stand corrected.
> 
> I wish :-(
> 
> In fact, this works ONLY if JCL is *not* available in a "common"
> classloader higher up the hierarchy.  In that case, the config file
> packaged in commons-logging.jar is found and used.
> 
> If JCL *is* packaged as a shared library in a parent classloader, then the
> work around is typically a non-standard feature offered by some J2EE
> hosts, for switching the search order within the classloader hierarchy
> from parent first to parent last.  This allows the config file packaged
> with the app to be located first.

I think you have this backwards. The standard J2EE class loader lookup
order is local first and then parents (i.e. parent last), as opposed
to the standard Java 2 order, which is the reverse. The non-standard
feature provided by some containers is to use the Java 2 order instead
of the J2EE order. See:

http://jakarta.apache.org/tomcat/tomcat-5.0-doc/class-loader-howto.html

--
Martin Cooper


> Part of the proposal for "new discovery" is to circumvent the classloader
> hierarchy [at a cost] and for picking up configs from the lowest point in
> the hierarchy.
> 
> >
> > --
> > 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]
> 
>

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

DO NOT REPLY [Bug 24045] - [cli] CommandLine state can be written to Properties

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||LATER




-- 
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 24040] - [cli] Per option Triggers

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||LATER




-- 
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 24039] - [cli] Factored out help for common groups

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||LATER




-- 
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: commons-logging auto-detection WAS: [logging] Enterprise Common Logging... dare we say 2.0?

[Richard Sitze]

"Henning P. Schmiedehausen" <[EMAIL PROTECTED]> wrote on 12/27/2004 
02:57:45 AM:

> "Charles Daniels" <[EMAIL PROTECTED]> writes:
> 
> >> -Original Message-
> >> From: Ceki Gülcü [mailto:[EMAIL PROTECTED] 
> >> Sent: Sunday, December 26, 2004 11:24 AM
> >> To: commons-dev@jakarta.apache.org
> >> Subject: commons-logging auto-detection WAS: [logging] 
> >> Enterprise Common Logging... dare we say 2.0?
> >> 
> >> 
> >> Simon et al.
> >> 
> >> Log4j is slowly migrating to a model where there will be only a 
single
> >> log4j.jar installed per Application Server. This single copy will be
> >> installed under the ./common/lib or ./lib/ directories. See 
> >> [1, 2, 3] for
> >> further details.
> >> 
> >> Consider the case of single log4j.jar placed in ./common/lib, and two
> >> web-applications called 'A' and 'B' both built on top of Struts. Also
> >> assume that user of 'A' wishes to use JDK logging (j.u.l) whereas the
> >> user of application 'B' wishes to use log4j. Since Struts uses JCL,
> >> there is no way for user of application 'A' to direct the logs
> >> generated by Struts to go to j.u.l and at the same time to have 
Struts
> >> in application 'B' direct its logging output to log4j. (Setting the
> >> org.apache.commons.logging.LogFactory system property will not help
> >> because system properties are shared by all applications.)
> >> 
> >> This simple example shows that the current JCL discovery mechanism
> >> will not always work as intended.
> 
> >If I understand the JCL discovery mechanism correctly, it actually
> >should work just fine in the scenario you describe above.  For it to

Not to mention within a J2EE environment, you can bind properties [such as 
org.apache.commons.logging.LogFactory] to the ClassLoader.  This has to be 
done by the J2EE application prior to any invocation of LogFactory, but 
it's do-able.

Hmm not so sure this works in JCL, but it does with JCDiscovery.

> Yep. Which once again shows, that using JCL in a component is a _good_
> thing, even though Ceki will never cease to argue against it. :-)

Humor aside, Ceki has taken a very reasonable view of JCL.  Please, let's 
not incite to humor-wars here.

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

***
Richard A. Sitze
IBM WebSphere WebServices Development


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

RE: commons-logging auto-detection WAS: [logging] Enterprise Common Logging... dare we say 2.0?

[Richard Sitze]

Ceki Gülcü <[EMAIL PROTECTED]> wrote on 12/27/2004 05:49:45 AM:

> At 03:05 AM 12/27/2004, Charles Daniels wrote:
> 
> >If I understand the JCL discovery mechanism correctly, it actually
> >should work just fine in the scenario you describe above.  For it to
> >work, you would not set the org.apache.commons.logging.LogFactory 
system
> >property, because, as you pointed out, system properties are JVM-wide.
> >Rather, for individual applications to use distinct underlying logging
> >implementations, you can simply place a commons-logging.properties file
> >in each application context (in WEB-INF/classes), setting the
> >org.apache.commons.logging.LogFactory property as appropriate in each
> >distinct commons-logging.properties file.  Since these properties files
> >will be loaded via distinct context class loaders, each application can
> >use distinct logging implementations.
> 
> Good point. This will require some understanding by the user about the
> classloader delegation mechanism used by the app server, which varies
> from vendor to vendor or even from version to version of an app server
> by the same vendor.  Nevertheless, I stand corrected.

I wish :-(

In fact, this works ONLY if JCL is *not* available in a "common" 
classloader higher up the hierarchy.  In that case, the config file 
packaged in commons-logging.jar is found and used.

If JCL *is* packaged as a shared library in a parent classloader, then the 
work around is typically a non-standard feature offered by some J2EE 
hosts, for switching the search order within the classloader hierarchy 
from parent first to parent last.  This allows the config file packaged 
with the app to be located first.

Part of the proposal for "new discovery" is to circumvent the classloader 
hierarchy [at a cost] and for picking up configs from the lowest point in 
the hierarchy.

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

DO NOT REPLY [Bug 32851] New: - copyProperties and null/empty values.

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

   Summary: copyProperties and null/empty values.
   Product: Commons
   Version: 1.6 Final
  Platform: PC
OS/Version: Windows 2000
Status: NEW
  Severity: normal
  Priority: P2
 Component: Bean Utilities
AssignedTo: commons-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


When BeanUtils.copyProperties copies a String property to a BigDecimal property
it throws ConversionException when the String property is null or "".
The opposite, when it copies a null BigDecimal property to a String property,
works fine, the String is set to null.

When BeanUtils.copyProperties copy a null or "" String property to a Integer
property, it sets the Integer to 0. The opposite, when I copy a null Integer
property to a String property it is set to null. Copying a null String to a null
Integer instead of 0 would be more consistent. (happens with other numeric
wrapper classes too).

These 2 issues are problematic when there are optional fields inside a Struts
ActionForm and the empty values are copied to a TO.

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

[roxspring]

roxspring2004/12/27 10:17:06

  Modified:cli/xdocs/examples index.xml
  Log:
  Added examples overview documentation
  
  Revision  ChangesPath
  1.2   +14 -1 jakarta-commons/cli/xdocs/examples/index.xml
  
  Index: index.xml
  ===
  RCS file: /home/cvs/jakarta-commons/cli/xdocs/examples/index.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- index.xml 2 Sep 2004 13:58:16 -   1.1
  +++ index.xml 27 Dec 2004 18:17:06 -  1.2
  @@ -23,7 +23,20 @@
   
 
   
  -  TODO quick overview to the examples
  +  
  +The examples section aims to show how a variety of applications and 
  +tools could be modelled using CLI2.  We make no claim that these 
tools 
  +use CLI2 in their implementation but simply use their interfaces to 
  +demonstrate commonly needed features.  Some examples will make 
  +simplifications to keep the documentation consise.
  +  
  +  
  +Many aspects of the API are touched upon but few are described in 
  +great detail.  If more information is required then the reader is 
  +encouraged to review the API documentation and look at the unit 
tests 
  +for inspiration.  Failing that, further advice and discussion can be 
  +found on the commons-user@jakarta.apache.org mailing 
list.
  +  
   
 
   
  
  
  

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

DO NOT REPLY [Bug 31284] - [cli] CLI does not support long parameter names on command-line.

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WORKSFORME




--- Additional Comments From [EMAIL PROTECTED]  2004-12-27 18:57 ---
The support for long option names in CLI1 is admittedly ropey but is there and
is much improved in CLI2.  I don't think the documentation claims that Ant uses
CLI, just that Ant's options could be modelled, its just an example.

XML based modelling has been suggested elsewhere and will probably be
implemented in 2.1, please come to commons-dev to discuss your thoughts and
requirements (prefix threads with [cli]).

Rob

-- 
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 31464] - [cli] CLI cant parse ANT option set as claimed in official usage guide

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|--- |2.0 Final




--- Additional Comments From [EMAIL PROTECTED]  2004-12-27 18:43 ---
I've updated the documentation to have an example of modelling ant using CLI2. 
The DocumentationTest has a replica of the example code to ensure that it still
compiles and works.

Marking as 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/cli/src/test/org/apache/commons/cli2 DocumentationTest.java

[roxspring]

roxspring2004/12/27 09:41:28

  Modified:cli/xdocs/examples ant.xml
   cli/src/test/org/apache/commons/cli2 DocumentationTest.java
  Log:
  Documented ant example
  
  Revision  ChangesPath
  1.2   +266 -1jakarta-commons/cli/xdocs/examples/ant.xml
  
  Index: ant.xml
  ===
  RCS file: /home/cvs/jakarta-commons/cli/xdocs/examples/ant.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- ant.xml   2 Sep 2004 13:58:16 -   1.1
  +++ ant.xml   27 Dec 2004 17:41:27 -  1.2
  @@ -23,12 +23,277 @@
   
 
   
  -  TODO what is ant
  +  
  +This example works through modelling Apache Ant using CLI2, the 
  +example is based on Apache Ant version 1.6.1 compiled on February 12 
  +2004.
  +  
  +  
  +"Apache Ant is a Java-based build tool. In theory, it is kind of 
like 
  +Make, but without Make's wrinkles." - For more information please 
  +visit http://ant.apache.org/";>http://ant.apache.org/
  +  
 
  +  
  +To model the ant options we first need to create some Builders so 
that 
  +each of the option instances can be created:
  +  
  +final DefaultOptionBuilder obuilder = new DefaultOptionBuilder();
  +final ArgumentBuilder abuilder = new ArgumentBuilder();
  +final GroupBuilder gbuilder = new GroupBuilder();
  +  
  + For each option we create an Option instance that will model 
it, built 
  + using the Builder instances above:
  +  
  +Option help =
  +obuilder
  +.withShortName("help")
  +.withShortName("h")
  +.withDescription("print this message")
  +.create();
  +Option projecthelp =
  +obuilder
  +.withShortName("projecthelp")
  +.withShortName("p")
  +.withDescription("print project help information")
  +.create();
  +Option version =
  +obuilder
  +.withShortName("version")
  +.withDescription("print the version information and exit")
  +.create();
  +Option diagnostics =
  +obuilder
  +.withShortName("diagnostics")
  +.withDescription("print information that might be helpful to 
diagnose or report problems.")
  +.create();
  +Option quiet =
  +obuilder
  +.withShortName("quiet")
  +.withShortName("q")
  +.withDescription("be extra quiet")
  +.create();
  +Option verbose =
  +obuilder
  +.withShortName("verbose")
  +.withShortName("v")
  +.withDescription("be extra verbose")
  +.create();
  +Option debug =
  +obuilder
  +.withShortName("debug")
  +.withShortName("d")
  +.withDescription("print debugging information")
  +.create();
  +Option emacs =
  +obuilder
  +.withShortName("emacs")
  +.withShortName("e")
  +.withDescription("produce logging information without adornments")
  +.create();
  +Option lib =
  +obuilder
  +.withShortName("lib")
  +.withDescription("specifies a path to search for jars and classes")
  +.withArgument(
  +abuilder
  +.withName("path")
  +.withMinimum(1)
  +.withMaximum(1)
  +.create())
  +.create();
  +Option logfile =
  +obuilder
  +.withShortName("logfile")
  +.withShortName("l")
  +.withDescription("use given file for log")
  +.withArgument(
  +abuilder
  +.withName("file")
  +.withMinimum(1)
  +.withMaximum(1)
  +.create())
  +.create();
  +Option logger =
  +obuilder
  +.withShortName("logger")
  +.withDescription("the class which is to perform logging")
  +.withArgument(
  +abuilder
  +.withName("classname")
  +.withMinimum(1)
  +.withMaximum(1)
  +.create())
  +.create();
  +Option listener =
  +obuilder
  +.withShortName("listener")
  +.withDescription("add an instance of class as a project listener")
  +.withArgument(
  +abuilder
  +.withName("classname")
  +.withMinimum(1)
  +.withMaximum(1)
  +.create())
  +.create();
  +Option noinput =
  +obuilder
  +.withShortName("noinput")
  +.withDescription("do not allow interactive input")
  +.create();
  +Option buildfile =
  +obuilder
  +.withShortName("buildfile")
  +.withShortName("file")
  +.withShortName("f")
  +.withDescription("use given buildfile")
  +.withArgument(
  +abuilder
  +.withName("file")
  +.withMin

Re: commons-logging auto-detection WAS: [logging] Enterprise Common Logging... dare we say 2.0?

[Martin Cooper]

On Mon, 27 Dec 2004 12:49:45 +0100, Ceki Gülcü <[EMAIL PROTECTED]> wrote:
> At 03:05 AM 12/27/2004, Charles Daniels wrote:
> 
> >If I understand the JCL discovery mechanism correctly, it actually
> >should work just fine in the scenario you describe above.  For it to
> >work, you would not set the org.apache.commons.logging.LogFactory system
> >property, because, as you pointed out, system properties are JVM-wide.
> >Rather, for individual applications to use distinct underlying logging
> >implementations, you can simply place a commons-logging.properties file
> >in each application context (in WEB-INF/classes), setting the
> >org.apache.commons.logging.LogFactory property as appropriate in each
> >distinct commons-logging.properties file.  Since these properties files
> >will be loaded via distinct context class loaders, each application can
> >use distinct logging implementations.
> 
> Good point. This will require some understanding by the user about the
> classloader delegation mechanism used by the app server, which varies
> from vendor to vendor or even from version to version of an app server
> by the same vendor.  Nevertheless, I stand corrected.

Given that making web applications self-contained, such that
everything required by the app is incorporated in the war file, is a
standard "best practice", I don't think there will be that much of a
need to educate people further with respect to class loader mechanisms
in order to understand how to use logging properly.

--
Martin Cooper


> 
> --
> Ceki Gülcü
> 
>   The complete log4j manual: http://qos.ch/log4j/
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

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

DO NOT REPLY [Bug 21304] - [cli] Broken link report (13 404s)

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

   Target Milestone|--- |2.0 Final




-- 
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 24039] - [cli] Factored out help for common groups

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

   Target Milestone|--- |2.1 Final




--- Additional Comments From [EMAIL PROTECTED]  2004-12-27 17:10 ---
Not needed before 2.0

-- 
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 24040] - [cli] Per option Triggers

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

   Target Milestone|--- |2.1 Final




--- Additional Comments From [EMAIL PROTECTED]  2004-12-27 17:09 ---
Not needed before 2.0

-- 
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 24045] - [cli] CommandLine state can be written to Properties

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

   Target Milestone|--- |2.1 Final




--- Additional Comments From [EMAIL PROTECTED]  2004-12-27 17:08 ---
Not needed for 2.0

-- 
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 25018] - [cli] CommandLine getArgList() serves no options but args, only

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE




--- Additional Comments From [EMAIL PROTECTED]  2004-12-27 17:05 ---
This appears to be a duplicate

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

-- 
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 17662] - [cli] Unknown options are ignored instead of throwing UnrecognizedOptionException

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]




--- Additional Comments From [EMAIL PROTECTED]  2004-12-27 17:06 ---
*** Bug 25018 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 19383] - [cli] Missing arguments in HelpFormatter.renderOptions(..)

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2004-12-27 16:26 ---
This no longer appears to be the case.

Added test to BugsTest (test19383).

Rob

-- 
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/cli/src/test/org/apache/commons/cli BugsTest.java

[roxspring]

roxspring2004/12/27 07:25:53

  Modified:cli/src/test/org/apache/commons/cli BugsTest.java
  Log:
  Added test to demonstrate fix of 19383
  
  BR: 19383
  
  Revision  ChangesPath
  1.23  +18 -0 
jakarta-commons/cli/src/test/org/apache/commons/cli/BugsTest.java
  
  Index: BugsTest.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/cli/src/test/org/apache/commons/cli/BugsTest.java,v
  retrieving revision 1.22
  retrieving revision 1.23
  diff -u -r1.22 -r1.23
  --- BugsTest.java 27 Dec 2004 14:51:37 -  1.22
  +++ BugsTest.java 27 Dec 2004 15:25:53 -  1.23
  @@ -514,5 +514,23 @@
   "Footer"+SEP
   ,out.toString());
   }
  +
  +public void test19383() {
  +Options options = new Options();
  +options.addOption(new Option("a","aaa",false,"aaa"));
  +options.addOption(new Option(null,"bbb",false,"bbb"));
  +options.addOption(new Option("c",null,false,"ccc"));
  +
  +HelpFormatter formatter = new HelpFormatter();
  +String SEP = System.getProperty("line.separator");
  +StringWriter out = new StringWriter();
  +formatter.printHelp(new PrintWriter(out),80, "foobar", "", options, 
2, 2, "", true);
  +assertEquals(
  +"usage: foobar [-a] [-c] [--bbb]"+SEP+
  +"  -a,--aaa  aaa"+SEP+
  +" --bbb  bbb"+SEP+
  +"  -cccc"+SEP
  +,out.toString());
  +}
   
   }
  
  
  

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

DO NOT REPLY [Bug 25044] - [cli] Error parsing option arguments

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]




--- Additional Comments From [EMAIL PROTECTED]  2004-12-27 15:56 ---
*** Bug 20214 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 21215] - [cli] Line separator as first char for helpformatter (footer) throws exception

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2004-12-27 15:53 ---
Added test to BugsTest and fixed in CVS
The bug also applied to the header text but would have affected other strings
starting with line separators,

Rob

-- 
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/cli/src/java/org/apache/commons/cli HelpFormatter.java

[roxspring]

roxspring2004/12/27 06:51:38

  Modified:cli/src/test/org/apache/commons/cli BugsTest.java
   cli/src/java/org/apache/commons/cli HelpFormatter.java
  Log:
  Line separator as first char for helpformatter footer and header no longer 
throws exception
  
  BR: 21215
  
  Revision  ChangesPath
  1.22  +17 -0 
jakarta-commons/cli/src/test/org/apache/commons/cli/BugsTest.java
  
  Index: BugsTest.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/cli/src/test/org/apache/commons/cli/BugsTest.java,v
  retrieving revision 1.21
  retrieving revision 1.22
  diff -u -r1.21 -r1.22
  --- BugsTest.java 27 Dec 2004 14:35:36 -  1.21
  +++ BugsTest.java 27 Dec 2004 14:51:37 -  1.22
  @@ -497,5 +497,22 @@
   assertTrue(cl.hasOption('o'));
   assertEquals("ovalue",cl.getOptionValue('o'));
   }
  +
  +public void test21215() {
  +Options options = new Options();
  +HelpFormatter formatter = new HelpFormatter();
  +String SEP = System.getProperty("line.separator");
  +String header = SEP+"Header";
  +String footer = "Footer";
  +StringWriter out = new StringWriter();
  +formatter.printHelp(new PrintWriter(out),80, "foobar", header, 
options, 2, 2, footer, true);
  +assertEquals(
  +"usage: foobar"+SEP+
  +""+SEP+
  +"Header"+SEP+
  +""+SEP+
  +"Footer"+SEP
  +,out.toString());
  +}
   
   }
  
  
  
  1.17  +2 -2  
jakarta-commons/cli/src/java/org/apache/commons/cli/HelpFormatter.java
  
  Index: HelpFormatter.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/cli/src/java/org/apache/commons/cli/HelpFormatter.java,v
  retrieving revision 1.16
  retrieving revision 1.17
  diff -u -r1.16 -r1.17
  --- HelpFormatter.java22 Apr 2004 23:00:09 -  1.16
  +++ HelpFormatter.java27 Dec 2004 14:51:38 -  1.17
  @@ -797,7 +797,7 @@
   if (((pos = text.indexOf('\n', startPos)) != -1 && pos <= width)
   || ((pos = text.indexOf('\t', startPos)) != -1 && pos <= width))
   {
  -return pos;
  +return pos+1;
   }
   else if ((startPos + width) >= text.length())
   {
  @@ -872,7 +872,7 @@
   
   int pos = s.length();
   
  -while ((pos >= 0) && Character.isWhitespace(s.charAt(pos - 1)))
  +while ((pos > 0) && Character.isWhitespace(s.charAt(pos - 1)))
   {
   --pos;
   }
  
  
  

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

DO NOT REPLY [Bug 31148] - [cli] Passing properties in Parser does not work for options with a single argument

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2004-12-27 15:36 ---
Added test to BugsTest and fixed in CVS

Thanks,

Rob

-- 
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/cli/src/java/org/apache/commons/cli Parser.java

[roxspring]

roxspring2004/12/27 06:35:36

  Modified:cli/src/test/org/apache/commons/cli BugsTest.java
   cli/src/java/org/apache/commons/cli Parser.java
  Log:
  When extracting option values from properties, options with a single argument 
can now be processed successfully.
  
  BR: 31148
  
  Revision  ChangesPath
  1.21  +18 -0 
jakarta-commons/cli/src/test/org/apache/commons/cli/BugsTest.java
  
  Index: BugsTest.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/cli/src/test/org/apache/commons/cli/BugsTest.java,v
  retrieving revision 1.20
  retrieving revision 1.21
  diff -u -r1.20 -r1.21
  --- BugsTest.java 27 Dec 2004 13:33:48 -  1.20
  +++ BugsTest.java 27 Dec 2004 14:35:36 -  1.21
  @@ -19,6 +19,7 @@
   import java.io.PrintStream;
   import java.io.PrintWriter;
   import java.io.StringWriter;
  +import java.util.Properties;
   
   import junit.framework.Test;
   import junit.framework.TestCase;
  @@ -478,6 +479,23 @@
   "  -v,--versionprint version information"+EOL+
   "footer"+EOL
   ,out.toString());
  +}
  +
  +public void test31148() throws ParseException {
  +Option multiArgOption = new Option("o","option with multiple args");
  +multiArgOption.setArgs(1);
  +
  +Options options = new Options();
  +options.addOption(multiArgOption);
  +
  +Parser parser = new PosixParser();
  +String[] args = new String[]{};
  +Properties props = new Properties();
  +props.setProperty("o","ovalue");
  +CommandLine cl = parser.parse(options,args,props);
  +
  +assertTrue(cl.hasOption('o'));
  +assertEquals("ovalue",cl.getOptionValue('o'));
   }
   
   }
  
  
  
  1.18  +2 -2  
jakarta-commons/cli/src/java/org/apache/commons/cli/Parser.java
  
  Index: Parser.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/cli/src/java/org/apache/commons/cli/Parser.java,v
  retrieving revision 1.17
  retrieving revision 1.18
  diff -u -r1.17 -r1.18
  --- Parser.java   27 Dec 2004 13:21:17 -  1.17
  +++ Parser.java   27 Dec 2004 14:35:36 -  1.18
  @@ -243,7 +243,7 @@
   // get the value from the properties instance
   String value = properties.getProperty(option);
   
  -if (opt.hasArgs())
  +if (opt.hasArg())
   {
   if ((opt.getValues() == null)
   || (opt.getValues().length == 0))
  
  
  

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

DO NOT REPLY [Bug 32533] - [cli] CLI2 Group Parser skips arguments

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |ASSIGNED




--- Additional Comments From [EMAIL PROTECTED]  2004-12-27 15:12 ---
I'm struggling to get my head around this problem properly.  I'd like to develop
a test case that can demonstrate the problems in action - both the scenario that
is fixed by the patch and the scenario that isn't.  If you could supply code to
create an option model and an argument array that exercises the bug then
hopefully I'll be able to understand the problem better.

Thanks,

Rob

-- 
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 23515] - [cli] Really strange parsing behaviour

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2004-12-27 14:39 ---
I'm pretty sure that this problem is not fixable within the 1.x line but is no
longer present in 2.x.

Marking as fixed and recommending the use of CLI2.

Rob


-- 
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 27635] - [cli] Only long options without short option seems to be noticed

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2004-12-27 14:35 ---
This appears to have been fixed, added a test to BugsTest to demonstrate.

Thanks,

Rob

-- 
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/cli/src/test/org/apache/commons/cli BugsTest.java

[roxspring]

roxspring2004/12/27 05:33:48

  Modified:cli/src/test/org/apache/commons/cli BugsTest.java
  Log:
  Added test to demonstrate the 27635 has been fixed
  
  PR: 27635
  
  Revision  ChangesPath
  1.20  +69 -0 
jakarta-commons/cli/src/test/org/apache/commons/cli/BugsTest.java
  
  Index: BugsTest.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/cli/src/test/org/apache/commons/cli/BugsTest.java,v
  retrieving revision 1.19
  retrieving revision 1.20
  diff -u -r1.19 -r1.20
  --- BugsTest.java 6 Sep 2004 22:51:45 -   1.19
  +++ BugsTest.java 27 Dec 2004 13:33:48 -  1.20
  @@ -17,6 +17,7 @@
   
   import java.io.ByteArrayOutputStream;
   import java.io.PrintStream;
  +import java.io.PrintWriter;
   import java.io.StringWriter;
   
   import junit.framework.Test;
  @@ -409,6 +410,74 @@
   options.addOption( m );
   CommandLine line = parser.parse( options, args );
   assertEquals( "Two Words", line.getOptionValue( "m" ) );
  +}
  +
  +public void test27635() {
  +Option help = new Option("h", "help", false, "print this message");
  +Option version = new Option("v", "version", false, "print version 
information");
  +Option newRun = new Option("n", "new", false, "Create NLT cache 
entries only for new items");
  +Option trackerRun = new Option("t", "tracker", false, "Create NLT 
cache entries only for tracker items");
  +
  +Option timeLimit = OptionBuilder.withLongOpt("limit")
  +.hasArg()
  +.withValueSeparator()
  +.withDescription("Set time limit for 
execution, in mintues")
  +.create("l");
  +
  +Option age = OptionBuilder.withLongOpt("age")
  +.hasArg()
  +.withValueSeparator()
  +.withDescription("Age (in days) of 
cache item before being recomputed")
  +.create("a");
  +
  +Option server = OptionBuilder.withLongOpt("server")
  +.hasArg()
  +.withValueSeparator()
  +.withDescription("The NLT server 
address")
  +.create("s");
  +
  +Option numResults = OptionBuilder.withLongOpt("results")
  +.hasArg()
  +.withValueSeparator()
  +.withDescription("Number of results 
per item")
  +.create("r");
  +
  +Option configFile = OptionBuilder.withLongOpt("config")
  +.hasArg()
  +.withValueSeparator()
  +.withDescription("Use the specified 
configuration file")
  +.create();
  +
  +Options mOptions = new Options();
  +mOptions.addOption(help);
  +mOptions.addOption(version);
  +mOptions.addOption(newRun);
  +mOptions.addOption(trackerRun);
  +mOptions.addOption(timeLimit);
  +mOptions.addOption(age);
  +mOptions.addOption(server);
  +mOptions.addOption(numResults);
  +mOptions.addOption(configFile);
  +
  +HelpFormatter formatter = new HelpFormatter();
  +final String EOL = System.getProperty("line.separator");
  +StringWriter out = new StringWriter();
  +formatter.printHelp(new 
PrintWriter(out),80,"commandline","header",mOptions,2,2,"footer",true);
  +assertEquals(
  +"usage: commandline [--config ] [-r ] [-a ] 
[-h] [-t] [-n] [-l"+EOL+
  +"   ] [-s ] [-v]"+EOL+
  +"header"+EOL+
  +"  -a,--age   Age (in days) of cache item before 
being recomputed"+EOL+
  +" --configUse the specified configuration 
file"+EOL+
  +"  -h,--help   print this message"+EOL+
  +"  -l,--limit Set time limit for execution, in 
mintues"+EOL+
  +"  -n,--newCreate NLT cache entries only for new 
items"+EOL+
  +"  -r,--results   Number of results per item"+EOL+
  +"  -s,--serverThe NLT server address"+EOL+
  +"  -t,--trackerCreate NLT cache entries only for 
tracker items"+EOL+
  +"  -v,--versionprint version information"+EOL+
  +"footer"+EOL
  +,out.toString());
   }
   
   }
  
  
  

---

cvs commit: jakarta-commons/cli/src/java/org/apache/commons/cli Parser.java

[roxspring]

roxspring2004/12/27 05:21:17

  Modified:cli/src/java/org/apache/commons/cli Parser.java
  Log:
  Recommitted with the fix applied not commented out (whoops)
  PR: 25044
  
  Revision  ChangesPath
  1.17  +2 -3  
jakarta-commons/cli/src/java/org/apache/commons/cli/Parser.java
  
  Index: Parser.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/cli/src/java/org/apache/commons/cli/Parser.java,v
  retrieving revision 1.16
  retrieving revision 1.17
  diff -u -r1.16 -r1.17
  --- Parser.java   27 Dec 2004 13:11:39 -  1.16
  +++ Parser.java   27 Dec 2004 13:21:17 -  1.17
  @@ -320,8 +320,7 @@
   String str = (String) iter.next();
   
   // found an Option, not an argument
  -//if (options.hasOption(str) && str.startsWith("-"))
  -if (options.hasOption(str))
  +if (options.hasOption(str) && str.startsWith("-"))
   {
   iter.previous();
   
  
  
  

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

DO NOT REPLY [Bug 25044] - [cli] Error parsing option arguments

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2004-12-27 14:12 ---
Applied.

Thanks!

Rob

-- 
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/cli/src/test/org/apache/commons/cli ArgumentIsOptionTest.java

[roxspring]

roxspring2004/12/27 05:11:39

  Modified:cli/src/test/org/apache/commons/cli2/jdepend
JDependTest.java
   cli/src/java/org/apache/commons/cli Parser.java
   cli/src/test/org/apache/commons/cli2
CommandLineTestCase.java
   cli/src/test/org/apache/commons/cli
ArgumentIsOptionTest.java
  Log:
  Parser now correctly allows option arguments to be the same as other options, 
less the initial '-'.  E.g. with options -a, the value 'a' is now allowed.
  Also corrected typo in test: testNoCyclesPresnet().
  
  PR: 25044
  Submitted by: David Morris
  
  Revision  ChangesPath
  1.3   +1 -1  
jakarta-commons/cli/src/test/org/apache/commons/cli2/jdepend/JDependTest.java
  
  Index: JDependTest.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/cli/src/test/org/apache/commons/cli2/jdepend/JDependTest.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- JDependTest.java  22 Apr 2004 23:00:16 -  1.2
  +++ JDependTest.java  27 Dec 2004 13:11:39 -  1.3
  @@ -71,7 +71,7 @@
   }
   }
   
  -public void testNoCyclesPresnet() {
  +public void testNoCyclesPresent() {
   assertEquals("Cycles exist", false, dependancies.containsCycles());
   }
   
  
  
  
  1.16  +3 -2  
jakarta-commons/cli/src/java/org/apache/commons/cli/Parser.java
  
  Index: Parser.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/cli/src/java/org/apache/commons/cli/Parser.java,v
  retrieving revision 1.15
  retrieving revision 1.16
  diff -u -r1.15 -r1.16
  --- Parser.java   22 Apr 2004 23:00:09 -  1.15
  +++ Parser.java   27 Dec 2004 13:11:39 -  1.16
  @@ -319,7 +319,8 @@
   {
   String str = (String) iter.next();
   
  -// found an Option
  +// found an Option, not an argument
  +//if (options.hasOption(str) && str.startsWith("-"))
   if (options.hasOption(str))
   {
   iter.previous();
  
  
  
  1.4   +27 -0 
jakarta-commons/cli/src/test/org/apache/commons/cli2/CommandLineTestCase.java
  
  Index: CommandLineTestCase.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/cli/src/test/org/apache/commons/cli2/CommandLineTestCase.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- CommandLineTestCase.java  2 Oct 2004 13:16:21 -   1.3
  +++ CommandLineTestCase.java  27 Dec 2004 13:11:39 -  1.4
  @@ -19,6 +19,7 @@
   import java.util.Iterator;
   import java.util.List;
   
  +import org.apache.commons.cli2.builder.ArgumentBuilder;
   import org.apache.commons.cli2.builder.DefaultOptionBuilder;
   import org.apache.commons.cli2.builder.GroupBuilder;
   import org.apache.commons.cli2.commandline.Parser;
  @@ -483,5 +484,31 @@
   assertEquals(1, cl.getOptionCount("login"));
   assertEquals(3, cl.getOptionCount("-?"));
   assertEquals(1, cl.getOptionCount("+display"));
  +}
  +
  +public final void testOptionAsArgument() throws OptionException {
  + final Option bool = new 
DefaultOptionBuilder().withShortName("p").create();
  + final Argument argument = new ArgumentBuilder().create();
  + final Option withArgument = new 
DefaultOptionBuilder().withShortName("attr").withArgument(argument).create();
  +
  + final Group group =
  +new GroupBuilder()
  +.withOption(bool)
  +.withOption(withArgument)
  +.create();
  +
  +final Parser parser = new Parser();
  +parser.setGroup(group);
  +final CommandLine cl =
  +parser.parse(
  +new String[] {
  +"-p",
  +"-attr",
  +"p" });
  +
  +assertEquals(1, cl.getOptionCount("-p"));
  +assertTrue(cl.hasOption("-p"));
  +assertTrue(cl.hasOption("-attr"));
  +assertTrue(cl.getValue("-attr").equals("p"));
   }
   }
  
  
  
  1.2   +4 -4  
jakarta-commons/cli/src/test/org/apache/commons/cli/ArgumentIsOptionTest.java
  
  Index: ArgumentIsOptionTest.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/cli/src/test/org/apache/commons/cli/ArgumentIsOptionTest.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- ArgumentIsOptionTest.java 27 Dec 2004 12:42:38 -  1.1
  +++ ArgumentIsOptionTest.java 27 Dec 2004 13:11:39 -  1.2
  @@ -46,7 +46,7 @@
   String[] args = new String[] {
   "-p",
   "-attr",
  -"value"
  +"p"
 

DO NOT REPLY [Bug 32525] - [cli] Parser breaks up command line parms into single characters

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2004-12-27 13:44 ---
Applied with minor alterations to avoid tickling #25044 who's patch hasn't been
reviewed yet.

Thanks,

Rob

-- 
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/cli/src/test/org/apache/commons/cli LongOptionWithShort.java ArgumentIsOptionTest.java

[roxspring]

roxspring2004/12/27 04:42:38

  Modified:cli/src/java/org/apache/commons/cli PosixParser.java
  Added:   cli/src/test/org/apache/commons/cli LongOptionWithShort.java
ArgumentIsOptionTest.java
  Log:
  Stops the PosixParser from bursting options unecessarily, i.e. if -file is an 
acceptible option then it won't be broken into -f -i -l -e.
  
  PR: 32525
  Submitted by: David Morris
  
  Revision  ChangesPath
  1.16  +4 -2  
jakarta-commons/cli/src/java/org/apache/commons/cli/PosixParser.java
  
  Index: PosixParser.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/cli/src/java/org/apache/commons/cli/PosixParser.java,v
  retrieving revision 1.15
  retrieving revision 1.16
  diff -u -r1.15 -r1.16
  --- PosixParser.java  22 Apr 2004 23:00:09 -  1.15
  +++ PosixParser.java  27 Dec 2004 12:42:38 -  1.16
  @@ -135,7 +135,9 @@
   {
   processOptionToken(token, stopAtNonOption);
   }
  -
  +else if (options.hasOption(token)) {
  + tokens.add(token);
  +}
   // requires bursting
   else
   {
  
  
  
  1.1  
jakarta-commons/cli/src/test/org/apache/commons/cli/LongOptionWithShort.java
  
  Index: LongOptionWithShort.java
  ===
  /**
   * Copyright 2001-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.cli;
  
  import junit.framework.Test;
  import junit.framework.TestCase;
  import junit.framework.TestSuite;
  
  
  /**
   * 
   * This is a collection of tests that test real world
   * applications command lines focusing on options with
   * long and short names.
   * 
   */
  public class LongOptionWithShort extends TestCase {
  public LongOptionWithShort(String name) {
  super(name);
  }
  
  public static Test suite() {
  return new TestSuite(LongOptionWithShort.class);
  }
  
  /**
   *
   */
  public void testLongOptionWithShort() {
  Option help = new Option("h", "help", false, "print this message");
  Option version = new Option("v", "version", false,
  "print version information");
  Option newRun = new Option("n", "new", false,
  "Create NLT cache entries only for new items");
  Option trackerRun = new Option("t", "tracker", false,
  "Create NLT cache entries only for tracker items");
  
  Option timeLimit = OptionBuilder.withLongOpt("limit").hasArg()
  .withValueSeparator()
  .withDescription("Set time limit for 
execution, in mintues")
  .create("l");
  
  Option age = OptionBuilder.withLongOpt("age").hasArg()
.withValueSeparator()
.withDescription("Age (in days) of cache 
item before being recomputed")
.create("a");
  
  Option server = OptionBuilder.withLongOpt("server").hasArg()
   .withValueSeparator()
   .withDescription("The NLT server 
address")
   .create("s");
  
  Option numResults = OptionBuilder.withLongOpt("results").hasArg()
   .withValueSeparator()
   .withDescription("Number of results 
per item")
   .create("r");
  
  Option configFile = OptionBuilder.withLongOpt("file").hasArg()
   .withValueSeparator()
   .withDescription("Use the specified 
configuration file")
   .create();
  
  Options options = new Options();
  options.addOption(help);
  options.addOption(version);
  options.addOption(newRun);
  options.addOption(trackerRun);
  options.addOption(timeLimit);
  options.addOption(age);
  options.addOption(server);
  options.addOption(numResu

cvs commit: jakarta-commons/cli/src/test/org/apache/commons/cli2 CLITestCase.java

[roxspring]

roxspring2004/12/27 03:55:12

  Modified:cli/src/test/org/apache/commons/cli2 CLITestCase.java
  Log:
  CLITestCase is now abstract to stop eclipse 3.1 complaining about it having 
no tests
  
  Revision  ChangesPath
  1.3   +1 -1  
jakarta-commons/cli/src/test/org/apache/commons/cli2/CLITestCase.java
  
  Index: CLITestCase.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/cli/src/test/org/apache/commons/cli2/CLITestCase.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- CLITestCase.java  22 Apr 2004 23:00:06 -  1.2
  +++ CLITestCase.java  27 Dec 2004 11:55:12 -  1.3
  @@ -24,7 +24,7 @@
   
   import junit.framework.TestCase;
   
  -public class CLITestCase extends TestCase {
  +public abstract class CLITestCase extends TestCase {
   
public static List list() {
return Collections.EMPTY_LIST;
  
  
  

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

RE: commons-logging auto-detection WAS: [logging] Enterprise Common Logging... dare we say 2.0?

[Ceki Gülcü]

At 03:05 AM 12/27/2004, Charles Daniels wrote:
If I understand the JCL discovery mechanism correctly, it actually
should work just fine in the scenario you describe above.  For it to
work, you would not set the org.apache.commons.logging.LogFactory system
property, because, as you pointed out, system properties are JVM-wide.
Rather, for individual applications to use distinct underlying logging
implementations, you can simply place a commons-logging.properties file
in each application context (in WEB-INF/classes), setting the
org.apache.commons.logging.LogFactory property as appropriate in each
distinct commons-logging.properties file.  Since these properties files
will be loaded via distinct context class loaders, each application can
use distinct logging implementations.
Good point. This will require some understanding by the user about the
classloader delegation mechanism used by the app server, which varies
from vendor to vendor or even from version to version of an app server
by the same vendor.  Nevertheless, I stand corrected.
--
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: commons-logging auto-detection WAS: [logging] Enterprise

[Ceki Gülcü]

At 09:55 AM 12/27/2004, Henning P. Schmiedehausen wrote:
Ceki =?iso-8859-1?Q?G=FClc=FC?= <[EMAIL PROTECTED]> writes:
>Log4j is slowly migrating to a model where there will be only a single
>log4j.jar installed per Application Server. This single copy will be
>installed under the ./common/lib or ./lib/ directories. See [1, 2, 3] for
>further details.
This approach is doomed to fail. This is the approach that was first
tried with JCL and strongly argued against by some log4j people.  See
http://www.qos.ch/logging/thinkAgain.jsp for details.
In a nutshell, [1] says:
1) automated classloader-based discovery mechanisms cause a lot of
headaches and can be health hazard
2) don't assume diverging APIs can be abstracted away.
So in what way [1] is in contradiction with [2, 3, 4]?
[1] http://www.qos.ch/logging/thinkAgain.jsp
[2] http://wiki.custine.com/display/ENV/Log4j+1.3+and+Tomcat5
[3] http://cvs.apache.org/viewcvs.cgi/logging-log4j/examples/tiny-webapp/
[4] http://www.qos.ch/logging/sc.jsp
I am extremely curious to know in what way two documents written by
me, around the same time, contradict each other.

In a nutshell: My webapp _requires_ log4j-a.b.c.jar and your container
provides log4j-x.y.z.jar in common/lib. E.g. I _require_
org.apache.log4j.RollingFileAppender from log4j-1.2.8.jar [1]
Well, log4j 1.3 is still in alpha. We still have time to address the
o.a.l.RollingFileAppender compatibility problem before 1.3 goes RC.
IMHO you shouldn't argue on both sides of the fence.
In what way was I arguing on both sides of the fence?
Personally, I prefer to let every application bring its own jars and
be able to completely isolate the jars used by the container from the
jars used by the application. Which is possible with Tomcat and
renders your "model" useless.
The model suggested in [2] allows for greater control over the logging
environment. It was developed in response to demand from the
developers of various Application Servers, in particular Tomcat. You
are of course free to characterize it as "useless".
At some point, you want to understand, that logging, like
configuration or a web framework is a minor part of a larger app and
that it has to subordinate to its requirements. Logging cannot dictate
the way that an application is written. If it tries to, developers
will use another library.
Agreed. Another point to keep in mind is that logging should help
solve problems and not be the source of bugs obfuscating problem
diagnosis.
Regards
Henning
[1] If you think, this is a constructed example, you might want to
read velocity-dev.
...and what was their conclusion?

--
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: commons-logging auto-detection WAS: [logging] Enterprise Common Logging... dare we say 2.0?

[Henning P. Schmiedehausen]

"Charles Daniels" <[EMAIL PROTECTED]> writes:

>> -Original Message-
>> From: Ceki Gülcü [mailto:[EMAIL PROTECTED] 
>> Sent: Sunday, December 26, 2004 11:24 AM
>> To: commons-dev@jakarta.apache.org
>> Subject: commons-logging auto-detection WAS: [logging] 
>> Enterprise Common Logging... dare we say 2.0?
>> 
>> 
>> Simon et al.
>> 
>> Log4j is slowly migrating to a model where there will be only a single
>> log4j.jar installed per Application Server. This single copy will be
>> installed under the ./common/lib or ./lib/ directories. See 
>> [1, 2, 3] for
>> further details.
>> 
>> Consider the case of single log4j.jar placed in ./common/lib, and two
>> web-applications called 'A' and 'B' both built on top of Struts. Also
>> assume that user of 'A' wishes to use JDK logging (j.u.l) whereas the
>> user of application 'B' wishes to use log4j. Since Struts uses JCL,
>> there is no way for user of application 'A' to direct the logs
>> generated by Struts to go to j.u.l and at the same time to have Struts
>> in application 'B' direct its logging output to log4j. (Setting the
>> org.apache.commons.logging.LogFactory system property will not help
>> because system properties are shared by all applications.)
>> 
>> This simple example shows that the current JCL discovery mechanism
>> will not always work as intended.

>If I understand the JCL discovery mechanism correctly, it actually
>should work just fine in the scenario you describe above.  For it to

Yep. Which once again shows, that using JCL in a component is a _good_
thing, even though Ceki will never cease to argue against it. :-)

Regards
Henning


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

Re: commons-logging auto-detection WAS: [logging] Enterprise

[Henning P. Schmiedehausen]

Ceki =?iso-8859-1?Q?G=FClc=FC?= <[EMAIL PROTECTED]> writes:

>Log4j is slowly migrating to a model where there will be only a single
>log4j.jar installed per Application Server. This single copy will be
>installed under the ./common/lib or ./lib/ directories. See [1, 2, 3] for
>further details.

This approach is doomed to fail. This is the approach that was first
tried with JCL and strongly argued against by some log4j people.  See
http://www.qos.ch/logging/thinkAgain.jsp for details.

In a nutshell: My webapp _requires_ log4j-a.b.c.jar and your container
provides log4j-x.y.z.jar in common/lib. E.g. I _require_
org.apache.log4j.RollingFileAppender from log4j-1.2.8.jar [1]

Either I can do some class loader magic, that I get that right or my
app fails. Which is then your fault. :-)

IMHO you shouldn't argue on both sides of the fence. 

Personally, I prefer to let every application bring its own jars and
be able to completely isolate the jars used by the container from the
jars used by the application. Which is possible with Tomcat and
renders your "model" useless.

At some point, you want to understand, that logging, like
configuration or a web framework is a minor part of a larger app and
that it has to subordinate to its requirements. Logging cannot dictate
the way that an application is written. If it tries to, developers
will use another library.

Regards
Henning

[1] If you think, this is a constructed example, you might want to
read velocity-dev.


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

[IO] [PROPOSAL] reader writer

[Nishant Kumar]

Hi,
I have a small proposal.

Usage scenario is as follows.

One generates a char array of data using some process and then
immediately this is consumed by another process.

There are two ways of doing the same now.
1. Use a CharArrayWriter to accumulate the data generated in the first
step. convert it to char[] and then consume the char[] in the next step.
2. Use piped reader writer pair.

In both these methods data is written twice. firstly into the
intermediate buffer then onto an array that the second step will
consume.

I have written a class on lines of the piped reader and writer. In this
class there is no intermediate buffer. writer writes the data directly
into the char array passed by the reader in the read method.

Kindly have a look at the class ReaderWriter and ReaderWriterTest (which
gives a usage sample).

Also one more small proposal.
Why don't you have a CharArrayWriter class on the same lines of
ByteArrayOutputStream?

thanks,
nishant
package com.nk.io;

import java.io.IOException;
import java.io.Reader;
import java.io.Writer;

/**
 * This class enables a reader to read a content written by a writter
 * in a much easier manner than using Piped Writer and Piped Reader.
 * This is more efficient than the other as the amount of data copy
 * is halved as there is no intermediate buffer. The data passed by
 * the writer is written directly into the buffer passed by the
 * reader methods.
 * To use this class just instantiate this class, get the reader and
 * writer in two threads and starts reading from and writing to them
 * respectively. When finished close the writer and then close the
 * reader when it returns -1. Skipping and marking is not supported
 * in reader.
 * Writer must be closed to complete the reading process. Writing to
 * a writer when the reader has been closed will throw an IOException.
 * 
 * Passing a larger buffer into the read method will reduce context
 * switch between the reader and the writer threads.
 * 
 * @author Nishant Kumar
 */
public final class ReaderWriter
{
	private final PrivateReader reader = new PrivateReader();
	private final PrivateWriter writer = new PrivateWriter();

	private final Object mutex = new Object();

	private boolean writerClosed = false;
	private boolean readerClosed = false;

	public ReaderWriter()
	{
	}

	/**
	 * Returns the reader.
	 * @return the reader
	 */
	public Reader getReader()
	{
		return reader;
	}

	/**
	 * Returns the writer.
	 * @return the writer.
	 */
	public Writer getWriter()
	{
		return writer;
	}

	private final class PrivateReader extends Reader
	{
		private char[] readerBuffer;
		private int readerOffset;
		private int readerLength = 0;

		public void close()
		{
			synchronized (mutex)
			{
readerClosed = true;
mutex.notify();
			}
		}

		public int read(final char[] readerBuffer, final int offset, final int length)
		{
			if ((offset < 0) || (offset > readerBuffer.length) || (length < 0) ||
			((offset + length) > readerBuffer.length) || ((offset + length) < 0))
			{
throw new IndexOutOfBoundsException();
			}
			else if (length == 0)
			{
return 0;
			}
			synchronized (mutex)
			{
if (writerClosed)
{
	return -1;
}
this.readerBuffer = readerBuffer;
this.readerOffset = offset;
this.readerLength = length;
mutex.notify();
while (this.readerLength > 0 && !writerClosed)
{
	try
	{
		mutex.wait();
	}
	catch (InterruptedException e)
	{
		throw new RuntimeException(e);
	}
}
			}
			return this.readerOffset - offset;
		}

		public long skip(final long n)
		{
			return 0;
		}

		public void write(final char[] writerBuffer, int offset, int length) throws IOException
		{
			synchronized (mutex)
			{
while (length > 0)
{
	while (this.readerLength == 0 && !readerClosed)
	{
		try
		{
			mutex.wait();
		}
		catch (InterruptedException e)
		{
			throw new RuntimeException(e);
		}
	}
	if (readerClosed)
	{
		throw new IOException("Reader has been closed");
	}
	final int lengthToWrite = Math.min(length, this.readerLength);
	System.arraycopy(writerBuffer, offset, this.readerBuffer, this.readerOffset, lengthToWrite);
	offset += lengthToWrite;
	length -= lengthToWrite;
	this.readerOffset += lengthToWrite;
	this.readerLength -= lengthToWrite;
	if (this.readerLength == 0)
	{
		mutex.notify();
	}
}
			}
		}
	}

	private final class PrivateWriter extends Writer
	{
		public void close()
		{
			synchronized (mutex)
			{
writerClosed = true;
mutex.notify();
			}
		}

		public void flush()
		{
			//no-op
		}

		public void write(final char writerBuffer[], final int offset, final int length) throws IOException
		{
			if ((offset < 0) || (offset > writerBuffer.length) || (length < 0) ||
			((offset + length) > writerBuffer.length) || ((offset + length) < 0))
			{
throw new IndexOutOfBoundsException();
			}