[jira] Created: (CONFIGURATION-282) NPE in HierarchicalConfiguration.fetchNodeList

2007-06-26 Thread Dennis Kieselhorst (JIRA)
NPE in HierarchicalConfiguration.fetchNodeList
--

 Key: CONFIGURATION-282
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-282
 Project: Commons Configuration
  Issue Type: Bug
Affects Versions: 1.4
 Environment: Linux, Java 1.5
Reporter: Dennis Kieselhorst


java.lang.NullPointerException
at 
org.apache.commons.configuration.HierarchicalConfiguration.fetchNodeList(HierarchicalConfiguration.java:721)
at 
org.apache.commons.configuration.AbstractHierarchicalFileConfiguration.fetchNodeList(AbstractHierarchicalFileConfiguration.java:338)
at 
org.apache.commons.configuration.HierarchicalConfiguration.getProperty(HierarchicalConfiguration.java:284)
at 
org.apache.commons.configuration.AbstractHierarchicalFileConfiguration.getProperty(AbstractHierarchicalFileConfiguration.java:319)
at 
org.apache.commons.configuration.AbstractConfiguration.resolveContainerStore(AbstractConfiguration.java:1222)
at 
org.apache.commons.configuration.AbstractConfiguration.getBoolean(AbstractConfiguration.java:667)
at 
org.apache.commons.configuration.AbstractConfiguration.getBoolean(AbstractConfiguration.java:633)


java.lang.NullPointerException
at 
org.apache.commons.configuration.HierarchicalConfiguration.fetchNodeList(HierarchicalConfiguration.java:721)
at 
org.apache.commons.configuration.AbstractHierarchicalFileConfiguration.fetchNodeList(AbstractHierarchicalFileConfiguration.java:338)
at 
org.apache.commons.configuration.HierarchicalConfiguration.getProperty(HierarchicalConfiguration.java:284)
at 
org.apache.commons.configuration.AbstractHierarchicalFileConfiguration.getProperty(AbstractHierarchicalFileConfiguration.java:319)
at 
org.apache.commons.configuration.AbstractConfiguration.resolveContainerStore(AbstractConfiguration.java:1222)
at 
org.apache.commons.configuration.AbstractConfiguration.getString(AbstractConfiguration.java:1097)
at 
org.apache.commons.configuration.AbstractConfiguration.getString(AbstractConfiguration.java:1077)


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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



Re: Invitation to join the Apache Commons PMC

2007-06-26 Thread simon
On Sun, 2007-06-24 at 21:16 +0100, Niall Pemberton wrote:
 Hi Simon,
 
 You've been nominated to become a part of the Apache Commons PMC and the vote
 has passed.
 
 Would you be interested in accepting the nomination?
 
 We understand that you were not in favour of the Commons TLP but,
 since the board has now passed the Commons resolution, hope that you
 still want to be involved with Commons and will accept this nomination

Yes, I would like to join the new Commons PMC. Thanks for the
invitation.



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



[ANNOUNCE] Commons Modeler 2.0.1 released

2007-06-26 Thread Niall Pemberton

The Commons team is pleased to announce the release of Commons Modeler
2.0.1. This is a minor bug fix release that corrects a number of build
issues found in the Modeler 2.0 release.

Commons Modeler is design to make the process of setting up JMX (Java
Management Extensions) MBeans easier by configuring the required meta
data using an XML descriptor. In addition, Modeler provides a factory
mechanism to create the actual Model MBean instances themselves. See
the Modeler website for more details:

Commons Modeler Website:
http://jakarta.apache.org/commons/modeler/

Release notes:
http://jakarta.apache.org/commons/modeler/commons-modeler-2.0.1/RELEASE-NOTES.txt

Download:
http://jakarta.apache.org/site/downloads/downloads_commons-modeler.cgi

Niall Pemberton,
on behalf of the Commons community

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



[jira] Created: (COLLECTIONS-258) DualLinkedHashBidiMap

2007-06-26 Thread Nathan Blomquist (JIRA)
DualLinkedHashBidiMap
-

 Key: COLLECTIONS-258
 URL: https://issues.apache.org/jira/browse/COLLECTIONS-258
 Project: Commons Collections
  Issue Type: New Feature
  Components: BidiMap
Reporter: Nathan Blomquist
Priority: Trivial


I recently needed a BidiMap that also maintained an insertion iteration order.  
I didn't find one in Commons Collections, but I did find a good framework for 
the creation of one.

I basically took the code from DualHashBidiMap and changed all the references 
from HashMap to LinkedHashMap.  This made it trivial to create.

Thanks for the great package!


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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



[jira] Updated: (COLLECTIONS-258) DualLinkedHashBidiMap

2007-06-26 Thread Nathan Blomquist (JIRA)

 [ 
https://issues.apache.org/jira/browse/COLLECTIONS-258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nathan Blomquist updated COLLECTIONS-258:
-

Attachment: DualLinkedHashBidiMap.java

This is the actual implementation.  Based off of the original 
DualHashBidiMap.java from Collections 3.1 or 3.2.

 DualLinkedHashBidiMap
 -

 Key: COLLECTIONS-258
 URL: https://issues.apache.org/jira/browse/COLLECTIONS-258
 Project: Commons Collections
  Issue Type: New Feature
  Components: BidiMap
Reporter: Nathan Blomquist
Priority: Trivial
 Attachments: DualLinkedHashBidiMap.java


 I recently needed a BidiMap that also maintained an insertion iteration 
 order.  I didn't find one in Commons Collections, but I did find a good 
 framework for the creation of one.
 I basically took the code from DualHashBidiMap and changed all the references 
 from HashMap to LinkedHashMap.  This made it trivial to create.
 Thanks for the great package!

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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



[jira] Closed: (COLLECTIONS-257) CollectionUtils.removeAll() calls ListUtils.retainAll()

2007-06-26 Thread Henri Yandell (JIRA)

 [ 
https://issues.apache.org/jira/browse/COLLECTIONS-257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Henri Yandell closed COLLECTIONS-257.
-

   Resolution: Duplicate
Fix Version/s: 3.3

Duplicate of COLLECTIONS-219, which has been fixed in trunk. 

 CollectionUtils.removeAll() calls ListUtils.retainAll()
 ---

 Key: COLLECTIONS-257
 URL: https://issues.apache.org/jira/browse/COLLECTIONS-257
 Project: Commons Collections
  Issue Type: Bug
  Components: Collection
Affects Versions: 3.2
Reporter: Sami Kallio
 Fix For: 3.3


 /**
  * Returns a collection containing all the elements in 
 codecollection/code
  * that are also in coderetain/code. The cardinality of an element 
 codee/code
  * in the returned collection is the same as the cardinality of 
 codee/code
  * in codecollection/code unless coderetain/code does not contain 
 codee/code, in which
  * case the cardinality is zero. This method is useful if you do not wish 
 to modify
  * the collection codec/code and thus cannot call 
 codec.retainAll(retain);/code.
  * 
  * @param collection  the collection whose contents are the target of the 
 #retailAll operation
  * @param retain  the collection containing the elements to be retained 
 in the returned collection
  * @return a codeCollection/code containing all the elements of 
 codecollection/code
  * that occur at least once in coderetain/code.
  * @throws NullPointerException if either parameter is null
  * @since Commons Collections 3.2
  */
 public static Collection retainAll(Collection collection, Collection 
 retain) {
 return ListUtils.retainAll(collection, retain);
 }
 /**
  * Removes the elements in coderemove/code from 
 codecollection/code. That is, this
  * method returns a collection containing all the elements in 
 codec/code
  * that are not in coderemove/code. The cardinality of an element 
 codee/code
  * in the returned collection is the same as the cardinality of 
 codee/code
  * in codecollection/code unless coderemove/code contains 
 codee/code, in which
  * case the cardinality is zero. This method is useful if you do not wish 
 to modify
  * the collection codec/code and thus cannot call 
 codecollection.removeAll(remove);/code.
  * 
  * @param collection  the collection from which items are removed (in the 
 returned collection)
  * @param remove  the items to be removed from the returned 
 codecollection/code
  * @return a codeCollection/code containing all the elements of 
 codecollection/code except
  * any elements that also occur in coderemove/code.
  * @throws NullPointerException if either parameter is null
  * @since Commons Collections 3.2
  */
 public static Collection removeAll(Collection collection, Collection 
 remove) {
 return ListUtils.retainAll(collection, remove);
 }
 I guess the later method shoud be:
 public static Collection removeAll(Collection collection, Collection 
 remove) {
 return ListUtils.removeAll(collection, remove);
 }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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



[jira] Commented: (SCXML-47) Provide a state machine support class to allow for delegation.

2007-06-26 Thread Michael Heuer (JIRA)

[ 
https://issues.apache.org/jira/browse/SCXML-47?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12508232
 ] 

Michael Heuer commented on SCXML-47:


the same problem exists in AbstractStateMachine itself, see SCXML-48

 Provide a state machine support class to allow for delegation.
 --

 Key: SCXML-47
 URL: https://issues.apache.org/jira/browse/SCXML-47
 Project: Commons SCXML
  Issue Type: Improvement
Affects Versions: 0.6
Reporter: Michael Heuer
Priority: Minor
 Fix For: 0.7

 Attachments: additional-tests.tar.gz, state-machine-support-src.tar.gz


 This is not completely thought out yet, but if folks like the idea I might 
 persue it further.
 I would like to use AbstractStateMachine but cannot extend from it:
 class B extends A /*, AbstractStateMachine */ {
   // copy source from AbstractStateMachine here
 }
 I propose here a StateMachineSupport class that provides for use by 
 subclassing and for use by delegation.  The constructors are a little messy, 
 but in the end I have
 public class StateMachineSupport {
   // use by subclassing
   protected StateMachineSupport(...) {
   }
   // use by delegation
   public StateMachineSupport(Object delegator, ...) {
   }
   // ... methods from AbstractStateMachine
 }
 public abstract class AbstractStateMachine extends StateMachineSupport {
   protected AbstractStateMachine(...) {
 super(...);
   }
 }
 // use by subclassing
 class ConcreteStateMachine extends AbstractStateMachine {
   ConcreteStateMachine() {
 super(...stopwatch.xml);
   }
   public void reset() { ... }
   public void running() { ... }
   public void paused() { ... }
   public void stopped() { ... }
 }
 // use by delegation
 class DelegatingStateMachine extends SomethingElse {
   StateMachineSupport delegate;
   DelegatingStateMachine() {
 delegate = new StateMachineSupport(this, ...stopwatch.xml);
   }
   public void reset() { ... }
   public void running() { ... }
   public void paused() { ... }
   public void stopped() { ... }
 }
 StateMachineSupport.java, AbstractStateMachine2.java, 
 StateMachineSupportTest.java, and AbstractStateMachine2Test.java attached.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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



[jira] Created: (SCXML-48) Cannot create more than one subclass of AbstractStateMachine

2007-06-26 Thread Michael Heuer (JIRA)
Cannot create more than one subclass of AbstractStateMachine


 Key: SCXML-48
 URL: https://issues.apache.org/jira/browse/SCXML-48
 Project: Commons SCXML
  Issue Type: Bug
Reporter: Michael Heuer
 Attachments: abstract-state-machine-test-src.tar.gz

Similar to the issue described in SCXML-47, the following test case will fail:

public void testMoreThanOneScxmlDocument() throws Exception {
URL fooScxmlDocument = getClass().getResource(foo.xml);
URL barScxmlDocument = getClass().getResource(bar.xml);

Foo foo = new Foo(fooScxmlDocument);
Bar bar = new Bar(barScxmlDocument);

assertTrue(fooCalled);
// bar's initialstate bar never called, since bar's 
AbstractStateMachine has
// static reference to stateMachine for foo.xml
assertTrue(barCalled);
}

private class Foo extends AbstractStateMachine {

public Foo(final URL scxmlDocument) {
super(scxmlDocument);
}

public void foo() {
fooCalled = true;
}
}

private class Bar extends AbstractStateMachine {

public Bar(final URL scxmlDocument) {
super(scxmlDocument);
}

public void bar() {
barCalled = true;
}
}

with simple SCXML files

foo.xml:
scxml xmlns=http://www.w3.org/2005/07/scxml; version=1.0 initialstate=foo
  state id=foo/
/scxml

bar.xml:
scxml xmlns=http://www.w3.org/2005/07/scxml; version=1.0 initialstate=bar
  state id=bar/
/scxml


[junit] Running org.apache.commons.scxml.env.EnvTestSuite
org.apache.commons.scxml.env.AbstractStateMachineTest$Bar.foo()
java.lang.NoSuchMethodException: 
org.apache.commons.scxml.env.AbstractStateMachineTest$Bar.foo()
at java.lang.Class.getDeclaredMethod(Class.java:1937)
at 
org.apache.commons.scxml.env.AbstractStateMachine.invoke(AbstractStateMachine.java:212)
at 
org.apache.commons.scxml.env.AbstractStateMachine$EntryListener.onEntry(AbstractStateMachine.java:269)


Testsuite: org.apache.commons.scxml.env.EnvTestSuite
Tests run: 21, Failures: 2, Errors: 0, Time elapsed: 0.391 sec

Testcase: 
testMoreThanOneScxmlDocument(org.apache.commons.scxml.env.AbstractStateMachineTest):
  FAILED
junit.framework.AssertionFailedError
at 
org.apache.commons.scxml.env.AbstractStateMachineTest.testMoreThanOneScxmlDocument(AbstractStateMachineTest.java:60)

Testcase: testStopWatch(org.apache.commons.scxml.env.StopWatchTest):FAILED
expected:reset but was:foo
junit.framework.ComparisonFailure: expected:reset but was:foo
at 
org.apache.commons.scxml.env.StopWatchTest.testStopWatch(StopWatchTest.java:56)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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



[jira] Updated: (SCXML-48) Cannot create more than one subclass of AbstractStateMachine

2007-06-26 Thread Michael Heuer (JIRA)

 [ 
https://issues.apache.org/jira/browse/SCXML-48?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Heuer updated SCXML-48:
---

Attachment: abstract-state-machine-test-src.tar.gz

unit test for AbstractStateMachine as described

 Cannot create more than one subclass of AbstractStateMachine
 

 Key: SCXML-48
 URL: https://issues.apache.org/jira/browse/SCXML-48
 Project: Commons SCXML
  Issue Type: Bug
Reporter: Michael Heuer
 Attachments: abstract-state-machine-test-src.tar.gz


 Similar to the issue described in SCXML-47, the following test case will fail:
 public void testMoreThanOneScxmlDocument() throws Exception {
 URL fooScxmlDocument = getClass().getResource(foo.xml);
 URL barScxmlDocument = getClass().getResource(bar.xml);
 Foo foo = new Foo(fooScxmlDocument);
 Bar bar = new Bar(barScxmlDocument);
 assertTrue(fooCalled);
 // bar's initialstate bar never called, since bar's 
 AbstractStateMachine has
 // static reference to stateMachine for foo.xml
 assertTrue(barCalled);
 }
 private class Foo extends AbstractStateMachine {
 public Foo(final URL scxmlDocument) {
 super(scxmlDocument);
 }
 public void foo() {
 fooCalled = true;
 }
 }
 private class Bar extends AbstractStateMachine {
 public Bar(final URL scxmlDocument) {
 super(scxmlDocument);
 }
 public void bar() {
 barCalled = true;
 }
 }
 with simple SCXML files
 foo.xml:
 scxml xmlns=http://www.w3.org/2005/07/scxml; version=1.0 
 initialstate=foo
   state id=foo/
 /scxml
 bar.xml:
 scxml xmlns=http://www.w3.org/2005/07/scxml; version=1.0 
 initialstate=bar
   state id=bar/
 /scxml
 [junit] Running org.apache.commons.scxml.env.EnvTestSuite
 org.apache.commons.scxml.env.AbstractStateMachineTest$Bar.foo()
 java.lang.NoSuchMethodException: 
 org.apache.commons.scxml.env.AbstractStateMachineTest$Bar.foo()
 at java.lang.Class.getDeclaredMethod(Class.java:1937)
 at 
 org.apache.commons.scxml.env.AbstractStateMachine.invoke(AbstractStateMachine.java:212)
 at 
 org.apache.commons.scxml.env.AbstractStateMachine$EntryListener.onEntry(AbstractStateMachine.java:269)
 Testsuite: org.apache.commons.scxml.env.EnvTestSuite
 Tests run: 21, Failures: 2, Errors: 0, Time elapsed: 0.391 sec
 Testcase: 
 testMoreThanOneScxmlDocument(org.apache.commons.scxml.env.AbstractStateMachineTest):
   FAILED
 junit.framework.AssertionFailedError
 at 
 org.apache.commons.scxml.env.AbstractStateMachineTest.testMoreThanOneScxmlDocument(AbstractStateMachineTest.java:60)
 Testcase: testStopWatch(org.apache.commons.scxml.env.StopWatchTest):FAILED
 expected:reset but was:foo
 junit.framework.ComparisonFailure: expected:reset but was:foo
 at 
 org.apache.commons.scxml.env.StopWatchTest.testStopWatch(StopWatchTest.java:56)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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



java.lang.NoSuchMethodError: com.sun.activation.registries.MailcapFile.getMailcapList(Ljava/lang/String;)Ljava/util/Map;

2007-06-26 Thread Shah, Dhara \(CT\)
Hey,

I have used the SimpleMail class just as it is on the User Guide.
However, I keep getting an error

 java.lang.NoSuchMethodError:
com.sun.activation.registries.MailcapFile.getMailcapList(Ljava/lang/Stri
ng;)Ljava/util/Map;

Can someone help me?


This message w/attachments (message) may be privileged, confidential or 
proprietary, and if you are not an intended recipient, please notify the 
sender, do not use or share it and delete it. Unless specifically indicated, 
this message is not an offer to sell or a solicitation of any investment 
products or other financial product or service, an official confirmation of any 
transaction, or an official statement of Merrill Lynch. Subject to applicable 
law, Merrill Lynch may monitor, review and retain e-communications (EC) 
traveling through its networks/systems. The laws of the country of each 
sender/recipient may impact the handling of EC, and EC may be archived, 
supervised and produced in countries other than the country in which you are 
located. This message cannot be guaranteed to be secure or error-free. This 
message is subject to terms available at the following link: 
http://www.ml.com/e-communications_terms/. By messaging with Merrill Lynch you 
consent to the foregoing.



[jira] Commented: (LANG-76) [lang] EnumUtils.getEnum() doesn't work well in 1.5

2007-06-26 Thread Joe Kelly (JIRA)

[ 
https://issues.apache.org/jira/browse/LANG-76?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12508298
 ] 

Joe Kelly commented on LANG-76:
---

I like Marcus Schulte's suggestion. EnumUtils.getEnum() should force class 
initialization.

 [lang] EnumUtils.getEnum() doesn't work well in 1.5
 ---

 Key: LANG-76
 URL: https://issues.apache.org/jira/browse/LANG-76
 Project: Commons Lang
  Issue Type: Bug
Affects Versions: 2.1
 Environment: Operating System: other
 Platform: Other
Reporter: Igor Laberov
 Fix For: 3.0


 Hi,
 I encountered with problem using EnumUtils.getEnum() in 1.5. It appears that 
 my
 Enum class should be accessed first so constructor will be called. In 1.4 it 
 was
 enough to have myClass.class, so all static members were initialized. In 1.5 
 it
 doesn't work.
 I noticed that static members are not initialized anymore while acessing to
 class definition. See the code
 public class Test {
 public static final class TT{
 public static final TT one = new TT();
 private TT(){
 System.out.println(Called TT );
 }
 }
 
 public static void main(String[] args) {
  Class cl = TT.class;
// System.out.println( TT.one);
   //  System.out.println(TT.class.isAssignableFrom(String.class));
 }
 }
 In 1.4 constructor of TT is called, while in 1.5 is not. 
 Actually, according to the spec
 (http://java.sun.com/docs/books/jls/second_edition/html/execution.doc.html#57946),
 this is right behavior of Java. 
 Unfortunately, I didn't succeded to think about good solution..
 P.s. I know that in 1.5 we have enum built-in, but it is not the same, and we
 try to move to 1.5 without too much changes

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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



[jira] Commented: (CONFIGURATION-282) NPE in HierarchicalConfiguration.fetchNodeList

2007-06-26 Thread Oliver Heger (JIRA)

[ 
https://issues.apache.org/jira/browse/CONFIGURATION-282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12508306
 ] 

Oliver Heger commented on CONFIGURATION-282:


It would really be helpful if you could provide some more information: How did 
you create the configuration object, which properties were set and which key 
did you pass in.

Since the last release development has been going on, so the line numbers are 
no longer valid.

Thanks.

 NPE in HierarchicalConfiguration.fetchNodeList
 --

 Key: CONFIGURATION-282
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-282
 Project: Commons Configuration
  Issue Type: Bug
Affects Versions: 1.4
 Environment: Linux, Java 1.5
Reporter: Dennis Kieselhorst

 java.lang.NullPointerException
 at 
 org.apache.commons.configuration.HierarchicalConfiguration.fetchNodeList(HierarchicalConfiguration.java:721)
 at 
 org.apache.commons.configuration.AbstractHierarchicalFileConfiguration.fetchNodeList(AbstractHierarchicalFileConfiguration.java:338)
 at 
 org.apache.commons.configuration.HierarchicalConfiguration.getProperty(HierarchicalConfiguration.java:284)
 at 
 org.apache.commons.configuration.AbstractHierarchicalFileConfiguration.getProperty(AbstractHierarchicalFileConfiguration.java:319)
 at 
 org.apache.commons.configuration.AbstractConfiguration.resolveContainerStore(AbstractConfiguration.java:1222)
 at 
 org.apache.commons.configuration.AbstractConfiguration.getBoolean(AbstractConfiguration.java:667)
 at 
 org.apache.commons.configuration.AbstractConfiguration.getBoolean(AbstractConfiguration.java:633)
 java.lang.NullPointerException
 at 
 org.apache.commons.configuration.HierarchicalConfiguration.fetchNodeList(HierarchicalConfiguration.java:721)
 at 
 org.apache.commons.configuration.AbstractHierarchicalFileConfiguration.fetchNodeList(AbstractHierarchicalFileConfiguration.java:338)
 at 
 org.apache.commons.configuration.HierarchicalConfiguration.getProperty(HierarchicalConfiguration.java:284)
 at 
 org.apache.commons.configuration.AbstractHierarchicalFileConfiguration.getProperty(AbstractHierarchicalFileConfiguration.java:319)
 at 
 org.apache.commons.configuration.AbstractConfiguration.resolveContainerStore(AbstractConfiguration.java:1222)
 at 
 org.apache.commons.configuration.AbstractConfiguration.getString(AbstractConfiguration.java:1097)
 at 
 org.apache.commons.configuration.AbstractConfiguration.getString(AbstractConfiguration.java:1077)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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



svn commit: r550948 - in /jakarta/commons/proper/scxml/trunk/src: main/java/org/apache/commons/scxml/env/ test/java/org/apache/commons/scxml/env/

2007-06-26 Thread rahul
Author: rahul
Date: Tue Jun 26 13:58:10 2007
New Revision: 550948

URL: http://svn.apache.org/viewvc?view=revrev=550948
Log:
SCXML-48 Broken subclassing for AbstractStateMachine.

Unrelated changes:
 - Two new constructors to avoid recurring parsing cost
 - Some cosmetic changes so the class Javadoc renders in a readable manner.

Thanks to Michael Heuer heuermh AT acm DOT org for the AbstractStateMachine 
tests (which now pass).

Added:

jakarta/commons/proper/scxml/trunk/src/test/java/org/apache/commons/scxml/env/AbstractStateMachineTest.java
   (with props)

jakarta/commons/proper/scxml/trunk/src/test/java/org/apache/commons/scxml/env/bar.xml
   (with props)

jakarta/commons/proper/scxml/trunk/src/test/java/org/apache/commons/scxml/env/foo.xml
   (with props)
Modified:

jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/env/AbstractStateMachine.java

jakarta/commons/proper/scxml/trunk/src/test/java/org/apache/commons/scxml/env/EnvTestSuite.java

Modified: 
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/env/AbstractStateMachine.java
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/env/AbstractStateMachine.java?view=diffrev=550948r1=550947r2=550948
==
--- 
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/env/AbstractStateMachine.java
 (original)
+++ 
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/env/AbstractStateMachine.java
 Tue Jun 26 13:58:10 2007
@@ -39,27 +39,27 @@
 import org.xml.sax.SAXException;
 
 /**
- * This class demonstrates one approach for providing the base
+ * pThis class demonstrates one approach for providing the base
  * functionality needed by classes representing stateful entities,
- * whose behaviors are defined via SCXML documents.
+ * whose behaviors are defined via SCXML documents./p
  *
- * SCXML documents (more generically, UML state chart diagrams) can be
+ * pSCXML documents (more generically, UML state chart diagrams) can be
  * used to define stateful behavior of objects, and Commons SCXML enables
  * developers to use this model directly into the corresponding code
  * artifacts. The resulting artifacts tend to be much simpler, embody
  * a useful separation of concerns and are easier to understand and
  * maintain. As the size of the modeled entity grows, these benefits
- * become more apparent.
+ * become more apparent./p
  *
- * This approach functions by registering an SCXMLListener that gets
+ * pThis approach functions by registering an SCXMLListener that gets
  * notified onentry, and calls the namesake method for each state that
- * has been entered.
+ * has been entered./p
  *
- * This class swallows all exceptions only to log them. Developers of
+ * pThis class swallows all exceptions only to log them. Developers of
  * subclasses should think of themselves as quot;component developersquot;
  * catering to other end users, and therefore ensure that the subclasses
  * are free of codeModelException/codes and the like. Most methods
- * are codeprotected/code for ease of subclassing.
+ * are codeprotected/code for ease of subclassing./p
  *
  */
 public abstract class AbstractStateMachine {
@@ -67,7 +67,7 @@
 /**
  * The state machine that will drive the instances of this class.
  */
-private static SCXML stateMachine;
+private SCXML stateMachine;
 
 /**
  * The instance specific SCXML engine.
@@ -92,7 +92,7 @@
 private static final Object[] PARAMETERS = new Object[0];
 
 /**
- * Convenience constructor.
+ * Convenience constructor, object instantiation incurs parsing cost.
  *
  * @param scxmlDocument The URL pointing to the SCXML document that
  *  describes the quot;lifecyclequot; of the
@@ -104,7 +104,7 @@
 }
 
 /**
- * Primary constructor.
+ * Primary constructor, object instantiation incurs parsing cost.
  *
  * @param scxmlDocument The URL pointing to the SCXML document that
  *  describes the quot;lifecyclequot; of the
@@ -118,20 +118,58 @@
 public AbstractStateMachine(final URL scxmlDocument,
 final Context rootCtx, final Evaluator evaluator) {
 log = LogFactory.getLog(this.getClass());
-if (stateMachine == null) {
-// parse only once per subclass
-ErrorHandler errHandler = new SimpleErrorHandler();
-try {
-stateMachine = SCXMLDigester.digest(scxmlDocument,
-errHandler);
-} catch (IOException ioe) {
-logError(ioe);
-} catch (SAXException sae) {
-logError(sae);
-} catch (ModelException me) {
-logError(me);
-}
+ErrorHandler errHandler = new SimpleErrorHandler();
+try {
+  

[jira] Resolved: (SCXML-48) Cannot create more than one subclass of AbstractStateMachine

2007-06-26 Thread Rahul Akolkar (JIRA)

 [ 
https://issues.apache.org/jira/browse/SCXML-48?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rahul Akolkar resolved SCXML-48.


   Resolution: Fixed
Fix Version/s: 0.7

Thanks for the tests. They've been added to the test suite and a fix has been 
applied. Should be available in tomorrow's nightly (or immediately via trunk).


 Cannot create more than one subclass of AbstractStateMachine
 

 Key: SCXML-48
 URL: https://issues.apache.org/jira/browse/SCXML-48
 Project: Commons SCXML
  Issue Type: Bug
Reporter: Michael Heuer
 Fix For: 0.7

 Attachments: abstract-state-machine-test-src.tar.gz


 Similar to the issue described in SCXML-47, the following test case will fail:
 public void testMoreThanOneScxmlDocument() throws Exception {
 URL fooScxmlDocument = getClass().getResource(foo.xml);
 URL barScxmlDocument = getClass().getResource(bar.xml);
 Foo foo = new Foo(fooScxmlDocument);
 Bar bar = new Bar(barScxmlDocument);
 assertTrue(fooCalled);
 // bar's initialstate bar never called, since bar's 
 AbstractStateMachine has
 // static reference to stateMachine for foo.xml
 assertTrue(barCalled);
 }
 private class Foo extends AbstractStateMachine {
 public Foo(final URL scxmlDocument) {
 super(scxmlDocument);
 }
 public void foo() {
 fooCalled = true;
 }
 }
 private class Bar extends AbstractStateMachine {
 public Bar(final URL scxmlDocument) {
 super(scxmlDocument);
 }
 public void bar() {
 barCalled = true;
 }
 }
 with simple SCXML files
 foo.xml:
 scxml xmlns=http://www.w3.org/2005/07/scxml; version=1.0 
 initialstate=foo
   state id=foo/
 /scxml
 bar.xml:
 scxml xmlns=http://www.w3.org/2005/07/scxml; version=1.0 
 initialstate=bar
   state id=bar/
 /scxml
 [junit] Running org.apache.commons.scxml.env.EnvTestSuite
 org.apache.commons.scxml.env.AbstractStateMachineTest$Bar.foo()
 java.lang.NoSuchMethodException: 
 org.apache.commons.scxml.env.AbstractStateMachineTest$Bar.foo()
 at java.lang.Class.getDeclaredMethod(Class.java:1937)
 at 
 org.apache.commons.scxml.env.AbstractStateMachine.invoke(AbstractStateMachine.java:212)
 at 
 org.apache.commons.scxml.env.AbstractStateMachine$EntryListener.onEntry(AbstractStateMachine.java:269)
 Testsuite: org.apache.commons.scxml.env.EnvTestSuite
 Tests run: 21, Failures: 2, Errors: 0, Time elapsed: 0.391 sec
 Testcase: 
 testMoreThanOneScxmlDocument(org.apache.commons.scxml.env.AbstractStateMachineTest):
   FAILED
 junit.framework.AssertionFailedError
 at 
 org.apache.commons.scxml.env.AbstractStateMachineTest.testMoreThanOneScxmlDocument(AbstractStateMachineTest.java:60)
 Testcase: testStopWatch(org.apache.commons.scxml.env.StopWatchTest):FAILED
 expected:reset but was:foo
 junit.framework.ComparisonFailure: expected:reset but was:foo
 at 
 org.apache.commons.scxml.env.StopWatchTest.testStopWatch(StopWatchTest.java:56)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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



[jira] Commented: (SCXML-47) Provide a state machine support class to allow for delegation.

2007-06-26 Thread Rahul Akolkar (JIRA)

[ 
https://issues.apache.org/jira/browse/SCXML-47?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12508326
 ] 

Rahul Akolkar commented on SCXML-47:


Indeed, that should be out of the way. Please ping if it isn't. While I was at 
it, I've added the additional constructors that avoid the recurring parsing 
cost (by accepting the parsed SCXML instance instead of the URL to the 
document).


 Provide a state machine support class to allow for delegation.
 --

 Key: SCXML-47
 URL: https://issues.apache.org/jira/browse/SCXML-47
 Project: Commons SCXML
  Issue Type: Improvement
Affects Versions: 0.6
Reporter: Michael Heuer
Priority: Minor
 Fix For: 0.7

 Attachments: additional-tests.tar.gz, state-machine-support-src.tar.gz


 This is not completely thought out yet, but if folks like the idea I might 
 persue it further.
 I would like to use AbstractStateMachine but cannot extend from it:
 class B extends A /*, AbstractStateMachine */ {
   // copy source from AbstractStateMachine here
 }
 I propose here a StateMachineSupport class that provides for use by 
 subclassing and for use by delegation.  The constructors are a little messy, 
 but in the end I have
 public class StateMachineSupport {
   // use by subclassing
   protected StateMachineSupport(...) {
   }
   // use by delegation
   public StateMachineSupport(Object delegator, ...) {
   }
   // ... methods from AbstractStateMachine
 }
 public abstract class AbstractStateMachine extends StateMachineSupport {
   protected AbstractStateMachine(...) {
 super(...);
   }
 }
 // use by subclassing
 class ConcreteStateMachine extends AbstractStateMachine {
   ConcreteStateMachine() {
 super(...stopwatch.xml);
   }
   public void reset() { ... }
   public void running() { ... }
   public void paused() { ... }
   public void stopped() { ... }
 }
 // use by delegation
 class DelegatingStateMachine extends SomethingElse {
   StateMachineSupport delegate;
   DelegatingStateMachine() {
 delegate = new StateMachineSupport(this, ...stopwatch.xml);
   }
   public void reset() { ... }
   public void running() { ... }
   public void paused() { ... }
   public void stopped() { ... }
 }
 StateMachineSupport.java, AbstractStateMachine2.java, 
 StateMachineSupportTest.java, and AbstractStateMachine2Test.java attached.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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



[jira] Commented: (BEANUTILS-142) [beanutils] RowSetDynaClass fails to copy resulset to DynaBean with Oracle 10g JDBC driver

2007-06-26 Thread dyna bean (JIRA)

[ 
https://issues.apache.org/jira/browse/BEANUTILS-142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12508330
 ] 

dyna bean commented on BEANUTILS-142:
-

Hello Niall Pemberton,

opps, yes you have right ,thanks. 

I have my project tested again with the new night version (20070626), same 
exception :

 org.apache.commons.beanutils.ConversionException: Cannot assign value of type 
'java.sql.Date' to property 'stand' of type 'java.sql.Timestamp'
at 
org.apache.commons.beanutils.BasicDynaBean.set(BasicDynaBean.java:297)
at 
org.apache.commons.beanutils.RowSetDynaClass.copy(RowSetDynaClass.java:240)
at 
org.apache.commons.beanutils.RowSetDynaClass.init(RowSetDynaClass.java:187)
at 
org.apache.commons.beanutils.RowSetDynaClass.init(RowSetDynaClass.java:105)

I think, it is fixed with one change line in class RowSetDynaClass, it work at 
least.

protected void copy(ResultSet resultSet) throws SQLException {
...
  Class type = properties[i].getType(); //Old : 
properties[i].getClass()
   ...
}

 [beanutils] RowSetDynaClass fails to copy resulset to DynaBean with Oracle 
 10g JDBC driver
 --

 Key: BEANUTILS-142
 URL: https://issues.apache.org/jira/browse/BEANUTILS-142
 Project: Commons BeanUtils
  Issue Type: Bug
  Components: DynaBean
 Environment: Operating System: Windows XP
 Platform: All
Reporter: Li Zhang
 Fix For: 1.8.0

 Attachments: Beanutils-142.patch


 Beginning in Oracle 9.2, DATE is mapped to Date and TIMESTAMP is mapped to
 Timestamp. However if you were relying on DATE values to contain time
 information, there is a problem. When using Oracle 10g JDBC driver, the
 ResultSetMetaData.getColumnClassName returns java.sql.Timestamp but
 ResultSet.getObject(name).getClass() returns java.sql.Date. Obviously these 
 two
 do not match each other. When the RowSetDynaClass.copy function tries to set 
 the
 value to BasicDynaBean, it throws exception. Need a workaround.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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



[jira] Updated: (BEANUTILS-142) [beanutils] RowSetDynaClass fails to copy resulset to DynaBean with Oracle 10g JDBC driver

2007-06-26 Thread dyna bean (JIRA)

 [ 
https://issues.apache.org/jira/browse/BEANUTILS-142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

dyna bean updated BEANUTILS-142:


Comment: was deleted

 [beanutils] RowSetDynaClass fails to copy resulset to DynaBean with Oracle 
 10g JDBC driver
 --

 Key: BEANUTILS-142
 URL: https://issues.apache.org/jira/browse/BEANUTILS-142
 Project: Commons BeanUtils
  Issue Type: Bug
  Components: DynaBean
 Environment: Operating System: Windows XP
 Platform: All
Reporter: Li Zhang
 Fix For: 1.8.0

 Attachments: Beanutils-142.patch


 Beginning in Oracle 9.2, DATE is mapped to Date and TIMESTAMP is mapped to
 Timestamp. However if you were relying on DATE values to contain time
 information, there is a problem. When using Oracle 10g JDBC driver, the
 ResultSetMetaData.getColumnClassName returns java.sql.Timestamp but
 ResultSet.getObject(name).getClass() returns java.sql.Date. Obviously these 
 two
 do not match each other. When the RowSetDynaClass.copy function tries to set 
 the
 value to BasicDynaBean, it throws exception. Need a workaround.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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



Commons PMC += Simon Kitching

2007-06-26 Thread Torsten Curdt

Please acknowledge

http://mail-archives.apache.org/mod_mbox/jakarta-commons-dev/ 
200706.mbox/% 
[EMAIL PROTECTED]


cheers
--
Torsten

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



Commons PMC += Rahul Akolar

2007-06-26 Thread Torsten Curdt

Please acknowledge

http://mail-archives.apache.org/mod_mbox/jakarta-commons-dev/ 
200706.mbox/% 
[EMAIL PROTECTED]


cheers
--
Torsten

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



Re: Invitation to join the Apache Commons PMC

2007-06-26 Thread Torsten Curdt


On 26.06.2007, at 02:58, Niall Pemberton wrote:


On 6/25/07, Rahul Akolkar [EMAIL PROTECTED] wrote:

Process-wise, the chair might need to ascertain the board's lazy
consensus. But, you probably know better.


AFAIK the chair pings the board after someone accepts and its
effective 24 hours after its been ACK'd by a board member.

Torsten?


Sorry, I have been traveling. Done.

cheers
--
Torsten


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



svn commit: r551000 - in /jakarta/commons/proper/fileupload/trunk: ./ src/changes/ src/java/org/apache/commons/fileupload/ src/test/org/apache/commons/fileupload/

2007-06-26 Thread jochen
Author: jochen
Date: Tue Jun 26 17:59:16 2007
New Revision: 551000

URL: http://svn.apache.org/viewvc?view=revrev=551000
Log:
Short files could cause an unexpected end of the item stream.
PR: FILEUPLOAD-135
Submitted-By: Alexander Sova [EMAIL PROTECTED]

Modified:
jakarta/commons/proper/fileupload/trunk/pom.xml
jakarta/commons/proper/fileupload/trunk/src/changes/changes.xml

jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/FileUploadException.java

jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/MultipartStream.java

jakarta/commons/proper/fileupload/trunk/src/test/org/apache/commons/fileupload/MockHttpServletRequest.java

jakarta/commons/proper/fileupload/trunk/src/test/org/apache/commons/fileupload/StreamingTest.java

Modified: jakarta/commons/proper/fileupload/trunk/pom.xml
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/fileupload/trunk/pom.xml?view=diffrev=551000r1=550999r2=551000
==
--- jakarta/commons/proper/fileupload/trunk/pom.xml (original)
+++ jakarta/commons/proper/fileupload/trunk/pom.xml Tue Jun 26 17:59:16 2007
@@ -105,6 +105,10 @@
   email[EMAIL PROTECTED]/email
 /contributor
 contributor
+  nameAlexander Sova/name
+  email[EMAIL PROTECTED]/email
+/contributor
+contributor
   nameThomas Vandahl/name
   email[EMAIL PROTECTED]/email
 /contributor

Modified: jakarta/commons/proper/fileupload/trunk/src/changes/changes.xml
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/fileupload/trunk/src/changes/changes.xml?view=diffrev=551000r1=550999r2=551000
==
--- jakarta/commons/proper/fileupload/trunk/src/changes/changes.xml (original)
+++ jakarta/commons/proper/fileupload/trunk/src/changes/changes.xml Tue Jun 26 
17:59:16 2007
@@ -64,56 +64,50 @@
   due-to=Thomas Vandahl due-to-email=[EMAIL PROTECTED]
 DiskFileItem.toString() could throw an NPE.
   /action
+  action dev=jochen type=fix issue=FILEUPLOAD-135
+  due-to=Alexander Sova due-to-email=[EMAIL PROTECTED]
+Short files could cause an unexpected end of the item stream.
+  /action
 /release
 
release version=1.2 date=2007-02-13
-
   action dev=jochen type=fix due-to=Aaron Freeman
due-to-email=[EMAIL PROTECTED]
 Made Streams.asString static.
   /action
-
  action dev=jochen type=update issue=FILEUPLOAD-109
Eliminated duplicate code.
  /action
-
  action dev=jochen type=add issue=FILEUPLOAD-112
Added a streaming API.
  /action
-
  action dev=jochen type=fix issue=FILEUPLOAD-93
Eliminated the necessity of a content-length header.
  /action
-
   action dev=jochen type=fix issue=FILEUPLOAD-108
   due-to=Amichai Rothman due-to-email=[EMAIL PROTECTED]
 Eliminated the limitation of a maximum size for a single
 header line. (The total size of all headers is already
 limited, so there's no need for another limit.)  
   /action
-
   action dev=jochen type=add issue=FILEUPLOAD-87
 Added the ProgressListener, which allows to implement a
 progress bar.
   /action
-
   action dev=jochen type=add issue=FILEUPLOAD-111
   due-to=Amichai Rothman due-to-email=[EMAIL PROTECTED]
 Added support for header continuation lines.
   /action
-
   action dev=jochen type=add issue=FILEUPLOAD-88
   due-to=Andrey Aristarkhov due-to-email=[EMAIL PROTECTED]
 It is now possible to limit the actual file size and not
 the request size.
   /action
-
   action dev=jochen type=add issue=FILEUPLOAD-120
   due-to=Henry Yandell due-to-email=[EMAIL PROTECTED]
 Added the FileCleanerCleanup as an example for how to close
 down the FileCleaner's reaper thread nicely.
   /action
-
   action dev=jochen type=fix issue=FILEUPLOAD-123
 A descriptive NPE is now thrown, if the FileItemFactory
 has not been set.

Modified: 
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/FileUploadException.java
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/FileUploadException.java?view=diffrev=551000r1=550999r2=551000
==
--- 
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/FileUploadException.java
 (original)
+++ 
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/FileUploadException.java
 Tue Jun 26 17:59:16 2007
@@ -92,4 +92,8 @@
 cause.printStackTrace(writer);
 }
 }
+
+public Throwable getCause() {
+return cause;
+}
 }

[jira] Resolved: (FILEUPLOAD-135) InputStream created with Streaming API returns EOF on first read() for short files uploaded from FireFox over HTTPS

2007-06-26 Thread Jochen Wiedmann (JIRA)

 [ 
https://issues.apache.org/jira/browse/FILEUPLOAD-135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jochen Wiedmann resolved FILEUPLOAD-135.


   Resolution: Fixed
Fix Version/s: 1.2.1
 Assignee: Jochen Wiedmann

Applied, thank you!


 InputStream created with Streaming API returns EOF on first read() for short 
 files uploaded from FireFox over HTTPS
 ---

 Key: FILEUPLOAD-135
 URL: https://issues.apache.org/jira/browse/FILEUPLOAD-135
 Project: Commons FileUpload
  Issue Type: Bug
Affects Versions: 1.2, 1.2.1
 Environment: Windows XP
 Browser: Firefox 1.5.0.11
 Protocol: HTTPS
Reporter: Alexander Sova
Assignee: Jochen Wiedmann
 Fix For: 1.2.1

 Attachments: commons-fileupload-1.1-bug-short-file-eof.patch, 
 commons-fileupload-1.2-bug-short-file-eof.patch, FILEUPLOAD135.patch


 This problem happens only with files shorer then boundary string generated by 
 browser and only with Firefox using HTTPS protocol.
 For some reason in this particular environment inputStream.read() in 
 MultipartStream.ItemInputStream.makeAvailable() reads not whole HTTP response 
 body, but only file content before boundary string. 
 I've created a patch fixing this issue.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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



[jira] Resolved: (FILEUPLOAD-137) MultipartStream public API broken

2007-06-26 Thread Jochen Wiedmann (JIRA)

 [ 
https://issues.apache.org/jira/browse/FILEUPLOAD-137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jochen Wiedmann resolved FILEUPLOAD-137.


   Resolution: Fixed
Fix Version/s: 1.2.1
 Assignee: Jochen Wiedmann

 MultipartStream public API broken
 -

 Key: FILEUPLOAD-137
 URL: https://issues.apache.org/jira/browse/FILEUPLOAD-137
 Project: Commons FileUpload
  Issue Type: Bug
Affects Versions: 1.2
Reporter: Mark Sinke
Assignee: Jochen Wiedmann
 Fix For: 1.2.1


 In commons-transaction 1.2 the MultipartStream class has 2 public 
 constructors. Both are deprecated; however their implementation delegates to 
 non-visible (package-private) constructors. There are two issues here:
 1. the deprecated, delegating constructors use a null pointer for the 
 progress notifier, which in turn yield a NullPointerException when you try to 
 use them
 2. the non-deprecated constructors are not visible.
 Hence, I cannot really upgrade from 1.0 to 1.2.
 Thanks,
 Mark.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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



[jira] Resolved: (FILEUPLOAD-110) MultipartStream's keep region padding is either unnecessary or untested (and undocumented)

2007-06-26 Thread Jochen Wiedmann (JIRA)

 [ 
https://issues.apache.org/jira/browse/FILEUPLOAD-110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jochen Wiedmann resolved FILEUPLOAD-110.


Resolution: Fixed
  Assignee: Jochen Wiedmann

The extra bytes are no longer used. 

 MultipartStream's keep region padding is either unnecessary or untested (and 
 undocumented)
 --

 Key: FILEUPLOAD-110
 URL: https://issues.apache.org/jira/browse/FILEUPLOAD-110
 Project: Commons FileUpload
  Issue Type: Bug
Affects Versions: 1.1 Final
Reporter: Amichai Rothman
Assignee: Jochen Wiedmann
Priority: Minor
 Attachments: commons-fileupload-1.1-bug-removed-keep-region.patch


 MultipartStream has logic and constants related to a keep region which, 
 according to the docs, is
 The amount of data, in bytes, that must be kept in the buffer in order to 
 detect delimiters reliably.
 However, why that region is needed, why the padding is set to 3, and what 
 makes it more reliable, is undocumented. Furthermore, when setting 
 KEEP_REGION_PAD to zero (which effectively bypasses the extra keep region 
 padding mechanism - it simply uses the boundary delimiter size, which makes 
 sense), all tests pass successfully. 
 so... either the extra padding is required but whatever it is required for is 
 untested and undocumented, which should be corrected, or it is indeed 
 unneeded, in which case all the keep region related code and constants can be 
 deleted, and the code where the actual delimiters are searched for can be 
 modified to simply use the boundary length instead of keepRegion.
 Note: I suspect the keep region pad may be a patch to compensate for the 
 skipPreamble() patch which modifies the global boundary, calls a method which 
 uses it, and the restores the global variable. If this is the case, this can 
 all be reorganized in a clear and straightforward manner (with no awkward 
 patches) by using an internal utility method that simply reads data into a 
 given outputstream until a given delimiter is reached. this can then be used 
 by readHeaders, readBodyData, discardBodyData, and skipPreamble, all of which 
 require this same basic underlying functionality. I'd be happy to provide 
 this code change, if this seems like a correct analysis to you...

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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



svn commit: r551002 - /jakarta/commons/proper/io/branches/b1_3/src/java/org/apache/commons/io/FileCleaner.java

2007-06-26 Thread jochen
Author: jochen
Date: Tue Jun 26 18:33:05 2007
New Revision: 551002

URL: http://svn.apache.org/viewvc?view=revrev=551002
Log:
Removed the @deprecation tags.

Modified:

jakarta/commons/proper/io/branches/b1_3/src/java/org/apache/commons/io/FileCleaner.java

Modified: 
jakarta/commons/proper/io/branches/b1_3/src/java/org/apache/commons/io/FileCleaner.java
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/io/branches/b1_3/src/java/org/apache/commons/io/FileCleaner.java?view=diffrev=551002r1=551001r2=551002
==
--- 
jakarta/commons/proper/io/branches/b1_3/src/java/org/apache/commons/io/FileCleaner.java
 (original)
+++ 
jakarta/commons/proper/io/branches/b1_3/src/java/org/apache/commons/io/FileCleaner.java
 Tue Jun 26 18:33:05 2007
@@ -35,7 +35,6 @@
  * @author Noel Bergman
  * @author Martin Cooper
  * @version $Id$
- * @deprecated Use [EMAIL PROTECTED] FileCleaningTracker}
  */
 public class FileCleaner {
 /**
@@ -52,7 +51,6 @@
  * @param file  the file to be tracked, not null
  * @param marker  the marker object used to track the file, not null
  * @throws NullPointerException if the file is null
- * @deprecated Use [EMAIL PROTECTED] FileCleaningTracker#track(File, 
Object)}.
  */
 public static void track(File file, Object marker) {
 theInstance.track(file, marker);
@@ -67,7 +65,6 @@
  * @param marker  the marker object used to track the file, not null
  * @param deleteStrategy  the strategy to delete the file, null means 
normal
  * @throws NullPointerException if the file is null
- * @deprecated Use [EMAIL PROTECTED] FileCleaningTracker#track(File, 
Object, FileDeleteStrategy)}.
  */
 public static void track(File file, Object marker, FileDeleteStrategy 
deleteStrategy) {
 theInstance.track(file, marker, deleteStrategy);
@@ -81,7 +78,6 @@
  * @param path  the full path to the file to be tracked, not null
  * @param marker  the marker object used to track the file, not null
  * @throws NullPointerException if the path is null
- * @deprecated Use [EMAIL PROTECTED] FileCleaningTracker#track(String, 
Object)}.
  */
 public static void track(String path, Object marker) {
 theInstance.track(path, marker);
@@ -96,7 +92,6 @@
  * @param marker  the marker object used to track the file, not null
  * @param deleteStrategy  the strategy to delete the file, null means 
normal
  * @throws NullPointerException if the path is null
- * @deprecated Use [EMAIL PROTECTED] FileCleaningTracker#track(String, 
Object, FileDeleteStrategy)}.
  */
 public static void track(String path, Object marker, FileDeleteStrategy 
deleteStrategy) {
 theInstance.track(path, marker, deleteStrategy);
@@ -108,7 +103,6 @@
  * awaiting deletion.
  *
  * @return the number of files being tracked
- * @deprecated Use [EMAIL PROTECTED] FileCleaningTracker#getTrackCount()}.
  */
 public static int getTrackCount() {
 return theInstance.getTrackCount();
@@ -134,7 +128,6 @@
  * This method allows the thread to be terminated. Simply call this method
  * in the resource cleanup code, such as [EMAIL PROTECTED] 
javax.servlet.ServletContextListener#contextDestroyed}.
  * One called, no new objects can be tracked by the file cleaner.
- * @deprecated Use [EMAIL PROTECTED] 
FileCleaningTracker#exitWhenFinished()}.
  */
 public static synchronized void exitWhenFinished() {
 theInstance.exitWhenFinished();



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



svn commit: r551003 - /jakarta/commons/proper/io/branches/b1_3/src/main/assembly/src.xml

2007-06-26 Thread jochen
Author: jochen
Date: Tue Jun 26 18:35:56 2007
New Revision: 551003

URL: http://svn.apache.org/viewvc?view=revrev=551003
Log:
Using the -src suffix now for the source distribution.

Modified:
jakarta/commons/proper/io/branches/b1_3/src/main/assembly/src.xml

Modified: jakarta/commons/proper/io/branches/b1_3/src/main/assembly/src.xml
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/io/branches/b1_3/src/main/assembly/src.xml?view=diffrev=551003r1=551002r2=551003
==
--- jakarta/commons/proper/io/branches/b1_3/src/main/assembly/src.xml (original)
+++ jakarta/commons/proper/io/branches/b1_3/src/main/assembly/src.xml Tue Jun 
26 18:35:56 2007
@@ -20,9 +20,7 @@
 formattar.gz/format
 formatzip/format
 /formats
-!--
 baseDirectory${project.build.finalName}-src/baseDirectory
- --
 fileSets
 fileSet
 includes



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



svn commit: r551004 - /jakarta/commons/proper/io/branches/b1_3/src/main/assembly/src.xml

2007-06-26 Thread jochen
Author: jochen
Date: Tue Jun 26 18:50:28 2007
New Revision: 551004

URL: http://svn.apache.org/viewvc?view=revrev=551004
Log:
Using the -src suffix now for the source distribution.

Modified:
jakarta/commons/proper/io/branches/b1_3/src/main/assembly/src.xml

Modified: jakarta/commons/proper/io/branches/b1_3/src/main/assembly/src.xml
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/io/branches/b1_3/src/main/assembly/src.xml?view=diffrev=551004r1=551003r2=551004
==
--- jakarta/commons/proper/io/branches/b1_3/src/main/assembly/src.xml (original)
+++ jakarta/commons/proper/io/branches/b1_3/src/main/assembly/src.xml Tue Jun 
26 18:50:28 2007
@@ -20,7 +20,7 @@
 formattar.gz/format
 formatzip/format
 /formats
-baseDirectory${project.build.finalName}-src/baseDirectory
+baseDirectorycommons-io-1.3.2-src/baseDirectory
 fileSets
 fileSet
 includes



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



Re: fileUpload bug report

2007-06-26 Thread Jochen Wiedmann

On 6/20/07, Nils Miehe [EMAIL PROTECTED] wrote:


I'm quite sure I found a bug in the fileUpload module:


Might be related to FILEUPLOAD-135, which I have applied tonight.
Checkout the latest source and verify whether that fixes your problem.


--
Besides, manipulating elections is under penalty of law, resulting in
a preventative effect against manipulating elections.

The german government justifying the use of electronic voting machines
and obviously  believing that we don't need a police, because all
illegal actions are forbidden.

http://dip.bundestag.de/btd/16/051/1605194.pdf

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



[VOTE] 4th attempt: Release commons-io 1.3.2

2007-06-26 Thread Jochen Wiedmann

Hi,

I have prepared a further release candidate, with the following changes:

- Deprecation tags have been removed from the FileCleaner. (In the 1.3
branch only,
 not in the trunk.) The discussion has clearly shown, that opinions
vary on this
 topic, nevertheless I feel forced to make that change against my
personal opinion.
 IMO, releasing a 1.4 release with as little changes as that would be
the greater
 evil.
- The extracted source distribution is now using the -src suffix.
- The .md5 and .sha1 files meet the commons standard and have the format
checksum *filename

Please cast your vote.

Thanks,

Jochen

[ ] +1
[ ] =0
[ ] -1



--
Besides, manipulating elections is under penalty of law, resulting in
a preventative effect against manipulating elections.

The german government justifying the use of electronic voting machines
and obviously  believing that we don't need a police, because all
illegal actions are forbidden.

http://dip.bundestag.de/btd/16/051/1605194.pdf

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



svn commit: r551047 - in /jakarta/commons/proper/beanutils/trunk/src: java/org/apache/commons/beanutils/ConvertUtilsBean.java test/org/apache/commons/beanutils/ConvertUtilsTestCase.java

2007-06-26 Thread niallp
Author: niallp
Date: Tue Jun 26 22:34:15 2007
New Revision: 551047

URL: http://svn.apache.org/viewvc?view=revrev=551047
Log:
BEANUTILS-258 Improve ConvertUtilsBean's new convert(Object, Class) method - if 
the registered Converter cannot handle conversion to String then try using the 
registered String converter, before trying the Object's toString() method. 
Highlighted by the problems BeanUtils changes caused to Betwixt - thanks to 
Martin van den Bemt - see http://tinyurl.com/26ahat

Modified:

jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/ConvertUtilsBean.java

jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/ConvertUtilsTestCase.java

Modified: 
jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/ConvertUtilsBean.java
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/ConvertUtilsBean.java?view=diffrev=551047r1=551046r2=551047
==
--- 
jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/ConvertUtilsBean.java
 (original)
+++ 
jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/ConvertUtilsBean.java
 Tue Jun 26 22:34:15 2007
@@ -544,7 +544,23 @@
 }
 if (targetType == String.class  converted != null  
 !(converted instanceof String)) {
-converted = converted.toString();
+
+// NOTE: For backwards compatibility, if the Converter
+//   doesn't handle  conversion--String then
+//   use the registered String Converter
+converter = lookup(String.class);
+if (converter != null) {
+if (log.isTraceEnabled()) {
+log.trace(  Using converter  + converter);
+}
+converted = converter.convert(String.class, converted);
+}
+
+// If the object still isn't a String, use toString() method
+if (converted != null  !(converted instanceof String)) {
+converted = converted.toString();
+}
+
 }
 return converted;
 

Modified: 
jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/ConvertUtilsTestCase.java
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/ConvertUtilsTestCase.java?view=diffrev=551047r1=551046r2=551047
==
--- 
jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/ConvertUtilsTestCase.java
 (original)
+++ 
jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/ConvertUtilsTestCase.java
 Tue Jun 26 22:34:15 2007
@@ -614,23 +614,46 @@
 }
 
 public void testConvertToString() throws Exception {
+Converter dummyConverter = new Converter() {
+public Object convert(Class type, Object value) {
+return value;
+}
+};
 
-ConvertUtilsBean utils = new ConvertUtilsBean();
+Converter fooConverter = new Converter() {
+public Object convert(Class type, Object value) {
+return Foo-Converter;
+}
+};
 
-// Register a DateConverter using Locale.US
 DateConverter dateConverter = new DateConverter();
 dateConverter.setLocale(Locale.US);
+
+ConvertUtilsBean utils = new ConvertUtilsBean();
 utils.register(dateConverter, java.util.Date.class);
+utils.register(fooConverter, String.class);
 
+// Convert using registerd DateConverter
 java.util.Date today = new java.util.Date();
 DateFormat fmt = new SimpleDateFormat(M/d/yy); /* US Short Format */
 String expected = fmt.format(today);
-
-assertEquals(date M/d/yy, expected, utils.convert(today, 
String.class));
+assertEquals(DateConverter M/d/yy, expected, utils.convert(today, 
String.class));
 
-// Remove the registered DateConverter
+// Date converter doesn't do String conversion - use String Converter
+utils.register(dummyConverter, java.util.Date.class);
+assertEquals(Date Converter doesn't do String conversion, 
Foo-Converter, utils.convert(today, String.class));
+
+// No registered Date converter - use String Converter
 utils.deregister(java.util.Date.class);
-assertEquals(Date.toString(), today.toString(), utils.convert(today, 
String.class));
+assertEquals(No registered Date converter, Foo-Converter, 
utils.convert(today, String.class));
+
+// String Converter doesn't do Strings!!!
+utils.register(dummyConverter, String.class);
+assertEquals(String Converter doesn't do Strings!!!, 
today.toString(), utils.convert(today, 

[BeanUtils] Backwards Compatibility of new Converter features

2007-06-26 Thread Niall Pemberton

On 6/23/07, Martin van den Bemt [EMAIL PROTECTED] wrote:

Noticed the call of toString() on a String during the huntdown of what in 
beanutils broke the
betwixt tests. (in the TestObjectStringConverters)
The commit was a bit premature probably, although this is most (read most, so 
not all) of the time
faster that calling toString() on a String. Will revert it (after some sleep) 
if that is what you
are asking (code is more readable without the addition, agreed).

Another questions (probably related to BEANUTILS-258) : The failing gump of 
betwixt is related to
the changes you made to ConvertUtilsBean.convert(Object). In beanutils 1.7 a 
default lookup is done
for the type String.class and in the new code this is just the case when no 
converter can be found
for the sourcetype, which makes the new beanutils code not a drop in 
replacement of the old one and
not backward compatible. I will see if I can run the beanutils 1.7 testcases 
against trunk tomorrow
(they should pass, or am I being simplistic here?)

Was this breakage intended and what are your thoughts on how to handle this ?


I only see 6 failures in 2 test cases (and looking at the gump output
seems the same) and really its only 3 because one test case extends
the other and its the same failures.

TestObjectStringConverters (3 failures)
 - testConvertUtilsConverter
 - testDefaultOSConverter
 - testDefaultOSConverterDates

Testi18nObjectStringConversion (3 failures)
(same failures as above since it inherits from TestObjectStringConverters)

The cause is the same in all cases - these tests are effectively
testing that ConvertUtils is delegating to the Converter registered
for the String.class. This is what I (intentionally) changed.

http://issues.apache.org/jira/browse/BEANUTILS-258

The contract for BeanUtils's Converter includes the type you want to
convert to. Unfortunately the Converter implementations mostly ignored
this and for conversion to String ConvertUtils delegated to the
registered String Converter. Makes more sense to me if the Converter
registered for the Type handled conversion from the type to String.
So for example - the date Converter implementations can now be
configured with a pattern ( Locale) and use that pattern to convert
from String to Date and from Date to String. The same is true for the
improved number converters (which can now also be configured with
patterns and a Locale).

In light of the betwixt issue I have made one change to the
ConvertUtilsBean's new convert() method - if the registered Converter
doesn't convert the value to a String it tries the registered String
Conveter first - before then defaulting to the object's toString()
method. This only partially resolves the compatability issue though
and doesn't stop Betwixt tests failing.

http://svn.apache.org/viewvc?view=revrevision=551047

On the compatibility issue - I believe the Converter implementations
provided by BeanUtils are backwards compatible and its only where
people have registered their own implementations that there may be
issues. With my change today - if their Converter implementations
don't handle conversion to String then it will continue to delegate to
the registered String Converter - if their Converter doesn't cope well
with that then they have an issue. The solution is fairly straight
forward though since I have added a new AbstractConverter
implementation that provides a structure to easily add String
conversion capability. The question is though whether this is all
enough (IMO yes).

If not then the one option would for the existing ConvertUtilsBean's
convert() methods to revert to their previour behaviour (and be
deprecated?) and not delegate to the new convert() method impl. This
would resolve the issue for Betwixt (which uses
ConvertUtils/ConvertUtilsBean) - but not for BeanUtils/BeanUtilsBean -
whose methods (setProperty/copyProperty) should IMO use the new
features.

Another option would be to reinstate backward compatible behaviour
with a configuration option (not sure what default would be) to switch
on/off the new features. Personally I'm not keen on doing that work
but if that is the preferred route I would hope the default behaviour
would be the new, rather than old behaviour.

Opinions?

Niall

P.S. If the consensus is to leave BeanUtils as it is - the Betwixt
tests can be made to work with both the current BeanUtils trunk and
the previous (1.7.0) release with only minor modifications, which I
can do.


Mvgr,
Martin

Niall Pemberton wrote:
 Is there a reason for this change? AFAIK calling toString() on a
 String object just returns a reference to itself - so this just seems
 to add clutter in my mind. Also there was discussion on this (i.e.
 calling toString() on a String) for this very bit of code in the
 following issue ticket - would have been nice to comment before
 arbitarily making the change

 http://issues.apache.org/jira/browse/BEANUTILS-283

 Niall

 On 6/23/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
 Author: