[jira] Commented: (JELLY-168) jelly-tags/swing can not build
[
http://nagoya.apache.org/jira/browse/JELLY-168?page=comments#action_55964 ]
carsten madsen commented on JELLY-168:
--
I got jelly from the CVS rep. I only fetched the jelly module from cvs.
cvs co jakarta-commons/jelly
with:
CVSROOT=:pserver:[EMAIL PROTECTED]:/home/cvspublic
Doing a cvs log project.properties gives:
RCS file: /home/cvspublic/jakarta-commons/jelly/project.properties,v
Working file: project.properties
head: 1.27
branch:
locks: strict
access list:
symbolic names:
COMMONS_JELLY-1_0_RC1: 1.27
COMMONS-JELLY-1_0-beta-4: 1.27
JELLY_PRE_EXCEPTION_REFACTOR: 1.15
keyword substitution: o
total revisions: 27;selected revisions: 27
description:
Is this enough information?
/carsten
jelly-tags/swing can not build
--
Key: JELLY-168
URL: http://nagoya.apache.org/jira/browse/JELLY-168
Project: jelly
Type: Bug
Components: taglib.swing
Versions: 1.0-beta-4
Environment: Linux 2.6.8-1.521
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-b64)
Reporter: carsten madsen
Priority: Minor
When trying to build jelly-tags/swing I get the following error. Seems like
the jelly test stuff is not in the jar file?
[EMAIL PROTECTED] swing]$ maven
__ __
| \/ |__ _Apache__ ___
| |\/| / _` \ V / -_) ' \ ~ intelligent projects ~
|_| |_\__,_|\_/\___|_||_| v. 1.0.1
Attempting to download commons-jelly-SNAPSHOT.jar.
build:start:
java:prepare-filesystem:
java:compile:
[echo] Compiling to
/opt/jakarta-commons/jelly/jelly-tags/swing/target/classes
java:jar-resources:
test:prepare-filesystem:
test:test-resources:
test:compile:
[javac] Compiling 5 source files to
/opt/jakarta-commons/jelly/jelly-tags/swing/target/test-classes
/opt/jakarta-commons/jelly/jelly-tags/swing/src/test/org/apache/commons/jelly/swing/TestSwingTags.java:39:
package org.apache.commons.jelly.test does not exist
import org.apache.commons.jelly.test.BaseJellyTest;
^
/opt/jakarta-commons/jelly/jelly-tags/swing/src/test/org/apache/commons/jelly/swing/TestSwingTags.java:45:
cannot find symbol
symbol: class BaseJellyTest
public class TestSwingTags extends BaseJellyTest {
^
/opt/jakarta-commons/jelly/jelly-tags/swing/src/test/org/apache/commons/jelly/swing/TestSwingTags.java:65:
cannot find symbol
symbol : method getJellyContext()
location: class org.apache.commons.jelly.swing.TestSwingTags
JellyContext context = getJellyContext();
^
/opt/jakarta-commons/jelly/jelly-tags/swing/src/test/org/apache/commons/jelly/swing/TestSwingTags.java:67:
cannot find symbol
symbol : method assertEquals(java.awt.Dimension,java.awt.Dimension)
location: class org.apache.commons.jelly.swing.TestSwingTags
assertEquals(new Dimension(100,100), frame.getSize());
^
/opt/jakarta-commons/jelly/jelly-tags/swing/src/test/org/apache/commons/jelly/swing/TestSwingTags.java:68:
cannot find symbol
symbol : method assertEquals(java.awt.Point,java.awt.Point)
location: class org.apache.commons.jelly.swing.TestSwingTags
assertEquals(new Point(200,200), frame.getLocation());
^
/opt/jakarta-commons/jelly/jelly-tags/swing/src/test/org/apache/commons/jelly/swing/TestSwingTags.java:71:
cannot find symbol
symbol : method assertNotNull(javax.swing.JButton)
location: class org.apache.commons.jelly.swing.TestSwingTags
assertNotNull(button);
^
/opt/jakarta-commons/jelly/jelly-tags/swing/src/test/org/apache/commons/jelly/swing/TestSwingTags.java:72:
cannot find symbol
symbol : method assertEquals(java.awt.Color,java.awt.Color)
location: class org.apache.commons.jelly.swing.TestSwingTags
assertEquals(new Color(0x11,0x22,0x33), button.getBackground());
^
/opt/jakarta-commons/jelly/jelly-tags/swing/src/test/org/apache/commons/jelly/swing/TestSwingTags.java:73:
cannot find symbol
symbol : method assertEquals(java.awt.Color,java.awt.Color)
location: class org.apache.commons.jelly.swing.TestSwingTags
assertEquals(new Color(0x44,0x55,0x66), button.getForeground());
^
/opt/jakarta-commons/jelly/jelly-tags/swing/src/test/org/apache/commons/jelly/swing/TestSwingTags.java:74:
cannot find symbol
symbol : method assertEquals(int,int)
location: class org.apache.commons.jelly.swing.TestSwingTags
assertEquals(DebugGraphics.FLASH_OPTION|DebugGraphics.LOG_OPTION,
panel.getDebugGraphicsOptions());
^
/opt/jakarta-commons/jelly/jelly-tags/swing/src/test/org/apache/commons/jelly/swing/TestSwingTags.java:75:
cannot find symbol
symbol : method assertEquals(int,int)
location: class org.apache.commons.jelly.swing.TestSwingTags
assertEquals(DebugGraphics.BUFFERED_OPTION,
button.getDebugGraphicsOptions());
^
[jira] Commented: (JELLY-168) jelly-tags/swing can not build
[
http://nagoya.apache.org/jira/browse/JELLY-168?page=comments#action_55965 ]
Paul Libbrecht commented on JELLY-168:
--
Things are actually quite dark.
http://www.ibiblio.org/commons-jelly/jars/commons-jelly-SNAPSHOT.jar
supposedly the daily snapshot, dates back from Sept 16th... which explains the
compilation errors. Is this GUMP produced ?
So the normal thing should be react as if the repository did not have
commons-jelly, and use maven jar:install-snapshot in the jelly directory.
This seems, however, to fail on JDK 1.5. But works with JDK 1.4 (both tested on
Linux, also works on MacOSX JDK 1.4).
The same test-error (TestXXXTags) happens to fail in Jelly-Swing in JDK 1.5 and
succeeds in JDK 1.4 (once the snapshot is installed).
Carsten, you're left to install a 1.4, sorry.
And I'll decompose this bug.
paul
jelly-tags/swing can not build
--
Key: JELLY-168
URL: http://nagoya.apache.org/jira/browse/JELLY-168
Project: jelly
Type: Bug
Components: taglib.swing
Versions: 1.0-beta-4
Environment: Linux 2.6.8-1.521
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-b64)
Reporter: carsten madsen
Priority: Minor
When trying to build jelly-tags/swing I get the following error. Seems like
the jelly test stuff is not in the jar file?
[EMAIL PROTECTED] swing]$ maven
__ __
| \/ |__ _Apache__ ___
| |\/| / _` \ V / -_) ' \ ~ intelligent projects ~
|_| |_\__,_|\_/\___|_||_| v. 1.0.1
Attempting to download commons-jelly-SNAPSHOT.jar.
build:start:
java:prepare-filesystem:
java:compile:
[echo] Compiling to
/opt/jakarta-commons/jelly/jelly-tags/swing/target/classes
java:jar-resources:
test:prepare-filesystem:
test:test-resources:
test:compile:
[javac] Compiling 5 source files to
/opt/jakarta-commons/jelly/jelly-tags/swing/target/test-classes
/opt/jakarta-commons/jelly/jelly-tags/swing/src/test/org/apache/commons/jelly/swing/TestSwingTags.java:39:
package org.apache.commons.jelly.test does not exist
import org.apache.commons.jelly.test.BaseJellyTest;
^
/opt/jakarta-commons/jelly/jelly-tags/swing/src/test/org/apache/commons/jelly/swing/TestSwingTags.java:45:
cannot find symbol
symbol: class BaseJellyTest
public class TestSwingTags extends BaseJellyTest {
^
/opt/jakarta-commons/jelly/jelly-tags/swing/src/test/org/apache/commons/jelly/swing/TestSwingTags.java:65:
cannot find symbol
symbol : method getJellyContext()
location: class org.apache.commons.jelly.swing.TestSwingTags
JellyContext context = getJellyContext();
^
/opt/jakarta-commons/jelly/jelly-tags/swing/src/test/org/apache/commons/jelly/swing/TestSwingTags.java:67:
cannot find symbol
symbol : method assertEquals(java.awt.Dimension,java.awt.Dimension)
location: class org.apache.commons.jelly.swing.TestSwingTags
assertEquals(new Dimension(100,100), frame.getSize());
^
/opt/jakarta-commons/jelly/jelly-tags/swing/src/test/org/apache/commons/jelly/swing/TestSwingTags.java:68:
cannot find symbol
symbol : method assertEquals(java.awt.Point,java.awt.Point)
location: class org.apache.commons.jelly.swing.TestSwingTags
assertEquals(new Point(200,200), frame.getLocation());
^
/opt/jakarta-commons/jelly/jelly-tags/swing/src/test/org/apache/commons/jelly/swing/TestSwingTags.java:71:
cannot find symbol
symbol : method assertNotNull(javax.swing.JButton)
location: class org.apache.commons.jelly.swing.TestSwingTags
assertNotNull(button);
^
/opt/jakarta-commons/jelly/jelly-tags/swing/src/test/org/apache/commons/jelly/swing/TestSwingTags.java:72:
cannot find symbol
symbol : method assertEquals(java.awt.Color,java.awt.Color)
location: class org.apache.commons.jelly.swing.TestSwingTags
assertEquals(new Color(0x11,0x22,0x33), button.getBackground());
^
/opt/jakarta-commons/jelly/jelly-tags/swing/src/test/org/apache/commons/jelly/swing/TestSwingTags.java:73:
cannot find symbol
symbol : method assertEquals(java.awt.Color,java.awt.Color)
location: class org.apache.commons.jelly.swing.TestSwingTags
assertEquals(new Color(0x44,0x55,0x66), button.getForeground());
^
/opt/jakarta-commons/jelly/jelly-tags/swing/src/test/org/apache/commons/jelly/swing/TestSwingTags.java:74:
cannot find symbol
symbol : method assertEquals(int,int)
location: class org.apache.commons.jelly.swing.TestSwingTags
assertEquals(DebugGraphics.FLASH_OPTION|DebugGraphics.LOG_OPTION,
panel.getDebugGraphicsOptions());
^
/opt/jakarta-commons/jelly/jelly-tags/swing/src/test/org/apache/commons/jelly/swing/TestSwingTags.java:75:
cannot find symbol
symbol : method assertEquals(int,int)
location: class org.apache.commons.jelly.swing.TestSwingTags
RE: Cleanup questions from importing email
Craig, Joe Germuska (details below) was a sandbox committer for email: developer nameJoe Germuska/name idgermuska/id email[EMAIL PROTECTED]/email /developer Eric Pugh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (JELLY-169) Testing fails in JDK 1.5
Testing fails in JDK 1.5 Key: JELLY-169 URL: http://nagoya.apache.org/jira/browse/JELLY-169 Project: jelly Type: Bug Components: core / taglib.core Versions: 1.0-beta-4 Reporter: Paul Libbrecht Currently, running maven jar fails in both jelly and jelly-swing with JDK 1.5. The TestXXXtags fail. paul -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://nagoya.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JELLY-169) Testing fails in JDK 1.5
[ http://nagoya.apache.org/jira/browse/JELLY-169?page=comments#action_55966 ] Paul Libbrecht commented on JELLY-169: -- Tuning up (and sorry for the pollution): - building with JDK 1.5 is now working with Swing... I had forgotten the DISPLAY variable ! (which is needed for Swing tests, sorry for that, we can't, otherwise, instantiate almost any awt or Swing component). - building with JDK 1.5 is still not working with Jelly-core. And the message are: Attempt to use a script that has been garbage collected. org.apache.commons.jelly.JellyTagException paul Testing fails in JDK 1.5 Key: JELLY-169 URL: http://nagoya.apache.org/jira/browse/JELLY-169 Project: jelly Type: Bug Components: core / taglib.core Versions: 1.0-beta-4 Reporter: Paul Libbrecht Currently, running maven jar fails in both jelly and jelly-swing with JDK 1.5. The TestXXXtags fail. paul -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://nagoya.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JELLY-168) jelly-tags/swing can not build
[
http://nagoya.apache.org/jira/browse/JELLY-168?page=comments#action_55967 ]
Paul Libbrecht commented on JELLY-168:
--
Sorry, I was too quick with my tests... I can run maven jar in jdk 1.5 once
the install-snapshot is done... I just had to have the DISPLAY variable
defined, which I didn't have.
paul
jelly-tags/swing can not build
--
Key: JELLY-168
URL: http://nagoya.apache.org/jira/browse/JELLY-168
Project: jelly
Type: Bug
Components: taglib.swing
Versions: 1.0-beta-4
Environment: Linux 2.6.8-1.521
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-b64)
Reporter: carsten madsen
Priority: Minor
When trying to build jelly-tags/swing I get the following error. Seems like
the jelly test stuff is not in the jar file?
[EMAIL PROTECTED] swing]$ maven
__ __
| \/ |__ _Apache__ ___
| |\/| / _` \ V / -_) ' \ ~ intelligent projects ~
|_| |_\__,_|\_/\___|_||_| v. 1.0.1
Attempting to download commons-jelly-SNAPSHOT.jar.
build:start:
java:prepare-filesystem:
java:compile:
[echo] Compiling to
/opt/jakarta-commons/jelly/jelly-tags/swing/target/classes
java:jar-resources:
test:prepare-filesystem:
test:test-resources:
test:compile:
[javac] Compiling 5 source files to
/opt/jakarta-commons/jelly/jelly-tags/swing/target/test-classes
/opt/jakarta-commons/jelly/jelly-tags/swing/src/test/org/apache/commons/jelly/swing/TestSwingTags.java:39:
package org.apache.commons.jelly.test does not exist
import org.apache.commons.jelly.test.BaseJellyTest;
^
/opt/jakarta-commons/jelly/jelly-tags/swing/src/test/org/apache/commons/jelly/swing/TestSwingTags.java:45:
cannot find symbol
symbol: class BaseJellyTest
public class TestSwingTags extends BaseJellyTest {
^
/opt/jakarta-commons/jelly/jelly-tags/swing/src/test/org/apache/commons/jelly/swing/TestSwingTags.java:65:
cannot find symbol
symbol : method getJellyContext()
location: class org.apache.commons.jelly.swing.TestSwingTags
JellyContext context = getJellyContext();
^
/opt/jakarta-commons/jelly/jelly-tags/swing/src/test/org/apache/commons/jelly/swing/TestSwingTags.java:67:
cannot find symbol
symbol : method assertEquals(java.awt.Dimension,java.awt.Dimension)
location: class org.apache.commons.jelly.swing.TestSwingTags
assertEquals(new Dimension(100,100), frame.getSize());
^
/opt/jakarta-commons/jelly/jelly-tags/swing/src/test/org/apache/commons/jelly/swing/TestSwingTags.java:68:
cannot find symbol
symbol : method assertEquals(java.awt.Point,java.awt.Point)
location: class org.apache.commons.jelly.swing.TestSwingTags
assertEquals(new Point(200,200), frame.getLocation());
^
/opt/jakarta-commons/jelly/jelly-tags/swing/src/test/org/apache/commons/jelly/swing/TestSwingTags.java:71:
cannot find symbol
symbol : method assertNotNull(javax.swing.JButton)
location: class org.apache.commons.jelly.swing.TestSwingTags
assertNotNull(button);
^
/opt/jakarta-commons/jelly/jelly-tags/swing/src/test/org/apache/commons/jelly/swing/TestSwingTags.java:72:
cannot find symbol
symbol : method assertEquals(java.awt.Color,java.awt.Color)
location: class org.apache.commons.jelly.swing.TestSwingTags
assertEquals(new Color(0x11,0x22,0x33), button.getBackground());
^
/opt/jakarta-commons/jelly/jelly-tags/swing/src/test/org/apache/commons/jelly/swing/TestSwingTags.java:73:
cannot find symbol
symbol : method assertEquals(java.awt.Color,java.awt.Color)
location: class org.apache.commons.jelly.swing.TestSwingTags
assertEquals(new Color(0x44,0x55,0x66), button.getForeground());
^
/opt/jakarta-commons/jelly/jelly-tags/swing/src/test/org/apache/commons/jelly/swing/TestSwingTags.java:74:
cannot find symbol
symbol : method assertEquals(int,int)
location: class org.apache.commons.jelly.swing.TestSwingTags
assertEquals(DebugGraphics.FLASH_OPTION|DebugGraphics.LOG_OPTION,
panel.getDebugGraphicsOptions());
^
/opt/jakarta-commons/jelly/jelly-tags/swing/src/test/org/apache/commons/jelly/swing/TestSwingTags.java:75:
cannot find symbol
symbol : method assertEquals(int,int)
location: class org.apache.commons.jelly.swing.TestSwingTags
assertEquals(DebugGraphics.BUFFERED_OPTION,
button.getDebugGraphicsOptions());
^
/opt/jakarta-commons/jelly/jelly-tags/swing/src/test/org/apache/commons/jelly/swing/TestSwingTags.java:85:
cannot find symbol
symbol : method getJellyContext()
location: class org.apache.commons.jelly.swing.TestSwingTags
JellyContext context = getJellyContext();
^
/opt/jakarta-commons/jelly/jelly-tags/swing/src/test/org/apache/commons/jelly/swing/TestSwingTags.java:93:
cannot find symbol
symbol
Re: [transaction] improved logging interface.
Ok, this would do it too. The other way would it make nicer, but you are right it is not required absolutly. (One advantage would be that the parametrized version coulkd use a more efficient type of string processing) Than we should do the isXXXEnabled tests propertly. Because the most logging is fine, finer or finest and we sould avoid this in an working environment. I'll do this next time. Regards, Stefan Oliver Zeigermann wrote: I thought the standard way to handle this is to guard the log statements with checks if the log level is enabled like: if (isFineEnabled()) logFine(anyObject1 + any string + anyObject2); which already is possible with LoggerFacade. This would make the extension obsolete... Oliver On Thu, 25 Nov 2004 14:19:13 +0100, Stefan Lützkendorf [EMAIL PROTECTED] wrote: Hello Oliver, I would like to improve the LoggerFacade interface with methods like, logFiner(String message, Object param1); logFiner(String message, Object param1, Object param2); logFine(String message, Object param1); ... to avoid the frequently used calls like logFine(anyObject1 + any string + anyObject2); This would reduce the overhead if logging is disabled. Changing the interfaces before the first release would be good, I think. What do you think? Regards, Stefan -- Stefan Lützkendorf -- [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] -- Stefan Lützkendorf -- [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 32260] - [email] byte array attachments
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32260. 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=32260 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |ASSIGNED --- Additional Comments From [EMAIL PROTECTED] 2004-11-29 10:42 --- I have applied back the ByteArrayDataSource.. However, I thought about the convenicenc method and on MultiPartEmail and decided against it. I realized that over time we may have multiple *DataSource, so we really should have the user convert the object (in this case byte[]) to the datasource, and just hand that in, otherwise we pollute the api with lots of conveniece methods. I can't seem to commit right now, but I will. If you can come up with a unit test, that would be cool too. -- 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 32410] - [email] tests fail on Unix c/o port settings
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32410. 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=32410 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |ASSIGNED --- Additional Comments From [EMAIL PROTECTED] 2004-11-29 10:48 --- Okay, I've applied this patch. When CVS is working I'll commit it. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[transaction][resources] Gump Build Fixed
Hi guys, I move the gump project file from jakarta-commons-sandbox.xml to jakarta-commons.xml. You should be notified of a success/failure later today. Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/email/src/test/org/apache/commons/mail/settings EmailConfiguration.java
epugh 2004/11/29 01:58:33 Modified:email/src/test/org/apache/commons/mail/settings EmailConfiguration.java Log: Revision ChangesPath 1.2 +2 -2 jakarta-commons/email/src/test/org/apache/commons/mail/settings/EmailConfiguration.java Index: EmailConfiguration.java === RCS file: /home/cvs/jakarta-commons/email/src/test/org/apache/commons/mail/settings/EmailConfiguration.java,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- EmailConfiguration.java 25 Nov 2004 11:14:53 - 1.1 +++ EmailConfiguration.java 29 Nov 2004 09:58:33 - 1.2 @@ -24,7 +24,7 @@ /** */ public static final String MAIL_SERVER = localhost; /** */ -public static final int MAIL_SERVER_PORT = 25; +public static final int MAIL_SERVER_PORT = 2500; /** */ public static final String TEST_FROM = [EMAIL PROTECTED]; /** */ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/email/xdocs changes.xml
epugh 2004/11/29 01:59:12 Modified:email/src/test/org/apache/commons/mail HtmlEmailTest.java SendWithAttachmentsTest.java MultiPartEmailTest.java SimpleEmailTest.java emailproject.properties email/xdocs changes.xml Added: email/src/java/org/apache/commons/mail ByteArrayDataSource.java Log: BugZilla submitted fixes. Revision ChangesPath 1.2 +5 -1 jakarta-commons/email/src/test/org/apache/commons/mail/HtmlEmailTest.java Index: HtmlEmailTest.java === RCS file: /home/cvs/jakarta-commons/email/src/test/org/apache/commons/mail/HtmlEmailTest.java,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- HtmlEmailTest.java25 Nov 2004 11:14:53 - 1.1 +++ HtmlEmailTest.java29 Nov 2004 09:59:11 - 1.2 @@ -254,6 +254,7 @@ this.email = new MockHtmlEmailConcrete(); this.email.setHostName(this.strTestMailServer); +this.email.setSmtpPort(this.intTestMailServerPort); this.email.setFrom(this.strTestMailFrom); this.email.addTo(this.strTestMailTo); @@ -335,6 +336,7 @@ this.email = new MockHtmlEmailConcrete(); this.email.setHostName(this.strTestMailServer); +this.email.setSmtpPort(this.intTestMailServerPort); this.email.setFrom(this.strTestMailFrom); this.email.addTo(this.strTestMailTo); @@ -386,6 +388,7 @@ this.email = new MockHtmlEmailConcrete(); this.email.setHostName(this.strTestMailServer); +this.email.setSmtpPort(this.intTestMailServerPort); this.email.setFrom(this.strTestMailFrom); this.email.addTo(this.strTestMailTo); @@ -441,6 +444,7 @@ this.email = new MockHtmlEmailConcrete(); this.email.setHostName(this.strTestMailServer); this.email.setFrom(this.strTestMailFrom); +this.email.setSmtpPort(this.intTestMailServerPort); this.email.addTo(this.strTestMailTo); if (this.strTestUser != null this.strTestPasswd != null) 1.2 +3 -1 jakarta-commons/email/src/test/org/apache/commons/mail/SendWithAttachmentsTest.java Index: SendWithAttachmentsTest.java === RCS file: /home/cvs/jakarta-commons/email/src/test/org/apache/commons/mail/SendWithAttachmentsTest.java,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- SendWithAttachmentsTest.java 25 Nov 2004 11:14:53 - 1.1 +++ SendWithAttachmentsTest.java 29 Nov 2004 09:59:11 - 1.2 @@ -64,6 +64,7 @@ this.email = new MockHtmlEmailConcrete(); this.email.setHostName(this.strTestMailServer); +this.email.setSmtpPort(this.intTestMailServerPort); this.email.setFrom(this.strTestMailFrom); this.email.addTo(this.strTestMailTo); @@ -153,6 +154,7 @@ this.email = new MockHtmlEmailConcrete(); this.email.setHostName(this.strTestMailServer); + this.email.setSmtpPort(this.intTestMailServerPort); this.email.setFrom(this.strTestMailFrom); this.email.addTo(this.strTestMailTo); 1.2 +2 -1 jakarta-commons/email/src/test/org/apache/commons/mail/MultiPartEmailTest.java Index: MultiPartEmailTest.java === RCS file: /home/cvs/jakarta-commons/email/src/test/org/apache/commons/mail/MultiPartEmailTest.java,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- MultiPartEmailTest.java 25 Nov 2004 11:14:53 - 1.1 +++ MultiPartEmailTest.java 29 Nov 2004 09:59:11 - 1.2 @@ -148,6 +148,7 @@ MockMultiPartEmailConcrete testEmail = new MockMultiPartEmailConcrete(); testEmail.setHostName(this.strTestMailServer); +testEmail.setSmtpPort(this.intTestMailServerPort); testEmail.setFrom(this.strTestMailFrom); testEmail.addTo(this.strTestMailTo); testEmail.attach(attachment); 1.2 +2 -1 jakarta-commons/email/src/test/org/apache/commons/mail/SimpleEmailTest.java Index: SimpleEmailTest.java === RCS file: /home/cvs/jakarta-commons/email/src/test/org/apache/commons/mail/SimpleEmailTest.java,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- SimpleEmailTest.java 25 Nov 2004
RE: [email] Exceptions
My take on this is that users of [email] are looking for a package that simplifies the JavaMail api. And one of the big simplifing aspects is that the Exceptions that they have to catch are minimized. Most users will probably not care *what* the exception was, only that there *was* an exception, and just pass it up the chain. For folks who actually have code to deal with the specific exception, then they are either going to use the JavaMail api directly without the extra layer of [email], or we should provide a way for them to retrieve the specific Exception. Hence that is why I propose that we have two types of exceptions: EmailException and RuntimeEmailException. For common exceptions, we throw an EmailException which is an extension of NestableException and wraps whatever the underlying JavaMail exception was. This provides a nice facade for people who don't care what the exception was, but allows folks who do to get the underlying exception. The other RuntimeEmailException will extend NestableRuntimeException and can be used for any runtime exceptions in the same manner as EmailException. For the case of the UEE, that would be another exception in the API to throw, which goes against the charter that: contains a set of Java classes providing a thin convenience layer over JavaMail. So, in that case, throw the approapriate EmailException and that will wrap the UEE. Mark, is it possible to use the 1.4 io stuff conditionally? I guess not, but we could think about maybe how we compile the jar? Our primary target is definitly 1.3 for now though. Eric -Original Message- From: Mark Lowe [mailto:[EMAIL PROTECTED] Sent: Sunday, November 28, 2004 4:04 PM To: Commons dev list; Corey Scott Subject: [email] Exceptions The issue of exceptions has come up a few times, and heres a summary of my understanding of whats been said and agreed and disagreed about. The idea of throwing AddressException is favourable, but not at the cost of needing to throw UnsupportingEncodingException. When setting InternetAddress() this throws a UEE and AddressException. My position is that without 1.4's new io package there's no means of checking supported charsets on a given JVM. If the user enters a shady charset for a email address or name is there anything wrong with them having a UEE thrown? The lightest means of doing this in my opinion is just throw both, its consistent with the mailapi. It would work on all target JVMs. Of course you could just throw MessagingException for everything , oh thats what it does. But is this a useful and therefore good thing? Having a commons.mail.EmailException was suggested, but does that have any advantage over throwing AddressException and UEE? I'm not sure. I don't mind summitting the patches, i need to do this for a project I'm working on at present, so I need to do the work anyway. It makes sense to submit this to the effort but I don't mind either way. Mark - 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]
[GUMP@brutus]: Project commons-resources (in module jakarta-commons-sandbox) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-resources has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 10 runs. The current state of this project is 'Failed', with reason 'Pre-Build Failed'. For reference only, the following projects are affected by this: - commons-resources : Commons resources Full details are available at: http://brutus.apache.org/gump/public/jakarta-commons-sandbox/commons-resources/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-resources-29112004.jar] identifier set to project name -INFO- Failed with reason pre-build failed -INFO- Failed to extract fallback artifacts from Gump Repository To subscribe to this information via syndicated feeds: - RSS: http://brutus.apache.org/gump/public/jakarta-commons-sandbox/commons-resources/rss.xml - Atom: http://brutus.apache.org/gump/public/jakarta-commons-sandbox/commons-resources/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 3029112004, brutus:brutus-public:3029112004 Gump E-mail Identifier (unique within run) #9. -- Apache Gump http://gump.apache.org/ [Instance: brutus] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[GUMP@brutus]: Project commons-jelly-tags-ant (in module jelly-tags) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-jelly-tags-ant has an issue affecting its community integration. This issue affects 4 projects, and has been outstanding for 54 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-ant : This is a Jelly interface for Ant. - commons-jelly-tags-fmt : This is a set of Jelly i18n tags. - commons-jelly-tags-jsl : The Jelly Stylesheet Library (JSL) - maven : Project Management Tools Full details are available at: http://brutus.apache.org/gump/public/jelly-tags/commons-jelly-tags-ant/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-jelly-tags-ant-29112004.jar] identifier set to project name -INFO- Failed with reason build failed -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://brutus.apache.org/gump/public/jelly-tags/commons-jelly-tags-ant/gump_work/build_jelly-tags_commons-jelly-tags-ant.html Work Name: build_jelly-tags_commons-jelly-tags-ant (Type: Build) Work ended in a state of : Failed Elapsed: 7 secs Command Line: java -Djava.awt.headless=true -Dbuild.clonevm=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar org.apache.tools.ant.Main -Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dfinal.name=commons-jelly-tags-ant-29112004 jar [Working Directory: /usr/local/gump/public/workspace/jelly-tags/ant] CLASSPATH: /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/jelly-tags/ant/target/classes:/usr/local/gump/public/workspace/jelly-tags/ant/target/test-classes:/usr/local/gump/public/workspace/jakarta-commons/jelly/target/commons-jelly-29112004.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-stylebook.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-29112004.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-29112004.jar:/usr/local/gump/public/workspace/jakarta-commons/lang/dist/commons-lang-29112004.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar:/usr/local/gump/packages/dom4j-1.4/dom4j-full.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-29112004.jar:/usr/local/gump/public/workspace/jakarta-commons/discovery/dist/commons-discovery.jar:/usr/local/gump/public/workspace/jakarta-servletapi-5/jsr154/dist/lib/servlet-api.jar:/usr/local/gump/public/workspace/jakarta-servletapi-5/jsr152/dist/lib/jsp-api.jar:/usr/local/gump/public/workspace/jakarta-taglibs/dist/standard/lib/standard.jar:/usr/local/gump/public/workspace/jakarta-taglibs/dist/standard/lib/jstl.jar:/usr/local/gump/packages/nekohtml-0.9.3/nekohtmlXni.jar:/usr/local/gump/packages/nekohtml-0.9.3/nekohtml.jar:/usr/local/gump/public/workspace/commons-grant/target/commons-grant-29112004.jar:/usr/local/gump/public/workspace/jelly-tags/util/target/commons-jelly-tags-util-29112004.jar:/usr/local/gump/public/workspace/jelly-tags/junit/target/commons-jelly-tags-junit-29112004.jar - [junit] Testcase: readWriteIn took 0.229 sec [junit] Testcase: startUpReadWrite took 0.148 sec [junit] Testcase: copy took 0.149 sec [junit] Caused an ERROR [junit] file:/home/gump/workspaces2/public/workspace/jelly-tags/ant/target/test-classes/org/apache/commons/jelly/ant/suite.jelly:114:80: util:loadText charsetName [junit] org.apache.commons.jelly.JellyTagException: file:/home/gump/workspaces2/public/workspace/jelly-tags/ant/target/test-classes/org/apache/commons/jelly/ant/suite.jelly:114:80: util:loadText charsetName [junit] at org.apache.commons.jelly.impl.TagScript.handleException(TagScript.java:680) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:263) [junit] at
Re: [email] Exceptions
Okay 2 commons.mail exceptions sounds like an improvement. So the goal is to minimise the catch statements the user needs to use, sound reasonable. Throwing everything would mean 2 catches, so I can see the value in catching once. I'll look into a way of having a 1.4+ build option in the build files for folk that don't give a gnat's winnit about 1.3 et al. Anyone know the default behaviour for the InternetAddress(email,name) constructor? Does it adopt the charset from the parent email? Mark On Mon, 29 Nov 2004 11:11:06 +0100, Eric Pugh [EMAIL PROTECTED] wrote: My take on this is that users of [email] are looking for a package that simplifies the JavaMail api. And one of the big simplifing aspects is that the Exceptions that they have to catch are minimized. Most users will probably not care *what* the exception was, only that there *was* an exception, and just pass it up the chain. For folks who actually have code to deal with the specific exception, then they are either going to use the JavaMail api directly without the extra layer of [email], or we should provide a way for them to retrieve the specific Exception. Hence that is why I propose that we have two types of exceptions: EmailException and RuntimeEmailException. For common exceptions, we throw an EmailException which is an extension of NestableException and wraps whatever the underlying JavaMail exception was. This provides a nice facade for people who don't care what the exception was, but allows folks who do to get the underlying exception. The other RuntimeEmailException will extend NestableRuntimeException and can be used for any runtime exceptions in the same manner as EmailException. For the case of the UEE, that would be another exception in the API to throw, which goes against the charter that: contains a set of Java classes providing a thin convenience layer over JavaMail. So, in that case, throw the approapriate EmailException and that will wrap the UEE. Mark, is it possible to use the 1.4 io stuff conditionally? I guess not, but we could think about maybe how we compile the jar? Our primary target is definitly 1.3 for now though. Eric -Original Message- From: Mark Lowe [mailto:[EMAIL PROTECTED] Sent: Sunday, November 28, 2004 4:04 PM To: Commons dev list; Corey Scott Subject: [email] Exceptions The issue of exceptions has come up a few times, and heres a summary of my understanding of whats been said and agreed and disagreed about. The idea of throwing AddressException is favourable, but not at the cost of needing to throw UnsupportingEncodingException. When setting InternetAddress() this throws a UEE and AddressException. My position is that without 1.4's new io package there's no means of checking supported charsets on a given JVM. If the user enters a shady charset for a email address or name is there anything wrong with them having a UEE thrown? The lightest means of doing this in my opinion is just throw both, its consistent with the mailapi. It would work on all target JVMs. Of course you could just throw MessagingException for everything , oh thats what it does. But is this a useful and therefore good thing? Having a commons.mail.EmailException was suggested, but does that have any advantage over throwing AddressException and UEE? I'm not sure. I don't mind summitting the patches, i need to do this for a project I'm working on at present, so I need to do the work anyway. It makes sense to submit this to the effort but I don't mind either way. Mark - 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: [transaction] improved logging interface.
On Mon, 29 Nov 2004 10:42:08 +0100, Stefan Lützkendorf [EMAIL PROTECTED] wrote: Ok, this would do it too. The other way would it make nicer, but you are right it is not required absolutly. (One advantage would be that the parametrized version coulkd use a more efficient type of string processing) If we are logging finest performance wouldn't be our major goal and if we are not the string concatenation wouldn't be done in the first place. So IMHO there is little need for a parameterized version, is there? Than we should do the isXXXEnabled tests propertly. Because the most logging is fine, finer or finest and we sould avoid this in an working environment. Agreed! Oliver I'll do this next time. Regards, Stefan Oliver Zeigermann wrote: I thought the standard way to handle this is to guard the log statements with checks if the log level is enabled like: if (isFineEnabled()) logFine(anyObject1 + any string + anyObject2); which already is possible with LoggerFacade. This would make the extension obsolete... Oliver On Thu, 25 Nov 2004 14:19:13 +0100, Stefan Lützkendorf [EMAIL PROTECTED] wrote: Hello Oliver, I would like to improve the LoggerFacade interface with methods like, logFiner(String message, Object param1); logFiner(String message, Object param1, Object param2); logFine(String message, Object param1); ... to avoid the frequently used calls like logFine(anyObject1 + any string + anyObject2); This would reduce the overhead if logging is disabled. Changing the interfaces before the first release would be good, I think. What do you think? Regards, Stefan -- Stefan Lützkendorf -- [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] -- Stefan Lützkendorf -- [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: [transaction][resources] Gump Build Fixed
Great, thanks! Oliver On Mon, 29 Nov 2004 10:54:01 +0100, Eric Pugh [EMAIL PROTECTED] wrote: Hi guys, I move the gump project file from jakarta-commons-sandbox.xml to jakarta-commons.xml. You should be notified of a success/failure later today. Eric - 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: [email] Exceptions
I've created the exceptions and I'm now working through the test cases. If I summit a patch with the exception testing in a ExceptionTestCase what's the likelyhood of this being patched? This isn't a question of style its a question of maintainabilty and now, I'm faced with the task of weeding out all these try catch statements. Any objection to a patch with these exception tests moved into a specialised test case? Mark On Mon, 29 Nov 2004 11:23:50 +0100, Mark Lowe [EMAIL PROTECTED] wrote: Okay 2 commons.mail exceptions sounds like an improvement. So the goal is to minimise the catch statements the user needs to use, sound reasonable. Throwing everything would mean 2 catches, so I can see the value in catching once. I'll look into a way of having a 1.4+ build option in the build files for folk that don't give a gnat's winnit about 1.3 et al. Anyone know the default behaviour for the InternetAddress(email,name) constructor? Does it adopt the charset from the parent email? Mark On Mon, 29 Nov 2004 11:11:06 +0100, Eric Pugh [EMAIL PROTECTED] wrote: My take on this is that users of [email] are looking for a package that simplifies the JavaMail api. And one of the big simplifing aspects is that the Exceptions that they have to catch are minimized. Most users will probably not care *what* the exception was, only that there *was* an exception, and just pass it up the chain. For folks who actually have code to deal with the specific exception, then they are either going to use the JavaMail api directly without the extra layer of [email], or we should provide a way for them to retrieve the specific Exception. Hence that is why I propose that we have two types of exceptions: EmailException and RuntimeEmailException. For common exceptions, we throw an EmailException which is an extension of NestableException and wraps whatever the underlying JavaMail exception was. This provides a nice facade for people who don't care what the exception was, but allows folks who do to get the underlying exception. The other RuntimeEmailException will extend NestableRuntimeException and can be used for any runtime exceptions in the same manner as EmailException. For the case of the UEE, that would be another exception in the API to throw, which goes against the charter that: contains a set of Java classes providing a thin convenience layer over JavaMail. So, in that case, throw the approapriate EmailException and that will wrap the UEE. Mark, is it possible to use the 1.4 io stuff conditionally? I guess not, but we could think about maybe how we compile the jar? Our primary target is definitly 1.3 for now though. Eric -Original Message- From: Mark Lowe [mailto:[EMAIL PROTECTED] Sent: Sunday, November 28, 2004 4:04 PM To: Commons dev list; Corey Scott Subject: [email] Exceptions The issue of exceptions has come up a few times, and heres a summary of my understanding of whats been said and agreed and disagreed about. The idea of throwing AddressException is favourable, but not at the cost of needing to throw UnsupportingEncodingException. When setting InternetAddress() this throws a UEE and AddressException. My position is that without 1.4's new io package there's no means of checking supported charsets on a given JVM. If the user enters a shady charset for a email address or name is there anything wrong with them having a UEE thrown? The lightest means of doing this in my opinion is just throw both, its consistent with the mailapi. It would work on all target JVMs. Of course you could just throw MessagingException for everything , oh thats what it does. But is this a useful and therefore good thing? Having a commons.mail.EmailException was suggested, but does that have any advantage over throwing AddressException and UEE? I'm not sure. I don't mind summitting the patches, i need to do this for a project I'm working on at present, so I need to do the work anyway. It makes sense to submit this to the effort but I don't mind either way. Mark - 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: SVN repository structure (was Re: Volunteer for SVN migrationmanagement)
Simon Kitching wrote: If each subproject has a 'tags'/'branches' directory, then doesn't it become impossible to check out the latest source of *all* the commons projects without ending up with a copy of every branch of that project ever made? You would check out the trunk for each component. The trunk/tags/branches structure is usually applied to each separately releasable entity. I think the ability to get the latest of commons is important To a minority of people, IMO. Most are interested in the components they want to use. But, hey, SVN supports any of these organizations. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 32094] - [email] All exceptions seem to be thrown as messagingExceptions
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32094. 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=32094 --- Additional Comments From [EMAIL PROTECTED] 2004-11-29 14:59 --- Created an attachment (id=13577) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=13577action=view) [email] EmailException src file. -- 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: [email] Exceptions
I would prefer an Exception Test case per base class, especially for the larger files. I know most of the tests I wrote, but I think that if anything the files are too long and would be much more usable if they were shorter and more focused. Does anyone have any objections to gave more (but shorter) files? -Corey On Mon, 29 Nov 2004 14:17:30 +0100, Mark Lowe [EMAIL PROTECTED] wrote: I've created the exceptions and I'm now working through the test cases. If I summit a patch with the exception testing in a ExceptionTestCase what's the likelyhood of this being patched? This isn't a question of style its a question of maintainabilty and now, I'm faced with the task of weeding out all these try catch statements. Any objection to a patch with these exception tests moved into a specialised test case? Mark On Mon, 29 Nov 2004 11:23:50 +0100, Mark Lowe [EMAIL PROTECTED] wrote: Okay 2 commons.mail exceptions sounds like an improvement. So the goal is to minimise the catch statements the user needs to use, sound reasonable. Throwing everything would mean 2 catches, so I can see the value in catching once. I'll look into a way of having a 1.4+ build option in the build files for folk that don't give a gnat's winnit about 1.3 et al. Anyone know the default behaviour for the InternetAddress(email,name) constructor? Does it adopt the charset from the parent email? Mark On Mon, 29 Nov 2004 11:11:06 +0100, Eric Pugh [EMAIL PROTECTED] wrote: My take on this is that users of [email] are looking for a package that simplifies the JavaMail api. And one of the big simplifing aspects is that the Exceptions that they have to catch are minimized. Most users will probably not care *what* the exception was, only that there *was* an exception, and just pass it up the chain. For folks who actually have code to deal with the specific exception, then they are either going to use the JavaMail api directly without the extra layer of [email], or we should provide a way for them to retrieve the specific Exception. Hence that is why I propose that we have two types of exceptions: EmailException and RuntimeEmailException. For common exceptions, we throw an EmailException which is an extension of NestableException and wraps whatever the underlying JavaMail exception was. This provides a nice facade for people who don't care what the exception was, but allows folks who do to get the underlying exception. The other RuntimeEmailException will extend NestableRuntimeException and can be used for any runtime exceptions in the same manner as EmailException. For the case of the UEE, that would be another exception in the API to throw, which goes against the charter that: contains a set of Java classes providing a thin convenience layer over JavaMail. So, in that case, throw the approapriate EmailException and that will wrap the UEE. Mark, is it possible to use the 1.4 io stuff conditionally? I guess not, but we could think about maybe how we compile the jar? Our primary target is definitly 1.3 for now though. Eric -Original Message- From: Mark Lowe [mailto:[EMAIL PROTECTED] Sent: Sunday, November 28, 2004 4:04 PM To: Commons dev list; Corey Scott Subject: [email] Exceptions The issue of exceptions has come up a few times, and heres a summary of my understanding of whats been said and agreed and disagreed about. The idea of throwing AddressException is favourable, but not at the cost of needing to throw UnsupportingEncodingException. When setting InternetAddress() this throws a UEE and AddressException. My position is that without 1.4's new io package there's no means of checking supported charsets on a given JVM. If the user enters a shady charset for a email address or name is there anything wrong with them having a UEE thrown? The lightest means of doing this in my opinion is just throw both, its consistent with the mailapi. It would work on all target JVMs. Of course you could just throw MessagingException for everything , oh thats what it does. But is this a useful and therefore good thing? Having a commons.mail.EmailException was suggested, but does that have any advantage over throwing AddressException and UEE? I'm not sure. I don't mind summitting the patches, i need to do this for a project I'm working on at present, so I need to do the work anyway. It makes sense to submit this to the effort but I don't mind either way. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 32094] - [email] All exceptions seem to be thrown as messagingExceptions
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32094. 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=32094 --- Additional Comments From [EMAIL PROTECTED] 2004-11-29 15:01 --- Created an attachment (id=13578) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=13578action=view) [email] Email class that throws EmailException. -- 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 32094] - [email] All exceptions seem to be thrown as messagingExceptions
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32094. 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=32094 --- Additional Comments From [EMAIL PROTECTED] 2004-11-29 15:02 --- Created an attachment (id=13579) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=13579action=view) [email] EmailExceptionTest class -- 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 32094] - [email] All exceptions seem to be thrown as messagingExceptions
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32094. 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=32094 --- Additional Comments From [EMAIL PROTECTED] 2004-11-29 15:08 --- Created an attachment (id=13580) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=13580action=view) [email] tests with try catches not to test for MessagingException IMHO having tests that test functionlity should throw exception, and exception test in a specialised test case. Not because this is a matter of style, but because it doesn't create a maintaince nightmare. Adding a new exception to the package shouldn't involve addressing a zillion build errors in the standard test cases. -- 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: Migrate to SVN?
Hi, I feel the same as Senor Colebourne to a large extent. Not -1, but not a +1 either -- a true neutral 0 on this one. When we do move, we need to make sure the relevant documentation for potential contributors, e.g. http://www.apache.org/dev/contributors.html, and all related pages which currently only have CVS information, are updated to include SVN as well. It's a higher barrier of entry unfortunately. Yoav Shapira http://www.yoavshapira.com -Original Message- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] Sent: Friday, November 26, 2004 6:13 PM To: Jakarta Commons Developers List Subject: Re: Migrate to SVN? I remain unenthused by SVN, probably because I don't have to manage a CVS server. Effectively I'm -1, but I'm probably not going to fight. My main reason is that SVN does not appear to be that widely adopted yet. A sign that the time has come to migrate would be when Eclipse/Idea ships with SVN support built in. At the moment, I fear we may just scare off some potential users/contributers. If we are moving though, I would want the pain all at once. Stephen - Original Message - From: Phil Steitz [EMAIL PROTECTED] +1 from me as well -- seems to make sense to move as a group. Phil Alex Karasulu wrote: +1 Noel J. Bergman wrote: 6) should I just delete the /jakarta-commons-sandbox/email directory, or leave the folder and a note pointing to the promotion? What about the website as well? I think for [configuration] we just deleted both. The ideal scenario would be to use cvs delete on all the sandbox files, so that the original history is maintained there, but nobody who checks out the sandbox (with -dP at least) will be bothered by the files. The IDEAL situation would be to convert Jakarta Commons to SVN. Can we PLEASE consider doing so? A lot of projects, including the HTTP Server project, have been migrating, as can be seen from http://svn.apache.org/viewcvs. Jakarta and XML are definitely the laggards now. --- Noel - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [email] Exceptions
My thoughts on the test cases are that they should throw exception,
and then have the exception testing separate. This would make the
cases shorter also, perhaps this is what you mean.
public void testFoo() throws Exception
{
Foo foo = new Foo();
foo.setBar(testvar);
}
For example, if for some reason the exception for setBar() was ever
changed the case could remain the same as before, and the only change
would need to be in the exception test case.
Mark
On Mon, 29 Nov 2004 21:59:44 +0800, Corey Scott [EMAIL PROTECTED] wrote:
I would prefer an Exception Test case per base class, especially for
the larger files. I know most of the tests I wrote, but I think that
if anything the files are too long and would be much more usable if
they were shorter and more focused. Does anyone have any objections
to gave more (but shorter) files?
-Corey
On Mon, 29 Nov 2004 14:17:30 +0100, Mark Lowe [EMAIL PROTECTED] wrote:
I've created the exceptions and I'm now working through the test cases.
If I summit a patch with the exception testing in a ExceptionTestCase
what's the likelyhood of this being patched? This isn't a question of
style its a question of maintainabilty and now, I'm faced with the
task of weeding out all these try catch statements.
Any objection to a patch with these exception tests moved into a
specialised test case?
Mark
On Mon, 29 Nov 2004 11:23:50 +0100, Mark Lowe [EMAIL PROTECTED] wrote:
Okay 2 commons.mail exceptions sounds like an improvement. So the goal
is to minimise the catch statements the user needs to use, sound
reasonable. Throwing everything would mean 2 catches, so I can see the
value in catching once.
I'll look into a way of having a 1.4+ build option in the build files
for folk that don't give a gnat's winnit about 1.3 et al.
Anyone know the default behaviour for the InternetAddress(email,name)
constructor? Does it adopt the charset from the parent email?
Mark
On Mon, 29 Nov 2004 11:11:06 +0100, Eric Pugh [EMAIL PROTECTED] wrote:
My take on this is that users of [email] are looking for a package that
simplifies the JavaMail api. And one of the big simplifing aspects is
that
the Exceptions that they have to catch are minimized. Most users will
probably not care *what* the exception was, only that there *was* an
exception, and just pass it up the chain. For folks who actually have
code
to deal with the specific exception, then they are either going to use
the
JavaMail api directly without the extra layer of [email], or we should
provide a way for them to retrieve the specific Exception.
Hence that is why I propose that we have two types of exceptions:
EmailException and RuntimeEmailException. For common exceptions, we
throw
an EmailException which is an extension of NestableException and wraps
whatever the underlying JavaMail exception was. This provides a nice
facade
for people who don't care what the exception was, but allows folks who
do to
get the underlying exception.
The other RuntimeEmailException will extend NestableRuntimeException
and can
be used for any runtime exceptions in the same manner as EmailException.
For the case of the UEE, that would be another exception in the API to
throw, which goes against the charter that:
contains a set of Java classes providing a thin convenience layer over
JavaMail. So, in that case, throw the approapriate EmailException and
that will wrap the UEE.
Mark, is it possible to use the 1.4 io stuff conditionally? I guess
not,
but we could think about maybe how we compile the jar? Our primary
target
is definitly 1.3 for now though.
Eric
-Original Message-
From: Mark Lowe [mailto:[EMAIL PROTECTED]
Sent: Sunday, November 28, 2004 4:04 PM
To: Commons dev list; Corey Scott
Subject: [email] Exceptions
The issue of exceptions has come up a few times, and heres a summary
of my understanding of whats been said and agreed and disagreed about.
The idea of throwing AddressException is favourable, but not at the
cost of needing to throw UnsupportingEncodingException. When setting
InternetAddress() this throws a UEE and AddressException.
My position is that without 1.4's new io package there's no means of
checking supported charsets on a given JVM. If the user enters a shady
charset for a email address or name is there anything wrong with them
having a UEE thrown?
The lightest means of doing this in my opinion is just throw both, its
consistent with the mailapi. It would work on all target JVMs.
Of course you could just throw MessagingException for everything , oh
thats what it does. But is this a useful and therefore good thing?
Having a
Re: [io] Exact meaning of getPath, esp. on UNIX?
Paulo Gaspar wrote: To complitelly avoid ambiguities, why not calling it getParentPath() instead? Keep it simple... Any file-system object (file or directory) has a name and a path to it. The simple rule is fileNameAndPath := FilenameUtils.getFullPath( fileNameAndPath ) + File.separatorChar + FilenameUtils.getName( fileNameAndPath ) := FilenameUtils.concat( FilenameUtils.getFullPath( fileNameAndPath ), FilenameUtils.getName( fileNameAndPath ) ) Is this agreable by everyone? Why compicate the matters? Notable is that a directory itself is positioned at a path location. Therefore FilenameUtils.getPath(pathToDirectory).length() pathToDirectory.length() Cheers, Christoph Regards, Paulo Gaspar Stephen Colebourne wrote: I think its best to change it. After all calling getPath() returns a path, but calling getPath() on that result doesn't return the same path, but the parent. If I add a getParent() method, that can cover the existing case of this method. And these name manipulations have to be independent of File objects I reckon. Stephen - Original Message - From: matthew.hawthorne [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Saturday, November 27, 2004 7:07 PM Subject: Re: [io] Exact meaning of getPath, esp. on UNIX? Stephen Colebourne wrote: getPath is currently coded so that: /a/b/c.txt -- /a/b this is of course correct. However, it is also coded to do: /a/b/c -- /a/b which seems a little odd (for me with a windows background). ie. the method treats 'c' as a file not a folder. This method seems to behave the same as the 'dirname' command in Unix. It returns the directory containing the item, whether the item is a file or a folder. - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [io] Exact meaning of getPath, esp. on UNIX?
And isn't it always simpler if the name of the method perfectly explains its functionality instead of relying on some convention? (Ok, that is not always possible, but it IS in this case.) Regards, Paulo Christoph Reck wrote: Paulo Gaspar wrote: To complitelly avoid ambiguities, why not calling it getParentPath() instead? Keep it simple... Any file-system object (file or directory) has a name and a path to it. The simple rule is fileNameAndPath := FilenameUtils.getFullPath( fileNameAndPath ) + File.separatorChar + FilenameUtils.getName( fileNameAndPath ) := FilenameUtils.concat( FilenameUtils.getFullPath( fileNameAndPath ), FilenameUtils.getName( fileNameAndPath ) ) Is this agreable by everyone? Why compicate the matters? Notable is that a directory itself is positioned at a path location. Therefore FilenameUtils.getPath(pathToDirectory).length() pathToDirectory.length() Cheers, Christoph Regards, Paulo Gaspar Stephen Colebourne wrote: I think its best to change it. After all calling getPath() returns a path, but calling getPath() on that result doesn't return the same path, but the parent. If I add a getParent() method, that can cover the existing case of this method. And these name manipulations have to be independent of File objects I reckon. Stephen - Original Message - From: matthew.hawthorne [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Saturday, November 27, 2004 7:07 PM Subject: Re: [io] Exact meaning of getPath, esp. on UNIX? Stephen Colebourne wrote: getPath is currently coded so that: /a/b/c.txt -- /a/b this is of course correct. However, it is also coded to do: /a/b/c -- /a/b which seems a little odd (for me with a windows background). ie. the method treats 'c' as a file not a folder. This method seems to behave the same as the 'dirname' command in Unix. It returns the directory containing the item, whether the item is a file or a folder. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [email] Exceptions
Humm... I typically make all my unit tests throw Exception. It reduces
the length of each test, especially when all you are doing is logging that
it failed with a fail(ex.getMessage).
However, if you are actually TESTING that an exception gets thrown:
try {
email.doSomething();
fail(should have thrown ee);
}
catch (EmailException ee){
assertTrue(ee.getMessage().indexOf(myerror)-1)
}
then I argue they should go in with whatever class we are testing, because
when someone adds a new method to the class, it will encourage them to add
the corresponding test case for any exeption. Or, put the exception test
into the test.
public void testSomething() throws Exception{
email.doSomethign();
snip/
try {
email.doSomething();
fail(should have thrown ee);
}
catch (EmailException ee){
assertTrue(ee.getMessage().indexOf(myerror)-1)
}
}
That way everything stays together. If we aren't actually asserting the
exception, then we shouldn't bother testing it..
Eric
-Original Message-
From: Mark Lowe [mailto:[EMAIL PROTECTED]
Sent: Monday, November 29, 2004 3:19 PM
To: Corey Scott
Cc: Jakarta Commons Developers List
Subject: Re: [email] Exceptions
My thoughts on the test cases are that they should throw exception,
and then have the exception testing separate. This would make the
cases shorter also, perhaps this is what you mean.
public void testFoo() throws Exception
{
Foo foo = new Foo();
foo.setBar(testvar);
}
For example, if for some reason the exception for setBar() was ever
changed the case could remain the same as before, and the only change
would need to be in the exception test case.
Mark
On Mon, 29 Nov 2004 21:59:44 +0800, Corey Scott
[EMAIL PROTECTED] wrote:
I would prefer an Exception Test case per base class, especially for
the larger files. I know most of the tests I wrote, but I think that
if anything the files are too long and would be much more usable if
they were shorter and more focused. Does anyone have any objections
to gave more (but shorter) files?
-Corey
On Mon, 29 Nov 2004 14:17:30 +0100, Mark Lowe [EMAIL PROTECTED] wrote:
I've created the exceptions and I'm now working through the
test cases.
If I summit a patch with the exception testing in a ExceptionTestCase
what's the likelyhood of this being patched? This isn't a question of
style its a question of maintainabilty and now, I'm faced with the
task of weeding out all these try catch statements.
Any objection to a patch with these exception tests moved into a
specialised test case?
Mark
On Mon, 29 Nov 2004 11:23:50 +0100, Mark Lowe
[EMAIL PROTECTED] wrote:
Okay 2 commons.mail exceptions sounds like an improvement.
So the goal
is to minimise the catch statements the user needs to use, sound
reasonable. Throwing everything would mean 2 catches, so I
can see the
value in catching once.
I'll look into a way of having a 1.4+ build option in the
build files
for folk that don't give a gnat's winnit about 1.3 et al.
Anyone know the default behaviour for the
InternetAddress(email,name)
constructor? Does it adopt the charset from the parent email?
Mark
On Mon, 29 Nov 2004 11:11:06 +0100, Eric Pugh
[EMAIL PROTECTED] wrote:
My take on this is that users of [email] are looking for
a package that
simplifies the JavaMail api. And one of the big
simplifing aspects is that
the Exceptions that they have to catch are minimized.
Most users will
probably not care *what* the exception was, only that
there *was* an
exception, and just pass it up the chain. For folks who
actually have code
to deal with the specific exception, then they are either
going to use the
JavaMail api directly without the extra layer of [email],
or we should
provide a way for them to retrieve the specific Exception.
Hence that is why I propose that we have two types of exceptions:
EmailException and RuntimeEmailException. For common
exceptions, we throw
an EmailException which is an extension of
NestableException and wraps
whatever the underlying JavaMail exception was. This
provides a nice facade
for people who don't care what the exception was, but
allows folks who do to
get the underlying exception.
The other RuntimeEmailException will extend
NestableRuntimeException and can
be used for any runtime exceptions in the same manner as
EmailException.
For the case of the UEE, that would be another exception
in the API to
throw, which goes against the charter that:
contains a set of Java classes providing a thin
convenience layer over
JavaMail. So, in that case, throw the approapriate
EmailException and
that will wrap the UEE.
Mark, is it possible to use the 1.4 io stuff
conditionally? I guess not,
but we could think about
Re: [email] Exceptions
This is exactly what I was trying to say, just not so elegantly :-)
Eg. Tests for the HtmlEmail class should be in teh HtmlEmailTest class
or is this becomes too big and you want to separate the exceptions,
then there should be two classes HtmlEmailTest (for normal test cases)
and HtmlEmailExceptionTest
-Corey
On Mon, 29 Nov 2004 16:59:29 +0100, Eric Pugh [EMAIL PROTECTED] wrote:
Humm... I typically make all my unit tests throw Exception. It reduces
the length of each test, especially when all you are doing is logging that
it failed with a fail(ex.getMessage).
However, if you are actually TESTING that an exception gets thrown:
try {
email.doSomething();
fail(should have thrown ee);
}
catch (EmailException ee){
assertTrue(ee.getMessage().indexOf(myerror)-1)
}
then I argue they should go in with whatever class we are testing, because
when someone adds a new method to the class, it will encourage them to add
the corresponding test case for any exeption. Or, put the exception test
into the test.
public void testSomething() throws Exception{
email.doSomethign();
snip/
try {
email.doSomething();
fail(should have thrown ee);
}
catch (EmailException ee){
assertTrue(ee.getMessage().indexOf(myerror)-1)
}
}
That way everything stays together. If we aren't actually asserting the
exception, then we shouldn't bother testing it..
Eric
-Original Message-
From: Mark Lowe [mailto:[EMAIL PROTECTED]
Sent: Monday, November 29, 2004 3:19 PM
To: Corey Scott
Cc: Jakarta Commons Developers List
Subject: Re: [email] Exceptions
My thoughts on the test cases are that they should throw exception,
and then have the exception testing separate. This would make the
cases shorter also, perhaps this is what you mean.
public void testFoo() throws Exception
{
Foo foo = new Foo();
foo.setBar(testvar);
}
For example, if for some reason the exception for setBar() was ever
changed the case could remain the same as before, and the only change
would need to be in the exception test case.
Mark
On Mon, 29 Nov 2004 21:59:44 +0800, Corey Scott
[EMAIL PROTECTED] wrote:
I would prefer an Exception Test case per base class, especially for
the larger files. I know most of the tests I wrote, but I think that
if anything the files are too long and would be much more usable if
they were shorter and more focused. Does anyone have any objections
to gave more (but shorter) files?
-Corey
On Mon, 29 Nov 2004 14:17:30 +0100, Mark Lowe [EMAIL PROTECTED] wrote:
I've created the exceptions and I'm now working through the
test cases.
If I summit a patch with the exception testing in a ExceptionTestCase
what's the likelyhood of this being patched? This isn't a question of
style its a question of maintainabilty and now, I'm faced with the
task of weeding out all these try catch statements.
Any objection to a patch with these exception tests moved into a
specialised test case?
Mark
On Mon, 29 Nov 2004 11:23:50 +0100, Mark Lowe
[EMAIL PROTECTED] wrote:
Okay 2 commons.mail exceptions sounds like an improvement.
So the goal
is to minimise the catch statements the user needs to use, sound
reasonable. Throwing everything would mean 2 catches, so I
can see the
value in catching once.
I'll look into a way of having a 1.4+ build option in the
build files
for folk that don't give a gnat's winnit about 1.3 et al.
Anyone know the default behaviour for the
InternetAddress(email,name)
constructor? Does it adopt the charset from the parent email?
Mark
On Mon, 29 Nov 2004 11:11:06 +0100, Eric Pugh
[EMAIL PROTECTED] wrote:
My take on this is that users of [email] are looking for
a package that
simplifies the JavaMail api. And one of the big
simplifing aspects is that
the Exceptions that they have to catch are minimized.
Most users will
probably not care *what* the exception was, only that
there *was* an
exception, and just pass it up the chain. For folks who
actually have code
to deal with the specific exception, then they are either
going to use the
JavaMail api directly without the extra layer of [email],
or we should
provide a way for them to retrieve the specific Exception.
Hence that is why I propose that we have two types of exceptions:
EmailException and RuntimeEmailException. For common
exceptions, we throw
an EmailException which is an extension of
NestableException and wraps
whatever the underlying JavaMail exception was. This
provides a nice facade
for people who don't care what the exception was, but
allows folks who do to
get the underlying exception.
The other RuntimeEmailException will extend
[email] site cleanup
Eric, If you could change the group permissions recursively on the email site so that it can be updated by others that would be great. Afterwards, I'll be glad to run the site generation to cleanup the existing site. [EMAIL PROTECTED]:/www/jakarta.apache.org/commons/email ls -a -l total 390 drwxr-xr-x 8 epugh jakarta 1024 Nov 25 04:21 . drwxrwxr-x 50 mdiggory jakarta 2048 Nov 28 14:32 .. drwxr-xr-x 4 epugh jakarta512 Nov 25 04:18 apidocs -rw-r--r-- 1 epugh jakarta 26249 Nov 25 04:18 changelog-report.html -rw-r--r-- 1 epugh jakarta 16963 Nov 25 04:18 changes-report.html -rw-r--r-- 1 epugh jakarta736 Nov 25 04:18 changes.rss -rw-r--r-- 1 epugh jakarta 47015 Nov 25 04:18 checkstyle-report.html -rw-r--r-- 1 epugh jakarta 2348 Nov 25 04:18 checkstyle.rss -rw-r--r-- 1 epugh jakarta 13128 Nov 25 04:18 cvs-usage.html -rw-r--r-- 1 epugh jakarta 12762 Nov 25 04:18 dependencies.html -rw-r--r-- 1 epugh jakarta 11780 Nov 25 04:18 developer-activity-report.html -rw-r--r-- 1 epugh jakarta 11908 Nov 25 04:18 downloads.html -rw-r--r-- 1 epugh jakarta 20142 Nov 25 04:18 examples.html -rw-r--r-- 1 epugh jakarta 16455 Nov 25 04:18 file-activity-report.html drwxr-xr-x 3 epugh jakarta 2048 Nov 25 04:19 images -rw-r--r-- 1 epugh jakarta 13248 Nov 25 04:19 index.html -rw-r--r-- 1 epugh jakarta 11379 Nov 25 04:19 issue-tracking.html -rw-r--r-- 1 epugh jakarta 12091 Nov 25 04:19 javadoc-warnings-report.html -rw-r--r-- 1 epugh jakarta 11830 Nov 25 04:19 javadoc.html drwxr-xr-x 3 epugh jakarta512 Nov 25 04:20 jcoverage -rw-r--r-- 1 epugh jakarta 36976 Nov 25 04:20 junit-report.html -rw-r--r-- 1 epugh jakarta 22679 Nov 25 04:20 license.html -rw-r--r-- 1 epugh jakarta 12733 Nov 25 04:20 mail-lists.html -rw-r--r-- 1 epugh jakarta 14442 Nov 25 04:20 maven-reports.html -rw-r--r-- 1 epugh jakarta 12984 Nov 25 04:20 pmd-report.html -rw-r--r-- 1 epugh jakarta 13456 Nov 25 04:20 project-info.html drwxr-xr-x 2 epugh jakarta512 Nov 25 04:20 style -rw-r--r-- 1 epugh jakarta 17676 Nov 25 04:20 team-list.html drwxr-xr-x 3 epugh jakarta512 Nov 25 04:21 xref drwxr-xr-x 3 epugh jakarta512 Nov 25 04:21 xref-test -Mark -- Mark Diggory Open Source Software Developer Apache Jakarta Project http://jakarta.apache.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [email] Exceptions
Okay I'll take a look tommorrow and sumbit my patch with the test
cases in with the Other test methods.
Judging from you example, you agree that unexpected exceptions should
just get thrown and that exceptions should be tested independently to
normal tests, which all sounds good to me. Or am i wrong? If the
method isn't there to invoke an exception then if one happens then
surely just throw it, the fact that its unexpected will be evident by
virtue of the test failing due to errors.
Mark
On Tue, 30 Nov 2004 00:04:16 +0800, Corey Scott [EMAIL PROTECTED] wrote:
This is exactly what I was trying to say, just not so elegantly :-)
Eg. Tests for the HtmlEmail class should be in teh HtmlEmailTest class
or is this becomes too big and you want to separate the exceptions,
then there should be two classes HtmlEmailTest (for normal test cases)
and HtmlEmailExceptionTest
-Corey
On Mon, 29 Nov 2004 16:59:29 +0100, Eric Pugh [EMAIL PROTECTED] wrote:
Humm... I typically make all my unit tests throw Exception. It reduces
the length of each test, especially when all you are doing is logging that
it failed with a fail(ex.getMessage).
However, if you are actually TESTING that an exception gets thrown:
try {
email.doSomething();
fail(should have thrown ee);
}
catch (EmailException ee){
assertTrue(ee.getMessage().indexOf(myerror)-1)
}
then I argue they should go in with whatever class we are testing, because
when someone adds a new method to the class, it will encourage them to add
the corresponding test case for any exeption. Or, put the exception test
into the test.
public void testSomething() throws Exception{
email.doSomethign();
snip/
try {
email.doSomething();
fail(should have thrown ee);
}
catch (EmailException ee){
assertTrue(ee.getMessage().indexOf(myerror)-1)
}
}
That way everything stays together. If we aren't actually asserting the
exception, then we shouldn't bother testing it..
Eric
-Original Message-
From: Mark Lowe [mailto:[EMAIL PROTECTED]
Sent: Monday, November 29, 2004 3:19 PM
To: Corey Scott
Cc: Jakarta Commons Developers List
Subject: Re: [email] Exceptions
My thoughts on the test cases are that they should throw exception,
and then have the exception testing separate. This would make the
cases shorter also, perhaps this is what you mean.
public void testFoo() throws Exception
{
Foo foo = new Foo();
foo.setBar(testvar);
}
For example, if for some reason the exception for setBar() was ever
changed the case could remain the same as before, and the only change
would need to be in the exception test case.
Mark
On Mon, 29 Nov 2004 21:59:44 +0800, Corey Scott
[EMAIL PROTECTED] wrote:
I would prefer an Exception Test case per base class, especially for
the larger files. I know most of the tests I wrote, but I think that
if anything the files are too long and would be much more usable if
they were shorter and more focused. Does anyone have any objections
to gave more (but shorter) files?
-Corey
On Mon, 29 Nov 2004 14:17:30 +0100, Mark Lowe [EMAIL PROTECTED] wrote:
I've created the exceptions and I'm now working through the
test cases.
If I summit a patch with the exception testing in a ExceptionTestCase
what's the likelyhood of this being patched? This isn't a question of
style its a question of maintainabilty and now, I'm faced with the
task of weeding out all these try catch statements.
Any objection to a patch with these exception tests moved into a
specialised test case?
Mark
On Mon, 29 Nov 2004 11:23:50 +0100, Mark Lowe
[EMAIL PROTECTED] wrote:
Okay 2 commons.mail exceptions sounds like an improvement.
So the goal
is to minimise the catch statements the user needs to use, sound
reasonable. Throwing everything would mean 2 catches, so I
can see the
value in catching once.
I'll look into a way of having a 1.4+ build option in the
build files
for folk that don't give a gnat's winnit about 1.3 et al.
Anyone know the default behaviour for the
InternetAddress(email,name)
constructor? Does it adopt the charset from the parent email?
Mark
On Mon, 29 Nov 2004 11:11:06 +0100, Eric Pugh
[EMAIL PROTECTED] wrote:
My take on this is that users of [email] are looking for
a package that
simplifies the JavaMail api. And one of the big
simplifing aspects is that
the Exceptions that they have to catch are minimized.
Most users will
probably not care *what* the exception was, only that
there *was* an
exception, and just pass it up the chain. For folks who
actually have code
to deal with the specific exception, then
Re: Cleanup questions from importing email
Fixed -- Joe now has commit access on jakarta-commons as well. Craig On Mon, 29 Nov 2004 10:23:53 +0100, Eric Pugh [EMAIL PROTECTED] wrote: Craig, Joe Germuska (details below) was a sandbox committer for email: developer nameJoe Germuska/name idgermuska/id email[EMAIL PROTECTED]/email /developer Eric Pugh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Migrate to SVN?
It's true that the svn tools aren't as good as the cvs tools yet. However, Struts recently moved to svn and it's amazing how easy it's been to refactor and rearrange the code base after the switch. The change has really livened up that project. Also, I was able to use Subclipse to work with the Struts repository. David --- Shapira, Yoav [EMAIL PROTECTED] wrote: Hi, I feel the same as Senor Colebourne to a large extent. Not -1, but not a +1 either -- a true neutral 0 on this one. When we do move, we need to make sure the relevant documentation for potential contributors, e.g. http://www.apache.org/dev/contributors.html, and all related pages which currently only have CVS information, are updated to include SVN as well. It's a higher barrier of entry unfortunately. Yoav Shapira http://www.yoavshapira.com -Original Message- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] Sent: Friday, November 26, 2004 6:13 PM To: Jakarta Commons Developers List Subject: Re: Migrate to SVN? I remain unenthused by SVN, probably because I don't have to manage a CVS server. Effectively I'm -1, but I'm probably not going to fight. My main reason is that SVN does not appear to be that widely adopted yet. A sign that the time has come to migrate would be when Eclipse/Idea ships with SVN support built in. At the moment, I fear we may just scare off some potential users/contributers. If we are moving though, I would want the pain all at once. Stephen - Original Message - From: Phil Steitz [EMAIL PROTECTED] +1 from me as well -- seems to make sense to move as a group. Phil Alex Karasulu wrote: +1 Noel J. Bergman wrote: 6) should I just delete the /jakarta-commons-sandbox/email directory, or leave the folder and a note pointing to the promotion? What about the website as well? I think for [configuration] we just deleted both. The ideal scenario would be to use cvs delete on all the sandbox files, so that the original history is maintained there, but nobody who checks out the sandbox (with -dP at least) will be bothered by the files. The IDEAL situation would be to convert Jakarta Commons to SVN. Can we PLEASE consider doing so? A lot of projects, including the HTTP Server project, have been migrating, as can be seen from http://svn.apache.org/viewcvs. Jakarta and XML are definitely the laggards now. --- Noel - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? The all-new My Yahoo! - Get yours free! http://my.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 32094] - [email] All exceptions seem to be thrown as messagingExceptions
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32094. 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=32094 [EMAIL PROTECTED] changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-11-29 18:44 --- All applied. -- 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 32410] - [email] tests fail on Unix c/o port settings
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32410. 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=32410 --- Additional Comments From [EMAIL PROTECTED] 2004-11-29 18:45 --- Committed. Can someone test this and verify the fix? -- 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 18968] - [email] Support SMTP Envelope From (bounce address)
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=18968. 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=18968 [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-11-29 18:46 --- Joe added docs. -- 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 32260] - [email] byte array attachments
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32260. 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=32260 [EMAIL PROTECTED] changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-11-29 18:46 --- Restored the ByteArrayDataSource and committed. -- 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: Migrate to SVN?
I have the same feelings as Stephen. Without built-in Eclipse support, this is a pain for me to deal with. I deal with CVS everyday for work no matter what. Dealing with SVN means extra hoops and is a disincentive for me. Yes, playing with a new toy would be fun but at the end of the day, I need to get work done. Gary -Original Message- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] Sent: Friday, November 26, 2004 3:13 PM To: Jakarta Commons Developers List Subject: Re: Migrate to SVN? I remain unenthused by SVN, probably because I don't have to manage a CVS server. Effectively I'm -1, but I'm probably not going to fight. My main reason is that SVN does not appear to be that widely adopted yet. A sign that the time has come to migrate would be when Eclipse/Idea ships with SVN support built in. At the moment, I fear we may just scare off some potential users/contributers. If we are moving though, I would want the pain all at once. Stephen - Original Message - From: Phil Steitz [EMAIL PROTECTED] +1 from me as well -- seems to make sense to move as a group. Phil Alex Karasulu wrote: +1 Noel J. Bergman wrote: 6) should I just delete the /jakarta-commons-sandbox/email directory, or leave the folder and a note pointing to the promotion? What about the website as well? I think for [configuration] we just deleted both. The ideal scenario would be to use cvs delete on all the sandbox files, so that the original history is maintained there, but nobody who checks out the sandbox (with -dP at least) will be bothered by the files. The IDEAL situation would be to convert Jakarta Commons to SVN. Can we PLEASE consider doing so? A lot of projects, including the HTTP Server project, have been migrating, as can be seen from http://svn.apache.org/viewcvs. Jakarta and XML are definitely the laggards now. --- Noel - 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] - 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: [email] site cleanup
Mark, I think I did the right chmod. Can you just double check? Eric -Original Message- From: Mark R. Diggory [mailto:[EMAIL PROTECTED] Sent: Monday, November 29, 2004 5:08 PM To: Jakarta Commons Developers List Cc: [EMAIL PROTECTED] Subject: [email] site cleanup Eric, If you could change the group permissions recursively on the email site so that it can be updated by others that would be great. Afterwards, I'll be glad to run the site generation to cleanup the existing site. [EMAIL PROTECTED]:/www/jakarta.apache.org/commons/email ls -a -l total 390 drwxr-xr-x 8 epugh jakarta 1024 Nov 25 04:21 . drwxrwxr-x 50 mdiggory jakarta 2048 Nov 28 14:32 .. drwxr-xr-x 4 epugh jakarta512 Nov 25 04:18 apidocs -rw-r--r-- 1 epugh jakarta 26249 Nov 25 04:18 changelog-report.html -rw-r--r-- 1 epugh jakarta 16963 Nov 25 04:18 changes-report.html -rw-r--r-- 1 epugh jakarta736 Nov 25 04:18 changes.rss -rw-r--r-- 1 epugh jakarta 47015 Nov 25 04:18 checkstyle-report.html -rw-r--r-- 1 epugh jakarta 2348 Nov 25 04:18 checkstyle.rss -rw-r--r-- 1 epugh jakarta 13128 Nov 25 04:18 cvs-usage.html -rw-r--r-- 1 epugh jakarta 12762 Nov 25 04:18 dependencies.html -rw-r--r-- 1 epugh jakarta 11780 Nov 25 04:18 developer-activity-report.html -rw-r--r-- 1 epugh jakarta 11908 Nov 25 04:18 downloads.html -rw-r--r-- 1 epugh jakarta 20142 Nov 25 04:18 examples.html -rw-r--r-- 1 epugh jakarta 16455 Nov 25 04:18 file-activity-report.html drwxr-xr-x 3 epugh jakarta 2048 Nov 25 04:19 images -rw-r--r-- 1 epugh jakarta 13248 Nov 25 04:19 index.html -rw-r--r-- 1 epugh jakarta 11379 Nov 25 04:19 issue-tracking.html -rw-r--r-- 1 epugh jakarta 12091 Nov 25 04:19 javadoc-warnings-report.html -rw-r--r-- 1 epugh jakarta 11830 Nov 25 04:19 javadoc.html drwxr-xr-x 3 epugh jakarta512 Nov 25 04:20 jcoverage -rw-r--r-- 1 epugh jakarta 36976 Nov 25 04:20 junit-report.html -rw-r--r-- 1 epugh jakarta 22679 Nov 25 04:20 license.html -rw-r--r-- 1 epugh jakarta 12733 Nov 25 04:20 mail-lists.html -rw-r--r-- 1 epugh jakarta 14442 Nov 25 04:20 maven-reports.html -rw-r--r-- 1 epugh jakarta 12984 Nov 25 04:20 pmd-report.html -rw-r--r-- 1 epugh jakarta 13456 Nov 25 04:20 project-info.html drwxr-xr-x 2 epugh jakarta512 Nov 25 04:20 style -rw-r--r-- 1 epugh jakarta 17676 Nov 25 04:20 team-list.html drwxr-xr-x 3 epugh jakarta512 Nov 25 04:21 xref drwxr-xr-x 3 epugh jakarta512 Nov 25 04:21 xref-test -Mark -- Mark Diggory Open Source Software Developer Apache Jakarta Project http://jakarta.apache.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: [email] Exceptions
I've applied a stack of changes, including Mark's EmailException, to the
codebase. I don't really care much about how the unit tests look, as long
as the jcoverage keeps going up!
At this point, I think all the API changes are done, and my gut feeling is
that we should look to final testing, cut a Release Candidate and then roll
1.0. We should also start thinking about what the next version will entail.
Eric
-Original Message-
From: Mark Lowe [mailto:[EMAIL PROTECTED]
Sent: Monday, November 29, 2004 5:25 PM
To: Corey Scott
Cc: Jakarta Commons Developers List; [EMAIL PROTECTED]
Subject: Re: [email] Exceptions
Okay I'll take a look tommorrow and sumbit my patch with the test
cases in with the Other test methods.
Judging from you example, you agree that unexpected exceptions should
just get thrown and that exceptions should be tested independently to
normal tests, which all sounds good to me. Or am i wrong? If the
method isn't there to invoke an exception then if one happens then
surely just throw it, the fact that its unexpected will be evident by
virtue of the test failing due to errors.
Mark
On Tue, 30 Nov 2004 00:04:16 +0800, Corey Scott
[EMAIL PROTECTED] wrote:
This is exactly what I was trying to say, just not so elegantly :-)
Eg. Tests for the HtmlEmail class should be in teh HtmlEmailTest class
or is this becomes too big and you want to separate the exceptions,
then there should be two classes HtmlEmailTest (for normal test cases)
and HtmlEmailExceptionTest
-Corey
On Mon, 29 Nov 2004 16:59:29 +0100, Eric Pugh [EMAIL PROTECTED] wrote:
Humm... I typically make all my unit tests throw Exception.
It reduces
the length of each test, especially when all you are doing is
logging that
it failed with a fail(ex.getMessage).
However, if you are actually TESTING that an exception gets thrown:
try {
email.doSomething();
fail(should have thrown ee);
}
catch (EmailException ee){
assertTrue(ee.getMessage().indexOf(myerror)-1)
}
then I argue they should go in with whatever class we are
testing, because
when someone adds a new method to the class, it will
encourage them to add
the corresponding test case for any exeption. Or, put the
exception test
into the test.
public void testSomething() throws Exception{
email.doSomethign();
snip/
try {
email.doSomething();
fail(should have thrown ee);
}
catch (EmailException ee){
assertTrue(ee.getMessage().indexOf(myerror)-1)
}
}
That way everything stays together. If we aren't actually
asserting the
exception, then we shouldn't bother testing it..
Eric
-Original Message-
From: Mark Lowe [mailto:[EMAIL PROTECTED]
Sent: Monday, November 29, 2004 3:19 PM
To: Corey Scott
Cc: Jakarta Commons Developers List
Subject: Re: [email] Exceptions
My thoughts on the test cases are that they should throw exception,
and then have the exception testing separate. This would make the
cases shorter also, perhaps this is what you mean.
public void testFoo() throws Exception
{
Foo foo = new Foo();
foo.setBar(testvar);
}
For example, if for some reason the exception for setBar() was ever
changed the case could remain the same as before, and the
only change
would need to be in the exception test case.
Mark
On Mon, 29 Nov 2004 21:59:44 +0800, Corey Scott
[EMAIL PROTECTED] wrote:
I would prefer an Exception Test case per base class,
especially for
the larger files. I know most of the tests I wrote, but
I think that
if anything the files are too long and would be much more
usable if
they were shorter and more focused. Does anyone have any
objections
to gave more (but shorter) files?
-Corey
On Mon, 29 Nov 2004 14:17:30 +0100, Mark Lowe
[EMAIL PROTECTED] wrote:
I've created the exceptions and I'm now working through the
test cases.
If I summit a patch with the exception testing in a
ExceptionTestCase
what's the likelyhood of this being patched? This isn't
a question of
style its a question of maintainabilty and now, I'm
faced with the
task of weeding out all these try catch statements.
Any objection to a patch with these exception tests moved into a
specialised test case?
Mark
On Mon, 29 Nov 2004 11:23:50 +0100, Mark Lowe
[EMAIL PROTECTED] wrote:
Okay 2 commons.mail exceptions sounds like an improvement.
So the goal
is to minimise the catch statements the user needs to
use, sound
reasonable. Throwing everything would mean 2 catches, so I
can see the
value in catching once.
I'll look into a way of having a 1.4+ build option in the
build files
for folk
DO NOT REPLY [Bug 32364] - [lang] HashCodeBuilder failed to generate unique hashcode
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32364. 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=32364 --- Additional Comments From [EMAIL PROTECTED] 2004-11-29 19:06 --- I appended the string first and then integer and seem to get different hashcode back. But the problem may come back for some other combinations. Many thanks for comments posted. Bruce -- 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 32410] - [email] tests fail on Unix c/o port settings
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32410. 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=32410 [EMAIL PROTECTED] changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-11-29 19:17 --- I have run the tests on Mac OS X and verified that they work without being 'root'. -- 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: Migrate to SVN?
I doubt Eclipse will ever have built-in svn support because there are several third party plugins available. Since adding a plugin update site is so trivial in Eclipse I wouldn't think this would be a big deal. The plugin I use with Struts svn is http://subclipse.tigris.org/. It works largely the same as Eclipse's cvs plugin. David --- Gary Gregory [EMAIL PROTECTED] wrote: I have the same feelings as Stephen. Without built-in Eclipse support, this is a pain for me to deal with. I deal with CVS everyday for work no matter what. Dealing with SVN means extra hoops and is a disincentive for me. Yes, playing with a new toy would be fun but at the end of the day, I need to get work done. Gary -Original Message- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] Sent: Friday, November 26, 2004 3:13 PM To: Jakarta Commons Developers List Subject: Re: Migrate to SVN? I remain unenthused by SVN, probably because I don't have to manage a CVS server. Effectively I'm -1, but I'm probably not going to fight. My main reason is that SVN does not appear to be that widely adopted yet. A sign that the time has come to migrate would be when Eclipse/Idea ships with SVN support built in. At the moment, I fear we may just scare off some potential users/contributers. If we are moving though, I would want the pain all at once. Stephen - Original Message - From: Phil Steitz [EMAIL PROTECTED] +1 from me as well -- seems to make sense to move as a group. Phil Alex Karasulu wrote: +1 Noel J. Bergman wrote: 6) should I just delete the /jakarta-commons-sandbox/email directory, or leave the folder and a note pointing to the promotion? What about the website as well? I think for [configuration] we just deleted both. The ideal scenario would be to use cvs delete on all the sandbox files, so that the original history is maintained there, but nobody who checks out the sandbox (with -dP at least) will be bothered by the files. The IDEAL situation would be to convert Jakarta Commons to SVN. Can we PLEASE consider doing so? A lot of projects, including the HTTP Server project, have been migrating, as can be seen from http://svn.apache.org/viewcvs. Jakarta and XML are definitely the laggards now. --- Noel - 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] - 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 you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/transaction/src/java/org/apache/commons/transaction/util RendezvousBarrier.java
luetzkendorf2004/11/29 10:28:17
Modified:transaction/src/java/org/apache/commons/transaction/util/xa
AbstractXAResource.java XidWrapper.java
transaction/src/java/org/apache/commons/transaction/file
FileResourceManager.java
transaction/src/java/org/apache/commons/transaction/locking
GenericLock.java
transaction/src/java/org/apache/commons/transaction/util
RendezvousBarrier.java
Log:
logging now tests for appropriate logging level as early as possible
Revision ChangesPath
1.2 +30 -20
jakarta-commons/transaction/src/java/org/apache/commons/transaction/util/xa/AbstractXAResource.java
Index: AbstractXAResource.java
===
RCS file:
/home/cvs/jakarta-commons/transaction/src/java/org/apache/commons/transaction/util/xa/AbstractXAResource.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- AbstractXAResource.java 18 Nov 2004 23:27:19 - 1.1
+++ AbstractXAResource.java 29 Nov 2004 18:28:17 - 1.2
@@ -53,7 +53,9 @@
protected abstract boolean includeBranchInXid();
public void forget(Xid xid) throws XAException {
-getLoggerFacade().logFine(Forgetting transaction branch + xid);
+if (getLoggerFacade().isFineEnabled()) {
+getLoggerFacade().logFine(Forgetting transaction branch +
xid);
+}
TransactionalResource ts = getTransactionalResource(xid);
if (ts == null) {
throw new XAException(XAException.XAER_NOTA);
@@ -69,7 +71,9 @@
throw new XAException(XAException.XAER_NOTA);
}
-getLoggerFacade().logFine(Committing transaction branch + ts);
+if (getLoggerFacade().isFineEnabled()) {
+getLoggerFacade().logFine(Committing transaction branch + ts);
+}
if (ts.getStatus() == STATUS_MARKED_ROLLBACK) {
throw new XAException(XAException.XA_RBROLLBACK);
@@ -94,7 +98,9 @@
throw new XAException(XAException.XAER_NOTA);
}
-getLoggerFacade().logFine(Rolling back transaction branch + ts);
+if (getLoggerFacade().isFineEnabled()) {
+getLoggerFacade().logFine(Rolling back transaction branch +
ts);
+}
ts.rollback();
setCurrentlyActiveTransactionalResource(null);
@@ -108,7 +114,9 @@
throw new XAException(XAException.XAER_NOTA);
}
-getLoggerFacade().logFine(Preparing transaction branch + ts);
+if (getLoggerFacade().isFineEnabled()) {
+getLoggerFacade().logFine(Preparing transaction branch + ts);
+}
if (ts.getStatus() == STATUS_MARKED_ROLLBACK) {
throw new XAException(XAException.XA_RBROLLBACK);
@@ -127,12 +135,13 @@
if (getCurrentlyActiveTransactionalResource() == null) {
throw new XAException(XAException.XAER_INVAL);
}
-getLoggerFacade().logFine(
-Thread
-+ Thread.currentThread()
-+ (flags == TMSUSPEND ? suspends : flags == TMFAIL ?
fails : ends)
-+ work on behalf of transaction branch
-+ ts);
+if (getLoggerFacade().isFineEnabled()) {
+ getLoggerFacade().logFine(new StringBuffer(128)
+ .append(Thread ).append(Thread.currentThread())
+ .append(flags == TMSUSPEND ? suspends : flags == TMFAIL
? fails : ends)
+ .append( work on behalf of transaction branch )
+ .append(ts).toString());
+}
switch (flags) {
case TMSUSPEND :
@@ -153,13 +162,14 @@
if (getCurrentlyActiveTransactionalResource() != null) {
throw new XAException(XAException.XAER_INVAL);
}
-getLoggerFacade().logFine(
-Thread
-+ Thread.currentThread()
-+ (flags == TMNOFLAGS ? starts : flags == TMJOIN ?
joins : resumes)
-+ work on behalf of transaction branch
-+ xid);
-
+if (getLoggerFacade().isFineEnabled()) {
+getLoggerFacade().logFine(new StringBuffer(128)
+.append(Thread ).append(Thread.currentThread())
+.append(flags == TMNOFLAGS ? starts : flags == TMJOIN
? joins : resumes)
+.append( work on behalf of transaction branch )
+.append(xid).toString());
+}
+
TransactionalResource ts;
switch (flags) {
// a new transaction
1.2 +8 -5
DO NOT REPLY [Bug 30858] - [configuration] PropertyConfiguration.save() does not take basePath into account
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=30858. 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=30858 --- Additional Comments From [EMAIL PROTECTED] 2004-11-29 19:38 --- Created an attachment (id=13583) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=13583action=view) Test case for saving with base path -- 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: [io] Exact meaning of getPath, esp. on UNIX?
Paulo Gaspar wrote: And isn't it always simpler if the name of the method perfectly explains its functionality instead of relying on some convention? That was exactly the reason for my previous email. The function getPath() is already straightforward. Any element in a file system has a path - even directories. This is no convention, but a fact (which sometimes it needs a second thought to grasp). By adding getParentPath would also require renaming the sister function to getFullParentPath... :D and in the end, no one would understand the reason for such function names. So again, KISS! Cheers, Christoph P.S. This is my last comment to this issue, so not to inch into a flame thread :) (Ok, that is not always possible, but it IS in this case.) Regards, Paulo Christoph Reck wrote: Paulo Gaspar wrote: To complitelly avoid ambiguities, why not calling it getParentPath() instead? Keep it simple... Any file-system object (file or directory) has a name and a path to it. The simple rule is fileNameAndPath := FilenameUtils.getFullPath( fileNameAndPath ) + File.separatorChar + FilenameUtils.getName( fileNameAndPath ) := FilenameUtils.concat( FilenameUtils.getFullPath( fileNameAndPath ), FilenameUtils.getName( fileNameAndPath ) ) Is this agreable by everyone? Why compicate the matters? Notable is that a directory itself is positioned at a path location. Therefore FilenameUtils.getPath(pathToDirectory).length() pathToDirectory.length() Cheers, Christoph [snip] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30858] - [configuration] PropertyConfiguration.save() does not take basePath into account
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=30858. 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=30858 --- Additional Comments From [EMAIL PROTECTED] 2004-11-29 19:59 --- I wrote a test case for saving a file based configuration with a base path, and this still fails. The test should reproduce a situation as it occurs in ConfigurationFactory: When a file based configuration is loaded, first its setBasePath() method gets called and then setFileName(). To the former a URL may be passed. If later the file based configuration should be saved using the save() method or save(String) with a relative file name, conversion of this URL to a File object fails. A solution would be to make ConfigurationUtils.constructFile() aware of URLs, so that a correct File object is constructed even if URLs are involved (given that all URLs have the file protocol). After looking at the code for a while I find our actual solution for dealing with file names, base paths and URLs very confusing. The fact that we distinguish between a base path and an URL makes the whole stuff hard to maintain and error prone (just think about the many places in ConfigurationFactory, AbstractFileConfiguration and elsewhere where special checks are performed). Besides it is hard for the users to understand. What can we do about it? I would suggest dropping (deprecating) either the get/setURL() or get/setBasePath() methods. The remaining methods should be able to deal with both URLs and files. This could be implemented in ConfigurationUtils, in a central place. Are there any other ideas/opinions? -- 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: [email] site cleanup
You'll need to change the `email` directory as well drwxr-xr-x 8 epughjakarta 1024 Nov 25 04:21 email thnx again, Mark Eric Pugh wrote: Mark, I think I did the right chmod. Can you just double check? Eric -Original Message- From: Mark R. Diggory [mailto:[EMAIL PROTECTED] Sent: Monday, November 29, 2004 5:08 PM To: Jakarta Commons Developers List Cc: [EMAIL PROTECTED] Subject: [email] site cleanup Eric, If you could change the group permissions recursively on the email site so that it can be updated by others that would be great. Afterwards, I'll be glad to run the site generation to cleanup the existing site. [EMAIL PROTECTED]:/www/jakarta.apache.org/commons/email ls -a -l total 390 drwxr-xr-x 8 epugh jakarta 1024 Nov 25 04:21 . drwxrwxr-x 50 mdiggory jakarta 2048 Nov 28 14:32 .. drwxr-xr-x 4 epugh jakarta512 Nov 25 04:18 apidocs -rw-r--r-- 1 epugh jakarta 26249 Nov 25 04:18 changelog-report.html -rw-r--r-- 1 epugh jakarta 16963 Nov 25 04:18 changes-report.html -rw-r--r-- 1 epugh jakarta736 Nov 25 04:18 changes.rss -rw-r--r-- 1 epugh jakarta 47015 Nov 25 04:18 checkstyle-report.html -rw-r--r-- 1 epugh jakarta 2348 Nov 25 04:18 checkstyle.rss -rw-r--r-- 1 epugh jakarta 13128 Nov 25 04:18 cvs-usage.html -rw-r--r-- 1 epugh jakarta 12762 Nov 25 04:18 dependencies.html -rw-r--r-- 1 epugh jakarta 11780 Nov 25 04:18 developer-activity-report.html -rw-r--r-- 1 epugh jakarta 11908 Nov 25 04:18 downloads.html -rw-r--r-- 1 epugh jakarta 20142 Nov 25 04:18 examples.html -rw-r--r-- 1 epugh jakarta 16455 Nov 25 04:18 file-activity-report.html drwxr-xr-x 3 epugh jakarta 2048 Nov 25 04:19 images -rw-r--r-- 1 epugh jakarta 13248 Nov 25 04:19 index.html -rw-r--r-- 1 epugh jakarta 11379 Nov 25 04:19 issue-tracking.html -rw-r--r-- 1 epugh jakarta 12091 Nov 25 04:19 javadoc-warnings-report.html -rw-r--r-- 1 epugh jakarta 11830 Nov 25 04:19 javadoc.html drwxr-xr-x 3 epugh jakarta512 Nov 25 04:20 jcoverage -rw-r--r-- 1 epugh jakarta 36976 Nov 25 04:20 junit-report.html -rw-r--r-- 1 epugh jakarta 22679 Nov 25 04:20 license.html -rw-r--r-- 1 epugh jakarta 12733 Nov 25 04:20 mail-lists.html -rw-r--r-- 1 epugh jakarta 14442 Nov 25 04:20 maven-reports.html -rw-r--r-- 1 epugh jakarta 12984 Nov 25 04:20 pmd-report.html -rw-r--r-- 1 epugh jakarta 13456 Nov 25 04:20 project-info.html drwxr-xr-x 2 epugh jakarta512 Nov 25 04:20 style -rw-r--r-- 1 epugh jakarta 17676 Nov 25 04:20 team-list.html drwxr-xr-x 3 epugh jakarta512 Nov 25 04:21 xref drwxr-xr-x 3 epugh jakarta512 Nov 25 04:21 xref-test -Mark -- Mark Diggory Open Source Software Developer Apache Jakarta Project http://jakarta.apache.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] -- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [email] site cleanup
Okay, done.. I tried ls -l email and couldn't get it, I got every directory, but I think I did it correctly. Thanks for the handholding. -Original Message- From: Mark R. Diggory [mailto:[EMAIL PROTECTED] Sent: Monday, November 29, 2004 8:24 PM To: Jakarta Commons Developers List Subject: Re: [email] site cleanup You'll need to change the `email` directory as well drwxr-xr-x 8 epughjakarta 1024 Nov 25 04:21 email thnx again, Mark Eric Pugh wrote: Mark, I think I did the right chmod. Can you just double check? Eric -Original Message- From: Mark R. Diggory [mailto:[EMAIL PROTECTED] Sent: Monday, November 29, 2004 5:08 PM To: Jakarta Commons Developers List Cc: [EMAIL PROTECTED] Subject: [email] site cleanup Eric, If you could change the group permissions recursively on the email site so that it can be updated by others that would be great. Afterwards, I'll be glad to run the site generation to cleanup the existing site. [EMAIL PROTECTED]:/www/jakarta.apache.org/commons/email ls -a -l total 390 drwxr-xr-x 8 epugh jakarta 1024 Nov 25 04:21 . drwxrwxr-x 50 mdiggory jakarta 2048 Nov 28 14:32 .. drwxr-xr-x 4 epugh jakarta512 Nov 25 04:18 apidocs -rw-r--r-- 1 epugh jakarta 26249 Nov 25 04:18 changelog-report.html -rw-r--r-- 1 epugh jakarta 16963 Nov 25 04:18 changes-report.html -rw-r--r-- 1 epugh jakarta736 Nov 25 04:18 changes.rss -rw-r--r-- 1 epugh jakarta 47015 Nov 25 04:18 checkstyle-report.html -rw-r--r-- 1 epugh jakarta 2348 Nov 25 04:18 checkstyle.rss -rw-r--r-- 1 epugh jakarta 13128 Nov 25 04:18 cvs-usage.html -rw-r--r-- 1 epugh jakarta 12762 Nov 25 04:18 dependencies.html -rw-r--r-- 1 epugh jakarta 11780 Nov 25 04:18 developer-activity-report.html -rw-r--r-- 1 epugh jakarta 11908 Nov 25 04:18 downloads.html -rw-r--r-- 1 epugh jakarta 20142 Nov 25 04:18 examples.html -rw-r--r-- 1 epugh jakarta 16455 Nov 25 04:18 file-activity-report.html drwxr-xr-x 3 epugh jakarta 2048 Nov 25 04:19 images -rw-r--r-- 1 epugh jakarta 13248 Nov 25 04:19 index.html -rw-r--r-- 1 epugh jakarta 11379 Nov 25 04:19 issue-tracking.html -rw-r--r-- 1 epugh jakarta 12091 Nov 25 04:19 javadoc-warnings-report.html -rw-r--r-- 1 epugh jakarta 11830 Nov 25 04:19 javadoc.html drwxr-xr-x 3 epugh jakarta512 Nov 25 04:20 jcoverage -rw-r--r-- 1 epugh jakarta 36976 Nov 25 04:20 junit-report.html -rw-r--r-- 1 epugh jakarta 22679 Nov 25 04:20 license.html -rw-r--r-- 1 epugh jakarta 12733 Nov 25 04:20 mail-lists.html -rw-r--r-- 1 epugh jakarta 14442 Nov 25 04:20 maven-reports.html -rw-r--r-- 1 epugh jakarta 12984 Nov 25 04:20 pmd-report.html -rw-r--r-- 1 epugh jakarta 13456 Nov 25 04:20 project-info.html drwxr-xr-x 2 epugh jakarta512 Nov 25 04:20 style -rw-r--r-- 1 epugh jakarta 17676 Nov 25 04:20 team-list.html drwxr-xr-x 3 epugh jakarta512 Nov 25 04:21 xref drwxr-xr-x 3 epugh jakarta512 Nov 25 04:21 xref-test -Mark -- Mark Diggory Open Source Software Developer Apache Jakarta Project http://jakarta.apache.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] -- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu - 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: Migrate to SVN?
On 29 Nov 2004, at 14:15, Shapira, Yoav wrote: Hi, I feel the same as Senor Colebourne to a large extent. Not -1, but not a +1 either -- a true neutral 0 on this one. When we do move, we need to make sure the relevant documentation for potential contributors, e.g. http://www.apache.org/dev/contributors.html, and all related pages which currently only have CVS information, are updated to include SVN as well. It's a higher barrier of entry unfortunately. yep. but this is something that jakarta as a whole needs to address. it wouldn't be that much effort each provided we could get a number of volunteers. maybe this is something that could be raised on general. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Migrate to SVN?
Hi, I agree it's not a huge effort. I was (am) just saying it's a prerequisite. Yoav Shapira http://www.yoavshapira.com -Original Message- From: robert burrell donkin [mailto:[EMAIL PROTECTED] Sent: Monday, November 29, 2004 3:15 PM To: Jakarta Commons Developers List Subject: Re: Migrate to SVN? On 29 Nov 2004, at 14:15, Shapira, Yoav wrote: Hi, I feel the same as Senor Colebourne to a large extent. Not -1, but not a +1 either -- a true neutral 0 on this one. When we do move, we need to make sure the relevant documentation for potential contributors, e.g. http://www.apache.org/dev/contributors.html, and all related pages which currently only have CVS information, are updated to include SVN as well. It's a higher barrier of entry unfortunately. yep. but this is something that jakarta as a whole needs to address. it wouldn't be that much effort each provided we could get a number of volunteers. maybe this is something that could be raised on general. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Migrate to SVN?
I doubt Eclipse will ever have built-in svn support because there are several third party plugins available. Since adding a plugin update site is so trivial in Eclipse I wouldn't think this would be a big deal. The plugin I use with Struts svn is http://subclipse.tigris.org/. It works largely the same as Eclipse's cvs plugin. I'm sure Eclipse *will* have built-in svn support at some point. If the Subclipse plug-in provides more or less the same functionality as the standard cvs plug-ins, and conforms to the VCM architecture, then there is every chance that it could be hosted by Eclipse and provided as an alternative to the cvs stuff. The key will be the adoption rate of svn in the wider community - the more projects like Apache/Jakarta that use it, the greater will be the demand for Eclipse to support it... One of those chicken and egg things... ;-) Colin Sharples IBM Advisory IT Specialist Email: sharples-at-nz.ibm.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Migrate to SVN?
On Tue, 30 Nov 2004 09:31:25 +1300, Sharples, Colin [EMAIL PROTECTED] wrote: I doubt Eclipse will ever have built-in svn support because there are several third party plugins available. Since adding a plugin update site is so trivial in Eclipse I wouldn't think this would be a big deal. The plugin I use with Struts svn is http://subclipse.tigris.org/. It works largely the same as Eclipse's cvs plugin. I'm sure Eclipse *will* have built-in svn support at some point. If the Subclipse plug-in provides more or less the same functionality as the standard cvs plug-ins, and conforms to the VCM architecture, then there is every chance that it could be hosted by Eclipse and provided as an alternative to the cvs stuff. The key will be the adoption rate of svn in the wider community - the more projects like Apache/Jakarta that use it, the greater will be the demand for Eclipse to support it... It's a stated goal of the infrastructure team to get _all_ Apache projects moved over from CVS to SVN, for a variety of important reasons. A bunch of projects have already made the move, as you can see here: http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN If you believe that tool support will follow adoption, then we'd be doing ourselves a favour by migrating sooner rather than later. Then the ASF can say we use only Subversion for all our source control needs, which is a pretty powerful statement that SVN is here to stay in a big way. -- Martin Cooper One of those chicken and egg things... ;-) Colin Sharples IBM Advisory IT Specialist Email: sharples-at-nz.ibm.com - 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: cvs commit: jakarta-commons/transaction/src/java/org/apache/commons/transaction/util RendezvousBarrier.java
This looks like a lot of tiresome work, thanks for doing it :)
Oliver
On 29 Nov 2004 18:28:17 -, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
luetzkendorf2004/11/29 10:28:17
Modified:transaction/src/java/org/apache/commons/transaction/util/xa
AbstractXAResource.java XidWrapper.java
transaction/src/java/org/apache/commons/transaction/file
FileResourceManager.java
transaction/src/java/org/apache/commons/transaction/locking
GenericLock.java
transaction/src/java/org/apache/commons/transaction/util
RendezvousBarrier.java
Log:
logging now tests for appropriate logging level as early as possible
Revision ChangesPath
1.2 +30 -20
jakarta-commons/transaction/src/java/org/apache/commons/transaction/util/xa/AbstractXAResource.java
Index: AbstractXAResource.java
===
RCS file:
/home/cvs/jakarta-commons/transaction/src/java/org/apache/commons/transaction/util/xa/AbstractXAResource.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- AbstractXAResource.java 18 Nov 2004 23:27:19 - 1.1
+++ AbstractXAResource.java 29 Nov 2004 18:28:17 - 1.2
@@ -53,7 +53,9 @@
protected abstract boolean includeBranchInXid();
public void forget(Xid xid) throws XAException {
-getLoggerFacade().logFine(Forgetting transaction branch + xid);
+if (getLoggerFacade().isFineEnabled()) {
+getLoggerFacade().logFine(Forgetting transaction branch +
xid);
+}
TransactionalResource ts = getTransactionalResource(xid);
if (ts == null) {
throw new XAException(XAException.XAER_NOTA);
@@ -69,7 +71,9 @@
throw new XAException(XAException.XAER_NOTA);
}
-getLoggerFacade().logFine(Committing transaction branch + ts);
+if (getLoggerFacade().isFineEnabled()) {
+getLoggerFacade().logFine(Committing transaction branch +
ts);
+}
if (ts.getStatus() == STATUS_MARKED_ROLLBACK) {
throw new XAException(XAException.XA_RBROLLBACK);
@@ -94,7 +98,9 @@
throw new XAException(XAException.XAER_NOTA);
}
-getLoggerFacade().logFine(Rolling back transaction branch + ts);
+if (getLoggerFacade().isFineEnabled()) {
+getLoggerFacade().logFine(Rolling back transaction branch +
ts);
+}
ts.rollback();
setCurrentlyActiveTransactionalResource(null);
@@ -108,7 +114,9 @@
throw new XAException(XAException.XAER_NOTA);
}
-getLoggerFacade().logFine(Preparing transaction branch + ts);
+if (getLoggerFacade().isFineEnabled()) {
+getLoggerFacade().logFine(Preparing transaction branch +
ts);
+}
if (ts.getStatus() == STATUS_MARKED_ROLLBACK) {
throw new XAException(XAException.XA_RBROLLBACK);
@@ -127,12 +135,13 @@
if (getCurrentlyActiveTransactionalResource() == null) {
throw new XAException(XAException.XAER_INVAL);
}
-getLoggerFacade().logFine(
-Thread
-+ Thread.currentThread()
-+ (flags == TMSUSPEND ? suspends : flags == TMFAIL ?
fails : ends)
-+ work on behalf of transaction branch
-+ ts);
+if (getLoggerFacade().isFineEnabled()) {
+ getLoggerFacade().logFine(new StringBuffer(128)
+ .append(Thread ).append(Thread.currentThread())
+ .append(flags == TMSUSPEND ? suspends : flags ==
TMFAIL ? fails : ends)
+ .append( work on behalf of transaction branch )
+ .append(ts).toString());
+}
switch (flags) {
case TMSUSPEND :
@@ -153,13 +162,14 @@
if (getCurrentlyActiveTransactionalResource() != null) {
throw new XAException(XAException.XAER_INVAL);
}
-getLoggerFacade().logFine(
-Thread
-+ Thread.currentThread()
-+ (flags == TMNOFLAGS ? starts : flags == TMJOIN ?
joins : resumes)
-+ work on behalf of transaction branch
-+ xid);
-
+if (getLoggerFacade().isFineEnabled()) {
+getLoggerFacade().logFine(new StringBuffer(128)
+.append(Thread ).append(Thread.currentThread())
+.append(flags == TMNOFLAGS ? starts : flags ==
TMJOIN ? joins : resumes)
+.append( work on behalf of transaction branch )
+
[jira] Resolved: (JELLY-169) Testing fails in JDK 1.5
[ http://nagoya.apache.org/jira/browse/JELLY-169?page=history ] dion gillard resolved JELLY-169: Resolution: Duplicate Fix Version: 1.0 Dupe of JELLY-166 Testing fails in JDK 1.5 Key: JELLY-169 URL: http://nagoya.apache.org/jira/browse/JELLY-169 Project: jelly Type: Bug Components: core / taglib.core Versions: 1.0-beta-4 Reporter: Paul Libbrecht Fix For: 1.0 Currently, running maven jar fails in both jelly and jelly-swing with JDK 1.5. The TestXXXtags fail. paul -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://nagoya.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JELLY-169) Testing fails in JDK 1.5
[ http://nagoya.apache.org/jira/browse/JELLY-169?page=comments#action_55998 ] dion gillard commented on JELLY-169: Which version of Maven are you using. This sounds awfully like a bug I reported which has only surfaced on Maven 1.1-SNAPSHOT so far. Testing fails in JDK 1.5 Key: JELLY-169 URL: http://nagoya.apache.org/jira/browse/JELLY-169 Project: jelly Type: Bug Components: core / taglib.core Versions: 1.0-beta-4 Reporter: Paul Libbrecht Fix For: 1.0 Currently, running maven jar fails in both jelly and jelly-swing with JDK 1.5. The TestXXXtags fail. paul -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://nagoya.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JELLY-169) Testing fails in JDK 1.5
[ http://nagoya.apache.org/jira/browse/JELLY-169?page=comments#action_56002 ] Paul Libbrecht commented on JELLY-169: -- The maven versions were 1.0 and 1.0.1, for me... nothing fancy in there. paul Testing fails in JDK 1.5 Key: JELLY-169 URL: http://nagoya.apache.org/jira/browse/JELLY-169 Project: jelly Type: Bug Components: core / taglib.core Versions: 1.0-beta-4 Reporter: Paul Libbrecht Fix For: 1.0 Currently, running maven jar fails in both jelly and jelly-swing with JDK 1.5. The TestXXXtags fail. paul -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://nagoya.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 32350] - [chain] Consider making lookup commands default to same chain
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32350. 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=32350 --- Additional Comments From [EMAIL PROTECTED] 2004-11-29 23:59 --- Joe, Perhaps I am misunderstanding your original message, but I think this functionality already exists in the LookupComand. If you do not specify a catalog name, then it will search the default (via CatalogFactory.getInstance () method). This was added somewhat recently (end of October), so maybe you were not looking at the latest source code? Most likely I am confused because Craig's response seems to indicate an entirely different take on your post. Just got back from a month long vacation, so I am a little bit out of it. Let me know if this of any help to you. sean -- 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 32350] - [chain] Consider making lookup commands default to same chain
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32350. 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=32350 --- Additional Comments From [EMAIL PROTECTED] 2004-11-30 00:20 --- The problem comes when the instance of lookup command isn't in the default catalog - in that case, I think the expected behavior (if only from carelessness) would be that the lookup command would look up another command in the same catalog, and instead (as you point out), it would be looked up in the default catalog. More specifically, this is the configuration bug I fixed here: http://svn.apache.org/viewcvs.cgi/struts/sandbox/trunk/struts-chain/src/conf/chain-config.xml?rev=106250view=log For the moment, I'm acknowledging that I don't have any good ideas for how to craft the API that would support this request, but I'd like to leave it open for a while. Maybe there's a way to pass this information in the Context? -- 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: [io] Exact meaning of getPath, esp. on UNIX?
Ah! Now I understand your reasoning. (Had to reread your previous email too.) This seems to be a simple issue of terminology. And I already had that same problem: it is hard to choose an unambigous terminology because sometimes people call path of an item to the full name of the directory that holds that item, BUT, sometimes, some people call path to the full name of the item itself. Now, the only alternative that comes to my mind is: fullFileName := FilenameUtils.getFullParentName( fileNameAndPath ) + File.separatorChar + FilenameUtils.getName( fileNameAndPath ) ...but it is not more elegant than the current terminology and I still can't find anything better. =:o/ Cheers, Paulo Christoph Reck wrote: Paulo Gaspar wrote: And isn't it always simpler if the name of the method perfectly explains its functionality instead of relying on some convention? That was exactly the reason for my previous email. The function getPath() is already straightforward. Any element in a file system has a path - even directories. This is no convention, but a fact (which sometimes it needs a second thought to grasp). By adding getParentPath would also require renaming the sister function to getFullParentPath... :D and in the end, no one would understand the reason for such function names. So again, KISS! Cheers, Christoph P.S. This is my last comment to this issue, so not to inch into a flame thread :) (Ok, that is not always possible, but it IS in this case.) Regards, Paulo Christoph Reck wrote: Paulo Gaspar wrote: To complitelly avoid ambiguities, why not calling it getParentPath() instead? Keep it simple... Any file-system object (file or directory) has a name and a path to it. The simple rule is fileNameAndPath := FilenameUtils.getFullPath( fileNameAndPath ) + File.separatorChar + FilenameUtils.getName( fileNameAndPath ) := FilenameUtils.concat( FilenameUtils.getFullPath( fileNameAndPath ), FilenameUtils.getName( fileNameAndPath ) ) Is this agreable by everyone? Why compicate the matters? Notable is that a directory itself is positioned at a path location. Therefore FilenameUtils.getPath(pathToDirectory).length() pathToDirectory.length() Cheers, Christoph [snip] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 32350] - [chain] Consider making lookup commands default to same chain
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32350. 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=32350 --- Additional Comments From [EMAIL PROTECTED] 2004-11-30 00:52 --- OK. I see the problem. You are not requesting a default catalog name be used, you are concerned that using the default catalog will cause confusion because the user may expect the command to be found in the current catalog (as opposed to the default.) Perhaps the documentation for LookupCommand should be improved in order to warn the user of this potential pitfall? I am not sure how we could address your concern without causing confusion from the reverse scenario (where the user expects it be the default catalog and its not.) I will look at your ideas again (now that I understand the problem.) Also, I will see if I can't think of something myself. -- 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]
[jelly] documentation on all tags
Ok, the plan is to add a new collapsed menu item to the jelly home page called Tag Reference which will contain all the tags as items underneath it. For each tag, there will be a page similar to the ant task page with: - description - attributes - nested elements (if needed) - examples. Have a look at: http://www.apache.org/~dion/jelly/ and in particular click on 'Tag Reference' and see the first three entries ( ant:ant, ant:fileScanner, ant:setProperty ) and let me know about the format and content. Thanks in advance to all who provide input. On Mon, 29 Nov 2004 09:45:07 -0800, dan tran [EMAIL PROTECTED] wrote: Dion, Sure I will -D On Mon, 29 Nov 2004 14:53:13 +1100, Dion Gillard [EMAIL PROTECTED] wrote: Dan, would you be happy to review some docs as an example before I go too far with this? On Sun, 28 Nov 2004 15:01:38 -0800, dan tran [EMAIL PROTECTED] wrote: It is a huge improvement. Last time, I had to google jelly new argument and ended up at one of your blog entry. Then I make a leap of faith to place j:arg tag as a body of j:new tag ;-) My feed back here is to give example for each tag. -Dan On Mon, 29 Nov 2004 09:55:04 +1100, Dion Gillard [EMAIL PROTECTED] wrote: So if we had a frames style documentation of the taglibs and tags with more detail on the attributes and the usage, this would help? On Sun, 28 Nov 2004 14:39:49 -0800, dan tran [EMAIL PROTECTED] wrote: The tutorial is a big help at the web site. I am a Maven advocate at my comp, and one of the hardest thing trying to convince my collegue to use Maven is that they keep comparing jelly website and ant site where Ant has good user interface of documentation. It has example for every single public tag. But I think Jelly is great Thank you for all the good work. -Dan On Mon, 29 Nov 2004 09:26:36 +1100, Brett Porter [EMAIL PROTECTED] wrote: I think dan found the Jelly docs just fine as he found j:new. I think incorporating the Jelly tutorials into the Jelly website might be a good idea though. Cheers, Brett On Mon, 29 Nov 2004 09:19:01 +1100, Dion Gillard [EMAIL PROTECTED] wrote: Is there some way we could make the Jelly docs a little more obvious? There are some jelly tutorials on my blog, e.g. http://www.multitask.com.au/people/dion/archives/000192.html On Sun, 28 Nov 2004 14:02:34 -0800, dan tran [EMAIL PROTECTED] wrote: My appology, The answer is not obvious by using j:arg tag at the body of j:new tag -D On Sun, 28 Nov 2004 11:17:30 -0800, dan tran [EMAIL PROTECTED] wrote: Hello, I would like to construct new java object which requires an argument in its constructor (ex new TreeSet(myComparator)) How do I do that in Jelly? Please dont tell me to go to jelly group ;-) -Dan - 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] - 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/ -- http://www.multitask.com.au/people/dion/ -- http://www.multitask.com.au/people/dion/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [jelly] documentation on all tags
I like it. Could the list of tags also appear on the overview page? -Original Message- From: Dion Gillard [mailto:[EMAIL PROTECTED] Sent: Monday, November 29, 2004 6:54 PM To: dan tran; Jakarta Commons Developers List Subject: [jelly] documentation on all tags Ok, the plan is to add a new collapsed menu item to the jelly home page called Tag Reference which will contain all the tags as items underneath it. For each tag, there will be a page similar to the ant task page with: - description - attributes - nested elements (if needed) - examples. Have a look at: http://www.apache.org/~dion/jelly/ and in particular click on 'Tag Reference' and see the first three entries ( ant:ant, ant:fileScanner, ant:setProperty ) and let me know about the format and content. Thanks in advance to all who provide input. On Mon, 29 Nov 2004 09:45:07 -0800, dan tran [EMAIL PROTECTED] wrote: Dion, Sure I will -D On Mon, 29 Nov 2004 14:53:13 +1100, Dion Gillard [EMAIL PROTECTED] wrote: Dan, would you be happy to review some docs as an example before I go too far with this? On Sun, 28 Nov 2004 15:01:38 -0800, dan tran [EMAIL PROTECTED] wrote: It is a huge improvement. Last time, I had to google jelly new argument and ended up at one of your blog entry. Then I make a leap of faith to place j:arg tag as a body of j:new tag ;-) My feed back here is to give example for each tag. -Dan On Mon, 29 Nov 2004 09:55:04 +1100, Dion Gillard [EMAIL PROTECTED] wrote: So if we had a frames style documentation of the taglibs and tags with more detail on the attributes and the usage, this would help? On Sun, 28 Nov 2004 14:39:49 -0800, dan tran [EMAIL PROTECTED] wrote: The tutorial is a big help at the web site. I am a Maven advocate at my comp, and one of the hardest thing trying to convince my collegue to use Maven is that they keep comparing jelly website and ant site where Ant has good user interface of documentation. It has example for every single public tag. But I think Jelly is great Thank you for all the good work. -Dan On Mon, 29 Nov 2004 09:26:36 +1100, Brett Porter [EMAIL PROTECTED] wrote: I think dan found the Jelly docs just fine as he found j:new. I think incorporating the Jelly tutorials into the Jelly website might be a good idea though. Cheers, Brett On Mon, 29 Nov 2004 09:19:01 +1100, Dion Gillard [EMAIL PROTECTED] wrote: Is there some way we could make the Jelly docs a little more obvious? There are some jelly tutorials on my blog, e.g. http://www.multitask.com.au/people/dion/archives/000192.html On Sun, 28 Nov 2004 14:02:34 -0800, dan tran [EMAIL PROTECTED] wrote: My appology, The answer is not obvious by using j:arg tag at the body of j:new tag -D On Sun, 28 Nov 2004 11:17:30 -0800, dan tran [EMAIL PROTECTED] wrote: Hello, I would like to construct new java object which requires an argument in its constructor (ex new TreeSet(myComparator)) How do I do that in Jelly? Please dont tell me to go to jelly group ;-) -Dan - 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] - 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/ -- http://www.multitask.com.au/people/dion/ -- http://www.multitask.com.au/people/dion/ - 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: [jelly] documentation on all tags
It's a really long list. I'd be happier if it was in one place only. Or did you have some way of summarising it or shortening it? On Mon, 29 Nov 2004 19:31:26 -0500, Hans Gilde [EMAIL PROTECTED] wrote: I like it. Could the list of tags also appear on the overview page? -Original Message- From: Dion Gillard [mailto:[EMAIL PROTECTED] Sent: Monday, November 29, 2004 6:54 PM To: dan tran; Jakarta Commons Developers List Subject: [jelly] documentation on all tags Ok, the plan is to add a new collapsed menu item to the jelly home page called Tag Reference which will contain all the tags as items underneath it. For each tag, there will be a page similar to the ant task page with: - description - attributes - nested elements (if needed) - examples. Have a look at: http://www.apache.org/~dion/jelly/ and in particular click on 'Tag Reference' and see the first three entries ( ant:ant, ant:fileScanner, ant:setProperty ) and let me know about the format and content. Thanks in advance to all who provide input. On Mon, 29 Nov 2004 09:45:07 -0800, dan tran [EMAIL PROTECTED] wrote: Dion, Sure I will -D On Mon, 29 Nov 2004 14:53:13 +1100, Dion Gillard [EMAIL PROTECTED] wrote: Dan, would you be happy to review some docs as an example before I go too far with this? On Sun, 28 Nov 2004 15:01:38 -0800, dan tran [EMAIL PROTECTED] wrote: It is a huge improvement. Last time, I had to google jelly new argument and ended up at one of your blog entry. Then I make a leap of faith to place j:arg tag as a body of j:new tag ;-) My feed back here is to give example for each tag. -Dan On Mon, 29 Nov 2004 09:55:04 +1100, Dion Gillard [EMAIL PROTECTED] wrote: So if we had a frames style documentation of the taglibs and tags with more detail on the attributes and the usage, this would help? On Sun, 28 Nov 2004 14:39:49 -0800, dan tran [EMAIL PROTECTED] wrote: The tutorial is a big help at the web site. I am a Maven advocate at my comp, and one of the hardest thing trying to convince my collegue to use Maven is that they keep comparing jelly website and ant site where Ant has good user interface of documentation. It has example for every single public tag. But I think Jelly is great Thank you for all the good work. -Dan On Mon, 29 Nov 2004 09:26:36 +1100, Brett Porter [EMAIL PROTECTED] wrote: I think dan found the Jelly docs just fine as he found j:new. I think incorporating the Jelly tutorials into the Jelly website might be a good idea though. Cheers, Brett On Mon, 29 Nov 2004 09:19:01 +1100, Dion Gillard [EMAIL PROTECTED] wrote: Is there some way we could make the Jelly docs a little more obvious? There are some jelly tutorials on my blog, e.g. http://www.multitask.com.au/people/dion/archives/000192.html On Sun, 28 Nov 2004 14:02:34 -0800, dan tran [EMAIL PROTECTED] wrote: My appology, The answer is not obvious by using j:arg tag at the body of j:new tag -D On Sun, 28 Nov 2004 11:17:30 -0800, dan tran [EMAIL PROTECTED] wrote: Hello, I would like to construct new java object which requires an argument in its constructor (ex new TreeSet(myComparator)) How do I do that in Jelly? Please dont tell me to go to jelly group ;-) -Dan - 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] - 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/ -- http://www.multitask.com.au/people/dion/ -- http://www.multitask.com.au/people/dion/
cvs commit: jakarta-commons/digester/src/examples/api/dbinsert - New directory
skitching2004/11/29 18:25:20 jakarta-commons/digester/src/examples/api/dbinsert - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/digester/src/examples/api readme.txt
skitching2004/11/29 18:27:01 Modified:digester/src/examples/api readme.txt Log: Added info on new dbinsert example. Also added missing document-markup example. Revision ChangesPath 1.4 +3 -1 jakarta-commons/digester/src/examples/api/readme.txt Index: readme.txt === RCS file: /home/cvs/jakarta-commons/digester/src/examples/api/readme.txt,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- readme.txt9 Sep 2004 20:38:20 - 1.3 +++ readme.txt30 Nov 2004 02:27:01 - 1.4 @@ -29,4 +29,6 @@ The examples are graduated in the following order: 1. addressbook -2. catalog \ No newline at end of file +2. catalog +3. dbinsert +4. document-markup - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/digester/src/examples/api/dbinsert Main.java Row.java RowInserterRule.java Table.java build.xml example.xml readme.txt
skitching2004/11/29 18:38:24
Added: digester/src/examples/api/dbinsert Main.java Row.java
RowInserterRule.java Table.java build.xml
example.xml readme.txt
Log:
Added examples, inspired by Michael Schuerig.
Revision ChangesPath
1.1
jakarta-commons/digester/src/examples/api/dbinsert/Main.java
Index: Main.java
===
/*
* Copyright 2004 The Apache Software Foundation.
*
* Licensed under the Apache License, Version 2.0 (the License);
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an AS IS BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
import org.apache.commons.digester.Digester;
/**
* A simple program to demonstrate that the Commons Digester module can be
* used to trigger actions as the xml is parsed, rather than just build
* up in-memory representations of the parsed data. This example also shows
* how to write a custom Rule class.
* p
* This code will parse the provided example.xml file, and immediately
* insert the processed data into a database as each row tag is parsed,
* instead of building up an in-memory representation. Actually, in order
* to keep this example simple and easy to run, sql insert statements are
* printed out rather than actually performing database inserts, but the
* principle remains.
* p
* Very verbose comments are included here, as this class is intended
* as a tutorial; if you look closely at method addRules, you will
* see that the amount of code required to use the Digester is actually
* quite low.
* p
* Usage: java Main example.xml
*/
public class Main {
/**
* Main method : entry point for running this example program.
* p
* Usage: java Main example.xml
*/
public static void main(String[] args) {
if (args.length != 1) {
usage();
System.exit(-1);
}
String filename = args[0];
// Create a Digester instance
Digester d = new Digester();
// Here you would establish a real connection.
// There would also be a finally clause to ensure it is
// closed after parsing terminates, etc.
java.sql.Connection connection = null;
// Add rules to the digester that will be triggered while
// parsing occurs.
addRules(d, connection);
// Process the input file.
System.out.println(Parsing commencing...);
try {
java.io.File srcfile = new java.io.File(filename);
d.parse(srcfile);
}
catch(java.io.IOException ioe) {
System.out.println(Error reading input file: +
ioe.getMessage());
System.exit(-1);
}
catch(org.xml.sax.SAXException se) {
System.out.println(Error parsing input file: + se.getMessage());
System.exit(-1);
}
// And here there is nothing to do. The digester rules have
// (deliberately) not built a representation of the input, but
// instead processed the data as it was read.
System.out.println(Parsing complete.);
}
private static void addRules(Digester d, java.sql.Connection conn) {
//--
// when we encounter a table tag, do the following:
// Create a new instance of class Table, and push that
// object onto the digester stack of objects. We only need
// this so that when a row is inserted, it can find out what
// the enclosing tablename was.
//
// Note that the object is popped off the stack at the end of the
// table tag (normal behaviour for ObjectCreateRule). Because we
// never added the table object to some parent object, when it is
// popped off the digester stack it becomes garbage-collected. That
// is fine in this situation; we've done all the necessary work and
// don't need the table object any more.
d.addObjectCreate(database/table, Table.class);
// Map *any* attributes on the table tag to appropriate
// setter-methods on the top object on the stack (the Table
// instance created by the preceeding rule). We only expect one
cvs commit: jakarta-commons/digester/src/java/org/apache/commons/digester package.html
skitching2004/11/29 18:57:17 Modified:digester/src/java/org/apache/commons/digester package.html Log: Added information about using digester as a sax event handler. Revision ChangesPath 1.33 +12 -1 jakarta-commons/digester/src/java/org/apache/commons/digester/package.html Index: package.html === RCS file: /home/cvs/jakarta-commons/digester/src/java/org/apache/commons/digester/package.html,v retrieving revision 1.32 retrieving revision 1.33 diff -u -r1.32 -r1.33 --- package.html 7 Oct 2004 19:48:42 - 1.32 +++ package.html 30 Nov 2004 02:57:17 - 1.33 @@ -108,6 +108,17 @@ the processing rules./li /ul +pAlternatively a Digester may be used as a sax event hander, as follows:/p +ul +liCreate an instance of a sax parser (using the JAXP APIs or otherwise)./li +liSet any desired configuration properties on that parser object./li +liCreate an instance of codeorg.apache.commons.digester.Digester/code./li +liOptionally, push any desired initial object(s) onto the Digester's +a href=#doc.Stackobject stack/a./li +liRegister patterns and rules with the digester instance./li +liCall parser.parse(inputSource, digester)./li +/ul + pFor example code, see a href=#doc.Usage the usage examples/a, and a href=#doc.FAQ.Examples the FAQ /a. /p - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/digester/src/java/org/apache/commons/digester SetPropertyRule.java
skitching2004/11/29 19:06:27
Modified:digester/src/java/org/apache/commons/digester
SetPropertyRule.java
Log:
Added comment only (re PropertyUtils.isWriteable).
Revision ChangesPath
1.19 +4 -1
jakarta-commons/digester/src/java/org/apache/commons/digester/SetPropertyRule.java
Index: SetPropertyRule.java
===
RCS file:
/home/cvs/jakarta-commons/digester/src/java/org/apache/commons/digester/SetPropertyRule.java,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -r1.18 -r1.19
--- SetPropertyRule.java 10 May 2004 06:30:06 - 1.18
+++ SetPropertyRule.java 30 Nov 2004 03:06:27 - 1.19
@@ -130,6 +130,9 @@
// Force an exception if the property does not exist
// (BeanUtils.setProperty() silently returns in this case)
+//
+// This code should probably use PropertyUtils.isWriteable(),
+// like SetPropertiesRule does.
if (top instanceof DynaBean) {
DynaProperty desc =
((DynaBean) top).getDynaClass().getDynaProperty(actualName);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/digester/src/java/org/apache/commons/digester CallMethodRule.java CallParamRule.java
skitching2004/11/29 19:08:55
Modified:digester/src/java/org/apache/commons/digester
CallMethodRule.java CallParamRule.java
Log:
Added comments only, re behaviour when passing body of element and the
element is empty (empty string passed, not null).
Revision ChangesPath
1.36 +10 -3
jakarta-commons/digester/src/java/org/apache/commons/digester/CallMethodRule.java
Index: CallMethodRule.java
===
RCS file:
/home/cvs/jakarta-commons/digester/src/java/org/apache/commons/digester/CallMethodRule.java,v
retrieving revision 1.35
retrieving revision 1.36
diff -u -r1.35 -r1.36
--- CallMethodRule.java 10 May 2004 06:30:06 - 1.35
+++ CallMethodRule.java 30 Nov 2004 03:08:55 - 1.36
@@ -42,7 +42,7 @@
* This increases the kinds of methods successfully and allows primitives
* to be matched by passing in wrapper classes.
* There are rare cases when [EMAIL PROTECTED]
MethodUtils#invokeExactMethod}
- * (the old defualt) is required.
+ * (the old default) is required.
* This method is much stricter in it's reflection.
* Setting the codeUseExactMatch/code to true reverts to the use of this
* method./p
@@ -60,12 +60,19 @@
* not be invoked. If a CallMethodRule is expecting more than one parameter,
* then it is always invoked, regardless of whether the parameters were
* available or not (missing parameters are passed as null values)./p
+ *
+ * pNote that when a constructor is used with paramCount=0, indicating that
+ * the body of the element is to be passed to the target method, an empty
+ * element will cause an iempty string/i to be passed to the target
method,
+ * not null. And if automatic type conversion is being applied (ie if the
+ * target function takes something other than a string as a parameter) then
+ * the conversion will fail if the converter class does not accept an empty
+ * string as valid input./p
*/
public class CallMethodRule extends Rule {
// ---
Constructors
-
/**
* Construct a call method rule with the specified method name. The
1.23 +13 -1
jakarta-commons/digester/src/java/org/apache/commons/digester/CallParamRule.java
Index: CallParamRule.java
===
RCS file:
/home/cvs/jakarta-commons/digester/src/java/org/apache/commons/digester/CallParamRule.java,v
retrieving revision 1.22
retrieving revision 1.23
diff -u -r1.22 -r1.23
--- CallParamRule.java9 Sep 2004 20:38:21 - 1.22
+++ CallParamRule.java30 Nov 2004 03:08:55 - 1.23
@@ -51,6 +51,12 @@
* Construct a call parameter rule that will save the body text of this
* element as the parameter value.
*
+ * pNote that if the element is empty the an iempty string/i is
+ * passed to the target method, not null. And if automatic type
conversion
+ * is being applied (ie if the target function takes something other
than
+ * a string as a parameter) then the conversion will fail if the
converter
+ * class does not accept an empty string as valid input./p
+ *
* @param digester The associated Digester
* @param paramIndex The zero-relative parameter number
*
@@ -85,6 +91,12 @@
/**
* Construct a call parameter rule that will save the body text of this
* element as the parameter value.
+ *
+ * pNote that if the element is empty the an iempty string/i is
+ * passed to the target method, not null. And if automatic type
conversion
+ * is being applied (ie if the target function takes something other
than
+ * a string as a parameter) then the conversion will fail if the
converter
+ * class does not accept an empty string as valid input./p
*
* @param paramIndex The zero-relative parameter number
*/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 32441] New: - [DBCP] SQLException When PoolablePreparedStatement Already Closed
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32441. 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=32441 Summary: [DBCP] SQLException When PoolablePreparedStatement Already Closed Product: Commons Version: 1.2 Final Platform: All OS/Version: All Status: NEW Severity: minor Priority: P2 Component: Dbcp AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] When closing an already closed org.apache.commons.dbcp.PoolablePreparedStatement, a SQLException is thrown when the isClosed() method returns true. This seems to violate the contract of java.sql.Statement (super interface of implemented PreparedStatement) whose javadoc reads Calling the method close on a Statement object that is already closed has no effect. Work around exists -- when ever closing a statement, also null out. Then, before closing, check that it's non-null. -- 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: [email] Exceptions
Sounds good to me, I have a stack of things waiting for the next version.
Also I think most of the bugs have been cleared off by your recent
commits so there shouldnt be any reason to stop us from a RC1
-Corey
On Mon, 29 Nov 2004 19:01:00 +0100, Eric Pugh [EMAIL PROTECTED] wrote:
I've applied a stack of changes, including Mark's EmailException, to the
codebase. I don't really care much about how the unit tests look, as long
as the jcoverage keeps going up!
At this point, I think all the API changes are done, and my gut feeling is
that we should look to final testing, cut a Release Candidate and then roll
1.0. We should also start thinking about what the next version will entail.
Eric
-Original Message-
From: Mark Lowe [mailto:[EMAIL PROTECTED]
Sent: Monday, November 29, 2004 5:25 PM
To: Corey Scott
Cc: Jakarta Commons Developers List; [EMAIL PROTECTED]
Subject: Re: [email] Exceptions
Okay I'll take a look tommorrow and sumbit my patch with the test
cases in with the Other test methods.
Judging from you example, you agree that unexpected exceptions should
just get thrown and that exceptions should be tested independently to
normal tests, which all sounds good to me. Or am i wrong? If the
method isn't there to invoke an exception then if one happens then
surely just throw it, the fact that its unexpected will be evident by
virtue of the test failing due to errors.
Mark
On Tue, 30 Nov 2004 00:04:16 +0800, Corey Scott
[EMAIL PROTECTED] wrote:
This is exactly what I was trying to say, just not so elegantly :-)
Eg. Tests for the HtmlEmail class should be in teh HtmlEmailTest class
or is this becomes too big and you want to separate the exceptions,
then there should be two classes HtmlEmailTest (for normal test cases)
and HtmlEmailExceptionTest
-Corey
On Mon, 29 Nov 2004 16:59:29 +0100, Eric Pugh [EMAIL PROTECTED] wrote:
Humm... I typically make all my unit tests throw Exception.
It reduces
the length of each test, especially when all you are doing is
logging that
it failed with a fail(ex.getMessage).
However, if you are actually TESTING that an exception gets thrown:
try {
email.doSomething();
fail(should have thrown ee);
}
catch (EmailException ee){
assertTrue(ee.getMessage().indexOf(myerror)-1)
}
then I argue they should go in with whatever class we are
testing, because
when someone adds a new method to the class, it will
encourage them to add
the corresponding test case for any exeption. Or, put the
exception test
into the test.
public void testSomething() throws Exception{
email.doSomethign();
snip/
try {
email.doSomething();
fail(should have thrown ee);
}
catch (EmailException ee){
assertTrue(ee.getMessage().indexOf(myerror)-1)
}
}
That way everything stays together. If we aren't actually
asserting the
exception, then we shouldn't bother testing it..
Eric
-Original Message-
From: Mark Lowe [mailto:[EMAIL PROTECTED]
Sent: Monday, November 29, 2004 3:19 PM
To: Corey Scott
Cc: Jakarta Commons Developers List
Subject: Re: [email] Exceptions
My thoughts on the test cases are that they should throw exception,
and then have the exception testing separate. This would make the
cases shorter also, perhaps this is what you mean.
public void testFoo() throws Exception
{
Foo foo = new Foo();
foo.setBar(testvar);
}
For example, if for some reason the exception for setBar() was ever
changed the case could remain the same as before, and the
only change
would need to be in the exception test case.
Mark
On Mon, 29 Nov 2004 21:59:44 +0800, Corey Scott
[EMAIL PROTECTED] wrote:
I would prefer an Exception Test case per base class,
especially for
the larger files. I know most of the tests I wrote, but
I think that
if anything the files are too long and would be much more
usable if
they were shorter and more focused. Does anyone have any
objections
to gave more (but shorter) files?
-Corey
On Mon, 29 Nov 2004 14:17:30 +0100, Mark Lowe
[EMAIL PROTECTED] wrote:
I've created the exceptions and I'm now working through the
test cases.
If I summit a patch with the exception testing in a
ExceptionTestCase
what's the likelyhood of this being patched? This isn't
a question of
style its a question of maintainabilty and now, I'm
faced with the
task of weeding out all these try catch statements.
Any objection to a patch with these exception tests moved into a
specialised test case?
Mark
On
RE: [vote][math] Release Math 1.0
+1 Brent Worden -Original Message- From: Phil Steitz [mailto:[EMAIL PROTECTED] Sent: Saturday, November 27, 2004 10:32 AM To: Jakarta Commons Developers List Subject: [vote][math] Release Math 1.0 There have been no bug reports against commons-math-1.0-RC2, which has been out for a couple of weeks now. I propose that we release commons-math-1.0, based on CVS HEAD, tagged and renamed for 1.0. There have been no changes to [math] since 1.0-RC2 was cut, which is available here: http://www.apache.org/~psteitz/commons-math-1.0-RC2/dist/ Votes, please. Voting will last at least 72 hours. Thanks. --- [ ] +1 I support this release and am willing to help [ ] +0 I support this release but am unable to help [ ] -0 I do not support this release [ ] -1 I do not support this release, and here are my reasons --- Here is my +1. -- Phil Steitz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/digester/src/test/org/apache/commons/digester SetNestedPropertiesRuleTestCase.java
skitching2004/11/29 20:36:46
Modified:digester/src/test/org/apache/commons/digester
SetNestedPropertiesRuleTestCase.java
Log:
Added test case for bugzilla#31393, reported by James Pine.
SetNestedPropertiesRule fails when invoked re-entrantly.
Revision ChangesPath
1.4 +33 -1
jakarta-commons/digester/src/test/org/apache/commons/digester/SetNestedPropertiesRuleTestCase.java
Index: SetNestedPropertiesRuleTestCase.java
===
RCS file:
/home/cvs/jakarta-commons/digester/src/test/org/apache/commons/digester/SetNestedPropertiesRuleTestCase.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- SetNestedPropertiesRuleTestCase.java 7 May 2004 01:29:59 -
1.3
+++ SetNestedPropertiesRuleTestCase.java 30 Nov 2004 04:36:46 -
1.4
@@ -330,6 +330,38 @@
assertNotNull(bean);
}
+/**
+ * Test that the rule works in a sane manner when the associated pattern
+ * is a wildcard such that the rule matches one of its own child
elements.
+ * p
+ * See bugzilla entry 31393.
+ */
+public void testRecursiveNestedProperties()
+throws SAXException, IOException {
+
+String testXml =
+?xml version='1.0'? +
+testbean +
+betaBETA BODY/beta +
+testbean +
+betaBETA BODY/beta +
+/testbean +
+/testbean;
+
+Reader reader = new StringReader(testXml);
+
+// going to be setting properties on a SimpleTestBean
+digester.addObjectCreate(*/testbean,
+
org.apache.commons.digester.SimpleTestBean);
+
+SetNestedPropertiesRule rule = new SetNestedPropertiesRule();
+rule.setAllowUnknownChildElements(true);
+digester.addRule(*/testbean, rule);
+
+SimpleTestBean bean = (SimpleTestBean) digester.parse(reader);
+assertNotNull(bean);
+}
+
/**
* Get input stream from [EMAIL PROTECTED] #TEST_XML}.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/digester/src/java/org/apache/commons/digester SetNestedPropertiesRule.java
skitching2004/11/29 20:40:54
Modified:digester/src/java/org/apache/commons/digester
SetNestedPropertiesRule.java
Log:
Fix for bugzilla #31393, reported by James Pine. SetNestedPropertiesRule
failed when executed re-entrantly; removed over-zealous optimisation that
made it fail in that case (though it now runs slower in the usual case).
Revision ChangesPath
1.9 +45 -17
jakarta-commons/digester/src/java/org/apache/commons/digester/SetNestedPropertiesRule.java
Index: SetNestedPropertiesRule.java
===
RCS file:
/home/cvs/jakarta-commons/digester/src/java/org/apache/commons/digester/SetNestedPropertiesRule.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- SetNestedPropertiesRule.java 10 May 2004 06:52:50 - 1.8
+++ SetNestedPropertiesRule.java 30 Nov 2004 04:40:54 - 1.9
@@ -81,6 +81,11 @@
* underlying Rules implementation for the same pattern, so other rules
* are not disabled during processing of a SetNestedPropertiesRule./p
*
+ * pTODO: Optimise this class. Currently, each time begin is called,
+ * new AnyChildRules and AnyChildRule objects are created. It should be
+ * possible to cache these in normal use (though watch out for when a rule
+ * instance is invoked re-entrantly!)./p
+ *
* @since 1.6
*/
@@ -94,10 +99,6 @@
private Log log = null;
-private AnyChildRule anyChildRule = new AnyChildRule();
-private AnyChildRules newRules = new AnyChildRules(anyChildRule);
-private Rules oldRules = null;
-
private boolean trimData = true;
private boolean allowUnknownChildElements = false;
@@ -185,7 +186,6 @@
public void setDigester(Digester digester) {
super.setDigester(digester);
log = digester.getLogger();
-anyChildRule.setDigester(digester);
}
/**
@@ -203,8 +203,16 @@
}
/**
- * When set to true, any child element for which there is no
+ * Determines whether an error is reported when a nested element is
+ * encountered for which there is no corresponding property-setter
+ * method.
+ * p
+ * When set to false, any child element for which there is no
* corresponding object property will cause an error to be reported.
+ * p
+ * When set to false, any child element for which there is no
+ * corresponding object property will simply be ignored.
+ * p
* The default value of this attribute is false (not allowed).
*/
public void setAllowUnknownChildElements(boolean
allowUnknownChildElements) {
@@ -225,7 +233,10 @@
*/
public void begin(String namespace, String name, Attributes attributes)
throws Exception {
-oldRules = digester.getRules();
+Rules oldRules = digester.getRules();
+AnyChildRule anyChildRule = new AnyChildRule();
+anyChildRule.setDigester(digester);
+AnyChildRules newRules = new AnyChildRules(anyChildRule);
newRules.init(digester.getMatch()+/, oldRules);
digester.setRules(newRules);
}
@@ -236,7 +247,8 @@
* child-element-matching.
*/
public void body(String bodyText) throws Exception {
-digester.setRules(oldRules);
+AnyChildRules newRules = (AnyChildRules) digester.getRules();
+digester.setRules(newRules.getOldRules());
}
/**
@@ -293,21 +305,25 @@
(matchPath.indexOf('/', matchPrefix.length()) == -1)) {
// The current element is a direct child of the element
-// specified in the init method, so include it as the
-// first rule in the matches list. The way that
-// SetNestedPropertiesRule is used, it is in fact very
-// likely to be the only match, so we optimise that
-// solution by keeping a list with only the AnyChildRule
-// instance in it.
+// specified in the init method, so we want to ensure that
+// the rule passed to this object's constructor is included
+// in the returned list of matching rules.
if ((match == null || match.size()==0)) {
+// The real rules class doesn't have any matches for
+// the specified path, so we return a list containing
+// just one rule: the one passed to this object's
+// constructor.
return rules;
}
else {
-// it might not be safe to modify the returned list,
+
DO NOT REPLY [Bug 31393] - [digester] SetNestedPropertiesRule causes StackOverflowError
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31393. 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=31393 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-11-30 05:42 --- Well, I've committed the simple fix (remove the optimisations that were causing the problem). The downside is that it now runs more slowly in the normal usecase. I'll try to revisit this sometime to implement optimisation *correctly*, but in the meantime the rule does at least work correctly now when invoked re-entrantly. -- 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/jelly/xdocs/tag-reference - New directory
dion2004/11/29 21:01:09 jakarta-commons/jelly/xdocs/tag-reference - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/jelly/xdocs/tag-reference ant_setProperty.xml ant_ant.xml index.xml ant_fileScanner.xml template.xml
dion2004/11/29 21:01:13
Added: jelly/xdocs/tag-reference ant_setProperty.xml ant_ant.xml
index.xml ant_fileScanner.xml template.xml
Log:
Add initial tag ref prototype
Revision ChangesPath
1.1
jakarta-commons/jelly/xdocs/tag-reference/ant_setProperty.xml
Index: ant_setProperty.xml
===
?xml version=1.0?
!--
Copyright 2002,2004 The Apache Software Foundation.
Licensed under the Apache License, Version 2.0 (the License);
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an AS IS BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
--
document
properties
titleJelly Tag Reference (ant:setProperty)/title
/properties
body
section name=Home Page
pSee
a
href=http://jakarta.apache.org/commons/jelly/libs/ant/;http://jakarta.apache.org/commons/jelly/libs/ant//a
/p
/section
section name=Description
p
This tag sets an attribute of an Ant task or datatype if the given
value is not null. This is very useful in
allowing attributes of ant tasks to be set conditionally without ugly
if/then/else logic.
/p
/section
section name=Attributes
table
tr
thName/th
thDescription/th
thRequired/th
/tr
tr
tdname/td
tdThe name of the attribute of the ant task to set/td
tdYes/td
/tr
tr
tdvalue/td
tdThe value to give the attribute of the ant task/td
tdYes./td
/tr
tr
tddefault/td
tdThe default value to give the attribute of the ant task, if the
codevalue/code provided is null./td
tdNo/td
/tr
/table
/section
section name=Examples
p
This tag is strongalways/strong nested inside of another Ant
task, target or datatype.
/p
source![CDATA[
j:jelly xmlns:j=jelly:core xmlns:ant=jelly:ant
ant:javac
destdir=${maven.build.dest}
excludes=**/package.html
debug=${maven.compile.debug}
deprecation=${maven.compile.deprecation}
optimize=${maven.compile.optimize}
ant:setProperty name=encoding value=${maven.compile.encoding} /
ant:setProperty name=executable value=${maven.compile.executable} /
/ant:javac
/j:jelly
]]/source
/section
/body
/document
1.1 jakarta-commons/jelly/xdocs/tag-reference/ant_ant.xml
Index: ant_ant.xml
===
?xml version=1.0?
!--
Copyright 2002,2004 The Apache Software Foundation.
Licensed under the Apache License, Version 2.0 (the License);
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an AS IS BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
--
document
properties
titleJelly Tag Reference (ant:ant)/title
author email=[EMAIL PROTECTED]Dion Gillard/author
/properties
body
section name=Home Page
pSee
a
href=http://jakarta.apache.org/commons/jelly/libs/ant/;http://jakarta.apache.org/commons/jelly/libs/ant//a
/p
/section
section name=Description
p
This tag represents all a
href=http://ant.apache.org/manual/anttaskslist.html;Ant tasks/a, and
can create any a href=http://ant.apache.org/;Ant/a task, target
or datatype dynamically from the
tag name you use, e.g. lt;copygt;
/p
p
Any tag strongnot/strong defined in the Jelly tag library for Ant
is assumed to be an Ant task, target
or datatype. When Jelly tries to execute an undefined tag, it looks
for an Ant task, target or datatype to match
the tag name, and if found, matches the tag's attributes to the Ant
element's attributes, as Ant would.
/p
/section
section name=Examples
p
You never code this tag directly, instead you use
cvs commit: jakarta-commons/jelly/xdocs navigation.xml
dion2004/11/29 21:01:57 Modified:jelly/xdocs navigation.xml Log: Add initial tag ref prototype Revision ChangesPath 1.27 +411 -1jakarta-commons/jelly/xdocs/navigation.xml Index: navigation.xml === RCS file: /home/cvs/jakarta-commons/jelly/xdocs/navigation.xml,v retrieving revision 1.26 retrieving revision 1.27 diff -u -r1.26 -r1.27 --- navigation.xml7 Sep 2004 14:45:57 - 1.26 +++ navigation.xml30 Nov 2004 05:01:57 - 1.27 @@ -28,6 +28,211 @@ item name=Detail href=/overview.html/ item name=JellyDoc href=/jellydoc.html/ item name=Download href=http://www.ibiblio.org/maven/commons-jelly/distributions// + item name=Tag Reference href=/tag-reference/index.html collapse=true +item name=ant:ant href=/tag-reference/ant_ant.html/ +item name=ant:fileScanner href=/tag-reference/ant_fileScanner.html/ +item name=ant:setProperty href=/tag-reference/ant_setProperty.html/ +item name=antlr:antlr href=/tag-reference/template.html/ +item name=antlr:grammar href=/tag-reference/template.html/ +item name=bean:bean href=/tag-reference/template.html/ +item name=bean:beanProperty href=/tag-reference/template.html/ +item name=bean:beandef href=/tag-reference/template.html/ +item name=beanshell:script href=/tag-reference/template.html/ +item name=betwixt:introspector href=/tag-reference/template.html/ +item name=betwixt:parse href=/tag-reference/template.html/ +item name=bsf:script href=/tag-reference/template.html/ +item name=define:attribute href=/tag-reference/template.html/ +item name=define:bean href=/tag-reference/template.html/ +item name=define:classLoader href=/tag-reference/template.html/ +item name=define:dynaBean href=/tag-reference/template.html/ +item name=define:extend href=/tag-reference/template.html/ +item name=define:invoke href=/tag-reference/template.html/ +item name=define:invokeBody href=/tag-reference/template.html/ +item name=define:jellyBean href=/tag-reference/template.html/ +item name=define:script href=/tag-reference/template.html/ +item name=define:super href=/tag-reference/template.html/ +item name=define:tag href=/tag-reference/template.html/ +item name=define:taglib href=/tag-reference/template.html/ +item name=dynabean:dynabean href=/tag-reference/template.html/ +item name=dynabean:dynaclass href=/tag-reference/template.html/ +item name=dynabean:property href=/tag-reference/template.html/ +item name=dynabean:set href=/tag-reference/template.html/ +item name=email:email href=/tag-reference/template.html/ +item name=fmt:bundle href=/tag-reference/template.html/ +item name=fmt:formatDate href=/tag-reference/template.html/ +item name=fmt:message href=/tag-reference/template.html/ +item name=fmt:param href=/tag-reference/template.html/ +item name=fmt:setBundle href=/tag-reference/template.html/ +item name=fmt:setLocale href=/tag-reference/template.html/ +item name=fmt:setTimeZone href=/tag-reference/template.html/ +item name=fmt:timeZone href=/tag-reference/template.html/ +item name=html:parse href=/tag-reference/template.html/ +item name=http:body href=/tag-reference/template.html/ +item name=http:delete href=/tag-reference/template.html/ +item name=http:get href=/tag-reference/template.html/ +item name=http:head href=/tag-reference/template.html/ +item name=http:header href=/tag-reference/template.html/ +item name=http:multipartPost href=/tag-reference/template.html/ +item name=http:options href=/tag-reference/template.html/ +item name=http:parameter href=/tag-reference/template.html/ +item name=http:part href=/tag-reference/template.html/ +item name=http:post
cvs commit: jakarta-commons/jelly/xdocs/tag-reference index.xml
dion2004/11/29 21:03:33 Modified:jelly/xdocs/tag-reference index.xml Log: add simple statement about list Revision ChangesPath 1.2 +4 -0 jakarta-commons/jelly/xdocs/tag-reference/index.xml Index: index.xml === RCS file: /home/cvs/jakarta-commons/jelly/xdocs/tag-reference/index.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- index.xml 30 Nov 2004 05:01:13 - 1.1 +++ index.xml 30 Nov 2004 05:03:33 - 1.2 @@ -28,6 +28,10 @@ This tag reference details all tags available for Jelly along with an example of it's usage. /p + p +!-- insert hans or other list here -- +Please select a tag on the navigation list for more information about that tag. + /p /section /body /document - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/jelly/xdocs/tag-reference example.xml template.xml
dion2004/11/29 21:13:21 Added: jelly/xdocs/tag-reference example.xml Removed: jelly/xdocs/tag-reference template.xml Log: xdoc doesn't like template.xml Revision ChangesPath 1.1 jakarta-commons/jelly/xdocs/tag-reference/example.xml Index: example.xml === ?xml version=1.0? !-- Copyright 2002,2004 The Apache Software Foundation. Licensed under the Apache License, Version 2.0 (the License); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. -- document properties titleJelly Tag Reference (taglib:tag)/title /properties body section name=Home Page pSee a href=http://jakarta.apache.org/commons/jelly/libs/xxx/;http://jakarta.apache.org/commons/jelly/libs/xxx//a /p /section section name=Description /section section name=Attributes table tr thName/th thDescription/th thRequired/th /tr tr td.../td td.../td td.../td /tr /table /section section name=Nested Elements /section section name=Examples source![CDATA[ ... ]]/source /section /body /document - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/jelly/xdocs navigation.xml
dion2004/11/29 21:13:29 Modified:jelly/xdocs navigation.xml Log: xdoc doesn't like template.xml Revision ChangesPath 1.28 +200 -200 jakarta-commons/jelly/xdocs/navigation.xml Index: navigation.xml === RCS file: /home/cvs/jakarta-commons/jelly/xdocs/navigation.xml,v retrieving revision 1.27 retrieving revision 1.28 diff -u -r1.27 -r1.28 --- navigation.xml30 Nov 2004 05:01:57 - 1.27 +++ navigation.xml30 Nov 2004 05:13:29 - 1.28 @@ -32,206 +32,206 @@ item name=ant:ant href=/tag-reference/ant_ant.html/ item name=ant:fileScanner href=/tag-reference/ant_fileScanner.html/ item name=ant:setProperty href=/tag-reference/ant_setProperty.html/ -item name=antlr:antlr href=/tag-reference/template.html/ -item name=antlr:grammar href=/tag-reference/template.html/ -item name=bean:bean href=/tag-reference/template.html/ -item name=bean:beanProperty href=/tag-reference/template.html/ -item name=bean:beandef href=/tag-reference/template.html/ -item name=beanshell:script href=/tag-reference/template.html/ -item name=betwixt:introspector href=/tag-reference/template.html/ -item name=betwixt:parse href=/tag-reference/template.html/ -item name=bsf:script href=/tag-reference/template.html/ -item name=define:attribute href=/tag-reference/template.html/ -item name=define:bean href=/tag-reference/template.html/ -item name=define:classLoader href=/tag-reference/template.html/ -item name=define:dynaBean href=/tag-reference/template.html/ -item name=define:extend href=/tag-reference/template.html/ -item name=define:invoke href=/tag-reference/template.html/ -item name=define:invokeBody href=/tag-reference/template.html/ -item name=define:jellyBean href=/tag-reference/template.html/ -item name=define:script href=/tag-reference/template.html/ -item name=define:super href=/tag-reference/template.html/ -item name=define:tag href=/tag-reference/template.html/ -item name=define:taglib href=/tag-reference/template.html/ -item name=dynabean:dynabean href=/tag-reference/template.html/ -item name=dynabean:dynaclass href=/tag-reference/template.html/ -item name=dynabean:property href=/tag-reference/template.html/ -item name=dynabean:set href=/tag-reference/template.html/ -item name=email:email href=/tag-reference/template.html/ -item name=fmt:bundle href=/tag-reference/template.html/ -item name=fmt:formatDate href=/tag-reference/template.html/ -item name=fmt:message href=/tag-reference/template.html/ -item name=fmt:param href=/tag-reference/template.html/ -item name=fmt:setBundle href=/tag-reference/template.html/ -item name=fmt:setLocale href=/tag-reference/template.html/ -item name=fmt:setTimeZone href=/tag-reference/template.html/ -item name=fmt:timeZone href=/tag-reference/template.html/ -item name=html:parse href=/tag-reference/template.html/ -item name=http:body href=/tag-reference/template.html/ -item name=http:delete href=/tag-reference/template.html/ -item name=http:get href=/tag-reference/template.html/ -item name=http:head href=/tag-reference/template.html/ -item name=http:header href=/tag-reference/template.html/ -item name=http:multipartPost href=/tag-reference/template.html/ -item name=http:options href=/tag-reference/template.html/ -item name=http:parameter href=/tag-reference/template.html/ -item name=http:part href=/tag-reference/template.html/ -item name=http:post href=/tag-reference/template.html/ -item name=http:put href=/tag-reference/template.html/ -item name=http:session href=/tag-reference/template.html/ -item name=interaction:ask href=/tag-reference/template.html/ -item
cvs commit: jakarta-commons/jelly/xdocs navigation.xml
dion2004/11/29 21:14:30 Modified:jelly/xdocs navigation.xml Log: Remove dupe Revision ChangesPath 1.29 +0 -205jakarta-commons/jelly/xdocs/navigation.xml Index: navigation.xml === RCS file: /home/cvs/jakarta-commons/jelly/xdocs/navigation.xml,v retrieving revision 1.28 retrieving revision 1.29 diff -u -r1.28 -r1.29 --- navigation.xml30 Nov 2004 05:13:29 - 1.28 +++ navigation.xml30 Nov 2004 05:14:30 - 1.29 @@ -240,211 +240,6 @@ item name=Powered By href=/powered.html/ item name=To Do List href=/todo.html/ /menu -item name=Tag Reference href=/tag-reference/index.html collapse=true - item name=ant:ant href=/tag-reference/ant_ant.html/ - item name=ant:fileScanner href=/tag-reference/ant_fileScanner.html/ - item name=ant:setProperty href=/tag-reference/ant_setProperty.html/ - item name=antlr:antlr href=/tag-reference/template.html/ - item name=antlr:grammar href=/tag-reference/template.html/ - item name=bean:bean href=/tag-reference/template.html/ - item name=bean:beanProperty href=/tag-reference/template.html/ - item name=bean:beandef href=/tag-reference/template.html/ - item name=beanshell:script href=/tag-reference/template.html/ - item name=betwixt:introspector href=/tag-reference/template.html/ - item name=betwixt:parse href=/tag-reference/template.html/ - item name=bsf:script href=/tag-reference/template.html/ - item name=define:attribute href=/tag-reference/template.html/ - item name=define:bean href=/tag-reference/template.html/ - item name=define:classLoader href=/tag-reference/template.html/ - item name=define:dynaBean href=/tag-reference/template.html/ - item name=define:extend href=/tag-reference/template.html/ - item name=define:invoke href=/tag-reference/template.html/ - item name=define:invokeBody href=/tag-reference/template.html/ - item name=define:jellyBean href=/tag-reference/template.html/ - item name=define:script href=/tag-reference/template.html/ - item name=define:super href=/tag-reference/template.html/ - item name=define:tag href=/tag-reference/template.html/ - item name=define:taglib href=/tag-reference/template.html/ - item name=dynabean:dynabean href=/tag-reference/template.html/ - item name=dynabean:dynaclass href=/tag-reference/template.html/ - item name=dynabean:property href=/tag-reference/template.html/ - item name=dynabean:set href=/tag-reference/template.html/ - item name=email:email href=/tag-reference/template.html/ - item name=fmt:bundle href=/tag-reference/template.html/ - item name=fmt:formatDate href=/tag-reference/template.html/ - item name=fmt:message href=/tag-reference/template.html/ - item name=fmt:param href=/tag-reference/template.html/ - item name=fmt:setBundle href=/tag-reference/template.html/ - item name=fmt:setLocale href=/tag-reference/template.html/ - item name=fmt:setTimeZone href=/tag-reference/template.html/ - item name=fmt:timeZone href=/tag-reference/template.html/ - item name=html:parse href=/tag-reference/template.html/ - item name=http:body href=/tag-reference/template.html/ - item name=http:delete href=/tag-reference/template.html/ - item name=http:get href=/tag-reference/template.html/ - item name=http:head href=/tag-reference/template.html/ - item name=http:header href=/tag-reference/template.html/ - item name=http:multipartPost href=/tag-reference/template.html/ - item name=http:options href=/tag-reference/template.html/ - item name=http:parameter href=/tag-reference/template.html/ - item name=http:part href=/tag-reference/template.html/ - item name=http:post href=/tag-reference/template.html/ - item name=http:put href=/tag-reference/template.html/ - item name=http:session href=/tag-reference/template.html/ - item
[GUMP@brutus]: Project commons-jelly-tags-antlr (in module jelly-tags) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-jelly-tags-antlr has an issue affecting its community integration. This issue affects 1 projects. The current state of this project is 'Failed', with reason 'Configuration Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-antlr : This is a Jelly interface for Antlr. Full details are available at: http://brutus.apache.org/gump/public/jelly-tags/commons-jelly-tags-antlr/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-jelly-tags-antlr-29112004.jar] identifier set to project name -INFO- Failed with reason configuration failed -ERROR- Bad Dependency. Project: commons-jelly unknown to *this* workspace -DEBUG- Extracted fallback artifacts from Gump Repository To subscribe to this information via syndicated feeds: - RSS: http://brutus.apache.org/gump/public/jelly-tags/commons-jelly-tags-antlr/rss.xml - Atom: http://brutus.apache.org/gump/public/jelly-tags/commons-jelly-tags-antlr/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 18002129112004, brutus:brutus-public:18002129112004 Gump E-mail Identifier (unique within run) #1. -- Apache Gump http://gump.apache.org/ [Instance: brutus] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[GUMP@brutus]: Project commons-jelly-tags-http (in module jelly-tags) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-jelly-tags-http has an issue affecting its community integration. This issue affects 1 projects. The current state of this project is 'Failed', with reason 'Configuration Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-http : These Jelly tags provide a simple XML syntax for HttpClient. Full details are available at: http://brutus.apache.org/gump/public/jelly-tags/commons-jelly-tags-http/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-jelly-tags-http-29112004.jar] identifier set to project name -INFO- Failed with reason configuration failed -ERROR- Bad Dependency. Project: commons-jelly unknown to *this* workspace -ERROR- Bad Dependency. Project: commons-httpclient unknown to *this* workspace -DEBUG- Extracted fallback artifacts from Gump Repository To subscribe to this information via syndicated feeds: - RSS: http://brutus.apache.org/gump/public/jelly-tags/commons-jelly-tags-http/rss.xml - Atom: http://brutus.apache.org/gump/public/jelly-tags/commons-jelly-tags-http/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 18002129112004, brutus:brutus-public:18002129112004 Gump E-mail Identifier (unique within run) #2. -- Apache Gump http://gump.apache.org/ [Instance: brutus] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[GUMP@brutus]: Project commons-jelly-tags-swing (in module jelly-tags) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-jelly-tags-swing has an issue affecting its community integration. This issue affects 1 projects. The current state of this project is 'Failed', with reason 'Configuration Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-swing : This is a Jelly interface for configuring Swing applications... Full details are available at: http://brutus.apache.org/gump/public/jelly-tags/commons-jelly-tags-swing/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-jelly-tags-swing-29112004.jar] identifier set to project name -INFO- Failed with reason configuration failed -ERROR- Bad Dependency. Project: commons-jelly unknown to *this* workspace -DEBUG- Extracted fallback artifacts from Gump Repository To subscribe to this information via syndicated feeds: - RSS: http://brutus.apache.org/gump/public/jelly-tags/commons-jelly-tags-swing/rss.xml - Atom: http://brutus.apache.org/gump/public/jelly-tags/commons-jelly-tags-swing/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 18002129112004, brutus:brutus-public:18002129112004 Gump E-mail Identifier (unique within run) #3. -- Apache Gump http://gump.apache.org/ [Instance: brutus] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[GUMP@brutus]: Project commons-jelly-tags-email (in module jelly-tags) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-jelly-tags-email has an issue affecting its community integration. This issue affects 1 projects. The current state of this project is 'Failed', with reason 'Configuration Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-email : This is a Jelly interface for Email Full details are available at: http://brutus.apache.org/gump/public/jelly-tags/commons-jelly-tags-email/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-jelly-tags-email-29112004.jar] identifier set to project name -INFO- Failed with reason configuration failed -ERROR- Bad Dependency. Project: commons-jelly unknown to *this* workspace -DEBUG- Extracted fallback artifacts from Gump Repository To subscribe to this information via syndicated feeds: - RSS: http://brutus.apache.org/gump/public/jelly-tags/commons-jelly-tags-email/rss.xml - Atom: http://brutus.apache.org/gump/public/jelly-tags/commons-jelly-tags-email/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 18002129112004, brutus:brutus-public:18002129112004 Gump E-mail Identifier (unique within run) #4. -- Apache Gump http://gump.apache.org/ [Instance: brutus] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[GUMP@brutus]: Project commons-jelly-tags-interaction (in module jelly-tags) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-jelly-tags-interaction has an issue affecting its community integration. This issue affects 1 projects. The current state of this project is 'Failed', with reason 'Configuration Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-interaction : This is a Jelly interface to the user. Full details are available at: http://brutus.apache.org/gump/public/jelly-tags/commons-jelly-tags-interaction/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-jelly-tags-interaction-29112004.jar] identifier set to project name -INFO- Failed with reason configuration failed -ERROR- Bad Dependency. Project: commons-jelly unknown to *this* workspace -DEBUG- Extracted fallback artifacts from Gump Repository To subscribe to this information via syndicated feeds: - RSS: http://brutus.apache.org/gump/public/jelly-tags/commons-jelly-tags-interaction/rss.xml - Atom: http://brutus.apache.org/gump/public/jelly-tags/commons-jelly-tags-interaction/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 18002129112004, brutus:brutus-public:18002129112004 Gump E-mail Identifier (unique within run) #5. -- Apache Gump http://gump.apache.org/ [Instance: brutus] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[GUMP@brutus]: Project commons-jelly-tags-swt (in module jelly-tags) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-jelly-tags-swt has an issue affecting its community integration. This issue affects 1 projects. The current state of this project is 'Failed', with reason 'Configuration Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-swt : This is a Jelly interface for configuring Swing applications... Full details are available at: http://brutus.apache.org/gump/public/jelly-tags/commons-jelly-tags-swt/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-jelly-tags-swt-29112004.jar] identifier set to project name -INFO- Failed with reason configuration failed -ERROR- Bad Dependency. Project: commons-jelly unknown to *this* workspace -DEBUG- Extracted fallback artifacts from Gump Repository To subscribe to this information via syndicated feeds: - RSS: http://brutus.apache.org/gump/public/jelly-tags/commons-jelly-tags-swt/rss.xml - Atom: http://brutus.apache.org/gump/public/jelly-tags/commons-jelly-tags-swt/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 18002129112004, brutus:brutus-public:18002129112004 Gump E-mail Identifier (unique within run) #6. -- Apache Gump http://gump.apache.org/ [Instance: brutus] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[GUMP@brutus]: Project commons-id (in module jakarta-commons-sandbox) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-id has an issue affecting its community integration. This issue affects 1 projects. The current state of this project is 'Failed', with reason 'Configuration Failed'. For reference only, the following projects are affected by this: - commons-id : Commons Identifier Package Full details are available at: http://brutus.apache.org/gump/public/jakarta-commons-sandbox/commons-id/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-id-29112004.jar] identifier set to project name -INFO- Failed with reason configuration failed -ERROR- Bad Dependency. Project: commons-discovery unknown to *this* workspace -ERROR- Bad Dependency. Project: commons-logging unknown to *this* workspace -ERROR- Bad Dependency. Project: commons-codec unknown to *this* workspace -DEBUG- Extracted fallback artifacts from Gump Repository To subscribe to this information via syndicated feeds: - RSS: http://brutus.apache.org/gump/public/jakarta-commons-sandbox/commons-id/rss.xml - Atom: http://brutus.apache.org/gump/public/jakarta-commons-sandbox/commons-id/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 18002129112004, brutus:brutus-public:18002129112004 Gump E-mail Identifier (unique within run) #7. -- Apache Gump http://gump.apache.org/ [Instance: brutus] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[GUMP@brutus]: Project commons-jelly-tags-junit (in module jelly-tags) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-jelly-tags-junit has an issue affecting its community integration. This issue affects 1 projects. The current state of this project is 'Failed', with reason 'Configuration Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-junit : The Jelly Unit Test Tags Full details are available at: http://brutus.apache.org/gump/public/jelly-tags/commons-jelly-tags-junit/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-jelly-tags-junit-29112004.jar] identifier set to project name -INFO- Failed with reason configuration failed -ERROR- Bad Dependency. Project: commons-jelly unknown to *this* workspace -DEBUG- Extracted fallback artifacts from Gump Repository To subscribe to this information via syndicated feeds: - RSS: http://brutus.apache.org/gump/public/jelly-tags/commons-jelly-tags-junit/rss.xml - Atom: http://brutus.apache.org/gump/public/jelly-tags/commons-jelly-tags-junit/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 18002129112004, brutus:brutus-public:18002129112004 Gump E-mail Identifier (unique within run) #8. -- Apache Gump http://gump.apache.org/ [Instance: brutus] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[GUMP@brutus]: Project commons-jelly-tags-log (in module jelly-tags) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-jelly-tags-log has an issue affecting its community integration. This issue affects 1 projects. The current state of this project is 'Failed', with reason 'Configuration Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-log : The Jelly Logging Tags Full details are available at: http://brutus.apache.org/gump/public/jelly-tags/commons-jelly-tags-log/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-jelly-tags-log-29112004.jar] identifier set to project name -INFO- Failed with reason configuration failed -ERROR- Bad Dependency. Project: commons-jelly unknown to *this* workspace -DEBUG- Extracted fallback artifacts from Gump Repository To subscribe to this information via syndicated feeds: - RSS: http://brutus.apache.org/gump/public/jelly-tags/commons-jelly-tags-log/rss.xml - Atom: http://brutus.apache.org/gump/public/jelly-tags/commons-jelly-tags-log/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 18002129112004, brutus:brutus-public:18002129112004 Gump E-mail Identifier (unique within run) #9. -- Apache Gump http://gump.apache.org/ [Instance: brutus] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[GUMP@brutus]: Project commons-jelly-tags-betwixt (in module jelly-tags) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-jelly-tags-betwixt has an issue affecting its community integration. This issue affects 1 projects. The current state of this project is 'Failed', with reason 'Configuration Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-betwixt : This is a Jelly interface for Betwixt. Full details are available at: http://brutus.apache.org/gump/public/jelly-tags/commons-jelly-tags-betwixt/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-jelly-tags-betwixt-29112004.jar] identifier set to project name -INFO- Failed with reason configuration failed -ERROR- Bad Dependency. Project: commons-jelly unknown to *this* workspace -ERROR- Bad Dependency. Project: commons-betwixt unknown to *this* workspace -ERROR- Bad Dependency. Project: commons-digester unknown to *this* workspace -ERROR- Bad Dependency. Project: commons-digester-rss unknown to *this* workspace -DEBUG- Extracted fallback artifacts from Gump Repository To subscribe to this information via syndicated feeds: - RSS: http://brutus.apache.org/gump/public/jelly-tags/commons-jelly-tags-betwixt/rss.xml - Atom: http://brutus.apache.org/gump/public/jelly-tags/commons-jelly-tags-betwixt/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 18002129112004, brutus:brutus-public:18002129112004 Gump E-mail Identifier (unique within run) #10. -- Apache Gump http://gump.apache.org/ [Instance: brutus] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[GUMP@brutus]: Project commons-jelly-tags-dynabean (in module jelly-tags) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-jelly-tags-dynabean has an issue affecting its community integration. This issue affects 1 projects. The current state of this project is 'Failed', with reason 'Configuration Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-dynabean : This is a Jelly taglib for defining new tags and tag librari... Full details are available at: http://brutus.apache.org/gump/public/jelly-tags/commons-jelly-tags-dynabean/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-jelly-tags-dynabean-29112004.jar] identifier set to project name -INFO- Failed with reason configuration failed -ERROR- Bad Dependency. Project: commons-jelly unknown to *this* workspace -DEBUG- Extracted fallback artifacts from Gump Repository To subscribe to this information via syndicated feeds: - RSS: http://brutus.apache.org/gump/public/jelly-tags/commons-jelly-tags-dynabean/rss.xml - Atom: http://brutus.apache.org/gump/public/jelly-tags/commons-jelly-tags-dynabean/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 18002129112004, brutus:brutus-public:18002129112004 Gump E-mail Identifier (unique within run) #11. -- Apache Gump http://gump.apache.org/ [Instance: brutus] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[GUMP@brutus]: Project commons-jelly-tags-jetty (in module jelly-tags) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-jelly-tags-jetty has an issue affecting its community integration. This issue affects 1 projects. The current state of this project is 'Failed', with reason 'Configuration Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-jetty : These are Jelly tags that can set up an in-process web serve... Full details are available at: http://brutus.apache.org/gump/public/jelly-tags/commons-jelly-tags-jetty/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-jelly-tags-jetty-29112004.jar] identifier set to project name -INFO- Failed with reason configuration failed -ERROR- Bad Dependency. Project: commons-jelly unknown to *this* workspace -ERROR- Bad Dependency. Project: commons-httpclient unknown to *this* workspace -DEBUG- Extracted fallback artifacts from Gump Repository To subscribe to this information via syndicated feeds: - RSS: http://brutus.apache.org/gump/public/jelly-tags/commons-jelly-tags-jetty/rss.xml - Atom: http://brutus.apache.org/gump/public/jelly-tags/commons-jelly-tags-jetty/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 18002129112004, brutus:brutus-public:18002129112004 Gump E-mail Identifier (unique within run) #12. -- Apache Gump http://gump.apache.org/ [Instance: brutus] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[GUMP@brutus]: Project commons-jelly-tags-sql (in module jelly-tags) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-jelly-tags-sql has an issue affecting its community integration. This issue affects 1 projects. The current state of this project is 'Failed', with reason 'Configuration Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-sql : This is a Jelly interface for SQL Full details are available at: http://brutus.apache.org/gump/public/jelly-tags/commons-jelly-tags-sql/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-jelly-tags-sql-29112004.jar] identifier set to project name -INFO- Failed with reason configuration failed -ERROR- Bad Dependency. Project: commons-jelly unknown to *this* workspace -DEBUG- Extracted fallback artifacts from Gump Repository To subscribe to this information via syndicated feeds: - RSS: http://brutus.apache.org/gump/public/jelly-tags/commons-jelly-tags-sql/rss.xml - Atom: http://brutus.apache.org/gump/public/jelly-tags/commons-jelly-tags-sql/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 18002129112004, brutus:brutus-public:18002129112004 Gump E-mail Identifier (unique within run) #13. -- Apache Gump http://gump.apache.org/ [Instance: brutus] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[GUMP@brutus]: Project commons-jelly-tags-util (in module jelly-tags) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-jelly-tags-util has an issue affecting its community integration. This issue affects 1 projects. The current state of this project is 'Failed', with reason 'Configuration Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-util : This is a set of Jelly utility tags. Full details are available at: http://brutus.apache.org/gump/public/jelly-tags/commons-jelly-tags-util/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-jelly-tags-util-29112004.jar] identifier set to project name -INFO- Failed with reason configuration failed -ERROR- Bad Dependency. Project: commons-jelly unknown to *this* workspace -ERROR- Bad Dependency. Project: commons-beanutils unknown to *this* workspace -ERROR- Bad Dependency. Project: commons-beanutils-bean-collections unknown to *this* workspace -DEBUG- Extracted fallback artifacts from Gump Repository To subscribe to this information via syndicated feeds: - RSS: http://brutus.apache.org/gump/public/jelly-tags/commons-jelly-tags-util/rss.xml - Atom: http://brutus.apache.org/gump/public/jelly-tags/commons-jelly-tags-util/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 18002129112004, brutus:brutus-public:18002129112004 Gump E-mail Identifier (unique within run) #14. -- Apache Gump http://gump.apache.org/ [Instance: brutus] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[GUMP@brutus]: Project commons-jelly-tags-bean (in module jelly-tags) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-jelly-tags-bean has an issue affecting its community integration. This issue affects 1 projects. The current state of this project is 'Failed', with reason 'Configuration Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-bean : A tag library for mapping tags to beans using a similar appr... Full details are available at: http://brutus.apache.org/gump/public/jelly-tags/commons-jelly-tags-bean/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-jelly-tags-bean-29112004.jar] identifier set to project name -INFO- Failed with reason configuration failed -ERROR- Bad Dependency. Project: commons-jelly unknown to *this* workspace -DEBUG- Extracted fallback artifacts from Gump Repository To subscribe to this information via syndicated feeds: - RSS: http://brutus.apache.org/gump/public/jelly-tags/commons-jelly-tags-bean/rss.xml - Atom: http://brutus.apache.org/gump/public/jelly-tags/commons-jelly-tags-bean/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 18002129112004, brutus:brutus-public:18002129112004 Gump E-mail Identifier (unique within run) #15. -- Apache Gump http://gump.apache.org/ [Instance: brutus] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
