[jira] Created: (LANG-313) Wrong behavior of Entities.unescape
Wrong behavior of Entities.unescape
---
Key: LANG-313
URL: https://issues.apache.org/jira/browse/LANG-313
Project: Commons Lang
Issue Type: Bug
Affects Versions: 2.2, 2.1
Reporter: Thiago Souza
Fix For: 2.3
Hi,
There's seems to be a bug at Entities.unescape. Try for example
StringEscapeUtils.unescapeHtml("& &"). It outputs "& &" instead of "&
&". The problem is at this piece of code:
if (entityValue == -1) {
buf.append('&');
buf.append(entityName);
buf.append(';');
} else {
buf.append((char) (entityValue));
}
i = semi;
The method always skips to the next ";", even if it doesn't finds the
entity value and then disregarding any entity that may be actually be referred
inside.
Regards,
Thiago Souza
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jelly] webstartable generic jelly
is something I just managed and it is real easy, to my surprise it even works with ant. Now that there's java web start 1.5 (and JNLP 1.5), it might be useful to make: - a command-line generic jelly that starts in the current directory and runs run.jelly or another one given as parameter (note: this outputs nothing in the console, it could output to a current-dir log-file) - a file-extension association so that double-clicked jelly file (unless otherwise instructed) could be run by this application Worth comitting into the jelly tree ? paul smime.p7s Description: S/MIME Cryptographic Signature
svn commit: r496498 - in /jakarta/commons/proper/configuration/trunk/src: java/org/apache/commons/configuration/DatabaseConfiguration.java test/org/apache/commons/configuration/TestDatabaseConfigurati
Author: oheger
Date: Mon Jan 15 13:23:58 2007
New Revision: 496498
URL: http://svn.apache.org/viewvc?view=rev&rev=496498
Log:
CONFIGURATION-245: DatabaseConfiguration will now generate error events in case
on an internal error.
Modified:
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/DatabaseConfiguration.java
jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestDatabaseConfiguration.java
Modified:
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/DatabaseConfiguration.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/DatabaseConfiguration.java?view=diff&rev=496498&r1=496497&r2=496498
==
---
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/DatabaseConfiguration.java
(original)
+++
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/DatabaseConfiguration.java
Mon Jan 15 13:23:58 2007
@@ -79,6 +79,7 @@
this.valueColumn = valueColumn;
this.name = name;
setLogger(LogFactory.getLog(getClass()));
+addErrorLogListener(); // log errors per default
}
/**
@@ -95,7 +96,14 @@
}
/**
- * [EMAIL PROTECTED]
+ * Returns the value of the specified property. If this causes a database
+ * error, an error event will be generated of type
+ * EVENT_READ_PROPERTY with the causing exception. The
+ * event's propertyName is set to the passed in property key,
+ * the propertyValue is undefined.
+ *
+ * @param key the key of the desired property
+ * @return the value of this property
*/
public Object getProperty(String key)
{
@@ -113,7 +121,7 @@
try
{
-conn = datasource.getConnection();
+conn = getConnection();
// bind the parameters
pstmt = conn.prepareStatement(query.toString());
@@ -145,7 +153,7 @@
}
catch (SQLException e)
{
-getLogger().error(e.getMessage(), e);
+fireError(EVENT_READ_PROPERTY, key, null, e);
}
finally
{
@@ -156,7 +164,14 @@
}
/**
- * [EMAIL PROTECTED]
+ * Adds a property to this configuration. If this causes a database error,
+ * an error event will be generated of type EVENT_ADD_PROPERTY
+ * with the causing exception. The event's propertyName is
+ * set to the passed in property key, the propertyValue
+ * points to the passed in value.
+ *
+ * @param key the property key
+ * @param obj the value of the property to add
*/
protected void addPropertyDirect(String key, Object obj)
{
@@ -176,7 +191,7 @@
try
{
-conn = datasource.getConnection();
+conn = getConnection();
// bind the parameters
pstmt = conn.prepareStatement(query.toString());
@@ -192,7 +207,7 @@
}
catch (SQLException e)
{
-getLogger().error(e.getMessage(), e);
+fireError(EVENT_ADD_PROPERTY, key, obj, e);
}
finally
{
@@ -202,7 +217,12 @@
}
/**
- * [EMAIL PROTECTED]
+ * Checks if this configuration is empty. If this causes a database error,
+ * an error event will be generated of type
EVENT_READ_PROPERTY
+ * with the causing exception. Both the event's propertyName
+ * and propertyValue will be undefined.
+ *
+ * @return a flag whether this configuration is empty.
*/
public boolean isEmpty()
{
@@ -220,7 +240,7 @@
try
{
-conn = datasource.getConnection();
+conn = getConnection();
// bind the parameters
pstmt = conn.prepareStatement(query.toString());
@@ -238,7 +258,7 @@
}
catch (SQLException e)
{
-getLogger().error(e.getMessage(), e);
+fireError(EVENT_READ_PROPERTY, null, null, e);
}
finally
{
@@ -250,7 +270,14 @@
}
/**
- * [EMAIL PROTECTED]
+ * Checks whether this configuration contains the specified key. If this
+ * causes a database error, an error event will be generated of type
+ * EVENT_READ_PROPERTY with the causing exception. The
+ * event's propertyName will be set to the passed in key, the
+ * propertyValue will be undefined.
+ *
+ * @param key the key to be checked
+ * @return a flag whether this key is defined
*/
public boolean containsKey(String key)
{
@@ -268,7 +295,7 @@
try
{
-conn = datasource.getConnection();
+conn = getConnection();
// bind the parameters
pstmt = conn.prepareStatement(query.to
[jira] Commented: (VALIDATOR-220) EmailValidator fails with ArrayIndexOutOfBoundsException on domain names longer than 10 segments
[ https://issues.apache.org/jira/browse/VALIDATOR-220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12464991 ] Adam Gordon commented on VALIDATOR-220: --- Oh, excellent. Thanks for the heads up. > EmailValidator fails with ArrayIndexOutOfBoundsException on domain names > longer than 10 segments > > > Key: VALIDATOR-220 > URL: https://issues.apache.org/jira/browse/VALIDATOR-220 > Project: Commons Validator > Issue Type: Bug > Components: Framework >Affects Versions: 1.3.0 Release, 1.3.1 Release > Environment: $ uname -a > Linux frisky 2.6.17-10-generic #2 SMP Tue Dec 5 22:28:26 UTC 2006 i686 > GNU/Linux >Reporter: Adam Gordon > Assigned To: Niall Pemberton > Fix For: 1.4 > > > The EmailValidator class, specifically, the "protected boolean > isValidSymbolicDomain(String domain)" method makes an assumption on the PERL > RegEX rules, specifically, that no more than 10 domains/subdomains may be > specified in an email address. I.e. an email address of "[EMAIL PROTECTED]" > is valid according to the EmailValidator whereas an email address of "[EMAIL > PROTECTED]" causes isValidSymbolicDomain(String) to throw an > ArrayIndexOutOfBoundsException because the "domainSegment" local variable is > hard-coded to have a length of 10. > Whether or not this is due to a limitation in PERL w.r.t. the maximum number > of allowed groupings, I do not know, but the RFC for email addresses does not > appear to specify a maximum number. Additionally, although I couldn't find > it in the RFC, Wikipedia says that the maximum number of characters for the > domain name is 255 - though I am very hesitant to cite/use Wikipedia as an > official source... > Granted, I've never seen a domain name w/ more than 5 subdomain names, let > alone 10, but it seems like it should be supported regardless. > I'd submit a patch, but I wanted to discuss possible courses of action and > determine the "right" (or at least acceptable) one. Possible solutions are: > 1. check if the counter i in the for loop is > 10 and perform some action > that stops the iterative process. > 2. if the max number of groupings in PERL RegEX is 10, maybe we shouldn't > use RegEX to determine the groupings. > 3. if, per the RFC, the max number of domain name groupings is 10, then the > code should check for this. > Please let me know if you 1) have an alternative solution and 2) want me to > code a/the fix. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r496497 - /jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/AbstractConfiguration.java
Author: oheger
Date: Mon Jan 15 13:16:16 2007
New Revision: 496497
URL: http://svn.apache.org/viewvc?view=rev&rev=496497
Log:
CONFIGURATION-245: Added a convenience method for registering a logging error
listener to AbstractConfiguration
Modified:
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/AbstractConfiguration.java
Modified:
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/AbstractConfiguration.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/AbstractConfiguration.java?view=diff&rev=496497&r1=496496&r2=496497
==
---
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/AbstractConfiguration.java
(original)
+++
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/AbstractConfiguration.java
Mon Jan 15 13:16:16 2007
@@ -27,6 +27,8 @@
import org.apache.commons.collections.Predicate;
import org.apache.commons.collections.iterators.FilterIterator;
+import org.apache.commons.configuration.event.ConfigurationErrorEvent;
+import org.apache.commons.configuration.event.ConfigurationErrorListener;
import org.apache.commons.configuration.event.EventSource;
import org.apache.commons.configuration.interpol.ConfigurationInterpolator;
import org.apache.commons.lang.BooleanUtils;
@@ -76,18 +78,37 @@
*/
public abstract class AbstractConfiguration extends EventSource implements
Configuration
{
-/** Constant for the add property event type.*/
+/**
+ * Constant for the add property event type.
+ * @since 1.3
+ */
public static final int EVENT_ADD_PROPERTY = 1;
-/** Constant for the clear property event type.*/
+/**
+ * Constant for the clear property event type.
+ * @since 1.3
+ */
public static final int EVENT_CLEAR_PROPERTY = 2;
-/** Constant for the set property event type.*/
+/**
+ * Constant for the set property event type.
+ * @since 1.3
+ */
public static final int EVENT_SET_PROPERTY = 3;
-/** Constant for the clear configuration event type.*/
+/**
+ * Constant for the clear configuration event type.
+ * @since 1.3
+ */
public static final int EVENT_CLEAR = 4;
+/**
+ * Constant for the get property event type. This event type is used for
+ * error events.
+ * @since 1.4
+ */
+public static final int EVENT_READ_PROPERTY = 5;
+
/** start token */
protected static final String START_TOKEN = "${";
@@ -117,7 +138,7 @@
/** Stores the logger.*/
private Log log;
-
+
/**
* Creates a new instance of AbstractConfiguration.
*/
@@ -331,6 +352,27 @@
public void setLogger(Log log)
{
this.log = (log != null) ? log : new NoOpLog();
+}
+
+/**
+ * Adds a special
+ * [EMAIL PROTECTED]
org.apache.commons.configuration.event.ConfigurationErrorListener}
+ * object to this configuration that will log all internal errors. This
+ * method is intended to be used by certain derived classes, for which it
is
+ * known that they can fail on property access (e.g.
+ * DatabaseConfiguration).
+ *
+ * @since 1.4
+ */
+public void addErrorLogListener()
+{
+addErrorListener(new ConfigurationErrorListener()
+{
+public void configurationError(ConfigurationErrorEvent event)
+{
+getLogger().warn("Internal error", event.getCause());
+}
+});
}
/**
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (VALIDATOR-220) EmailValidator fails with ArrayIndexOutOfBoundsException on domain names longer than 10 segments
[ https://issues.apache.org/jira/browse/VALIDATOR-220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated VALIDATOR-220: -- Fix Version/s: 1.4 Assignee: Niall Pemberton > EmailValidator fails with ArrayIndexOutOfBoundsException on domain names > longer than 10 segments > > > Key: VALIDATOR-220 > URL: https://issues.apache.org/jira/browse/VALIDATOR-220 > Project: Commons Validator > Issue Type: Bug > Components: Framework >Affects Versions: 1.3.0 Release, 1.3.1 Release > Environment: $ uname -a > Linux frisky 2.6.17-10-generic #2 SMP Tue Dec 5 22:28:26 UTC 2006 i686 > GNU/Linux >Reporter: Adam Gordon > Assigned To: Niall Pemberton > Fix For: 1.4 > > > The EmailValidator class, specifically, the "protected boolean > isValidSymbolicDomain(String domain)" method makes an assumption on the PERL > RegEX rules, specifically, that no more than 10 domains/subdomains may be > specified in an email address. I.e. an email address of "[EMAIL PROTECTED]" > is valid according to the EmailValidator whereas an email address of "[EMAIL > PROTECTED]" causes isValidSymbolicDomain(String) to throw an > ArrayIndexOutOfBoundsException because the "domainSegment" local variable is > hard-coded to have a length of 10. > Whether or not this is due to a limitation in PERL w.r.t. the maximum number > of allowed groupings, I do not know, but the RFC for email addresses does not > appear to specify a maximum number. Additionally, although I couldn't find > it in the RFC, Wikipedia says that the maximum number of characters for the > domain name is 255 - though I am very hesitant to cite/use Wikipedia as an > official source... > Granted, I've never seen a domain name w/ more than 5 subdomain names, let > alone 10, but it seems like it should be supported regardless. > I'd submit a patch, but I wanted to discuss possible courses of action and > determine the "right" (or at least acceptable) one. Possible solutions are: > 1. check if the counter i in the for loop is > 10 and perform some action > that stops the iterative process. > 2. if the max number of groupings in PERL RegEX is 10, maybe we shouldn't > use RegEX to determine the groupings. > 3. if, per the RFC, the max number of domain name groupings is 10, then the > code should check for this. > Please let me know if you 1) have an alternative solution and 2) want me to > code a/the fix. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (VALIDATOR-220) EmailValidator fails with ArrayIndexOutOfBoundsException on domain names longer than 10 segments
[ https://issues.apache.org/jira/browse/VALIDATOR-220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Gordon updated VALIDATOR-220: -- Description: The EmailValidator class, specifically, the "protected boolean isValidSymbolicDomain(String domain)" method makes an assumption on the PERL RegEX rules, specifically, that no more than 10 domains/subdomains may be specified in an email address. I.e. an email address of "[EMAIL PROTECTED]" is valid according to the EmailValidator whereas an email address of "[EMAIL PROTECTED]" causes isValidSymbolicDomain(String) to throw an ArrayIndexOutOfBoundsException because the "domainSegment" local variable is hard-coded to have a length of 10. Whether or not this is due to a limitation in PERL w.r.t. the maximum number of allowed groupings, I do not know, but the RFC for email addresses does not appear to specify a maximum number. Additionally, although I couldn't find it in the RFC, Wikipedia says that the maximum number of characters for the domain name is 255 - though I am very hesitant to cite/use Wikipedia as an official source... Granted, I've never seen a domain name w/ more than 5 subdomain names, let alone 10, but it seems like it should be supported regardless. I'd submit a patch, but I wanted to discuss possible courses of action and determine the "right" (or at least acceptable) one. Possible solutions are: 1. check if the counter i in the for loop is > 10 and perform some action that stops the iterative process. 2. if the max number of groupings in PERL RegEX is 10, maybe we shouldn't use RegEX to determine the groupings. 3. if, per the RFC, the max number of domain name groupings is 10, then the code should check for this. Please let me know if you 1) have an alternative solution and 2) want me to code a/the fix. was: The EmailValidator class, specifically, the "protected boolean isValidSymbolicDomain(String domain)" method makes an assumption on the PERL RegEX rules, specifically, that no more than 10 domains/subdomains may be specified in an email address. I.e. an email address of "[EMAIL PROTECTED]" is valid according to the EmailValidator whereas an email address of "[EMAIL PROTECTED]" causes isValidSymbolicDomain(String) to throw an ArrayIndexOutOfBoundsException because the "domainSegment" local variable is hard-coded to have a length of 10. Whether or not this is due to a limitation in PERL w.r.t. the maximum number of allowed groupings, I do not know, but the RFC for email addresses does not appear to specify a maximum number. Additionally, although I couldn't find it in the RFC, Wikipedia says that the maximum number of characters for the domain name is 255 - though I am very hesitant to cite/use Wikipedia as an official source... Granted, I've never seen a domain name w/ more than 5 subdomain names, let alone 10, but it seems like it should be supported regardless. I'd submit a patch, but I wanted to discuss possible courses of action and determine the "right" (or at least acceptable) one. Possible solutions are: 1. check if the counter i in the for loop is > 10 and perform some action that stops the iterative process. 2. if the max number of groupings in PERL RegEX is 10, maybe we shouldn't use RegEX to determine the groupings. Please let me know if you 1) have an alternative solution and 2) want me to code a/the fix. > EmailValidator fails with ArrayIndexOutOfBoundsException on domain names > longer than 10 segments > > > Key: VALIDATOR-220 > URL: https://issues.apache.org/jira/browse/VALIDATOR-220 > Project: Commons Validator > Issue Type: Bug > Components: Framework >Affects Versions: 1.3.0 Release, 1.3.1 Release > Environment: $ uname -a > Linux frisky 2.6.17-10-generic #2 SMP Tue Dec 5 22:28:26 UTC 2006 i686 > GNU/Linux >Reporter: Adam Gordon > > The EmailValidator class, specifically, the "protected boolean > isValidSymbolicDomain(String domain)" method makes an assumption on the PERL > RegEX rules, specifically, that no more than 10 domains/subdomains may be > specified in an email address. I.e. an email address of "[EMAIL PROTECTED]" > is valid according to the EmailValidator whereas an email address of "[EMAIL > PROTECTED]" causes isValidSymbolicDomain(String) to throw an > ArrayIndexOutOfBoundsException because the "domainSegment" local variable is > hard-coded to have a length of 10. > Whether or not this is due to a limitation in PERL w.r.t. the maximum number > of allowed groupings, I do not know, but the RFC for email addresses does not > appear to specify a maximum number. Additionally, although I couldn't find > it in the RFC, Wikipedia says that the maximum number of characters for the > domain name
[jira] Created: (VALIDATOR-220) EmailValidator fails with ArrayIndexOutOfBoundsException on domain names longer than 10 segments
EmailValidator fails with ArrayIndexOutOfBoundsException on domain names longer than 10 segments Key: VALIDATOR-220 URL: https://issues.apache.org/jira/browse/VALIDATOR-220 Project: Commons Validator Issue Type: Bug Components: Framework Affects Versions: 1.3.1 Release, 1.3.0 Release Environment: $ uname -a Linux frisky 2.6.17-10-generic #2 SMP Tue Dec 5 22:28:26 UTC 2006 i686 GNU/Linux Reporter: Adam Gordon The EmailValidator class, specifically, the "protected boolean isValidSymbolicDomain(String domain)" method makes an assumption on the PERL RegEX rules, specifically, that no more than 10 domains/subdomains may be specified in an email address. I.e. an email address of "[EMAIL PROTECTED]" is valid according to the EmailValidator whereas an email address of "[EMAIL PROTECTED]" causes isValidSymbolicDomain(String) to throw an ArrayIndexOutOfBoundsException because the "domainSegment" local variable is hard-coded to have a length of 10. Whether or not this is due to a limitation in PERL w.r.t. the maximum number of allowed groupings, I do not know, but the RFC for email addresses does not appear to specify a maximum number. Additionally, although I couldn't find it in the RFC, Wikipedia says that the maximum number of characters for the domain name is 255 - though I am very hesitant to cite/use Wikipedia as an official source... Granted, I've never seen a domain name w/ more than 5 subdomain names, let alone 10, but it seems like it should be supported regardless. I'd submit a patch, but I wanted to discuss possible courses of action and determine the "right" (or at least acceptable) one. Possible solutions are: 1. check if the counter i in the for loop is > 10 and perform some action that stops the iterative process. 2. if the max number of groupings in PERL RegEX is 10, maybe we shouldn't use RegEX to determine the groupings. Please let me know if you 1) have an alternative solution and 2) want me to code a/the fix. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (VFS-107) large Sftp transfers fail with OutOfMemoryError: Java heap space
large Sftp transfers fail with OutOfMemoryError: Java heap space
Key: VFS-107
URL: https://issues.apache.org/jira/browse/VFS-107
Project: Commons VFS
Issue Type: Bug
Affects Versions: Nightly Builds
Environment: java version "1.5.0_04"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_04-b05)
Java HotSpot(TM) Client VM (build 1.5.0_04-b05, mixed mode, sharing)
Linux version 2.6.17-1.2142_FC4 ([EMAIL PROTECTED]) (gcc version 4.0.2 20051125
(Red Hat 4.0.2-8)) #1 Tue Jul 11 22:41:14 EDT 2006
Reporter: Marty Lamb
Calling SftpFileObject.getOutputStream() returns a descendant of
ByteArrayOutputStream; nothing is written to the remote sftp server until the
OutputStream is closed. For large data transfers, this exhausts local
resources.
This is noted in the source for SftpFileObject:
protected OutputStream doGetOutputStream(boolean bAppend) throws
Exception
{
// TODO - Don't write the entire file into memory. Use the
stream-based
// methods on ChannelSftp once the work properly
final ChannelSftp channel = fileSystem.getChannel();
return new SftpOutputStream(channel);
}
although it is not clear what "once the[y] work properly" is referring to.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Project commons-jelly-tags-jaxme (in module commons-jelly) 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-jaxme has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 49 runs. 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-jaxme : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jaxme/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-jaxme-15012007.jar] identifier set to project name -ERROR- No such project [ws-jaxme] for property. -ERROR- No such project [ws-jaxme] for property. -ERROR- No such project [ws-jaxme] for property. -ERROR- No such project [ws-jaxme] for property. -ERROR- Cannot resolve output/outputpath of *unknown* [ws-jaxme] -ERROR- Unhandled Property: maven.jar.jaxme-js on: Maven on Project:commons-jelly-tags-jaxme -ERROR- Cannot resolve output/outputpath of *unknown* [ws-jaxme] -ERROR- Unhandled Property: maven.jar.jaxme on: Maven on Project:commons-jelly-tags-jaxme -ERROR- Cannot resolve output/outputpath of *unknown* [ws-jaxme] -ERROR- Unhandled Property: maven.jar.jaxme-api on: Maven on Project:commons-jelly-tags-jaxme -ERROR- Cannot resolve output/outputpath of *unknown* [ws-jaxme] -ERROR- Unhandled Property: maven.jar.jaxme-xs on: Maven on Project:commons-jelly-tags-jaxme -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -INFO- Failed with reason configuration failed -ERROR- Bad Dependency. Project: ws-jaxme unknown to *this* workspace -INFO- Failed to extract fallback artifacts from Gump Repository To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jaxme/rss.xml - Atom: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jaxme/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 2415012007, vmgump.apache.org:vmgump-public:2415012007 Gump E-mail Identifier (unique within run) #15. -- Apache Gump http://gump.apache.org/ [Instance: vmgump] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Project commons-jelly-tags-jaxme (in module commons-jelly) 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-jaxme has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 49 runs. 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-jaxme : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jaxme/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-jaxme-15012007.jar] identifier set to project name -ERROR- No such project [ws-jaxme] for property. -ERROR- No such project [ws-jaxme] for property. -ERROR- No such project [ws-jaxme] for property. -ERROR- No such project [ws-jaxme] for property. -ERROR- Cannot resolve output/outputpath of *unknown* [ws-jaxme] -ERROR- Unhandled Property: maven.jar.jaxme-js on: Maven on Project:commons-jelly-tags-jaxme -ERROR- Cannot resolve output/outputpath of *unknown* [ws-jaxme] -ERROR- Unhandled Property: maven.jar.jaxme on: Maven on Project:commons-jelly-tags-jaxme -ERROR- Cannot resolve output/outputpath of *unknown* [ws-jaxme] -ERROR- Unhandled Property: maven.jar.jaxme-api on: Maven on Project:commons-jelly-tags-jaxme -ERROR- Cannot resolve output/outputpath of *unknown* [ws-jaxme] -ERROR- Unhandled Property: maven.jar.jaxme-xs on: Maven on Project:commons-jelly-tags-jaxme -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -INFO- Failed with reason configuration failed -ERROR- Bad Dependency. Project: ws-jaxme unknown to *this* workspace -INFO- Failed to extract fallback artifacts from Gump Repository To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jaxme/rss.xml - Atom: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jaxme/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 2415012007, vmgump.apache.org:vmgump-public:2415012007 Gump E-mail Identifier (unique within run) #15. -- Apache Gump http://gump.apache.org/ [Instance: vmgump] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Project commons-jelly-tags-soap (in module commons-jelly) 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-soap has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 49 runs. 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-soap : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-soap/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-soap-15012007.jar] identifier set to project name -ERROR- No such project [ws-jaxme] for property. -ERROR- Cannot resolve output/outputpath of *unknown* [ws-jaxme] -ERROR- Unhandled Property: maven.jar.jaxme-api on: Maven on Project:commons-jelly-tags-soap -DEBUG- Dependency on ws-axis exists, no need to add for property maven.jar.axis. -DEBUG- Dependency on ws-axis exists, no need to add for property maven.jar.jaxrpc-api. -DEBUG- Dependency on ws-axis exists, no need to add for property maven.jar.saaj-api. -DEBUG- Dependency on jakarta-servletapi-5-servlet exists, no need to add for property maven.jar.servletapi. -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -INFO- Failed with reason configuration failed -ERROR- Bad Dependency. Project: ws-jaxme unknown to *this* workspace -INFO- Failed to extract fallback artifacts from Gump Repository To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-soap/rss.xml - Atom: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-soap/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 2415012007, vmgump.apache.org:vmgump-public:2415012007 Gump E-mail Identifier (unique within run) #13. -- Apache Gump http://gump.apache.org/ [Instance: vmgump] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Project commons-jelly-tags-soap (in module commons-jelly) 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-soap has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 49 runs. 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-soap : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-soap/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-soap-15012007.jar] identifier set to project name -ERROR- No such project [ws-jaxme] for property. -ERROR- Cannot resolve output/outputpath of *unknown* [ws-jaxme] -ERROR- Unhandled Property: maven.jar.jaxme-api on: Maven on Project:commons-jelly-tags-soap -DEBUG- Dependency on ws-axis exists, no need to add for property maven.jar.axis. -DEBUG- Dependency on ws-axis exists, no need to add for property maven.jar.jaxrpc-api. -DEBUG- Dependency on ws-axis exists, no need to add for property maven.jar.saaj-api. -DEBUG- Dependency on jakarta-servletapi-5-servlet exists, no need to add for property maven.jar.servletapi. -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -INFO- Failed with reason configuration failed -ERROR- Bad Dependency. Project: ws-jaxme unknown to *this* workspace -INFO- Failed to extract fallback artifacts from Gump Repository To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-soap/rss.xml - Atom: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-soap/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 2415012007, vmgump.apache.org:vmgump-public:2415012007 Gump E-mail Identifier (unique within run) #13. -- Apache Gump http://gump.apache.org/ [Instance: vmgump] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
