svn commit: r151707 - jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/actions/SetPropertiesAction.java
Author: skitching
Date: Mon Feb 7 00:02:30 2005
New Revision: 151707
URL: http://svn.apache.org/viewcvs?view=revrev=151707
Log:
Major rework.
Modified:
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/actions/SetPropertiesAction.java
(contents, props changed)
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=151706r2=151707
==
---
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
Mon Feb 7 00:02:30 2005
@@ -1,24 +1,25 @@
-/* $Id: $
+/* $Id$
+ *
+ * Copyright 2001-2005 The Apache Software Foundation.
*
- * Copyright 2001-2004 The Apache Software Foundation.
- *
* Licensed under the Apache License, Version 2.0 (the License);
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
- *
+ *
* http://www.apache.org/licenses/LICENSE-2.0
- *
+ *
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an AS IS BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
- */
+ */
package org.apache.commons.digester2.actions;
import org.xml.sax.Attributes;
+import java.util.Map;
import java.util.HashMap;
import org.apache.commons.beanutils.BeanUtils;
@@ -28,77 +29,121 @@
import org.apache.commons.digester2.AbstractAction;
import org.apache.commons.digester2.ParseException;
-
-
/**
- * pRule implementation that sets properties on the object at the top of the
+ * pAn Action that sets properties on the object at the top of the
* stack, based on attributes with corresponding names./p
*
- * pThis rule supports custom mapping of attribute names to property names.
- * The default mapping for particular attributes can be overridden by using
+ * pBy default, any xml attribute xyz='value' causes a call to
property-setter
+ * method setXyz(value) on the top object on the stack. If the target method
+ * does not take a String parameter, then the BeanUtils library attempts
+ * to convert the String value of the xml attribute to the required type./p
+ *
+ * pCustom mapping of attribute names to property names can also be done.
+ * The default mapping for particular attributes can be overridden by using
* [EMAIL PROTECTED] #ActionSetProperties(String[] attributeNames, String[]
propertyNames)}.
* This allows attributes to be mapped to properties with different names.
- * Certain attributes can also be marked to be ignored./p
+ * Certain attributes can also be marked to be ignored, by specifying the
+ * target property to be null./p
+ *
+ * pXML Attributes that are not in the default namespace are ignored./p
*/
public class SetPropertiesAction extends AbstractAction {
-// --- Constructors
+private HashMap customMap = null;
+
+// ---
+// Constructors
+// ---
/**
* Base constructor.
*/
public SetPropertiesAction() {
-// nothing to set up
+// nothing to set up
}
-
-/**
- * pConvenience constructor overrides the mapping for just one
property./p
+
+/**
+ * pConstructor which allows the default attribute-property mapping to
+ * be overriden./p
+ *
+ * pThe keys of the map are xml attribute names, and the associated
values
+ * are the java property name to map that attribute to. If the value
+ * associated with an attribute name is null then the attibute will be
+ * ignored./p
+ *
+ * h5Example/h5
+ * p The following constructs a rule that maps the codeclass/code
+ * attribute to the codeclassName/code property. The attribute
+ * codeignore/code is not mapped, and will therefore be ignored rather
+ * than be passed to a setIgnore method (the default behaviour). All other
+ * attributes are mapped as usual using exact name matching.
+ * codepre
+ * HashMap map = new HashMap();
+ * map.put(class, className);
+ * map.put(ignore, null);
+ * SetPropertiesAction(map);
+ * /pre/code/p
+ *
+ * pSee also [EMAIL PROTECTED] #addAlias} which allows the custom
mapping to be
+ * modified after the
svn commit: r151708 - jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/DigesterTestCase.java
Author: skitching
Date: Mon Feb 7 00:04:15 2005
New Revision: 151708
URL: http://svn.apache.org/viewcvs?view=revrev=151708
Log:
Add test for setInitialObject.
Change assertEquals to assertSame where appropriate.
Modified:
jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/DigesterTestCase.java
Modified:
jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/DigesterTestCase.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/DigesterTestCase.java?view=diffr1=151707r2=151708
==
---
jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/DigesterTestCase.java
(original)
+++
jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/DigesterTestCase.java
Mon Feb 7 00:04:15 2005
@@ -125,7 +125,7 @@
SAXHandler h = new SAXHandler();
Digester d = new Digester(h);
-assertEquals(Constructor with SAXHandler, d.getSAXHandler(), h);
+assertSame(Constructor with SAXHandler, d.getSAXHandler(), h);
}
/**
@@ -285,6 +285,26 @@
// TODO: add tests for various parse methods
+/**
+ * Test that setInitialObject works.
+ */
+public void testInitialObject() throws Exception {
+// TODO: verify that Action classes see the initial object as
+// the root object on the stack...
+
+String inputText = root/;
+InputSource source = new InputSource(new StringReader(inputText));
+
+Object initial = new Object();
+
+// Create the digester
+Digester d = new Digester();
+d.setInitialObject(initial);
+d.parse(source);
+
+assertSame(Initial object is root, initial, d.getRoot());
+}
+
// TODO: add test for setInitialObject and getRoot
/**
@@ -298,7 +318,7 @@
// check we can set and get a custom error handler
assertNull(Initial error handler is null, d.getErrorHandler());
d.setErrorHandler(defaultHandler);
-assertEquals(Set/get error handler failed,
+assertSame(Set/get error handler failed,
defaultHandler, d.getErrorHandler());
d.setErrorHandler(null);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r151712 - jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/actions
Author: skitching Date: Mon Feb 7 00:23:29 2005 New Revision: 151712 URL: http://svn.apache.org/viewcvs?view=revrev=151712 Log: holds test cases for concrete Action subclasses Added: jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/actions/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r151713 - jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/actions/SetPropertiesActionTestCase.java
Author: skitching
Date: Mon Feb 7 00:24:03 2005
New Revision: 151713
URL: http://svn.apache.org/viewcvs?view=revrev=151713
Log:
Test cases for SetPropertiesAction
Added:
jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/actions/SetPropertiesActionTestCase.java
(with props)
Added:
jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/actions/SetPropertiesActionTestCase.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/actions/SetPropertiesActionTestCase.java?view=autorev=151713
==
---
jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/actions/SetPropertiesActionTestCase.java
(added)
+++
jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/actions/SetPropertiesActionTestCase.java
Mon Feb 7 00:24:03 2005
@@ -0,0 +1,208 @@
+/* $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.HashMap;
+
+import org.xml.sax.InputSource;
+
+import org.apache.commons.logging.Log;
+import org.apache.commons.digester2.Digester;
+
+/**
+ * pTest Cases for the SetPropertiesActionTestCase class./p
+ */
+
+public class SetPropertiesActionTestCase extends TestCase {
+
+// TODO: file bug on BeanUtils re unable to call BeanUtils.populate
+// on a class declared within a function.
+public static class TestObject {
+private String name;
+private int i;
+private float f;
+private String firstCode;
+private String secondCode;
+
+public void setName(String name) { this.name = name; }
+public void setInt(int i) { this.i = i; }
+public void setFloat(float f) { this.f = f; }
+public void setFirstCode(String s) { firstCode = s; }
+public void setSecondCode(String s) { secondCode = s; }
+
+public String getName() { return name; }
+public int getInt() { return i; }
+public float getFloat() { return f; }
+public String getFirstCode() { return firstCode; }
+public String getSecondCode() { return secondCode; }
+}
+
+// ---
+// Constructors
+// ---
+
+/**
+ * Construct a new instance of this test case.
+ *
+ * @param name Name of the test case
+ */
+public SetPropertiesActionTestCase(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(SetPropertiesActionTestCase.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 +
+ name='a' + // plain string-string mapping
+ int='1' + // string-int mapping
+ firstCode='first' +// camelCase attribute
+ second-code='second' + // auto-hyphenation-conversion
+ noProperty='xxx' + // attribute with no equivalent property
+/;
+
+InputSource source = new InputSource(new StringReader(inputText));
+
+Digester d = new Digester();
+TestObject testObject = new TestObject();
+
+SetPropertiesAction action = new SetPropertiesAction();
+d.addRule(/root, action);
+d.setInitialObject(testObject);
+
svn commit: r151714 - in jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2: SAXHandler.java actions/CallParamAction.java
Author: skitching Date: Mon Feb 7 00:34:04 2005 New Revision: 151714 URL: http://svn.apache.org/viewcvs?view=revrev=151714 Log: Remove dependency on collections.ArrayStack in favour of digester2.ArrayStack Modified: jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/SAXHandler.java jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/actions/CallParamAction.java Modified: jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/SAXHandler.java URL: http://svn.apache.org/viewcvs/jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/SAXHandler.java?view=diffr1=151713r2=151714 == --- jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/SAXHandler.java (original) +++ jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/SAXHandler.java Mon Feb 7 00:34:04 2005 @@ -39,7 +39,6 @@ import org.apache.commons.logging.Log; import org.apache.commons.logging.LogFactory; -import org.apache.commons.collections.ArrayStack; import org.xml.sax.Attributes; import org.xml.sax.InputSource; Modified: jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/actions/CallParamAction.java URL: http://svn.apache.org/viewcvs/jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/actions/CallParamAction.java?view=diffr1=151713r2=151714 == --- jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/actions/CallParamAction.java (original) +++ jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/actions/CallParamAction.java Mon Feb 7 00:34:04 2005 @@ -20,7 +20,7 @@ import org.xml.sax.Attributes; -import org.apache.commons.collections.ArrayStack; +import org.apache.commons.digester2.ArrayStack; import org.apache.commons.logging.Log; import org.apache.commons.digester2.Context; - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vfs] proposal: MemoryFS
B. K. Oxley (binkley) wrote: This is the sort of tree I was asking about (below) to represent the memory file system. I am on vacation this week. I will have a look at this an your sources afterwards. --- Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r151718 - in jakarta/commons/proper/digester/branches/digester2: maven.xml project.xml
Author: skitching
Date: Mon Feb 7 00:55:54 2005
New Revision: 151718
URL: http://svn.apache.org/viewcvs?view=revrev=151718
Log:
Update from 1.x stuff to 2.x stuff
Modified:
jakarta/commons/proper/digester/branches/digester2/maven.xml
jakarta/commons/proper/digester/branches/digester2/project.xml
Modified: jakarta/commons/proper/digester/branches/digester2/maven.xml
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/digester/branches/digester2/maven.xml?view=diffr1=151717r2=151718
==
--- jakarta/commons/proper/digester/branches/digester2/maven.xml (original)
+++ jakarta/commons/proper/digester/branches/digester2/maven.xml Mon Feb 7
00:55:54 2005
@@ -1,5 +1,5 @@
!--
- 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.
@@ -24,7 +24,6 @@
copy todir=${basedir}/target/docs/style/ failonerror=false
fileset dir=${basedir}/../commons-build/xdocs/style
include name='**/*'/
- exclude name='**/CVS/**'/
/fileset
/copy
/postGoal
Modified: jakarta/commons/proper/digester/branches/digester2/project.xml
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/digester/branches/digester2/project.xml?view=diffr1=151717r2=151718
==
--- jakarta/commons/proper/digester/branches/digester2/project.xml (original)
+++ jakarta/commons/proper/digester/branches/digester2/project.xml Mon Feb 7
00:55:54 2005
@@ -1,6 +1,6 @@
?xml version=1.0 encoding=UTF-8?
!--
- 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.
@@ -19,10 +19,14 @@
idcommons-digester/id
inceptionYear2001/inceptionYear
- currentVersion1.6/currentVersion
+ currentVersion2.0-alpha/currentVersion
nameDigester/name
shortDescriptionRule based XML-Java object mapping
module/shortDescription
- descriptionThe Digester package lets you configure an XML-Java object
mapping module which triggers certain actions called rules whenever a
particular pattern of nested XML elements is recognized./description
+ description
+The Digester package lets you configure an XML-Java object mapping module
+which triggers certain actions called rules whenever a particular pattern
+of nested XML elements is recognized.
+ /description
logo/images/logo.png/logo
urlhttp://jakarta.apache.org/commons/${pom.artifactId.substring(8)}//url
@@ -71,44 +75,8 @@
versions
version
- id1.5/id
- name1.5/name
- tagDIGESTER_1_5/tag
-/version
-version
- id1.4.1/id
- name1.4.1/name
- tagDIGESTER_1_4_1/tag
-/version
-version
- id1.4/id
- name1.4/name
- tagDIGESTER_1_4/tag
-/version
-version
- id1.3/id
- name1.3/name
- tagDIGESTER_1_3/tag
-/version
-version
- id1.2/id
- name1.2/name
- tagDIGESTER_1_2/tag
-/version
-version
- id1.1.1/id
- name1.1.1/name
- tagDIGESTER_1_1_1/tag
-/version
-version
- id1.1/id
- name1.1/name
- tagDIGESTER_1_1/tag
-/version
-version
- id1.0/id
- name1.0/name
- tagDIGESTER_1_0/tag
+ id2.0/id
+ name2.0/name
/version
/versions
@@ -202,16 +170,12 @@
dependencies
dependency
idcommons-beanutils/id
- version1.6/version
+ version1.7.0/version
/dependency
dependency
idcommons-logging/id
version1.0/version
/dependency
-dependency
- idcommons-collections/id
- version2.1/version
-/dependency
dependency
idxml-apis/id
version1.0.b2/version
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[GUMP@brutus]: Project commons-email (in module jakarta-commons) 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-email has an issue affecting its community integration. This issue affects 8 projects, and has been outstanding for 5 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-email : Commons Email Package - fulcrum-intake : Services Framework - fulcrum-security-adapter-turbine : Services Framework - fulcrum-template : Services Framework - jakarta-jetspeed : Enterprise Information Portal - jakarta-turbine-2 : A servlet based framework. - jakarta-turbine-3 : A servlet based framework. - scarab : Issue Tracking Built for the Ages Full details are available at: http://brutus.apache.org/gump/public/jakarta-commons/commons-email/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-email-07022005.jar] identifier set to project name -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/jakarta-commons/email/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/jakarta-commons/email/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/jakarta-commons/email/project.properties -DEBUG- Extracted fallback artifacts from Gump Repository The following work was performed: http://brutus.apache.org/gump/public/jakarta-commons/commons-email/gump_work/build_jakarta-commons_commons-email.html Work Name: build_jakarta-commons_commons-email (Type: Build) Work ended in a state of : Failed Elapsed: 9 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/jakarta-commons/email] CLASSPATH: /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/target/classes:/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/lang/dist/commons-lang-07022005.jar:/usr/local/gump/public/workspace/dumbster/build/dumbster.jar:/usr/local/gump/packages/javamail-1.3.2/mail.jar:/usr/local/gump/packages/javamail-1.3.2/lib/mailapi.jar:/usr/local/gump/packages/jaf-1.0.1/activation.jar - java:prepare-filesystem: [mkdir] Created dir: /home/gump/workspaces2/public/workspace/jakarta-commons/email/target/classes java:compile: [echo] Compiling to /home/gump/workspaces2/public/workspace/jakarta-commons/email/target/classes [echo] == NOTE: Targetting JVM 1.4, classes will not run on earlier JVMs == [javac] Compiling 8 source files to /home/gump/workspaces2/public/workspace/jakarta-commons/email/target/classes java:jar-resources: Copying 1 file to /home/gump/workspaces2/public/workspace/jakarta-commons/email/target/classes test:prepare-filesystem: [mkdir] Created dir: /home/gump/workspaces2/public/workspace/jakarta-commons/email/target/test-classes [mkdir] Created dir: /home/gump/workspaces2/public/workspace/jakarta-commons/email/target/test-reports test:test-resources: test:compile: [javac] Compiling 13 source files to /home/gump/workspaces2/public/workspace/jakarta-commons/email/target/test-classes /home/gump/workspaces2/public/workspace/jakarta-commons/email/src/test/org/apache/commons/mail/BaseEmailTestCase.java:110: isStopped() has private access in com.dumbster.smtp.SimpleSmtpServer if (this.fakeMailServer != null !this.fakeMailServer.isStopped()) ^ /home/gump/workspaces2/public/workspace/jakarta-commons/email/src/test/org/apache/commons/mail/BaseEmailTestCase.java:160: isStopped() has private access in com.dumbster.smtp.SimpleSmtpServer if (this.fakeMailServer == null || this.fakeMailServer.isStopped()) ^
[GUMP@brutus]: Project commons-logging (in module jakarta-commons) 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-logging has an issue affecting its community integration. This issue affects 301 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - addressing : WS-FX Project - ant-embed-optional : Java based build tool - ant-xdocs-proposal : Java based build tool - apache-ldapber-provider : Apache Directory Project - apacheds-protocol : Apache Directory Server - apollo : Apollo Project - apseda : An internet protocol server framework - asn1-ber : Apache ASN.1 Tools - authx-sandbox : Apache Authentication and Authorization Framework - avalon-activation-impl : Avalon SVN - avalon-central-site : Avalon SVN - avalon-composition-impl : Avalon SVN - avalon-finder-test : Avalon SVN - avalon-http-context : Avalon SVN - avalon-http-demo : Avalon SVN - avalon-http-examples : Avalon SVN - avalon-http-impl : Avalon SVN - avalon-http-server : Avalon SVN - avalon-http-servlet : Avalon SVN - avalon-http-static : Avalon SVN - avalon-http-test : Avalon SVN - avalon-jms-api : Avalon SVN - avalon-jms-impl : Avalon SVN - avalon-jms-test : Avalon SVN - avalon-jmx-mx4j : Avalon SVN - avalon-jmx-spi : Avalon SVN - avalon-jmx-test : Avalon SVN - avalon-jmx-util : Avalon SVN - avalon-logging-test : Avalon SVN - avalon-merlin-cli : Avalon SVN - avalon-merlin-impl : Avalon SVN - avalon-merlin-unit : Avalon SVN - avalon-planet-facilities : Avalon SVN - avalon-repository-cli : Avalon SVN - avalon-repository-test : Avalon SVN - avalon-runtime : Avalon SVN - avalon-tutorial-hello : Avalon SVN - avalon-tutorial-main : Avalon SVN - avalon-tutorial-webserver : Avalon SVN - beepcore : BEEP is a new Internet standards-track protocol - castor : Java to XML, SQL, LDAP bindings - checkstyle : Java style checker - checkstyle-test : Java style checker - cocoon : Java XML Framework - cocoon-block-apples : Java XML Framework - cocoon-block-asciiart : Java XML Framework - cocoon-block-authentication-fw : Java XML Framework - cocoon-block-axis : Java XML Framework - cocoon-block-batik : Java XML Framework - cocoon-block-bsf : Java XML Framework - cocoon-block-chaperon : Java XML Framework - cocoon-block-cron : Java XML Framework - cocoon-block-databases : Java XML Framework - cocoon-block-deli : Java XML Framework - cocoon-block-eventcache : Java XML Framework - cocoon-block-faces : Java XML Framework - cocoon-block-fop : Java XML Framework - cocoon-block-forms : Java XML Framework - cocoon-block-hsqldb : Java XML Framework - cocoon-block-html : Java XML Framework - cocoon-block-itext : Java XML Framework - cocoon-block-javaflow : Java XML Framework - cocoon-block-jfor : Java XML Framework - cocoon-block-jms : Java XML Framework - cocoon-block-jsp : Java XML Framework - cocoon-block-linkrewriter : Java XML Framework - cocoon-block-linotype : Java XML Framework - cocoon-block-lucene : Java XML Framework - cocoon-block-mail : Java XML Framework - cocoon-block-midi : Java XML Framework - cocoon-block-naming : Java XML Framework - cocoon-block-ojb : Java XML Framework - cocoon-block-paranoid : Java XML Framework - cocoon-block-petstore : Java XML Framework - cocoon-block-poi : Java XML Framework - cocoon-block-portal : Java XML Framework - cocoon-block-profiler : Java XML Framework - cocoon-block-proxy : Java XML Framework - cocoon-block-python : Java XML Framework - cocoon-block-qdox : Java XML Framework - cocoon-block-querybean : Java XML Framework - cocoon-block-repository : Java XML Framework - cocoon-block-scratchpad : Java XML Framework - cocoon-block-serializers : Java XML Framework - cocoon-block-session-fw : Java XML Framework - cocoon-block-slide : Java XML Framework - cocoon-block-slop : Java XML Framework - cocoon-block-stx : Java XML Framework - cocoon-block-taglib : Java XML Framework - cocoon-block-template : Java XML Framework - cocoon-block-tour : Java XML Framework - cocoon-block-velocity : Java XML Framework - cocoon-block-web3 : Java XML Framework - cocoon-block-webdav : Java XML Framework - cocoon-block-xmldb : Java XML Framework - cocoon-block-xsp : Java XML Framework - commons-beanutils : Bean Utilities (Core) - commons-beanutils-bean-collections : Bean Utilities (Bean Collections) - commons-beanutils-core : Jakarta commons -
Re: Javadoc formatting style
Or (c) /** * This is the first paragraph. * * pAnd this is the second./p */ and (d) /** * This is the first paragraph.br * br * And this is the second. */ I tend to use the (c) style, because most of the time the documentation consists in only one paragraph and I don't like to overload the doc with p/p. Emmanuel Bourg Simon Kitching wrote: Hi All, I have seen two basic approaches to applying formatting to javadoc text in source files: (a) XHTML-style /** *pThis is the first paragraph./p * *pAnd this is the second./p */ (b) HTML-style /** * This is the first paragraph. * p * And this is the second. */ I would certainly like to pick one or the other for Digester2. What conventions have other commons projects adopted? Are there any good reasons to pick one over the other? Thanks, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: [i18n] proposals
Hi Woody, you pass over your code to me directly using my apache email address. See comments inline... Cheers, Daniel -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Anaximandro (Woody) Gesendet: Montag, 7. Februar 2005 06:12 An: Jakarta Commons Developers List Betreff: Re: [i18n] proposals Hi Daniel, The ConfigManager in my idea is used for store specific configurations, as I see the MessageManager don't have this responsabilitie. If I store any configuration on MessageManager I will need specific instances of this guy for each thread with a diferent configuration. Well, in your code you don't let the user of this component to configure the behaviours of log, exceptions and default language. I do some code to do this in mine and, becouse this, I need to store these configurations on a isolated place. Store these guys inside MessageManager is not a good idea. The MessageManager only store the message providers and delegate calls to these providers. The main objective behind this is to write less code in cases wich I need to specify Locales differents than default Locale. Instead of write: Locale userLocale = getUserLocale( userId ); LocalizedText txt1 = new LocalizedText( consts.ID1, userLocale );// each message need to set the user locale LocalizedText txt2 = new LocalizedText( consts.ID2, userLocale );// LocalizedText txtN = new LocalizedText( consts.IDN, userLocale ); // The locale is not specified in the constructor. It is specified when you retrieve a particular entry: LocalizedText txt1 = new LocalizedText( consts.ID1 ); String translatedText = txt1.getText(Locale.DE); The default locale should only be used when no user locale can be detected. It might be a good idea to remove the methods dealing with the default locale in order to avoid confusion. I think in write: String servletID= getServletUUID(); ConfigManager config = new ConfigManager.getInstance( servletID ); config.setLocale( getUserLocale( userId ) ); // Only one place set the user locale LocalizedText txt1 = new LocalizedText( consts.ID1 ); LocalizedText txt2 = new LocalizedText( consts.ID2 ); LocalizedText txtN = new LocalizedText( consts.IDN ); I agree with your idea, keep it simple here is the best thing to do, but how to setup aditional information without a mediator to store? The code in first example can be a problem, he multiply locale information (configuration) in many places where I have a message ... In my code I write: - In LocalizedText, LocalizedMessage, LocalizedError, LocalizedException I change the extensions. Instead of cascating extensios I do direct extensions (LocalizedText extends LocalizedBundle, LocalizedMessage extends LocalizedBundle, LocalizedError extends LocalizedBundle ...) Why? Each extension adds some additional fields / methods. - new class: LocalizedRuntimeException (like your LocalizedException); Good idea. * new class: ConfigManager (LocalizedBundle delegate to this class); - service locator; - code to config excetions and defaults ( useMessageIdAsDeafult(), useEntryIdAsDefault(), if both was false, then, we throw exceptions) - code to config log levels (setLevelLog2Info, setLevelLog2Warning and setLevelLog2Error); - code to setLocale (used by all messages in a given instance); - this class delegate calls to MessageManager; Let me have a look at your code. Then it may become more clear ;-) * In MessageManager: - service locator; - methods to getProvider, removeProviders and reset/clear MessageManager; - move exception handling to ConfigManager (now it is configurable); - this class delegates class to each provider; * In XMLMessageProvider: - service locator; - move exception handling to ConfigManager; - more 2 xml formats (one file per message - as resource bundle does and a mix); * In ResourceBundleMessageProvider: - service locator; - move exception handling to ConfigManager; - In all classes I do some enhacements with final keyword; I do a lot of code and don't think is a good idea to put them here. How can I provide this to you? Did you have any email to I sent this? (sure, if you wish to see) Man, sorry by my english. Is more easy to me write code than write email ... If I write anything offensive, please, sorry and talk with me. Woody - Original Message - From: Daniel Florey [EMAIL PROTECTED] To: 'Jakarta Commons Developers List' commons-dev@jakarta.apache.org Sent: Saturday, February 05, 2005 5:58 AM Subject: AW: [i18n] status Hi Woody, Where did you post your proposals/patches? I'm very interested in improving the i18n/contract components. If you have any suggestions the best way is to describe the idea behind it so that it can be discussed in the mailing list. You can also post the related patches/files as attachment to a bugzilla entry (enhancement request). Please try
DO NOT REPLY [Bug 33427] New: - 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 Summary: Javadocs on public web site do not match public release Product: Commons Version: unspecified Platform: All URL: http://jakarta.apache.org/commons/configuration/apidocs/ index.html OS/Version: All Status: NEW Severity: trivial Priority: P2 Component: Configuration AssignedTo: commons-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] The value of the javadocs for commons-configuration on the public web site (http://jakarta.apache.org/commons/configuration/apidocs) is greatly diminished by the fact that they do not match the latest public release (1.0, according to iBiblio). In particular, the javadocs reference a MapConfiguration class that is not in the latest released jar (1.0). It is very frustrating to find exactly what you need in the documentation, only to discover that it is not yet in the actual code. It also rattles my already shaky confidence in the quality of the documentation. -- 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] Identify Class Loader Problems
On 2005-01-27 22:52:02, Richard Sitze wrote: Richard, Sorry for not responding earlier. I'be got a question regarding item C. C. Host / Sub - commons-logging.jar#org.apache.commons.logging.Log is loaded/loadable by Host. - A host, such as JUnit, creates and manages an independent Sub ClassLoader - Sub does NOT reference Host as a parent. How is that possible? As far as I know, a child class loader will (by default) inherit the system class loader as a parent, in this case 'Host'. As the set up you describe seems impossible to me, I can't make sense of the rest of your conclusions for item 'C'. What am I missing? - Sub is set as the thread context ClassLoader. - Execution is within code belonging to Host. Problems: 1. The discovery process may *fail* altogether as it starts with the thread context class loader, and cannot reach the Host loader. 2. The discovery process allows a Log implementation defined by the Sub to be discovered by the Host, as the host executes Host[LogFactory], via the thread context class loader. Consider the case where the *Sub* defines commons-logging.properties or META-INF/Services/org.apache.commons.logging.Log. -- 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]
Re: VOTE: FeedParser move to Commons Proper...
On Mon, 2005-02-07 at 01:37, Kevin A. Burton wrote: robert burrell donkin wrote: +1 OK... great. Thanks guys. So does this mean I'm a go? I've had more than 3 +1s and no -1s . i find it best to put a time limit on a vote at the start (so that everyone knows when it's finished). i'd go ahead an post a [RESULT] for the VOTE. if anyone has a problem, they'll just have to -1 the result :) I'd like to move to commons proper soon as I'd ideally like to do a 0.5.0 release prior to my codecon talk on Sat Feb 12th. No pressure though ;) that's up the feedparser team :) it will take a while to get CLAs processed but that's no reason not to migrate the code. Is it possible to migrate the SVN repository so I still have my version information? i believe that you should be able to do a copy. (hopefully any subversion guru's out there will correct me if i'm wrong.) snip 1. that was a bit of an experiment which didn't work out as well as was hoped. having all the components on one list encourages a sense of community and also provides for better oversight. And a bit of noise I'm afraid. Brad already has problems keeping on the list. I can just suggest to filter on [feedparser] in the subject line though. +1 filters have proved very effective. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Identify Class Loader Problems
On Mon, 2005-02-07 at 17:17, Ceki Gülcü wrote: On 2005-01-27 22:52:02, Richard Sitze wrote: Richard, Sorry for not responding earlier. I'be got a question regarding item C. C. Host / Sub - commons-logging.jar#org.apache.commons.logging.Log is loaded/loadable by Host. - A host, such as JUnit, creates and manages an independent Sub ClassLoader - Sub does NOT reference Host as a parent. How is that possible? As far as I know, a child class loader will (by default) inherit the system class loader as a parent, in this case 'Host'. i believe richard is talking about the case where both the host and the sub inherit (directly or indirectly) from the system classloader but where the sub does not inherit from the host. As the set up you describe seems impossible to me, I can't make sense of the rest of your conclusions for item 'C'. What am I missing? i believe that this arrangement happens in some EJB containers and is also used by some tools (for example, byte code enhancers). - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r151734 - in jakarta/commons/sandbox/jci/trunk: TODO project.xml
Author: tcurdt Date: Mon Feb 7 10:09:18 2005 New Revision: 151734 URL: http://svn.apache.org/viewcvs?view=revrev=151734 Log: updated the TODO Modified: jakarta/commons/sandbox/jci/trunk/TODO jakarta/commons/sandbox/jci/trunk/project.xml Modified: jakarta/commons/sandbox/jci/trunk/TODO URL: http://svn.apache.org/viewcvs/jakarta/commons/sandbox/jci/trunk/TODO?view=diffr1=151733r2=151734 == --- jakarta/commons/sandbox/jci/trunk/TODO (original) +++ jakarta/commons/sandbox/jci/trunk/TODO Mon Feb 7 10:09:18 2005 @@ -1,5 +1,6 @@ o integrate just4log into the build system -o use jakarta commons-logging +o proper package names +o subscribing to compiler events o monitor multiple repositories o compiler factory o compiler implementations Modified: jakarta/commons/sandbox/jci/trunk/project.xml URL: http://svn.apache.org/viewcvs/jakarta/commons/sandbox/jci/trunk/project.xml?view=diffr1=151733r2=151734 == --- jakarta/commons/sandbox/jci/trunk/project.xml (original) +++ jakarta/commons/sandbox/jci/trunk/project.xml Mon Feb 7 10:09:18 2005 @@ -1,6 +1,9 @@ ?xml version=1.0 encoding=UTF-8? project + !-- + -- extend../commons-build/sandbox-project.xml/extend + nameCommons JCI/name idcommons-jci/id logo/images/jci-logo-white.png/logo @@ -10,10 +13,8 @@ descriptionCommons JCI (java compiler interface)/description currentVersion0.1-dev/currentVersion - versions - /versions - branches - /branches + versions/versions + branches/branches !-- Note commons package is missing -- packageorg.apache.jci.*/package @@ -29,6 +30,15 @@ /developers + build +sourceDirectorysrc/java/sourceDirectory +unitTestSourceDirectorysrc/test/unitTestSourceDirectory +unitTest + includes +include**/*TestCase.java/include + /includes +/unitTest + /build dependencies - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r151735 - in jakarta/commons/sandbox/javaflow/trunk: ./ src/java/org/apache/commons/javaflow/ src/java/org/apache/commons/javaflow/utils/ src/test/org/apache/commons/javaflow/
Author: tcurdt
Date: Mon Feb 7 10:11:45 2005
New Revision: 151735
URL: http://svn.apache.org/viewcvs?view=revrev=151735
Log:
major API change,
lazy method lookups,
updated the TODO
Added:
jakarta/commons/sandbox/javaflow/trunk/src/java/org/apache/commons/javaflow/MethodLookup.java
Modified:
jakarta/commons/sandbox/javaflow/trunk/TODO
jakarta/commons/sandbox/javaflow/trunk/src/java/org/apache/commons/javaflow/Continuation.java
jakarta/commons/sandbox/javaflow/trunk/src/java/org/apache/commons/javaflow/ContinuationCompilingClassLoader.java
jakarta/commons/sandbox/javaflow/trunk/src/java/org/apache/commons/javaflow/ContinuationContext.java
jakarta/commons/sandbox/javaflow/trunk/src/java/org/apache/commons/javaflow/utils/ReflectionUtils.java
jakarta/commons/sandbox/javaflow/trunk/src/test/org/apache/commons/javaflow/ContinuationClassLoaderTestCase.java
Modified: jakarta/commons/sandbox/javaflow/trunk/TODO
URL:
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/javaflow/trunk/TODO?view=diffr1=151734r2=151735
==
--- jakarta/commons/sandbox/javaflow/trunk/TODO (original)
+++ jakarta/commons/sandbox/javaflow/trunk/TODO Mon Feb 7 10:11:45 2005
@@ -4,8 +4,7 @@
o website
o testcases
o documentation of the rewriting process.
- maybe re-evaluate and talk to the RIFE
- guys about joining forces
+ maybe re-evaluate
o make the Stack class use a hierarchical
approach to support differential continuations
o make the Stack and Continuation classes
@@ -17,6 +16,7 @@
o fix bugs:
o use of suspend in constructors
o inner classes
+ o how to handle finally
o implement an ANT task for build time class
rewriting (already have something on my disk)
o addition to async ContinuationCompilingClassLoader
@@ -38,7 +38,13 @@
o BCEL
o push some bug fixes in BCEL
+
+ http://issues.apache.org/bugzilla/show_bug.cgi?id=27646
+ http://issues.apache.org/bugzilla/show_bug.cgi?id=27854
+ http://issues.apache.org/bugzilla/show_bug.cgi?id=27855
+
o get rid of the static repository approach
+o talk to the RIFE guys about joining forces
o talk to the aspectwerkz and aspectj folks
about working together
Modified:
jakarta/commons/sandbox/javaflow/trunk/src/java/org/apache/commons/javaflow/Continuation.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/javaflow/trunk/src/java/org/apache/commons/javaflow/Continuation.java?view=diffr1=151734r2=151735
==
---
jakarta/commons/sandbox/javaflow/trunk/src/java/org/apache/commons/javaflow/Continuation.java
(original)
+++
jakarta/commons/sandbox/javaflow/trunk/src/java/org/apache/commons/javaflow/Continuation.java
Mon Feb 7 10:11:45 2005
@@ -35,39 +35,60 @@
public class Continuation implements Serializable {
private final static Log log = LogFactory.getLog(Continuation.class);
-
-private final Stack stack;
-
private final static transient Map continuationsMap = new HashMap();
+private transient Object context;
+
+private transient boolean restoring = false;
+private transient boolean capturing = false;
-private boolean restoring = false;
+private transient Method method;
+private transient Object instance;
+
+private String methodName;
+private final Stack stack;
+private final Continuation root;
-private boolean capturing = false;
+
+private Continuation() {
+stack = new Stack();
+root = this;
+}
/**
* Create a new continuation, which continue a previous continuation.
*/
private Continuation( final Continuation parent ) {
-if (parent != null) {
-stack = new Stack(parent.stack);
-} else {
-stack = new Stack();
-}
+stack = new Stack(parent.stack);
+methodName = parent.methodName;
+method = parent.method;
+instance = parent.instance;
+root = parent.root;
}
+
/**
- * Return the stack, which is used to store the frame information. private
- * Stack getStack() { return stack; }
+ * get the current contex. only valid
+ * while calling continueWith
+ *
+ * @return context object
*/
-
-// REVISIT
-private Object context;
-
public Object getContext() {
return context;
}
+
+public static Continuation startWith( final String methodName, final
ContinuationContext context ) {
+
+final Continuation newContinuation = new Continuation();
+
+newContinuation.methodName = methodName;
+
+log.debug(starting new flow from + methodName);
+
+return execute(newContinuation, context);
+}
+
/**
* Creates a new continuation to capture the
* next state. Resume where the old one was
@@ -77,42 +98,51 @@
* @param context context of the
DO NOT REPLY [Bug 33427] - 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 --- Additional Comments From [EMAIL PROTECTED] 2005-02-07 19:12 --- We are in the process of releasing version 1.1 of configuration and have just cut out release candidate 1.1RC1. The docmentation refers to this version. Because it is only a release candidate it is not mirrored at ibiblio. The latest nightly builds share exactly the same code base. I do not expect any significant changes before the final 1.1 release. About the quality of documentation: Do you have any concrete complaints? You are always invited to provide patches to improve the docs ;-) Oliver -- 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] Identify Class Loader Problems
Oh for better diagramming facilities in mail :-) *** Richard A. Sitze IBM WebSphere WebServices Development Ceki Gülcü [EMAIL PROTECTED] wrote on 02/07/2005 11:17:36 AM: On 2005-01-27 22:52:02, Richard Sitze wrote: Richard, Sorry for not responding earlier. I'be got a question regarding item C. C. Host / Sub - commons-logging.jar#org.apache.commons.logging.Log is loaded/loadable by Host. - A host, such as JUnit, creates and manages an independent Sub ClassLoader - Sub does NOT reference Host as a parent. How is that possible? As far as I know, a child class loader will (by default) inherit the system class loader as a parent, in this case 'Host'. System ClassLoader | +--+-+ || Host --- creates -- Sub As the set up you describe seems impossible to me, I can't make sense of the rest of your conclusions for item 'C'. What am I missing? - Sub is set as the thread context ClassLoader. - Execution is within code belonging to Host. Problems: 1. The discovery process may *fail* altogether as it starts with the thread context class loader, and cannot reach the Host loader. 2. The discovery process allows a Log implementation defined by the Sub to be discovered by the Host, as the host executes Host[LogFactory], via the thread context class loader. Consider the case where the *Sub* defines commons-logging.properties or META-INF/Services/org.apache.commons.logging.Log. -- 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]
Re: [logging] Enterprise Common Logging... dare we say 2.0?
Robert, Richard, Thank you both. On 2005-02-07 18:27:31, Richard Sitze wrote: System ClassLoader | +--+-+ || Host --- creates -- Sub -- 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]
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
Re: [logging] Enterprise Common Logging... dare we say 2.0?
On Mon, 2005-02-07 at 18:57, Ceki Gülcü wrote: Robert, Richard, Thank you both. i think richard's explanation wins, though :) On 2005-02-07 18:27:31, Richard Sitze wrote: System ClassLoader | +--+-+ || Host --- creates -- Sub - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[logging] releasing log4j resources
http://issues.apache.org/bugzilla/show_bug.cgi?id=32662 describes an issues that arises when restarting web apps in tomcat. JCL bridges to log4j which has a rolling file appender configured. the file appender doesn't roll when the application is restarted. the proposed solution is to add a call to LogManager.shutdown. i'm a little worried that calling shutdown may be inappropriate in this circumstance the JVM isn't closing, just a web application. before i take this question to the log4j lists, i wondered whether any log4j experts would be so kind as to either confirm my concerns or set my mind at ease. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[javaflow] patches
WHIRLYCOTT wrote: Torsten Curdt wrote: Well, the point is that the file writing code is temporary anyway. I should go away in the near future. That's why fixing it is not that important. Yes, I was going to ask about that one... can you let me in on your plans for this? I agree that it should go away, but I haven't spent any time rethinking this. ...not sure whether it's worth having it configurable for debugging purposes. WDYT? Btw: for some reason I've some problem applying your patches with eclipse :-/ ...most of the hunks are not being found. How goofy. The subclipse client isn't as painfree as the cvs one from what I can tell. The team synchronizing perspective occasionally indicates to me that there differences between local and remote when there are none. I'm not sure what could cause this... will investigate. I am talking about the apply patch dialog that comes with eclipse. cheers -- Torsten signature.asc Description: OpenPGP digital signature
Re: [logging] releasing log4j resources
Shouldn't this web-app which apparently knows it is using log4j call LogManger.shutdown() directly? At 09:05 PM 2/7/2005, you wrote: http://issues.apache.org/bugzilla/show_bug.cgi?id=32662 describes an issues that arises when restarting web apps in tomcat. JCL bridges to log4j which has a rolling file appender configured. the file appender doesn't roll when the application is restarted. the proposed solution is to add a call to LogManager.shutdown. i'm a little worried that calling shutdown may be inappropriate in this circumstance the JVM isn't closing, just a web application. before i take this question to the log4j lists, i wondered whether any log4j experts would be so kind as to either confirm my concerns or set my mind at ease. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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]
DO NOT REPLY [Bug 33221] - [logging] null pointer exception in LogFactory.getLog
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=33221. 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=33221 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-02-07 21:06 --- The code which seems to be in question now reads: ClassLoader cl = this.getClass().getClassLoader(); // handle the case if getClassLoader() returns null // It may mean this class was loaded from the bootstrap classloader logInterface = (cl == null) ? loadClass(LOG_INTERFACE) : cl.loadClass(LOG_INTERFACE); logClass = loadClass(logClassName); This looks ok. I've tried to replicate on my PowerBook with the newest code but doesn't seem to happen any more. -- 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 33313] - [javaflow] more test cases and findbugs problems
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=33313. 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=33313 [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2005-02-07 21:18 --- The close fix is already in. Regarding the null check: the question is what to do in such cases. Probably we should catch all exeception and return the the original or even throw a RuntimeException. ...not sure. For this case: if the frame is != null the context should should be != null. -- 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] releasing log4j resources
certainly the web application deployer should know :) IIRC it should be possible to tap into lifecycle events and perform the shutdown by creating a small amount of code external to the actual application. anyone object to me marking this one as WONTFIX? - robert On Mon, 2005-02-07 at 20:02, Ceki Gülcü wrote: Shouldn't this web-app which apparently knows it is using log4j call LogManger.shutdown() directly? At 09:05 PM 2/7/2005, you wrote: http://issues.apache.org/bugzilla/show_bug.cgi?id=32662 describes an issues that arises when restarting web apps in tomcat. JCL bridges to log4j which has a rolling file appender configured. the file appender doesn't roll when the application is restarted. the proposed solution is to add a call to LogManager.shutdown. i'm a little worried that calling shutdown may be inappropriate in this circumstance the JVM isn't closing, just a web application. before i take this question to the log4j lists, i wondered whether any log4j experts would be so kind as to either confirm my concerns or set my mind at ease. - robert - 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]
[Http Client] how I can pass Object to and from the servlet using Http Cleint
Hi, How I can pass Object to and from the servlet using Http Cleint. Can I used request.setAttribute(name, Object) in servlet. And is there any way to get them back in Client side(by using getAttribute or some other way as getAttribute is not exist). Please tell me Is there any way so I can communicate object using HttpClient. If yes then can I send parameter too from client. Thanks. Sanjeev Tripathi -Original Message- From: robert burrell donkin [mailto:[EMAIL PROTECTED] Sent: Monday, February 07, 2005 2:45 PM To: Jakarta Commons Developers List Subject: Re: [logging] releasing log4j resources certainly the web application deployer should know :) IIRC it should be possible to tap into lifecycle events and perform the shutdown by creating a small amount of code external to the actual application. anyone object to me marking this one as WONTFIX? - robert On Mon, 2005-02-07 at 20:02, Ceki Gülcü wrote: Shouldn't this web-app which apparently knows it is using log4j call LogManger.shutdown() directly? At 09:05 PM 2/7/2005, you wrote: http://issues.apache.org/bugzilla/show_bug.cgi?id=32662 describes an issues that arises when restarting web apps in tomcat. JCL bridges to log4j which has a rolling file appender configured. the file appender doesn't roll when the application is restarted. the proposed solution is to add a call to LogManager.shutdown. i'm a little worried that calling shutdown may be inappropriate in this circumstance the JVM isn't closing, just a web application. before i take this question to the log4j lists, i wondered whether any log4j experts would be so kind as to either confirm my concerns or set my mind at ease. - robert - 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]
svn commit: r151748 - jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/LogFactory.java
Author: rdonkin
Date: Mon Feb 7 12:36:53 2005
New Revision: 151748
URL: http://svn.apache.org/viewcvs?view=revrev=151748
Log:
Restricted warning message so that it is only displayed when the property has
been set
Modified:
jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/LogFactory.java
Modified:
jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/LogFactory.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/LogFactory.java?view=diffr1=151747r2=151748
==
---
jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/LogFactory.java
(original)
+++
jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/LogFactory.java
Mon Feb 7 12:36:53 2005
@@ -42,7 +42,7 @@
* @author Craig R. McClanahan
* @author Costin Manolache
* @author Richard A. Sitze
- * @version $Revision: 1.28 $ $Date: 2004/11/10 22:59:04 $
+ * @version $Revision: 1.28 $ $Date$
*/
public abstract class LogFactory {
@@ -115,7 +115,9 @@
*/
public static final String HASHTABLE_IMPLEMENTATION_PROPERTY =
org.apache.commons.logging.LogFactory.HashtableImpl;
-
+/** Name used to load the weak hashtable implementation by names */
+private static final String WEAK_HASHTABLE_CLASSNAME =
org.apache.commons.logging.impl.WeakHashtable;
+
// --- Constructors
@@ -224,7 +226,7 @@
String storeImplementationClass
= System.getProperty(HASHTABLE_IMPLEMENTATION_PROPERTY);
if (storeImplementationClass == null) {
-storeImplementationClass =
org.apache.commons.logging.impl.WeakHashtable;
+storeImplementationClass = WEAK_HASHTABLE_CLASSNAME;
}
try {
Class implementationClass =
Class.forName(storeImplementationClass);
@@ -232,7 +234,10 @@
} catch (Exception e) {
// ignore
-System.err.println([ERROR] LogFactory: Load of custom hashtable
failed);
+ if (!WEAK_HASHTABLE_CLASSNAME.equals(storeImplementationClass))
{
+ // if the user's trying to set up a custom
implementation, give a clue
+ System.err.println([ERROR] LogFactory: Load of custom
hashtable failed);
+ }
}
if (result == null) {
result = new Hashtable();
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r151750 - jakarta/commons/proper/logging/trunk/optional
Author: rdonkin Date: Mon Feb 7 12:42:52 2005 New Revision: 151750 URL: http://svn.apache.org/viewcvs?view=revrev=151750 Log: Added subversion ignore for build.properties in optional Modified: jakarta/commons/proper/logging/trunk/optional/ (props changed) Propchange: jakarta/commons/proper/logging/trunk/optional/ -- --- svn:ignore (original) +++ svn:ignore Mon Feb 7 12:42:52 2005 @@ -1,3 +1,4 @@ *.log target dist +*.properties - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JCL problems
Ceki Gülcü [EMAIL PROTECTED] wrote on 02/07/2005 01:32:26 PM: snip The idea of having separate jar files has been floated about for a few years, for various reasons. I believe it's only recently been associated with the idea that such would help alleviate classloader problems in the hierarchy [but only if certain rules are followed, as discussed in the original thread you referenced]. Sorry for my obtuseness but which rules are you referring to? Oh boy... ask a simple question... 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] So... what happens if/when the parent changes to move from default behavior to specific configuration behavior? Parent [commons-logging-api.jar, commons-logging.properties, MyLocalLoggerImpl.jar] ^ | Child [commons-logging.properties, LogKit.jar] Naturally, that drives down into the child, the parent effectively mandates the logger for the children. This is a very natural scenario. So, of course... sooner or later in our not-so-mythical universe, we get a user who wants to return control back to the client application [EJB's]. They would typically do this by setting [or the system is preset] the ClassLoader to do child-first resource resolution: Parent [commons-logging-api.jar, commons-logging.properties, MyLocalLoggerImpl.jar] ^ | Child, child-first loading [commons-logging.properties, LogKit.jar] Now we locate the proper config for the child, and all works as expected. But equally viable and frequently seen in this situation is a self contained EAR file: the EAR file contains a copy of the commons-logging jar file, and depends on the default behavior built into the LogFactory, i.e. NO config file: Parent [commons-logging-api.jar, commons-logging.properties, MyLocalLoggerImpl.jar] ^ | Child, child-first loading [commons-logging-api.jar, LogKit.jar] In this case, the child's LogFactory is going to locate the commons-logging.properties file from the parent, and attempt to load MyLocalLoggerImpl [which extends Parent's Log interface] and return it through the Child's LogFactory as a Child Log interface... and of course we get an Exception. A guideline ['rule'] that was floated about was that a parent class loader must never contain a configuration file, whether it be commons-logging.properties or META-INF/services/org.apache.commons.logging.Log*. This is not something we enforce today, and it's really counter to the expected use/configuration of JCL. So instead, we try the guideline that all children *must* provide a configuration file, noting that it may be ignored with parent-first search behavior. This is a small improvement, but again unenforcable. However, I've put more thought into this since my proposal of a few months back. :-) There are really THREE independent things that need to be done: a. Based on the discussion of ClassLoading issues from the other day, this is more properly handled by a discovery process that does NOT look higher in the hierarchy than the ClassLoader used to load the target interface (Log, in this case). This would prevent discovery of a configuration that does not apply to the local Log. b. Step completely away from default behavior [auto discovery]. Everything should be configured explicitely, either by placing a config file in every variant of the distributable jar files or possibly by hard-coding the logger impl for each variant [needs more thought]. c. Configuration discovery must enforce the rule that only ONE configuration may exist in any one ClassLoader. This doesn't mean we can't have diff configs in each ClassLoader in a hierarchy, or different *ways* to configure within a ClassLoader instance: it means that we must *must* have a clear understanding of which configuration is appropriate at a single *point* in the hierarchy. For example, the following *could* legal [though we could take a hard-line stance against it also]: Parent [A.jar(commons-logging.properties)] ^ | Child [B.jar(commons-logging.properties), C.jar(META-INF/services/org.apache.commons.logging.Log)] This might be considered legal because the discovery process places a precidence on the two
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]
svn commit: r151756 - in jakarta/commons/sandbox/jci/trunk: ./ src/java/org/apache/commons/ src/java/org/apache/commons/jci/ src/java/org/apache/commons/jci/compilers/ src/java/org/apache/commons/jci/compilers/eclipse/ src/java/org/apache/commons/jci/compilers/groovy/ src/java/org/apache/commons/jci/monitor/ src/java/org/apache/commons/jci/problems/ src/java/org/apache/commons/jci/readers/ src/java/org/apache/commons/jci/stores/ src/java/org/apache/jci/
Author: tcurdt Date: Mon Feb 7 13:04:01 2005 New Revision: 151756 URL: http://svn.apache.org/viewcvs?view=revrev=151756 Log: proper package name Added: jakarta/commons/sandbox/jci/trunk/src/java/org/apache/commons/ jakarta/commons/sandbox/jci/trunk/src/java/org/apache/commons/jci/ - copied from r151751, jakarta/commons/sandbox/jci/trunk/src/java/org/apache/jci/ Removed: jakarta/commons/sandbox/jci/trunk/src/java/org/apache/jci/ Modified: jakarta/commons/sandbox/jci/trunk/TODO jakarta/commons/sandbox/jci/trunk/project.xml jakarta/commons/sandbox/jci/trunk/src/java/org/apache/commons/jci/CompilingClassLoader.java jakarta/commons/sandbox/jci/trunk/src/java/org/apache/commons/jci/ResourceStoreClassLoader.java jakarta/commons/sandbox/jci/trunk/src/java/org/apache/commons/jci/compilers/JavaCompiler.java jakarta/commons/sandbox/jci/trunk/src/java/org/apache/commons/jci/compilers/eclipse/EclipseJavaCompiler.java jakarta/commons/sandbox/jci/trunk/src/java/org/apache/commons/jci/compilers/groovy/GroovyJavaCompiler.java jakarta/commons/sandbox/jci/trunk/src/java/org/apache/commons/jci/monitor/AlterationListener.java jakarta/commons/sandbox/jci/trunk/src/java/org/apache/commons/jci/monitor/AlterationMonitor.java jakarta/commons/sandbox/jci/trunk/src/java/org/apache/commons/jci/monitor/Test.java jakarta/commons/sandbox/jci/trunk/src/java/org/apache/commons/jci/problems/CompilationProblem.java jakarta/commons/sandbox/jci/trunk/src/java/org/apache/commons/jci/problems/CompilationProblemHandler.java jakarta/commons/sandbox/jci/trunk/src/java/org/apache/commons/jci/problems/ConsoleCompilationProblemHandler.java jakarta/commons/sandbox/jci/trunk/src/java/org/apache/commons/jci/readers/FileResourceReader.java jakarta/commons/sandbox/jci/trunk/src/java/org/apache/commons/jci/readers/ResourceReader.java jakarta/commons/sandbox/jci/trunk/src/java/org/apache/commons/jci/stores/FileResourceStore.java jakarta/commons/sandbox/jci/trunk/src/java/org/apache/commons/jci/stores/MemoryResourceStore.java jakarta/commons/sandbox/jci/trunk/src/java/org/apache/commons/jci/stores/ResourceStore.java jakarta/commons/sandbox/jci/trunk/src/java/org/apache/commons/jci/stores/TransactionalResourceStore.java Modified: jakarta/commons/sandbox/jci/trunk/TODO URL: http://svn.apache.org/viewcvs/jakarta/commons/sandbox/jci/trunk/TODO?view=diffr1=151755r2=151756 == --- jakarta/commons/sandbox/jci/trunk/TODO (original) +++ jakarta/commons/sandbox/jci/trunk/TODO Mon Feb 7 13:04:01 2005 @@ -1,5 +1,4 @@ o integrate just4log into the build system -o proper package names o subscribing to compiler events o monitor multiple repositories o compiler factory Modified: jakarta/commons/sandbox/jci/trunk/project.xml URL: http://svn.apache.org/viewcvs/jakarta/commons/sandbox/jci/trunk/project.xml?view=diffr1=151755r2=151756 == --- jakarta/commons/sandbox/jci/trunk/project.xml (original) +++ jakarta/commons/sandbox/jci/trunk/project.xml Mon Feb 7 13:04:01 2005 @@ -16,8 +16,7 @@ versions/versions branches/branches - !-- Note commons package is missing -- - packageorg.apache.jci.*/package + packageorg.apache.commons.jci.*/package developers Modified: jakarta/commons/sandbox/jci/trunk/src/java/org/apache/commons/jci/CompilingClassLoader.java URL: http://svn.apache.org/viewcvs/jakarta/commons/sandbox/jci/trunk/src/java/org/apache/commons/jci/CompilingClassLoader.java?view=diffr1=151751r2=151756 == --- jakarta/commons/sandbox/jci/trunk/src/java/org/apache/commons/jci/CompilingClassLoader.java (original) +++ jakarta/commons/sandbox/jci/trunk/src/java/org/apache/commons/jci/CompilingClassLoader.java Mon Feb 7 13:04:01 2005 @@ -13,7 +13,7 @@ * See the License for the specific language governing permissions and * limitations under the License. */ -package org.apache.jci; +package org.apache.commons.jci; import java.io.File; import java.io.InputStream; @@ -24,15 +24,15 @@ import org.apache.commons.logging.Log; import org.apache.commons.logging.LogFactory; -import org.apache.jci.compilers.JavaCompiler; -import org.apache.jci.compilers.eclipse.EclipseJavaCompiler; -import org.apache.jci.monitor.AlterationListener; -import org.apache.jci.monitor.AlterationMonitor; -import org.apache.jci.problems.ConsoleCompilationProblemHandler; -import org.apache.jci.readers.FileResourceReader; -import org.apache.jci.readers.ResourceReader; -import org.apache.jci.stores.MemoryResourceStore; -import org.apache.jci.stores.TransactionalResourceStore; +import org.apache.commons.jci.compilers.JavaCompiler; +import org.apache.commons.jci.compilers.eclipse.EclipseJavaCompiler; +import
svn commit: r151757 - in jakarta/commons/sandbox/javaflow/trunk: ./ lib/ src/java/org/apache/commons/javaflow/ src/java/org/apache/commons/javaflow/bytecode/ src/test/org/apache/commons/javaflow/
Author: tcurdt
Date: Mon Feb 7 13:05:17 2005
New Revision: 151757
URL: http://svn.apache.org/viewcvs?view=revrev=151757
Log:
updated to latest jci jar with proper package name
Added:
jakarta/commons/sandbox/javaflow/trunk/lib/commons-jci-0.1-dev.jar (with
props)
Removed:
jakarta/commons/sandbox/javaflow/trunk/lib/jci-20041213.jar
Modified:
jakarta/commons/sandbox/javaflow/trunk/project.properties
jakarta/commons/sandbox/javaflow/trunk/project.xml
jakarta/commons/sandbox/javaflow/trunk/src/java/org/apache/commons/javaflow/ContinuationCompilingClassLoader.java
jakarta/commons/sandbox/javaflow/trunk/src/java/org/apache/commons/javaflow/bytecode/RewritingResourceStore.java
jakarta/commons/sandbox/javaflow/trunk/src/test/org/apache/commons/javaflow/ContinuationCompilingClassLoaderTestCase.java
Added: jakarta/commons/sandbox/javaflow/trunk/lib/commons-jci-0.1-dev.jar
URL:
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/javaflow/trunk/lib/commons-jci-0.1-dev.jar?view=autorev=151757
==
Binary file - no diff available.
Propchange: jakarta/commons/sandbox/javaflow/trunk/lib/commons-jci-0.1-dev.jar
--
svn:mime-type = application/octet-stream
Modified: jakarta/commons/sandbox/javaflow/trunk/project.properties
URL:
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/javaflow/trunk/project.properties?view=diffr1=151756r2=151757
==
--- jakarta/commons/sandbox/javaflow/trunk/project.properties (original)
+++ jakarta/commons/sandbox/javaflow/trunk/project.properties Mon Feb 7
13:05:17 2005
@@ -34,5 +34,5 @@
#
# Jars set explicity by path.
#
-maven.jar.jci = ${basedir}/lib/jci-20041213.jar
+maven.jar.commons-jci = ${basedir}/lib/commons-jci-0.1-dev.jar
maven.jar.bcel = ${basedir}/lib/jakarta-bcel-20040329.jar
Modified: jakarta/commons/sandbox/javaflow/trunk/project.xml
URL:
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/javaflow/trunk/project.xml?view=diffr1=151756r2=151757
==
--- jakarta/commons/sandbox/javaflow/trunk/project.xml (original)
+++ jakarta/commons/sandbox/javaflow/trunk/project.xml Mon Feb 7 13:05:17 2005
@@ -58,9 +58,9 @@
/dependency
dependency
- groupIdjci/groupId
- artifactIdjci/artifactId
- version20041213/version
+ groupIdcommons-jci/groupId
+ artifactIdcommons-jci/artifactId
+ version0.1-dev/version
/dependency
dependency
Modified:
jakarta/commons/sandbox/javaflow/trunk/src/java/org/apache/commons/javaflow/ContinuationCompilingClassLoader.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/javaflow/trunk/src/java/org/apache/commons/javaflow/ContinuationCompilingClassLoader.java?view=diffr1=151756r2=151757
==
---
jakarta/commons/sandbox/javaflow/trunk/src/java/org/apache/commons/javaflow/ContinuationCompilingClassLoader.java
(original)
+++
jakarta/commons/sandbox/javaflow/trunk/src/java/org/apache/commons/javaflow/ContinuationCompilingClassLoader.java
Mon Feb 7 13:05:17 2005
@@ -18,10 +18,10 @@
import java.io.File;
import org.apache.commons.javaflow.bytecode.RewritingResourceStore;
+import org.apache.commons.jci.CompilingClassLoader;
+import org.apache.commons.jci.stores.MemoryResourceStore;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
-import org.apache.jci.CompilingClassLoader;
-import org.apache.jci.stores.MemoryResourceStore;
/**
* @author tcurdt
Modified:
jakarta/commons/sandbox/javaflow/trunk/src/java/org/apache/commons/javaflow/bytecode/RewritingResourceStore.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/javaflow/trunk/src/java/org/apache/commons/javaflow/bytecode/RewritingResourceStore.java?view=diffr1=151756r2=151757
==
---
jakarta/commons/sandbox/javaflow/trunk/src/java/org/apache/commons/javaflow/bytecode/RewritingResourceStore.java
(original)
+++
jakarta/commons/sandbox/javaflow/trunk/src/java/org/apache/commons/javaflow/bytecode/RewritingResourceStore.java
Mon Feb 7 13:05:17 2005
@@ -27,10 +27,10 @@
import org.apache.bcel.classfile.JavaClass;
import org.apache.bcel.util.ClassLoaderRepository;
import org.apache.commons.javaflow.bytecode.bcel.BcelClassTransformer;
+import org.apache.commons.jci.stores.ResourceStore;
+import org.apache.commons.jci.stores.TransactionalResourceStore;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
-import
RE: Spam: RE: Http Client- How to send and recieve Serialized Object using Http Client
Is there Any way I can retrieve object that I set in servlet using
request.setAttruibute(name, object);
And vise versa can I send from Client Side to servlet similar way as we
send
Other string parameter as follows
PostMethod authpost = new PostMethod(/argo/XmzServlet);
NameValuePair action = new NameValuePair(action, login);
NameValuePair url = new NameValuePair(url, argo/index.html);
NameValuePair userid = new NameValuePair(LOGIN_NAME, login);
NameValuePair password = new NameValuePair(LOGIN_PASSWORD, passwd);
NameValuePair thickClient = new NameValuePair(ThickClient,
ThickClient);
authpost.setRequestBody(
new NameValuePair[] {action, url, userid,
password,thickClient});
thanks.
-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
[Jakarta Commons Wiki] Updated: Logging/1.0.5ReleasePlan
Date: 2005-02-07T13:08:12 Editor: RobertBurrellDonkin Wiki: Jakarta Commons Wiki Page: Logging/1.0.5ReleasePlan URL: http://wiki.apache.org/jakarta-commons/Logging/1.0.5ReleasePlan Updated plan to reflect work done Change Log: -- @@ -6,7 +6,7 @@ == Status == -RELEASE PLAN is stalled (my much-loved cube blew up) +RELEASE PLAN: preparing for release branch @@ -17,7 +17,7 @@ == Documentation Review == * Ensure that javadocs and website are up to date. - * The new optional distribution which offers enhanced memory recycling in some environments needs documentation creating. + * The new optional distribution which offers enhanced memory recycling in some environments needs documentation creating. ''DONE'' (thanks brian) == Bug Review == - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[httpclient]- How to send and recieve Serialized Object using Http Client
Is there Any way I can retrieve object that I set in servlet using
request.setAttruibute(name, object);
And vise versa can I send from Client Side to servlet similar way as we
send
Other string parameter as follows
PostMethod authpost = new PostMethod(/argo/XmzServlet);
NameValuePair action = new NameValuePair(action, login);
NameValuePair url = new NameValuePair(url, argo/index.html);
NameValuePair userid = new NameValuePair(LOGIN_NAME, login);
NameValuePair password = new NameValuePair(LOGIN_PASSWORD, passwd);
NameValuePair thickClient = new NameValuePair(ThickClient,
ThickClient);
authpost.setRequestBody(
new NameValuePair[] {action, url, userid,
password,thickClient});
thanks.
-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
Re: [logging] releasing log4j resources
robert burrell donkin [EMAIL PROTECTED] wrote on 02/07/2005 02:45:28 PM: certainly the web application deployer should know :) IIRC it should be possible to tap into lifecycle events and perform the shutdown by creating a small amount of code external to the actual application. anyone object to me marking this one as WONTFIX? +1 to mark as WONTFIX. JCL *uses* a logger implementation, it shouldn't attempt to configure it or manage it. Consider: Parent [commons-logging-api.jar, Log4j] | +++ | | ChildAChildB [uses Log, Log bound to Log4JLogger, Log4JLogger bound to LogFactoryImpl, LogFactoryImpl instance bound to ChildB] When ChildB is disposed of, we currently do not have anyway of recognizing that the LogFactoryImpl using Log4J is being managed by Parent or ChildB. The ChildB classloader, or rather the LogFactoryImpl, should not attempt to manage this resource, as that may cause problems for both Parent and ChildA. - robert On Mon, 2005-02-07 at 20:02, Ceki Gülcü wrote: Shouldn't this web-app which apparently knows it is using log4j call LogManger.shutdown() directly? At 09:05 PM 2/7/2005, you wrote: http://issues.apache.org/bugzilla/show_bug.cgi?id=32662 describes an issues that arises when restarting web apps in tomcat. JCL bridges to log4j which has a rolling file appender configured. the file appender doesn't roll when the application is restarted. the proposed solution is to add a call to LogManager.shutdown. i'm a little worried that calling shutdown may be inappropriate in this circumstance the JVM isn't closing, just a web application. before i take this question to the log4j lists, i wondered whether any log4j experts would be so kind as to either confirm my concerns or set my mind at ease. - robert - 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] *** Richard A. Sitze IBM WebSphere WebServices Development
[httpclient]RE: Spam: RE: Http Client- How to send and recieve Serialized Object using Http Client
Can you please send me link for base 64 encode/decode examples in java.
-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]
svn commit: r151761 - jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/actions/SetNextAction.java
Author: skitching
Date: Mon Feb 7 13:50:58 2005
New Revision: 151761
URL: http://svn.apache.org/viewcvs?view=revrev=151761
Log:
Very minor tidyups
Modified:
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/actions/SetNextAction.java
Modified:
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/actions/SetNextAction.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/actions/SetNextAction.java?view=diffr1=151760r2=151761
==
---
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/actions/SetNextAction.java
(original)
+++
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/actions/SetNextAction.java
Mon Feb 7 13:50:58 2005
@@ -26,19 +26,35 @@
import org.apache.commons.digester2.ParseException;
/**
- * pRule implementation that calls a method on the (top-1) (parent)
- * object, passing the top object (child) as an argument. It is
- * commonly used to establish parent-child relationships./p
+ * pAn Action that calls a method on the (top-1) (parent) object, passing
+ * the top object (child) as an argument. It is commonly used to establish
+ * parent-child relationships between objects on the digester stack./p
*/
public class SetNextAction extends AbstractAction {
-// --- Constructors
+// -
+// Instance Variables
+// -
/**
- * Construct a set next rule with the specified method name. The
- * method's argument type is assumed to be the class of the
- * child object.
+ * The method name to call on the parent object.
+ */
+protected String methodName = null;
+
+/**
+ * The Java class name of the parameter type expected by the method.
+ * Normally this is null, in which case the paramType used is the
+ * concrete type of the object being passed.
+ */
+protected String paramType = null;
+
+// ---
+// Constructors
+// ---
+
+/**
+ * Construct an action which invokes the specified method name.
*
* @param methodName Method name of the parent method to call
*/
@@ -55,30 +71,19 @@
* Java wrapper class instead, such as codejava.lang.Boolean/code
* for a codeboolean/code parameter)
*/
-public SetNextAction(String methodName,
- String paramType) {
+public SetNextAction(String methodName, String paramType) {
this.methodName = methodName;
this.paramType = paramType;
}
-// - Instance Variables
-
-/**
- * The method name to call on the parent object.
- */
-protected String methodName = null;
-
-/**
- * The Java class name of the parameter type expected by the method.
- */
-protected String paramType = null;
-
-// - Public Methods
+// -
+// Public Methods
+// -
/**
* Process the end of this element.
*/
-public void end(Context context, String namespace, String nme)
+public void end(Context context, String namespace, String name)
throws ParseException {
// Identify the objects to be used
Object child = context.peek(0);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r151762 - jakarta/commons/proper/httpclient/trunk/xdocs/index.xml
Author: olegk Date: Mon Feb 7 13:59:32 2005 New Revision: 151762 URL: http://svn.apache.org/viewcvs?view=revrev=151762 Log: Fixed the applications page link on the index page Modified: jakarta/commons/proper/httpclient/trunk/xdocs/index.xml Modified: jakarta/commons/proper/httpclient/trunk/xdocs/index.xml URL: http://svn.apache.org/viewcvs/jakarta/commons/proper/httpclient/trunk/xdocs/index.xml?view=diffr1=151761r2=151762 == --- jakarta/commons/proper/httpclient/trunk/xdocs/index.xml (original) +++ jakarta/commons/proper/httpclient/trunk/xdocs/index.xml Mon Feb 7 13:59:32 2005 @@ -7,7 +7,7 @@ author email=commons-dev@jakarta.apache.orgCommons Documentation Team/author author email=[EMAIL PROTECTED]Rodney Waldhoff/author author email=[EMAIL PROTECTED]Jeff Dever/author -revision$Id: index.xml,v 1.9 2003/02/08 01:41:49 jsdever Exp $/revision +revision$Id$/revision /properties body @@ -44,8 +44,8 @@ Some of these are open source with project pages you can find on the web while others are closed source that you would never see or hear about. The Apache Source License provides maximum flexibility for source and binary -reuse. Please see the a href=applications.htmlApplications/a page -for projects using emHttpClient/em. +reuse. Please see the a href=http://wiki.apache.org/jakarta-httpclient/HttpClientPowered; +Applications/a page for projects using emHttpClient/em. /p /section - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r151763 - jakarta/commons/proper/httpclient/branches/HTTPCLIENT_2_0_BRANCH/xdocs/index.xml
Author: olegk Date: Mon Feb 7 13:59:54 2005 New Revision: 151763 URL: http://svn.apache.org/viewcvs?view=revrev=151763 Log: Fixed the applications page link on the index page Modified: jakarta/commons/proper/httpclient/branches/HTTPCLIENT_2_0_BRANCH/xdocs/index.xml Modified: jakarta/commons/proper/httpclient/branches/HTTPCLIENT_2_0_BRANCH/xdocs/index.xml URL: http://svn.apache.org/viewcvs/jakarta/commons/proper/httpclient/branches/HTTPCLIENT_2_0_BRANCH/xdocs/index.xml?view=diffr1=151762r2=151763 == --- jakarta/commons/proper/httpclient/branches/HTTPCLIENT_2_0_BRANCH/xdocs/index.xml (original) +++ jakarta/commons/proper/httpclient/branches/HTTPCLIENT_2_0_BRANCH/xdocs/index.xml Mon Feb 7 13:59:54 2005 @@ -7,7 +7,7 @@ author email=commons-dev@jakarta.apache.orgCommons Documentation Team/author author email=[EMAIL PROTECTED]Rodney Waldhoff/author author email=[EMAIL PROTECTED]Jeff Dever/author -revision$Id: index.xml,v 1.9 2003/02/08 01:41:49 jsdever Exp $/revision +revision$Id$/revision /properties body @@ -44,8 +44,8 @@ Some of these are open source with project pages you can find on the web while others are closed source that you would never see or hear about. The Apache Source License provides maximum flexibility for source and binary -reuse. Please see the a href=applications.htmlApplications/a page -for projects using emHttpClient/em. +reuse. Please see the a href=http://wiki.apache.org/jakarta-httpclient/HttpClientPowered; +Applications/a page for projects using emHttpClient/em. /p /section - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[logging] 1.0.5 release: plan update and bug review
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]
Re: [lang] release strategy
Personally I find the three digit release numbers just confusing. I much prefer to reserve the third digit for essential patches. So, I'm happy to have a 2.1-branch, but I want the release to be 2.1, not 2.1.0 or 2.1.1. Stephen - Original Message - From: Henri Yandell [EMAIL PROTECTED] I'm very tempted to try the branch then release strategy, and wondered what people thought about the idea. It might suggest a slight change to the version number style: Create 2.1 branch. Make changes to 2.1 branch until we're ready for release. Tag 2.1 branch with 2.1.0 tag. ... later Change 2.1 branch until we're ready for release Tag 2.1 branch with 2.1.1tag. ... later in parallel Change trunk until we're near a release Create 2.2 branch (or 3.0) Change 2.2 until ready Tag 2.2 with 2.2.0 etc. If we called it 2.1-head or something, it wouldn't need the version change, it just feels more logical to go with a 2.1.0 release than a 2.1 one if we use this style of development. Anyway, it seems to me that this fits us more nowadays. We end up with the text package slowing down because it's not planned for the next release, and having to avoid various other bugzilla requests as they're not wanting to be fixed until later. Any thoughts? Hen - 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 33436] New: - DateValidation doesn't allow dates
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=33436. 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=33436 Summary: DateValidation doesn't allow dates Product: Commons Version: 1.3 Final Platform: Macintosh OS/Version: Mac OS X 10.0 Status: NEW Severity: normal Priority: P2 Component: Validator AssignedTo: commons-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] It seems that Commons Validator does not allow me to validate properties that are of type java.util.Date. It only works if my properties are java.lang.String. WARN - GenericTypeValidator.formatDate(222) | Fri Dec 31 00:00:00 MST 2004 java.text.ParseException: Unparseable date: Fri Dec 31 00:00:00 MST 2004 at java.text.DateFormat.parse(DateFormat.java:335) at org.apache.commons.validator.GenericTypeValidator.formatDate(GenericTypeValidator.java:213) at org.apache.struts.validator.FieldChecks.validateDate(FieldChecks.java:519) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) It would be nice to validate Dates, so it would be easier to validate nested POJOs, as well as Spring Command objects (since Commons Validator works with Spring MVC). -- 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 33436] - DateValidation doesn't allow dates
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=33436. 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=33436 --- Additional Comments From [EMAIL PROTECTED] 2005-02-07 23:59 --- Thats the purpose of the date validator - to validate a String date. It validates by parsing the String into a java.util.Date for a specified pattern - and if its parses OK, its valid. If your input is already a java.util.Date then presumably its already a valid date, so I what exactly you want validator to validate? Niall -- 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 33436] - DateValidation doesn't allow dates
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=33436. 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=33436 --- Additional Comments From [EMAIL PROTECTED] 2005-02-08 00:30 --- Hmmm, I suppose that makes sense. I guess POJOs in Spring will just have to have duplicate properties in order to validate request parameters that are populating date fields? I guess I'll just have String accessors in my ActionForm that set the real date after (presumably) passing validating. It's just kindof a pain to do new SimpleDateFormat(MM/dd/).parse(stringDate) in order to get a Date and set it on the nested POJO's java.util.Date method. I suppose I could just not validate those, but then BeanUtils would probably blow up if the date is in an invalid format. -- 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: [lang] release strategy
Personally, I've always liked the following numbering scheme: Major.Minor.Maintenance. Gary -Original Message- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] Sent: Monday, February 07, 2005 2:08 PM To: Jakarta Commons Developers List Subject: Re: [lang] release strategy Personally I find the three digit release numbers just confusing. I much prefer to reserve the third digit for essential patches. So, I'm happy to have a 2.1-branch, but I want the release to be 2.1, not 2.1.0 or 2.1.1. Stephen - Original Message - From: Henri Yandell [EMAIL PROTECTED] I'm very tempted to try the branch then release strategy, and wondered what people thought about the idea. It might suggest a slight change to the version number style: Create 2.1 branch. Make changes to 2.1 branch until we're ready for release. Tag 2.1 branch with 2.1.0 tag. ... later Change 2.1 branch until we're ready for release Tag 2.1 branch with 2.1.1tag. ... later in parallel Change trunk until we're near a release Create 2.2 branch (or 3.0) Change 2.2 until ready Tag 2.2 with 2.2.0 etc. If we called it 2.1-head or something, it wouldn't need the version change, it just feels more logical to go with a 2.1.0 release than a 2.1 one if we use this style of development. Anyway, it seems to me that this fits us more nowadays. We end up with the text package slowing down because it's not planned for the next release, and having to avoid various other bugzilla requests as they're not wanting to be fixed until later. Any thoughts? Hen - 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: Spam: RE: Http Client- How to send and recieve Serialized Object using Http Client
Ok. I am able to receive object from servlet using
application/octet-stream, but How I can send the object from client
to sevlet. NameValuePair allow only Strings.
Thanks.
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]
DO NOT REPLY [Bug 33436] - DateValidation doesn't allow dates
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=33436. 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=33436 --- Additional Comments From [EMAIL PROTECTED] 2005-02-08 01:05 --- The shame is that since you have to go to the trouble of configuring validator with the date format and then validator goes and does the parse and converts it to a java.util.Date - that then doesn't get passed on to populate the actual property of whatever bean you want. It would also be nice if validators also passed on converted values to dependant validations. That way if I wanted to implement some custom date check (e.g. must be future date) I already have a valid java.util.Date to work with. Having said that validator does put the results into a ValidatorResults object but, for example, Struts doesn't do anything with that - and I'm guessing SpringMVC doesn't either. Also there isn't a way to configure validator to pass the converted value - you would have to build that into your custom validation. I also have a feeling that 'indexed' properties don't actually have their 'index' value in the results - but thats only from memory, so I could be wrong on that. -- 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 33436] - [Validator] DateValidation doesn't allow dates
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=33436. 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=33436 [EMAIL PROTECTED] changed: What|Removed |Added Summary|DateValidation doesn't allow|[Validator] DateValidation |dates |doesn't allow dates -- 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
How to use RequestEntity in http client to send and retrieve object
from servlet and vice versa.
Thanks.
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: [io] copyAndClose
From: B. K. Oxley (binkley) [EMAIL PROTECTED]
I do not understand. What is being copied in the finally block? Should
that have been:
finally {
IOUtils.closeQuietly(in);
IOUtils.closeQuietly(out);
}
Oops ;-) Yes
I do not want to swallow exceptions thrown by closing in or out as they
might indicate to the caller some kind of important failure (say a network
error). That is why my original has nexted try/finally blocks:
finally {
try {
out.close();
} finally {
in.close();
}
}
Oh. This is quite dangerous code as if both the closing of out and in throw
an exception only the exception from in is actually thrown.
The question then becomes whether the method to add to IOUtils is
copyAndClose() or copyAndCloseQuietly()
I wonder if any other committer has a view.
Were you interested in writing the patch and tests for IOUtils?
Do I just pull IO from SVN? What form of patch: unified diff ok?
Yes x2, but wait until we see if someone else comments on the thread
Stephen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE][configuration]Release 1.1
+1 ! Emmanuel Bourg Oliver Heger wrote: Dear community, since the 1.0 release of [configuration] a couple of new features have been added. The code base has been stable for a while now, so I think it is time to cut out a new 1.1 release before we start to implement further features and refactorings. A complete list of changes since the 1.0 releaes can be found here: http://jakarta.apache.org/commons/configuration/changes-report.html I have created a release candidate, which can be inspected at http://www.apache.org/~oheger/commons-configuration-1.1rc1/ (the tag for 1.1RC1 is named CONFIGURATION_1_1RC1). Here is my +1! Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] 1.0.5 release: plan update and bug review
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. Why? - The fix I envision will necessitate backwards incompatible behavior in a standalone commons-logging.jar file. This requires 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. - commons-logging 2.0 should to defer to commons-discovery, if commons-discovery is available in an appropriate class-loader [and yes, this means discovering commons-discovery... headache time.. but we'll keep it simple anyway :-) right?]. - I want to fix the ClassLoader problems in commons-discovery. - 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. 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. ras *** Richard A. Sitze IBM WebSphere WebServices Development robert burrell donkin [EMAIL PROTECTED] wrote on 02/07/2005 04:16:42 PM: 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]
svn commit: r151812 - in jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/actions: CreateNodeAction.java NodeCreateAction.java
Author: skitching Date: Mon Feb 7 18:00:43 2005 New Revision: 151812 URL: http://svn.apache.org/viewcvs?view=revrev=151812 Log: * Rename NodeCreateAction to CreateNodeAction * Decouple namespace-awareness of created nodes from namespace-awareness of digester's xml parser. Added: jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/actions/CreateNodeAction.java (contents, props changed) - copied, changed from r151539, jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/actions/NodeCreateAction.java Removed: jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/actions/NodeCreateAction.java Copied: jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/actions/CreateNodeAction.java (from r151539, jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/actions/NodeCreateAction.java) URL: http://svn.apache.org/viewcvs/jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/actions/CreateNodeAction.java?view=diffrev=151812p1=jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/actions/NodeCreateAction.javar1=151539p2=jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/actions/CreateNodeAction.javar2=151812 == --- jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/actions/NodeCreateAction.java (original) +++ jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/actions/CreateNodeAction.java Mon Feb 7 18:00:43 2005 @@ -1,19 +1,19 @@ -/* $Id: $ +/* $Id$ + * + * Copyright 2002-2005 The Apache Software Foundation. * - * Copyright 2002-2004 The Apache Software Foundation. - * * Licensed under the Apache License, Version 2.0 (the License); * you may not use this file except in compliance with the License. * You may obtain a copy of the License at - * + * * http://www.apache.org/licenses/LICENSE-2.0 - * + * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an AS IS BASIS, * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. * See the License for the specific language governing permissions and * limitations under the License. - */ + */ package org.apache.commons.digester2.actions; @@ -41,22 +41,26 @@ import org.apache.commons.digester2.SAXHandler; /** - * A rule implementation that creates a DOM - * [EMAIL PROTECTED] org.w3c.dom.Node Node} containing the XML at the element that matched - * the rule. Two concrete types of nodes can be created by this rule: + * pAn Action that creates a DOM [EMAIL PROTECTED] org.w3c.dom.Node Node} + * containing the XML at the element that matched the action./p + * + * pThe node can then be passed as a parameter to another object on + * the stack (usually the previous one) using SetNextAction, CallMethodAction + * or a similar Action./p + * + * pTwo concrete types of nodes can be created by this action: * ul * lithe default is to create an [EMAIL PROTECTED] org.w3c.dom.Element Element} node. - * The created element will correspond to the element that matched the rule, + * The created element will correspond to the element that matched the action, * containing all XML content underneath that element./li - * lialternatively, this rule can create nodes of type + * lialternatively, this action can create nodes of type * [EMAIL PROTECTED] org.w3c.dom.DocumentFragment DocumentFragment}, which will contain - * only the XML content under the element the rule was trigged on./li + * only the XML content under the element the action was trigged on./li * /ul - * The created node will be normalized, meaning it will not contain text nodes + * The created node will be normalized, meaning it will not contain text nodes * that only contain white space characters. - * - - * + * /p + * * pThe created codeNode/code will be pushed on Digester's object stack * when done. To use it in the context of another DOM * [EMAIL PROTECTED] org.w3c.dom.Document Document}, it must be imported first, using the @@ -64,69 +68,56 @@ * [EMAIL PROTECTED] org.w3c.dom.Document#importNode(org.w3c.dom.Node, boolean) importNode()}. * /p * - * pstrongImportant Note:/strong This is implemented by replacing the SAX - * [EMAIL PROTECTED] org.xml.sax.ContentHandler ContentHandler} in the parser used by - * Digester, and resetting it when the matched element is closed. As a side - * effect, rules that would match XML nodes under the element that matches - * a codeNodeCreateAction/code will never be triggered by Digester, which - * usually is the behavior one would expect./p - * - *
svn commit: r151814 - jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/actions/CreateNodeActionTestCase.java
Author: skitching
Date: Mon Feb 7 18:01:26 2005
New Revision: 151814
URL: http://svn.apache.org/viewcvs?view=revrev=151814
Log:
Add tests for CreateNodeAction
Added:
jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/actions/CreateNodeActionTestCase.java
(with props)
Added:
jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/actions/CreateNodeActionTestCase.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/actions/CreateNodeActionTestCase.java?view=autorev=151814
==
---
jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/actions/CreateNodeActionTestCase.java
(added)
+++
jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/actions/CreateNodeActionTestCase.java
Mon Feb 7 18:01:26 2005
@@ -0,0 +1,169 @@
+/* $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.HashMap;
+
+import org.xml.sax.InputSource;
+import org.w3c.dom.Element;
+import org.w3c.dom.Text;
+import org.w3c.dom.NodeList;
+
+
+import org.apache.commons.logging.Log;
+import org.apache.commons.digester2.Digester;
+
+/**
+ * pTest Cases for the CreateNodeActionTestCase class./p
+ */
+
+public class CreateNodeActionTestCase extends TestCase {
+
+// ---
+// Constructors
+// ---
+
+/**
+ * Construct a new instance of this test case.
+ *
+ * @param name Name of the test case
+ */
+public CreateNodeActionTestCase(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(CreateNodeActionTestCase.class));
+}
+
+/**
+ * Tear down instance variables required by this test case.
+ */
+public void tearDown() {
+}
+
+//
+// Individual Test Methods
+//
+
+/**
+ * Utility method useful when tests aren't working and you need
+ * to figure out why.
+ */
+private void dumpNode(String indent, org.w3c.dom.Node node) {
+
+System.out.print(indent);
+System.out.println(node [ + node.getNodeName() + ] = [ +
node.getNodeValue() + ]);
+org.w3c.dom.NamedNodeMap attrs = node.getAttributes();
+if (attrs != null) {
+int nAttrs = attrs.getLength();
+for(int i=0; inAttrs; ++i) {
+org.w3c.dom.Node attr = attrs.item(i);
+System.out.print(indent);
+System.out.println(
+ { + attr.getNamespaceURI() + }
+ + attr.getNodeName() + = + attr.getNodeValue());
+}
+}
+node = node.getFirstChild();
+while (node != null) {
+dumpNode(indent + , node);
+node = node.getNextSibling();
+}
+}
+
+
+/**
+ * Test basic operations.
+ */
+public void testBasicOperations() throws Exception {
+String inputText =
+root +
+ node attr1='1' attr2='2' +
+child attr='c1'/ +
+childbodytext/child +
+ /node +
+/root;
+
+InputSource source = new InputSource(new StringReader(inputText));
+
+Digester d = new Digester();
+
+CreateNodeAction action = new CreateNodeAction();
+d.addRule(/root/node, action);
+d.parse(source);
+
+Element element = null;
+try {
+element = (Element) d.getRoot();
+} catch(ClassCastException
[Jakarta Commons Wiki] Updated: Digester/TODO
Date: 2005-02-07T19:52:13 Editor: WendySmoak Wiki: Jakarta Commons Wiki Page: Digester/TODO URL: http://wiki.apache.org/jakarta-commons/Digester/TODO no comment Change Log: -- @@ -78,6 +78,13 @@ However it has been reported that the !SetNextRule doesn't handle !DynaBeans well (see mail archives for 2004-11-25, subject '!DynaBean Hierarchy'). It would be nice to fix this if an elegant solution can be found (and fix any other rules that might not work well with !DynaBeans). +=== Add Missing XML Rules === + +There are some Rules that could be configured with xml-based rules, but they aren't in !DigesterRuleParser nor the DTD. + + !CallMethodRule with 'target stack offset' + See: http://www.mail-archive.com/commons-user%40jakarta.apache.org/msg10012.html + == Possible == === Refactor CallParamRule === - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Jakarta Commons Wiki] Updated: Digester/TODO
Date: 2005-02-07T20:30:55 Editor: WendySmoak Wiki: Jakarta Commons Wiki Page: Digester/TODO URL: http://wiki.apache.org/jakarta-commons/Digester/TODO no comment Change Log: -- @@ -80,7 +80,7 @@ === Add Missing XML Rules === -There are some Rules that could be configured with xml-based rules, but they aren't in !DigesterRuleParser nor the DTD. +There are some Rules that could be configured with xml-based rules, but they aren't in !DigesterRuleParser or the DTD. !CallMethodRule with 'target stack offset' See: http://www.mail-archive.com/commons-user%40jakarta.apache.org/msg10012.html @@ -200,11 +200,16 @@ Class !DigesterRuleParser in the xmlrules package uses the deprecated begin() and end() methods (as do some other rules). Fix these. In general, get rid of use of deprecated methods. === Think about parsing multiple documents === + Some people have expressed the desire to use the same Digester instance to parse multiple xml documents. This is currently (v1.6) fairly unsafe. In the current (1.6) version, the best option is probably to create a configured Rules object and a configured !SAXParser object and keep these cached for reuse but recreate a new Digester object each time. At the least we should carefully document what objects are safe for reuse and which are not. And what the implications of using Digesters and Rules objects in multithreaded apps. I also think the APIs for preconfiguring Rules or !RuleSet objects and then reusing them are rather inconsistent, and need some review/fixing. This is particularly important for the !XmlRules stuff, as parsing an xmlrules config file is not a quick process. See bugzilla #29428 for some discussion of this. + +=== Make the XML Rules DTD more consistent === + +Some things are hyphenated, some are not. One tag uses attr-name while the rest use attrname. One uses prop-name and another propertyname. == Possible == - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[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]
