Query about Jelly
Hello, I am not sure if this is the right place to put in technical queries, but I would be grateful if someone pointed to me the right place to do so. I am facing the following problems with Jelly 1. Using the source code available on site, I get build errors. (The build errors are resolved when I use the latest code from CVS) 2. Even for the latest code, maven dist build fails. I get the following error BUILD FAILED File.. /home/rtonk/.maven/plugins/plugins/maven-xdoc-plugin-1.7.2-SNAPSHOT/plugin.jelly Element... x:parse Line.. 356 Column 49 /home/rtonk/Softwares/jakarta-commons/commons-build/menus/menus.dtd (No such file or directory) Nested exception: /home/rtonk/Softwares/jakarta-commons/commons-build/menus/menus.dtd (No such file or directory) Total time: 6 minutes 21 seconds Finished at: Wed Jun 23 17:20:56 IST 2004 3. When I try to run jelly from bin directory, I get the following exception: Exception in thread main java.lang.NoClassDefFoundError: com/werken/forehead/Forehead Any help regarding this will be appreciated. Thanks, Ritesh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/httpclient/src/test/org/apache/commons/httpclient TestHttpState.java
olegk 2004/06/22 23:50:25
Modified:httpclient/src/java/org/apache/commons/httpclient
HttpState.java
httpclient/src/java/org/apache/commons/httpclient/auth
AuthScope.java
httpclient/src/test/org/apache/commons/httpclient
TestHttpState.java
Log:
PR #29540 (HttpState#matchCredentials is broken)
Changelog:
* Fixes credentials scope matching algorithm
Contributed by Oleg Kalnichevski
Reviewed by Michael Becke
Revision ChangesPath
1.35 +32 -30
jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/HttpState.java
Index: HttpState.java
===
RCS file:
/home/cvs/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/HttpState.java,v
retrieving revision 1.34
retrieving revision 1.35
diff -u -r1.34 -r1.35
--- HttpState.java12 Jun 2004 22:47:23 - 1.34
+++ HttpState.java23 Jun 2004 06:50:25 - 1.35
@@ -310,7 +310,7 @@
* have been explictly supplied for the challenging host. Any previous
* credentials for the given realm on the given host will be overwritten.
*
- * @param scope the authentication scope
+ * @param realm the authentication realm
* @param host the host the realm belongs to
* @param credentials the authentication [EMAIL PROTECTED] Credentials
credentials}
* for the given realm.
@@ -330,7 +330,7 @@
* Sets the [EMAIL PROTECTED] Credentials credentials} for the given
authentication
* scope. Any previous credentials for the given scope will be overwritten.
*
- * @param scope the [EMAIL PROTECTED] AuthScope authentication scope}
+ * @param authscope the [EMAIL PROTECTED] AuthScope authentication scope}
* @param credentials the authentication [EMAIL PROTECTED] Credentials
credentials}
* for the given scope.
*
@@ -355,24 +355,26 @@
* @return the credentials
*
*/
-private static Credentials matchCredentials(HashMap map, AuthScope authscope) {
-AuthScope key = authscope;
-Credentials creds = (Credentials) map.get(key);
-if (creds == null authscope.getScheme() != null) {
-key = new AuthScope(authscope.getHost(), authscope.getPort(),
authscope.getRealm());
-creds = (Credentials) map.get(key);
-}
-if (creds == null authscope.getRealm() != null) {
-key = new AuthScope(authscope.getHost(), authscope.getPort());
-creds = (Credentials) map.get(key);
-}
-if (creds == null authscope.getPort() = 0) {
-key = new AuthScope(authscope.getHost(), -1);
-creds = (Credentials) map.get(key);
-}
-if (creds == null authscope.getHost() != null) {
-key = AuthScope.ANY;
-creds = (Credentials) map.get(key);
+private static Credentials matchCredentials(final HashMap map, final AuthScope
authscope) {
+// see if we get a direct hit
+Credentials creds = (Credentials)map.get(authscope);
+if (creds == null) {
+// Nope.
+// Do a full scan
+int bestMatchFactor = -1;
+AuthScope bestMatch = null;
+Iterator items = map.keySet().iterator();
+while (items.hasNext()) {
+AuthScope current = (AuthScope)items.next();
+int factor = authscope.match(current);
+if (factor bestMatchFactor) {
+bestMatchFactor = factor;
+bestMatch = current;
+}
+}
+if (bestMatch != null) {
+creds = (Credentials)map.get(bestMatch);
+}
}
return creds;
}
@@ -389,7 +391,7 @@
* the default Credentials. If there are no default credentials, return
* codenull/code.
*
- * @param scope the authentication scope
+ * @param realm the authentication realm
* @param host the host the realm is on
* @return the credentials
*
@@ -407,7 +409,7 @@
/**
* Get the [EMAIL PROTECTED] Credentials credentials} for the given
authentication scope.
*
- * @param scope the [EMAIL PROTECTED] AuthScope authentication scope}
+ * @param authscope the [EMAIL PROTECTED] AuthScope authentication scope}
* @return the credentials
*
* @see #setCredentials(AuthScope, Credentials)
@@ -433,7 +435,7 @@
* credentials for the given proxy realm on the given proxy host will be
* overwritten.
*
- * @param scope the authentication scope
+ * @param realm the authentication realm
* @param
cvs commit: jakarta-commons/httpclient release_notes.txt
olegk 2004/06/22 23:52:53 Modified:httpclient release_notes.txt Log: PR #29540 Revision ChangesPath 1.28 +3 -0 jakarta-commons/httpclient/release_notes.txt Index: release_notes.txt === RCS file: /home/cvs/jakarta-commons/httpclient/release_notes.txt,v retrieving revision 1.27 retrieving revision 1.28 diff -u -r1.27 -r1.28 --- release_notes.txt 12 Jun 2004 23:00:40 - 1.27 +++ release_notes.txt 23 Jun 2004 06:52:53 - 1.28 @@ -2,6 +2,9 @@ --- Changes since Alpha 1: + * 29540 - Fixed credentials scope matching algorithm in HttpState#matchCredentials. + Contributed by Oleg Kalnichevski olegk at apache.org + * 29439 - Cleaner interface to define authentication scope, handle credentials in HttpState. Contributed by Oleg Kalnichevski olegk at apache.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/transaction/src/java/org/apache/commons/transaction/file FileResourceManager.java
ozeigermann2004/06/22 23:55:51
Modified:transaction/src/java/org/apache/commons/transaction/file
FileResourceManager.java
Log:
Removed dependency on thread which is non sense
Revision ChangesPath
1.4 +10 -42
jakarta-commons-sandbox/transaction/src/java/org/apache/commons/transaction/file/FileResourceManager.java
Index: FileResourceManager.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/transaction/src/java/org/apache/commons/transaction/file/FileResourceManager.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- FileResourceManager.java 12 Jun 2004 13:39:25 - 1.3
+++ FileResourceManager.java 23 Jun 2004 06:55:51 - 1.4
@@ -517,10 +517,6 @@
return PREPARE_FAILURE;
}
-if (!Thread.currentThread().equals(context.txThread)) {
-throw new ResourceManagerException(ERR_THREAD_INVALID, txId);
-}
-
synchronized (context) {
sync();
@@ -651,7 +647,7 @@
context.isLightWeight = true;
// XXX higher isolation might be needed to make sure upgrade to commit
lock always works
context.isolationLevel = ISOLATION_LEVEL_READ_COMMITTED;
-//context.isolationLevel = ISOLATION_LEVEL_REPEATABLE_READ;
+//context.isolationLevel = ISOLATION_LEVEL_REPEATABLE_READ;
globalTransactions.put(txId, context);
}
@@ -759,7 +755,7 @@
context.isLightWeight = true;
// XXX higher isolation might be needed to make sure upgrade to commit
lock always works
context.isolationLevel = ISOLATION_LEVEL_READ_COMMITTED;
-//context.isolationLevel = ISOLATION_LEVEL_REPEATABLE_READ;
+//context.isolationLevel = ISOLATION_LEVEL_REPEATABLE_READ;
globalTransactions.put(txId, context);
}
@@ -910,10 +906,6 @@
throw new ResourceManagerException(ERR_NO_TX, txId);
}
-if (!Thread.currentThread().equals(context.txThread)) {
-throw new ResourceManagerException(ERR_THREAD_INVALID, txId);
-}
-
return context;
}
@@ -1266,35 +1258,13 @@
return (globalTransactions.size() == 0);
}
-protected boolean rollbackAllTx() {
-synchronized (globalTransactions) {
-for (Iterator it = globalTransactions.values().iterator();
it.hasNext();) {
-TransactionContext context = (TransactionContext) it.next();
-logger.logInfo(Stopping + context.txId);
-context.txThread.interrupt();
-}
-return rollBackOrForward();
-}
-}
-
-protected void stopAllTx() {
-synchronized (globalTransactions) {
-for (Iterator it = globalTransactions.values().iterator();
it.hasNext();) {
-TransactionContext context = (TransactionContext) it.next();
-logger.logInfo(Killing + context.txId);
-context.txThread.interrupt();
-}
-}
-}
-
protected boolean shutdown(int mode, long timeoutMSecs) {
switch (mode) {
case SHUTDOWN_MODE_NORMAL :
return waitForAllTxToStop(timeoutMSecs);
case SHUTDOWN_MODE_ROLLBACK :
-return rollbackAllTx();
+return rollBackOrForward();
case SHUTDOWN_MODE_KILL :
-stopAllTx();
return true;
default :
return false;
@@ -1321,7 +1291,6 @@
protected long timeoutMSecs = getDefaultTransactionTimeout();
protected long startTime;
protected long commitTime = -1L;
-protected Thread txThread;
protected boolean isLightWeight = false;
protected boolean readOnly = true;
protected boolean finished = false;
@@ -1333,7 +1302,6 @@
public TransactionContext(Object txId) throws ResourceManagerException {
this.txId = txId;
startTime = System.currentTimeMillis();
-txThread = Thread.currentThread();
}
public Collection getLocks() {
@@ -1529,12 +1497,12 @@
buf.append(Long.toString(startTime)).append('\n');
if (debug) {
buf.append(- Lock Debug Info -\n);
-
+
for (Iterator it = locks.iterator(); it.hasNext();) {
MultiLevelLock lock = (MultiLevelLock) it.next();
-buf.append(lock.toString() + \n);
+buf.append(lock.toString()+\n);
}
-
+
RE: [configuration] DOM vs DOM4J
Emmanuel Bourg wrote on Tuesday, June 22, 2004 5:06 PM: Jörg Schaible wrote: Taking Paul's comment into account, there seems not to be a real sufficient solution. DOCConfiguration is quite nice for JDK = 1.4, since no additional dependency is generated. Therefore I vote in first place for the DOMConfiguration, but it might be good to have DOM4JConfiguration in e.g. commons-configuration-optional around and the possibility to tell the core to use this implementation. Comments? DOMConfiguration is even nice for JDK 1.3 since most server environnements under this version provide the standard XML APIs. I don't think [configuration] is performance critical enough to justify the use of an additional dependency, and there are other possible optimizations if a better implementation is really needed (for example the properties could be stored only once in the BaseConfiguration and the DOM parser could be dropped for a SAX parser). I tend to prefer a complete removal of the DOM4J classes to cut down the maintenance burden. Fine with me. -- Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/vfs project.xml
epugh 2004/06/23 00:26:57 Modified:vfs project.xml Log: Update dependencies to groupId/artifactId format. Revision ChangesPath 1.36 +20 -10jakarta-commons-sandbox/vfs/project.xml Index: project.xml === RCS file: /home/cvs/jakarta-commons-sandbox/vfs/project.xml,v retrieving revision 1.35 retrieving revision 1.36 diff -u -r1.35 -r1.36 --- project.xml 17 Jun 2004 19:29:28 - 1.35 +++ project.xml 23 Jun 2004 07:26:57 - 1.36 @@ -37,37 +37,44 @@ dependencies dependency -idant/id +groupIdant/groupId +artifactIdant/artifactId version1.5/version /dependency dependency -idjunit/id +groupIdjunit/groupId +artifactIdjunit/artifactId version3.8.1/version /dependency dependency -idcommons-net/id +groupIdcommons-net/groupId +artifactIdcommons-net/artifactId version1.2.1/version /dependency dependency -idcommons-logging/id +groupIdcommons-logging/groupId +artifactIdcommons-logging/artifactId version1.0.3/version /dependency dependency -idcommons-compress/id +groupIdcommons-compress/groupId +artifactIdcommons-compress/artifactId version20040530/version /dependency dependency -idcommons-collections/id +groupIdcommons-collections/groupId +artifactIdcommons-collections/artifactId version20040616/version /dependency dependency -idjcifs/id +groupIdjcifs/groupId +artifactIdjcifs/artifactId version0.8.3/version /dependency @@ -78,17 +85,20 @@ /dependency dependency -idcommons-httpclient/id +groupIdcommons-httpclient/groupId +artifactIdcommons-httpclient/artifactId version2.0/version /dependency dependency -idjsch/id +groupIdjsch/groupId +artifactIdjsch/artifactId version0.1.14/version /dependency dependency -idxml-apis/id +groupIdxml-apis/groupId +artifactIdxml-apis/artifactId version1.0.b2/version /dependency /dependencies - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Why are various reports in /sandbox-build/project.xml commented out
Hi all, I was merrily trying to build [vfs] and wondered where all the unit tests had gone! I looked, and discovered that /sandbox-build/project.xml has the unit tests reports etc, but they are commented out. Before I removed the commented out marks, I thought I might check and see if there was a reason for this? Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang] Equalator?
Yes, I think the naming idea is good.. ConfigurationComparator probably should have been a method on some sort of ConfigurationUtils class, as the name is confusing... Eric -Original Message- From: Emmanuel Bourg [mailto:[EMAIL PROTECTED] Sent: Monday, June 21, 2004 9:02 PM To: Jakarta Commons Developers List Subject: Re: [lang] Equalator? Edelson, Justin wrote: I'm writing a few classes that currently implement Comparator, but I really don't care about comparisons - I just want to use an object to test equality, ergo Equalator. Does such an interface exist somewhere in lang (I can't find anything similar). We have a simiar interface in [configuration], that's ConfigurationComparator, it defines a simple compare(conf1, conf2) method returning a boolean. I'm not quite satisfied with the name since it leads to think it inherits the java.util.Comparator interface. An Equalator interface in [lang] could be a good replacement. 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]
cvs commit: jakarta-commons-sandbox/vfs project.xml
epugh 2004/06/23 00:45:01 Modified:vfs project.xml Log: JUnit is not required, Maven will provide it. Revision ChangesPath 1.37 +0 -6 jakarta-commons-sandbox/vfs/project.xml Index: project.xml === RCS file: /home/cvs/jakarta-commons-sandbox/vfs/project.xml,v retrieving revision 1.36 retrieving revision 1.37 diff -u -r1.36 -r1.37 --- project.xml 23 Jun 2004 07:26:57 - 1.36 +++ project.xml 23 Jun 2004 07:45:01 - 1.37 @@ -43,12 +43,6 @@ /dependency dependency -groupIdjunit/groupId -artifactIdjunit/artifactId -version3.8.1/version -/dependency - -dependency groupIdcommons-net/groupId artifactIdcommons-net/artifactId version1.2.1/version - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vfs] FileSystemManager construction rethought
Hello Rami, here are some thoughts about configuration: *) GlobalConfiguration: As you have seen, the StandardFileSystemManager currently uses an xml file to configure the system. I tried to replace the parsing of the xml file by commons-digester beanutils but failed as it comes to the point to add those dependencies to vfs. Other people vetoed against it (Too large jars) If i had ever finished this new configuration parsing the result would be a object structure useable to pass to the DefaultFileSystemManager. The GlobalConfiguration is one of the relicts of this try and maybe i will remove it and place its current members to the DefaultFileSystemManager. *) FileSystemConfigBuilder: Is the try to configure various aspects of a FileSystem (e.g. for http proxy authentication, for sftp the key location, ...) So the container for all those options is a instance of FileSystemOptions, but there are no public methods to add configuration parameters into it. Every filesystem which could be configured do have its own FileSystemConfigBuild e.g. for sftp this is SftpFileSystemConfigBuilder. Now the idea behind this construct was to have a typesafe configuration framework. FileSystemOptions opts = new FileSystemOptions(); SftpFileSystemConfigBuilder.getInstance().setKnownHosts(opts, new File(path-to-your-known_hosts-file)); HttpFileSystemConfigBuilder.getInstance().setProxyHost(ops, proxy.domain.org); On resolveFile it is possible to pass this opts in and if it comes to the sftp-filesystem it picks its options out of opts. Currently this is the only way to pass options into the system, but for sure, we need a method on the DefaultFileSystemManager to set the defaults and allow some kind of override of this options at resolveFile(). Conclusion: IMHO you could finish your work without loose your time with handling of FileSystemOptions - this is a complicate part on its own, to make this work in ant and from the xml configuration we need reflection. Drop your FileSystemConfiguration and replace it by a simple string which holds the class for the filesystem manager. I will have a look at GlobalConfiguration (and maybe drop it too) and find some way how to pass in a global/defaults/... FileSystemOptions object. One question that arose is that why would someone want to write a different FileSystemManager implementation. Could the DefaultFileSystemManager be made so configurable that this would not be needed? One reason could be not to use the xml file for configuration, but write a custom FileSystemManager which does the whole configuration in code. -- Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [vfs] FileSystemManager construction rethought
Mario Ivankovits wrote on Wednesday, June 23, 2004 9:48 AM: Hello Rami, here are some thoughts about configuration: *) GlobalConfiguration: As you have seen, the StandardFileSystemManager currently uses an xml file to configure the system. I tried to replace the parsing of the xml file by commons-digester beanutils but failed as it comes to the point to add those dependencies to vfs. Other people vetoed against it (Too large jars) If i had ever finished this new configuration parsing the result would be a object structure useable to pass to the DefaultFileSystemManager. The GlobalConfiguration is one of the relicts of this try and maybe i will remove it and place its current members to the DefaultFileSystemManager. Why not use a lightweight XML-Java mapper like XStream or directly xpp3 ? -- Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[vfs] running unit tests for Http provider
Hi, I wanted to look into using VFS in a project. I downloaded it and tried out the unit tests. I am getting quite a few unit test failures, revolving around the fact that I am missing test.hostname and test.path. In order to run the unittests (specifially for the http provider) what kind of http website do I need? I believe it is a readonly provider, right? I tried doing this: test.hostname=www.ibiblio.org test.path=/maven But now it fails on not finding a directory www.ibiblio.rog/maven/read-data. Is it possible to a) Stick up docs on how to build and run the unit tests w/ what exteranal dependencies there are. b) change the unit tests so that if we are donig a readonly test, we could maybe point to files or something that are on a public website, like maybe the VFS website? Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [configuration] DOM vs DOM4J
It'll be in CVS if we come up with a reason to reimplement it... Eric -Original Message- From: Jörg Schaible [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 23, 2004 9:19 AM To: Jakarta Commons Developers List Subject: RE: [configuration] DOM vs DOM4J Emmanuel Bourg wrote on Tuesday, June 22, 2004 5:06 PM: Jörg Schaible wrote: Taking Paul's comment into account, there seems not to be a real sufficient solution. DOCConfiguration is quite nice for JDK = 1.4, since no additional dependency is generated. Therefore I vote in first place for the DOMConfiguration, but it might be good to have DOM4JConfiguration in e.g. commons-configuration-optional around and the possibility to tell the core to use this implementation. Comments? DOMConfiguration is even nice for JDK 1.3 since most server environnements under this version provide the standard XML APIs. I don't think [configuration] is performance critical enough to justify the use of an additional dependency, and there are other possible optimizations if a better implementation is really needed (for example the properties could be stored only once in the BaseConfiguration and the DOM parser could be dropped for a SAX parser). I tend to prefer a complete removal of the DOM4J classes to cut down the maintenance burden. Fine with me. -- 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]
cvs commit: jakarta-commons-sandbox/vfs/xdocs api.xml
epugh 2004/06/23 00:59:14
Modified:vfs/xdocs api.xml
Log:
Make code example compile!
Revision ChangesPath
1.9 +2 -2 jakarta-commons-sandbox/vfs/xdocs/api.xml
Index: api.xml
===
RCS file: /home/cvs/jakarta-commons-sandbox/vfs/xdocs/api.xml,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- api.xml 17 May 2004 17:56:57 - 1.8
+++ api.xml 23 Jun 2004 07:59:14 - 1.9
@@ -47,10 +47,10 @@
// List the children of the Jar file
FileObject[] children = jarFile.getChildren();
-System.println( Children of + jarFile.getName().getURI() );
+System.out.println( Children of + jarFile.getName().getURI() );
for ( int i = 0; i children.length; i++ )
{
-System.println( children[ i ].getName().getBaseName() );
+System.out.println( children[ i ].getName().getBaseName() );
}
]]/source
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vfs] running unit tests for Http provider
Eric Pugh wrote: But now it fails on not finding a directory www.ibiblio.rog/maven/read-data. Is it possible to a) Stick up docs on how to build and run the unit tests w/ what exteranal dependencies there are. b) change the unit tests so that if we are donig a readonly test, we could maybe point to files or something that are on a public website, like maybe the VFS website? a) This might be possible, and for sure, completing the documentation should be a top priority ... but you know ;-) b) Not sure why we should provide a read-only test server for vfs as there are many write-tests one should do too. And the vfs tests expect a certain amount of files/directories and their content. And even if we are try to do this, think of the various different filesystem: sftp, smb, webdav, ... However i use a UML-Linux (UserModeLinux - something like vmware but for linux only) server which is configured in a manner that the vfs tests can pass (read and write). On every restart of this uml-linux instance the whole system is in a clear state and every update has been rollbacked. If it is allowed to provide a e.g. 70 MB download at apache i could simply upload it and everyone can use it to do the tests. -- Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/jelly maven.xml
polx2004/06/23 01:12:01
Modified:jellymaven.xml
Log:
Adding the pack-fat-jar with a full set of default values.
paul
Revision ChangesPath
1.72 +3 -2 jakarta-commons/jelly/maven.xml
Index: maven.xml
===
RCS file: /home/cvs/jakarta-commons/jelly/maven.xml,v
retrieving revision 1.71
retrieving revision 1.72
diff -u -r1.71 -r1.72
--- maven.xml 24 May 2004 21:39:35 - 1.71
+++ maven.xml 23 Jun 2004 08:12:01 - 1.72
@@ -344,7 +344,8 @@
!-- this goal isn't really much tested yet but could be the key
to get a better packaging --
- property name=tagLibs value=/
+ property name=tagLibs
value=ant,bean,beanshell,betwixt,define,dynabean,fmt,html,http,interaction,junit,jsl,log,swing,threads,util,validate,velocity,xml,xmlunit/
+ !-- arbitrary set of taglibs with dependencies that should
have no problems --
property name=doBuildAll value=false/
property name=fatJarPath value=${maven.build.dir}/fatjelly.jar/
property name=classpathFile
value=${maven.build.dir}/classpath-with-deps.txt/
@@ -407,7 +408,7 @@
!-- merging it all --
j:if test=${'' ne fatJarPath}
- jar destfile=${fatJarPath}
+ jar destfile=${fatJarPath} update=yes
manifest
attribute name=Main-Class
value=org.apache.commons.jelly.Jelly//manifest
j:forEach var=dep items=${deps}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Query about Jelly
On 23-Jun-04, at 08:40 Uhr, Ritesh Tonk wrote: I am not sure if this is the right place to put in technical queries, but I would be grateful if someone pointed to me the right place to do so. I am facing the following problems with Jelly 1. Using the source code available on site, I get build errors. (The build errors are resolved when I use the latest code from CVS) We need a newer release... that's a known fact only prevented from by time... 2. Even for the latest code, maven dist build fails. I get the following error BUILD FAILED File.. /home/rtonk/.maven/plugins/plugins/maven-xdoc-plugin-1.7.2-SNAPSHOT/ plugin.jelly Element... x:parse Line.. 356 Column 49 /home/rtonk/Softwares/jakarta-commons/commons-build/menus/menus.dtd (No such file or directory) Nested exception: /home/rtonk/Softwares/jakarta-commons/commons-build/menus/menus.dtd (No such file or directory) Total time: 6 minutes 21 seconds Finished at: Wed Jun 23 17:20:56 IST 2004 This tastes like you need to checkout the commons-build as well... For some reason, web-site and documentation are the same thing (maybe that should be tackled) so that it tries to build the web-site for the distribution which involves common things in jakarta-commons... Indeed it shows a bone... 3. When I try to run jelly from bin directory, I get the following exception: Exception in thread main java.lang.NoClassDefFoundError: com/werken/forehead/Forehead well sure, that's just the source bin... Try running maven pack-fat-jar, this will create target/fatjelly.jar, an 8Mb archive which is a merge of all the jars needed in order to run jelly with the taglibs: ant,bean,beanshell,betwixt,define,dynabean,fmt,html,http,interaction,jun it,jsl,log,swing,threads,util,validate,velocity,xml, and xmlunit. This doesn't make a jelly command but you can make your own as it is a double-clickable-jar (well, Usage: jelly [scriptFile] [-script scriptFile -o outputFile -Dsysprop=syspropval]) Hope that helps. Indeed, a bug should be filed about the inappropriateness of the dist dependency on the commons-build. paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vfs] running unit tests for Http provider
Http webdav configuration:
Server version: Apache/1.3.26
/etc/apache/httpd.conf
--- snip
#
# VFSTEST
#
Alias /vfstest /vfstest/
Location /
DAV On
Options Indexes MultiViews
AllowOverride None
AuthType Basic
AuthName vfstest_zone
AuthUserFile /etc/apache/passwd
Limit PUT POST DELETE PROPFIND PROPPATCH MKCOL COPY MOVE LOCK
UNLOCK
Require user vfsusr
/Limit
/Location
--- snip ---
Direcotry-structure of /vfstest:
vfstest
vfstest/write-tests
vfstest/read-tests
vfstest/read-tests/emptydir
vfstest/read-tests/file1.txt
vfstest/read-tests/dir1
vfstest/read-tests/dir1/file1.txt
vfstest/read-tests/dir1/file2.txt
vfstest/read-tests/dir1/file3.txt
vfstest/read-tests/dir1/subdir1
vfstest/read-tests/dir1/subdir1/file1.txt
vfstest/read-tests/dir1/subdir1/file2.txt
vfstest/read-tests/dir1/subdir1/file3.txt
vfstest/read-tests/dir1/subdir2
vfstest/read-tests/dir1/subdir2/file1.txt
vfstest/read-tests/dir1/subdir2/file2.txt
vfstest/read-tests/dir1/subdir2/file3.txt
vfstest/read-tests/dir1/subdir3
vfstest/read-tests/dir1/subdir3/file1.txt
vfstest/read-tests/dir1/subdir3/file2.txt
vfstest/read-tests/dir1/subdir3/file3.txt
vfstest/read-tests/empty.txt
vfstest/code
vfstest/code/sealed
vfstest/code/sealed/AnotherClass.class
vfstest/code/ClassToLoad.class
You will find the files needed for read-tests and code in
test-data in the vfs repository.
As i use ant for build i simply added the configuration in my build.xml
into the internal-test target.
property name=test.user value=vfsusr /
property name=test.password value=vfsusr /
property name=test.hostname value=vfstest /
property name=test.path value=/vfstest /
sysproperty key=test.smb.uri
value=smb://${test.user}:[EMAIL PROTECTED]/${test.user}${test.path}/
sysproperty key=test.ftp.uri
value=ftp://${test.user}:[EMAIL PROTECTED]/
sysproperty key=test.http.uri
value=http://${test.hostname}${test.path}/
sysproperty key=test.webdav.uri
value=webdav://${test.user}:[EMAIL PROTECTED]/
sysproperty key=test.sftp.uri
value=sftp://${test.user}:[EMAIL PROTECTED]/home/${test.user}${test.path}/
Hope this helps a little bit.
--
Mario
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/transaction/src/java/org/apache/commons/transaction/util/xa - New directory
ozeigermann2004/06/23 01:40:53 jakarta-commons-sandbox/transaction/src/java/org/apache/commons/transaction/util/xa - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/transaction/src/java/org/apache/commons/transaction/util/xa AbstractXAResource.java TransactionalResource.java
ozeigermann2004/06/23 01:40:58
Added: transaction/src/java/org/apache/commons/transaction/util/xa
AbstractXAResource.java TransactionalResource.java
Log:
Added initial version of unified helper code for XAResource implementations
Revision ChangesPath
1.1
jakarta-commons-sandbox/transaction/src/java/org/apache/commons/transaction/util/xa/AbstractXAResource.java
Index: AbstractXAResource.java
===
/*
* $Header:
/home/cvs/jakarta-commons-sandbox/transaction/src/java/org/apache/commons/transaction/util/xa/AbstractXAResource.java,v
1.1 2004/06/23 08:40:58 ozeigermann Exp $
* $Revision: 1.1 $
* $Date: 2004/06/23 08:40:58 $
*
*
*
* Copyright 2004 The Apache Software Foundation
*
* Licensed under the Apache License, Version 2.0 (the License);
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an AS IS BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*
*/
package org.apache.commons.transaction.util.xa;
import java.util.HashMap;
import java.util.Map;
import javax.transaction.Status;
import javax.transaction.xa.XAException;
import javax.transaction.xa.XAResource;
import javax.transaction.xa.Xid;
import org.apache.commons.transaction.util.LoggerFacade;
/**
* Abstract XAResource doing all the tedious tasks shared by many XAResouce
implementations.
*/
public abstract class AbstractXAResource implements XAResource, Status {
// there might be at least one active transaction branch per thread
private ThreadLocal activeTransactionBranch = new ThreadLocal();
private Map suspendedContexts = new HashMap();
private Map activeContexts = new HashMap();
public abstract boolean isSameRM(XAResource xares) throws XAException;
public abstract Xid[] recover(int flag) throws XAException;
protected abstract LoggerFacade getLogger();
public void forget(Xid xid) throws XAException {
getLogger().logFine(Preparing transaction branch + xid);
setCurrentlyActiveTransactionalResource(null);
removeActiveTransactionalResource(xid);
}
public void commit(Xid xid, boolean onePhase) throws XAException {
TransactionalResource ts = getActiveTransactionalResource(xid);
if (ts == null) {
throw new XAException(XAException.XAER_NOTA);
}
getLogger().logFine(Committing transaction branch + ts);
if (ts.getStatus() == STATUS_MARKED_ROLLBACK) {
throw new XAException(XAException.XA_RBROLLBACK);
}
if (ts.getStatus() != STATUS_PREPARED) {
if (onePhase) {
ts.prepare();
} else {
throw new XAException(XAException.XAER_PROTO);
}
}
ts.commit();
setCurrentlyActiveTransactionalResource(null);
removeActiveTransactionalResource(xid);
}
public void rollback(Xid xid) throws XAException {
TransactionalResource ts = getActiveTransactionalResource(xid);
if (ts == null) {
throw new XAException(XAException.XAER_NOTA);
}
getLogger().logFine(Rolling back transaction branch + ts);
ts.commit();
setCurrentlyActiveTransactionalResource(null);
removeActiveTransactionalResource(xid);
}
public int prepare(Xid xid) throws XAException {
TransactionalResource ts = getActiveTransactionalResource(xid);
if (ts == null) {
throw new XAException(XAException.XAER_NOTA);
}
getLogger().logFine(Preparing transaction branch + ts);
if (ts.getStatus() == STATUS_MARKED_ROLLBACK) {
throw new XAException(XAException.XA_RBROLLBACK);
}
return ts.prepare();
}
public void end(Xid xid, int flags) throws XAException {
TransactionalResource ts = getActiveTransactionalResource(xid);
if (ts == null) {
throw new XAException(XAException.XAER_NOTA);
}
if (getCurrentlyActiveTransactionalResource() == null) {
throw new XAException(XAException.XAER_INVAL);
}
getLogger().logFine(
Thread
+ Thread.currentThread()
+ (flags == TMSUSPEND ?
cvs commit: jakarta-commons-sandbox/transaction/src/java/org/apache/commons/transaction/util/xa XidWrapper.java
ozeigermann2004/06/23 01:42:36
Added: transaction/src/java/org/apache/commons/transaction/util/xa
XidWrapper.java
Removed: transaction/src/java/org/apache/commons/transaction/util
XidWrapper.java
Log:
Moved XidWrapper into newly created xa package
Revision ChangesPath
1.1
jakarta-commons-sandbox/transaction/src/java/org/apache/commons/transaction/util/xa/XidWrapper.java
Index: XidWrapper.java
===
/*
* $Header:
/home/cvs/jakarta-commons-sandbox/transaction/src/java/org/apache/commons/transaction/util/xa/XidWrapper.java,v
1.1 2004/06/23 08:42:36 ozeigermann Exp $
* $Revision: 1.1 $
* $Date: 2004/06/23 08:42:36 $
*
*
*
* Copyright 1999-2002 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.
*
*/
package org.apache.commons.transaction.util.xa;
import javax.transaction.xa.Xid;
import java.lang.Object;
//import java.util.Arrays;
import java.lang.String;
/**
* Wraps an codeXid/code to guarantee methods for equality and hashcode are
* implemented correctly. This is escpecially necessary when the codeXid/code is
used as a key in a codeHashMap/code.
*
* @version $Revision: 1.1 $
*
*/
public class XidWrapper implements Xid {
public static final Xid wrap(Xid xid) {
return wrap(xid, false); // for Slide branch qualifier must not be included
in onePhase commit
}
public static final Xid wrap(Xid xid, boolean includeBranch) {
return (xid instanceof XidWrapper ? xid : new XidWrapper(xid,
includeBranch));
}
private final Xid xid;
private final String asString;
private final int hashCode;
private XidWrapper(Xid xid, boolean includeBranch) {
this.xid = xid;
// do calculations once for performance
asString =
new String(xid.getGlobalTransactionId())
+ (includeBranch ? - + new String(xid.getBranchQualifier()) : );
hashCode = asString.hashCode();
}
public Xid getXid() {
return xid;
}
public int getFormatId() {
return xid.getFormatId();
}
public byte[] getGlobalTransactionId() {
return xid.getGlobalTransactionId();
}
public byte[] getBranchQualifier() {
return xid.getBranchQualifier();
}
public boolean equals(Object o) {
return (o != null asString.equals(o.toString()));
/*
if (this == o) {
return true;
}
if (o != null o instanceof Xid) {
Xid xid2 = (Xid) o;
// we do not need equality of format Id
return (
Arrays.equals(xid.getGlobalTransactionId(),
xid2.getGlobalTransactionId())
Arrays.equals(xid.getBranchQualifier(),
xid2.getBranchQualifier()));
}
return false;
*/
}
public String toString() {
return asString;
}
public int hashCode() {
return hashCode;
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [vfs] running unit tests for Http provider
As I dig more into it.. I see your challenges with testing! All the different platforms means a LOT of external dependencies. Something that could be an approach would be to have two modes: Real and Mock.. You could Mock all the various platforms so that if someone is testing the logic of VFS, they can run without having smb/webdav etc. Then, to test that the real world works, then you switch to Real mode, and run against smb and webdav etc. On the other hand, if you have a system setup to do this, and can therefore run the tests for real, then maybe this isn't worth all the work. The HTTP one does though seem like an easy one to provide since the HTTP is a read only provider.. But again, if you have a system, then that works.. Eric -Original Message- From: Mario Ivankovits [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 23, 2004 10:06 AM To: Jakarta Commons Developers List Subject: Re: [vfs] running unit tests for Http provider Eric Pugh wrote: But now it fails on not finding a directory www.ibiblio.rog/maven/read-data. Is it possible to a) Stick up docs on how to build and run the unit tests w/ what exteranal dependencies there are. b) change the unit tests so that if we are donig a readonly test, we could maybe point to files or something that are on a public website, like maybe the VFS website? a) This might be possible, and for sure, completing the documentation should be a top priority ... but you know ;-) b) Not sure why we should provide a read-only test server for vfs as there are many write-tests one should do too. And the vfs tests expect a certain amount of files/directories and their content. And even if we are try to do this, think of the various different filesystem: sftp, smb, webdav, ... However i use a UML-Linux (UserModeLinux - something like vmware but for linux only) server which is configured in a manner that the vfs tests can pass (read and write). On every restart of this uml-linux instance the whole system is in a clear state and every update has been rollbacked. If it is allowed to provide a e.g. 70 MB download at apache i could simply upload it and everyone can use it to do the tests. -- Mario - 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]
[all] site generation
Hi, quick question from a newcomer, is there an established procedure to trigger the generation of the various jakarta-commons sites ? I'd like to refresh the [configuration] site. Is it ok to: - execute 'maven site' directly on minotaur, or should I upload the generated files from another computer ? - install a cron job to do it automatically ? By the way, I noticed that maven wasn't installed on minotaur, it seems everyone is installing it in its home directory. That's a significant waste of space since the local repository is duplicated on each account (building [configuration] took 30M just for maven). Is there a shared local repository available somewhere ? Emmanuel Bourg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [configuration] DOM vs DOM4J
And what about donating the code to the dom4j project if you decide to remove it? Maarten Eric Pugh wrote: It'll be in CVS if we come up with a reason to reimplement it... Eric -Original Message- From: Jörg Schaible [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 23, 2004 9:19 AM To: Jakarta Commons Developers List Subject: RE: [configuration] DOM vs DOM4J Emmanuel Bourg wrote on Tuesday, June 22, 2004 5:06 PM: Jörg Schaible wrote: Taking Paul's comment into account, there seems not to be a real sufficient solution. DOCConfiguration is quite nice for JDK = 1.4, since no additional dependency is generated. Therefore I vote in first place for the DOMConfiguration, but it might be good to have DOM4JConfiguration in e.g. commons-configuration-optional around and the possibility to tell the core to use this implementation. Comments? DOMConfiguration is even nice for JDK 1.3 since most server environnements under this version provide the standard XML APIs. I don't think [configuration] is performance critical enough to justify the use of an additional dependency, and there are other possible optimizations if a better implementation is really needed (for example the properties could be stored only once in the BaseConfiguration and the DOM parser could be dropped for a SAX parser). I tend to prefer a complete removal of the DOM4J classes to cut down the maintenance burden. Fine with me. -- 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vfs] running unit tests for Http provider
Eric Pugh wrote:
Something that
could be an approach would be to have two modes: Real and Mock..
Well, i use the local file provider to test if i do global changes on
vfs, it is easy to setup and the core of vfs is tested well.
For this, and if i have problems with a special filesystem i use a
RunTest class.
If this test passes, i startup my uml-linux and trigger the whole test
chain.
But again, if you have a system, then that works..
And never ever there should be a commit to vfs without testing the
change against this system using ALL filesystems.
If you are interested in this uml-linux server, just drop me a note.
---RunTest---
package org.apache.commons.vfs.test;
import junit.framework.AssertionFailedError;
import junit.framework.Test;
import junit.framework.TestResult;
import org.apache.commons.vfs.provider.webdav.test.WebdavProviderTestCase;
import java.util.Properties;
public class RunTest
{
public static void main(String[] args) throws Exception
{
Properties props = System.getProperties();
props.setProperty(test.data.src, src/test-data);
props.setProperty(test.basedir, target/test-data);
props.setProperty(test.policy, src/test-data/test.policy);
props.setProperty(test.secure, false);
props.setProperty(test.smb.uri,
smb://vfsusr:[EMAIL PROTECTED]/vfsusr/vfstest);
props.setProperty(test.ftp.uri,
ftp://vfsusr:[EMAIL PROTECTED]/vfstest);
props.setProperty(test.http.uri, http://vfstest/vfstest;);
props.setProperty(test.webdav.uri,
webdav://vfsusr:[EMAIL PROTECTED]/vfstest);
props.setProperty(test.sftp.uri,
sftp://vfsusr:[EMAIL PROTECTED]/home/vfsusr/vfstest);
Test test;
// test = FtpProviderTestCase.suite();
// test = HttpProviderTestCase.suite();
// test = LocalProviderTestCase.suite();
// test = JarProviderTestCase.suite();
// test = ZipProviderTestCase.suite();
// test = TemporaryProviderTestCase.suite();
test = WebdavProviderTestCase.suite();
// test = UrlProviderTestCase.suite();
// test = SmbProviderTestCase.suite();
// test = SftpProviderTestCase.suite();
TestResult result = new TestResult()
{
public synchronized void addError(Test test, Throwable
throwable)
{
throwable.printStackTrace();
}
public synchronized void addFailure(Test test,
AssertionFailedError assertionFailedError)
{
assertionFailedError.printStackTrace();
}
};
test.run(result);
}
}
---RunTest---
--
Mario
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/transaction/xdocs/maps - New directory
ozeigermann2004/06/23 03:08:42 jakarta-commons-sandbox/transaction/xdocs/maps - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[General] How do I upload generated docs to the WebSite
s.o. Cheers and thanks in advance, Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/transaction/xdocs navigation.xml wrappers-comparision.xml
ozeigermann2004/06/23 03:19:05 Modified:transaction/xdocs navigation.xml Added: transaction/xdocs/maps wrappers-comparision.xml index.xml Removed: transaction/xdocs wrappers-comparision.xml Log: Added map section Revision ChangesPath 1.1 jakarta-commons-sandbox/transaction/xdocs/maps/wrappers-comparision.xml Index: wrappers-comparision.xml === ?xml version=1.0? document properties titleComparision of transactional map wrappers/title author email=[EMAIL PROTECTED]Commons Documentation Team/author /properties body section name=Comparision of transactional map wrappers p /p table summary= border=1 frame=HSIDES rules=GROUPS width=100% cellpadding=3 cellspacing=0 dir=ltr title= thead tr th align=left valign=bottom scope=col/th th align=left valign=bottom scope=col font face=Arial, Helvetica, sans-serifstrongTransactionalMapWrapper/strong/font/th th align=left valign=bottom scope=col font face=Arial, Helvetica, sans-serifstrongOptimisticMapWrapper/strong/font/th th align=left valign=bottom scope=col font face=Arial, Helvetica, sans-serifstrongPessimisticMapWrapper/strong/font/th /tr /thead tbody tr align=left valign=top td pDirty write / lost updates/p /td td pPossible/p /td td pNot possible/p /td td pNot possible/p /td /tr tr align=left valign=top td pDirty read/p /td td pNot possible/p /td td pNot possible/p /td td pNot possible/p /td /tr tr align=left valign=top td pNonrepeatable read/p /td td pPossible/p /td td pNot possible/p /td td pNot possible/p /td /tr tr align=left valign=top td pPhantoms/p /td td pPossible/p /td td pNot possible/p /td td pNot possible/p /td /tr tr align=left valign=top td pReaders block writers/p /td td pNo/p /td td pNo/p /td td pYes/p /td /tr tr align=left valign=top td pWriters block readers/p /td td pNo/p /td td pNo/p /td td pYes/p /td /tr tr align=left valign=top td pWriters block writers/p /td td pNo/p /td td pNo/p /td td pYes/p /td /tr tr align=left valign=top td pMight deadlock/p /td td pNo/p /td td pNo/p /td td pYes/p /td /tr tr align=left valign=top td pCommit might fail/p /td td pNo/p /td td pYes/p /td td pNo/p /td /tr /tbody /table /section /body /document 1.1 jakarta-commons-sandbox/transaction/xdocs/maps/index.xml Index: index.xml === ?xml version=1.0? document properties titleTransactional Map Wrappers/title author email=[EMAIL PROTECTED]Commons Documentation Team/author /properties body section name=Transactional Map Wrappers pOne major part of the Transaction Component are a set of wrappers that allow to add transactional control to any kind of Map implemening the codejava.util.Map/code interface./p p You can find a comparison of its transaction features a href=wrappers-comparision.htmlhere/a. /p /section /body /document 1.2 +3 -0 jakarta-commons-sandbox/transaction/xdocs/navigation.xml Index: navigation.xml === RCS file: /home/cvs/jakarta-commons-sandbox/transaction/xdocs/navigation.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- navigation.xml22 May 2004 12:39:55 - 1.1 +++ navigation.xml23 Jun 2004 10:19:05 - 1.2 @@ -5,6 +5,9 @@ body menu name=Commons#xA0;Transaction item name=Overview href=/index.html / +item name=Transactional Maps href=/maps/index.html + item name=Map Wrapper comparision href=/maps/wrappers-comparision.html/ +/item !--item name=Configuration href=/configuration.html / -- item name=API#xA0;Documentationhref=/apidocs/index.html/ !-- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [General] How do I upload generated docs to the WebSite
This is what i got as answer if i asked for this some time ago ;-) What I do in commons-net. maven site And your target/docs directory should have your site locally. To deploy that generated site: maven site:sshdeploy If you want to generate and deploy in one step: maven site:deploy And it worked ! -- Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vfs] FileSystemManager construction rethought
I tried to replace the parsing of the xml file by commons-digester beanutils but failed as it comes to the point to add those dependencies to vfs. Other people vetoed against it (Too large jars) That is a shame. But isn't it so that we should first come up with a configuration structure (data structure and configuration policy) for vfs independent of where we get the actual data to this data structure. Since it takes a lot of data to configure FileSystemManager it is obvious that we need xml file to hold this data. And the current xml structure is a good start. Now the idea behind this construct was to have a typesafe configuration framework. The configuration container could IMHO be not type safe. Because once you call configure() right after instantiation the filesystem manager passes provider specific configuration to providers and all the providers would configure themselves too. And any missing or erroneous stuff would be reported at that point. Which to me would be a very natural point for letting the user know that something is wrong in his configuration file. The configuration data structure could mention the providers and their data types making it type safe. Anyway, now it seems to me overly complex when the issue is quite simple. In the simplest case we would just need a naming convention and meaning for different configuration elements. Example: Sftp provider accepts the following configuration elements - sftp.known-hosts A path (String) that must point to a valid known-hosts file - sftp.private-key A path (String) that must point to a valid private key file in XXX encoding ... This same configuration data structure class could be used when overriding in case of resolveFile() One question that arose is that why would someone want to write a different FileSystemManager implementation. Could the DefaultFileSystemManager be made so configurable that this would not be needed? One reason could be not to use the xml file for configuration, but write a custom FileSystemManager which does the whole configuration in code. Is this really reason enough for the added complexity? - rami - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [vfs] running unit tests for Http provider
I would love to try out uml-linux.. Unfortunantly I'm a windows user who
has just dipped his toe in linux waters, so it'll be a while until I'm up to
running uml-linux.
Eric
-Original Message-
From: Mario Ivankovits [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 23, 2004 11:56 AM
To: Jakarta Commons Developers List
Subject: Re: [vfs] running unit tests for Http provider
Eric Pugh wrote:
Something that
could be an approach would be to have two modes: Real and Mock..
Well, i use the local file provider to test if i do global changes on
vfs, it is easy to setup and the core of vfs is tested well.
For this, and if i have problems with a special filesystem i use a
RunTest class.
If this test passes, i startup my uml-linux and trigger the whole test
chain.
But again, if you have a system, then that works..
And never ever there should be a commit to vfs without testing the
change against this system using ALL filesystems.
If you are interested in this uml-linux server, just drop me a note.
---RunTest---
package org.apache.commons.vfs.test;
import junit.framework.AssertionFailedError;
import junit.framework.Test;
import junit.framework.TestResult;
import org.apache.commons.vfs.provider.webdav.test.WebdavProviderTestCase;
import java.util.Properties;
public class RunTest
{
public static void main(String[] args) throws Exception
{
Properties props = System.getProperties();
props.setProperty(test.data.src, src/test-data);
props.setProperty(test.basedir, target/test-data);
props.setProperty(test.policy, src/test-data/test.policy);
props.setProperty(test.secure, false);
props.setProperty(test.smb.uri,
smb://vfsusr:[EMAIL PROTECTED]/vfsusr/vfstest);
props.setProperty(test.ftp.uri,
ftp://vfsusr:[EMAIL PROTECTED]/vfstest);
props.setProperty(test.http.uri, http://vfstest/vfstest;);
props.setProperty(test.webdav.uri,
webdav://vfsusr:[EMAIL PROTECTED]/vfstest);
props.setProperty(test.sftp.uri,
sftp://vfsusr:[EMAIL PROTECTED]/home/vfsusr/vfstest);
Test test;
// test = FtpProviderTestCase.suite();
// test = HttpProviderTestCase.suite();
// test = LocalProviderTestCase.suite();
// test = JarProviderTestCase.suite();
// test = ZipProviderTestCase.suite();
// test = TemporaryProviderTestCase.suite();
test = WebdavProviderTestCase.suite();
// test = UrlProviderTestCase.suite();
// test = SmbProviderTestCase.suite();
// test = SftpProviderTestCase.suite();
TestResult result = new TestResult()
{
public synchronized void addError(Test test, Throwable
throwable)
{
throwable.printStackTrace();
}
public synchronized void addFailure(Test test,
AssertionFailedError assertionFailedError)
{
assertionFailedError.printStackTrace();
}
};
test.run(result);
}
}
---RunTest---
--
Mario
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/math build.xml
brentworden2004/06/23 06:43:24
Modified:math build.xml
Log:
regenerated Ant script; dependencies were removed.
Revision ChangesPath
1.17 +25 -17jakarta-commons/math/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-commons/math/build.xml,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -r1.16 -r1.17
--- build.xml 2 Jun 2004 14:47:03 - 1.16
+++ build.xml 23 Jun 2004 13:43:23 - 1.17
@@ -1,18 +1,20 @@
?xml version=1.0 encoding=UTF-8?
!--build.xml generated by maven from project.xml version 1.0-dev
- on date June 2 2004, time 1044--
+ on date June 23 2004, time 0841--
project default=jar name=commons-math basedir=.
- property name=defaulttargetdir value=target
+ property name=defaulttargetdir
value=C:\files\projects\apache\jakarta-commons\math/target
/property
- property name=libdir value=target/lib
+ property name=libdir
value=C:\files\projects\apache\jakarta-commons\math/target/lib
/property
- property name=classesdir value=target/classes
+ property name=classesdir
value=C:\files\projects\apache\jakarta-commons\math/target/classes
/property
- property name=testclassesdir value=target/test-classes
+ property name=testclassesdir
value=C:\files\projects\apache\jakarta-commons\math/target/test-classes
/property
- property name=testreportdir value=target/test-reports
+ property name=testclassesdir
value=C:\files\projects\apache\jakarta-commons\math/target/test-classes
+ /property
+ property name=testreportdir
value=C:\files\projects\apache\jakarta-commons\math/target/test-reports
/property
property name=distdir value=dist
/property
@@ -53,7 +55,7 @@
/copy
/target
target name=jar description=o Create the jar depends=compile,test
-jar jarfile=target/${final.name}.jar excludes=**/package.html
basedir=${classesdir}
+jar jarfile=${defaulttargetdir}/${final.name}.jar excludes=**/package.html
basedir=${classesdir}
/jar
/target
target name=clean description=o Clean up the generated directories
@@ -123,8 +125,16 @@
/pathelement
/classpath
/javac
+copy todir=${testclassesdir}
+ fileset dir=C:\files\projects\apache\jakarta-commons\math\src\test
+include name=**/*.xml
+/include
+include name=**/*.txt
+/include
+ /fileset
+/copy
/target
- target name=javadoc description=o Generate javadoc depends=jar
+ target name=javadoc description=o Generate javadoc
mkdir dir=${javadocdir}
/mkdir
tstamp
@@ -141,25 +151,23 @@
include name=*.jar
/include
/fileset
-pathelement location=target/${final.name}.jar
+pathelement location=${defaulttargetdir}/${final.name}.jar
/pathelement
/classpath
/javadoc
/target
target name=get-deps unless=noget depends=init
-get dest=${libdir}/commons-collections-3.0.jar usetimestamp=true
ignoreerrors=true
src=http://www.ibiblio.org/maven//commons-collections/jars/commons-collections-3.0.jar;
-/get
-get dest=${libdir}/commons-lang-2.0.jar usetimestamp=true
ignoreerrors=true
src=http://www.ibiblio.org/maven//commons-lang/jars/commons-lang-2.0.jar;
+get dest=${libdir}/commons-lang-2.0.jar usetimestamp=true
ignoreerrors=true
src=http://www.ibiblio.org/maven/commons-lang/jars/commons-lang-2.0.jar;
/get
-get dest=${libdir}/commons-logging-1.0.3.jar usetimestamp=true
ignoreerrors=true
src=http://www.ibiblio.org/maven//commons-logging/jars/commons-logging-1.0.3.jar;
+get dest=${libdir}/commons-logging-1.0.3.jar usetimestamp=true
ignoreerrors=true
src=http://www.ibiblio.org/maven/commons-logging/jars/commons-logging-1.0.3.jar;
/get
-get dest=${libdir}/commons-discovery-0.2.jar usetimestamp=true
ignoreerrors=true
src=http://www.ibiblio.org/maven//commons-discovery/jars/commons-discovery-0.2.jar;
+get dest=${libdir}/commons-discovery-0.2.jar usetimestamp=true
ignoreerrors=true
src=http://www.ibiblio.org/maven/commons-discovery/jars/commons-discovery-0.2.jar;
/get
-get dest=${libdir}/junit-3.8.1.jar usetimestamp=true ignoreerrors=true
src=http://www.ibiblio.org/maven//junit/jars/junit-3.8.1.jar;
+get dest=${libdir}/junit-3.8.1.jar usetimestamp=true ignoreerrors=true
src=http://www.ibiblio.org/maven/junit/jars/junit-3.8.1.jar;
/get
-get dest=${libdir}/ant-1.5.jar usetimestamp=true ignoreerrors=true
src=http://www.ibiblio.org/maven//ant/jars/ant-1.5.jar;
+get dest=${libdir}/ant-1.5.jar usetimestamp=true ignoreerrors=true
src=http://www.ibiblio.org/maven/ant/jars/ant-1.5.jar;
/get
-get dest=${libdir}/ant-optional-1.5.jar usetimestamp=true
ignoreerrors=true
RE: [configuration] DOM vs DOM4J
I think a good solution is to do what Log4J has done with there distribution. Include a number of contrib classes in the distribution. I agree with the sentiment to get rid of Dom4JConfiguration, as I think it would make it easier to address some larger issues with the API - like why does this thing only load resources from the system classloader? From: Maarten Coene [mailto:[EMAIL PROTECTED] Sent: Wed 6/23/2004 5:30 AM To: Jakarta Commons Developers List Subject: Re: [configuration] DOM vs DOM4J And what about donating the code to the dom4j project if you decide to remove it? Maarten Eric Pugh wrote: It'll be in CVS if we come up with a reason to reimplement it... Eric -Original Message- From: Jörg Schaible [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 23, 2004 9:19 AM To: Jakarta Commons Developers List Subject: RE: [configuration] DOM vs DOM4J Emmanuel Bourg wrote on Tuesday, June 22, 2004 5:06 PM: Jörg Schaible wrote: Taking Paul's comment into account, there seems not to be a real sufficient solution. DOCConfiguration is quite nice for JDK = 1.4, since no additional dependency is generated. Therefore I vote in first place for the DOMConfiguration, but it might be good to have DOM4JConfiguration in e.g. commons-configuration-optional around and the possibility to tell the core to use this implementation. Comments? DOMConfiguration is even nice for JDK 1.3 since most server environnements under this version provide the standard XML APIs. I don't think [configuration] is performance critical enough to justify the use of an additional dependency, and there are other possible optimizations if a better implementation is really needed (for example the properties could be stored only once in the BaseConfiguration and the DOM parser could be dropped for a SAX parser). I tend to prefer a complete removal of the DOM4J classes to cut down the maintenance burden. Fine with me. -- 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] - 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]
[configuration] Release Date
Hi, Is there a planned release date for the commons-configuration package? Also, is there currently a maven repository that contains the current sanpshot builds or anything like that. Thanks Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] poms in java-repository
I rolled it back on request. Maven 2 seems to use poms more actively, so having Maven 1 poms there caused them problems, so the initial request was to hack our poms to help them there. In retrospect though, their mind changed as we're not meant to be tweaking the files on ibiblio etc, so I then rolled them back again. Which is why you can't see evidence of the below :) Hen On Wed, 23 Jun 2004, Mark R. Diggory wrote: Not quite grokking this, or at least its not what I currently see in the repository...Can you elaborate? http://www.apache.org/dist/java-repository/commons-beanutils/poms/commons-beanutils-1.6.pom -M. Henri Yandell wrote: Apparantly it's caused a bit of a problem for the Maven-2 work, so I'm going to modify the poms slightly. currentVersion will have a version next to it. id will also have groupId/artifactId next to it for both project and dependencies. Shoudln't break for maven 1 or 2, but means they won't be the same as in cvs. Hen -- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] site generation
On Wed, 23 Jun 2004, Mark R. Diggory wrote: That said, some public-key juggling could let you build locally and upload/rsync frequently, or maybe one of the other Apache boxes could be used as a build manager. Yes, I've got ssh keys in place that get me onto minotaur, all my generation is local and uploaded. My fault for being lazy. Had meant empty-passphrase ssh-keying. Unsure if infrastructure would be happy with lots of these in place. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] site generation
On Wed, 23 Jun 2004, Emmanuel Bourg wrote: Henri Yandell wrote: I'd be surprised if anyone is using Maven on minotaur. It's a FreeBSD machine without Java as far as I know. Well I was suprised to find a recent JDK on minotaur as well, I guess it uses the Linux emulation layer. Ant is available too. Odd. hostname matches, java gives me command not found and ant is there. We must have path differences: /sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/bin:/usr/X11R6/bin:/home/bayard/bin You are right, only the developpement pages should be refreshed then (changes, commits, activity, tests...). The documentation should stick to the latest stable release. I have no idea how to achieve this with Maven though ;) Yeah, I've actually gone with a pretty different solution and have a series of scripts that run Maven and build their own website for the development pages: http://builds.osjava.org/ Gump, Continuum (Maven), Damage-Control, CruiseControl all promise to do thise but don't get close to the development site. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] site generation
Henri Yandell wrote: Odd. hostname matches, java gives me command not found and ant is there. We must have path differences: /sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/bin:/usr/X11R6/bin:/home/bayard/bin Yes I cheated, I changed the path in my .profile : export JAVA_HOME=/usr/local/jdk1.4.2 export PATH=$PATH:$JAVA_HOME/bin Emmanuel Bourg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/math/src/test/org/apache/commons/math/stat/univariate ListUnivariateImpl.java
brentworden2004/06/23 09:26:18 Modified:math/src/java/org/apache/commons/math/stat/inference TTest.java ChiSquareTestImpl.java ChiSquareTest.java TTestImpl.java math/src/java/org/apache/commons/math/analysis SecantSolver.java UnivariateRealSolverFactoryImpl.java BisectionSolver.java PolynomialFunction.java NewtonSolver.java BrentSolver.java UnivariateRealInterpolator.java UnivariateRealSolverFactory.java UnivariateRealSolver.java DifferentiableUnivariateRealFunction.java SplineInterpolator.java UnivariateRealSolverUtils.java UnivariateRealSolverImpl.java PolynomialSplineFunction.java UnivariateRealFunction.java math/src/java/org/apache/commons/math/stat/univariate/moment Skewness.java ThirdMoment.java Kurtosis.java SecondMoment.java StandardDeviation.java FourthMoment.java Mean.java Variance.java GeometricMean.java FirstMoment.java math/src/java/org/apache/commons/math/distribution DiscreteDistribution.java BinomialDistributionImpl.java FDistributionImpl.java ChiSquaredDistributionImpl.java TDistribution.java BinomialDistribution.java GammaDistribution.java ChiSquaredDistribution.java AbstractDiscreteDistribution.java DistributionFactoryImpl.java DistributionFactory.java HypergeometricDistributionImpl.java ExponentialDistribution.java GammaDistributionImpl.java HypergeometricDistribution.java ContinuousDistribution.java FDistribution.java AbstractContinuousDistribution.java TDistributionImpl.java ExponentialDistributionImpl.java NormalDistribution.java NormalDistributionImpl.java math/src/java/org/apache/commons/math/util DefaultTransformer.java NumberTransformer.java TransformerMap.java MathUtils.java DoubleArray.java ResizableDoubleArray.java ContinuedFraction.java math/src/java/org/apache/commons/math/stat/univariate/summary SumOfSquares.java Sum.java Product.java SumOfLogs.java math/xdocs/userguide stat.xml special.xml index.xml complex.xml math/src/java/org/apache/commons/math MathConfigurationException.java MathException.java ConvergenceException.java math/src/java/org/apache/commons/math/complex ComplexFormat.java Complex.java ComplexMath.java math/src/java/org/apache/commons/math/stat/univariate StatisticalSummary.java StorelessUnivariateStatistic.java UnivariateStatistic.java AbstractUnivariateStatistic.java AbstractStorelessUnivariateStatistic.java SummaryStatisticsImpl.java SummaryStatistics.java DescriptiveStatistics.java DescriptiveStatisticsImpl.java StatisticalSummaryValues.java math/src/java/org/apache/commons/math/linear RealMatrixImpl.java BigMatrixImpl.java BigMatrix.java math/src/java/org/apache/commons/math/special Beta.java Erf.java Gamma.java math/src/java/org/apache/commons/math/stat/multivariate BivariateRegression.java math license-header.txt project.xml math/src/java/org/apache/commons/math/stat/univariate/rank Percentile.java Median.java Max.java Min.java math/xdocs developers.xml tasks.xml math/src/java/org/apache/commons/math/stat Frequency.java StatUtils.java math/src/java/org/apache/commons/math/random EmpiricalDistributionImpl.java ValueServer.java math/src/test/org/apache/commons/math/stat/univariate ListUnivariateImpl.java Log: Fixed javadoc, checkstyle, and link warnings. Made some corrections and
Re: [configuration] Release Date
Rob Dingwell wrote: Hi, Is there a planned release date for the commons-configuration package? Hello, there is no planned release date, the when it's ready motto applies here but we hope to release it as soon as the code is stabilized and consolidated. Early July is my intended target for the 1.0 release if no outstanding issue arise. The remaning issues are : - bug 29717 getKeys(String) broken in JNDIConfiguration (Eric if you can get a look I'll need your help there) - bug 29721 Saving XML configurations to another file (Altough it looks like a feature enhancement its purpose is to make the save methods easily testable) - bug 29722 addProperty throws a NPE in DOMConfiguration - bug 29734 DatabaseConfiguration doesn't support List properties - bug 29616 getStringArray doesn't interpolate in CompositeConfiguration - better test coverage, DOMConfiguration and JNDIConfiguration have chunks of untested code. - and the usual code formatting stuff :) Also, is there currently a maven repository that contains the current sanpshot builds or anything like that. There are nightly snapshots here : http://cvs.apache.org/builds/jakarta-commons/nightly/commons-configuration/ and an outdated maven repository here : http://www.apache.org/dist/java-repository/commons-configuration/jars/ Anyone could instruct me on how to refresh the snapshot there ? Emmanuel Bourg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [configuration] Release Date
Emmanuel has picked up the ball from me on getting 1.0 done.. He's been going through the issues and really looking carefully at the state of the code, so I think 1.0 will be arriving soon.. There are nightly builds (done for all commons projects) and you can also grab a snapshot off of jakarta.apache.org/turbine/repo Eric -Original Message- From: Rob Dingwell [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 23, 2004 5:15 PM To: [EMAIL PROTECTED] Subject: [configuration] Release Date Hi, Is there a planned release date for the commons-configuration package? Also, is there currently a maven repository that contains the current sanpshot builds or anything like that. Thanks Rob - 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][collections] Release 3.1
On Wed, 23 Jun 2004, Stephen Colebourne wrote: - [X] +1 Go ahead and release 3.1 [ ] +0 [ ] -0 [ ] -1 Don't release 3.1, because... - (non-binding) michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 29721] - [configuration] Saving XML configurations to another 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=29721. 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=29721 [configuration] Saving XML configurations to another file --- Additional Comments From [EMAIL PROTECTED] 2004-06-23 17:19 --- Created an attachment (id=11930) Patch providing save method to the XML configurations. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dbcp] [PATCH] Fix for blank username/password handling
The problem (in DriverManagerConnectionFactory.java):
If you supply a username but not a password, or a password but not a
username, dbcp ignores these values, and simply uses the URL to connect
to your database (even when defaults exist for the null values). This
means if I create a DriverManagerConnectionFactory with url, user and
pass of mydburl, myusername, null, it will try connect to mydburl using
default username and default password rather than myusername and default
password.
The solution:
Allow the default username and password values to be used when one is
present but the other is not, as provided by the patch. Now I realise
default usernames/passwords are not ideal, but at the same time there's
no need to prevent this functionality from working (imho).
Regards,
Max
--
Maxwell Grender-Jones [EMAIL PROTECTED]
http://www.mxtelecom.com/ +44 (0)845 6667778
Technical support[EMAIL PROTECTED]
Index: DriverManagerConnectionFactory.java
===
RCS file:
/home/cvspublic/jakarta-commons/dbcp/src/java/org/apache/commons/dbcp/DriverManagerConnectionFactory.java,v
retrieving revision 1.8
diff -u -r1.8 DriverManagerConnectionFactory.java
--- DriverManagerConnectionFactory.java 28 Feb 2004 12:18:17 - 1.8
+++ DriverManagerConnectionFactory.java 23 Jun 2004 17:12:31 -
@@ -25,6 +25,7 @@
*
* @author Rodney Waldhoff
* @author Ignacio J. Ortega
+ * @author Max Grender-Jones
* @version $Revision: 1.8 $ $Date: 2004/02/28 12:18:17 $
*/
public class DriverManagerConnectionFactory implements ConnectionFactory {
@@ -42,7 +43,7 @@
public Connection createConnection() throws SQLException {
if(null == _props) {
-if((_uname == null) || (_passwd == null)) {
+if((_uname == null) (_passwd == null)) {
return DriverManager.getConnection(_connectUri);
} else {
return DriverManager.getConnection(_connectUri,_uname,_passwd);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/vfs/src/java/org/apache/commons/vfs/provider/http HttpFileObject.java
imario 2004/06/23 11:17:44
Modified:vfs/src/java/org/apache/commons/vfs/provider
AbstractFileObject.java
vfs/src/test/org/apache/commons/vfs/test
AbstractTestSuite.java
vfs/src/java/org/apache/commons/vfs/impl
DefaultFileSystemManager.java
vfs/src/java/org/apache/commons/vfs FileSystemManager.java
Resources.properties
vfs/src/java/org/apache/commons/vfs/provider/http
HttpFileObject.java
Removed: vfs/src/java/org/apache/commons/vfs GlobalConfiguration.java
Log:
For clarification, remove GlobalConfiguration and reworked it into
DefaultFileSystemManager
Revision ChangesPath
1.47 +3 -5
jakarta-commons-sandbox/vfs/src/java/org/apache/commons/vfs/provider/AbstractFileObject.java
Index: AbstractFileObject.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/vfs/src/java/org/apache/commons/vfs/provider/AbstractFileObject.java,v
retrieving revision 1.46
retrieving revision 1.47
diff -u -r1.46 -r1.47
--- AbstractFileObject.java 17 Jun 2004 19:29:28 - 1.46
+++ AbstractFileObject.java 23 Jun 2004 18:17:44 - 1.47
@@ -25,7 +25,6 @@
import org.apache.commons.vfs.FileSystemException;
import org.apache.commons.vfs.FileType;
import org.apache.commons.vfs.FileUtil;
-import org.apache.commons.vfs.GlobalConfiguration;
import org.apache.commons.vfs.NameScope;
import org.apache.commons.vfs.RandomAccessContent;
import org.apache.commons.vfs.Selectors;
@@ -904,7 +903,7 @@
attach();
if (content == null)
{
-content = new DefaultFileContent(this, createFileContentInfoFactory());
+content = new DefaultFileContent(this, getFileContentInfoFactory());
}
return content;
}
@@ -1351,10 +1350,9 @@
/**
* create the filecontentinfo implementation
*/
-protected FileContentInfoFactory createFileContentInfoFactory()
+protected FileContentInfoFactory getFileContentInfoFactory()
{
-GlobalConfiguration gc =
getFileSystem().getFileSystemManager().getGlobalConfiguration();
-return gc.getFileContentInfoFactory();
+return getFileSystem().getFileSystemManager().getFileContentInfoFactory();
}
protected void injectType(FileType fileType)
1.3 +2 -6
jakarta-commons-sandbox/vfs/src/test/org/apache/commons/vfs/test/AbstractTestSuite.java
Index: AbstractTestSuite.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/vfs/src/test/org/apache/commons/vfs/test/AbstractTestSuite.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- AbstractTestSuite.java17 May 2004 17:56:57 - 1.2
+++ AbstractTestSuite.java23 Jun 2004 18:17:44 - 1.3
@@ -21,7 +21,6 @@
import org.apache.commons.AbstractVfsTestCase;
import org.apache.commons.vfs.FileName;
import org.apache.commons.vfs.FileObject;
-import org.apache.commons.vfs.GlobalConfiguration;
import org.apache.commons.vfs.impl.DefaultFileReplicator;
import org.apache.commons.vfs.impl.DefaultFileSystemManager;
import org.apache.commons.vfs.impl.PrivilegedFileReplicator;
@@ -128,11 +127,8 @@
checkTempDir(Temp dir not empty before test);
// Create the file system manager
-GlobalConfiguration config = new GlobalConfiguration();
-config.setFilesCache(providerConfig.getFilesCache());
-
manager = new DefaultFileSystemManager();
-manager.setGlobalConfiguration(config);
+manager.setFilesCache(providerConfig.getFilesCache());
final DefaultFileReplicator replicator = new DefaultFileReplicator(tempDir);
manager.setReplicator(new PrivilegedFileReplicator(replicator));
1.31 +42 -21
jakarta-commons-sandbox/vfs/src/java/org/apache/commons/vfs/impl/DefaultFileSystemManager.java
Index: DefaultFileSystemManager.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/vfs/src/java/org/apache/commons/vfs/impl/DefaultFileSystemManager.java,v
retrieving revision 1.30
retrieving revision 1.31
diff -u -r1.30 -r1.31
--- DefaultFileSystemManager.java 19 May 2004 19:34:06 - 1.30
+++ DefaultFileSystemManager.java 23 Jun 2004 18:17:44 - 1.31
@@ -16,13 +16,14 @@
package org.apache.commons.vfs.impl;
import org.apache.commons.logging.Log;
+import org.apache.commons.vfs.FileContentInfoFactory;
import org.apache.commons.vfs.FileObject;
import org.apache.commons.vfs.FileSystemException;
import
Re: [lang] mutables
Cool, just figured out the Heap walker part of JProfiler :) Never had a need to before. Anyways, my maintenance 'improvement' basically doubles the size. Old MutableInteger wrapping an int is 16 bytes in size. New MutableInteger wrapping a Number via superclass is 2 x 16 bytes in size. Will go ahead and roll it on back. Hen On Mon, 21 Jun 2004, Henri Yandell wrote: I plan to do this by Saturday. I want to try them out in JProfiler to see what the actual differences are, more for my own education than because I think there will be a surprising result. Just in case you wonder about nothing happening. Hen On Mon, 21 Jun 2004, Henri Yandell wrote: Jar size isn't important, maintainable code size is why I suggested moving to storing the value in the abstract. Am happy to rollback if that is desired. Hen On Mon, 21 Jun 2004, Stephen Colebourne wrote: I've only now got a chance to review this (holiday ;-). I am less than happy with the current CVS code as it involves storing each subclass as an Object. IMO, the whole point of this package is to create classes that hold each value as a primitive, as per the java lang Number subclasses, and [lang] Range classes. I know that this creates more code in the jar, but that is irrelevant next to the new Integer() or new Byte() etc in the constructor of the CVS code. Creating these additional objects is a memory hog and bad for the gc. I can see no advantage other than jar size for the CVS code, hence would -1 the current CVS. I haven't checked if this was how the classes were originally. If so, can we rollback? Stephen - Original Message - From: Henri Yandell [EMAIL PROTECTED] First thought when looking at the code is that we could simplify things with a protected Number in MutableNumber, and move the intValue etc methods up into MutableNumber. The getValue/ setValue(Object) can go up too, and all that would be left in the mutable subclass is the primitive override and the constructor. Pro: Less code in the subclasses. Con: A protected rather than private variable. More memory is taken up with the mutable part being an Object and not a primitive. Just a thought. Hen On Thu, 10 Jun 2004, matthew.hawthorne wrote: I just made a checkin of some initial code for mutables. I haven't used CVS in a few months now (switched to subversion) so let's hope I didn't screw anything up. I have to admit that I haven't looked at this code for a good time, since around August maybe. So all are welcome to take a look and make improvements. I don't really have a solid use case for these classes anymore, so I'd imagine that others will have a better insight in that regard. The test coverage is pretty good, I think in the 70% range. I remember learning some weird things about the way Java handles primitive number conversions, as I was trying to get the tests to pass. If something looks bizarre give a yell and I'll investigate. - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[RESULT][VOTE][betwixt] release betwixt 0.5
i count 3 binding +1s only (thanks dims!) for the 0.5 betwixt release (see http://marc.theaimsgroup.com/?l=jakarta-commons- devm=108776703608142w=2). therefore, unless objections from the pmc are posted within 24 hours i will proceed to cut the 0.5 release. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] site generation
Usually you run Maven locally and upload the site manually. I'm not sure anyone is running a cron for it, and I'd recommend not doing so because the published site ends up in line with CVS and not with your latest stable release. User's then get very confused. You are right, only the developpement pages should be refreshed then (changes, commits, activity, tests...). The documentation should stick to the latest stable release. I have no idea how to achieve this with Maven though ;) See [collections]. The maven.xml has a full script for building javadoc of old versions (tested on Maven RC1). The navigation.xml has explicit links to each of the generated javadocs. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] mutables
From: Henri Yandell [EMAIL PROTECTED] Anyways, my maintenance 'improvement' basically doubles the size. Old MutableInteger wrapping an int is 16 bytes in size. New MutableInteger wrapping a Number via superclass is 2 x 16 bytes in size. As I expected, but my main concern is that 2 objects takes twice as long to gc as 1. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/beanutils/src/java/org/apache/commons/beanutils package.html
rdonkin 2004/06/23 13:39:56 Modified:beanutils/src/java/org/apache/commons/beanutils Tag: RELEASE_BEANUTILS_1_7_0_BRANCH package.html Log: Ensured that guide makes clear when the classes described are to be found in bean-collections. Revision ChangesPath No revision No revision 1.18.2.1 +30 -0 jakarta-commons/beanutils/src/java/org/apache/commons/beanutils/package.html Index: package.html === RCS file: /home/cvs/jakarta-commons/beanutils/src/java/org/apache/commons/beanutils/package.html,v retrieving revision 1.18 retrieving revision 1.18.2.1 diff -u -r1.18 -r1.18.2.1 --- package.html 7 Jan 2004 22:01:09 - 1.18 +++ package.html 23 Jun 2004 20:39:55 - 1.18.2.1 @@ -55,6 +55,7 @@ lia href=#FAQ.propertyWhy Can't BeanUtils Find My Method?/a/li lia href=#FAQ.bc.orderHow Do I Set The BeanComparator Order To Be Ascending/Descending?/a/li /ul/li +lia href='#Packaging'Packaging/a/li /ol a name=overview/a @@ -704,6 +705,12 @@ a name=collections/a h1Collections/h1 +strongNote:/strong these classes depend on +a href='http://jakarta.apache.org/commons/collections'Commons Collection/a 3.0 or higher +and are optional. To use them, please ensure that this library is available +and that either the all-in-one jar is used or the modular +codecommons-beanutils-bean-collections.jar/code is available +(in addition to codecommons-beanutils-core.jar/code, of course :-). a name=bean-comparator/a h3Comparing Beans/h3 p @@ -832,5 +839,28 @@ Collections.sort(myList, reversedNaturalOrderBeanComparator); ... /pre/code + +a name=Packaging/a +h1Packaging/h1 +p +BeanUtils now comes packaged (into jars) in two different ways: +/p +ol +lian all-in-one jar (codecommons-beanutils.jar/code)/li +liand as modular component jars: +ul + licodecommons-beanutils-core.jar/code (core classes)/li + licodecommons-beanutils-bean-collections.jar/code +(additional dependency on commons-collections 3.0)/li +/ol +p +Those who want it all should grab the all-in-one codecommons-beanutils.jar/code +(and remember to add any optional dependencies needed) +whereas those who need minimal dependencies should use codecommons-beanutils-core.jar/code +plus any optional jars they plan to use. +/p +p +The binary distribution contains all these jars. +/p /body /html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/beanutils/xdocs navigation.xml
rdonkin 2004/06/23 13:51:54 Modified:beanutils/xdocs Tag: RELEASE_BEANUTILS_1_7_0_BRANCH navigation.xml Log: Changed navigation reference to assist in assembling offline composite docs Revision ChangesPath No revision No revision 1.7.2.1 +1 -1 jakarta-commons/beanutils/xdocs/navigation.xml Index: navigation.xml === RCS file: /home/cvs/jakarta-commons/beanutils/xdocs/navigation.xml,v retrieving revision 1.7 retrieving revision 1.7.2.1 diff -u -r1.7 -r1.7.2.1 --- navigation.xml24 May 2004 21:29:32 - 1.7 +++ navigation.xml23 Jun 2004 20:51:54 - 1.7.2.1 @@ -39,7 +39,7 @@ /menu menu name='Modules' -item name=Bean Collections href=http://jakarta.apache.org/commons/beanutils/bean-collections/index.html/ +item name=Bean Collections href=bean-collections/index.html/ /menu common-menus; - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Jakarta Commons Wiki] Updated: BeanUtils/1.7.0ReleasePlan
Date: 2004-06-23T13:52:50 Editor: RobertBurrellDonkin [EMAIL PROTECTED] Wiki: Jakarta Commons Wiki Page: BeanUtils/1.7.0ReleasePlan URL: http://wiki.apache.org/jakarta-commons/BeanUtils/1.7.0ReleasePlan Added note about completing task Change Log: -- @@ -28,7 +28,7 @@ === Documentation === * Review documentation to ensure that those classes in bean-collections are clear ''DONE'' - * Add documentation on any classes in bean-collections which have not been covered already + * Add documentation on any classes in bean-collections which have not been covered already ''DONE'' * Ensure bean-collections classes are properly javadoc'd ''DONE'' == Beanification == - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/beanutils/optional/bean-collections project.xml
rdonkin 2004/06/23 14:00:22 Modified:beanutils Tag: RELEASE_BEANUTILS_1_7_0_BRANCH project.xml beanutils/optional/bean-collections Tag: RELEASE_BEANUTILS_1_7_0_BRANCH project.xml Log: Upgraded version for upcoming release candidate Revision ChangesPath No revision No revision 1.21.2.1 +1 -1 jakarta-commons/beanutils/project.xml Index: project.xml === RCS file: /home/cvs/jakarta-commons/beanutils/project.xml,v retrieving revision 1.21 retrieving revision 1.21.2.1 diff -u -r1.21 -r1.21.2.1 --- project.xml 10 May 2004 19:48:03 - 1.21 +++ project.xml 23 Jun 2004 21:00:22 - 1.21.2.1 @@ -18,7 +18,7 @@ pomVersion3/pomVersion idcommons-beanutils/id nameBeanUtils/name - currentVersion1.7-dev/currentVersion + currentVersion1.7RC1/currentVersion inceptionYear2000/inceptionYear shortDescriptionCommons BeanUtils/shortDescription descriptionBeanUtils provides an easy-to-use but flexible wrapper around reflection and introspection./description No revision No revision 1.3.2.1 +1 -1 jakarta-commons/beanutils/optional/bean-collections/project.xml Index: project.xml === RCS file: /home/cvs/jakarta-commons/beanutils/optional/bean-collections/project.xml,v retrieving revision 1.3 retrieving revision 1.3.2.1 diff -u -r1.3 -r1.3.2.1 --- project.xml 24 May 2004 20:41:40 - 1.3 +++ project.xml 23 Jun 2004 21:00:22 - 1.3.2.1 @@ -19,7 +19,7 @@ pomVersion3/pomVersion idcommons-beanutils-bean-collections/id nameBeanUtils Bean Collections/name - currentVersion1.7-dev/currentVersion + currentVersion1.7RC1/currentVersion inceptionYear2000/inceptionYear shortDescriptionCommons BeanUtils Bean Collections/shortDescription descriptionExtensions of commons collections focussing on collections of beans/description - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/collections/src/test/org/apache/commons/collections TestFastArrayList1.java
scolebourne2004/06/23 14:41:49
Modified:collections/src/java/org/apache/commons/collections
FastArrayList.java
collections/src/test/org/apache/commons/collections
TestFastArrayList1.java
Log:
Fix FastArrayList iterator to work in thread-safe environments
Revision ChangesPath
1.16 +46 -17
jakarta-commons/collections/src/java/org/apache/commons/collections/FastArrayList.java
Index: FastArrayList.java
===
RCS file:
/home/cvs/jakarta-commons/collections/src/java/org/apache/commons/collections/FastArrayList.java,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- FastArrayList.java18 Feb 2004 01:15:42 - 1.15
+++ FastArrayList.java23 Jun 2004 21:41:49 - 1.16
@@ -60,6 +60,7 @@
* @version $Revision$ $Date$
*
* @author Craig R. McClanahan
+ * @author Stephen Colebourne
*/
public class FastArrayList extends ArrayList {
@@ -486,12 +487,20 @@
/**
* Return an iterator over the elements in this list in proper sequence.
- * brbr
- * strongIMPLEMENTATION NOTE/strong - If the list is operating in fast
- * mode, an Iterator is returned, and a structural modification to the
- * list is made, then the Iterator will continue over the previous contents
- * of the list (at the time that the Iterator was created), rather than
- * failing due to concurrent modifications.
+ * p
+ * bThread safety/bbr /
+ * The iterator returned is thread-safe ONLY in FAST mode.
+ * In slow mode there is no way to synchronize, or make the iterator
thread-safe.
+ * p
+ * In fast mode iteration and modification may occur in parallel on different
threads,
+ * however there is a restriction. Modification must be EITHER via the Iterator
+ * interface methods OR the List interface. If a mixture of modification
+ * methods is used a ConcurrentModificationException is thrown from the iterator
+ * modification method. If the List modification methods are used the changes
are
+ * NOT visible in the iterator (it shows the list contents at the time the
iterator
+ * was created).
+ *
+ * @return the iterator
*/
public Iterator iterator() {
if (fast) {
@@ -524,7 +533,20 @@
/**
* Return an iterator of the elements of this list, in proper sequence.
- * See the implementation note on codeiterator()/code.
+ * p
+ * bThread safety/bbr /
+ * The iterator returned is thread-safe ONLY in FAST mode.
+ * In slow mode there is no way to synchronize, or make the iterator
thread-safe.
+ * p
+ * In fast mode iteration and modification may occur in parallel on different
threads,
+ * however there is a restriction. Modification must be EITHER via the Iterator
+ * interface methods OR the List interface. If a mixture of modification
+ * methods is used a ConcurrentModificationException is thrown from the iterator
+ * modification method. If the List modification methods are used the changes
are
+ * NOT visible in the iterator (it shows the list contents at the time the
iterator
+ * was created).
+ *
+ * @return the list iterator
*/
public ListIterator listIterator() {
if (fast) {
@@ -538,10 +560,21 @@
/**
* Return an iterator of the elements of this list, in proper sequence,
* starting at the specified position.
- * See the implementation note on codeiterator()/code.
+ * p
+ * bThread safety/bbr /
+ * The iterator returned is thread-safe ONLY in FAST mode.
+ * In slow mode there is no way to synchronize, or make the iterator
thread-safe.
+ * p
+ * In fast mode iteration and modification may occur in parallel on different
threads,
+ * however there is a restriction. Modification must be EITHER via the Iterator
+ * interface methods OR the List interface. If a mixture of modification
+ * methods is used a ConcurrentModificationException is thrown from the iterator
+ * modification method. If the List modification methods are used the changes
are
+ * NOT visible in the iterator (it shows the list contents at the time the
iterator
+ * was created).
*
* @param index The starting position of the iterator to return
- *
+ * @return the list iterator
* @exception IndexOutOfBoundsException if the index is out of range
*/
public ListIterator listIterator(int index) {
@@ -1205,8 +1238,9 @@
int i = nextIndex();
get().add(i, o);
last++;
+expected = list;
iter = get().listIterator(i + 1);
DO NOT REPLY [Bug 29625] - [collections] FastArrayList iterator method throwing ConcurrentModificationException in 'fast' mode
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=29625. 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=29625 [collections] FastArrayList iterator method throwing ConcurrentModificationException in 'fast' mode [EMAIL PROTECTED] changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |3.2 --- Additional Comments From [EMAIL PROTECTED] 2004-06-23 21:48 --- I took a proper look and found various holes. There was no easy full solution, however I have managed to make some simple changes which greatly enhance usability. 1) Fast mode SubList iterator add() then set() and add() then remove() now works correctly. 2) Fast mode Iterator add() doesn't break the iterator from then on. 3) Fast mode now allows modification EITHER via the Iterator methods OR via the List methods. Mixing them gives a ConcurrentModificationException. 4) Some extra tests added. Change in CVS, but won't be in 3.1 (unless 3.1 has to be rebuilt). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/io TestBeanWriter.java
rdonkin 2004/06/23 14:56:59
Modified:betwixt/src/java/org/apache/commons/betwixt/io
BeanWriter.java
Added: betwixt/src/test/org/apache/commons/betwixt/io
TestBeanWriter.java
Log:
Added ability to choose to write empty tags as two tags or onee.
Revision ChangesPath
1.25 +41 -2
jakarta-commons/betwixt/src/java/org/apache/commons/betwixt/io/BeanWriter.java
Index: BeanWriter.java
===
RCS file:
/home/cvs/jakarta-commons/betwixt/src/java/org/apache/commons/betwixt/io/BeanWriter.java,v
retrieving revision 1.24
retrieving revision 1.25
diff -u -r1.24 -r1.25
--- BeanWriter.java 31 Mar 2004 21:11:52 - 1.24
+++ BeanWriter.java 23 Jun 2004 21:56:59 - 1.25
@@ -98,6 +98,8 @@
private boolean currentElementHasBodyText = false;
/** Has the last start tag been closed */
private boolean closedStartTag = true;
+/** Should an end tag be added for empty elements? */
+private boolean addEndTagForEmptyElement = false;
/** Current level of indentation (starts at 1 with the first element) */
private int indentLevel;
/** USed to determine how body content should be encoded before being output*/
@@ -286,6 +288,34 @@
mixedContentEncodingStrategy = strategy;
}
+/**
+ * Should an end tag be added for each empty element?
+ * When this property is false then empty elements will
+ * be written as codelt;emelement-name/em/gt;/code.
+ * When this property is true then empty elements will
+ * be written as codelt;emelement-name/emgt;
+ * lt;/emelement-name/emgt;/code.
+ * @return true if an end tag should be added
+ */
+public boolean isEndTagForEmptyElement() {
+return addEndTagForEmptyElement;
+}
+
+/**
+ * Sets when an an end tag be added for each empty element?
+ * When this property is false then empty elements will
+ * be written as codelt;emelement-name/em/gt;/code.
+ * When this property is true then empty elements will
+ * be written as codelt;emelement-name/emgt;
+ * lt;/emelement-name/emgt;/code.
+ * @param addEndTagForEmptyElement true if an end tag should be
+ * written for each empty element, false otherwise
+ */
+public void setEndTagForEmptyElement(boolean addEndTagForEmptyElement) {
+this.addEndTagForEmptyElement = addEndTagForEmptyElement;
+}
+
+
// New API
//--
@@ -353,7 +383,10 @@
throws
IOException,
SAXException {
-if ( ( !closedStartTag ) currentElementIsEmpty ) {
+if (
+!addEndTagForEmptyElement
+ !closedStartTag
+ currentElementIsEmpty ) {
writer.write( / );
closedStartTag = true;
@@ -361,6 +394,12 @@
} else {
if (!currentElementHasBodyText) {
indent();
+}
+if (
+addEndTagForEmptyElement
+ !closedStartTag ) {
+ writer.write( );
+ closedStartTag = true;
}
writer.write( / );
writer.write( qualifiedName );
1.1
jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/io/TestBeanWriter.java
Index: TestBeanWriter.java
===
/*
* Copyright 2004 The Apache Software Foundation.
*
* Licensed under the Apache License, Version 2.0 (the License);
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an AS IS BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
package org.apache.commons.betwixt.io;
import java.io.StringWriter;
import org.apache.commons.betwixt.ElementDescriptor;
import org.xml.sax.helpers.AttributesImpl;
import junit.framework.TestCase;
/**
* Test for codeBeanWriter/code
* @author a href='http://jakarta.apache.org/'Jakarta Commons Team/a
* @version $Revision: 1.1 $
*/
public class TestBeanWriter extends TestCase {
public void testSetEndTagForEmptyElementTrue() throws
[collections] JDK1.5
While release 3.1 is being tidied up (still time to vote ;-), I thought I'd just put out a note about JDK1.5. One of the key enhancements in JDK1.5 is generics which allows typed classes using the angle bracket notation. The biggest area this impacts is collections. Clearly questions have to be raised as to how this affects [collections]. So far, I have done no work to see if [collections] will compile under JDK1.5. My expectation is that it will, but there are no guarantees. To take full advantage of generics will involve a considerable rewrite of [collections]. It will affect every class, and produce a version that only compiles on JDK1.5. I have no doubt that Sun spent many mandays changing the JDK classes to achieve this update. Personally, I have no plans to update [collections] to JDK1.5 (no itch, too much effort). If anyone else does, feel free to come in and either change [collections], or (more likely) create a new [collections15] project. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] JDK1.5
I most definitely have the itch, but frankly, that's a lot of typing. :( [collections] HEAD compiles with 1.5 but as expected generates a pile of unchecked warnings, such as [javac] /home/heuer/working/jakarta-commons/collections/src/java/org/apache/commons/collections/set/MapBackedSet.java:130: warning: [unchecked] unchecked call to removeAll(java.util.Collection?) as a member of the raw type java.util.Set [javac] return map.keySet().removeAll(coll); [javac] ^ [javac] /home/heuer/working/jakarta-commons/collections/src/java/org/apache/commons/collections/set/MapBackedSet.java:134: warning: [unchecked] unchecked call to retainAll(java.util.Collection?) as a member of the raw type java.util.Set [javac] return map.keySet().retainAll(coll); [javac] ^ [javac] /home/heuer/working/jakarta-commons/collections/src/java/org/apache/commons/collections/set/MapBackedSet.java:146: warning: [unchecked] unchecked call to TtoArray(T[]) as a member of the raw type java.util.Set [javac] return map.keySet().toArray(array); The tests don't compile because of some variables named 'enum' in TestCollectionUtils. Just add # javac v1.5 support maven.compile.source=1.5 maven.compile.target=1.5 maven.compile.fork=true maven.compile.compilerargs=-Xlint:unchecked to the [collections] project.properties to build with maven (rc3 ant 1.6) and jdk 1.5 (beta3 build 56). michael On Wed, 23 Jun 2004, Stephen Colebourne wrote: While release 3.1 is being tidied up (still time to vote ;-), I thought I'd just put out a note about JDK1.5. One of the key enhancements in JDK1.5 is generics which allows typed classes using the angle bracket notation. The biggest area this impacts is collections. Clearly questions have to be raised as to how this affects [collections]. So far, I have done no work to see if [collections] will compile under JDK1.5. My expectation is that it will, but there are no guarantees. To take full advantage of generics will involve a considerable rewrite of [collections]. It will affect every class, and produce a version that only compiles on JDK1.5. I have no doubt that Sun spent many mandays changing the JDK classes to achieve this update. Personally, I have no plans to update [collections] to JDK1.5 (no itch, too much effort). If anyone else does, feel free to come in and either change [collections], or (more likely) create a new [collections15] project. Stephen - 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] JDK1.5
For the record, while I'm +0 on moving toward JDK 1.5 support within collections, I'm certainly -1 on abandoning JDK 1.4 support in the near future. - Rod On Wed, 23 Jun 2004, Stephen Colebourne wrote: While release 3.1 is being tidied up (still time to vote ;-), I thought I'd just put out a note about JDK1.5. One of the key enhancements in JDK1.5 is generics which allows typed classes using the angle bracket notation. The biggest area this impacts is collections. Clearly questions have to be raised as to how this affects [collections]. So far, I have done no work to see if [collections] will compile under JDK1.5. My expectation is that it will, but there are no guarantees. To take full advantage of generics will involve a considerable rewrite of [collections]. It will affect every class, and produce a version that only compiles on JDK1.5. I have no doubt that Sun spent many mandays changing the JDK classes to achieve this update. Personally, I have no plans to update [collections] to JDK1.5 (no itch, too much effort). If anyone else does, feel free to come in and either change [collections], or (more likely) create a new [collections15] project. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[GUMP@brutus]: jelly-tags/commons-jelly-tags-jsl 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 folk at [EMAIL PROTECTED] Project commons-jelly-tags-jsl has an issue affecting its community integration, and has been outstanding for 35 runs. Project State : 'Failed', Reason 'Build Failed' Full details are available at: http://brutus.apache.org:8080/gump/jelly-tags/commons-jelly-tags-jsl/index.html That said, some snippets follow: The following annotations were provided: -DEBUG- Sole jar [commons-jelly-tags-jsl-20040623.jar] identifier set to project name -INFO- Enable debug output, due to a sequence of 34 previous errors. -INFO- Failed with reason build failed The following work was performed: http://brutus.apache.org:8080/gump/jelly-tags/commons-jelly-tags-jsl/gump_work/build_jelly-tags_commons-jelly-tags-jsl.html Work Name: build_jelly-tags_commons-jelly-tags-jsl (Type: Build) State: Failed Elapsed: 0 hours, 0 minutes, 6 seconds Command Line: java -Djava.awt.headless=true -Dbuild.clonevm=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar org.apache.tools.ant.Main -debug -Dgump.merge=/usr/local/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dfinal.name=commons-jelly-tags-jsl-20040623 jar [Working Directory: /usr/local/gump/public/workspace/jelly-tags/jsl] CLASSPATH : /usr/local/j2sdk1.4.2_04/lib/tools.jar:/usr/local/gump/public/workspace/jelly-tags/jsl/target/classes:/usr/local/gump/public/workspace/jelly-tags/jsl/target/test-classes:/usr/local/gump/public/workspace/jakarta-commons/jelly/target/commons-jelly-20040623.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-stylebook.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-20040623.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-20040623.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar:/usr/local/gump/packages/dom4j-1.4/dom4j-full.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-20040623.jar:/usr/local/gump/public/workspace/jakarta-commons/discovery/dist/commons-discovery.jar:/usr/local/gump/public/workspace/jakarta-servletapi-4/lib/servlet.jar:/usr/local/gump/packages/nekohtml-0.9.2/nekohtmlXni.jar:/usr/local/gump/packages/nekohtml-0.9.2/nekohtml.jar:/usr/local/gump/public/workspace/jelly-tags/xml/target/commons-jelly-tags-xml-20040623.jar:/usr/local/gump/public/workspace/jelly-tags/junit/target/commons-jelly-tags-junit-20040623.jar:/usr/local/gump/public/workspace/jelly-tags/ant/target/commons-jelly-tags-ant-20040623.jar:/usr/local/gump/public/workspace/commons-grant/target/commons-grant-20040623.jar:/usr/local/gump/public/workspace/jelly-tags/log/target/commons-jelly-tags-log-20040623.jar- [junit] at org.apache.commons.jelly.impl.StaticTag.doTag(StaticTag.java:65) [junit] at org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.java:102) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:89) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) [junit] at org.apache.commons.jelly.tags.jsl.TemplateTag$1.run(TemplateTag.java:160) [junit] at org.dom4j.rule.Mode.fireRule(Mode.java:51) [junit] at org.dom4j.rule.Mode.applyTemplates(Mode.java:71) [junit] at org.dom4j.rule.RuleManager$1.run(RuleManager.java:148) [junit] at org.dom4j.rule.Mode.fireRule(Mode.java:51) [junit] at org.dom4j.rule.Stylesheet.run(Stylesheet.java:73) [junit] at org.dom4j.rule.Stylesheet.run(Stylesheet.java:65) [junit] at org.dom4j.rule.Stylesheet.run(Stylesheet.java:57) [junit] at org.apache.commons.jelly.tags.jsl.StylesheetTag.doTag(StylesheetTag.java:124) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:233) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:89) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) [junit] at org.apache.commons.jelly.tags.core.ForEachTag.doTag
[GUMP@brutus]: jelly-tags/commons-jelly-tags-define 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 folk at [EMAIL PROTECTED] Project commons-jelly-tags-define has an issue affecting its community integration. This issue affects 2 projects, and has been outstanding for 35 runs. Project State : 'Failed', Reason 'Build Failed' The following are affected: - maven : Project Management Tools - maven-bootstrap : Project Management Tools Full details are available at: http://brutus.apache.org:8080/gump/jelly-tags/commons-jelly-tags-define/index.html That said, some snippets follow: The following annotations were provided: -DEBUG- Sole jar [commons-jelly-tags-define-20040623.jar] identifier set to project name -INFO- Enable debug output, due to a sequence of 34 previous errors. -INFO- Failed with reason build failed The following work was performed: http://brutus.apache.org:8080/gump/jelly-tags/commons-jelly-tags-define/gump_work/build_jelly-tags_commons-jelly-tags-define.html Work Name: build_jelly-tags_commons-jelly-tags-define (Type: Build) State: Failed Elapsed: 0 hours, 0 minutes, 5 seconds Command Line: java -Djava.awt.headless=true -Dbuild.clonevm=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar org.apache.tools.ant.Main -debug -Dgump.merge=/usr/local/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dfinal.name=commons-jelly-tags-define-20040623 jar [Working Directory: /usr/local/gump/public/workspace/jelly-tags/define] CLASSPATH : /usr/local/j2sdk1.4.2_04/lib/tools.jar:/usr/local/gump/public/workspace/jelly-tags/define/target/classes:/usr/local/gump/public/workspace/jelly-tags/define/target/test-classes:/usr/local/gump/public/workspace/jakarta-commons/jelly/target/commons-jelly-20040623.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-stylebook.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-20040623.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-20040623.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar:/usr/local/gump/packages/dom4j-1.4/dom4j-full.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-20040623.jar:/usr/local/gump/public/workspace/jakarta-commons/discovery/dist/commons-discovery.jar:/usr/local/gump/public/workspace/jakarta-servletapi-4/lib/servlet.jar:/usr/local/gump/packages/nekohtml-0.9.2/nekohtmlXni.jar:/usr/local/gump/packages/nekohtml-0.9.2/nekohtml.jar:/usr/local/gump/public/workspace/jelly-tags/dynabean/target/commons-jelly-tags-dynabean-20040623.jar:/usr/local/gump/public/workspace/jelly-tags/junit/target/commons-jelly-tags-junit-20040623.jar:/usr/local/gump/public/workspace/jelly-tags/log/target/commons-jelly-tags-log-20040623.jar:/usr/local/gump/public/workspace/jelly-tags/xml/target/commons-jelly-tags-xml-20040623.jar- [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:89) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) [junit] at org.apache.commons.jelly.TagSupport.getBodyText(TagSupport.java:236) [junit] at org.apache.commons.jelly.tags.core.SetTag.doTag(SetTag.java:90) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:233) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:89) [junit] at org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59) [junit] Caused by: java.lang.NullPointerException [junit] at org.apache.commons.jelly.tags.define.SuperTag.doTag(SuperTag.java:44) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:233) [junit] ... 20 more [junit] Root cause [junit] java.lang.NullPointerException [junit] at org.apache.commons.jelly.tags.define.SuperTag.doTag(SuperTag.java:44) [junit] at org.apache.commons.jelly.impl.TagScript.run
[GUMP@brutus]: jelly-tags/commons-jelly-tags-jetty 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 folk at [EMAIL PROTECTED] Project commons-jelly-tags-jetty has an issue affecting its community integration, and has been outstanding for 21 runs. Project State : 'Failed', Reason 'Build Failed' Full details are available at: http://brutus.apache.org:8080/gump/jelly-tags/commons-jelly-tags-jetty/index.html That said, some snippets follow: The following annotations were provided: -DEBUG- Sole jar [commons-jelly-tags-jetty-20040623.jar] identifier set to project name -INFO- Enable debug output, due to a sequence of 20 previous errors. -INFO- Failed with reason build failed The following work was performed: http://brutus.apache.org:8080/gump/jelly-tags/commons-jelly-tags-jetty/gump_work/build_jelly-tags_commons-jelly-tags-jetty.html Work Name: build_jelly-tags_commons-jelly-tags-jetty (Type: Build) State: Failed Elapsed: 0 hours, 0 minutes, 2 seconds Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar org.apache.tools.ant.Main -debug -Dgump.merge=/usr/local/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dfinal.name=commons-jelly-tags-jetty-20040623 jar [Working Directory: /usr/local/gump/public/workspace/jelly-tags/jetty] CLASSPATH : /usr/local/j2sdk1.4.2_04/lib/tools.jar:/usr/local/gump/public/workspace/jelly-tags/jetty/target/classes:/usr/local/gump/public/workspace/jelly-tags/jetty/target/test-classes:/usr/local/gump/public/workspace/jakarta-commons/jelly/target/commons-jelly-20040623.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-stylebook.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-20040623.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-20040623.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar:/usr/local/gump/packages/dom4j-1.4/dom4j-full.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-20040623.jar:/usr/local/gump/public/workspace/jakarta-commons/discovery/dist/commons-discovery.jar:/usr/local/gump/public/workspace/jakarta-servletapi-4/lib/servlet.jar:/usr/local/gump/packages/nekohtml-0.9.2/nekohtmlXni.jar:/usr/local/gump/packages/nekohtml-0.9.2/nekohtml.jar:/usr/local/gump/public/workspace/jakarta-commons/httpclient/dist/commons-httpclient.jar:/usr/local/gump/public/workspace/jetty/lib/org.mortbay.jetty.jar:/usr/local/gump/public/workspace/jelly-tags/http/target/commons-jelly-tags-http-20040623.jar- [javac] _logSink = new OutputStreamLogSink(DEFAULT_LOG_FILE); [javac]^ [javac] /usr/local/gump/public/workspace/jelly-tags/jetty/src/java/org/apache/commons/jelly/tags/jetty/JettyHttpServerTag.java:75: cannot resolve symbol [javac] symbol : variable Log [javac] location: class org.apache.commons.jelly.tags.jetty.JettyHttpServerTag [javac] Log.instance().add(_logSink); [javac] ^ [javac] /usr/local/gump/public/workspace/jelly-tags/jetty/src/java/org/apache/commons/jelly/tags/jetty/SecurityHandlerTag.java:191: cannot resolve symbol [javac] symbol : variable Code [javac] location: class org.apache.commons.jelly.tags.jetty.SecurityHandlerTag [javac] Code.warning(Unknown user-data-constraint:+guarantee); [javac] ^ [javac] /usr/local/gump/public/workspace/jelly-tags/jetty/src/java/org/apache/commons/jelly/tags/jetty/SecurityHandlerTag.java:236: cannot resolve symbol [javac] symbol : class Authenticator [javac] location: class org.apache.commons.jelly.tags.jetty.SecurityHandlerTag [javac] Authenticator authenticator=null; [javac] ^ [javac] /usr/local/gump/public/workspace/jelly-tags/jetty/src/java/org/apache/commons/jelly/tags/jetty/SecurityHandlerTag.java:248: cannot resolve symbol [javac] symbol : variable Code [javac] location: class org.apache.commons.jelly.tags.jetty.SecurityHandlerTag [javac
[GUMP@brutus]: jakarta-commons-sandbox/commons-resources 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 folk at [EMAIL PROTECTED] Project commons-resources has an issue affecting its community integration, and has been outstanding for 34 runs. Project State : 'Failed', Reason 'Build Failed' Full details are available at: http://brutus.apache.org:8080/gump/jakarta-commons-sandbox/commons-resources/index.html That said, some snippets follow: The following annotations were provided: -DEBUG- Sole jar [commons-resources-20040623.jar] identifier set to project name -INFO- Enable debug output, due to a sequence of 33 previous errors. -INFO- Failed with reason build failed The following work was performed: http://brutus.apache.org:8080/gump/jakarta-commons-sandbox/commons-resources/gump_work/build_jakarta-commons-sandbox_commons-resources.html Work Name: build_jakarta-commons-sandbox_commons-resources (Type: Build) State: Failed Elapsed: 0 hours, 0 minutes, 2 seconds Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar org.apache.tools.ant.Main -debug -Dgump.merge=/usr/local/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dfinal.name=commons-resources-20040623 dist [Working Directory: /usr/local/gump/public/workspace/jakarta-commons-sandbox/resources] CLASSPATH : /usr/local/j2sdk1.4.2_04/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons-sandbox/resources/target/classes:/usr/local/gump/public/workspace/jakarta-commons-sandbox/resources/target/test-classes:/usr/local/gump/public/workspace/ant/dist/lib/ant-stylebook.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-20040623.jar:/usr/local/gump/public/workspace/jakarta-commons/digester/dist/commons-digester.jar:/usr/local/gump/public/workspace/jakarta-commons/discovery/dist/commons-discovery.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/jakarta-servletapi-4/lib/servlet.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar- [javac] import net.sf.hibernate.cfg.Configuration; [javac] ^ [javac] /usr/local/gump/public/workspace/jakarta-commons-sandbox/resources/src/java/org/apache/commons/resources/impl/HibernateResources.java:114: cannot resolve symbol [javac] symbol : class Session [javac] location: class org.apache.commons.resources.impl.HibernateResources [javac] Session session = null; [javac] ^ [javac] /usr/local/gump/public/workspace/jakarta-commons-sandbox/resources/src/java/org/apache/commons/resources/impl/HibernateResources.java:117: cannot resolve symbol [javac] symbol : class SessionFactory [javac] location: class org.apache.commons.resources.impl.HibernateResources [javac] SessionFactory sessionFactory = [javac] ^ [javac] /usr/local/gump/public/workspace/jakarta-commons-sandbox/resources/src/java/org/apache/commons/resources/impl/HibernateResources.java:118: cannot resolve symbol [javac] symbol : class Configuration [javac] location: class org.apache.commons.resources.impl.HibernateResources [javac] new Configuration().configure().buildSessionFactory(); [javac] ^ [javac] /usr/local/gump/public/workspace/jakarta-commons-sandbox/resources/src/java/org/apache/commons/resources/impl/HibernateResources.java:120: cannot resolve symbol [javac] symbol : class Query [javac] location: class org.apache.commons.resources.impl.HibernateResources [javac] Query q = session.getNamedQuery(QueryByLocale); [javac] ^ [javac] /usr/local/gump/public/workspace/jakarta-commons-sandbox/resources/src/java/org/apache/commons/resources/impl/HibernateResources.java:130: cannot resolve symbol [javac] symbol : class HibernateException [javac] location: class
Re: [collections] JDK1.5
It seems that the vendors are (indirectly) controlling this situation in commons now anyway. I believe that Websphere still only runs on 1.3, so that's the limiting factor as far as JDK versions go -- or else people who use Websphere can't use [collections]. I tried JBoss 3.2.4 the other day and it runs on 1.5 (3.2.3 didn't.) As far as I know, the latest version of Jonas doesn't run on 1.5. I'm not sure about the other servers. I think a branch, or as you suggested, a completely separate project may be the best way to go here. This may be a good thing to discuss for commons as a whole, because it's a complicated situation and no solution seems apparent, other than not using 1.5 features at all. There are wide-spreading new syntax features other than generics (varargs, autoboxing, enums) in 1.5 that seem very nice. But I don't really have the time or the energy for such a thing right now anyway, and I want to spend some time learning how to use the new features before I start abusing them. Stephen Colebourne wrote: While release 3.1 is being tidied up (still time to vote ;-), I thought I'd just put out a note about JDK1.5. One of the key enhancements in JDK1.5 is generics which allows typed classes using the angle bracket notation. The biggest area this impacts is collections. Clearly questions have to be raised as to how this affects [collections]. So far, I have done no work to see if [collections] will compile under JDK1.5. My expectation is that it will, but there are no guarantees. To take full advantage of generics will involve a considerable rewrite of [collections]. It will affect every class, and produce a version that only compiles on JDK1.5. I have no doubt that Sun spent many mandays changing the JDK classes to achieve this update. Personally, I have no plans to update [collections] to JDK1.5 (no itch, too much effort). If anyone else does, feel free to come in and either change [collections], or (more likely) create a new [collections15] project. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] JDK1.5
For the record, I'm -1 to abandoning JDK1.2 support in [collections] ;-) - Original Message - From: Rodney Waldhoff [EMAIL PROTECTED] For the record, while I'm +0 on moving toward JDK 1.5 support within collections, I'm certainly -1 on abandoning JDK 1.4 support in the near future. - Rod On Wed, 23 Jun 2004, Stephen Colebourne wrote: While release 3.1 is being tidied up (still time to vote ;-), I thought I'd just put out a note about JDK1.5. One of the key enhancements in JDK1.5 is generics which allows typed classes using the angle bracket notation. The biggest area this impacts is collections. Clearly questions have to be raised as to how this affects [collections]. So far, I have done no work to see if [collections] will compile under JDK1.5. My expectation is that it will, but there are no guarantees. To take full advantage of generics will involve a considerable rewrite of [collections]. It will affect every class, and produce a version that only compiles on JDK1.5. I have no doubt that Sun spent many mandays changing the JDK classes to achieve this update. Personally, I have no plans to update [collections] to JDK1.5 (no itch, too much effort). If anyone else does, feel free to come in and either change [collections], or (more likely) create a new [collections15] project. Stephen - 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 29772] New: - DateLocaleConverter does NOT return a default value if a conversion error occurs
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=29772. 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=29772 DateLocaleConverter does NOT return a default value if a conversion error occurs Summary: DateLocaleConverter does NOT return a default value if a conversion error occurs Product: Commons Version: 1.6 Final Platform: PC URL: http://jakarta.apache.org/commons/beanutils/apidocs/inde x.html OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Bean Utilities AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The org.apache.commons.beanutils.locale.converters.DateLocaleConverter does not return a default value even when the object is constructed with a default value. The reason for the exception being thrown lies within the BaseLocaleConvert class that DateLocaleConverter extends. I checked the source of BaseLocaleConvert and found that the boolean Default is set to false with this comment... Should we return the default value on conversion errors? There is no method supplied within the any of the subclasses that allows this boolean to be set. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] JDK1.5
On Wed, 23 Jun 2004, matthew.hawthorne wrote: It seems that the vendors are (indirectly) controlling this situation in commons now anyway. I believe that Websphere still only runs on 1.3, so that's the limiting factor as far as JDK versions go -- or else people who use Websphere can't use [collections]. Actually, WebSphere 5.1 runs on JDK 1.4; 5.02 and earlier do not. -- Martin Cooper I tried JBoss 3.2.4 the other day and it runs on 1.5 (3.2.3 didn't.) As far as I know, the latest version of Jonas doesn't run on 1.5. I'm not sure about the other servers. I think a branch, or as you suggested, a completely separate project may be the best way to go here. This may be a good thing to discuss for commons as a whole, because it's a complicated situation and no solution seems apparent, other than not using 1.5 features at all. There are wide-spreading new syntax features other than generics (varargs, autoboxing, enums) in 1.5 that seem very nice. But I don't really have the time or the energy for such a thing right now anyway, and I want to spend some time learning how to use the new features before I start abusing them. Stephen Colebourne wrote: While release 3.1 is being tidied up (still time to vote ;-), I thought I'd just put out a note about JDK1.5. One of the key enhancements in JDK1.5 is generics which allows typed classes using the angle bracket notation. The biggest area this impacts is collections. Clearly questions have to be raised as to how this affects [collections]. So far, I have done no work to see if [collections] will compile under JDK1.5. My expectation is that it will, but there are no guarantees. To take full advantage of generics will involve a considerable rewrite of [collections]. It will affect every class, and produce a version that only compiles on JDK1.5. I have no doubt that Sun spent many mandays changing the JDK classes to achieve this update. Personally, I have no plans to update [collections] to JDK1.5 (no itch, too much effort). If anyone else does, feel free to come in and either change [collections], or (more likely) create a new [collections15] project. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/validator/xdocs downloads.xml
husted 2004/06/23 16:52:22 Modified:validator/xdocs Tag: VALIDATOR_1_1_2_BRANCH downloads.xml Log: Website changes in anticipation of 1.1.3 release. Revision ChangesPath No revision No revision 1.1.2.2 +2 -2 jakarta-commons/validator/xdocs/downloads.xml Index: downloads.xml === RCS file: /home/cvs/jakarta-commons/validator/xdocs/downloads.xml,v retrieving revision 1.1.2.1 retrieving revision 1.1.2.2 diff -u -r1.1.2.1 -r1.1.2.2 --- downloads.xml 22 Jun 2004 02:31:46 - 1.1.2.1 +++ downloads.xml 23 Jun 2004 23:52:22 - 1.1.2.2 @@ -30,8 +30,8 @@ pstrongLatest Development Release/strong/p ul -lia href=http://www.apache.org/~martinc/validator/v1.1.2/commons-validator-1.1.2.zip;1.1.2 Binary/a/li -lia href=http://www.apache.org/~martinc/validator/v1.1.2/commons-validator-1.1.2-src.zip;1.1.2 Source/a/li +lia href=http://www.apache.org/~husted/validator/v1.1.3/commons-validator-1.1.3.zip;1.1.3 Binary/a/li +lia href=http://www.apache.org/~husted/validator/v1.1.3/commons-validator-1.1.3-src.zip;1.1.3 Source/a/li /ul !-- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/validator/xdocs downloads.xml
husted 2004/06/23 16:56:48 Modified:validator/xdocs Tag: VALIDATOR_1_1_2_BRANCH downloads.xml Log: Website changes in anticipation of 1.1.3 release. Revision ChangesPath No revision No revision 1.1.2.3 +2 -2 jakarta-commons/validator/xdocs/downloads.xml Index: downloads.xml === RCS file: /home/cvs/jakarta-commons/validator/xdocs/downloads.xml,v retrieving revision 1.1.2.2 retrieving revision 1.1.2.3 diff -u -r1.1.2.2 -r1.1.2.3 --- downloads.xml 23 Jun 2004 23:52:22 - 1.1.2.2 +++ downloads.xml 23 Jun 2004 23:56:47 - 1.1.2.3 @@ -30,8 +30,8 @@ pstrongLatest Development Release/strong/p ul -lia href=http://www.apache.org/~husted/validator/v1.1.3/commons-validator-1.1.3.zip;1.1.3 Binary/a/li -lia href=http://www.apache.org/~husted/validator/v1.1.3/commons-validator-1.1.3-src.zip;1.1.3 Source/a/li +lia href=http://www.apache.org/~husted/validator/v1.1.3/;1.1.3 Binary and Source/a/li +lia href=http://www.apache.org/~martinc/validator/v1.1.2/;1.1.2 Binary and Source/a/li /ul !-- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [vfs] Adding list children ability to Http provider
I would say the HTML parsing should be split out from the HTTP class since in general the HTTP body could be something else than HTML, XHTML, DHTML, etc. Thank you, Gary -Original Message- From: Eric Pugh [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 23, 2004 03:40 To: Commons-Dev Subject: [vfs] Adding list children ability to Http provider Hi all, I have been hacking my own copy of the http provider to provide a doListChildren() method. I added to HttpFileProvider a method setListChildrenStrategry() that takes in an implementation of the interface ListChildrenStrategy(). The ListChildrenStrategy is responsible for parsing through the results of a webpage and parsing out what is a child and what isn't... I need this because I want to parse a page like this: http://www.ibiblio.org/maven/jcifs/jars/ and pull out as 'children' all the links that end in .jar... Does this sound like something that should be added to HttpFileProvider? Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Validator] 1.1.3 ALPHA release available
I've tagged the 1.1.2 branch, and rolled the Validator 1.1.3 alpha release. It is posted in my Apache home directory for review: - http://www.apache.org/~husted/validator/v1.1.3/ Please review the release and advise whether you believe we should promote the release to Beta or General Release quality. I'm still reviewing the signing procedures, and should this release past the Alpha stage, I will sign and mirror it as appropriate. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] JDK1.5
Rodney Waldhoff wrote: For the record, while I'm +0 on moving toward JDK 1.5 support within collections, I'm certainly -1 on abandoning JDK 1.4 support in the near future. Is there a simple way to get Ant to strip out the angle brackets from the source before invoking javac? I'd imagine that a JRE 1.5 specific version of collections could be a lot smaller and simpler so collections15 might be a good way to go. I think that there will be a lot of demand for the existing collections codebase for some time so I doubt it will be abandoned any time soon. -- Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-commons/math build.xml
Ouch! Once again, maven is generating local path references. Does anyone
know how to stop this???
I had hand-edited the previous version to correct this.
Phil
[EMAIL PROTECTED] wrote:
brentworden2004/06/23 06:43:24
Modified:math build.xml
Log:
regenerated Ant script; dependencies were removed.
Revision ChangesPath
1.17 +25 -17jakarta-commons/math/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-commons/math/build.xml,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -r1.16 -r1.17
--- build.xml 2 Jun 2004 14:47:03 - 1.16
+++ build.xml 23 Jun 2004 13:43:23 - 1.17
@@ -1,18 +1,20 @@
?xml version=1.0 encoding=UTF-8?
!--build.xml generated by maven from project.xml version 1.0-dev
- on date June 2 2004, time 1044--
+ on date June 23 2004, time 0841--
project default=jar name=commons-math basedir=.
- property name=defaulttargetdir value=target
+ property name=defaulttargetdir value=C:\files\projects\apache\jakarta-commons\math/target
/property
- property name=libdir value=target/lib
+ property name=libdir value=C:\files\projects\apache\jakarta-commons\math/target/lib
/property
- property name=classesdir value=target/classes
+ property name=classesdir value=C:\files\projects\apache\jakarta-commons\math/target/classes
/property
- property name=testclassesdir value=target/test-classes
+ property name=testclassesdir value=C:\files\projects\apache\jakarta-commons\math/target/test-classes
/property
- property name=testreportdir value=target/test-reports
+ property name=testclassesdir value=C:\files\projects\apache\jakarta-commons\math/target/test-classes
+ /property
+ property name=testreportdir value=C:\files\projects\apache\jakarta-commons\math/target/test-reports
/property
property name=distdir value=dist
/property
@@ -53,7 +55,7 @@
/copy
/target
target name=jar description=o Create the jar depends=compile,test
-jar jarfile=target/${final.name}.jar excludes=**/package.html basedir=${classesdir}
+jar jarfile=${defaulttargetdir}/${final.name}.jar excludes=**/package.html basedir=${classesdir}
/jar
/target
target name=clean description=o Clean up the generated directories
@@ -123,8 +125,16 @@
/pathelement
/classpath
/javac
+copy todir=${testclassesdir}
+ fileset dir=C:\files\projects\apache\jakarta-commons\math\src\test
+include name=**/*.xml
+/include
+include name=**/*.txt
+/include
+ /fileset
+/copy
/target
- target name=javadoc description=o Generate javadoc depends=jar
+ target name=javadoc description=o Generate javadoc
mkdir dir=${javadocdir}
/mkdir
tstamp
@@ -141,25 +151,23 @@
include name=*.jar
/include
/fileset
-pathelement location=target/${final.name}.jar
+pathelement location=${defaulttargetdir}/${final.name}.jar
/pathelement
/classpath
/javadoc
/target
target name=get-deps unless=noget depends=init
-get dest=${libdir}/commons-collections-3.0.jar usetimestamp=true ignoreerrors=true src=http://www.ibiblio.org/maven//commons-collections/jars/commons-collections-3.0.jar;
-/get
-get dest=${libdir}/commons-lang-2.0.jar usetimestamp=true ignoreerrors=true src=http://www.ibiblio.org/maven//commons-lang/jars/commons-lang-2.0.jar;
+get dest=${libdir}/commons-lang-2.0.jar usetimestamp=true ignoreerrors=true src=http://www.ibiblio.org/maven/commons-lang/jars/commons-lang-2.0.jar;
/get
-get dest=${libdir}/commons-logging-1.0.3.jar usetimestamp=true ignoreerrors=true src=http://www.ibiblio.org/maven//commons-logging/jars/commons-logging-1.0.3.jar;
+get dest=${libdir}/commons-logging-1.0.3.jar usetimestamp=true ignoreerrors=true src=http://www.ibiblio.org/maven/commons-logging/jars/commons-logging-1.0.3.jar;
/get
-get dest=${libdir}/commons-discovery-0.2.jar usetimestamp=true ignoreerrors=true src=http://www.ibiblio.org/maven//commons-discovery/jars/commons-discovery-0.2.jar;
+get dest=${libdir}/commons-discovery-0.2.jar usetimestamp=true ignoreerrors=true src=http://www.ibiblio.org/maven/commons-discovery/jars/commons-discovery-0.2.jar;
/get
-get dest=${libdir}/junit-3.8.1.jar usetimestamp=true ignoreerrors=true src=http://www.ibiblio.org/maven//junit/jars/junit-3.8.1.jar;
+get dest=${libdir}/junit-3.8.1.jar usetimestamp=true ignoreerrors=true src=http://www.ibiblio.org/maven/junit/jars/junit-3.8.1.jar;
/get
-get dest=${libdir}/ant-1.5.jar usetimestamp=true ignoreerrors=true src=http://www.ibiblio.org/maven//ant/jars/ant-1.5.jar;
+get dest=${libdir}/ant-1.5.jar usetimestamp=true ignoreerrors=true
Re: cvs commit: jakarta-commons/math build.xml
Phil Steitz wrote:
Ouch! Once again, maven is generating local path references. Does
anyone know how to stop this???
I had hand-edited the previous version to correct this.
I had heard it was fixed back around rc1, but was never able to confirm
it. I think it's the ${basedir} references that screw it up, and I'm
never quite sure if I need ${basedir} in there, especially if I'm doing
multiproject builds.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/lang/src/java/org/apache/commons/lang/mutable MutableByte.java MutableDouble.java MutableFloat.java MutableInteger.java MutableLong.java MutableNumber.java MutableShort.java
bayard 2004/06/23 21:20:46
Modified:lang/src/java/org/apache/commons/lang/mutable
MutableByte.java MutableDouble.java
MutableFloat.java MutableInteger.java
MutableLong.java MutableNumber.java
MutableShort.java
Log:
rolled back the Mutable change. It doubled the size of a mutable instance, and as it
wrapped another object, doubled the work for garbage collection
Revision ChangesPath
1.3 +27 -3
jakarta-commons/lang/src/java/org/apache/commons/lang/mutable/MutableByte.java
Index: MutableByte.java
===
RCS file:
/home/cvs/jakarta-commons/lang/src/java/org/apache/commons/lang/mutable/MutableByte.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- MutableByte.java 13 Jun 2004 06:18:49 - 1.2
+++ MutableByte.java 24 Jun 2004 04:20:46 - 1.3
@@ -24,20 +24,44 @@
public class MutableByte extends MutableNumber {
/**
+ * Internal value.
+ */
+private byte value;
+
+/**
* Instantiates with the specified value
* @param value a value.
*/
public MutableByte(byte value) {
super();
-setValue(new Byte(value));
+this.value = value;
}
public void setValue(byte value) {
-setValue(new Byte(value));
+this.value = value;
+}
+
+public long longValue() {
+return this.value;
+}
+
+public double doubleValue() {
+return this.value;
+}
+
+public int intValue() {
+return this.value;
+}
+
+/**
+ * @return a codeByte/code
+ */
+public Object getValue() {
+return new Byte(this.value);
}
/**
- * @param value a codeNumber/code
+ * @param value a codeByte/code
*/
public void setValue(Object value) {
setValue(((Number)value).byteValue());
1.3 +24 -6
jakarta-commons/lang/src/java/org/apache/commons/lang/mutable/MutableDouble.java
Index: MutableDouble.java
===
RCS file:
/home/cvs/jakarta-commons/lang/src/java/org/apache/commons/lang/mutable/MutableDouble.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- MutableDouble.java13 Jun 2004 06:18:49 - 1.2
+++ MutableDouble.java24 Jun 2004 04:20:46 - 1.3
@@ -16,7 +16,7 @@
package org.apache.commons.lang.mutable;
/**
- * A mutable codeDouble/code.
+ * A mutable codeDouble/code
*
* @since 2.1
* @version $Id$
@@ -24,21 +24,39 @@
public class MutableDouble extends MutableNumber {
/**
+ * Internal value.
+ */
+private double value;
+
+/**
* Instantiates with the specified value
* @param value a value.
*/
public MutableDouble(double value) {
super();
-setValue(new Double(value));
+this.value = value;
}
public void setValue(double value) {
-setValue(new Double(value));
+this.value = value;
+}
+
+public double doubleValue() {
+return this.value;
+}
+
+public long longValue() {
+return (long)this.value;
+}
+
+public int intValue() {
+return (int)this.value;
+}
+
+public Object getValue() {
+return new Double(this.value);
}
-/**
- * @param value a codeNumber/code
- */
public void setValue(Object value) {
setValue(((Number)value).doubleValue());
}
1.3 +25 -6
jakarta-commons/lang/src/java/org/apache/commons/lang/mutable/MutableFloat.java
Index: MutableFloat.java
===
RCS file:
/home/cvs/jakarta-commons/lang/src/java/org/apache/commons/lang/mutable/MutableFloat.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- MutableFloat.java 13 Jun 2004 06:18:49 - 1.2
+++ MutableFloat.java 24 Jun 2004 04:20:46 - 1.3
@@ -16,7 +16,7 @@
package org.apache.commons.lang.mutable;
/**
- * A mutable codeFloat/code.
+ * A mutable codeFloat/code
*
* @since 2.1
* @version $Id$
@@ -24,21 +24,40 @@
public class MutableFloat extends MutableNumber {
/**
+ * Internal value.
+ */
+private float value;
+
+/**
* Instantiates with the specified value
+ *
* @param value a value.
*/
public MutableFloat(float value) {
super();
-setValue(new Float(value));
+this.value = value;
}
public void
[Jakarta Commons Wiki] Updated: Lang
Date: 2004-06-23T21:24:25 Editor: 12.220.74.99 Wiki: Jakarta Commons Wiki Page: Lang URL: http://wiki.apache.org/jakarta-commons/Lang no comment Change Log: -- @@ -22,7 +22,7 @@ 5. 21663 [lang] Add support in ToStringStyle for DateFormat. 5. 22172 [lang] DateUtils.parseCVS behavior parsing h:mm z 5. 22692 StringUtils.split ignores empty items - 5. 22717 [lang] MutableNumbers - '''Matt Hawthorne and Geronimo have implementations.''' + 5. 22717 [lang] MutableNumbers - '''Initial offering committed to CVS''' 5. 23749 [lang] [PATCH] NumberRange - adds inclusive and exclusive end points 5. 24910 new StringUtils.split methods that split on the whole separator string 5. 25560 DateUtils.truncate() is off by one hour when using a date in DST switch 'zone' - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 29540] - HttpState#matchCredentials is broken
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=29540. 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=29540 HttpState#matchCredentials is broken [EMAIL PROTECTED] changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-06-23 06:55 --- Patch committed Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 29767] - [API DOC] Authentication guide update: alternate authentication
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=29767. 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=29767 [API DOC] Authentication guide update: alternate authentication --- Additional Comments From [EMAIL PROTECTED] 2004-06-23 19:50 --- Created an attachment (id=11934) Patch - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 29767] - [API DOC] Authentication guide update: alternate authentication
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=29767. 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=29767 [API DOC] Authentication guide update: alternate authentication [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |ASSIGNED --- Additional Comments From [EMAIL PROTECTED] 2004-06-23 19:51 --- Please review content- and language-wise Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 29767] - [API DOC] Authentication guide update: alternate authentication
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=29767. 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=29767 [API DOC] Authentication guide update: alternate authentication [EMAIL PROTECTED] changed: What|Removed |Added Target Milestone|--- |3.0 Alpha 2 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: NTLM authentication to an MS Exchange web page account using HTTP Client V2.0
Hi All, Thanks again Adrian, very helpful. The NTCredentials API shows that the user, password, host, and domain can be set. Is it possible to use the logged-in users credentials? This way it would allow a user to be authenticated without reentering user/pw. Thanks for the help, Steve -Original Message- From: Adrian Sutton [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 22, 2004 4:20 PM To: Commons HttpClient Project Subject: Re: NTLM authentication to an MS Exchange web page account using HTTP Client V2.0 This sounds very much like the webserver isn't really using NTLM but is using Digest/Basic instead. If it really were using NTLM passing in DOMAIN\User would definitely not work because HttpClient doesn't check for that case. That would also explain why the realm isn't what you expect. I'd say a wire log should shed a lot of light on the situation (see http://jakarta.apache.org/commons/httpclient/logging.html ) Regards, Adrian Sutton On 23/06/2004, at 3:43 AM, Steve Johnson wrote: Hi All, Using HTTPClient version 2.0 We are using HTTPClient to login to a MS Exchange web page account. We can only get it to work by passing in the realm as null, and putting the domain back on to the front of the user to pass into NTCredentials(). new NTCredentials(authUserNameAppendDomainWithBackSlash + settings.getAuthUserName(), settings.getAuthPassword(), settings.getHost(), settings.getAuthDomain()) The comments on the interface say that only the username should be passed in, and NOT the domain. For other NTLM pages it works to use only the user, but this page has not worked for us without the domain like this myDomain\myUser. On State.setCredentials() we have tried passing the host, null, and the string realm in without the domain appended to user. All these attempts fail. We would prefer to use the API without the domain on the user. client.getState().setCredentials( null, //realm, null, settings.getHost()- settings.getHost(), new NTCredentials(authUserNameAppendDomain + settings.getAuthUserName(), settings.getAuthPassword(), settings.getHost(), settings.getAuthDomain()) ); Is there some documentation on how the realm interacts with authentication? Thanks for your time and effort, Steve Steve Johnson Software Engineer Mercury Interactive 720 564 - 6532 USA, Canada and the Americas 720 564-6620 Hours: M-F 08:00-17:00 MST (Mountain Standard Time) http://www.mercuryinteractive.com http://www.mercuryinteractive.com Looking for Answers to your SiteScope or SiteSeer questions? http://support.mercuryinteractive.com http://support.mercuryinteractive.com -- Intencha tomorrow's technology today Ph: 38478913 0422236329 Suite 8/29 Oatland Crescent Holland Park West 4121 Australia QLD www.intencha.com
Re: NTLM authentication to an MS Exchange web page account using HTTP Client V2.0
Hi Steve, There's no way that I know of to do this, however the builtin handling for the JRE seems to manage it so there's probably a com.sun class around somewhere that makes it possible. It would definitely be possibly using JNI. It's on my todo list to investigate how this is done but it's a fairly low priority (not a single user has complained yet - presumably because few of our users use NTLM). If you do find out how to do it please do let us know. Regards, Adrian Sutton. On 24/06/2004, at 2:31 AM, Steve Johnson wrote: Hi All, Thanks again Adrian, very helpful. The NTCredentials API shows that the user, password, host, and domain can be set. Is it possible to use the logged-in users credentials? This way it would allow a user to be authenticated without reentering user/pw. Thanks for the help, Steve -Original Message- From: Adrian Sutton [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 22, 2004 4:20 PM To: Commons HttpClient Project Subject: Re: NTLM authentication to an MS Exchange web page account using HTTP Client V2.0 This sounds very much like the webserver isn't really using NTLM but is using Digest/Basic instead. If it really were using NTLM passing in DOMAIN\User would definitely not work because HttpClient doesn't check for that case. That would also explain why the realm isn't what you expect. I'd say a wire log should shed a lot of light on the situation (see http://jakarta.apache.org/commons/httpclient/logging.html ) Regards, Adrian Sutton On 23/06/2004, at 3:43 AM, Steve Johnson wrote: Hi All, Using HTTPClient version 2.0 We are using HTTPClient to login to a MS Exchange web page account. We can only get it to work by passing in the realm as null, and putting the domain back on to the front of the user to pass into NTCredentials(). new NTCredentials(authUserNameAppendDomainWithBackSlash + settings.getAuthUserName(), settings.getAuthPassword(), settings.getHost(), settings.getAuthDomain()) The comments on the interface say that only the username should be passed in, and NOT the domain. For other NTLM pages it works to use only the user, but this page has not worked for us without the domain like this myDomain\myUser. On State.setCredentials() we have tried passing the host, null, and the string realm in without the domain appended to user. All these attempts fail. We would prefer to use the API without the domain on the user. client.getState().setCredentials( null, //realm, null, settings.getHost()- settings.getHost(), new NTCredentials(authUserNameAppendDomain + settings.getAuthUserName(), settings.getAuthPassword(), settings.getHost(), settings.getAuthDomain()) ); Is there some documentation on how the realm interacts with authentication? Thanks for your time and effort, Steve Steve Johnson Software Engineer Mercury Interactive 720 564 - 6532 USA, Canada and the Americas 720 564-6620 Hours: M-F 08:00-17:00 MST (Mountain Standard Time) http://www.mercuryinteractive.com http://www.mercuryinteractive.com Looking for Answers to your SiteScope or SiteSeer questions? http://support.mercuryinteractive.com http://support.mercuryinteractive.com -- Intencha tomorrow's technology today Ph: 38478913 0422236329 Suite 8/29 Oatland Crescent Holland Park West 4121 Australia QLD www.intencha.com -- Intencha tomorrow's technology today Ph: 38478913 0422236329 Suite 8/29 Oatland Crescent Holland Park West 4121 Australia QLD www.intencha.com PGP.sig Description: This is a digitally signed message part
