svn commit: r164949 - /jakarta/commons/sandbox/vfs/trunk/src/java/org/apache/commons/vfs/impl/providers.xml

[imario]

Author: imario
Date: Tue Apr 26 22:38:45 2005
New Revision: 164949

URL: http://svn.apache.org/viewcvs?rev=164949&view=rev
Log:
Corrected class-name for ftpFileProvider

Modified:

jakarta/commons/sandbox/vfs/trunk/src/java/org/apache/commons/vfs/impl/providers.xml

Modified: 
jakarta/commons/sandbox/vfs/trunk/src/java/org/apache/commons/vfs/impl/providers.xml
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/vfs/trunk/src/java/org/apache/commons/vfs/impl/providers.xml?rev=164949&r1=164948&r2=164949&view=diff
==
--- 
jakarta/commons/sandbox/vfs/trunk/src/java/org/apache/commons/vfs/impl/providers.xml
 (original)
+++ 
jakarta/commons/sandbox/vfs/trunk/src/java/org/apache/commons/vfs/impl/providers.xml
 Tue Apr 26 22:38:45 2005
@@ -28,7 +28,7 @@
 
 
 
-
+
 
 
 



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

svn commit: r164926 - /jakarta/commons/proper/codec/trunk/project.xml

[brett]

Author: brett
Date: Tue Apr 26 17:30:00 2005
New Revision: 164926

URL: http://svn.apache.org/viewcvs?rev=164926&view=rev
Log:
correct invalid project.xml file

Modified:
jakarta/commons/proper/codec/trunk/project.xml

Modified: jakarta/commons/proper/codec/trunk/project.xml
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/codec/trunk/project.xml?rev=164926&r1=164925&r2=164926&view=diff
==
--- jakarta/commons/proper/codec/trunk/project.xml (original)
+++ jakarta/commons/proper/codec/trunk/project.xml Tue Apr 26 17:30:00 2005
@@ -138,20 +138,24 @@
 
 Christopher O'Brien
 [EMAIL PROTECTED]
-hex, md5, architecture
+
+hex
+md5
+architecture
+
 
 
 Martin Redington
-representing xml-rpc
+representing xml-rpc
 
 
 Jeffery Dever
-representing http-client
+representing http-client
 
 
 Steve Zimmermann
 [EMAIL PROTECTED]
-documentation
+documentation
 
 
 Benjamin Walstrum
@@ -160,22 +164,22 @@
 
 Oleg Kalnichevski
 [EMAIL PROTECTED]
-representing http-client
+representing http-client
 
 
 Dave Dribin
 [EMAIL PROTECTED]
-digest util
+digest util
 
 
 Alex Karasulu
 aok123 at bellsouth.net
-Submitted Binary class and test
+Submitted Binary class and test
 
 
 Matthew Inger
 mattinger at yahoo.com
-Submitted DIFFERENCE algorithm for Soundex and 
RefinedSoundex
+Submitted DIFFERENCE algorithm for Soundex and 
RefinedSoundex
 
 
 



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

svn commit: r164897 - /jakarta/commons/proper/betwixt/trunk/xdocs/tasks.xml

[rdonkin]

Author: rdonkin
Date: Tue Apr 26 14:56:22 2005
New Revision: 164897

URL: http://svn.apache.org/viewcvs?rev=164897&view=rev
Log:
Updated task document

Modified:
jakarta/commons/proper/betwixt/trunk/xdocs/tasks.xml

Modified: jakarta/commons/proper/betwixt/trunk/xdocs/tasks.xml
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/betwixt/trunk/xdocs/tasks.xml?rev=164897&r1=164896&r2=164897&view=diff
==
--- jakarta/commons/proper/betwixt/trunk/xdocs/tasks.xml (original)
+++ jakarta/commons/proper/betwixt/trunk/xdocs/tasks.xml Tue Apr 26 14:56:22 
2005
@@ -190,6 +190,8 @@
 
 
 
+Fixed bug in nested element diagnosing empty elements.
+
 Added support for polymorphic mappings. 
 This allows the type of a property to be guessed at bind time
 (rather than at compile time).



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

svn commit: r164896 - in /jakarta/commons/proper/betwixt/trunk/src: java/org/apache/commons/betwixt/io/ test/org/apache/commons/betwixt/ test/org/apache/commons/betwixt/io/

[rdonkin]

Author: rdonkin
Date: Tue Apr 26 14:48:43 2005
New Revision: 164896

URL: http://svn.apache.org/viewcvs?rev=164896&view=rev
Log:
Fixed nested empty element bug.

Added:

jakarta/commons/proper/betwixt/trunk/src/java/org/apache/commons/betwixt/io/TestIgnoreEmptyElements.java

jakarta/commons/proper/betwixt/trunk/src/test/org/apache/commons/betwixt/io/SidekickBean.java

jakarta/commons/proper/betwixt/trunk/src/test/org/apache/commons/betwixt/io/SuperheroBean.java
Modified:

jakarta/commons/proper/betwixt/trunk/src/java/org/apache/commons/betwixt/io/AbstractBeanWriter.java

jakarta/commons/proper/betwixt/trunk/src/test/org/apache/commons/betwixt/TestBeanWriter.java

Modified: 
jakarta/commons/proper/betwixt/trunk/src/java/org/apache/commons/betwixt/io/AbstractBeanWriter.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/betwixt/trunk/src/java/org/apache/commons/betwixt/io/AbstractBeanWriter.java?rev=164896&r1=164895&r2=164896&view=diff
==
--- 
jakarta/commons/proper/betwixt/trunk/src/java/org/apache/commons/betwixt/io/AbstractBeanWriter.java
 (original)
+++ 
jakarta/commons/proper/betwixt/trunk/src/java/org/apache/commons/betwixt/io/AbstractBeanWriter.java
 Tue Apr 26 14:48:43 2005
@@ -270,22 +270,34 @@
 }
 
 // introspect to obtain bean info
-XMLBeanInfo beanInfo = null;
-Class introspectedBindType = parentDescriptor.getSingularPropertyType();
-if ( introspectedBindType == null ) {
-introspectedBindType = parentDescriptor.getPropertyType();
-}
-if ( parentDescriptor.isUseBindTimeTypeForMapping() || 
introspectedBindType == null ) {
-beanInfo = introspector.introspect( bean );
-} else {
-beanInfo = introspector.introspect( introspectedBindType );
-}
+XMLBeanInfo beanInfo = findXMLBeanInfo(bean, parentDescriptor);
 writeBean(namespaceUri, localName, qualifiedName, bean, context, beanInfo);
 
 log.trace( "Finished writing bean graph." );
 }
 
 /**
+ * Finds the appropriate bean info for the given (hollow) element.
+ * @param bean
+ * @param parentDescriptor ElementDescriptor, not null
+ * @return XMLBeanInfo, not null
+ * @throws IntrospectionException
+ */
+private XMLBeanInfo findXMLBeanInfo(Object bean, ElementDescriptor 
parentDescriptor) throws IntrospectionException {
+XMLBeanInfo beanInfo = null;
+Class introspectedBindType = 
parentDescriptor.getSingularPropertyType();
+if ( introspectedBindType == null ) {
+introspectedBindType = parentDescriptor.getPropertyType();
+}
+if ( parentDescriptor.isUseBindTimeTypeForMapping() || 
introspectedBindType == null ) {
+beanInfo = introspector.introspect( bean );
+} else {
+beanInfo = introspector.introspect( introspectedBindType );
+}
+return beanInfo;
+}
+
+/**
  * Writes the given bean to the current stream 
  * using the given mapping.
  *
@@ -1035,8 +1047,9 @@
  * @param descriptor the ElementDescriptor to evaluate
  * @param context the Context against which the element will 
be evaluated
  * @return true if this element should be written out
+ * @throws IntrospectionException
  */
-private boolean ignoreElement( ElementDescriptor descriptor, Context 
context ) {
+private boolean ignoreElement( ElementDescriptor descriptor, Context 
context ) throws IntrospectionException {
 if ( ! getWriteEmptyElements() ) {
 return isEmptyElement( descriptor, context );
 }
@@ -1050,16 +1063,19 @@
  * and no body text.
  * For example,  is an empty element but
  *  is not.
- *
+ * 
  * @param descriptor the ElementDescriptor to evaluate
  * @param context the Context against which the element will 
be evaluated
  * @return true if this element is empty on evaluation
+ * @throws IntrospectionException
  */
-private boolean isEmptyElement( ElementDescriptor descriptor, Context 
context ) {
+private boolean isEmptyElement( ElementDescriptor descriptor, Context 
context ) throws IntrospectionException {
+//TODO: this design isn't too good
+// to would be much better to render just once 
 if ( log.isTraceEnabled() ) {
 log.trace( "Is " + descriptor + " empty?" );
 }
-
+
 // an element which has attributes is not empty
 if ( descriptor.hasAttributes() ) {
 log.trace( "Element has attributes." );
@@ -1090,6 +1106,23 @@
 if ( ! isEmptyElement( descriptor.getElementDescriptors()[i], 
context ) ) {
 log.trace( "Element has child which isn't empty." );
 return false;
+}
+}
+}
+
+if ( descriptor.isHollow() )
+

RE: [lang] (RE)VOTE 2.1 Release

[Gary Gregory]

If the changes below are committed, we'll need an RC4... sorry for the
extra work Steven, by now you must have it turn-key ;-)

Gary

-Original Message-
From: Michael Heuer [mailto:[EMAIL PROTECTED] On Behalf Of
Michael Heuer
Sent: Tuesday, April 26, 2005 9:22 AM
To: Jakarta Commons Developers List; Steven Caswell
Subject: Re: [lang] (RE)VOTE 2.1 Release


A few minor nits with the web site:

Links before commas and periods have an extra space, e.g. lang status
document . and Maven , JDiff , PMD , FindBugs on index.html.  I had
thought that this issue was resolved in an upgrade to maven and/or the
maven xdoc plugin?

Update tasks.html, user guide has been written.  (it is quite nice, by
the
way)

Give userguide.html a header similar to that of developerguide.html.

userguide.html abbout --> about

userguide.html use CharSetUtils.delete("testtest", "tr")
instead of 'CharSetUtils.delete("testtest", "tr")' ?  What about the
other
methods used in the text, should they be put in  tags as well?

developerguide.html nessesary --> necessary

A non-binding +1 from me.

   michael


On Tue, 26 Apr 2005, Steven Caswell wrote:

> Release candidate 3 (and hopefully final :) is in
> http://www.apache.org/~stevencaswell/commons-lang-2.1/
>
> The only changes between RC2 and RC3 are documentation clean-up
(thanks to
> Gary for finding some inconsistencies). It would be good if someone
could
> check the compatibility of the distribution with JDK 1.2.
>
> I know Stephen asked for a clirr, and I haven't had time to work on
that,
> but I should be able to get it by tomorrow evening (ET).
>
> Not sure if another vote is necessary since I don't recall any -1s,
but I'll
> go ahead and propose it and see what shakes out:
>
> [ ] +1
> [ ] -1
>
> --
> Steven Caswell
> [EMAIL PROTECTED]
>
> Take back the web - http://www.mozilla.org
>


-
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] possible errors in child first cases

[robert burrell donkin]

On Mon, 2005-04-25 at 23:01 -0700, Brian Stansberry wrote:
> Sorry to waste your time; false alarm. The child-first
> cases are fine.  Somehow my commons-logging.jar had
> everything but the kitchen sink in it, including the
> demonstration code. 
> 
> Good news is with that problem fixed and a refactored
> LogFactoryImpl, JCL worked as expected in all cases.

great :)

- robert


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

Re: [logging] LogFactoryImpl weaknesses [WAS Re: [logging] issues highlighted by analysis]

[robert burrell donkin]

On Mon, 2005-04-25 at 23:22 -0700, Brian Stansberry wrote:
> --- robert burrell donkin
> <[EMAIL PROTECTED]> wrote:
> 
  
> > once you're happy to left other people take a look
> > at your code, add it
> > to a bug report. 
> 
> I'll try to do that tomorrow or at most Wed.  I won't
> be shy about posting early and having people find a
> few warts; I figure letting more eyes look at the
> subtleties is more important.

+1

we'll need to go through the code in detail. 

my tentative plan is to create a branch (lovely, easy, cheap SVN
branches :) and patch in your code pretty quickly and then everyone can
spend time analysing it. opinions?

- robert


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

Re: [logging] issues highlighted by analysis

[robert burrell donkin]

On Mon, 2005-04-25 at 13:53 -0700, Brian Stansberry wrote:
> --- robert burrell donkin
> <[EMAIL PROTECTED]> wrote:
> 
> > On Sun, 2005-04-24 at 16:43 -0700, Brian Stansberry
> > wrote:
> > > --- robert burrell donkin
> > > <[EMAIL PROTECTED]> wrote:
> > 
> > 
> > 
> > > > i'm wondering whether to commit them onto a
> > branch
> > > > so that everyone can
> > > > take a look, check their accuracy and take a
> > look at
> > > > fixes. opinions?
> > > 
> > > Please forgive if this is a stupid question, but
> > why
> > > on a branch?
> > 
> > to prevent a gump storm :)
> > 
> > gump builds from TRUNK. committing unit tests that
> > failure onto TRUNK
> > means that gump will fail to build JCL. last time
> > that happened, there
> > were literally hundreds of dependent products that
> > could not be built.
> > each failed project means an email every day until
> > it's fixed. thus, a
> > gump storm. 
> > 
> 
> Wow.  That's a shame.  I'd think not being able to add
> unit tests that fail to the main line would tend to
> lead to a lot fewer unit tests.

of course, they can be committed so long as they aren't run as part of
the main test target. unit tests that are intended to fail would require
some documentation and seems a bit strange for TRUNK.

given the general interest, i'll probably tidy up the test i have and
commit them into TRUNK (for now) but i won't call the target from the
main test target.

> BTW, a couple weeks back I added a unit test patch to
> the JBoss Memory Leak bug.  The added test will fail,
> so the patch shouldn't be committed to trunk. (Thus
> confirming my point above).

part of the required habit for a committer is to get in the right
habits. once the work's finished and ready for committing, always
update, build the distribution and run the standard unit tests. never
commit a patch with broken unit tests.

i'm coming round to simon's idea that an additional directory (a peer to
TRUNK and BRANCHES) may be the best solution. we could add memory issues
analysis next to the discovery stuff. 

- robert


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

Re: [lang] (RE)VOTE 2.1 Release

[Michael Heuer]

A few minor nits with the web site:

Links before commas and periods have an extra space, e.g. lang status
document . and Maven , JDiff , PMD , FindBugs on index.html.  I had
thought that this issue was resolved in an upgrade to maven and/or the
maven xdoc plugin?

Update tasks.html, user guide has been written.  (it is quite nice, by the
way)

Give userguide.html a header similar to that of developerguide.html.

userguide.html abbout --> about

userguide.html use CharSetUtils.delete("testtest", "tr")
instead of 'CharSetUtils.delete("testtest", "tr")' ?  What about the other
methods used in the text, should they be put in  tags as well?

developerguide.html nessesary --> necessary

A non-binding +1 from me.

   michael


On Tue, 26 Apr 2005, Steven Caswell wrote:

> Release candidate 3 (and hopefully final :) is in
> http://www.apache.org/~stevencaswell/commons-lang-2.1/
>
> The only changes between RC2 and RC3 are documentation clean-up (thanks to
> Gary for finding some inconsistencies). It would be good if someone could
> check the compatibility of the distribution with JDK 1.2.
>
> I know Stephen asked for a clirr, and I haven't had time to work on that,
> but I should be able to get it by tomorrow evening (ET).
>
> Not sure if another vote is necessary since I don't recall any -1s, but I'll
> go ahead and propose it and see what shakes out:
>
> [ ] +1
> [ ] -1
>
> --
> Steven Caswell
> [EMAIL PROTECTED]
>
> Take back the web - http://www.mozilla.org
>


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

DO NOT REPLY [Bug 25830] - [fileupload] Upload Progress Reporting

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]




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

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

Life cycle document?

[Dennis Lundberg]

Hello
I remember that someone wrote an excellent document describing the 
different states of a project's life cycle. For example whether it is 
active, mature, security-patches-only, dormant or unstable. I can't seem 
to find it on the web anymore. Does anyone know if it still exists and 
where it might be?

PS. I sent this to [EMAIL PROTECTED] a week ago, but didn't get any 
answers so I'll try here.

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

[lang] (RE)VOTE 2.1 Release

[Steven Caswell]

Release candidate 3 (and hopefully final :) is in
http://www.apache.org/~stevencaswell/commons-lang-2.1/

The only changes between RC2 and RC3 are documentation clean-up (thanks to 
Gary for finding some inconsistencies). It would be good if someone could 
check the compatibility of the distribution with JDK 1.2.

I know Stephen asked for a clirr, and I haven't had time to work on that, 
but I should be able to get it by tomorrow evening (ET).

Not sure if another vote is necessary since I don't recall any -1s, but I'll 
go ahead and propose it and see what shakes out:

[ ] +1
[ ] -1

-- 
Steven Caswell
[EMAIL PROTECTED]

Take back the web - http://www.mozilla.org

DO NOT REPLY [Bug 34613] - [digester] Need to process [attribute id="name"]somename[/attribute]

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|Need to process [attribute  |[digester] Need to process
   |id="name"]somename[/attribut|[attribute
   |e]  |id="name"]somename[/attribut
   ||e]




-- 
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: Collections 3.2/4.0 questions

[Chris Lambrou]

Hi Bryan,
After some discussions on the subject some time ago, it was decided that 
collections should concentrate on maintaining supporting for earlier JDK 
versions, whilst the Java 5.0 port should not carry over any Java 1.4 
baggage and concentrate on providing the same functionality as 
collections but with the freedom to make full use of the new 5.0 
language features. This 5.0 port was started on SourceForge since there 
weren't any commons committers who were able to commit to overseeing a 
5.0. port under the Apache Jakarta sandbox, but the aim is to bring the 
development from SourceForge to the sandbox once it has advanced 
sufficiently to attract the attentions of one or more commons 
committers.Sadly there's not been as much development on the Java 5.0 
port in recent weeks as I'd like, as there are only a small number of 
other developers and I've had some more pressing problems to deal with 
both at home and at work. Any contributions, either code or comments, 
would be much appreciated, especially as I plan to revisit the port over 
the next few weeks to try and help move it along some more.

Chris
P.S. Sorry I got your first name wrong in my previous post. I'm in a bit 
of a rush to get to work, so didn't read it as clearly as I should have.


Bryan W. Headley wrote:
Guys,
What are the plans, RE generics support being put into 
Commons-Collections? I'm in the middle of doing a conversion right 
now; I'm aware of a Collections 2.0(?) based port on sourceforge...

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