[vote] Release Mojo webstart plugin 1.0-alpha-1
Hi, I'd like to release the first alpha release of the webstart plugin. Plugin has been almost unchanged since before the summer. I intend to change some things before 1.0, but there's clearly a need for an official non-snapshot release of the plugin. The latest snapshot was just deployed (20061023.145534-2) and is available in the Codehaus snapshots repository ([1]). Please vote for the release 1.0-alpha-1 of webstart plugin: [+1]: [0]: [-1]: (obviously +1 from me.) Jerome [1] http://snapshots.repository.codehaus.org/org/codehaus/mojo/webstart-maven-plugin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r466633 - in /jakarta/commons/proper/vfs/trunk: core/pom.xml examples/pom.xml pom.xml sandbox/pom.xml
Author: imario Date: Sun Oct 22 00:54:39 2006 New Revision: 466633 URL: http://svn.apache.org/viewvc?view=revrev=466633 Log: added poms (though, not tested yet as the apache infrastructure is having a travel ;-) ) Added: jakarta/commons/proper/vfs/trunk/core/pom.xml (with props) jakarta/commons/proper/vfs/trunk/examples/pom.xml (with props) jakarta/commons/proper/vfs/trunk/sandbox/pom.xml (with props) Modified: jakarta/commons/proper/vfs/trunk/pom.xml Added: jakarta/commons/proper/vfs/trunk/core/pom.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/vfs/trunk/core/pom.xml?view=autorev=466633 == --- jakarta/commons/proper/vfs/trunk/core/pom.xml (added) +++ jakarta/commons/proper/vfs/trunk/core/pom.xml Sun Oct 22 00:54:39 2006 @@ -0,0 +1,169 @@ +?xml version=1.0 encoding=UTF-8? + +!-- + Copyright 2006 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. + -- + +project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; + xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd; + + modelVersion4.0.0/modelVersion + packagingjar/packaging + + namecore/name + groupIdorg.apache.commons/groupId + artifactIdcommons-vfs/artifactId + version1.0-RC8-SNAPSHOT/version + descriptionVFS is a Virtual File System library./description + + parent +groupIdorg.apache.commons/groupId +artifactIdcommons-vfs-project/artifactId +version1.0-RC8-SNAPSHOT/version + /parent + + + organization +nameApache Software Foundation/name +urlhttp://www.apache.org//url + /organization + licenses +license + nameThe Apache Software License, Version 2.0/name + urlhttp://www.apache.org/licenses/LICENSE-2.0.txt/url + distributionrepo/distribution +/license + /licenses + + dependencies +dependency + groupIdcommons-logging/groupId + artifactIdcommons-logging/artifactId + version1.0.4/version +/dependency +dependency + groupIdant/groupId + artifactIdant/artifactId + version1.6.2/version + optionaltrue/optional +/dependency +dependency + groupIdcommons-net/groupId + artifactIdcommons-net/artifactId + version1.4.1/version + optionaltrue/optional +/dependency +!--TODO:Revert to [compress] if/when released +dependency + groupIdcommons-compress/groupId + artifactIdcommons-compress/artifactId + versionSNAPSHOT/version + optionaltrue/optional +/dependency-- +dependency + groupIdcommons-collections/groupId + artifactIdcommons-collections/artifactId + version3.1/version + optionaltrue/optional +/dependency +dependency + groupIdjcifs/groupId + artifactIdjcifs/artifactId + version0.8.3/version + optionaltrue/optional +/dependency +dependency + groupIdslide/groupId + artifactIdjakarta-slide-webdavlib/artifactId + version20050629.161100/version + optionaltrue/optional +/dependency +dependency + groupIdjdom/groupId + artifactIdjdom/artifactId + version1.0/version + optionaltrue/optional +/dependency +dependency + groupIdcommons-httpclient/groupId + artifactIdcommons-httpclient/artifactId + version2.0.2/version + optionaltrue/optional +/dependency +dependency + groupIdcom.jcraft/groupId + artifactIdjsch/artifactId + version0.1.23/version + optionaltrue/optional +/dependency +dependency + groupIdxml-apis/groupId + artifactIdxml-apis/artifactId + version1.0.b2/version + optionaltrue/optional +/dependency +dependency + groupIdoro/groupId + artifactIdoro/artifactId + version2.0.8/version + optionaltrue/optional +/dependency +dependency + groupIdjunit/groupId + artifactIdjunit/artifactId + version3.8.1/version + scopetest/scope +/dependency + /dependencies + + build +resources + resource +directorysrc/java/directory +excludes + exclude**/*.java/exclude +/excludes + /resource +/resources +testResources + testResource +directorysrc/main/test-data/directory + /testResource +/testResources + +plugins + + plugin +
[math][VOTE] Accept Mantissa contribution
Going through the (excellent, thanks Robert!) incubator IP clearance checklist http://incubator.apache.org/ip-clearance/ip-clearance-template.html for Luc's Mantissa contribution, I see that an acceptance VOTE is recommended. So let's do it. This has been previously discussed on a couple of threads: http://marc.theaimsgroup.com/?t=11482407654r=1w=2 http://marc.theaimsgroup.com/?l=jakarta-commons-devm=115005376421847w=2 Luc has joined the commons-math team and will work with us to repackage and / or refactor as necessary toward the goal of including the Mantissa code in future commons-math releases. Several items on the commons math wish list are included in the Mantissa codebase. The codebase is here: http://www.spaceroots.org/software/mantissa/mantissa-for-commons-math.zip The MD5 hash for the file is: f9ecc079d79d2e0009a7b97e95d1e8de mantissa-for-commons-math.zip Jakarta PMC members, Pls weigh in here. I will post the result of the VOTE thread to the pmc list, but do not want to cross-post and see this as a community decision, so am running the vote here. This vote will run for 72 hours, ending at 25-October, 16:00 GMT Thanks! Phil Here is my +1 -- [ ] +1 Accept the Mantissa codebase into commons-math [ ] +0 OK... [ ] -0 OK, but I have the following concerns... [ ] -1 No, because... --- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [collections] Generifying Collections
Hi Stephen and Henri, Stephen Colebourne wrote on Saturday, October 21, 2006 5:20 PM: Henri Yandell wrote: Why not just start a branch within Collections? I don't see why this is a new component, are we going to be advising people to use Collections 3.x on JDK 1.5+ for any reasons other than legacy or instability of our generified version? My view is to make a collections-generics branch in collections with a view to it being Collections 4.0. Because commons isn't like other OSS projects. We can't go around changing our APIs freely, even between major versions. Its a simple case of us being at the bottom of the stack of jars. If we do change an API, any API then jar hell ensues because higher OSS projects will clash on their required versions of [collections]. Thus, it has to be a new package, and this is best thought of as a new component. It is also about branding. Collections is a well-known name in the community. Think of three years from now. If we declare collections 4.x needs JDK 1.5+ now, in 3 years nobody will rermember, that the older versions did support JDK 1.3. But the name for collections still persist. That's the political reason, not to change the name. (Compare this with the JDK where they had to jump through ridiculous hoops to make generics fully backwards-compatible, and created a half-arsed mess in the process...) This is the real problem. We must use a different namespace for the Java package itself. A lot of stuff depends on c-c (http://www.mavenregistry.com/search/artifact/19973 + http://www.mavenregistry.com/search/depended_upon_artifacts, quite impressive) and even in 3 years there will be stuff available that still depends on those old versions. A new package name solves the problem of coexistence as long as the jar name contains the version (e.g. commons-collection-3.1 commons-collection-4.2) but it creates new problems for e.g. Maven, that cannot handle two (binary distinct) versions at the same time. So there are three points to decide: - does a new package name imply a different Jakarta Commons project? - shall we give up existing brands (it means in the end the establishment of a new brand for all commons projects)? - if we keep the project name, do we have to accept the inevitable limits of popular tools such as Maven? - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[fileupload] [Fwd: REX and File Upload published]
I just wanted to make sure that Commons-FileUpload's project's members are aware of this ongoing specification. paul Original Message Subject:REX and File Upload published Resent-Date:Sun, 22 Oct 2006 17:03:41 + Resent-From:public-webapi@w3.org Date: Sun, 22 Oct 2006 19:03:31 +0200 From: Charles McCathieNevile [EMAIL PROTECTED] Organization: Opera Software To: Web API public public-webapi@w3.org References: [EMAIL PROTECTED] Hi folks, there is a new working draft of REX [1], and a first public working draft of file upload, for your delectation. We are hoping to take REX in this version to last call very shortly, and may then start on a version 2. So if you want to comment, please do so sooner rather than later (File Upload is not on such an aggressive schedule, but comments are also welcome of course). [1] http://www.w3.org/TR/rex [2] http://www.w3.org/TR/file-upload Cheers Chaals -- Charles McCathieNevile, Opera Software: Standards Group hablo español - je parle français - jeg lærer norsk [EMAIL PROTECTED] Try Opera 9 now! http://opera.com smime.p7s Description: S/MIME Cryptographic Signature
Re: [vote] Release Mojo webstart plugin 1.0-alpha-1
Wrong mailing list? On 10/23/06, Jerome Lacoste [EMAIL PROTECTED] wrote: Hi, I'd like to release the first alpha release of the webstart plugin. Plugin has been almost unchanged since before the summer. I intend to change some things before 1.0, but there's clearly a need for an official non-snapshot release of the plugin. The latest snapshot was just deployed (20061023.145534-2) and is available in the Codehaus snapshots repository ([1]). Please vote for the release 1.0-alpha-1 of webstart plugin: [+1]: [0]: [-1]: (obviously +1 from me.) Jerome [1] http://snapshots.repository.codehaus.org/org/codehaus/mojo/webstart-maven-plugin - 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: [collections] Generifying Collections
On 10/21/06, Stephen Colebourne [EMAIL PROTECTED] wrote: Henri Yandell wrote: Why not just start a branch within Collections? I don't see why this is a new component, are we going to be advising people to use Collections 3.x on JDK 1.5+ for any reasons other than legacy or instability of our generified version? My view is to make a collections-generics branch in collections with a view to it being Collections 4.0. Because commons isn't like other OSS projects. We can't go around changing our APIs freely, even between major versions. Its a simple case of us being at the bottom of the stack of jars. If we do change an API, any API then jar hell ensues because higher OSS projects will clash on their required versions of [collections]. Thus, it has to be a new package, and this is best thought of as a new component. I'm not convinced by that. What you're saying is that if we want to have a major API change in a component, that we need to change the package name so two pieces of code can sit side by side. If that's true, then we should do it for all major versions (as major API change is the defining factor of major version changing) and stay within the same component. Having a bit of deja vu - think we had this discussion 6 months ago :) Basically - we need to start putting the major version in our package names. I hate that, but I can see the need. So this would be a branch of collections, with a package name change to org.apache.commons.collections4.*. Would be sweet to have a build system that could deal with moving source from org/apache/commons/collections/ to the correct directory and package name prior to compiing/source-packaging. Might be worth playing with some Ant scripts for that. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r467086 - /jakarta/commons/proper/scxml/trunk/xdocs/index.xml
Author: rahul Date: Mon Oct 23 12:00:43 2006 New Revision: 467086 URL: http://svn.apache.org/viewvc?view=revrev=467086 Log: Apache Shale uses Commons SCXML (more precisely, the shale-dialog-scxml module therein uses Commons SCXML). Also added a one line blurb pointing out what Commons SCXML does within the RDC taglib. Modified: jakarta/commons/proper/scxml/trunk/xdocs/index.xml Modified: jakarta/commons/proper/scxml/trunk/xdocs/index.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/scxml/trunk/xdocs/index.xml?view=diffrev=467086r1=467085r2=467086 == --- jakarta/commons/proper/scxml/trunk/xdocs/index.xml (original) +++ jakarta/commons/proper/scxml/trunk/xdocs/index.xml Mon Oct 23 12:00:43 2006 @@ -114,8 +114,11 @@ p Projects that use Commons SCXML: ul -lia href=http://jakarta.apache.org/taglibs/doc/rdc-doc/intro.html;Reusable Dialog Components (RDC)/a -tag library/li +lia href=http://jakarta.apache.org/taglibs/doc/rdc-doc/intro.html;Reusable Dialog Components (RDC)/a, +part of Apache Jakarta Taglibs - For choreographing the execution of speech components +taking part in a voice interaction bounded by a RDC group container./li +lia href=http://shale.apache.org/;Apache Shale/a - For managing the flow of control in +web based applications, using a href=http://shale.apache.org/shale-dialog/;Shale dialogs/a./li /ul /p /section - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (DIGESTER-109) FromXmlRuleSet and SetNextRule classloader issue
[ http://issues.apache.org/jira/browse/DIGESTER-109?page=comments#action_12444087 ] Anna Komaristaia commented on DIGESTER-109: --- Hi Simon, Niall and Henri, Sorry for not respond quickly. Please note that 2 exceptions are not coming together. This is the printout related to FromXmlRuleSet exception: Exception in thread AWT-EventQueue-0 java.lang.NullPointerException at org.apache.commons.digester.xmlrules.FromXmlRuleSet.addRuleInstances(FromXmlRuleSet.java:163) at org.apache.commons.digester.xmlrules.FromXmlRuleSet.addRuleInstances(FromXmlRuleSet.java:140) at org.apache.commons.digester.Digester.addRuleSet(Digester.java:1776) at org.apache.commons.digester.xmlrules.DigesterLoader.createDigester(DigesterLoader.java:79) at org.apache.commons.validator.ValidatorResources.initDigester(ValidatorResources.java:206) at org.apache.commons.validator.ValidatorResources.init(ValidatorResources.java:153) at org.apache.commons.validator.ValidatorResources.init(ValidatorResources.java:133) Once FromXmlRuleSet class was changed (URL dtdURL = getClass().getClassLoader().getResource(DIGESTER_DTD_PATH);) we can see the next exception from SetNextRule class: java.lang.NullPointerException at org.apache.commons.digester.SetNextRule.end(SetNextRule.java:203) at org.apache.commons.digester.Rule.end(Rule.java:230) at org.apache.commons.digester.Digester.endElement(Digester.java:1130) at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source) at org.apache.xerces.parsers.AbstractXMLDocumentParser.emptyElement(Unknown Source) at org.apache.xerces.impl.dtd.XMLDTDValidator.emptyElement(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanStartElement(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source) at org.apache.commons.digester.Digester.parse(Digester.java:1666) at org.apache.commons.digester.xmlrules.FromXmlRuleSet$URLXMLRulesLoader.loadRules(FromXmlRuleSet.java:197) at org.apache.commons.digester.xmlrules.FromXmlRuleSet.addRuleInstances(FromXmlRuleSet.java:176) at org.apache.commons.digester.xmlrules.FromXmlRuleSet.addRuleInstances(FromXmlRuleSet.java:140) at org.apache.commons.digester.Digester.addRuleSet(Digester.java:1776) at org.apache.commons.digester.xmlrules.DigesterLoader.createDigester(DigesterLoader.java:79) at org.apache.commons.validator.ValidatorResources.initDigester(ValidatorResources.java:206) at org.apache.commons.validator.ValidatorResources.init(ValidatorResources.java:153) at org.apache.commons.validator.ValidatorResources.init(ValidatorResources.java:133) Thank you for your help, //Anna FromXmlRuleSet and SetNextRule classloader issue --- Key: DIGESTER-109 URL: http://issues.apache.org/jira/browse/DIGESTER-109 Project: Commons Digester Issue Type: Bug Reporter: Anna Komaristaia When I start the application in Unix, there are 2 classes cause the problem: 1) The NullPointerException in FromXmlRuleSet class in the method addRuleInstances(Digester, String); 2) The NullPointerException in SetNextRule class in the method end(); Temporary solution --- I recompiled the commons-digester jar with the next changes and it's working fine in PC and Unix: Changes in the FromXmlRuleSet class 1) public static final String DIGESTER_DTD_PATH = digester-rules.dtd; 2) in the method addRuleInstances the line URL dtdURL = getClass().getClassLoader().getResource(DIGESTER_DTD_PATH); changed by URL dtdURL = this.getClass().getResource(DIGESTER_DTD_PATH); Changes In the SetNextRule class the line paramTypes[0] = digester.getClassLoader().loadClass( paramType); changed by if( digester.getClassLoader() == null ) paramTypes[0] = Class.forName(paramType); else paramTypes[0] = digester.getClassLoader().loadClass( paramType); Thanks, //Anna -- This message is automatically generated by JIRA. - If you think it was
[jira] Commented: (DIGESTER-109) FromXmlRuleSet and SetNextRule classloader issue
[ http://issues.apache.org/jira/browse/DIGESTER-109?page=comments#action_12444089 ] Henri Yandell commented on DIGESTER-109: Hi Anna, Is this a command line application or within a server of some kind such as Tomcat, JBoss, WebLogic etc? Where have the digester and validator jars been deployed? The errors seem to be suggesting that they are in something like $JAVA_HOME/jre/lib/ext. FromXmlRuleSet and SetNextRule classloader issue --- Key: DIGESTER-109 URL: http://issues.apache.org/jira/browse/DIGESTER-109 Project: Commons Digester Issue Type: Bug Reporter: Anna Komaristaia When I start the application in Unix, there are 2 classes cause the problem: 1) The NullPointerException in FromXmlRuleSet class in the method addRuleInstances(Digester, String); 2) The NullPointerException in SetNextRule class in the method end(); Temporary solution --- I recompiled the commons-digester jar with the next changes and it's working fine in PC and Unix: Changes in the FromXmlRuleSet class 1) public static final String DIGESTER_DTD_PATH = digester-rules.dtd; 2) in the method addRuleInstances the line URL dtdURL = getClass().getClassLoader().getResource(DIGESTER_DTD_PATH); changed by URL dtdURL = this.getClass().getResource(DIGESTER_DTD_PATH); Changes In the SetNextRule class the line paramTypes[0] = digester.getClassLoader().loadClass( paramType); changed by if( digester.getClassLoader() == null ) paramTypes[0] = Class.forName(paramType); else paramTypes[0] = digester.getClassLoader().loadClass( paramType); Thanks, //Anna -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://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]
Re: [math][VOTE] Accept Mantissa contribution
On 10/22/06, Phil Steitz [EMAIL PROTECTED] wrote: -- [ X ] +1 Accept the Mantissa codebase into commons-math [ ] +0 OK... [ ] -0 OK, but I have the following concerns... [ ] -1 No, because... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VFS] problem with FileObject.createFolder() / File.canWrite()
Hi VFS/Mario,
There's a problem with java.io.File.canWrite() when accessing a CIFS
share on windows with
access control lists enabled: it's plain wrong (it just checks the read
only flag iso checking the
access control list -- returning a value that has nothing to do whether
the file is actually writable
or not -- known issue on the bug parade, but seems to not going to be
fixed any time soon).
Obviously this is not a problem of VFS, except that
AbstractFileObject.createFolder()
checks the canWrite flag before attempting to create a directory --
because of this directories
on certain filesystems simply cannot be created.
Do you have a probem with taking out the if (!isWriteable()) check and
have the doCreateFolder
throw the exception itself iso having vfs throw it ? There might be
other areas where a similar
thing happens (haven't checked createFile and the likes).
It would solve a very big issue I'm having right now...
Thanks a lot,
- Filip
- AbstractFileObject:
public void createFolder() throws FileSystemException
{
synchronized (fs)
{
if (getType() == FileType.FOLDER)
{
// Already exists as correct type
return;
}
if (getType() != FileType.IMAGINARY)
{
throw new
FileSystemException(vfs.provider/create-folder-mismatched-type.error,
name);
}
if (!isWriteable())
{
throw new
FileSystemException(vfs.provider/create-folder-read-only.error, name);
}
// Traverse up the heirarchy and make sure everything is a
folder
final FileObject parent = getParent();
if (parent != null)
{
parent.createFolder();
}
try
{
// Create the folder
doCreateFolder();
// Update cached info
handleCreate(FileType.FOLDER);
}
catch (final RuntimeException re)
{
throw re;
}
catch (final Exception exc)
{
throw new
FileSystemException(vfs.provider/create-folder.error, name, exc);
}
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math][VOTE] Accept Mantissa contribution
On 10/22/06, Phil Steitz [EMAIL PROTECTED] wrote: snip/ [X] +1 Accept the Mantissa codebase into commons-math [ ] +0 OK... [ ] -0 OK, but I have the following concerns... [ ] -1 No, because... Nit, not important at this stage: * First line in NOTICE should ultimately be Apache Jakarta Commons Math -Rahul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (LANG-287) Optimize StringEscapeUtils.unescapeXml(String)
[ http://issues.apache.org/jira/browse/LANG-287?page=all ]
Stepan Koltsov updated LANG-287:
Attachment: commons-lang-unescape-performace-stepancheg-2006-10-24.diff
This is a patch, that optimizes unescape* as Holger suggested.
Optimize StringEscapeUtils.unescapeXml(String)
--
Key: LANG-287
URL: http://issues.apache.org/jira/browse/LANG-287
Project: Commons Lang
Issue Type: Improvement
Affects Versions: 2.2
Reporter: Stepan Koltsov
Priority: Minor
Attachments:
commons-lang-unescape-performace-stepancheg-2006-10-24.diff
StringEscapeUtils.unescapeXml(String) (and other unescaes) works too slowly
if String has nothing to unescape, that is very common situation.
To make unescape faster, following check should be added to be start of
Entities.unescape(str)
if (str.indexOf('') 0)
return str;
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://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]
[Daemon] Patch to fix JSVC on Mac-OS X
Hi,
Attached is a patch to fix compilation of the dynamic library glue in
JSVC. This has been tested on Mac OS X 10.4.8, and to ensure I didn't
break regular Unix support I also tested on CentOS 3. I have also
attached a patch that tidies up the replace code that replaces
occurrences of one string with another one. This simplifies the code and
avoids a possible buffer overrun.
I also have a few other changes, including some consistency fixes to the
help text and command line options. I will submit patches for them when
I have tested on both Mac OS X and Linux.
Regards,
Chris
Index: src/native/unix/native/dso.h
===
--- src/native/unix/native/dso.h(revision 467118)
+++ src/native/unix/native/dso.h(working copy)
@@ -1,12 +1,12 @@
/*
Copyright 2001-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.
@@ -14,14 +14,16 @@
limitations under the License.
*/
/* @version $Id$ */
-#include jsvc.h
-/**
- * A library handle represents a unique pointer to its location in memory.
- */
+#ifndef JSVC_DSO_H
+#define JSVC_DSO_H
+
typedef void *dso_handle;
-bool dso_init(void);
-dso_handle dso_link(const char *pth);
-bool dso_unlink(dso_handle lib);
-void *dso_symbol(dso_handle lib, const char *nam);
+int dso_init(void);
+void *dso_link(const char *);
+int dso_unlink(void *);
+void *dso_symbol(void *, const char *);
+const char *dso_error(void);
+
+#endif
Index: src/native/unix/native/dso-dlfcn.c
===
--- src/native/unix/native/dso-dlfcn.c (revision 467118)
+++ src/native/unix/native/dso-dlfcn.c (working copy)
@@ -1,55 +1,67 @@
/*
Copyright 2001-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.
*/
+
/* @version $Id$ */
-#include jsvc.h
#ifdef DSO_DLFCN
#include dlfcn.h
+#include dso.h
+#include debug.h
+
#ifdef OS_LINUX
-bool ld_library_path_set=false;
-#endif /* ifdef OS_LINUX */
+int ld_library_path_set=false;
+#endif
/* Initialize all DSO stuff */
-bool dso_init() {
-return(true);
+int
+dso_init(void)
+{
+return 1;
}
/* Attempt to link a library from a specified filename */
-dso_handle dso_link(const char *path) {
-log_debug(Attemtping to load library %s,path);
+void *
+dso_link(const char *path)
+{
+log_debug(Attempting to load library %s, path);
return((void *)dlopen(path,RTLD_GLOBAL|RTLD_NOW));
}
/* Attempt to unload a library */
-bool dso_unlink(dso_handle libr) {
-if (dlclose(libr)==0) return(true);
-else return(false);
+int
+dso_unlink(void *libr)
+{
+return dlclose(libr) == 0 ? 1 : 0;
}
-/* Get the address for a specifed symbol */
-void *dso_symbol(dso_handle hdl, const char *nam) {
-return(dlsym(hdl,nam));
+/* Get the address for a symbol */
+void *
+dso_symbol(void *hdl, const char *name)
+{
+return dlsym(hdl, name);
}
/* Return the error message from dlopen */
-char *dso_error() {
-return(dlerror());
+const char *
+dso_error(void)
+{
+return dlerror();
}
-#endif /* ifdef DSO_DLFCN */
+#endif /* DSO_DLFCN */
Index: src/native/unix/native/dso-dyld.c
===
--- src/native/unix/native/dso-dyld.c (revision 467118)
+++ src/native/unix/native/dso-dyld.c (working copy)
@@ -1,12 +1,12 @@
/*
Copyright 2001-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.
@@ -14,126 +14,161 @@
limitations under the License.
*/
/* @version $Id$ */
-#include jsvc.h
#ifdef DSO_DYLD
Re: [betwixt] What's needed for a 0.8 release ?
On Tue, 2006-10-17 at 01:19 +0200, Martin van den Bemt wrote: Highly appreciated Robert.. barring unforeseen events, i should have time on tuesday and wednesday. the infrastructure should all be back up by then. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (DIGESTER-109) FromXmlRuleSet and SetNextRule classloader issue
[ http://issues.apache.org/jira/browse/DIGESTER-109?page=comments#action_12444131 ] Anna Komaristaia commented on DIGESTER-109: --- Hi Henri, It is command line application . The digester and validator jars is stored in $DEMO_HOME/lib and they listed in the $CLASSPATH. $DEMO_HOME is my application home. my $JAVA_HOME is $DEMO_HOME/jre/solaris_sparc which contains JRE 1.5 Should I put the commons jar files in $JAVA_HOME/jre/lib/ext ? Thanks, //Anna FromXmlRuleSet and SetNextRule classloader issue --- Key: DIGESTER-109 URL: http://issues.apache.org/jira/browse/DIGESTER-109 Project: Commons Digester Issue Type: Bug Reporter: Anna Komaristaia When I start the application in Unix, there are 2 classes cause the problem: 1) The NullPointerException in FromXmlRuleSet class in the method addRuleInstances(Digester, String); 2) The NullPointerException in SetNextRule class in the method end(); Temporary solution --- I recompiled the commons-digester jar with the next changes and it's working fine in PC and Unix: Changes in the FromXmlRuleSet class 1) public static final String DIGESTER_DTD_PATH = digester-rules.dtd; 2) in the method addRuleInstances the line URL dtdURL = getClass().getClassLoader().getResource(DIGESTER_DTD_PATH); changed by URL dtdURL = this.getClass().getResource(DIGESTER_DTD_PATH); Changes In the SetNextRule class the line paramTypes[0] = digester.getClassLoader().loadClass( paramType); changed by if( digester.getClassLoader() == null ) paramTypes[0] = Class.forName(paramType); else paramTypes[0] = digester.getClassLoader().loadClass( paramType); Thanks, //Anna -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://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] Commented: (DIGESTER-109) FromXmlRuleSet and SetNextRule classloader issue
[ http://issues.apache.org/jira/browse/DIGESTER-109?page=comments#action_12444149 ] Henri Yandell commented on DIGESTER-109: Nope, don't put them there; just trying to understand why the classloader is null there. FromXmlRuleSet and SetNextRule classloader issue --- Key: DIGESTER-109 URL: http://issues.apache.org/jira/browse/DIGESTER-109 Project: Commons Digester Issue Type: Bug Reporter: Anna Komaristaia When I start the application in Unix, there are 2 classes cause the problem: 1) The NullPointerException in FromXmlRuleSet class in the method addRuleInstances(Digester, String); 2) The NullPointerException in SetNextRule class in the method end(); Temporary solution --- I recompiled the commons-digester jar with the next changes and it's working fine in PC and Unix: Changes in the FromXmlRuleSet class 1) public static final String DIGESTER_DTD_PATH = digester-rules.dtd; 2) in the method addRuleInstances the line URL dtdURL = getClass().getClassLoader().getResource(DIGESTER_DTD_PATH); changed by URL dtdURL = this.getClass().getResource(DIGESTER_DTD_PATH); Changes In the SetNextRule class the line paramTypes[0] = digester.getClassLoader().loadClass( paramType); changed by if( digester.getClassLoader() == null ) paramTypes[0] = Class.forName(paramType); else paramTypes[0] = digester.getClassLoader().loadClass( paramType); Thanks, //Anna -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://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]
Re: [collections] Generifying Collections
Tomcat has been able to do this without any real problems. Why can't we just keep the Commons Collections name (and packages, etc.), but just use the version numbers to keep it straight? Tomcat 5.5.x requires JDK5. Couldn't we just say that Commons Collections 4.x (and beyond) requires JDK5? That way, for those folks who want to upgrade, it's not very tough. For the most part, the classes/methods will have the same names. On 10/23/06, Jörg Schaible [EMAIL PROTECTED] wrote: Hi Stephen and Henri, Stephen Colebourne wrote on Saturday, October 21, 2006 5:20 PM: Henri Yandell wrote: Why not just start a branch within Collections? I don't see why this is a new component, are we going to be advising people to use Collections 3.x on JDK 1.5+ for any reasons other than legacy or instability of our generified version? My view is to make a collections-generics branch in collections with a view to it being Collections 4.0. Because commons isn't like other OSS projects. We can't go around changing our APIs freely, even between major versions. Its a simple case of us being at the bottom of the stack of jars. If we do change an API, any API then jar hell ensues because higher OSS projects will clash on their required versions of [collections]. Thus, it has to be a new package, and this is best thought of as a new component. It is also about branding. Collections is a well-known name in the community. Think of three years from now. If we declare collections 4.xneeds JDK 1.5+ now, in 3 years nobody will rermember, that the older versions did support JDK 1.3. But the name for collections still persist. That's the political reason, not to change the name. (Compare this with the JDK where they had to jump through ridiculous hoops to make generics fully backwards-compatible, and created a half-arsed mess in the process...) This is the real problem. We must use a different namespace for the Java package itself. A lot of stuff depends on c-c ( http://www.mavenregistry.com/search/artifact/19973 + http://www.mavenregistry.com/search/depended_upon_artifacts, quite impressive) and even in 3 years there will be stuff available that still depends on those old versions. A new package name solves the problem of coexistence as long as the jar name contains the version (e.g. commons-collection-3.1 commons-collection-4.2) but it creates new problems for e.g. Maven, that cannot handle two (binary distinct) versions at the same time. So there are three points to decide: - does a new package name imply a different Jakarta Commons project? - shall we give up existing brands (it means in the end the establishment of a new brand for all commons projects)? - if we keep the project name, do we have to accept the inevitable limits of popular tools such as Maven? - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] Generifying Collections
On 10/23/06, James Carman [EMAIL PROTECTED] wrote: Tomcat has been able to do this without any real problems. snip/ Because now (TC6, some in 5.5, maybe other branches too) they've package renamed dependency artifacts (digester, logging, dbcp -- and even hinted at JDT ;-). -Rahul Why can't we just keep the Commons Collections name (and packages, etc.), but just use the version numbers to keep it straight? Tomcat 5.5.x requires JDK5. Couldn't we just say that Commons Collections 4.x (and beyond) requires JDK5? That way, for those folks who want to upgrade, it's not very tough. For the most part, the classes/methods will have the same names. On 10/23/06, Jörg Schaible [EMAIL PROTECTED] wrote: Hi Stephen and Henri, Stephen Colebourne wrote on Saturday, October 21, 2006 5:20 PM: Henri Yandell wrote: Why not just start a branch within Collections? I don't see why this is a new component, are we going to be advising people to use Collections 3.x on JDK 1.5+ for any reasons other than legacy or instability of our generified version? My view is to make a collections-generics branch in collections with a view to it being Collections 4.0. Because commons isn't like other OSS projects. We can't go around changing our APIs freely, even between major versions. Its a simple case of us being at the bottom of the stack of jars. If we do change an API, any API then jar hell ensues because higher OSS projects will clash on their required versions of [collections]. Thus, it has to be a new package, and this is best thought of as a new component. It is also about branding. Collections is a well-known name in the community. Think of three years from now. If we declare collections 4.xneeds JDK 1.5+ now, in 3 years nobody will rermember, that the older versions did support JDK 1.3. But the name for collections still persist. That's the political reason, not to change the name. (Compare this with the JDK where they had to jump through ridiculous hoops to make generics fully backwards-compatible, and created a half-arsed mess in the process...) This is the real problem. We must use a different namespace for the Java package itself. A lot of stuff depends on c-c ( http://www.mavenregistry.com/search/artifact/19973 + http://www.mavenregistry.com/search/depended_upon_artifacts, quite impressive) and even in 3 years there will be stuff available that still depends on those old versions. A new package name solves the problem of coexistence as long as the jar name contains the version (e.g. commons-collection-3.1 commons-collection-4.2) but it creates new problems for e.g. Maven, that cannot handle two (binary distinct) versions at the same time. So there are three points to decide: - does a new package name imply a different Jakarta Commons project? - shall we give up existing brands (it means in the end the establishment of a new brand for all commons projects)? - if we keep the project name, do we have to accept the inevitable limits of popular tools such as Maven? - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] Generifying Collections
I think a very significant part of this problem is just the profusion of jars anyway. The real incompatibility you're worried about is when two projects are using different versions of subcomponents, or at least the multitude of subcomponents makes it that much more likely. Commons isn't that large, it doesn't have lots of outside dependencies, why not just pare it down to one (1) jar, and then the vast majority of this version trouble goes away. Mix and match is a recipe for instability anyway. Something like this. Any project can do whatever it wants. Periodically, all projects are collected together, and a single commons jar is produced. When this found to be stable, it becomes the current version. Rinse, repeat. Programs would then be strongly advised to depend on exactly 1 version of commons, etc Maybe break into 2 or 3 jars, but this whole 30 jars idea is really where the problem lies, it seems to me. Anything running in the same JVM should use the same version anyway. My $0.02. On Oct 23, 2006, at 8:06 PM, Rahul Akolkar wrote: On 10/23/06, James Carman [EMAIL PROTECTED] wrote: Tomcat has been able to do this without any real problems. snip/ Because now (TC6, some in 5.5, maybe other branches too) they've package renamed dependency artifacts (digester, logging, dbcp -- and even hinted at JDT ;-). -Rahul Why can't we just keep the Commons Collections name (and packages, etc.), but just use the version numbers to keep it straight? Tomcat 5.5.x requires JDK5. Couldn't we just say that Commons Collections 4.x (and beyond) requires JDK5? That way, for those folks who want to upgrade, it's not very tough. For the most part, the classes/methods will have the same names. On 10/23/06, Jörg Schaible [EMAIL PROTECTED] wrote: Hi Stephen and Henri, Stephen Colebourne wrote on Saturday, October 21, 2006 5:20 PM: Henri Yandell wrote: Why not just start a branch within Collections? I don't see why this is a new component, are we going to be advising people to use Collections 3.x on JDK 1.5+ for any reasons other than legacy or instability of our generified version? My view is to make a collections-generics branch in collections with a view to it being Collections 4.0. Because commons isn't like other OSS projects. We can't go around changing our APIs freely, even between major versions. Its a simple case of us being at the bottom of the stack of jars. If we do change an API, any API then jar hell ensues because higher OSS projects will clash on their required versions of [collections]. Thus, it has to be a new package, and this is best thought of as a new component. It is also about branding. Collections is a well-known name in the community. Think of three years from now. If we declare collections 4.xneeds JDK 1.5+ now, in 3 years nobody will rermember, that the older versions did support JDK 1.3. But the name for collections still persist. That's the political reason, not to change the name. (Compare this with the JDK where they had to jump through ridiculous hoops to make generics fully backwards-compatible, and created a half-arsed mess in the process...) This is the real problem. We must use a different namespace for the Java package itself. A lot of stuff depends on c-c ( http://www.mavenregistry.com/search/artifact/19973 + http://www.mavenregistry.com/search/depended_upon_artifacts, quite impressive) and even in 3 years there will be stuff available that still depends on those old versions. A new package name solves the problem of coexistence as long as the jar name contains the version (e.g. commons-collection-3.1 commons-collection-4.2) but it creates new problems for e.g. Maven, that cannot handle two (binary distinct) versions at the same time. So there are three points to decide: - does a new package name imply a different Jakarta Commons project? - shall we give up existing brands (it means in the end the establishment of a new brand for all commons projects)? - if we keep the project name, do we have to accept the inevitable limits of popular tools such as Maven? - Jörg - 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]
[jira] Commented: (MATH-160) Chi-Square Test for Comparing two binned Data Sets
[ http://issues.apache.org/jira/browse/MATH-160?page=comments#action_12444161 ] Phil Steitz commented on MATH-160: -- You are both right - Luc is correct in pointing out that we cannot use code taken or translated from Numerical Recipes (NR), nor can we implement numerical algorithms unique to NR. What we always try to do is implement standard algorithms that are documented elsewhere (i.e., find another source beyond NR). I have not looked carefully at the patch yet, but it should not be hard to find documentation for ChiSquare computed as described above. Any suggestions for sources or comments on the patch itself would be appreciated. Chi-Square Test for Comparing two binned Data Sets -- Key: MATH-160 URL: http://issues.apache.org/jira/browse/MATH-160 Project: Commons Math Issue Type: New Feature Reporter: Matthias Hummel Priority: Minor Attachments: commons-math.patch Current Chi-Square test implementation only supports standard Chi-Square testing with respect to known distribution. We needed testing for comparison of two sample data sets where the distribution can be unknown. For this case the Chi-Square test has to be computed in a different way so that both error contributions (one for each sample data set) are taken into account. See Press et. al, Numerical Recipes, Second Edition, formula 14.3.2. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://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]
[codec]Implementing support for additional non-english vowels in double metaphone
I have made some modifications to org.apache.commons.codec.language.DoubleMetaphone in order to support the three additional Norwegian and Danish vowels. The current implementation at Jakarta does not provide any methods to specify the language of the input text. Is it all right to modify DoubleMetaphone to support the Scandinavian vowels (Swedish, Danish and Norwegian) and possibly other languages or have I completely misunderstood the idea behind the double metaphone algorithm? That is, should double metaphone detect various language constructs automatically or is it perhaps a better idea to have a factory which returns a double metaphone implementation appropriate for the language? Any suggestions? I would like to contribute any changes back to Jakarta commons-codec, of course. Steinar Cook [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [betwixt] What's needed for a 0.8 release ?
On 10/23/06, robert burrell donkin [EMAIL PROTECTED] wrote: barring unforeseen events, i should have time on tuesday and wednesday. the infrastructure should all be back up by then. great, thanks! Let me know how I can help! cheers, Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
