DO NOT REPLY [Bug 33427] - [configuration] Javadocs on public web site do not match public release
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=33427. 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=33427 [EMAIL PROTECTED] changed: What|Removed |Added Summary|Javadocs on public web site |[configuration] Javadocs on |do not match public release |public web site do not match ||public release -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33427] - [configuration] Versioned Javadocs
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=33427. 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=33427 [EMAIL PROTECTED] changed: What|Removed |Added Severity|trivial |enhancement Summary|[configuration] Javadocs on |[configuration] Versioned |public web site do not match|Javadocs |public release | --- Additional Comments From [EMAIL PROTECTED] 2005-02-08 11:29 --- Roger is right, we should keep a copy of the released APIs on the website just like the other commons components. Something like: http://jakarta.apache.org/commons/configuration/apidocs-RELEASE_TAG/ and for the current developpement tree: http://jakarta.apache.org/commons/configuration/apidocs/ If Maven could generate this automatically that would be great :) -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33415] - [validator] Getting Validator defitions from other resource types
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=33415. 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=33415 [EMAIL PROTECTED] changed: What|Removed |Added Summary|enable getting Validator|[validator] Getting |defitions from other|Validator defitions from |resource types |other resource types -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33303] - [io] Method wildcardMatch of FilenameUtils fail with recurent patterns
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=33303. 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=33303 [EMAIL PROTECTED] changed: What|Removed |Added Summary|Method wildcardMatch of |[io] Method wildcardMatch of |FilenameUtils fail with |FilenameUtils fail with |recurent patterns |recurent patterns -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r152660 - jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/actions/SetNextActionTestCase.java
Author: skitching
Date: Tue Feb 8 02:49:16 2005
New Revision: 152660
URL: http://svn.apache.org/viewcvs?view=revrev=152660
Log:
Test cases for SetNextAction.
Added:
jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/actions/SetNextActionTestCase.java
(with props)
Added:
jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/actions/SetNextActionTestCase.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/actions/SetNextActionTestCase.java?view=autorev=152660
==
---
jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/actions/SetNextActionTestCase.java
(added)
+++
jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/actions/SetNextActionTestCase.java
Tue Feb 8 02:49:16 2005
@@ -0,0 +1,111 @@
+/* $Id$
+ *
+ * Copyright 2001-2005 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.digester2.actions;
+
+import junit.framework.Test;
+import junit.framework.TestCase;
+import junit.framework.TestSuite;
+
+import java.io.StringReader;
+
+import org.xml.sax.InputSource;
+
+import org.apache.commons.logging.Log;
+import org.apache.commons.digester2.Digester;
+
+/**
+ * pTest Cases for the SetNextAction class./p
+ */
+
+public class SetNextActionTestCase extends TestCase {
+
+public static class Item {
+}
+
+public static class TestObject {
+private Item item;
+
+public void addItem(Item item) { this.item = item; }
+public Item getItem() { return item; }
+}
+
+// ---
+// Constructors
+// ---
+
+/**
+ * Construct a new instance of this test case.
+ *
+ * @param name Name of the test case
+ */
+public SetNextActionTestCase(String name) {
+super(name);
+}
+
+// --
+// Overall Test Methods
+// --
+
+/**
+ * Set up instance variables required by this test case.
+ */
+public void setUp() {
+}
+
+/**
+ * Return the tests included in this test suite.
+ */
+public static Test suite() {
+return (new TestSuite(SetNextActionTestCase.class));
+}
+
+/**
+ * Tear down instance variables required by this test case.
+ */
+public void tearDown() {
+}
+
+//
+// Individual Test Methods
+//
+
+/**
+ * Test basic operations.
+ */
+public void testBasicOperations() throws Exception {
+String inputText =
+root +
+ item/ +
+/root;
+
+InputSource source = new InputSource(new StringReader(inputText));
+
+Digester d = new Digester();
+d.addRule(/root/item, new CreateObjectAction(Item.class));
+d.addRule(/root/item, new SetNextAction(addItem));
+
+TestObject testObject = new TestObject();
+d.setInitialObject(testObject);
+d.parse(source);
+
+// string was passed ok
+Item item = testObject.getItem();
+assertNotNull(SetNextAction works, item);
+}
+}
Propchange:
jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/actions/SetNextActionTestCase.java
--
svn:keywords = Id
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[lang] 2.1
Hi,
Firstly, in RELEASE-NOTES.txt:
DEPRECTAIONS: should be DEPRECATIONS:
There was some discussion a while ago about having a variable
substitution utility available to handle strings like
Hello, ${name}
I seem to remember some code I wrote for Digester was adopted into Lang
for this, but I now see no trace of it. Was there a problem with it? (Or
was it some other commons project - my memory is pretty bad :-)
If it has been deliberately left out, that's fine - I wasn't pushing for
it to be included. But if there was just some minor issue (like no unit
tests) I would be happy to try to resolve it.
Thanks,
Simon
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: JCL problems
Richard et al., Before discussing relatively complex cases you mention, I think it would benefit everyone to realize that even in the most basic cases JCL will not work as expected. In your examples you refer to commons-logging-api.jar but commons-logging-api.jar and commons-logging.jar are not equivalent. The former does *not* include the classes org.apache.commons.logging.impl.Log4JLogger nor org.apache.commons.logging.impl.AvalonLogger. Thus, commons-logging-api.jar cannot bridge to log4j, for the simple reason that the bridge, Log4JLogger, is not there. Consider the following simple set up Parent [commons-logging.jar] ^ | Child [log4j.jar] Depending on how the thread context class loader is set,and the delegation model followed by the child loader, the above configuration, in the best case, will ignore log4j and in many other cases will throw a LogConfigurationException. The following set up will not fair much better (regardless of the delegation model): Parent [commons-logging.jar] ^ | Child [commons-logging.jar, log4j.jar] The only setup that will not blow in your face is the following: Parent [commons-logging-api.jar] ^ | Child [commons-logging.jar, log4j.jar] Note this is the set up used by Tomcat. Also note that it precludes the use of log4j by Tomcat itself as commons-logging-api.jar includes support for java.util.logging but not log4j. If you replace commons-logging-api.jar with commons-logging.jar, then you must place log4j.jar next to it unless you enjoy JCL throwing LogConfigurationExceptions at you. The bottom lines is that when compared with any statically bound bridging mechanism found in UGLI, JCL's dynamic discovery brings no added value but has a significant cost in aggravation. Richard, is there a point discussing complex cases when even the simplest ones don't work? Were you aware of problems in the above cases? At 09:52 PM 2/7/2005, Richard Sitze wrote: One problem that we encounter, in one form or another, is when we look for a resource that may or may not be visible. For example, a configuration file. As delivered, the JCL jar files do *not* include a configuration file. Parent [commons-logging-api.jar, Log4J.jar] ^ | Child This works as expected, for the most part [other ClassLoader problems aside]. So how do you configure the child application, in this case, to use a different logger? You might introduce a configuration file. Parent [commons-logging-api.jar, Log4J.jar] ^ | Child [commons-logging.properties, LogKit.jar] [cut] -- Ceki Gülcü The complete log4j manual: http://www.qos.ch/log4j/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Faulty method name?
In org.apache.commons.net.ftp.FTP there is a public method named removeProtocolCommandistener. I think this would be worth changing to removeProtocolCommandListener (with an L) in a future version. Regards, Per Lindberger
svn commit: r152666 - jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/actions/CreateObjectAction.java
Author: skitching
Date: Tue Feb 8 03:59:34 2005
New Revision: 152666
URL: http://svn.apache.org/viewcvs?view=revrev=152666
Log:
Very minor tidyups.
Modified:
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/actions/CreateObjectAction.java
Modified:
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/actions/CreateObjectAction.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/actions/CreateObjectAction.java?view=diffr1=152665r2=152666
==
---
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/actions/CreateObjectAction.java
(original)
+++
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/actions/CreateObjectAction.java
Tue Feb 8 03:59:34 2005
@@ -1,6 +1,6 @@
-/* $Id: $
+/* $Id$
*
- * Copyright 2001-2004 The Apache Software Foundation.
+ * Copyright 2001-2005 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.
@@ -15,110 +15,137 @@
* limitations under the License.
*/
-
package org.apache.commons.digester2.actions;
-
import org.xml.sax.Attributes;
import org.apache.commons.logging.Log;
-
import org.apache.commons.digester2.Context;
import org.apache.commons.digester2.AbstractAction;
import org.apache.commons.digester2.ParseException;
/**
- * Rule implementation that creates a new object and pushes it
- * onto the object stack. When the element is complete, the
- * object will be popped
+ * An Action that creates a new object and pushes it onto the object stack.
+ * When the element is complete, the object will be popped.
+ * p
+ * Normally a SetNextAction or CallMethodAction is used in partnership with
+ * this action to create a reference from some other object to this newly
+ * created object before it is popped from the object stack.
*/
public class CreateObjectAction extends AbstractAction {
-// --- Constructors
+// -
+// Instance Variables
+// -
/**
- * Construct an object create rule with the specified class name.
+ * The Java class name of the object to be created.
+ */
+protected String className = null;
+
+/**
+ * The attribute containing an override class name if it is present.
+ */
+protected String attributeName = null;
+
+// ---
+// Constructors
+// ---
+
+/**
+ * Construct a create object action which will create an instance
+ * of the specified class.
+ * p
+ * The classloader used to load the class will be the value returned
+ * from the SAXHandler.getClassLoader method. By default this is the same
+ * classloader which was used to load the Digester classes. For simple
+ * applications the default is fine, but applications running in more
+ * complex environments may need to use the following methods to control
+ * exactly which classloader is used:
+ * ul
+ * lisetExplicitClassLoader on Digester or SAXHandler classes
+ * lisetUseContextClassLoader on Digester or SAXHandler classes
+ * /ul
*
* @param className Java class name of the object to be created
*/
public CreateObjectAction(String className) {
-
-this(className, (String) null);
-
+this.className = className;
}
-
/**
- * Construct an object create rule with the specified class.
+ * Construct a create object action which will create an instance
+ * of the specified class.
+ * p
+ * Note that this is exactly equivalent to calling
+ * codenew CreateObjectAction(clazz.getClassName())code.
+ * Note in particular that the classloader associated with the specified
+ * Class object is ignored; when the rule fires the new instance will
+ * be created from a Class object which has been loaded via the classloader
+ * returned from saxHandler.getClassLoader. See method
+ * [EMAIL PROTECTED] #CreateObjectAction(String className)} for more
information.
*
- * @param clazz Java class name of the object to be created
+ * @param clazz Java class of the object to be created
*/
public CreateObjectAction(Class clazz) {
-
-this(clazz.getName(), (String) null);
-
+this.className = clazz.getClassName();
}
-
/**
- * Construct an object create rule with the specified class name and an
- * optional attribute name containing an override.
+ *
svn commit: r152667 - jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/actions/CreateObjectAction.java
Author: skitching
Date: Tue Feb 8 04:03:32 2005
New Revision: 152667
URL: http://svn.apache.org/viewcvs?view=revrev=152667
Log:
Fix silly typo. Also add svn:keywords property
Modified:
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/actions/CreateObjectAction.java
(contents, props changed)
Modified:
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/actions/CreateObjectAction.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/actions/CreateObjectAction.java?view=diffr1=152666r2=152667
==
---
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/actions/CreateObjectAction.java
(original)
+++
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/actions/CreateObjectAction.java
Tue Feb 8 04:03:32 2005
@@ -89,7 +89,7 @@
* @param clazz Java class of the object to be created
*/
public CreateObjectAction(Class clazz) {
-this.className = clazz.getClassName();
+this.className = clazz.getName();
}
/**
@@ -126,7 +126,7 @@
* @param attributeName Attribute name which, if present, contains an
*/
public CreateObjectAction(Class clazz, String attributeName) {
-this.className = clazz.getClassName();
+this.className = clazz.getName();
this.attributeName = attributeName;
}
Propchange:
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/actions/CreateObjectAction.java
--
svn:keywords = Id
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r152668 - jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/actions/CreateObjectActionTestCase.java
Author: skitching
Date: Tue Feb 8 04:04:25 2005
New Revision: 152668
URL: http://svn.apache.org/viewcvs?view=revrev=152668
Log:
Add test cases for CreateObjectAction
Added:
jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/actions/CreateObjectActionTestCase.java
(with props)
Added:
jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/actions/CreateObjectActionTestCase.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/actions/CreateObjectActionTestCase.java?view=autorev=152668
==
---
jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/actions/CreateObjectActionTestCase.java
(added)
+++
jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/actions/CreateObjectActionTestCase.java
Tue Feb 8 04:04:25 2005
@@ -0,0 +1,111 @@
+/* $Id$
+ *
+ * Copyright 2001-2005 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.digester2.actions;
+
+import junit.framework.Test;
+import junit.framework.TestCase;
+import junit.framework.TestSuite;
+
+import java.io.StringReader;
+
+import org.xml.sax.InputSource;
+
+import org.apache.commons.logging.Log;
+import org.apache.commons.digester2.Digester;
+
+/**
+ * pTest Cases for the CreateObjectAction class./p
+ */
+
+public class CreateObjectActionTestCase extends TestCase {
+
+public static class Item {
+}
+
+public static class TestObject {
+private Item item;
+
+public void addItem(Item item) { this.item = item; }
+public Item getItem() { return item; }
+}
+
+// ---
+// Constructors
+// ---
+
+/**
+ * Construct a new instance of this test case.
+ *
+ * @param name Name of the test case
+ */
+public CreateObjectActionTestCase(String name) {
+super(name);
+}
+
+// --
+// Overall Test Methods
+// --
+
+/**
+ * Set up instance variables required by this test case.
+ */
+public void setUp() {
+}
+
+/**
+ * Return the tests included in this test suite.
+ */
+public static Test suite() {
+return (new TestSuite(CreateObjectActionTestCase.class));
+}
+
+/**
+ * Tear down instance variables required by this test case.
+ */
+public void tearDown() {
+}
+
+//
+// Individual Test Methods
+//
+
+/**
+ * Test basic operations.
+ */
+public void testBasicOperations() throws Exception {
+String inputText =
+root +
+ item/ +
+/root;
+
+InputSource source = new InputSource(new StringReader(inputText));
+
+Digester d = new Digester();
+d.addRule(/root/item, new CreateObjectAction(Item.class));
+d.addRule(/root/item, new SetNextAction(addItem));
+
+TestObject testObject = new TestObject();
+d.setInitialObject(testObject);
+d.parse(source);
+
+// string was passed ok
+Item item = testObject.getItem();
+assertNotNull(CreateObjectAction works, item);
+}
+}
Propchange:
jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/actions/CreateObjectActionTestCase.java
--
svn:keywords = Id
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r152670 - jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/Digester.java
Author: skitching
Date: Tue Feb 8 04:51:03 2005
New Revision: 152670
URL: http://svn.apache.org/viewcvs?view=revrev=152670
Log:
* add setAllowUnknownExternalEntities and equivalent getter
* move getErrorHandler method within file
Modified:
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/Digester.java
Modified:
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/Digester.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/Digester.java?view=diffr1=152669r2=152670
==
---
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/Digester.java
(original)
+++
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/Digester.java
Tue Feb 8 04:51:03 2005
@@ -450,6 +450,30 @@
}
/**
+ * Specify whether an input xml document is permitted to reference external
+ * entities (including external DTDs, schemas, and include-files) that have
+ * not been specified by methods registerKnownEntity or setKnownEntities.
+ * p
+ * If this is allowed, then documents can take unbounded amounts of time
+ * to process, as they can attempt to download entities from the network
+ * (particularly via http urls).
+ * p
+ * This flag defaults to false (ie unknown external entities are not
allowed).
+ * In this case, any occurrence of such an entity within an xml document
+ * will cause an exception to be thrown.
+ */
+public void setAllowUnknownExternalEntities(boolean state) {
+saxHandler.setAllowUnknownExternalEntities(state);
+}
+
+/**
+ * See setAllowUnknownExternalEntities.
+ */
+public boolean getAllowUnknownExternalEntities() {
+return saxHandler.getAllowUnknownExternalEntities();
+}
+
+/**
* Specify whether an external DTD should be ignored, ie treated as if
* it were an empty file. This can be dangerous; DTDs can potentially
* contain definitions for default attribute values and entities that
@@ -740,19 +764,19 @@
}
/**
- * Return the error handler which will be used if the xml parser detects
- * errors in the xml input being parsed.
- */
-public ErrorHandler getErrorHandler() {
-return saxHandler.getErrorHandler();
-}
-
-/**
* Set the error handler for this Digester.
*
* @param errorHandler The new error handler
*/
public void setErrorHandler(ErrorHandler errorHandler) {
saxHandler.setErrorHandler(errorHandler);
+}
+
+/**
+ * Return the error handler which will be used if the xml parser detects
+ * errors in the xml input being parsed.
+ */
+public ErrorHandler getErrorHandler() {
+return saxHandler.getErrorHandler();
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE : [VFS] Problem with Zip files
XmlBeans doesn't matter in any way in my problem. Sorry for the confusion !!
But my real problem with Zip file is still alive :-(
Here is the stack trace of the exception catched :
org.apache.commons.vfs.FileSystemException: Could not replicate
file://c:/temp/toto.zip as it does not exist.
at
org.apache.commons.vfs.provider.AbstractFileSystem.replicateFile(AbstractFil
eSystem.java:310)
at
org.apache.commons.vfs.provider.zip.ZipFileSystem.init(ZipFileSystem.java:
59)
at
org.apache.commons.vfs.provider.zip.ZipFileProvider.doCreateFileSystem(ZipFi
leProvider.java:83)
at
org.apache.commons.vfs.provider.AbstractLayeredFileProvider.createFileSystem
(AbstractLayeredFileProvider.java:77)
at
org.apache.commons.vfs.provider.AbstractLayeredFileProvider.findFile(Abstrac
tLayeredFileProvider.java:57)
at
org.apache.commons.vfs.impl.DefaultFileSystemManager.resolveFile(DefaultFile
SystemManager.java:505)
at
org.apache.commons.vfs.impl.DefaultFileSystemManager.resolveFile(DefaultFile
SystemManager.java:483)
at
org.apache.commons.vfs.impl.DefaultFileSystemManager.resolveFile(DefaultFile
SystemManager.java:453)
at test.FileTest.test6(FileTest.java:154)
at test.FileTest.main(FileTest.java:37)
In the API, resolveFile may worked even with file which doesn't exist (Am I
wrong ?)
-Message d'origine-
De : Stéphane Rault [mailto:[EMAIL PROTECTED]
Envoyé : mardi 8 février 2005 08:43
À : commons-dev@jakarta.apache.org
Objet : [VFS] Problem with Zip files
I've a problem accessing Zip files with VFS API. I'm using XmlBeans V2
(cause of a bug in V1) compiled the 10 jan 2005.
Here is my sample code :
try {
StandardFileSystemManager manager = new
StandardFileSystemManager();
manager.setFilesCache(new SoftRefFilesCache());
manager.init();
// toto.txt doesn't exist in the folder
FileObject fileTxt = manager.resolveFile(c:\\temp\\toto.txt);
System.out.println(File Text works !!);
// toto.zip doesn't exist in the folder
FileObject fileZip =
manager.resolveFile(zip://c:\\temp\\toto.zip);
System.out.println(File Zip works !!);
// The file and the folder don't exist
FileObject fileInUnknownFolder =
manager.resolveFile(c:\\notPresentFolder\\toto.txt);
System.out.println(File in unknown Folder works !!);
} catch (Throwable t) {
System.out.println(It doesn't work !!);
}
And here is the output :
File Text works !!
It doesn't work !!
Note that c:\\temp is an existing directory.
Thanks in advance for your help...
Stéphane.
-
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]
[pool] Evictor thread
Hi all, I've just been through a particularly nasty case of debugging a memory leak where the evictor thread of GenericObjectPool (as used by DBCP) was not willing to die and let go of a disposed ClassLoader it held as the loader of a ProtectionDomain of its inherited SecurityContext. Now, while GenericObjectPool.close() was being called, the Thread running the Evictor code didn't observe the change in the _cancelled flag. This is unfortunately perfectly legal under the Java memory model given that there is neither a synchronization surrounding reading and writing of the flag, nor a volatile flag on the _cancelled flag. So, I'd ask you to fix this by adding the volatile flag to the boolean _cancelled field of the org.apache.commons.pool.impl.GenericObjectPool$Evictor class. Also, it'd be a big improvement in terms of scalability if the GenericObjectPool held a reference to the Thread running the Evictor object, and would interrupt() it on close(), so it doesn't take timeBetweenEvictionRunsMillis after a call to close() before the thread actually clears up. (All this might not be visible in a more-or-less statical environment, but is a problem in a system that frequently reloads classes using new class loaders which are a subclass of java.security.SecureClassLoader and therefore decorate threads with security contexts that ultimately hold a reference to the class loader. Few loitering class loaders can quickly escalate into an OutOfMemoryError.) Thanks, Attila - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r152672 - jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/actions/SetPropertiesAction.java
Author: skitching
Date: Tue Feb 8 05:37:44 2005
New Revision: 152672
URL: http://svn.apache.org/viewcvs?view=revrev=152672
Log:
Minor javadoc tweak
Modified:
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/actions/SetPropertiesAction.java
Modified:
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/actions/SetPropertiesAction.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/actions/SetPropertiesAction.java?view=diffr1=152671r2=152672
==
---
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/actions/SetPropertiesAction.java
(original)
+++
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/actions/SetPropertiesAction.java
Tue Feb 8 05:37:44 2005
@@ -82,7 +82,7 @@
* HashMap map = new HashMap();
* map.put(class, className);
* map.put(ignore, null);
- * SetPropertiesAction(map);
+ * Action action = new SetPropertiesAction(map);
* /pre/code/p
*
* pSee also [EMAIL PROTECTED] #addAlias} which allows the custom
mapping to be
@@ -130,7 +130,7 @@
* to the codestate/code property.
* All other attributes are mapped as usual using exact name matching.
* codepre
- * SetPropertiesAction(
+ * Action action = new SetPropertiesAction(
*new String[] {alt-city, alt-state},
*new String[] {city, state});
* /pre/code
@@ -142,7 +142,7 @@
* than be passed to a setIgnore method (the default behaviour). All other
* attributes are mapped as usual using exact name matching.
* codepre
- * SetPropertiesAction(
+ * Action action = new SetPropertiesAction(
*new String[] {class, ignore},
*new String[] {className});
* /pre/code
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[net] Faulty method name in class FTP
In org.apache.commons.net.ftp.FTP there is a public method named removeProtocolCommandistener. I think this would be worth changing to removeProtocolCommandListener (with an L) in a future version. Regards, Per L - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 19857] - [beanutils] Methods ConvertUtilsBean.convert could check for converters registered with base classes
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=19857.
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=19857
--- Additional Comments From [EMAIL PROTECTED] 2005-02-08 15:40 ---
Proposed resolution: extend ConvertUtilsBean.lookup() method implementation as
following:
Class: org.apache.commons.beanutils.ConvertUtilsBean
public Converter lookup(Class clazz) {
// lookup direct class
Converter converter = ((Converter) converters.get(clazz));
// recursive superclasses lookup
if (converter == null (!clazz.equals(Object.class)))
converter = lookup(clazz.getSuperclass());
// interfaces lookup
if (converter ==null){
Class[] interfaces = clazz.getInterfaces();
for (int i = 0; converter !=null i interfaces.length; i++)
converter=lookup(interfaces[i]);
}
return converter;
}
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[httpclient] Sending serialized object from httpclient to servlet.
Can any one tell me how send serialized object to servlet from httpclient. Thanks. Sanjeev tripathi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] 2.1
On Wed, 09 Feb 2005 00:16:05 +1300, Simon Kitching [EMAIL PROTECTED] wrote:
Hi,
Firstly, in RELEASE-NOTES.txt:
DEPRECTAIONS: should be DEPRECATIONS:
Thanks.
There was some discussion a while ago about having a variable
substitution utility available to handle strings like
Hello, ${name}
I seem to remember some code I wrote for Digester was adopted into Lang
for this, but I now see no trace of it. Was there a problem with it? (Or
was it some other commons project - my memory is pretty bad :-)
If it has been deliberately left out, that's fine - I wasn't pushing for
it to be included. But if there was just some minor issue (like no unit
tests) I would be happy to try to resolve it.
It's part of the .text package that's not finished yet and will go in
a later release.
Hen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[Email] setting charset
Hi, I think I just stumbled across a bug at the (unreleased) Email component. I want to send an Email with: Email e = new SimpleEmail(); // set some Recipients and Content here ... // I want to make sure that the following encoding is used. e.setCharset(Email.ISO_8859_1); e.send(); Now the thing is, that the set charset is ignored. Actually, when using this method the charset is *never* changed because of the implementation of Email.send() which just ignores the charset. Instead one has to use the method Email.setContent(Object, String) to make sure the encoding is used (though there is a code-block there which should just do that). I could send a patch for that, but currently I do not know the status and the further plans of the Email component. So please let me know if I can help out here. With regards Tino - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [httpclient] Sending serialized object from httpclient to servlet.
From: Sanjeev Tripathi [EMAIL PROTECTED] Can any one tell me how send serialized object to servlet from httpclient. Colin already gave you one option, (base 64 encoding the binary data): http://www.mail-archive.com/commons-dev%40jakarta.apache.org/msg57055.html For general information on base 64 encoding: http://www.google.com/search?q=java+base64+encoding Here's Jakarta Commons Codec, which includes a base 64 encoder: http://jakarta.apache.org/commons/codec/ http://jakarta.apache.org/commons/codec/apidocs/org/apache/commons/codec/binary/Base64.html Without actually trying it, it looks like all you need to do is: byte[] encodedData = Base64.encodeBase64( binaryData ); Then turn the byte[] into a String and POST it to the server as the value of a request parameter. If it's not too big, it should work the same way as sending a big string from a text area. The 'commons-dev' list is usually reserved for questions about the development of the libraries themselves, so I'm replying to commons-user (and copying dev). -- Wendy Smoak - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Email] setting charset
At 4:56 PM +0100 2/8/05, Tino Schöllhorn wrote: Hi, I think I just stumbled across a bug at the (unreleased) Email component. I want to send an Email with: Email e = new SimpleEmail(); // set some Recipients and Content here ... // I want to make sure that the following encoding is used. e.setCharset(Email.ISO_8859_1); e.send(); Now the thing is, that the set charset is ignored. Actually, when using this method the charset is *never* changed because of the implementation of Email.send() which just ignores the charset. Instead one has to use the method Email.setContent(Object, String) to make sure the encoding is used (though there is a code-block there which should just do that). I could send a patch for that, but currently I do not know the status and the further plans of the Email component. So please let me know if I can help out here. By all means, file an issue in Bugzilla, and attach a patch. I don't have time to roll a release, but I have time to apply a patch. Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com Narrow minds are weapons made for mass destruction -The Ex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RE : [VFS] Problem with Zip files
I haven't used vfs (yet) but I'm pretty sure the the file url should have 3
slashes:
file:///c:/temp/toto.zip
because urls reserve the spot between slash 2 and 3 for a host/port.
Rob
Stéphane Rault wrote:
XmlBeans doesn't matter in any way in my problem. Sorry for the confusion !!
But my real problem with Zip file is still alive :-(
Here is the stack trace of the exception catched :
org.apache.commons.vfs.FileSystemException: Could not replicate
file://c:/temp/toto.zip as it does not exist.
at
org.apache.commons.vfs.provider.AbstractFileSystem.replicateFile(AbstractFil
eSystem.java:310)
at
org.apache.commons.vfs.provider.zip.ZipFileSystem.init(ZipFileSystem.java:
59)
at
org.apache.commons.vfs.provider.zip.ZipFileProvider.doCreateFileSystem(ZipFi
leProvider.java:83)
at
org.apache.commons.vfs.provider.AbstractLayeredFileProvider.createFileSystem
(AbstractLayeredFileProvider.java:77)
at
org.apache.commons.vfs.provider.AbstractLayeredFileProvider.findFile(Abstrac
tLayeredFileProvider.java:57)
at
org.apache.commons.vfs.impl.DefaultFileSystemManager.resolveFile(DefaultFile
SystemManager.java:505)
at
org.apache.commons.vfs.impl.DefaultFileSystemManager.resolveFile(DefaultFile
SystemManager.java:483)
at
org.apache.commons.vfs.impl.DefaultFileSystemManager.resolveFile(DefaultFile
SystemManager.java:453)
at test.FileTest.test6(FileTest.java:154)
at test.FileTest.main(FileTest.java:37)
In the API, resolveFile may worked even with file which doesn't exist (Am I
wrong ?)
-Message d'origine-
De : Stéphane Rault [mailto:[EMAIL PROTECTED]
Envoyé : mardi 8 février 2005 08:43
À : commons-dev@jakarta.apache.org
Objet : [VFS] Problem with Zip files
I've a problem accessing Zip files with VFS API. I'm using XmlBeans V2
(cause of a bug in V1) compiled the 10 jan 2005.
Here is my sample code :
try {
StandardFileSystemManager manager = new
StandardFileSystemManager();
manager.setFilesCache(new SoftRefFilesCache());
manager.init();
// toto.txt doesn't exist in the folder
FileObject fileTxt = manager.resolveFile(c:\\temp\\toto.txt);
System.out.println(File Text works !!);
// toto.zip doesn't exist in the folder
FileObject fileZip =
manager.resolveFile(zip://c:\\temp\\toto.zip);
System.out.println(File Zip works !!);
// The file and the folder don't exist
FileObject fileInUnknownFolder =
manager.resolveFile(c:\\notPresentFolder\\toto.txt);
System.out.println(File in unknown Folder works !!);
} catch (Throwable t) {
System.out.println(It doesn't work !!);
}
And here is the output :
File Text works !!
It doesn't work !!
Note that c:\\temp is an existing directory.
Thanks in advance for your help...
Stéphane.
-
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 : RE : [VFS] Problem with Zip files
Unfortunately, you're wrong :
I've put
FileObject fileZip = manager.resolveFile(zip:///c:\\temp\\toto.zip);
And I got :
org.apache.commons.vfs.FileSystemException: Could not find file with URI
///c:\temp\toto.zip because it is a relative path, and no base URI was
provided.
-Message d'origine-
De : Rob Oxspring [mailto:[EMAIL PROTECTED]
Envoyé : mardi 8 février 2005 17:37
À : Jakarta Commons Developers List
Objet : Re: RE : [VFS] Problem with Zip files
I haven't used vfs (yet) but I'm pretty sure the the file url should have 3
slashes:
file:///c:/temp/toto.zip
because urls reserve the spot between slash 2 and 3 for a host/port.
Rob
Stéphane Rault wrote:
XmlBeans doesn't matter in any way in my problem. Sorry for the
confusion !!
But my real problem with Zip file is still alive :-(
Here is the stack trace of the exception catched :
org.apache.commons.vfs.FileSystemException: Could not replicate
file://c:/temp/toto.zip as it does not exist.
at
org.apache.commons.vfs.provider.AbstractFileSystem.replicateFile(Abstr
actFil
eSystem.java:310)
at
org.apache.commons.vfs.provider.zip.ZipFileSystem.init(ZipFileSystem.java:
59)
at
org.apache.commons.vfs.provider.zip.ZipFileProvider.doCreateFileSystem(ZipFi
leProvider.java:83)
at
org.apache.commons.vfs.provider.AbstractLayeredFileProvider.createFileSystem
(AbstractLayeredFileProvider.java:77)
at
org.apache.commons.vfs.provider.AbstractLayeredFileProvider.findFile(Abstrac
tLayeredFileProvider.java:57)
at
org.apache.commons.vfs.impl.DefaultFileSystemManager.resolveFile(DefaultFile
SystemManager.java:505)
at
org.apache.commons.vfs.impl.DefaultFileSystemManager.resolveFile(DefaultFile
SystemManager.java:483)
at
org.apache.commons.vfs.impl.DefaultFileSystemManager.resolveFile(DefaultFile
SystemManager.java:453)
at test.FileTest.test6(FileTest.java:154)
at test.FileTest.main(FileTest.java:37)
In the API, resolveFile may worked even with file which doesn't exist
(Am I wrong ?)
-Message d'origine-
De : Stéphane Rault [mailto:[EMAIL PROTECTED]
Envoyé : mardi 8 février 2005 08:43
À : commons-dev@jakarta.apache.org
Objet : [VFS] Problem with Zip files
I've a problem accessing Zip files with VFS API. I'm using XmlBeans V2
(cause of a bug in V1) compiled the 10 jan 2005.
Here is my sample code :
try {
StandardFileSystemManager manager = new
StandardFileSystemManager();
manager.setFilesCache(new SoftRefFilesCache());
manager.init();
// toto.txt doesn't exist in the folder
FileObject fileTxt =
manager.resolveFile(c:\\temp\\toto.txt);
System.out.println(File Text works !!);
// toto.zip doesn't exist in the folder
FileObject fileZip =
manager.resolveFile(zip://c:\\temp\\toto.zip);
System.out.println(File Zip works !!);
// The file and the folder don't exist
FileObject fileInUnknownFolder =
manager.resolveFile(c:\\notPresentFolder\\toto.txt);
System.out.println(File in unknown Folder works !!);
} catch (Throwable t) {
System.out.println(It doesn't work !!);
}
And here is the output :
File Text works !!
It doesn't work !!
Note that c:\\temp is an existing directory.
Thanks in advance for your help...
Stéphane.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [httpclient] Sending serialized object from httpclient to servlet.
Sanjeev Tripathi wrote: Thanks Wendy. I know how to serialize object to file or socket. But How I can convert object to bytes so I can use byte[] encodedData = Base64.encodeBase64( binaryData ); Try using the serialize(Serializable obj) method on org.apache.commons.lang.SerializationUtils. byte[] encodedData = Base64.encodeBase64(SerializationUtils.serialize(obj)); -- Bob Arnott - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[vfs] intellij idea licences
I've scored copies of IntelliJ IDEA for developing VFS from JetBrains: http://www.jetbrains.com/idea/opensource/ What should be the official project name for the purposed of licenses? Is just Jakarta Commons VFS good enough? How many licenses are needed? Cheers, --binkley - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [httpclient] Sending serialized object from httpclient to servlet.
Thanks Wendy. I know how to serialize object to file or socket. But How I can convert object to bytes so I can use byte[] encodedData = Base64.encodeBase64( binaryData ); could you give a example of it. I used this for strings but I am stuck for object String encodedPassword = new sun.misc.BASE64Encoder().encode(password.getBytes()) Thanks. Sanjeev Tripathi -Original Message- From: Wendy Smoak [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 08, 2005 10:23 AM To: commons-user@jakarta.apache.org Cc: Jakarta Commons Developers List Subject: Re: [httpclient] Sending serialized object from httpclient to servlet. From: Sanjeev Tripathi [EMAIL PROTECTED] Can any one tell me how send serialized object to servlet from httpclient. Colin already gave you one option, (base 64 encoding the binary data): http://www.mail-archive.com/commons-dev%40jakarta.apache.org/msg57055.ht ml For general information on base 64 encoding: http://www.google.com/search?q=java+base64+encoding Here's Jakarta Commons Codec, which includes a base 64 encoder: http://jakarta.apache.org/commons/codec/ http://jakarta.apache.org/commons/codec/apidocs/org/apache/commons/codec /binary/Base64.html Without actually trying it, it looks like all you need to do is: byte[] encodedData = Base64.encodeBase64( binaryData ); Then turn the byte[] into a String and POST it to the server as the value of a request parameter. If it's not too big, it should work the same way as sending a big string from a text area. The 'commons-dev' list is usually reserved for questions about the development of the libraries themselves, so I'm replying to commons-user (and copying dev). -- Wendy Smoak - 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 33450] New: - FTPClient: setSoTimeout() doesn't work properly on retrieveFile() method
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33450. 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=33450 Summary: FTPClient: setSoTimeout() doesn't work properly on retrieveFile() method Product: Commons Version: 1.3 Final Platform: PC OS/Version: Linux Status: NEW Severity: major Priority: P2 Component: Net AssignedTo: commons-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] My purpose is to terminate or cancel a retrieveFile() method if it takes more time than a specified timeout value. I connected with ftp client, set soTimeout to 700 msec and started to retrieve a file that takes 6000 seconds to get. When retrieving continues, after nearly 700 milisec., timeout occurs (I guess) but the retrieve procedure continues. After 6000msec. timeout exception is thrown. I don't want to wait for 6000 msec., and I think, I should get the exception after 700 msec. I couldn't find other helpful methods, setDataTimeout () method does something different I guess: If I set setDataTimeout to 10 msec., if a package of remote file comes more than 10 msec. late after the previous package , exception is thrown, am I right? -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL] nightly build broken
jar size is 45 bytes. .V -- Forums, Boards, Blogs and News in RiA http://www.boardVU.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [httpclient] Sending serialized object from httpclient to servlet.
Thanks Bob, Wendy. It worked well. Now I am able to send test object to servlet from http client. Now I need to test for My real objects and they are very big. I need to pass heavy collection of Value Objects to and from to the servlet from http client. Hope it will work there too. Thanks. Sanjeev Tripathi -Original Message- From: Bob Arnott [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 08, 2005 11:47 AM To: 'Jakarta Commons Developers List' Subject: RE: [httpclient] Sending serialized object from httpclient to servlet. Sanjeev Tripathi wrote: Thanks Wendy. I know how to serialize object to file or socket. But How I can convert object to bytes so I can use byte[] encodedData = Base64.encodeBase64( binaryData ); Try using the serialize(Serializable obj) method on org.apache.commons.lang.SerializationUtils. byte[] encodedData = Base64.encodeBase64(SerializationUtils.serialize(obj)); -- Bob Arnott - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [EMAIL] nightly build broken
The build works, but the unit tests (which are automatically execute as part of the script) fail ... therefore, no binaries are created. The [email] developers are going to have to fix that (or tell me how to set up my environment so the tests can work). Craig On Tue, 08 Feb 2005 13:41:07 -0600, Vic [EMAIL PROTECTED] wrote: jar size is 45 bytes. .V -- Forums, Boards, Blogs and News in RiA http://www.boardVU.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vfs] intellij idea licences
Meant to send them an email yesterday to ask how they wanted to handle licences. ie) could we just organise an ASF licence, would it be per person etc. I'll send that email now, as it gets silly if we end up with every codebase having to talk with them individually. Failing that: Apache Jakarta Commons VFS :) Hen On Tue, 08 Feb 2005 11:59:15 -0600, B. K. Oxley (binkley) [EMAIL PROTECTED] wrote: I've scored copies of IntelliJ IDEA for developing VFS from JetBrains: http://www.jetbrains.com/idea/opensource/ What should be the official project name for the purposed of licenses? Is just Jakarta Commons VFS good enough? How many licenses are needed? Cheers, --binkley - 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: [logging] 1.0.5 release: plan update and bug review
On Tue, 2005-02-08 at 00:46, Richard Sitze wrote:
Just for the record, might as well get this out now :-)
I'm going to take a fairly STRONG position against fixing discovery in a
1.0.6 if that is the ONLY change going in.
note that i said 'improve' not fix :)
now that i understand the issues more clearly, i think that it would be
possible to improve the classloader related behaviour of the 1.0.x
series of releases but this would not be a fix (in the wider sense) for
discovery. it wouldn't be unreasonable to create a JCL 1.0.6 release
along those lines provided that there were volunteers willing to carry
out the work.
Why?
- The fix I envision will necessitate backwards incompatible behavior
in a standalone commons-logging.jar file. This requires more than a
point release.
i've been thinking along similar lines for a while but i think that it's
probably possible to maintain a large measure of backwards
compatibility. IMHO the measure of backwards compatibility will go a
long way to determining the rate of adoption.
however, i would definitely agree that any radical change of
architecture should be more than a point release.
- commons-logging 2.0 should default to a simple discovery process very
much in line with the UGLI discovery [typical J2SE configuration], and
give up all attempts for managing complicated ClassLoader hierarchy
problems.
i favour a minimal API layer with no symbolic coupling downwards. i'd
prefer to use just a system property for configuration: even loading a
resource file can sometimes be a little interesting.
i agree that all classloading discovery should be delegated to an
implementation loaded by name.
- commons-logging 2.0 should to defer to commons-discovery, if
commons-discovery is available in an appropriate class-loader
i've always wanted an alternative mechanism based on commons-discovery.
[and yes, this means discovering commons-discovery... headache time.. but
we'll
keep it simple anyway :-) right?].
i'd prefer to side step this particular can-of-worms and i think that
it's possible to do so. i'd like to see the configuration of the basic
discovery mechanism separated from the execution of that mechanism.
though JCL needs to run in a variety of environments with differing
discovery mechanisms, for each environment the basic discovery mechanism
can (and should) be constant.
JCL could provide some defaults probably something similar to the
current LogFactory ('classic') and a commons-discovery adapter. by
making the (not unreasonable) insistance that an appropriate set of
classes (JCL API plus discovery mechanism) is deployed together in the
same classloader, it should be possible to use the classloader to load
the discovery implementation by name.
- I want to fix the ClassLoader problems in commons-discovery.
+1
- Specifically, allow the commons-logging 2.0 + commons-discover X.Y to
function well under J2EE and OSGI environs... or any other complicated
ClassLoader environment.
+1
Now, all that aside, someone is going to argue that we should go ahead
and fix the ClassLoader problems in 1.0.6. All well and good, but note
that I want to *encourage* use of the new branch, and let the old branch
rest piecefully [did I say die? I didn't say die... did I?]. If you want
a sophisticated discovery mechanism in complicated ClassLoader environs,
then defer to the new pluggable discovery mechanism and be ready to work
in OSGI, J2EE, or whereever. If you don't need it, then what comes in
commons-logging.jar will be sufficient for simple J2SE applications.
if people want to continue refining the 1.0.x series of releases, that's
cool. following the best apache traditions
(http://incubator.apache.org/learn/rules-for-revolutionaries.html),
providing that there are developers willing to develop and reasons to
code, there's no reason why the birth of a new branch should mean the
death of the other.
users have their own reasons for choosing one open source product over
another: some good, some bad. IMHO the merits of the new stuff will turn
out be pretty clear. it's far better to be positive about the merits of
the new than focusing on the drawbacks of the old.
- robert
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vfs] intellij idea licences
Henri Yandell wrote: Meant to send them an email yesterday to ask how they wanted to handle licences. ie) could we just organise an ASF licence, would it be per person etc. I am not a committer for ASF. Would this still apply to me? Cheers, --binkley - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[logging] discovery error handling
one of the drawbacks about JCL 1.0.x is the approach to handling errors in the configuration and discovery mechanism. JCL falls down and (in most commons use cases) takes the application with it. it also fails to provide useful diagnostic information. i've been considering for a while adopting a system for error handling which allows a system property to be used to tune the exactly behaviour: classic more would throw runtimes (as per now), silent more would suppress all issues continuing to function as well as it is able and diagnostic would print diagnostic information to System.out. though not all environments would allow system properties to be set, i think that this would improve matters for many common use cases. opinions? - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] 1.0.5 release: plan update and bug review
since there have been no objections (at least to the 1.0.5 release), i'm going to start work on the plan now. - robert On Mon, 2005-02-07 at 22:16, robert burrell donkin wrote: back up and running now :) i propose to take a branch for the 1.0.5 release as soon as the outstanding matters have been discussed. this will free up head for possible work either towards a 1.0.6 (with improved discovery) or a major revision. brian contributed the required documentation (many thanks) so all that i have on my list now is to work out which bugs will be addressed for this release. here's the analysed consensus from the wiki (thanks to dennis for his review). please feel free to jump in and disagree if appropriate. in the event of no complaints, i propose to update bugzilla and take the 1.0.5 release branch some time after 2200GMT tomorrow (tuesday). anyone with a problem with this plan should jump in now... - robert Open Bugs - Bug 28291 LATER http://issues.apache.org/bugzilla/show_bug.cgi?id=28291 Classloader related, these issues will be addressed by later releases Bug 30131 CLOSE http://issues.apache.org/bugzilla/show_bug.cgi?id=30131 This is related to httpclient example code but Dennis posted a followup (with no response) and I've check the example code (which looks ok to me). Bug 30268 LATER http://issues.apache.org/bugzilla/show_bug.cgi?id=30268 Needs architectural changes Bug 30632 CLOSE http://issues.apache.org/bugzilla/show_bug.cgi?id=30632 See 30131 Bug 32618 LATER http://issues.apache.org/bugzilla/show_bug.cgi?id=32618 The new proposal by IBM. Bug 32662 WONTFIX http://issues.apache.org/bugzilla/show_bug.cgi?id=32662 See http://marc.theaimsgroup.com/?l=jakarta-commons-devm=110780577017737w=2 Bug 32691 LATER http://issues.apache.org/bugzilla/show_bug.cgi?id=32691 General heading of improvements to API. (Needs a champion.) Bug 33347 LATER http://issues.apache.org/bugzilla/show_bug.cgi?id=33347 API improvements. (Needs a champion.) - 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 30131] - [logging] Getting Logger to give trace Information
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=30131. 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=30131 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2005-02-08 23:19 --- No followup has been received to Dennis' posting. I've tested the latest httpclient documentation and it seems to be in order. Posting a question to the user list would probably have provided more productive. If anyone feels the need to re-open this, please supply a unit test demonstrating the issue. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30632] - [logging] print/display the wire log!
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=30632. 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=30632 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2005-02-08 23:20 --- I've tested the latest httpclient documentation and it seems to be in order. Posting a question to the user list would probably have provided more productive. If anyone feels the need to re-open this, please supply a unit test demonstrating the issue. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 32662] - [logging] Log writer not closed with log4j after restarting a webapp (Tomcat 5.0)
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=32662. 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=32662 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2005-02-08 23:22 --- This is not within the scope of JCL. A deployer who knows that the component is going to be deployed with Log4J should take the steps required to ensure that the appenders are closed upon restart of the web application. See http://marc.theaimsgroup.com/?l=jakarta-commons-devm=110780577017737w=2 -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 32691] - [logging] Convenience methods for cleaner application code
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=32691. 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=32691 --- Additional Comments From [EMAIL PROTECTED] 2005-02-08 23:24 --- The future shape of the JCL component interface is currently under develpment. Will anyone who cares about this please join the commons-dev mailing list and champion it. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33347] - [logging] Allow logging additional fields to database
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=33347. 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=33347 --- Additional Comments From [EMAIL PROTECTED] 2005-02-08 23:25 --- The future shape of the JCL component interface is currently under develpment. Will anyone who cares about this please join the commons-dev mailing list and champion it. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r152955 - jakarta/commons/proper/logging/branches/RELEASE_BRANCH_1_0_5
Author: rdonkin Date: Tue Feb 8 14:54:27 2005 New Revision: 152955 URL: http://svn.apache.org/viewcvs?view=revrev=152955 Log: Created branch for 1.0.5 release Added: jakarta/commons/proper/logging/branches/RELEASE_BRANCH_1_0_5/ - copied from r152954, jakarta/commons/proper/logging/trunk/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Jakarta Commons Wiki] Updated: Logging/1.0.5ReleasePlan
Date: 2005-02-08T14:57:46 Editor: RobertBurrellDonkin Wiki: Jakarta Commons Wiki Page: Logging/1.0.5ReleasePlan URL: http://wiki.apache.org/jakarta-commons/Logging/1.0.5ReleasePlan Updated release status Change Log: -- @@ -6,7 +6,7 @@ == Status == -RELEASE PLAN: preparing for release branch +RELEASE PLAN: release branch taken, starting release candidate preparations @@ -16,11 +16,13 @@ == Documentation Review == - * Ensure that javadocs and website are up to date. + * Ensure that javadocs and website are up to date. ''DONE'' * The new optional distribution which offers enhanced memory recycling in some environments needs documentation creating. ''DONE'' (thanks brian) == Bug Review == +''DONE'' (thanks Dennis) + * Bug 28291 ''[logging] Context``Class``Loader may load Log impl from wrong context in JDK 1.4''. This one's about classloading and should not be handled in 1.0.5. * +1 Any solution I had, I've now forgotten... * Bug 30131 ''[logging] Getting Logger to give trace Information''. I made a comment on this one back in July with some suggestions to try for the reporter. No reply was made on those suggestions. I propose we close this one. @@ -55,6 +57,8 @@ == Repository == A release branch will be taken as soon as the preliminary work is complete. This will allow work to continue on HEAD. If possible, this step should be postponed until after jakarta commons is converted to SVN. + +''DONE'' == Release Notes == - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 32662] - [logging] Log writer not closed with log4j after restarting a webapp (Tomcat 5.0)
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=32662. 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=32662 --- Additional Comments From [EMAIL PROTECTED] 2005-02-08 23:58 --- I believe this is in scope of JCL, why else there is method which suggests all resources will be released (org.apache.commons.logging.LogFactory.releaseAll ()) with Log4j specific implementation class (org.apache.commons.logging.impl.Log4jFactory)? -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 32662] - [logging] Log writer not closed with log4j after restarting a webapp (Tomcat 5.0)
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=32662. 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=32662 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WONTFIX | --- Additional Comments From [EMAIL PROTECTED] 2005-02-09 00:03 --- Why else to use commons logging if we have to take care about Log4j specifics? -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] 1.0.5 release: plan update and bug review
release branch taken. next i'll be updating the trunk to JCL version 1.0.6-dev (just a name, not a decision ;) and rebuilding the website with news about the 1.0.5 release (unless someone beats me to it). then pushing towards a 1.0.5 release candidate. - robert On Tue, 2005-02-08 at 22:33, robert burrell donkin wrote: since there have been no objections (at least to the 1.0.5 release), i'm going to start work on the plan now. - robert On Mon, 2005-02-07 at 22:16, robert burrell donkin wrote: back up and running now :) i propose to take a branch for the 1.0.5 release as soon as the outstanding matters have been discussed. this will free up head for possible work either towards a 1.0.6 (with improved discovery) or a major revision. brian contributed the required documentation (many thanks) so all that i have on my list now is to work out which bugs will be addressed for this release. here's the analysed consensus from the wiki (thanks to dennis for his review). please feel free to jump in and disagree if appropriate. in the event of no complaints, i propose to update bugzilla and take the 1.0.5 release branch some time after 2200GMT tomorrow (tuesday). anyone with a problem with this plan should jump in now... - robert Open Bugs - Bug 28291 LATER http://issues.apache.org/bugzilla/show_bug.cgi?id=28291 Classloader related, these issues will be addressed by later releases Bug 30131 CLOSE http://issues.apache.org/bugzilla/show_bug.cgi?id=30131 This is related to httpclient example code but Dennis posted a followup (with no response) and I've check the example code (which looks ok to me). Bug 30268 LATER http://issues.apache.org/bugzilla/show_bug.cgi?id=30268 Needs architectural changes Bug 30632 CLOSE http://issues.apache.org/bugzilla/show_bug.cgi?id=30632 See 30131 Bug 32618 LATER http://issues.apache.org/bugzilla/show_bug.cgi?id=32618 The new proposal by IBM. Bug 32662 WONTFIX http://issues.apache.org/bugzilla/show_bug.cgi?id=32662 See http://marc.theaimsgroup.com/?l=jakarta-commons-devm=110780577017737w=2 Bug 32691 LATER http://issues.apache.org/bugzilla/show_bug.cgi?id=32691 General heading of improvements to API. (Needs a champion.) Bug 33347 LATER http://issues.apache.org/bugzilla/show_bug.cgi?id=33347 API improvements. (Needs a champion.) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 32662] - [logging] Log writer not closed with log4j after restarting a webapp (Tomcat 5.0)
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=32662. 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=32662 --- Additional Comments From [EMAIL PROTECTED] 2005-02-09 00:24 --- It would seem to me that Vedran is right that a webapp that uses commons-logging should not need to make direct calls to log4j on shutdown (this is what you were suggesting, Robert?) However as Robert states, the solution needs care; if two webapps are using log4j and one of them is reloaded it would be very unpleasant if the other webapp suddenly had its logging implementation shut down. So before adding a call to LogManager.shutdown in log4j, it would be wise to determine whether this would happen or not. I would initially assume that log4j.jar would be deployed in the webapp-specific libraries. As such, a separate copy should exist within each webapp (different classloaders used) and therefore calling shutdown on one would *not* affect the other. However I'm no expert on containers; I know that in some cases containers want to provide the underlying logging implementation so that logging is centralised for all webapps. If the container chooses log4j as its centralised logging implementation, then what? -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[httpclient] RE: Http Client- How to send and recieve Serialized Object using Http Client
Can any one give me url for getting Base64OutputStream and
Base64InputStream classes on google.
Tahnks.
Sanjeev Tripathi
-Original Message-
From: Sharples, Colin [mailto:[EMAIL PROTECTED]
Sent: Monday, February 07, 2005 2:57 PM
To: Jakarta Commons Developers List
Subject: Spam: RE: Http Client- How to send and recieve Serialized
Object using Http Client
Assuming it's not just because of the typo in the content type (should
be application/octet-stream), you could try base 64 encoding the
object output stream, and then you can just use text/plain content type.
On the other end you base 64 decode the response body before passing it
to the object input stream. There are plenty of examples of how to do
base 64 encode/decode on the web.
Colin Sharples
IBM Advisory IT Specialist
Email: [EMAIL PROTECTED]
-Original Message-
From: Sanjeev Tripathi [mailto:[EMAIL PROTECTED]
Sent: Tuesday, 8 February 2005 8:18 a.m.
To: commons-dev@jakarta.apache.org
Subject: Http Client- How to send and recieve Serialized Object using
Http Client
Hi,
I am working on thick client proxy that will connect to servlet and
retrive and save data to database. I am using Http Client for
communication.
I am able to send string values using parameter in request
as follows.
//
**
NameValuePair userid = new NameValuePair(LOGIN_NAME,
login);
NameValuePair password = new NameValuePair(LOGIN_PASSWORD,
password);
NameValuePair thickClient = new NameValuePair(ThickClient,
ThickClient);
authpost.setRequestBody(
new NameValuePair[] {action, url, userid,
password,thickClient});
//
**
I am able to send xml string as parameter and able to receive it back
from response as String.
But I am getting problem in serialized user defined objects
communication. Following is not working
//*In Servlet*
if (request.getParameter(ThickClient).equals(ThickClient)) {
response.setContentType(application/octel-stream);
ObjectOutputStream oos = new
ObjectOutputStream(response.getOutputStream());
oos.writeObject(new
com.parago.communication.SubmissionVO(1,Controll
Servlet));
oos.flush();
oos.close();
return;
}
In Thick Client Proxy *
client.executeMethod(authpost);
System.out.println(Login form post: +
authpost.getStatusCode());
ObjectInputStream ois = new
ObjectInputStream(authpost.getResponseBodyAsStream());
SubmissionVO vo = (SubmissionVO)ois.readObject();
System.out.println(id : +vo.getSubmissionId() +: desc: +
vo.getDescription());
//**Here SubmissionVO is Serialized Object***
public class SubmissionVO implements java.io.Serializable{
public SubmissionVO(int id,String desc) {
this.submissionId = id;
this.description = desc;
}
private int submissionId;
private String description;
public int getSubmissionId () {
return submissionId;
}
public String getDescription() {
return description;
}
}
//***
Please suggest me. How to send and receive Serialized User
Defined Value
Objects in using Http Client.
Thanks.
Sanjeev Tripathi
__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
__
-
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] intellij idea licences
On Tue, 08 Feb 2005 16:08:07 -0600, B. K. Oxley (binkley) [EMAIL PROTECTED] wrote: Henri Yandell wrote: Meant to send them an email yesterday to ask how they wanted to handle licences. ie) could we just organise an ASF licence, would it be per person etc. I am not a committer for ASF. Would this still apply to me? Probably not. Seems like a bit of an anomaly. I imagined it would be rare for somebody to pass Jetbrains' rule of: Some evidence of your engagement in the project and want to use an IDE for that project and not be either a committer, or making a lot of contributions/patches and heading towards a committer vote. I may be over-simplifying things. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 32662] - [logging] Log writer not closed with log4j after restarting a webapp (Tomcat 5.0)
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=32662. 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=32662 [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2005-02-09 02:27 --- There is a fundamental misunderstanding here of the purpose and nature of commons-logging. It may be somewhat confused by the existence of the Log4jFactory. Note the following, from the Log4jFactory javadoc: * @deprecated Per discussion on COMMONS-DEV, the behind-the-scenes use * of this class as a proxy factory has been removed. For 1.0, you * can still request it directly if you wish, but it doesn't really * do anything useful, and will be removed in 1.1. Now, that aside, the Log4jFactory does NOT initialize or manage Log4j: feel free to review the source for Log4jFactory, it doesn't have anything to do with initializing Log4j. And neither should commons-logging. It's not designed to manage the logger impl. THAT task remains in your core application. Please note that commons- logging is NOT intended to make your *application* independent from a logger implementation, though you are welcome to use it's API's to minimize impact to your application if you choose to change logger implementations. JCL is designed to help make your *components* [not applications] independent from logger implementations. You wouldn't expect each individual component to try to start/stop your apps logger, and so you shouldn't expect commons- logging to do so either [weak analogy, if you have complaints, forget it..]. The *expected* behavior of your application/framework is as follows: app startup: - initialize logging implementation [Avalon, Log4j, Whatever] - JCL configured to use appropriate logging impl, possibly via commons-logging.properties file - initializes components begins processing component at runtime: httpclient: component logs using JCL axis: component log using JCL other component(s): log using JCL app shutdown: - shutdown components [as needed] - shutdown logging [if needed] At NO time does JCL presume to *know* that your app is starting up or shutting down, it presume only that you want to use a specific logger impl, and presumes that your app runtime environment will supply the appropriate logger. Please also see the note I sent to the developers mailing list on this topic, it provides additional details on how your proposed fix will cause problems in other environs. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 32662] - [logging] Log writer not closed with log4j after restarting a webapp (Tomcat 5.0)
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=32662. 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=32662 --- Additional Comments From [EMAIL PROTECTED] 2005-02-09 02:39 --- Would note that Vedran has already discovered that Log4jFactory is NOT used [by default] with JCL, as his patch is placing a Log4J specific call to LogManager.release() into LogFactory, as opposed to Log4jFactory. As stated, for web-apps: The web-app OWNS the logging implementation, unless you have some understanding that your HOSTING environment is fronting JCL and a logger impl for you. In the first case, the web app is responsible for initializing and terminating the logger, as appropriate, for the context of the web-app. Your app may ALSO choose to use JCL. The benefits are: - if you elect to use a different logger impl [initialize terminate as appropriate for THAT logger impl], then you won't have to change any other part of your web-app. - if your web-app is using OTHER components [many open-source components] and technologies that leverage JCL, then they will log as you would like them to, in the context of your web-app. In the second case, you might reasonably assume that the hosting environment should to do what is right to manage the logger impl [whatever that means].. but that falls outside the scope of JCL and this defect. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] discovery error handling
robert burrell donkin [EMAIL PROTECTED] wrote on 02/08/2005 04:25:57 PM: one of the drawbacks about JCL 1.0.x is the approach to handling errors in the configuration and discovery mechanism. JCL falls down and (in most commons use cases) takes the application with it. it also fails to provide useful diagnostic information. i've been considering for a while adopting a system for error handling which allows a system property to be used to tune the exactly behaviour: classic more would throw runtimes (as per now), silent more would suppress all issues continuing to function as well as it is able and diagnostic would print diagnostic information to System.out. though not all environments would allow system properties to be set, i think that this would improve matters for many common use cases. opinions? Yes :-), focus all efforts on improving discovery and diagnostics on commons-discovery, and let's abandon further efforts to improve JC logging/discovery, other than to regress back to simple simple simple behavior that doesn't break so easily [ala the UGLI discovery]. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] *** Richard A. Sitze IBM WebSphere WebServices Development
DO NOT REPLY [Bug 32662] - [logging] Log writer not closed with log4j after restarting a webapp (Tomcat 5.0)
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=32662. 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=32662 --- Additional Comments From [EMAIL PROTECTED] 2005-02-09 02:51 --- Hi Richard, Ok, I'll buy the argument that commons-logging should be viewed as an API to wrap use but not configuration of the underlying concrete log library In this case, things are a bit more confusing because commons-logging *does* implicitly manage log4j's initialisation: when the first log4j Log instance is instantiated (via the appropriate commons-logging wrapper class), this triggers log4j to scan for a config file, load it, and initialise itself. And as loggers are often created as static members of classes, it is rather tricky to ensure that app-specific log initialisation code has been run before the first commons-logging Log object triggers log4j's default initialisation. Sorry if a solution to that has been raised on the logging email thread that occurred recently; I tried to keep up with that but the volume just got too great.. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r152977 - in jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/actions: AbstractObjectCreationFactory.java AbstractObjectFactory.java CreateObjectWithFactoryAction.java ObjectCreationFactory.java ObjectFactory.java
Author: skitching
Date: Tue Feb 8 18:40:19 2005
New Revision: 152977
URL: http://svn.apache.org/viewcvs?view=revrev=152977
Log:
Major rework.
Added:
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/actions/AbstractObjectFactory.java
- copied, changed from r151291,
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/actions/AbstractObjectCreationFactory.java
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/actions/ObjectFactory.java
- copied, changed from r151291,
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/actions/ObjectCreationFactory.java
Removed:
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/actions/AbstractObjectCreationFactory.java
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/actions/ObjectCreationFactory.java
Modified:
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/actions/CreateObjectWithFactoryAction.java
(contents, props changed)
Copied:
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/actions/AbstractObjectFactory.java
(from r151291,
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/actions/AbstractObjectCreationFactory.java)
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/actions/AbstractObjectFactory.java?view=diffrev=152977p1=jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/actions/AbstractObjectCreationFactory.javar1=151291p2=jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/actions/AbstractObjectFactory.javar2=152977
==
---
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/actions/AbstractObjectCreationFactory.java
(original)
+++
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/actions/AbstractObjectFactory.java
Tue Feb 8 18:40:19 2005
@@ -1,6 +1,6 @@
-/* $Id: $
+/* $Id$
*
- * Copyright 2001-2004 The Apache Software Foundation.
+ * Copyright 2001-2005 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.
@@ -21,22 +21,31 @@
import org.apache.commons.digester2.ParseException;
/**
- * pAbstract base class for codeObjectCreationFactory/code
- * implementations./p
+ * Abstract base class for codeObjectFactory/code implementations.
+ * p
+ * Note that extending this abstract class rather than directly implementing
+ * the ObjectFactory interface provides much better forward compatibility.
+ * Digester minor releases (2.x - 2.y) guarantee not to break any classes that
+ * subclass this abstract class. However no such guarantee exists for classes
+ * that directly implement the ObjectFactory interface.
*/
-abstract public class AbstractObjectCreationFactory implements
ObjectCreationFactory {
-// - Public Methods
+abstract public class AbstractObjectFactory implements ObjectFactory {
/**
* pFactory method called by [EMAIL PROTECTED]
CreateObjectWithFactoryAction} to
- * supply an object based on the element's attributes.
+ * supply an object based./p
*
- * @param attributes the element's attributes
+ * pNote in particular that implementations of this method have the
+ * option of inspecting the element's attributes to determine what kind
+ * of object to create./p
*
- * @throws Exception any exception thrown will be propagated upwards
+ * @param context is the current parsing context.
+ * @param attributes is the current element's set of xml attributes.
+ *
+ * @throws ParseException if a problem of any sort occurs. Any such
+ * exception will terminate parsing.
*/
public abstract Object createObject(Context context, Attributes
attributes)
throws ParseException;
-
}
Modified:
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/actions/CreateObjectWithFactoryAction.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/actions/CreateObjectWithFactoryAction.java?view=diffr1=152976r2=152977
==
---
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/actions/CreateObjectWithFactoryAction.java
(original)
+++
Re: [vfs] intellij idea licences
Henri Yandell wrote: Probably not. Seems like a bit of an anomaly. I imagined it would be rare for somebody to pass Jetbrains' rule of: Some evidence of your engagement in the project and want to use an IDE for that project and not be either a committer, or making a lot of contributions/patches and heading towards a committer vote. JetBrains ok'd me on the basis of multiple projects, I understand. (I tend to contribute here and there rather than concentrating in one area for more than a year.) And I'm a major IDEA bug-filer. :-) Cheers, --binkley - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r152978 - jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/actions/CreateObjectWithFactoryActionTestCase.java
Author: skitching
Date: Tue Feb 8 18:41:12 2005
New Revision: 152978
URL: http://svn.apache.org/viewcvs?view=revrev=152978
Log:
Test cases for CreateObjectWithFactoryAction
Added:
jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/actions/CreateObjectWithFactoryActionTestCase.java
(with props)
Added:
jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/actions/CreateObjectWithFactoryActionTestCase.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/actions/CreateObjectWithFactoryActionTestCase.java?view=autorev=152978
==
---
jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/actions/CreateObjectWithFactoryActionTestCase.java
(added)
+++
jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/actions/CreateObjectWithFactoryActionTestCase.java
Tue Feb 8 18:41:12 2005
@@ -0,0 +1,167 @@
+/* $Id$
+ *
+ * Copyright 2001-2005 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.digester2.actions;
+
+import junit.framework.Test;
+import junit.framework.TestCase;
+import junit.framework.TestSuite;
+
+import java.io.StringReader;
+import java.util.List;
+import java.util.ArrayList;
+
+import org.xml.sax.InputSource;
+
+import org.apache.commons.logging.Log;
+import org.apache.commons.digester2.Digester;
+import org.apache.commons.digester2.Context;
+
+/**
+ * pTest Cases for the CreateObjectWithFactoryAction class./p
+ */
+
+public class CreateObjectWithFactoryActionTestCase extends TestCase {
+
+// ---
+// Local classes
+// ---
+
+public static class CustomRoot {
+public List list = new ArrayList();
+public void addInteger(Integer i) {
+list.add(i);
+}
+}
+
+public static class IntegerFactory extends AbstractObjectFactory {
+public Object createObject(
+Context context,
+org.xml.sax.Attributes attrs) {
+// note that when retrieving attributes from a sax Attributes
+// object, an empty string should be passed to indicate the
+// null namespace. In a DOM node, you must use null. Yay.
+String value = attrs.getValue(, value);
+return new Integer(value);
+}
+}
+
+// ---
+// Constructors
+// ---
+
+/**
+ * Construct a new instance of this test case.
+ *
+ * @param name Name of the test case
+ */
+public CreateObjectWithFactoryActionTestCase(String name) {
+super(name);
+}
+
+// --
+// Overall Test Methods
+// --
+
+/**
+ * Set up instance variables required by this test case.
+ */
+public void setUp() {
+}
+
+/**
+ * Return the tests included in this test suite.
+ */
+public static Test suite() {
+return (new TestSuite(CreateObjectWithFactoryActionTestCase.class));
+}
+
+/**
+ * Tear down instance variables required by this test case.
+ */
+public void tearDown() {
+}
+
+//
+// Individual Test Methods
+//
+
+/**
+ * Test basic operations. Here we provide an already-instantiated
+ * ObjectFactory to the CreateObjectWithFactoryAction.
+ */
+public void testBasicOperations1() throws Exception {
+String inputText =
+root +
+ int value='16'/ +
+ int value='32'/ +
+ int value='64'/ +
+/root;
+
+InputSource source = new InputSource(new StringReader(inputText));
+
+CustomRoot root = new CustomRoot();
+IntegerFactory factory = new IntegerFactory();
+
+Digester d = new Digester();
+d.setInitialObject(root);
+d.addRule(/root/int, new CreateObjectWithFactoryAction(factory));
+
svn commit: r152979 - jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/Context.java
Author: skitching
Date: Tue Feb 8 18:42:39 2005
New Revision: 152979
URL: http://svn.apache.org/viewcvs?view=revrev=152979
Log:
Add methods putInstanceData and getInstanceData, used initially
by the reworked CreateObjectWithFactoryAction.
Modified:
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/Context.java
Modified:
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/Context.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/Context.java?view=diffr1=152978r2=152979
==
---
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/Context.java
(original)
+++
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/Context.java
Tue Feb 8 18:42:39 2005
@@ -18,7 +18,10 @@
package org.apache.commons.digester2;
import java.util.List;
+import java.util.Map;
import java.util.HashMap;
+import java.util.ArrayList;
+import java.util.Iterator;
import java.util.EmptyStackException;
import org.apache.commons.logging.Log;
@@ -40,6 +43,23 @@
public class Context {
// ---
+// Local classes
+// ---
+
+/**
+* See method [EMAIL PROTECTED] #putInstanceData}.
+ */
+private static class InstanceItem {
+public Object key;
+public Map map;
+
+public InstanceItem(Object key, Map map) {
+this.key = key;
+this.map = map;
+}
+}
+
+// ---
// Instance Variables
// ---
@@ -95,6 +115,12 @@
private HashMap stacksByName = new HashMap();
/**
+ * Place where other objects can store any data they like during a parse.
+ * See method [EMAIL PROTECTED] #putInstanceData} for more information.
+ */
+private List instanceData = new ArrayList();
+
+/**
* The parameters stack being utilized by CallMethodAction and
* CallParamAction.
*/
@@ -493,5 +519,68 @@
public void pushParams(Object object) {
params.push(object);
+}
+
+// ---
+// Other public methods
+// ---
+
+/**
+ * Place where an object (typically an Action) can store any data it likes
+ * during a parse. Usually the named stacks facility is the most
+ * appropriate location for action-related data, as using stacks allows
+ * Actions to be re-entrant. However in some cases a stack is not
+ * needed (eg when building a cache of Class objects used by an Action).
+ * If the data is specific to an action instance, then the action instance
+ * itself should be passed as the first parameter. If the data is used by
+ * all action instances of a specific class, then the action's Class object
+ * can be used as the first parameter.
+ *
+ * @param instance is a key to separate data related to this object from
+ * other data stored on this context object.
+ *
+ * @param category identifies the particular item of data being stored,
+ * so that an instance can store multiple data items.
+ *
+ * @param data is the object to be stored for later retrieval.
+ */
+public void putInstanceData(Object instance, String category, Object data)
{
+// Unfortunately, maps use equals to find a matching key rather than
+// identity, so we can't use a standard Map to implement this. As the
+// number of entries here is likely to be very small anyway, we will
+// just use a list-of-maps, and iterate over the list to find the
+// correct entry.
+//
+// Note that if we trusted System.identityHashCode to return a unique
+// string for an instance, then we could use a map. However that method
+// doesn't promise to return a unique string on all platforms.
+
+for(Iterator i = instanceData.iterator(); i.hasNext(); ) {
+InstanceItem item = (InstanceItem) i.next();
+if (item.key == instance) {
+item.map.put(category, data);
+return;
+}
+}
+
+// this instance has never stored data before
+Map map = new HashMap();
+map.put(category, data);
+InstanceItem instanceItem = new InstanceItem(instance, map);
+instanceData.add(instanceItem);
+}
+
+/**
+ * Retrieve a piece of data stored earlier via putInstanceData.
+ */
+public Object getInstanceData(Object instance, String category) {
+for(Iterator i =
[jxpath] Future of JXPath and DOM???
I am using Xalan 2.1.0 for XPath coverage presently -- behind a skinny wrapper API so we can change implementations fairly painlessly. I'd like to use something more recent and was looking at JXPath, but I note that the sources contain TO_DO comments about using Xalan as the backing XPath implementation -- for the DOM case presumably. Is this the plan? If not, what is? If this is the plan, then there is no reason for me to switch from Xalan to JXPath -- as I only care about XPath usage against DOMs (not JDOM, other beans, etc). You may ask why I'm on such an old Xalan or why I'm looking for something other than Xalan -- which are good questions... Essentially, recent versions of Xalan are missing the boat on some important XPath use cases. Xalan 2.1.0 is the last version of Xalan which does not have immense performance penalties for my use cases. Specifically, my use case is: 1. Parse/compile XPath expressions. 2. Use these expressions against many different DOMs. * I /rarely /use a given XPath against the same DOM (without intervening changes) twice. o I /often /use a given XPath against many, many different DOMs. * I /even more rarely /know that when I use an XPath on a DOM it will not be changing prior to it being used again. * I /often /need to use XPath to retrieve a list of DOM nodes to be edited or deleted -- followed by edits directly via DOM APIs and more use of other XPaths ad nauseum (e.g. based on GUI picks). After Xalan 2.1.0, the XPath portion of Xalan was optimized for the antithesis of this use case, i.e. it builds a DTM (document table model) for each DOM an XPath is used against -- which is a tremendous waste of time and memory if the XPath is all but certainly not going to be used against the given DOM (without intervening changes) more than once. I found cases of 500% performance improvement by moving back from more recent Xalan versions to 2.1.0 for these use cases! The Xalan team knows about this issue, but despite the fact that this directly affects the XPath API exposed in Java 1.5 this issue seems unimportant/uninteresting to them as compared to optimizing for the XSLT use case -- where the DTM approach makes sense since the DTM is formed once and acted upon by many XPaths many times. Some time ago I looked at both JXPath and Jaxen as possible replacements for Xalan 2.1.0. Unfortunately, both of these XPath libraries had major issues with evaluating some rather simple XPath expressions at the time -- and I need good fidelity to the XPath standard (at least as good as Xalan 2.1.0). I believe Jaxen is at the same version now as it was when I last tested it, but JXPath has had an update or two since then -- so I was going to try again until I saw the aforementioned TO_DO in the source code. If JXPath is not going to be a long-term contender for the my use cases, then I just have to continue using Xalan 2.1.0 (which I've move to another package using Ant -- similar to what Sun has done in Java 1.5 -- so as not to conflict with any other Xalan versions). So all that said, I'd appreciate any feedback as to: * the intended direction of JXPath, * the level of commitment to the XPath standard, and * the level of commitment to supporting the non-XSLT DOM use case outlined above. -- Jess Holle
Re: [jxpath] Future of JXPath and DOM???
P.S. Also, I must admit this message is somewhat of a test. If no one responds, then I can assume the JXPath community is not active enough to be worth considering over sticking with an old version of Xalan for the forseeable future. Jess Holle wrote: I am using Xalan 2.1.0 for XPath coverage presently -- behind a skinny wrapper API so we can change implementations fairly painlessly. I'd like to use something more recent and was looking at JXPath, but I note that the sources contain TO_DO comments about using Xalan as the backing XPath implementation -- for the DOM case presumably. Is this the plan? If not, what is? If this is the plan, then there is no reason for me to switch from Xalan to JXPath -- as I only care about XPath usage against DOMs (not JDOM, other beans, etc). You may ask why I'm on such an old Xalan or why I'm looking for something other than Xalan -- which are good questions... Essentially, recent versions of Xalan are missing the boat on some important XPath use cases. Xalan 2.1.0 is the last version of Xalan which does not have immense performance penalties for my use cases. Specifically, my use case is: 1. Parse/compile XPath expressions. 2. Use these expressions against many different DOMs. * I /rarely /use a given XPath against the same DOM (without intervening changes) twice. o I /often /use a given XPath against many, many different DOMs. * I /even more rarely /know that when I use an XPath on a DOM it will not be changing prior to it being used again. * I /often /need to use XPath to retrieve a list of DOM nodes to be edited or deleted -- followed by edits directly via DOM APIs and more use of other XPaths ad nauseum (e.g. based on GUI picks). After Xalan 2.1.0, the XPath portion of Xalan was optimized for the antithesis of this use case, i.e. it builds a DTM (document table model) for each DOM an XPath is used against -- which is a tremendous waste of time and memory if the XPath is all but certainly not going to be used against the given DOM (without intervening changes) more than once. I found cases of 500% performance improvement by moving back from more recent Xalan versions to 2.1.0 for these use cases! The Xalan team knows about this issue, but despite the fact that this directly affects the XPath API exposed in Java 1.5 this issue seems unimportant/uninteresting to them as compared to optimizing for the XSLT use case -- where the DTM approach makes sense since the DTM is formed once and acted upon by many XPaths many times. Some time ago I looked at both JXPath and Jaxen as possible replacements for Xalan 2.1.0. Unfortunately, both of these XPath libraries had major issues with evaluating some rather simple XPath expressions at the time -- and I need good fidelity to the XPath standard (at least as good as Xalan 2.1.0). I believe Jaxen is at the same version now as it was when I last tested it, but JXPath has had an update or two since then -- so I was going to try again until I saw the aforementioned TO_DO in the source code. If JXPath is not going to be a long-term contender for the my use cases, then I just have to continue using Xalan 2.1.0 (which I've move to another package using Ant -- similar to what Sun has done in Java 1.5 -- so as not to conflict with any other Xalan versions). So all that said, I'd appreciate any feedback as to: * the intended direction of JXPath, * the level of commitment to the XPath standard, and * the level of commitment to supporting the non-XSLT DOM use case outlined above. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jxpath] Future of JXPath and DOM???
Jess, JXPath has always supported Xalan through JAXP DOM APIs. What you may have seen in the source code of JXPath is some attempts to optimize JXPath when it is used specifically in combination with Xalan. You would not be interested in that optimization, because it would only be applied to static DOM and take advantage of DTM. Try using JXPath and let us know how it works out. - Dmitri Jess Holle [EMAIL PROTECTED] wrote: P.S. Also, I must admit this message is somewhat of a test. If no one responds, then I can assume the JXPath community is not active enough to be worth considering over sticking with an old version of Xalan for the forseeable future. Jess Holle wrote: I am using Xalan 2.1.0 for XPath coverage presently -- behind a skinny wrapper API so we can change implementations fairly painlessly. I'd like to use something more recent and was looking at JXPath, but I note that the sources contain TO_DO comments about using Xalan as the backing XPath implementation -- for the DOM case presumably. Is this the plan? If not, what is? If this is the plan, then there is no reason for me to switch from Xalan to JXPath -- as I only care about XPath usage against DOMs (not JDOM, other beans, etc). You may ask why I'm on such an old Xalan or why I'm looking for something other than Xalan -- which are good questions... Essentially, recent versions of Xalan are missing the boat on some important XPath use cases. Xalan 2.1.0 is the last version of Xalan which does not have immense performance penalties for my use cases. Specifically, my use case is: 1. Parse/compile XPath expressions. 2. Use these expressions against many different DOMs. * I /rarely /use a given XPath against the same DOM (without intervening changes) twice. o I /often /use a given XPath against many, many different DOMs. * I /even more rarely /know that when I use an XPath on a DOM it will not be changing prior to it being used again. * I /often /need to use XPath to retrieve a list of DOM nodes to be edited or deleted -- followed by edits directly via DOM APIs and more use of other XPaths ad nauseum (e.g. based on GUI picks). After Xalan 2.1.0, the XPath portion of Xalan was optimized for the antithesis of this use case, i.e. it builds a DTM (document table model) for each DOM an XPath is used against -- which is a tremendous waste of time and memory if the XPath is all but certainly not going to be used against the given DOM (without intervening changes) more than once. I found cases of 500% performance improvement by moving back from more recent Xalan versions to 2.1.0 for these use cases! The Xalan team knows about this issue, but despite the fact that this directly affects the XPath API exposed in Java 1.5 this issue seems unimportant/uninteresting to them as compared to optimizing for the XSLT use case -- where the DTM approach makes sense since the DTM is formed once and acted upon by many XPaths many times. Some time ago I looked at both JXPath and Jaxen as possible replacements for Xalan 2.1.0. Unfortunately, both of these XPath libraries had major issues with evaluating some rather simple XPath expressions at the time -- and I need good fidelity to the XPath standard (at least as good as Xalan 2.1.0). I believe Jaxen is at the same version now as it was when I last tested it, but JXPath has had an update or two since then -- so I was going to try again until I saw the aforementioned TO_DO in the source code. If JXPath is not going to be a long-term contender for the my use cases, then I just have to continue using Xalan 2.1.0 (which I've move to another package using Ant -- similar to what Sun has done in Java 1.5 -- so as not to conflict with any other Xalan versions). So all that said, I'd appreciate any feedback as to: * the intended direction of JXPath, * the level of commitment to the XPath standard, and * the level of commitment to supporting the non-XSLT DOM use case outlined above. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[GUMP@brutus]: Project commons-id (in module jakarta-commons-sandbox) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-id has an issue affecting its community integration. This issue affects 1 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-id : Commons Identifier Package Full details are available at: http://brutus.apache.org/gump/public/jakarta-commons-sandbox/commons-id/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-id-08022005.jar] identifier set to project name -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/jakarta-commons-sandbox/id/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/jakarta-commons-sandbox/id/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/jakarta-commons-sandbox/id/project.properties -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://brutus.apache.org/gump/public/jakarta-commons-sandbox/commons-id/gump_work/build_jakarta-commons-sandbox_commons-id.html Work Name: build_jakarta-commons-sandbox_commons-id (Type: Build) Work ended in a state of : Failed Elapsed: 3 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/jakarta-commons-sandbox/id] CLASSPATH: /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/discovery/dist/commons-discovery.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar - __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.0.2 org.apache.maven.MavenException: Error reading XML or initializing at org.apache.maven.MavenUtils.getProject(MavenUtils.java:156) at org.apache.maven.MavenUtils.getProject(MavenUtils.java:122) at org.apache.maven.MavenSession.initializeRootProject(MavenSession.java:232) at org.apache.maven.MavenSession.initialize(MavenSession.java:172) at org.apache.maven.cli.App.doMain(App.java:475) at org.apache.maven.cli.App.main(App.java:1239) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at com.werken.forehead.Forehead.run(Forehead.java:551) at com.werken.forehead.Forehead.main(Forehead.java:581) --- Nested Exception --- java.io.FileNotFoundException: Parent POM not found: /home/gump/workspaces2/public/workspace/jakarta-commons-sandbox/sandbox-build/project.xml at org.apache.maven.MavenUtils.getNonJellyProject(MavenUtils.java:230) at org.apache.maven.MavenUtils.getProject(MavenUtils.java:143) at org.apache.maven.MavenUtils.getProject(MavenUtils.java:122) at org.apache.maven.MavenSession.initializeRootProject(MavenSession.java:232) at org.apache.maven.MavenSession.initialize(MavenSession.java:172) at org.apache.maven.cli.App.doMain(App.java:475) at org.apache.maven.cli.App.main(App.java:1239) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at com.werken.forehead.Forehead.run(Forehead.java:551) at com.werken.forehead.Forehead.main(Forehead.java:581) You have encountered an unknown error running Maven. Please help us to
Re: [jxpath] Future of JXPath and DOM???
Jess, Sorry, I misspoke. Of course, what I wanted to say was that JXPath has always supported Xerces, which is the XML parser bundled with Xalan. Thus, it can work side-by-side with Xalan. - Dmitri Dmitri Plotnikov [EMAIL PROTECTED] wrote: Jess, JXPath has always supported Xalan through JAXP DOM APIs. What you may have seen in the source code of JXPath is some attempts to optimize JXPath when it is used specifically in combination with Xalan. You would not be interested in that optimization, because it would only be applied to static DOM and take advantage of DTM. Try using JXPath and let us know how it works out. - Dmitri Jess Holle wrote: P.S. Also, I must admit this message is somewhat of a test. If no one responds, then I can assume the JXPath community is not active enough to be worth considering over sticking with an old version of Xalan for the forseeable future. Jess Holle wrote: I am using Xalan 2.1.0 for XPath coverage presently -- behind a skinny wrapper API so we can change implementations fairly painlessly. I'd like to use something more recent and was looking at JXPath, but I note that the sources contain TO_DO comments about using Xalan as the backing XPath implementation -- for the DOM case presumably. Is this the plan? If not, what is? If this is the plan, then there is no reason for me to switch from Xalan to JXPath -- as I only care about XPath usage against DOMs (not JDOM, other beans, etc). You may ask why I'm on such an old Xalan or why I'm looking for something other than Xalan -- which are good questions... Essentially, recent versions of Xalan are missing the boat on some important XPath use cases. Xalan 2.1.0 is the last version of Xalan which does not have immense performance penalties for my use cases. Specifically, my use case is: 1. Parse/compile XPath expressions. 2. Use these expressions against many different DOMs. * I /rarely /use a given XPath against the same DOM (without intervening changes) twice. o I /often /use a given XPath against many, many different DOMs. * I /even more rarely /know that when I use an XPath on a DOM it will not be changing prior to it being used again. * I /often /need to use XPath to retrieve a list of DOM nodes to be edited or deleted -- followed by edits directly via DOM APIs and more use of other XPaths ad nauseum (e.g. based on GUI picks). After Xalan 2.1.0, the XPath portion of Xalan was optimized for the antithesis of this use case, i.e. it builds a DTM (document table model) for each DOM an XPath is used against -- which is a tremendous waste of time and memory if the XPath is all but certainly not going to be used against the given DOM (without intervening changes) more than once. I found cases of 500% performance improvement by moving back from more recent Xalan versions to 2.1.0 for these use cases! The Xalan team knows about this issue, but despite the fact that this directly affects the XPath API exposed in Java 1.5 this issue seems unimportant/uninteresting to them as compared to optimizing for the XSLT use case -- where the DTM approach makes sense since the DTM is formed once and acted upon by many XPaths many times. Some time ago I looked at both JXPath and Jaxen as possible replacements for Xalan 2.1.0. Unfortunately, both of these XPath libraries had major issues with evaluating some rather simple XPath expressions at the time -- and I need good fidelity to the XPath standard (at least as good as Xalan 2.1.0). I believe Jaxen is at the same version now as it was when I last tested it, but JXPath has had an update or two since then -- so I was going to try again until I saw the aforementioned TO_DO in the source code. If JXPath is not going to be a long-term contender for the my use cases, then I just have to continue using Xalan 2.1.0 (which I've move to another package using Ant -- similar to what Sun has done in Java 1.5 -- so as not to conflict with any other Xalan versions). So all that said, I'd appreciate any feedback as to: * the intended direction of JXPath, * the level of commitment to the XPath standard, and * the level of commitment to supporting the non-XSLT DOM use case outlined above. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[GUMP@brutus]: Project commons-jelly-tags-xml (in module commons-jelly) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-jelly-tags-xml has an issue affecting its community integration. This issue affects 12 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-define : Commons Jelly - commons-jelly-tags-html : Commons Jelly - commons-jelly-tags-http : Commons Jelly - commons-jelly-tags-jaxme : Commons Jelly - commons-jelly-tags-jetty : Commons Jelly - commons-jelly-tags-jface : Commons Jelly - commons-jelly-tags-jsl : Commons Jelly - commons-jelly-tags-swing : Commons Jelly - commons-jelly-tags-xml : Commons Jelly - commons-jelly-tags-xmlunit : Commons Jelly - maven : Project Management Tools - maven-bootstrap : Project Management Tools Full details are available at: http://brutus.apache.org/gump/public/commons-jelly/commons-jelly-tags-xml/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-jelly-tags-xml-08022005.jar] identifier set to project name -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/test-reports -DEBUG- Extracted fallback artifacts from Gump Repository The following work was performed: http://brutus.apache.org/gump/public/commons-jelly/commons-jelly-tags-xml/gump_work/build_commons-jelly_commons-jelly-tags-xml.html Work Name: build_commons-jelly_commons-jelly-tags-xml (Type: Build) Work ended in a state of : Failed Elapsed: 47 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml] CLASSPATH: /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-08022005.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-08022005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-08022005.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-08022005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-08022005.jar - [mkdir] Created dir: /home/gump/workspaces2/public/workspace/commons-jelly/jelly-tags/xml/target/classes java:compile: [echo] Compiling to /home/gump/workspaces2/public/workspace/commons-jelly/jelly-tags/xml/target/classes [echo] == NOTE: Targetting JVM 1.4, classes will not run on earlier JVMs == [javac] Compiling 16 source files to /home/gump/workspaces2/public/workspace/commons-jelly/jelly-tags/xml/target/classes java:jar-resources: test:prepare-filesystem: [mkdir] Created dir: /home/gump/workspaces2/public/workspace/commons-jelly/jelly-tags/xml/target/test-classes [mkdir] Created dir: /home/gump/workspaces2/public/workspace/commons-jelly/jelly-tags/xml/target/test-reports test:test-resources: Copying 36 files to /home/gump/workspaces2/public/workspace/commons-jelly/jelly-tags/xml/target/test-classes
[GUMP@brutus]: Project commons-jelly-tags-ant (in module commons-jelly) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-jelly-tags-ant has an issue affecting its community integration. This issue affects 2 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-ant : Commons Jelly - commons-jelly-tags-fmt : Commons Jelly Full details are available at: http://brutus.apache.org/gump/public/commons-jelly/commons-jelly-tags-ant/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-jelly-tags-ant-08022005.jar] identifier set to project name -ERROR- Multiple outputs defined by project ant; an id attribute is required to select the one you want -ERROR- Unhandled Property: maven.jar.ant-optional on: Maven on Project:commons-jelly-tags-ant -DEBUG- Dependency on ant exists, no need to add for property maven.jar.ant-optional. -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/test-reports -WARNING- No directory [/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/test-reports] -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://brutus.apache.org/gump/public/commons-jelly/commons-jelly-tags-ant/gump_work/build_commons-jelly_commons-jelly-tags-ant.html Work Name: build_commons-jelly_commons-jelly-tags-ant (Type: Build) Work ended in a state of : Failed Elapsed: 5 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant] CLASSPATH: /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-08022005.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-08022005.jar:/usr/local/gump/public/workspace/jakarta-commons-sandbox/grant/target/commons-grant-08022005.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-08022005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-08022005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/util/target/commons-jelly-tags-util-08022005.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-08022005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-08022005.jar - __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.0.2 You are working offline so the build will continue, but commons-jelly-SNAPSHOT.jar may be out of date! The build cannot continue because of the following unsatisfied dependency: ant-optional-1.5.3-1.jar; path override doesn't exist: /home/gump/workspaces2/public/workspace/commons-jelly/jelly-tags/ant/*Unset* Total time: 4 seconds Finished at: Tue Feb 08 21:31:13 PST 2005 - To subscribe to this information via syndicated feeds: - RSS: http://brutus.apache.org/gump/public/commons-jelly/commons-jelly-tags-ant/rss.xml - Atom:
Re: [jxpath] Future of JXPath and DOM???
Hi, I am also looking at the same optimization, but not in a way that Xalan handles the xpath, but in such a way that a metamodel (DOM or your own) can optimize the query implementation itself. I was thinking of having a nodepointer recognizing the model, and having the option to pass the jxpath expression to the actual model implementation. Right now I don't have ideas on the actual implementation, but any ideas from others on the subject are welcome. Any thoughts of such an implementation? Michael Jess, Sorry, I misspoke. Of course, what I wanted to say was that JXPath has always supported Xerces, which is the XML parser bundled with Xalan. Thus, it can work side-by-side with Xalan. - Dmitri Dmitri Plotnikov [EMAIL PROTECTED] wrote: Jess, JXPath has always supported Xalan through JAXP DOM APIs. What you may have seen in the source code of JXPath is some attempts to optimize JXPath when it is used specifically in combination with Xalan. You would not be interested in that optimization, because it would only be applied to static DOM and take advantage of DTM. Try using JXPath and let us know how it works out. - Dmitri Jess Holle wrote: P.S. Also, I must admit this message is somewhat of a test. If no one responds, then I can assume the JXPath community is not active enough to be worth considering over sticking with an old version of Xalan for the forseeable future. Jess Holle wrote: I am using Xalan 2.1.0 for XPath coverage presently -- behind a skinny wrapper API so we can change implementations fairly painlessly. I'd like to use something more recent and was looking at JXPath, but I note that the sources contain TO_DO comments about using Xalan as the backing XPath implementation -- for the DOM case presumably. Is this the plan? If not, what is? If this is the plan, then there is no reason for me to switch from Xalan to JXPath -- as I only care about XPath usage against DOMs (not JDOM, other beans, etc). You may ask why I'm on such an old Xalan or why I'm looking for something other than Xalan -- which are good questions... Essentially, recent versions of Xalan are missing the boat on some important XPath use cases. Xalan 2.1.0 is the last version of Xalan which does not have immense performance penalties for my use cases. Specifically, my use case is: 1. Parse/compile XPath expressions. 2. Use these expressions against many different DOMs. * I /rarely /use a given XPath against the same DOM (without intervening changes) twice. o I /often /use a given XPath against many, many different DOMs. * I /even more rarely /know that when I use an XPath on a DOM it will not be changing prior to it being used again. * I /often /need to use XPath to retrieve a list of DOM nodes to be edited or deleted -- followed by edits directly via DOM APIs and more use of other XPaths ad nauseum (e.g. based on GUI picks). After Xalan 2.1.0, the XPath portion of Xalan was optimized for the antithesis of this use case, i.e. it builds a DTM (document table model) for each DOM an XPath is used against -- which is a tremendous waste of time and memory if the XPath is all but certainly not going to be used against the given DOM (without intervening changes) more than once. I found cases of 500% performance improvement by moving back from more recent Xalan versions to 2.1.0 for these use cases! The Xalan team knows about this issue, but despite the fact that this directly affects the XPath API exposed in Java 1.5 this issue seems unimportant/uninteresting to them as compared to optimizing for the XSLT use case -- where the DTM approach makes sense since the DTM is formed once and acted upon by many XPaths many times. Some time ago I looked at both JXPath and Jaxen as possible replacements for Xalan 2.1.0. Unfortunately, both of these XPath libraries had major issues with evaluating some rather simple XPath expressions at the time -- and I need good fidelity to the XPath standard (at least as good as Xalan 2.1.0). I believe Jaxen is at the same version now as it was when I last tested it, but JXPath has had an update or two since then -- so I was going to try again until I saw the aforementioned TO_DO in the source code. If JXPath is not going to be a long-term contender for the my use cases, then I just have to continue using Xalan 2.1.0 (which I've move to another package using Ant -- similar to what Sun has done in Java 1.5 -- so as not to conflict with any other Xalan versions). So all that said, I'd appreciate any feedback as to: * the intended direction of JXPath, * the level of commitment to the XPath standard, and * the level of commitment to supporting the non-XSLT DOM use case outlined above. -- Jess Holle - To unsubscribe,
svn commit: r153033 - in jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2: Context.java SAXHandler.java
Author: skitching
Date: Tue Feb 8 23:24:49 2005
New Revision: 153033
URL: http://svn.apache.org/viewcvs?view=revrev=153033
Log:
Move several variables that evolve during a parse from the SAXHandler to
the Context class. In most cases, the related methods that modify them
have been moved too. In particular, the following have been moved:
* documentLocator
* contentHandler
* bodyText/bodyTexts
* namespaces
Modified:
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/Context.java
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/SAXHandler.java
Modified:
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/Context.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/Context.java?view=diffr1=153032r2=153033
==
---
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/Context.java
(original)
+++
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/Context.java
Tue Feb 8 23:24:49 2005
@@ -23,6 +23,12 @@
import java.util.ArrayList;
import java.util.Iterator;
import java.util.EmptyStackException;
+import java.lang.reflect.InvocationTargetException;
+
+import org.xml.sax.Locator;
+import org.xml.sax.ContentHandler;
+import org.xml.sax.SAXException;
+import org.xml.sax.SAXParseException;
import org.apache.commons.logging.Log;
@@ -76,6 +82,53 @@
private Log log;
/**
+ * The Locator associated with our parser object. This object can be
+ * consulted to find out which line of the input xml document we are
+ * currently on - very useful when generating error messages.
+ */
+private Locator documentLocator = null;
+
+/**
+ * Registered namespaces we are currently processing. The key is the
+ * namespace prefix that was declared in the document. The value is an
+ * ArrayStack of the namespace URIs this prefix has been mapped to --
+ * the top Stack element is the most current one. (This architecture
+ * is required because documents can declare nested uses of the same
+ * prefix for different Namespace URIs).
+ * p
+ * TODO: move this data to the Context.
+ */
+private HashMap namespaces = new HashMap();
+
+/**
+ * If not null, then calls to the saxHandler's characters, startElement,
+ * endElement and processingInstruction methods are forwarded to the
+ * specified object. This is intended to allow rules to temporarily
+ * take control of the sax events. In particular, this is used by
+ * NodeCreateAction.
+ */
+private ContentHandler contentHandler = null;
+
+/**
+ * The body text of the current element. As the parser reports chunks
+ * of text associated with the current element, they are appended here.
+ * When the end of the element is reported, the full text content of the
+ * current element should be here. Note that if the element has mixed
+ * content, ie text intermingled with child elements, then this buffer
+ * ends up with all the different text pieces appended to form one string.
+ */
+private StringBuffer bodyText = new StringBuffer();
+
+/**
+ * When processing an element with mixed content (ie text and child
+ * elements), then when we start a child element we need to store the
+ * current text seen so far, and restore it after we have finished
+ * with the child element. This stack therefore contains StringBuffer
+ * items containing the body text of interrupted xml elements.
+ */
+private ArrayStack bodyTexts = new ArrayStack();
+
+/**
* Stack whose elements are List objects, each containing a list of
* Action objects as returned from RuleManager.getMatchingActions().
* As each xml element in the input is entered, the list of matching
@@ -133,9 +186,10 @@
/**
* Construct a new Context.
*/
-public Context(SAXHandler saxHandler, Log log) {
+public Context(SAXHandler saxHandler, Log log, Locator locator) {
this.saxHandler = saxHandler;
this.log = log;
+this.documentLocator = locator;
}
// ---
@@ -150,6 +204,111 @@
}
/**
+ * Gets the document locator associated with our parser. This object
+ * can be consulted to find out which line of the input xml document
+ * we are currently on - very useful when generating error messages.
+ *
+ * @return the Locator supplied by the document parser
+ */
+public Locator getDocumentLocator() {
+return documentLocator;
+}
+
+/**
+ * Return the currently mapped namespace URI for the specified prefix,
+ * if any; otherwise return
svn commit: r153034 - jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/factory/ActionFactory.java
Author: skitching
Date: Tue Feb 8 23:32:50 2005
New Revision: 153034
URL: http://svn.apache.org/viewcvs?view=revrev=153034
Log:
Minor change due to constructor change for CreateObjectAction
Modified:
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/factory/ActionFactory.java
Modified:
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/factory/ActionFactory.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/factory/ActionFactory.java?view=diffr1=153033r2=153034
==
---
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/factory/ActionFactory.java
(original)
+++
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/factory/ActionFactory.java
Tue Feb 8 23:32:50 2005
@@ -131,18 +131,19 @@
* Add a create object rule for the specified parameters.
*
* @param pattern Element matching pattern
- * @param attributeName Attribute name that optionally overrides
* @param clazz Default Java class to be created
+ * @param attributeName Attribute name that optionally overrides
* the default Java class name to be created
+ *
* @see CreateObjectAction
*/
public void addCreateObject(
String pattern,
-String attributeName,
-Class clazz)
+Class clazz,
+String attributeName)
throws InvalidRuleException {
addRule(pattern,
-new CreateObjectAction(attributeName, clazz));
+new CreateObjectAction(clazz, attributeName));
}
/**
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r153035 - jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/actions/CreateNodeAction.java
Author: skitching
Date: Tue Feb 8 23:34:03 2005
New Revision: 153035
URL: http://svn.apache.org/viewcvs?view=revrev=153035
Log:
Minor changes due to setContentHandler method now being defined on
the Context class, not the saxHandler class.
Modified:
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/actions/CreateNodeAction.java
Modified:
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/actions/CreateNodeAction.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/actions/CreateNodeAction.java?view=diffr1=153034r2=153035
==
---
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/actions/CreateNodeAction.java
(original)
+++
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/actions/CreateNodeAction.java
Tue Feb 8 23:34:03 2005
@@ -148,8 +148,8 @@
* of SAX events.
*
* @param context is the object which holds the current parse context.
- * More importantly here, it provides a way to access the current
- * saxHandler object which receives sax events from the xml parser.
+ * It also provides a way to access the current saxHandler object
+ * which receives sax events from the xml parser.
*/
public NodeBuilder(Context context) throws SAXException {
this.context = context;
@@ -164,7 +164,7 @@
*/
public void init(String namespaceURI, String name, Attributes
attributes) {
saxHandler = context.getSAXHandler();
-oldContentHandler = saxHandler.getContentHandler();
+oldContentHandler = context.getContentHandler();
// Access the documentBuilder in the enclosing class to build a
// Document object that we just use as a factory for creating
@@ -205,7 +205,7 @@
// Tell the SAXHandler to forward events it receives from the
// sax parser to the methods on this object
-saxHandler.setContentHandler(this);
+context.setContentHandler(this);
}
// -
@@ -308,7 +308,7 @@
try {
if (depth == 0) {
// Restore sax event handler.
-saxHandler.setContentHandler(oldContentHandler);
+context.setContentHandler(oldContentHandler);
// push built node onto stack so that other actions can
// access it. Note that this node gets popped in the
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
