DO NOT REPLY [Bug 33744] - [collections] Should make collection generic like Java5 generic containers
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=33744. 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=33744 [EMAIL PROTECTED] changed: What|Removed |Added Severity|normal |enhancement OS/Version|Windows XP |All Platform|PC |All Summary|Should make collection |[collections] Should make |generic like Java5 generic |collection generic like |containers. |Java5 generic containers -- 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 33676] - [servlet] SessionUtils and new methods for RequestUtils
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=33676. 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=33676 [EMAIL PROTECTED] changed: What|Removed |Added Severity|normal |enhancement Summary|Suggestions For Servlet In |[servlet] SessionUtils and |Sandbox |new methods for RequestUtils -- 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]
[GUMP@brutus]: Project commons-jelly-tags-xml (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-xml has an issue affecting its community integration. This issue affects 12 projects, and has been outstanding for 2 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-define : Commons Jelly - commons-jelly-tags-html : Commons Jelly - commons-jelly-tags-http : Commons Jelly - commons-jelly-tags-jaxme : Commons Jelly - commons-jelly-tags-jetty : Commons Jelly - commons-jelly-tags-jface : Commons Jelly - commons-jelly-tags-jsl : Commons Jelly - commons-jelly-tags-swing : Commons Jelly - commons-jelly-tags-xml : Commons Jelly - commons-jelly-tags-xmlunit : Commons Jelly - maven : Project Management Tools - maven-bootstrap : Project Management Tools Full details are available at: http://brutus.apache.org/gump/public/commons-jelly/commons-jelly-tags-xml/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-xml-28022005.jar] identifier set to project name -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/test-reports -DEBUG- Extracted fallback artifacts from Gump Repository The following work was performed: http://brutus.apache.org/gump/public/commons-jelly/commons-jelly-tags-xml/gump_work/build_commons-jelly_commons-jelly-tags-xml.html Work Name: build_commons-jelly_commons-jelly-tags-xml (Type: Build) Work ended in a state of : Failed Elapsed: 14 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml] CLASSPATH: /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.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-apache-resolver.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/dist/junit/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-28022005.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-28022005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-28022005.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-28022005.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/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-28022005.jar - [mkdir] Created dir: /home/gump/workspaces2/public/workspace/commons-jelly/jelly-tags/xml/target/classes java:compile: [echo] Compiling to /home/gump/workspaces2/public/workspace/commons-jelly/jelly-tags/xml/target/classes [echo] == NOTE: Targetting JVM 1.4, classes will not run on earlier JVMs == [javac] Compiling 16 source files to /home/gump/workspaces2/public/workspace/commons-jelly/jelly-tags/xml/target/classes java:jar-resources: test:prepare-filesystem: [mkdir] Created dir: /home/gump/workspaces2/public/workspace/commons-jelly/jelly-tags/xml/target/test-classes [mkdir] Created dir: /home/gump/workspaces2/public/workspace/commons-jelly/jelly-tags/xml/target/test-reports test:test-resources: Copying 36 files to
[GUMP@brutus]: Project commons-jelly-tags-ant (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-ant has an issue affecting its community integration. This issue affects 2 projects, and has been outstanding for 2 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 : Commons Jelly - commons-jelly-tags-fmt : Commons Jelly Full details are available at: http://brutus.apache.org/gump/public/commons-jelly/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-28022005.jar] identifier set to project name -DEBUG- Dependency on ant exists, no need to add for property maven.jar.ant-optional. -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/test-reports -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://brutus.apache.org/gump/public/commons-jelly/commons-jelly-tags-ant/gump_work/build_commons-jelly_commons-jelly-tags-ant.html Work Name: build_commons-jelly_commons-jelly-tags-ant (Type: Build) Work ended in a state of : Failed Elapsed: 11 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant] CLASSPATH: /opt/jdk1.4/lib/tools.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-apache-resolver.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/dist/junit/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-28022005.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-28022005.jar:/usr/local/gump/public/workspace/jakarta-commons-sandbox/grant/target/commons-grant-28022005.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-28022005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-28022005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/util/target/commons-jelly-tags-util-28022005.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-28022005.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/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-28022005.jar - java:prepare-filesystem: [mkdir] Created dir: /home/gump/workspaces2/public/workspace/commons-jelly/jelly-tags/ant/target/classes java:compile: [echo] Compiling to /home/gump/workspaces2/public/workspace/commons-jelly/jelly-tags/ant/target/classes [echo] == NOTE: Targetting JVM 1.4, classes will not run on earlier JVMs == [javac] Compiling 10 source files to /home/gump/workspaces2/public/workspace/commons-jelly/jelly-tags/ant/target/classes [javac] /home/gump/workspaces2/public/workspace/commons-jelly/jelly-tags/ant/src/java/org/apache/commons/jelly/tags/ant/AntTag.java:385: warning: createElement(org.apache.tools.ant.Project,java.lang.Object,java.lang.String) in org.apache.tools.ant.IntrospectionHelper has been deprecated [javac] dataType = ih.createElement( getAntProject(), object, name.toLowerCase() ); [javac]
[PATCH][commons-daemonSetting the process name
I'm using the JSVC to run multiple java processes. I would like to be able to tell them apart when viewing the process list. Currently they all display as jsvc-exec. The patch contains a new command line argument called procname. If procname is passed as an argument to jsvc it is as the process name instead of the hardcoded 'jsvc.exec'. Also could you tell me when the next release would be available I'd prefer to use a released version of jsvc then a locally modified version, assuming this patch is accepted. Thanks Derek - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[digester] Patches to xmlrules : NodeCreateRule addon + namespace prefix support
Added PREFIX namespace support for NodeCreateRule: Can now parse a XML Schema
correctly
Tested (see Junit TestCase below). Works fine!
+++
public class NodeCreateRule extends Rule {
private class NodeBuilder
extends DefaultHandler {
+++
public void startElement(String namespaceURI, String localName,
String qName, Attributes atts)
throws SAXException {
try {
Node previousTop = top;
if ((localName == null) || (localName.length() == 0)) {
top = doc.createElement(qName);
} else {
top = doc.createElementNS(namespaceURI, localName);
}
String prefix = qName.split(:)[0];
if (prefix != null) {
top.setPrefix(prefix);
}
for (int i = 0; i atts.getLength(); i++) {
Attr attr = null;
String attQname = atts.getQName(i);
prefix = null;
if (attQname.contains(:))
prefix = attQname.split(:)[0];
if ((atts.getLocalName(i) == null) ||
(atts.getLocalName(i).length() == 0)) {
attr = doc.createAttribute(attQname);
attr.setNodeValue(atts.getValue(i));
if (prefix != null) {
attr.setPrefix(prefix);
}
((Element)top).setAttributeNode(attr);
} else {
attr = doc.createAttributeNS(atts.getURI(i),
atts.getLocalName(i));
attr.setNodeValue(atts.getValue(i));
if (prefix != null) {
attr.setPrefix(prefix);
}
((Element)top).setAttributeNodeNS(attr);
}
}
previousTop.appendChild(top);
depth++;
} catch (DOMException e) {
throw new SAXException(e.getMessage());
}
}
+++
Added support for [NodeCreateRule]
public class DigesterRuleParser extends RuleSetBase {
public static javax.xml.parsers.DocumentBuilder documentBuilder;
public static javax.xml.parsers.DocumentBuilder getDocumentBuilder() {
return documentBuilder;
}
public static void setDocumentBuilder(
javax.xml.parsers.DocumentBuilder documentBuilder) {
DigesterRuleParser.documentBuilder = documentBuilder;
}
static {
try {
DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
factory.setNamespaceAware(true);
factory.setIgnoringComments(false);
factory.setCoalescing(false);
factory.setIgnoringElementContentWhitespace(false);
documentBuilder = factory.newDocumentBuilder();
} catch (ParserConfigurationException e) {
System.err.println(e);
}
}
+++
public void addRuleInstances(Digester digester) {
digester.addFactoryCreate(*/node-create-rule, new
NodeCreateRuleFactory());
digester.addRule(*/node-create-rule, new PatternRule(pattern));
digester.addSetNext(*/node-create-rule, add, ruleClassName);
/**
* Factory for creating a NodeCreateRule
*/
protected class NodeCreateRuleFactory extends AbstractObjectCreationFactory
{
private boolean isNotEmpty(String str) {
return (str != null str.length() 0);
}
public Object createObject(Attributes attributes) {
String strDocumentBuilderFactoryClass = attributes
.getValue(documentbuilderfactory);
String strDocumentBuilderClass = attributes
.getValue(documentbuilder);
String strIsNsAware = attributes.getValue(namespaceaware);
String strIsIgnoreComments = attributes.getValue(ignorecomments);
String strIsFragment = attributes.getValue(fragment);
boolean ignoreExceptions = true.equalsIgnoreCase(attributes
.getValue(ignore-exceptions));
boolean isNewFactory = false;
// Use custom DocumentBuilderFactory
if (isNotEmpty(strDocumentBuilderFactoryClass)) {
try {
DocumentBuilderFactory customDocumentBuilderFactory =
(DocumentBuilderFactory) Class
.forName(strDocumentBuilderFactoryClass)
.newInstance();
setDocumentBuilderFactory(customDocumentBuilderFactory);
isNewFactory = true;
} catch (Exception e) {
System.err.println(e);
}
}
Re: [VOTE][configuration]Release 1.1
Okay, I would like to get out the release as soon as possible, too. Emmanuel, did you make some progress at the reloading stuff? Is there something I can do to help you? Oliver Eric Pugh wrote: You didn't break fulcrum.. Fulcrum Configuration is built by Gump against the CVS head, so the API change between 1.0 and 1.1 of commons-configuration cause compile errors. The sooner we can get a release out, the better.. I'll try next week to see if I can help! Eric -Original Message- From: Oliver Heger [mailto:[EMAIL PROTECTED] Sent: Friday, February 18, 2005 1:53 AM To: Jakarta Commons Developers List Subject: Re: [VOTE][configuration]Release 1.1 Welcome back, Eric! We were trying to get a 1.1 release out, but this is halted now because of problems in the reloading area. In which way did we break Fulcrum? Oliver Eric Pugh wrote: Folks, I have been really tied up in real life since before Christmas, but life has started calming down. I'll be looking at getting reinvolved again in the commons projects that are near and dear to my heart! For what it's worth, I am very excited about getting another rev of configuration out. (that and gump has been complaining about Fulcrum Configuration and the new API!). Eric -Original Message- From: robert burrell donkin [mailto:[EMAIL PROTECTED] Sent: Thursday, February 10, 2005 2:16 PM To: Jakarta Commons Developers List Subject: Re: [VOTE][configuration]Release 1.1 FWIW i've never regretted holding a release and i think the right decision's been made. - robert On Thu, 2005-02-10 at 19:43, Oliver Heger wrote: Of course, I don't want to force a release out which is not mature. Let's hold it. But I feel a bit disappointed that it seems to be so hard to get the required three +1s. I think we must be careful that we do not lose our momentum :-( Oliver Emmanuel Bourg wrote: I'm actually -1 for the release, I dropped the 1.1rc1 jar in my application yesterday and it broke with an exception related to the configuration reloading stuff. This may be linked to the issue reported by Jurgen Schlierf on the commons-user list. I'd like to investigate this bug before releasing the final 1.1. Emmanuel Bourg Oliver Heger wrote: Hi all, we need another +1 to get our release out. Nobody? Oliver Oliver Heger wrote: Dear community, since the 1.0 release of [configuration] a couple of new features have been added. The code base has been stable for a while now, so I think it is time to cut out a new 1.1 release before we start to implement further features and refactorings. A complete list of changes since the 1.0 releaes can be found here: http://jakarta.apache.org/commons/configuration/changes-report.html I have created a release candidate, which can be inspected at http://www.apache.org/~oheger/commons-configuration-1.1rc1/ (the tag for 1.1RC1 is named CONFIGURATION_1_1RC1). Here is my +1! Oliver - 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: [VOTE][configuration]Release 1.1
Oliver Heger wrote: Okay, I would like to get out the release as soon as possible, too. Emmanuel, did you make some progress at the reloading stuff? Is there something I can do to help you? Oliver I haven't had a chance to test it yet, I should have some time this week. Emmanuel Bourg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33167] - [dbcp] Individual connection close method
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=33167.
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=33167
--- Additional Comments From [EMAIL PROTECTED] 2005-02-28 18:41 ---
Removing the pool from the hashmap seems to work
(unit test doesn't fail anymore) but more testing is needed before commit.
public synchronized void close(String user) {
try {
PoolKey key = getPoolKey(user);
ObjectPool pool = (ObjectPool) pools.get(key);
pool.close();
pools.remove(key);
} catch (Exception closePoolException) {
closePoolException.printStackTrace();
}
}
--
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 33775] New: - dist dir has out-of-date files
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=33775. 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=33775 Summary: dist dir has out-of-date files Product: Commons Version: unspecified Platform: All OS/Version: Windows XP Status: NEW Severity: normal Priority: P2 Component: attributes AssignedTo: commons-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] The distribution directory http://xml.apache.org/commons/dist/ has files that are out of date. It shows resolver 1.0 instead of 1.1, for example. -- 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 33744] - [collections] Should make collection generic like Java5 generic containers
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=33744. 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=33744 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2005-02-28 19:11 --- See http://collections15.sourceforge.net Lack of developer time at apache meant a sf project got created. Maybe at some point the code may get reintegrated. -- 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 33775] - [attributes] dist dir has out-of-date files
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=33775. 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=33775 [EMAIL PROTECTED] changed: What|Removed |Added Summary|dist dir has out-of-date|[attributes] dist dir has |files |out-of-date files -- 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: [VOTE][configuration]Release 1.1
Emmanuel Bourg wrote: I haven't had a chance to test it yet, I should have some time this week. Ok I checked again my application with the latest nightly build and it worked fine. I don't know what happened the last time I updated my commons configuration jar... I'm +1 for a 1.1-rc2 release followed by a final 1.1 Emmanuel Bourg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE][configuration]Release 1.1
Strange! Okay, I would like to have a look at bug 33723 and maybe add a unit test that checks for absolute path names (to be sure). 33691 is open, too, but I think this has been more or less solved in the meantime. Here we could only modify the constructor of SubsetConfiguration that does not take a delimiter as argument to set the default delimiter. And we could prevent trailing dots in the prefix. I hope I come to these things tomorrow. Then it's time for the second RC! Oliver Emmanuel Bourg wrote: Emmanuel Bourg wrote: I haven't had a chance to test it yet, I should have some time this week. Ok I checked again my application with the latest nightly build and it worked fine. I don't know what happened the last time I updated my commons configuration jar... I'm +1 for a 1.1-rc2 release followed by a final 1.1 Emmanuel Bourg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33331] - [betwixt] Custom Object-String Conversion in .betwixt file
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=1. 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=1 --- Additional Comments From [EMAIL PROTECTED] 2005-02-28 21:42 --- The idea is that the options allow any information to be passed: for example, the name of a custom converter class. I though about including this feature as default and would be willing to take a look at a submitted implementation. -- 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]
commons lang: Comparisons with null support
I have not done an extensive search of the mailing list archives, but I was
wondering if something like the following comparison functions with support
for null values may be useful in commons lang StringUtils (and also
DateUtils and NumberUtils):
public static int compare(String left, String right) {
if (left == right) {
return 0;
}
if (left == null) {
return -1;
}
if (right == null) {
return 1;
}
return left.compareTo(right);
}
Sualeh.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] [logging] promote RC1 to alpha status
+1 *** Richard A. Sitze IBM WebSphere WebServices Development robert burrell donkin [EMAIL PROTECTED] wrote on 02/26/2005 01:41:05 PM: the release candidate has been available for a while now and i am not aware of any problems with it. the next stage in the release process will be to promote this release candidate to alpha release status. this involves moving the release to a new location with a new name and announcing the availability of this release to the public. this is a full release vote (and so three +1's are required). please check the release before voting +1. i will not tally the votes before 2300 hours GMT on tuesday 1st of march. here's my +1 - robert -8- [ ] +1 Promote RC1 to commons-logging-1.0.5-alpha1 [ ] +0 In favour of this release [ ] -0 Against this release [ ] -1 Do not release RC1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE][configuration]Release 1.1
Oliver Heger wrote: Strange! Okay, I would like to have a look at bug 33723 and maybe add a unit test that checks for absolute path names (to be sure). 33691 is open, too, but I think this has been more or less solved in the meantime. Here we could only modify the constructor of SubsetConfiguration that does not take a delimiter as argument to set the default delimiter. And we could prevent trailing dots in the prefix. I hope I come to these things tomorrow. Then it's time for the second RC! Regarding bug 33691 I'm not sure we should change the code of SubsetConfiguration, this may just be a documentation issue. Emmanuel Bourg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] commons lang: Comparisons with null support
You may find NullComparator in [collections] useful.
Stephen
- Original Message -
From: Sualeh Fatehi [EMAIL PROTECTED]
I have not done an extensive search of the mailing list archives, but I was
wondering if something like the following comparison functions with
support
for null values may be useful in commons lang StringUtils (and also
DateUtils and NumberUtils):
public static int compare(String left, String right) {
if (left == right) {
return 0;
}
if (left == null) {
return -1;
}
if (right == null) {
return 1;
}
return left.compareTo(right);
}
Sualeh.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33377] - [jxpath] asPath() returns a path to the last sibling
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=33377. 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=33377 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |ASSIGNED -- 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 33780] - [betwixt] SAX Attribute Problem: qName differ from localName
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=33780. 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=33780 --- Additional Comments From [EMAIL PROTECTED] 2005-03-01 00:46 --- Created an attachment (id=14377) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=14377action=view) TestCase for showing the problem pathc containing of three files: - a simple bean - it's dot-betwixt-file - the test case -- 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]
[betwixt] Bug in attribute output to SAX events. local name differs from qualified name
hi, found some strange behavior with BetwixtTransfomer in cocoon that comes from a problem of the SAX output of betwixt, as I think. The attributes of a start element SAX event local names that differ from there qualified names for attributes without namespace applied. I wrote a small testcase to demonstrate the bug, but I wasn't able to track it down and fix it. It seems to be a problem in the introspector, as I see it. Perheaps somebody more familiar with betwixt could have a look at it. The bugreport is at http://issues.apache.org/bugzilla/show_bug.cgi?id=33780 The testcase is attached to the bugreport as a patch. regards, Christoph [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] Patches to xmlrules : NodeCreateRule addon + namespace prefix support
Hi Kristian,
On Mon, 2005-02-28 at 17:43 +0100, Kristian Mandrup wrote:
Added PREFIX namespace support for NodeCreateRule: Can now parse a XML Schema
correctly
Tested (see Junit TestCase below). Works fine!
[snip]
if ((localName == null) || (localName.length() == 0)) {
top = doc.createElement(qName);
} else {
top = doc.createElementNS(namespaceURI, localName);
}
String prefix = qName.split(:)[0];
if (prefix != null) {
top.setPrefix(prefix);
}
This seems to ensure that if an xml document containing namespaces is parsed
with
a non-namespace-aware xml parser (ie localName is not defined), then a DOM-1
(ie non-namespace-aware) element node is created (createElement), but then
the namespace-aware setPrefix method is called on it.
It seems to me that if the createElement (ie non-namespace-aware) method
is called to create the attribute, then calling setPrefix (ie a
namespace-aware method) is a bad idea. A prefix is being set, but there
is no namespace URI associated with the node...
for (int i = 0; i atts.getLength(); i++) {
Attr attr = null;
String attQname = atts.getQName(i);
prefix = null;
if (attQname.contains(:))
prefix = attQname.split(:)[0];
if ((atts.getLocalName(i) == null) ||
(atts.getLocalName(i).length() == 0)) {
attr = doc.createAttribute(attQname);
attr.setNodeValue(atts.getValue(i));
if (prefix != null) {
attr.setPrefix(prefix);
}
This seems to have the same issue as described above; it seems to me
that if the createAttribute (ie non-namespace-aware) method is called to
create the attribute, then calling setPrefix (ie a namespace-aware
method) is a bad idea. A prefix is being set, but there is no namespace
URI associated with the node...
If I have misunderstood your patch, please let me know.
What is the problem that you are encountering with the current code that
this patch is intended to remedy?
Regards,
Simon
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] Patches to xmlrules : NodeCreateRule addon + namespace prefix support
On Tue, 2005-03-01 at 14:15 +1300, Simon Kitching wrote:
Hi Kristian,
On Mon, 2005-02-28 at 17:43 +0100, Kristian Mandrup wrote:
Added PREFIX namespace support for NodeCreateRule: Can now parse a XML
Schema correctly
Tested (see Junit TestCase below). Works fine!
[snip]
if ((localName == null) || (localName.length() == 0)) {
top = doc.createElement(qName);
} else {
top = doc.createElementNS(namespaceURI, localName);
}
String prefix = qName.split(:)[0];
if (prefix != null) {
top.setPrefix(prefix);
}
This seems to ensure that if an xml document containing namespaces is parsed
with
a non-namespace-aware xml parser (ie localName is not defined), then a DOM-1
(ie non-namespace-aware) element node is created (createElement), but then
the namespace-aware setPrefix method is called on it.
It seems to me that if the createElement (ie non-namespace-aware) method
is called to create the attribute, then calling setPrefix (ie a
namespace-aware method) is a bad idea. A prefix is being set, but there
is no namespace URI associated with the node...
Ok, I've had another look and think I understand at least part of your
patch.
First, you've added support for NodeCreateRule to the xmlrules module.
That's fine - though providing an explicit patch to do *just* this
(including a patch to the dtd and some unit tests) would be preferable
to including this as part of a larger and more complex patch. By patch
I mean a file generated by svn diff , which generates a diff file
between your local version (with the changes in it) and the current
version in the apache subversion repository. I would also recommend
leaving out the rather complex code that allows the xmlrules to specify
configuration for a custom DocumentBuilderFactory; I'm not convinced
that this is necessary or useful, and leaving it out of your initial
patch will make it more likely that the initial patch will be merged in
a timely manner.
You're then trying to parse a document containing namespaces, using a
namespace-aware parser. But a pattern can never match an xml element
which has a namespace unless the setNamespaceURI method has been
called on the Rule object (either directly, or indirectly via
Rules.setNamespaceURI or Digester.setRuleNamespaceURI).
Note that the setRuleNamespaceURI method used in your testcase has no
effect:
Digester d = DigesterLoader.createDigester(rules);
d.setNamespaceAware(true);
d.setRuleNamespaceURI(www.diku.dk);
That method only affects rules added after the call is made; but by the
time you call it here, all the rules have already been added. In fact,
there is currently no way to use the setNamespaceURI functionality
with xmlrules as far as I can see. If you would like to provide a patch
to add that to xmlrules somehow, that would be nice. I can't suggest
how, though. And you'd certainly need to read the RulesBase
implementation of the match(namespace, name) method to understand how
Digester's horribly hacky implementation of namespace support currently
works.
I still don't understand the point of the changes to the NodeCreateRule;
see my comments in the previous email.
Regards,
Simon
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33780] - [betwixt] SAX Attribute Problem: qName differ from localName
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=33780.
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=33780
--- Additional Comments From [EMAIL PROTECTED] 2005-03-01 03:18 ---
Hi Christoph,
While the qname in the attributes does seem odd to me, you should note that when
using a namespace-aware sax parser to parse text input, there is no guarantee
that the qname field is populated at all. At least, that's my interpretation of
the javadoc
From the javadoc for the org.xml.sax.Attributes.getQName method:
Returns:
The XML 1.0 qualified name, or the empty string if none is available, ...
Code processing attributes really should do:
if (localname.size() 0) {
// we are using a namespace-aware parser, so use
// (URI, localname). Don't use the qname, as it might
// or might not be defined, at the discretion of the parser
// implementation...
} else {
// we are using a non-namespace-aware parser, so
// use the qname
}
If cocoon is looking at the qname field when the localname is not empty, then I
believe that cocoon needs fixing.
Note that if the namespace-prefixes attribute is set on the sax parser, then
qnames are definitely available - but namespace declarations *also* get passed
as attributes, which is not normally desired.
--
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: [dbutils]Sending large set of numbers
I had the query in a properties file. The numbers for the set were the result of another query. It was a string named sids in the form of a CSV. ,222,333,444,,666.,888,999 I think this was the problem. I was trying to call it like: list = (List) queryRunner.query(query, sids, new BeanListHandler(LineupMember.class)); The query was along the lines of: select * from foo where sid in (?) = Norris Shelton Software Engineer Sun Certified Java 1.1 Programmer Appriss, Inc. ICQ# 26487421 AIM NorrisEShelton YIM norrisshelton __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[FeedParser] Patch: Maven build changes
The patch below modifies the FeedParser Maven build so it can be used to
compile the code. This should apply against
http://svn.apache.org/repos/asf/jakarta/commons/proper/feedparser/trunk/
(which I presume is the correct site - the website says
http://svn.apache.org/repos/asf/jakarta/commons/sandbox/feedparser/trunk
)
This patch makes the build use jars from the iBiblio jar repository if
they are curretnly there, but overrides the location for those that
aren't there with the jars used by the Ant build.
It's possible to make Maven create a jar by default. To do this create a
maven.xml file in the root dir with the following contents (the patch
doesn't include this, but it would probably be a good idea):
?xml version=1.0 encoding=ISO-8859-1?
project default=jar:jar xmlns:m=jelly:maven
/project
Regards
Nick Lothian
Patch:
Index: project.xml
===
--- project.xml (revision 155664)
+++ project.xml (working copy)
@@ -93,15 +93,14 @@
dependency
idjaxen/id
-version1.1-beta-4/version
-/dependency
-
- !--
-dependency
-idjaxen/id
+!--
+The filesize of the jaxen-full jar currently in CVS doesn't
match
+any in the Maven repo.
+
+version1.1-beta-4/version
+--
version1.0/version
/dependency
- --
dependency
idjunit/id
@@ -124,6 +123,11 @@
/dependency
!-- FIXME xmlrpc --
+
+dependency
+idsaxpath/id
+version1.0-FCS/version
+/dependency
!-- these two are required by maven --
dependencyidxml-apis/idversion2.0.2/version/dependency
@@ -133,7 +137,7 @@
build
nagEmailAddress[EMAIL PROTECTED]/nagEmailAddress
-sourceDirectorysrc/java/sourceDirectory
+sourceDirectorysrc/java/sourceDirectory
/build
reports
Index: build.properties
===
--- build.properties(revision 155664)
+++ build.properties(working copy)
@@ -1,16 +1,5 @@
-# The full path to where the Jakarta Feed Parser is installed, such as
-# c:/jakarta/feedparser; use forward slashes instead of backslashes
on
-# Windows. --
-#feedparser.home=${user.home}/feedparser
-feedparser.home=.
-
-# The file path location to where all of our external JARs are located
that are
-# not bundled with the Jakarta Feed Parser, such as junit.jar.
-#
-# FIXME: should NOT have ksa-lib.jar in it. We should put external
.jars in CVS
-# but I'm not sure about current Apache policy for this. This is
really ugly
-# right now so maybe maven is the solution. I need this to build on
ANY unix
-# machine with java installed.
-
-ext.lib.path=${user.home}/feedparser/lib/build/
+# Turn maven jar overrides on
+maven.jar.override=on
+maven.jar.jaxen=lib/jaxen-full.jar
+#maven.jar.saxpath=lib/saxpath.jar
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE][configuration]Release 1.1
I'll take a loo at the latest as well, I need to update some dependencies anyway for Turbine! -Original Message- From: Oliver Heger [mailto:[EMAIL PROTECTED] Sent: Monday, February 28, 2005 12:09 PM To: Jakarta Commons Developers List Subject: Re: [VOTE][configuration]Release 1.1 Strange! Okay, I would like to have a look at bug 33723 and maybe add a unit test that checks for absolute path names (to be sure). 33691 is open, too, but I think this has been more or less solved in the meantime. Here we could only modify the constructor of SubsetConfiguration that does not take a delimiter as argument to set the default delimiter. And we could prevent trailing dots in the prefix. I hope I come to these things tomorrow. Then it's time for the second RC! Oliver Emmanuel Bourg wrote: Emmanuel Bourg wrote: I haven't had a chance to test it yet, I should have some time this week. Ok I checked again my application with the latest nightly build and it worked fine. I don't know what happened the last time I updated my commons configuration jar... I'm +1 for a 1.1-rc2 release followed by a final 1.1 Emmanuel Bourg - 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]
[VOTE] Release commons email 1.0
Hi all, The commons-email RC3 release has been available for a couple days, and has isn't fundamentally changed from the RC2 release that has been out for a couple months. I'd like to move to releasing the code here: http://www.apache.org/~epugh/email/distributions/ as commons-email-1.0. Documentation is available at http://www.apache.org/~epugh/email/docs/. Assuming this vote passes, my plan is to rename the jars, and then deploy them, as well as tag the 1.0 based on the RC3 tag in SVN. [ ] +1 Lets release commons-email, it's been too long! [ ] 0 Commons-what? Not ready for release [ ] -1 Don't release. I can't get dumbster (replace with your reason) to work. Eric Pugh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
