Re:
Isn't modeler dead, IIRC? Jakarta Commons Developers List commons-dev@jakarta.apache.org wrote: I am sorry to hurt somone's feelings: I think email doest not do much. Just IMO. Modeler, same. Consider moving them back to sandbox. .V -- Forums, Boards, Blogs and News in RiA http://www.boardVU.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Sign up for eircom broadband now and get a free two month trial.* Phone 1850 73 00 73 or visit http://home.eircom.net/broadbandoffer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re:
On Thu, 10 Feb 2005 08:17:12 +, Rory Winston [EMAIL PROTECTED] wrote: Isn't modeler dead, IIRC? Only if you think its OK to break Tomcat builds -- Tomcat critically depends on Modeler for its JMX support. There is a difference between being actively developed and enhanced and being complete enough to do what it's designed to do, with no further changes. The latter characterization also applies to other mature projects like jakarta-oro and jakarta-regexp ... they do what they are designed to do, no muss no fuss. The fact that they aren't being actively developed is a Good Thing. Vic, the fact that *you* may not find a particular package useful has nothing to do with what other people might think :-). Craig Jakarta Commons Developers List commons-dev@jakarta.apache.org wrote: I am sorry to hurt somone's feelings: I think email doest not do much. Just IMO. Modeler, same. Consider moving them back to sandbox. .V -- Forums, Boards, Blogs and News in RiA http://www.boardVU.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Sign up for eircom broadband now and get a free two month trial.* Phone 1850 73 00 73 or visit http://home.eircom.net/broadbandoffer - 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 33481] - [io] Synchronized methods in NullOutputStream
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=33481. 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=33481 [EMAIL PROTECTED] changed: What|Removed |Added OS/Version|Windows XP |All Platform|PC |All Summary|sychronized methods in |[io] Synchronized methods in |NullOutputStream|NullOutputStream -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[GUMP@brutus]: Project commons-id (in module jakarta-commons-sandbox) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-id has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 4 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-id : Commons Identifier Package Full details are available at: http://brutus.apache.org/gump/public/jakarta-commons-sandbox/commons-id/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-id-10022005.jar] identifier set to project name -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/jakarta-commons-sandbox/id/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/jakarta-commons-sandbox/id/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/jakarta-commons-sandbox/id/project.properties -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://brutus.apache.org/gump/public/jakarta-commons-sandbox/commons-id/gump_work/build_jakarta-commons-sandbox_commons-id.html Work Name: build_jakarta-commons-sandbox_commons-id (Type: Build) Work ended in a state of : Failed Elapsed: 1 sec Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/jakarta-commons-sandbox/id] CLASSPATH: /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/discovery/dist/commons-discovery.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar - __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.0.2 org.apache.maven.MavenException: Error reading XML or initializing at org.apache.maven.MavenUtils.getProject(MavenUtils.java:156) at org.apache.maven.MavenUtils.getProject(MavenUtils.java:122) at org.apache.maven.MavenSession.initializeRootProject(MavenSession.java:232) at org.apache.maven.MavenSession.initialize(MavenSession.java:172) at org.apache.maven.cli.App.doMain(App.java:475) at org.apache.maven.cli.App.main(App.java:1239) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at com.werken.forehead.Forehead.run(Forehead.java:551) at com.werken.forehead.Forehead.main(Forehead.java:581) --- Nested Exception --- java.io.FileNotFoundException: Parent POM not found: /home/gump/workspaces2/public/workspace/jakarta-commons-sandbox/sandbox-build/project.xml at org.apache.maven.MavenUtils.getNonJellyProject(MavenUtils.java:230) at org.apache.maven.MavenUtils.getProject(MavenUtils.java:143) at org.apache.maven.MavenUtils.getProject(MavenUtils.java:122) at org.apache.maven.MavenSession.initializeRootProject(MavenSession.java:232) at org.apache.maven.MavenSession.initialize(MavenSession.java:172) at org.apache.maven.cli.App.doMain(App.java:475) at org.apache.maven.cli.App.main(App.java:1239) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at com.werken.forehead.Forehead.run(Forehead.java:551) at com.werken.forehead.Forehead.main(Forehead.java:581) You have encountered an unknown error
[GUMP@brutus]: Project commons-jelly-tags-xml (in module commons-jelly) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-jelly-tags-xml has an issue affecting its community integration. This issue affects 12 projects, and has been outstanding for 4 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-define : Commons Jelly - commons-jelly-tags-html : Commons Jelly - commons-jelly-tags-http : Commons Jelly - commons-jelly-tags-jaxme : Commons Jelly - commons-jelly-tags-jetty : Commons Jelly - commons-jelly-tags-jface : Commons Jelly - commons-jelly-tags-jsl : Commons Jelly - commons-jelly-tags-swing : Commons Jelly - commons-jelly-tags-xml : Commons Jelly - commons-jelly-tags-xmlunit : Commons Jelly - maven : Project Management Tools - maven-bootstrap : Project Management Tools Full details are available at: http://brutus.apache.org/gump/public/commons-jelly/commons-jelly-tags-xml/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-jelly-tags-xml-10022005.jar] identifier set to project name -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/test-reports -DEBUG- Extracted fallback artifacts from Gump Repository The following work was performed: http://brutus.apache.org/gump/public/commons-jelly/commons-jelly-tags-xml/gump_work/build_commons-jelly_commons-jelly-tags-xml.html Work Name: build_commons-jelly_commons-jelly-tags-xml (Type: Build) Work ended in a state of : Failed Elapsed: 14 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml] CLASSPATH: /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-10022005.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-10022005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-10022005.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-10022005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-10022005.jar - [mkdir] Created dir: /home/gump/workspaces2/public/workspace/commons-jelly/jelly-tags/xml/target/classes java:compile: [echo] Compiling to /home/gump/workspaces2/public/workspace/commons-jelly/jelly-tags/xml/target/classes [echo] == NOTE: Targetting JVM 1.4, classes will not run on earlier JVMs == [javac] Compiling 16 source files to /home/gump/workspaces2/public/workspace/commons-jelly/jelly-tags/xml/target/classes java:jar-resources: test:prepare-filesystem: [mkdir] Created dir: /home/gump/workspaces2/public/workspace/commons-jelly/jelly-tags/xml/target/test-classes [mkdir] Created dir: /home/gump/workspaces2/public/workspace/commons-jelly/jelly-tags/xml/target/test-reports test:test-resources: Copying 36 files to
[VFS] Asking for a solution with Zip files
OK, my problem is that I want to create some files in an inexisting location. I've understood that i can't resolveFile like zip:file://c:/temp/toto.zip!/myFile.txt if toto.zip doesn't exist. But How can I manipulate the URL to create first the file and then create its son. (The same question is available if the URL is ftp://myserver.fr/myNotCreatedDirectory/theFileIWantToPut.ext). Did someone have a tip for me or do I have to parse theURL on my own to do the trick ? Thanks in advance... Stéphane. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[GUMP@brutus]: Project commons-jelly-tags-ant (in module commons-jelly) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-jelly-tags-ant has an issue affecting its community integration. This issue affects 2 projects, and has been outstanding for 4 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-ant : Commons Jelly - commons-jelly-tags-fmt : Commons Jelly Full details are available at: http://brutus.apache.org/gump/public/commons-jelly/commons-jelly-tags-ant/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-jelly-tags-ant-10022005.jar] identifier set to project name -DEBUG- Dependency on ant exists, no need to add for property maven.jar.ant-optional. -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/test-reports -WARNING- No directory [/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/test-reports] -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://brutus.apache.org/gump/public/commons-jelly/commons-jelly-tags-ant/gump_work/build_commons-jelly_commons-jelly-tags-ant.html Work Name: build_commons-jelly_commons-jelly-tags-ant (Type: Build) Work ended in a state of : Failed Elapsed: 5 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant] CLASSPATH: /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-10022005.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-10022005.jar:/usr/local/gump/public/workspace/jakarta-commons-sandbox/grant/target/commons-grant-10022005.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-10022005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-10022005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/util/target/commons-jelly-tags-util-10022005.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-10022005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-10022005.jar - | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.0.2 You are working offline so the build will continue, but commons-jelly-SNAPSHOT.jar may be out of date! build:start: java:prepare-filesystem: [mkdir] Created dir: /home/gump/workspaces2/public/workspace/commons-jelly/jelly-tags/ant/target/classes java:compile: [echo] Compiling to /home/gump/workspaces2/public/workspace/commons-jelly/jelly-tags/ant/target/classes [echo] == NOTE: Targetting JVM 1.4, classes will not run on earlier JVMs == [javac] Compiling 10 source files to /home/gump/workspaces2/public/workspace/commons-jelly/jelly-tags/ant/target/classes [javac]
Re: cruft in commons
Define doesn't do much... Mvgr, Martin Vic wrote: I am sorry to hurt somone's feelings: I think email doest not do much. Just IMO. Modeler, same. Consider moving them back to sandbox. .V - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r153203 - jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/Context.java
Author: skitching
Date: Thu Feb 10 04:37:52 2005
New Revision: 153203
URL: http://svn.apache.org/viewcvs?view=revrev=153203
Log:
* Expanded concept of named stacks into scratch stacks
* Removed trailing whitespace from all lines
Modified:
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/Context.java
Modified:
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/Context.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/Context.java?view=diffr1=153202r2=153203
==
---
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/Context.java
(original)
+++
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/Context.java
Thu Feb 10 04:37:52 2005
@@ -48,26 +48,90 @@
public class Context {
-// ---
+// ---
// Local classes
// ---
-
+
/**
-* See method [EMAIL PROTECTED] #putInstanceData}.
+ * The context provides scratch stacks that any other object with
+ * access to the context can use for storing data; instances of this
+ * class are used to identify which scratch stack is to be used when
+ * using those push/pop/peek/isEmpty methods that take a StackId parameter.
+ * p
+ * An object of class Foo which wishes to store data on a private scratch
+ * stack for its own use should declare a StackId member variable then
+ * later reference it:
+ * pre
+ *private final Context.StackId WIDGET_STACK
+ * = new Context.StackId(Foo.class, WidgetStack, this);
+ *
+ *context.push(WIDGET_STACK, someObject);
+ *
+ *Object savedObject = context.pop(WIDGET_STACK);
+ * /pre
+ * p
+ * If an class Bar wishes to share a scratch stack across all instances of
+ * itself, then it should declare a static StackId:
+ * pre
+ *private static final Context.StackId GADGET_STACK
+ * = new Context.StackId(Bar.class, GadgetStack);
+ * /pre
+ * p
+ * If a class wishes to share a scratch stack with objects that are not of
+ * the same class, then it can follow the above example but declare access
+ * to be protected or public. Other classes can then access it via:
+ * pre
+ * context.push(Bar.GADGET_STACK, someObject);
+ * /pre
+ * p
+ * The parameters to StackId are actually only used in debugging but
+ * the above conventions should be followed for consistency.
*/
+public static class StackId {
+private String desc;
+
+/**
+ * Create an instance which has no specific owner object.
+ */
+public StackId(Class sourceClass, String desc) {
+this.desc = sourceClass.getName() + : + desc;
+}
+
+/**
+ * Create an instance which has an owner object.
+ */
+public StackId(Class sourceClass, String desc, Object owner) {
+this.desc = sourceClass.getName() + : + desc
+ + : + System.identityHashCode(owner);
+}
+
+/**
+ * Provides a nice string which shows what class declares this StackId,
+ * what it is intended to be used for (desc) and what specific
+ * instance of the class (if any) the stack is associated with.
+ */
+public String toString() {
+return desc;
+}
+}
+
+ /**
+* See method [EMAIL PROTECTED] #putInstanceData}.
+*/
private static class InstanceItem {
public Object key;
public Map map;
-
+
public InstanceItem(Object key, Map map) {
this.key = key;
this.map = map;
}
}
-// ---
+
+// ---
// Instance Variables
-// ---
+// ---
/**
* The owner of this object.
@@ -101,10 +165,10 @@
private HashMap namespaces = new HashMap();
/**
- * If not null, then calls to the saxHandler's characters, startElement,
- * endElement and processingInstruction methods are forwarded to the
- * specified object. This is intended to allow rules to temporarily
- * take control of the sax events. In particular, this is used by
+ * If not null, then calls to the saxHandler's characters, startElement,
+ * endElement and processingInstruction methods are forwarded to the
+ * specified object. This is intended to allow rules to temporarily
+ * take control
svn commit: r153205 - jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/ContextTestCase.java
Author: skitching
Date: Thu Feb 10 04:38:33 2005
New Revision: 153205
URL: http://svn.apache.org/viewcvs?view=revrev=153205
Log:
* Changes due to named stacks becoming scratch stacks.
Modified:
jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/ContextTestCase.java
Modified:
jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/ContextTestCase.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/ContextTestCase.java?view=diffr1=153204r2=153205
==
---
jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/ContextTestCase.java
(original)
+++
jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/ContextTestCase.java
Thu Feb 10 04:38:33 2005
@@ -332,19 +332,19 @@
/**
- * Test the basic named stack mechanisms.
+ * Test the basic scratch stack mechanisms.
*/
-public void testNamedStackMethods() {
+public void testScratchStackMethods() {
// peek, peek(n), pop, push, isEmpty
SAXHandler saxHandler = new SAXHandler();
Log log = saxHandler.getLogger();
Context context = new Context(saxHandler, log, null);
Object value = null;
-String stack1 = stack1;
-String stack2 = stack2;
+Context.StackId stack1 = new Context.StackId(ContextTestCase.class,
stack1, this);
+Context.StackId stack2 = new Context.StackId(ContextTestCase.class,
stack2, this);
-// Unused named stacks must be empty
+// Unused scratch stacks must be empty
assertTrue(New stack is empty, context.isEmpty(stack1));
// peek on empty stack fails
@@ -395,8 +395,8 @@
}
-/** Tests the push-peek-pop cycle for a named stack */
-public void testNamedStackPushPeekPop() throws Exception
+/** Tests the push-peek-pop cycle for a scratch stack */
+public void testScratchStackPushPeekPop() throws Exception
{
SAXHandler saxHandler = new SAXHandler();
Log log = saxHandler.getLogger();
@@ -404,47 +404,49 @@
Object o1 = new Object();
-String testStackName =
org.apache.commons.digester.tests.testNamedStackPushPeekPop;
-assertTrue(Stack starts empty:, context.isEmpty(testStackName));
-context.push(testStackName, o1);
-
-assertSame(Peeked value:, o1, context.peek(testStackName));
-assertSame(Popped value:, o1, context.pop(testStackName));
-assertTrue(Stack ends empty:, context.isEmpty(testStackName));
+Context.StackId testStack = new Context.StackId(ContextTestCase.class,
stack, this);
+assertTrue(Stack starts empty:, context.isEmpty(testStack));
+context.push(testStack, o1);
+
+assertSame(Peeked value:, o1, context.peek(testStack));
+assertSame(Popped value:, o1, context.pop(testStack));
+assertTrue(Stack ends empty:, context.isEmpty(testStack));
}
/** Tests that values are stored independently */
-public void testNamedIndependence()
+public void testScratchStackIndependence()
{
SAXHandler saxHandler = new SAXHandler();
Log log = saxHandler.getLogger();
Context context = new Context(saxHandler, log, null);
-String testStackOneName =
org.apache.commons.digester.tests.testNamedIndependenceOne;
-String testStackTwoName =
org.apache.commons.digester.tests.testNamedIndependenceTwo;
-context.push(testStackOneName, Tweedledum);
-context.push(testStackTwoName, Tweedledee);
-assertEquals(Popped value one:, Tweedledum,
context.pop(testStackOneName));
-assertEquals(Popped value two:, Tweedledee,
context.pop(testStackTwoName));
+Context.StackId stack1 = new Context.StackId(ContextTestCase.class,
stack1, this);
+Context.StackId stack2 = new Context.StackId(ContextTestCase.class,
stack2, this);
+
+context.push(stack1, Tweedledum);
+context.push(stack2, Tweedledee);
+assertEquals(Popped value one:, Tweedledum, context.pop(stack1));
+assertEquals(Popped value two:, Tweedledee, context.pop(stack2));
}
-/** Tests popping named stack not yet pushed */
-public void testPopNamedStackNotPushed()
+/** Tests popping scratch stack not yet pushed */
+public void testPopScratchStackNotPushed()
{
SAXHandler saxHandler = new SAXHandler();
Log log = saxHandler.getLogger();
Context context = new Context(saxHandler, log, null);
-String testStackName =
org.apache.commons.digester.tests.testPopNamedStackNotPushed;
+Context.StackId testStack = new Context.StackId(ContextTestCase.class,
stack, this);
+
svn commit: r153211 - jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/AbstractAction.java jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/Action.java
Author: skitching Date: Thu Feb 10 04:56:02 2005 New Revision: 153211 URL: http://svn.apache.org/viewcvs?view=revrev=153211 Log: Fix error in javadoc: the body method is always called, even if there isn't any body text. Note that digester1 javadoc gets this wrong too. Modified: jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/AbstractAction.java jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/Action.java Modified: jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/AbstractAction.java URL: http://svn.apache.org/viewcvs/jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/AbstractAction.java?view=diffr1=153210r2=153211 == --- jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/AbstractAction.java (original) +++ jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/AbstractAction.java Thu Feb 10 04:56:02 2005 @@ -92,8 +92,8 @@ /** * This method is called when the body of a matching XML element is - * encountered. If the element has no body, this method is not called at - * all. + * encountered. If the element has no body, this method is called with + * an empty string as the body text. * p * Note that if the element has multiple pieces of body text separated by * child elements (ie is mixed content) then all the text is merged Modified: jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/Action.java URL: http://svn.apache.org/viewcvs/jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/Action.java?view=diffr1=153210r2=153211 == --- jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/Action.java (original) +++ jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/Action.java Thu Feb 10 04:56:02 2005 @@ -106,8 +106,8 @@ /** * This method is called when the body of a matching XML element is - * encountered. If the element has no body, this method is not called at - * all. + * encountered. If the element has no body, this method is called with + * an empty string as the body text. * p * Note that if the element has multiple pieces of body text separated by * child elements (ie is mixed content) then all the text is merged - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r153212 - jakarta/commons/proper/digester/trunk/src/java/org/apache/commons/digester/Rule.java
Author: skitching Date: Thu Feb 10 04:58:31 2005 New Revision: 153212 URL: http://svn.apache.org/viewcvs?view=revrev=153212 Log: Fix javadoc error: the body method is always called even if there is no body text in an element. Modified: jakarta/commons/proper/digester/trunk/src/java/org/apache/commons/digester/Rule.java Modified: jakarta/commons/proper/digester/trunk/src/java/org/apache/commons/digester/Rule.java URL: http://svn.apache.org/viewcvs/jakarta/commons/proper/digester/trunk/src/java/org/apache/commons/digester/Rule.java?view=diffr1=153211r2=153212 == --- jakarta/commons/proper/digester/trunk/src/java/org/apache/commons/digester/Rule.java (original) +++ jakarta/commons/proper/digester/trunk/src/java/org/apache/commons/digester/Rule.java Thu Feb 10 04:58:31 2005 @@ -1,4 +1,4 @@ -/* $Id: Rule.java,v 1.15 2004/05/10 06:30:06 skitching Exp $ +/* $Id$ * * Copyright 2001-2004 The Apache Software Foundation. * @@ -157,7 +157,7 @@ /** * This method is called when the body of a matching XML element * is encountered. If the element has no body, this method is - * not called at all. + * called with an empty string as the body text. * * @param text The text of the body of this element * @deprecated Use the [EMAIL PROTECTED] #body(String,String,String) body} method @@ -173,8 +173,10 @@ /** * This method is called when the body of a matching XML element is - * encountered. If the element has no body, this method is not called at - * all. The default implementation delegates to the deprecated method + * encountered. If the element has no body, this method is + * called with an empty string as the body text. + * p + * The default implementation delegates to the deprecated method * [EMAIL PROTECTED] #body(String) body} without the codenamespace/code and * codename/code parameters, to retain backwards compatibility. * - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33475] - [configuration] [PATCH] ClassNotFoundException on Sun App Server
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=33475. 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=33475 --- Additional Comments From [EMAIL PROTECTED] 2005-02-10 13:59 --- Mike, I am a bit reluctant about this patch because I am unsure whether it has any undesired side effects. Did you check if all unit tests run with your modification? Did you evaluate other options to solve your problem, e.g. including the correct version of digester in your ear and setting the classpath property in the manifest of your ejb-jars? 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]
svn commit: r153213 - jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/SAXHandler.java
Author: skitching
Date: Thu Feb 10 05:00:25 2005
New Revision: 153213
URL: http://svn.apache.org/viewcvs?view=revrev=153213
Log:
Apply substitutor to bodySegment text as well as body text.
Modified:
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/SAXHandler.java
Modified:
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/SAXHandler.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/SAXHandler.java?view=diffr1=153212r2=153213
==
---
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
Thu Feb 10 05:00:25 2005
@@ -704,6 +704,12 @@
StringBuffer currTextSegment = context.getBodyTextSegment();
if (currTextSegment.length() 0) {
String segment = currTextSegment.toString();
+
+Substitutor substitutor = getSubstitutor();
+if (substitutor != null) {
+segment = substitutor.substitute(segment);
+}
+
List parentMatches = (List) context.peekMatchingActions();
int len = parentMatches.size();
for(int i=0; ilen; ++i) {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r153215 - jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/SAXHandler.java
Author: skitching
Date: Thu Feb 10 05:00:58 2005
New Revision: 153215
URL: http://svn.apache.org/viewcvs?view=revrev=153215
Log:
Just removed trailing whitespace from lines
Modified:
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/SAXHandler.java
Modified:
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/SAXHandler.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/SAXHandler.java?view=diffr1=153214r2=153215
==
---
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
Thu Feb 10 05:00:58 2005
@@ -91,9 +91,9 @@
public class SAXHandler extends DefaultHandler implements LexicalHandler {
-// ---
+// ---
// Instance Variables
-// ---
+// ---
/**
* The EntityResolver used to look up any external entities referenced
@@ -119,7 +119,7 @@
* However it seems likely that a count could be useful at some time.
*/
private int numEntitiesResolved = 0;
-
+
/**
* A map of known external entities that input xml documents may refer to.
* via public or system IDs. The keys of the map entries are public or
@@ -139,7 +139,7 @@
* See setIgnoreExternalDTD.
*/
private boolean ignoreExternalDTD = false;
-
+
/**
* An object which contains state information that evolves
* as the parse progresses. Rule object commonly interact with
@@ -227,9 +227,9 @@
*/
private String dtdSystemId = null;
-// -
+// -
// Constructors
-// -
+// -
/**
* Construct a new SAXHandler.
@@ -609,20 +609,20 @@
public void setAllowUnknownExternalEntities(boolean state) {
allowUnknownExternalEntities = state;
}
-
+
/**
* See setAllowUnknownExternalEntities.
*/
public boolean getAllowUnknownExternalEntities() {
return allowUnknownExternalEntities;
}
-
+
/**
* Specify whether an external DTD should be ignored, ie treated as if
* it were an empty file. This can be dangerous; DTDs can potentially
* contain definitions for default attribute values and entities that
* affect the meaning of the xml document, so skipping them can cause
- * incorrect output. However in many cases it is known that the DTD
+ * incorrect output. However in many cases it is known that the DTD
* does no such thing, so processing of it can be suppressed.
* p
* This flag defaults to false (ie external dtds are read during the
parse).
@@ -630,14 +630,14 @@
public void setIgnoreExternalDTD(boolean state) {
ignoreExternalDTD = state;
}
-
+
/**
* See setIgnoreExternalDTD.
*/
public boolean getIgnoreExternalDTD() {
return ignoreExternalDTD;
}
-
+
/**
* Add a (pattern, action) pair to the RuleManager instance associated
* with this saxHandler. This is equivalent to
@@ -699,7 +699,7 @@
* segment of text from the xml element body.
*/
private void handleBodySegment(
-Context context,
+Context context,
String namespace, String name) throws SAXException {
StringBuffer currTextSegment = context.getBodyTextSegment();
if (currTextSegment.length() 0) {
@@ -876,7 +876,7 @@
if (saxLog.isDebugEnabled()) {
saxLog.debug(endPrefixMapping( + prefix + ));
}
-
+
context.popNamespace(prefix);
}
@@ -1030,7 +1030,7 @@
handleBodySegment(context, parentNamespaceURI, parentLocalName);
context.clearBodyTextSegment();
}
-
+
// Save the body text accumulated for our surrounding element
context.pushBodyText();
@@ -1275,18 +1275,18 @@
// care whether this is zero or one, so a boolean could do as well.
// However it seems likely that a count could be useful at some time.
++numEntitiesResolved;
-
+
// Is this the DTD? If there *is* a DTD (ie one was reported to the
// lexical handler) then it is presumed here that it will be the first
// entity resolved.
//
// Note that we can't just check whether this
concurrency and starting a synchronized block
Guys, forgive me if this too off topic...
...but I thought it is somehow related to
collections that's why I am bringing it up
here anyway. I bet someone of you will know
Consider this code...
Object o = map.get(key);
if (o == null) {
synchronized(map) {
map.put(key,new Object());
}
}
99% of the time the gets on the map are going
to return an object. That's why I would like
to avoid synchronizing the get access.
Now since a put might corrupt the data it
has to be synchronized.
Since the get, the comparison and the put
are not in a synchronized block I might loose
objects ...but for this particular usecase
that's ok.
Now what really got me thinking is the
concurrent sychronized and non-synchronized
access.
What happens when Thread A is in doing a
get while Thread B is entering the
sychronized block for the put?
I assume that since the map object is not
locked it will go straight into the put
and bang ...right?
Somehow this looks like the optimal usecase
for the FastHashMap from collections ...but
since this code needs to be very portable
this might be a problem because of the
double-checked locking idiom.
Another option would be using the StaticBucketMap.
What do you guys think?
If you consider this too OT please reply off list.
cheers
--
Torsten
signature.asc
Description: OpenPGP digital signature
svn commit: r153223 - jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/actions/BeanPropertySetterAction.java
Author: skitching
Date: Thu Feb 10 05:20:26 2005
New Revision: 153223
URL: http://svn.apache.org/viewcvs?view=revrev=153223
Log:
Major rework.
Modified:
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/actions/BeanPropertySetterAction.java
(contents, props changed)
Modified:
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/actions/BeanPropertySetterAction.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/actions/BeanPropertySetterAction.java?view=diffr1=153222r2=153223
==
---
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/actions/BeanPropertySetterAction.java
(original)
+++
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/actions/BeanPropertySetterAction.java
Thu Feb 10 05:20:26 2005
@@ -1,6 +1,6 @@
-/* $Id: ActionBeanPropertySetter.java,v 1.20 2004/05/10 06:30:06 skitching Exp
$
+/* $Id$
*
- * Copyright 2001-2004 The Apache Software Foundation.
+ * Copyright 2001-2005 The Apache Software Foundation.
*
* Licensed under the Apache License, Version 2.0 (the License);
* you may not use this file except in compliance with the License.
@@ -32,53 +32,64 @@
import org.apache.commons.digester2.ParseException;
/**
- * p Action which sets a bean property on the top object to the body
text./p
- *
- * p The property set:/p
- * ullican be specified when the rule is created/li
- * lior can match the current element when the rule is called./li/ul
- *
- * p Using the second method and the [EMAIL PROTECTED] ExtendedRuleManager}
child match
- * pattern, all the child elements can be automatically mapped to properties
- * on the parent object./p
+ * An Action which sets a property on the object on the top of the
+ * digester object stack to the body text from the matched element.
+ * p
+ * The name of the property to set:
+ * ul
+ * lican be specified when the action is created, or/li
+ * lican be the name of the matched xml element (useful when the Action is
+ * used with a pattern that can match multiple elements)./li
+ * /ul
+ * p
+ * The text contained in the xml element has all leading and trailing
+ * whitespace removed from it before the property setter method is invoked
+ * on the target object.
*/
public class BeanPropertySetterAction extends AbstractAction {
-// --- Constructors
+// - Instance Variables
/**
- * pConstruct instance that sets the given property from the body
text./p
- *
- * @param propertyName name of property to set
+ * Set this property on the top object.
*/
-public BeanPropertySetterAction(String propertyName) {
-this.propertyName = propertyName;
-}
+protected String propertyName = null;
/**
- * pConstruct instance that automatically sets a property from the body
text.
- *
- * p This construct creates an action that sets the property
- * on the top object named the same as the current element.
+ * The identifier of the context scratch stack used to store the
+ * body text passed to the body method, so that it can be used in
+ * the end method. This stack is per-action-instance, so that other
+ * instances of this class can't ever interfere with the data on this
+ * stack.
+ */
+protected final Context.StackId BODY_TEXT_STACK =
+new Context.StackId(BeanPropertySetterAction.class, bodytext, this);
+
+// ---
+// Constructors
+// ---
+
+/**
+ * Construct an instance that uses the xml element name to determine
+ * which property to set on the target object.
*/
public BeanPropertySetterAction() {
this((String)null);
}
-// - Instance Variables
-
-/**
- * Set this property on the top object.
- */
-protected String propertyName = null;
-
/**
- * The body text used to set the property.
+ * Construct an instance that sets the given property.
+ *
+ * @param propertyName name of property to set
*/
-protected String bodyText = null;
+public BeanPropertySetterAction(String propertyName) {
+this.propertyName = propertyName;
+}
-// - Public Methods
+// -
+// Public Methods
+// -
/**
* Process the body text of this element.
@@ -100,7 +111,7 @@
RE: concurrency and starting a synchronized block
Torsten Curdt wrote on Thursday, February 10, 2005 2:07 PM:
Guys, forgive me if this too off topic...
...but I thought it is somehow related to
collections that's why I am bringing it up
here anyway. I bet someone of you will know
Consider this code...
Object o = map.get(key);
if (o == null) {
synchronized(map) {
map.put(key,new Object());
}
}
99% of the time the gets on the map are going
to return an object. That's why I would like
to avoid synchronizing the get access.
Now since a put might corrupt the data it
has to be synchronized.
then get() twice:
Object o = map.get(key);
if (o == null) {
synchronized(map) {
o = map.get(key);
if (o == null) {
map.put(key,new Object());
}
}
}
since 99% of the time it will not enter the block, the second lookup does not
matter ...
Regards,
Jörg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: concurrency and starting a synchronized block
On Feb 10, 2005, at 8:20 AM, Jörg Schaible wrote:
en get() twice:
Object o = map.get(key);
if (o == null) {
synchronized(map) {
o = map.get(key);
if (o == null) {
map.put(key,new Object());
}
}
}
since 99% of the time it will not enter the block, the second lookup
does not matter ...
Is that still enough to not be double-checked locking (which is broken
in java..)
http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html
-pete
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: concurrency and starting a synchronized block
On Thu, 2005-02-10 at 14:20 +0100, Jörg Schaible wrote:
Torsten Curdt wrote on Thursday, February 10, 2005 2:07 PM:
Guys, forgive me if this too off topic...
I think this list is a perfectly good place to ask this sort of thing..
...but I thought it is somehow related to
collections that's why I am bringing it up
here anyway. I bet someone of you will know
Consider this code...
Object o = map.get(key);
if (o == null) {
synchronized(map) {
map.put(key,new Object());
}
}
99% of the time the gets on the map are going
to return an object. That's why I would like
to avoid synchronizing the get access.
Now since a put might corrupt the data it
has to be synchronized.
then get() twice:
Object o = map.get(key);
if (o == null) {
synchronized(map) {
o = map.get(key);
if (o == null) {
map.put(key,new Object());
}
}
}
since 99% of the time it will not enter the block, the second lookup does not
matter ...
Regards,
Jörg
Well, I personally would be very reluctant to adopt this kind of
solution.
Firstly, I believe that if you never synchronise on the get, then there
is no guarantee the reading thread will ever see data put into the map
by other threads. Having a synchronize around the get forces the cpu to
synchronise its cache or some-such.
And secondly, I believe there are many other traps out there for code
that tries to play tricks with synchronization.
Synchronisation is a fiendishly difficult subject, involving CPU cache
coherence mechanisms, etc., and there are many traps to fall into. Many
of these are described in the articles about why double checked
locking is broken.
I think someone mentioned just a week or two ago on this list that Doug
Lea's concurrency library is available under a BSD-ish license. If
that's the case, I would look there for a fast hashmap implementation
first...
Cheers,
Simon
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: concurrency and starting a synchronized block
Consider this code...
Object o = map.get(key);
if (o == null) {
synchronized(map) {
map.put(key,new Object());
}
}
99% of the time the gets on the map are going
to return an object. That's why I would like
to avoid synchronizing the get access.
Now since a put might corrupt the data it
has to be synchronized.
then get() twice:
snip/
since 99% of the time it will not enter the block, the second lookup does not matter ...
that's true ...but that's not the problem :)
as I said: I don't mind if I loose an instance
but the problem is that the get is not
synchronized while the put is.
So I asssume that the get is not checking
for a lock on the map object which means
that a concurrent get and put might clash.
The above code would only be safe for two
concurrent put calls.
...at least that's what I assume
cheers
--
Torsten
signature.asc
Description: OpenPGP digital signature
DO NOT REPLY [Bug 33475] - [configuration] [PATCH] ClassNotFoundException on Sun App Server
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=33475. 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=33475 --- Additional Comments From [EMAIL PROTECTED] 2005-02-10 15:30 --- Hi Oliver, I ran the unit tests with and without the patch; TestXMLConfiguration failed in the same way both times at testLoad. So, I'm unable to tell at this time if the patch affects the unit tests. This is using code from CVS. Regarding other options, I'm open to alternatives. I am already packaging the correct jars in the EAR and setting the classpath in the ejb-jar manifest. This doesn't solve the problem, though, due to the classloader delegation model. Since Digester is already loaded by the System classloader, it will not be loaded by any child classloaders, such as the EJB classloader. Again, I'm using code from CVS. Does this make any difference? I'm a little confused about whether to use CVS or SVN here. CVS doesn't look seem as up to date. -- 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: concurrency and starting a synchronized block
A call to Map.get() may depend on state that can be corrupted by a
concurrent call to Map.put(). You don't know without learning the
implementation details of get(). So, you need to synchronize around both
operations:
synchronized(map) {
Object o = map.get(key);
if (o == null) {
map.put(key,new Object());
}
}
Have you identified this one synchronized block as a bottleneck in your
application with performance testing? If not, then why are you worrying
about making micro optimizations that may or may not benefit the
application?
FastHashMap states it is not portable in its javadoc so it should never be
used. Using non-portable classes defeats the entire purpose of using
Java.
David
--- Torsten Curdt [EMAIL PROTECTED] wrote:
Guys, forgive me if this too off topic...
...but I thought it is somehow related to
collections that's why I am bringing it up
here anyway. I bet someone of you will know
Consider this code...
Object o = map.get(key);
if (o == null) {
synchronized(map) {
map.put(key,new Object());
}
}
99% of the time the gets on the map are going
to return an object. That's why I would like
to avoid synchronizing the get access.
Now since a put might corrupt the data it
has to be synchronized.
Since the get, the comparison and the put
are not in a synchronized block I might loose
objects ...but for this particular usecase
that's ok.
Now what really got me thinking is the
concurrent sychronized and non-synchronized
access.
What happens when Thread A is in doing a
get while Thread B is entering the
sychronized block for the put?
I assume that since the map object is not
locked it will go straight into the put
and bang ...right?
Somehow this looks like the optimal usecase
for the FastHashMap from collections ...but
since this code needs to be very portable
this might be a problem because of the
double-checked locking idiom.
Another option would be using the StaticBucketMap.
What do you guys think?
If you consider this too OT please reply off list.
cheers
--
Torsten
ATTACHMENT part 2 application/pgp-signature name=signature.asc
__
Do you Yahoo!?
The all-new My Yahoo! - Get yours free!
http://my.yahoo.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[commons-email] fix nightly build
Hi all, Can someone fix builds/jakarta-commons/nightly/commons-email/ so that the binary builds are working again? Thanks, Pander - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33475] - [configuration] [PATCH] ClassNotFoundException on Sun App Server
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=33475. 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=33475 --- Additional Comments From [EMAIL PROTECTED] 2005-02-10 15:44 --- Mike, we (the whole jakarta commons) switched from CVS to SVN recently. There have been minor changes in the meantime (especially in the build.xml), thats probably the reason why the unit tests fail. You can checkout the newest version of configuration using svn checkout http://svn.apache.org/repos/asf/jakarta/commons/proper/configuration/trunk 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]
DO NOT REPLY [Bug 33475] - [configuration] ClassNotFoundException on Sun App Server
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=33475. 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=33475 [EMAIL PROTECTED] changed: What|Removed |Added Keywords||PatchAvailable Summary|[configuration] [PATCH] |[configuration] |ClassNotFoundException on |ClassNotFoundException on |Sun App Server |Sun App Server --- Additional Comments From [EMAIL PROTECTED] 2005-02-10 15:48 --- The code has been migrated to SVN recently, you can ignore the code in CVS. I'm +1 for the change suggested by Mike, I haven't tested it but it makes sense. If this issue comes back later we can easily add a way to configure the classloader used by the ConfigurationFactory. -- 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 33475] - [configuration] ClassNotFoundException on Sun App Server
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=33475. 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=33475 --- Additional Comments From [EMAIL PROTECTED] 2005-02-10 15:57 --- If the unit tests run, I am fine as well. I was wondering if it makes sense to get rid off digester as a core dependency anyway. The XML files processed by configuration factory are quite simple and digester does not earn us that much. I think parsing these files by hand using SAX would not be too complicated. 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: [VOTE][configuration]Release 1.1
Hi all, we need another +1 to get our release out. Nobody? Oliver Oliver Heger wrote: Dear community, since the 1.0 release of [configuration] a couple of new features have been added. The code base has been stable for a while now, so I think it is time to cut out a new 1.1 release before we start to implement further features and refactorings. A complete list of changes since the 1.0 releaes can be found here: http://jakarta.apache.org/commons/configuration/changes-report.html I have created a release candidate, which can be inspected at http://www.apache.org/~oheger/commons-configuration-1.1rc1/ (the tag for 1.1RC1 is named CONFIGURATION_1_1RC1). Here is my +1! Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33475] - [configuration] ClassNotFoundException on Sun App Server
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=33475. 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=33475 --- Additional Comments From [EMAIL PROTECTED] 2005-02-10 16:20 --- Well why not, but that may prevent us from doing more complex things with ConfigurationFactory in the future. Digester is also used by XMLPropertiesConfiguration, a simple SAX parser would be good enough there. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE][configuration]Release 1.1
I'm actually -1 for the release, I dropped the 1.1rc1 jar in my application yesterday and it broke with an exception related to the configuration reloading stuff. This may be linked to the issue reported by Jurgen Schlierf on the commons-user list. I'd like to investigate this bug before releasing the final 1.1. Emmanuel Bourg Oliver Heger wrote: Hi all, we need another +1 to get our release out. Nobody? Oliver Oliver Heger wrote: Dear community, since the 1.0 release of [configuration] a couple of new features have been added. The code base has been stable for a while now, so I think it is time to cut out a new 1.1 release before we start to implement further features and refactorings. A complete list of changes since the 1.0 releaes can be found here: http://jakarta.apache.org/commons/configuration/changes-report.html I have created a release candidate, which can be inspected at http://www.apache.org/~oheger/commons-configuration-1.1rc1/ (the tag for 1.1RC1 is named CONFIGURATION_1_1RC1). Here is my +1! Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VFS] Asking for a solution with Zip files
Hello! I am on vacation this week, and only a very poor internet connection. If no one else solved your problem in the meantime I will have a look at it start next week. (And all the other stuff collected this week in the mailinglist. Its odd, all the time this list is so silent and if I am on vacation there starts a mailstorm) --- Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: concurrency and starting a synchronized block
This is the save and obvious solution - I agree. But I thought Torsten
wanted something less restrictive where there could be any number of
concurrent reads, but only a single write that also does not allow for
any concurrent reads. This is exactly what a read/write lock does and
is available from Doug Lea's package.
Oliver
P.S.: It is also avaliable from commons transaction, but if you only
want a read/write lock Doug's stuff for sure is more suitable.
On Thu, 10 Feb 2005 06:33:04 -0800 (PST), David Graham
[EMAIL PROTECTED] wrote:
A call to Map.get() may depend on state that can be corrupted by a
concurrent call to Map.put(). You don't know without learning the
implementation details of get(). So, you need to synchronize around both
operations:
synchronized(map) {
Object o = map.get(key);
if (o == null) {
map.put(key,new Object());
}
}
Have you identified this one synchronized block as a bottleneck in your
application with performance testing? If not, then why are you worrying
about making micro optimizations that may or may not benefit the
application?
FastHashMap states it is not portable in its javadoc so it should never be
used. Using non-portable classes defeats the entire purpose of using
Java.
David
--- Torsten Curdt [EMAIL PROTECTED] wrote:
Guys, forgive me if this too off topic...
...but I thought it is somehow related to
collections that's why I am bringing it up
here anyway. I bet someone of you will know
Consider this code...
Object o = map.get(key);
if (o == null) {
synchronized(map) {
map.put(key,new Object());
}
}
99% of the time the gets on the map are going
to return an object. That's why I would like
to avoid synchronizing the get access.
Now since a put might corrupt the data it
has to be synchronized.
Since the get, the comparison and the put
are not in a synchronized block I might loose
objects ...but for this particular usecase
that's ok.
Now what really got me thinking is the
concurrent sychronized and non-synchronized
access.
What happens when Thread A is in doing a
get while Thread B is entering the
sychronized block for the put?
I assume that since the map object is not
locked it will go straight into the put
and bang ...right?
Somehow this looks like the optimal usecase
for the FastHashMap from collections ...but
since this code needs to be very portable
this might be a problem because of the
double-checked locking idiom.
Another option would be using the StaticBucketMap.
What do you guys think?
If you consider this too OT please reply off list.
cheers
--
Torsten
ATTACHMENT part 2 application/pgp-signature name=signature.asc
__
Do you Yahoo!?
The all-new My Yahoo! - Get yours free!
http://my.yahoo.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE : [VFS] Asking for a solution with Zip files
If no one else solved your problem in the meantime I will have a look at it start next week. -- Thanks a lot. I admit that I'm a bit lost in the code... (but I'm a beginner with VFS). For what I've seen, It's a hard coded test which throw an exception when the file doesn't exist. I think it's necessary for the following code but I can't manage to see where and how... (And all the other stuff collected this week in the mailinglist. Its odd, all the time this list is so silent and if I am on vacation there starts a mailstorm) -- Oh I see...You've been introduced to Mr. Murphy too :-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Feedparser exception
Steven Leija wrote: Hey Kevin, I'm working on integrating feed parser with AppFuse and getting the following exception. Is this simple cause the classloader is perhaps loading a different version of jaxen? Yeah.. Thats exactly your issue. We want to move to the latest Jaxen but i'm waiting for 1.0 to do this. (which won't be that long). Just use the one thats in SVN right now. Kevin -- Use Rojo (RSS/Atom aggregator). Visit http://rojo.com. Ask me for an invite! Also see irc.freenode.net #rojo if you want to chat. Rojo is Hiring! - http://www.rojonetworks.com/JobsAtRojo.html If you're interested in RSS, Weblogs, Social Networking, etc... then you should work for Rojo! If you recommend someone and we hire them you'll get a free iPod! Kevin A. Burton, Location - San Francisco, CA AIM/YIM - sfburtonator, Web - http://peerfear.org/ GPG fingerprint: 5FB2 F3E2 760E 70A8 6174 D393 E84D 8D04 99F1 4412 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [commons-email] fix nightly build
On Thu, 10 Feb 2005 15:29:17 +0100, Pander [EMAIL PROTECTED] wrote: Hi all, Can someone fix builds/jakarta-commons/nightly/commons-email/ so that the binary builds are working again? FWIW, the compile part works fine, but the unit tests fail. Here's the output of ant dist. It's going to take one of email's developers to tell us what's going on, and/or how to configure my system (on which the nightly builds are executed) to correctly execute the unit tests. Craig Buildfile: build.xml init: get-deps: [get] Getting: http://www.ibiblio.org/maven/commons-lang/jars/commons-lang-2.0.jar [get] Not modified - so not downloaded [get] Getting: file:/usr/local/javamail-1.3.2/lib/mailapi.jar [get] Getting: file:/usr/local/jaf-1.0.2/activation.jar [get] Getting: http://www.ibiblio.org/maven/dumbster/jars/dumbster-1.5.jar [get] Not modified - so not downloaded compile: [mkdir] Created dir: /home/craigmcc/Build/jakarta/commons/trunks-proper/email/target/classes [javac] Compiling 8 source files to /home/craigmcc/Build/jakarta/commons/trunks-proper/email/target/classes junit-present: compile-tests: [mkdir] Created dir: /home/craigmcc/Build/jakarta/commons/trunks-proper/email/target/test-classes [javac] Compiling 13 source files to /home/craigmcc/Build/jakarta/commons/trunks-proper/email/target/test-classes internal-test: [mkdir] Created dir: /home/craigmcc/Build/jakarta/commons/trunks-proper/email/target/test-reports [junit] Running org.apache.commons.mail.DefaultAuthenticatorTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.73 sec [junit] Testsuite: org.apache.commons.mail.DefaultAuthenticatorTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.73 sec [junit] Testcase: testDefaultAuthenticatorConstructor took 0.693 sec [junit] Running org.apache.commons.mail.EmailAttachmentTest [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.561 sec [junit] Testsuite: org.apache.commons.mail.EmailAttachmentTest [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.561 sec [junit] Testcase: testGetSetDescription took 0.012 sec [junit] Testcase: testGetSetName took 0 sec [junit] Testcase: testGetSetPath took 0 sec [junit] Testcase: testGetSetURL took 0.417 sec [junit] Testcase: testGetSetDisposition took 0 sec [junit] Running org.apache.commons.mail.EmailTest [junit] Tests run: 36, Failures: 2, Errors: 0, Time elapsed: 1.683 sec [junit] Testsuite: org.apache.commons.mail.EmailTest [junit] Tests run: 36, Failures: 2, Errors: 0, Time elapsed: 1.683 sec [junit] Testcase: testGetSetDebug took 0.141 sec [junit] Testcase: testGetSetSession took 0.059 sec [junit] Testcase: testGetSetAuthentication took 0.003 sec [junit] Testcase: testGetSetAuthenticator took 0 sec [junit] Testcase: testGetSetCharset took 0 sec [junit] Testcase: testSetContentMimeMultipart took 0.269 sec [junit] Testcase: testSetContentObject took 0.113 sec [junit] Testcase: testGetSetHostName took 0.007 sec [junit] Testcase: testGetSetSmtpPort took 0.002 sec [junit] Testcase: testSetFrom took 0.008 sec [junit] Testcase: testSetFromWithEnconding took 0.001 sec [junit] Testcase: testSetFrom2 took 0.031 sec [junit] Testcase: testAddTo took 0.001 sec [junit] Testcase: testAddToWithEncoding took 0 sec [junit] Testcase: testAddTo2 took 0.003 sec [junit] Testcase: testSetTo took 0.001 sec [junit] Testcase: testAddCc took 0.001 sec [junit] Testcase: testAddCcWithEncoding took 0 sec [junit] Testcase: testAddCc2 took 0.006 sec [junit] Testcase: testSetCc took 0.001 sec [junit] Testcase: testAddBcc took 0.001 sec [junit] Testcase: testAddBccWithEncoding took 0 sec [junit] Testcase: testAddBcc2 took 0.011 sec [junit] Testcase: testSetBcc took 0.002 sec [junit] Testcase: testAddReplyTo took 0 sec [junit] Testcase: testAddReplyToWithEncoding took 0 sec [junit] Testcase: testAddReplyTo2 took 0.007 sec [junit] Testcase: testAddHeader took 0.003 sec [junit] Testcase: testAddHeaderEx took 0 sec [junit] Testcase: testSetHeaders took 0.001 sec [junit] Testcase: testSetHeadersEx took 0 sec [junit] Testcase: testSetSubject took 0 sec [junit] Testcase: testSendEx took 0.842 sec [junit] FAILED [junit] Mail server failed to start [junit] junit.framework.AssertionFailedError: Mail server failed to start [junit] at org.apache.commons.mail.BaseEmailTestCase.getMailServer(BaseEmailTestCase.java:179) [junit] at org.apache.commons.mail.EmailTest.testSendEx(EmailTest.java:1440) [junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [junit] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [junit] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
Re:
snip On Thu, 10 Feb 2005 00:36:34 -0800, Craig McClanahan [EMAIL PROTECTED] wrote: Vic, the fact that *you* may not find a particular package useful has nothing to do with what other people might think :-). Craig /snip http://www.jccmi.edu/InfoTech/Training/EmailEtiquette.html Flaming is a net tradition but has no place in professional communications. Flaming is expressing a strong opinion without emotion held back. Tact and courtesy are not objectives. In other words, really stupid things get said. If you encounter a flame war on a public conference, do your part to get it under control before the administration has to step in. Flame wars do nothing except take up bandwidth, waste managerial and administrative time and, of course, give us proof that the human race still has some important evolution to complete. -- You can lead a horse to water but you cannot make it float on its back. Heaven has changed. The Sky now goes all the way to our feet. ~Dakota Jack~ This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[digester2] Additions
Folks,
as I noticed Simon has done so much work on Digester2, I just wanted
to be sure that my scheduled additions still are appropriate and
aligned to the overall design. Here they are:
(1) XMLIORuleManager: A rule manager that takes an action and
unconditionally calls it on any event. It's useful to imitate xmlio
style processing, but not limited to this. One application might be
logging. As it is more general any proposal for a better name?
Quoting code sample from Simon:
// xmlio-style digester
Action myHandler = new AbstractAction() {
public void begin(
Context context,
String namespace, String name,
Attributes attrs) {
String path = context.getMatchPath();
if (path.equals(..)) {
} else {
}
}
public void body(...) {
}
}
RuleManager xmlioRuleManager = new XMLIORuleManager(myHandler);
Digester d = new Digester();
d.setRuleManager(xmlioRuleManager);
As an option it might be possible to register an action with any rule
manager that gets called unconditionally - epsecially for logging and
debugging this can be really helpful. However, I wasn't quite sure if
Simon was happy with that.
(2) Next to the body and bodySegment call back methods there might be
one that gives you the complete body of an element as a string
composed of all character and markup data. This might be useful when
you want to verbosely take over formatted mixed content like in XHTML.
For performance reasons there should be some mechanism that tells
digester when such content is needed on an element basis. Maybe
something returned by the begin method or - maybe cleaner - something
returned by an additional call back directly called after begin like
boolean requiresComposedBody(String namespace, String name) or
anything similar. This method could alternatively be part of an
additional or extended interface.
Comments?
Oliver
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: concurrency and starting a synchronized block
I spent a whole bunch of time looking into how various
caches/collections handled this issue when I was designing Whirlycache
[1] and the cleanest solution that is available today, as others have
pointed out, is Doug Lea's util.concurrent package.
The high-level explanation of how Doug Lea's ConcurrentHashMap works is
that it has 32 internal buckets and a fast hashing algorithm. It only
synchronizes internally on the bucket that is being modified, thereby
leaving the other n buckets free to do whatever they need. So you can
conceivably have 32 concurrent threads reading and/or writing depending
on how the hashing algorithm causes the buckets to be synchronized.
It's a lot faster than a java.util.HashMap when you have many threads
reading and writing.
I think the 32 fixed bucket size limit was removed when these classes
were ported to JDK 1.5.
Depending on what you are doing, you basically have 3 choices when
you're dealing with multithreaded access/modification to a collection:
1) don't synchronize and watch failures happen
2) synchronize on the containing object's monitor:
...
public synchronized whatever(Object arg1) {...}
public synchronized something() {...}
...
3) use more granular synch locks, if possible:
...
private Object whatever = new Object();
private Object something = new Object();
public whatever(Object arg1) {
synchronized (whatever) {
...
}
}
public something(Object arg1) {
synchronized (something) {
...
}
}
Making the locks more granular can make a huge difference, but it's only
possible if your particular case will allow for it. But it's definitely
worth investigating rather than blindly using 'synchronized' in method
signatures... which turns out to be not-that-slow anyway.
YMMV.
phil.
[1] http://whirlycache.dev.java.net/
Torsten Curdt wrote:
Guys, forgive me if this too off topic...
...but I thought it is somehow related to
collections that's why I am bringing it up
here anyway. I bet someone of you will know
Consider this code...
Object o = map.get(key);
if (o == null) {
synchronized(map) {
map.put(key,new Object());
}
}
99% of the time the gets on the map are going
to return an object. That's why I would like
to avoid synchronizing the get access.
Now since a put might corrupt the data it
has to be synchronized.
Since the get, the comparison and the put
are not in a synchronized block I might loose
objects ...but for this particular usecase
that's ok.
Now what really got me thinking is the
concurrent sychronized and non-synchronized
access.
What happens when Thread A is in doing a
get while Thread B is entering the
sychronized block for the put?
I assume that since the map object is not
locked it will go straight into the put
and bang ...right?
Somehow this looks like the optimal usecase
for the FastHashMap from collections ...but
since this code needs to be very portable
this might be a problem because of the
double-checked locking idiom.
Another option would be using the StaticBucketMap.
What do you guys think?
If you consider this too OT please reply off list.
cheers
--
Torsten
--
Whirlycott
Philip Jacob
[EMAIL PROTECTED]
http://www.whirlycott.com/phil/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DBCP
Hi, I have one question about DBCP. I like to know if any one have used BasicDataSource.close(). In my program I set up a BasicDataSource and get connection from MYSQL, I call BasicDataSource.close() right after get connection, I still see the connectioin from MYSQL admin. I just wonder this function is working? thanks, Paul
Re: concurrency and starting a synchronized block
On Thu, 10 Feb 2005 13:09:14 -0500, WHIRLYCOTT [EMAIL PROTECTED] wrote:
2) synchronize on the containing object's monitor:
...
public synchronized whatever(Object arg1) {...}
public synchronized something() {...}
...
Blindly doing this can easily lead to deadlocks. Consider thread #1 in
method whatever accesses another synchronized object and needs to wait
for thread #2 to release the lock on it. Now thread #2 tries to access
method something and - of course - needs to wait for thread #1 to
release the lock on that first objec. Now both threads mutually wait
for each other and you have a deadlock.
Oliver
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: DBCP
Calling BasicDataSource.close() will only close the connections still
in the pool -- not the ones that have been checked out. It is
designed to be called only when your app is ready to shut down.
For normal usage, the best approach is something like this:
DataSource ds = ... get your data source reference;
Connection conn = null;
try {
conn = ds.getConnection();
... use the connection as needed ...
conn.close(); // Returns this connection to the pool
} catch (SQLException e) {
... deal with any exception ...
} finally {
if (conn != null) {
try {
conn.close();
} catch (SQLException e) {
...
}
}
}
That way, you're always returning the connection to the pool, even if
an exception occurs while you're using it.
BTW, your MySQL admin will show active connections for all the entries
in the pool, as well as those that have been checked out and are in
use.
Craig
On Thu, 10 Feb 2005 10:14:17 -0800, Paul Hsu [EMAIL PROTECTED] wrote:
Hi,
I have one question about DBCP. I like to know if any one have used
BasicDataSource.close(). In my program I set up a BasicDataSource and get
connection from MYSQL, I call BasicDataSource.close() right after get
connection, I still see the connectioin from MYSQL admin. I just wonder this
function is working?
thanks,
Paul
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: concurrency and starting a synchronized block
Exactly - most books and documentation about resource exclusion about
this make it abundantly clear that synchronized methods shouldn't call
each other for this very reason.
Thanks for adding that point.
phil.
Oliver Zeigermann wrote:
On Thu, 10 Feb 2005 13:09:14 -0500, WHIRLYCOTT [EMAIL PROTECTED] wrote:
2) synchronize on the containing object's monitor:
...
public synchronized whatever(Object arg1) {...}
public synchronized something() {...}
...
Blindly doing this can easily lead to deadlocks. Consider thread #1 in
method whatever accesses another synchronized object and needs to wait
for thread #2 to release the lock on it. Now thread #2 tries to access
method something and - of course - needs to wait for thread #1 to
release the lock on that first objec. Now both threads mutually wait
for each other and you have a deadlock.
Oliver
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Whirlycott
Philip Jacob
[EMAIL PROTECTED]
http://www.whirlycott.com/phil/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: DBCP
I think the first conn.close is unneeded, because the finally block is
always executed.
Bernard
-Original Message-
From: Craig McClanahan [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 10, 2005 7:24 PM
To: Jakarta Commons Developers List
Subject: Re: DBCP
Calling BasicDataSource.close() will only close the connections still in the
pool -- not the ones that have been checked out. It is designed to be
called only when your app is ready to shut down.
For normal usage, the best approach is something like this:
DataSource ds = ... get your data source reference;
Connection conn = null;
try {
conn = ds.getConnection();
... use the connection as needed ...
conn.close(); // Returns this connection to the pool
} catch (SQLException e) {
... deal with any exception ...
} finally {
if (conn != null) {
try {
conn.close();
} catch (SQLException e) {
...
}
}
}
That way, you're always returning the connection to the pool, even if an
exception occurs while you're using it.
BTW, your MySQL admin will show active connections for all the entries in
the pool, as well as those that have been checked out and are in use.
Craig
On Thu, 10 Feb 2005 10:14:17 -0800, Paul Hsu [EMAIL PROTECTED] wrote:
Hi,
I have one question about DBCP. I like to know if any one have used
BasicDataSource.close(). In my program I set up a BasicDataSource and
get connection from MYSQL, I call BasicDataSource.close() right after
get connection, I still see the connectioin from MYSQL admin. I just
wonder this function is working?
thanks,
Paul
-
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: DBCP
True ... old habits die hard :-)
Craig
On Thu, 10 Feb 2005 20:25:57 +0100, Bernard D'Have [EMAIL PROTECTED] wrote:
I think the first conn.close is unneeded, because the finally block is
always executed.
Bernard
-Original Message-
From: Craig McClanahan [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 10, 2005 7:24 PM
To: Jakarta Commons Developers List
Subject: Re: DBCP
Calling BasicDataSource.close() will only close the connections still in the
pool -- not the ones that have been checked out. It is designed to be
called only when your app is ready to shut down.
For normal usage, the best approach is something like this:
DataSource ds = ... get your data source reference;
Connection conn = null;
try {
conn = ds.getConnection();
... use the connection as needed ...
conn.close(); // Returns this connection to the pool
} catch (SQLException e) {
... deal with any exception ...
} finally {
if (conn != null) {
try {
conn.close();
} catch (SQLException e) {
...
}
}
}
That way, you're always returning the connection to the pool, even if an
exception occurs while you're using it.
BTW, your MySQL admin will show active connections for all the entries in
the pool, as well as those that have been checked out and are in use.
Craig
On Thu, 10 Feb 2005 10:14:17 -0800, Paul Hsu [EMAIL PROTECTED] wrote:
Hi,
I have one question about DBCP. I like to know if any one have used
BasicDataSource.close(). In my program I set up a BasicDataSource and
get connection from MYSQL, I call BasicDataSource.close() right after
get connection, I still see the connectioin from MYSQL admin. I just
wonder this function is working?
thanks,
Paul
-
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 33475] - [configuration] ClassNotFoundException on Sun App Server
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=33475. 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=33475 --- Additional Comments From [EMAIL PROTECTED] 2005-02-10 20:38 --- Or even cooler, we could use XMLConfiguration in ConfigurationFactory to parse the definition file. Then we could use the whole Configuration API to access the properties and could do wild things, too. Just a thought, but I enjoy such recursive stuff! -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE][configuration]Release 1.1
Of course, I don't want to force a release out which is not mature. Let's hold it. But I feel a bit disappointed that it seems to be so hard to get the required three +1s. I think we must be careful that we do not lose our momentum :-( Oliver Emmanuel Bourg wrote: I'm actually -1 for the release, I dropped the 1.1rc1 jar in my application yesterday and it broke with an exception related to the configuration reloading stuff. This may be linked to the issue reported by Jurgen Schlierf on the commons-user list. I'd like to investigate this bug before releasing the final 1.1. Emmanuel Bourg Oliver Heger wrote: Hi all, we need another +1 to get our release out. Nobody? Oliver Oliver Heger wrote: Dear community, since the 1.0 release of [configuration] a couple of new features have been added. The code base has been stable for a while now, so I think it is time to cut out a new 1.1 release before we start to implement further features and refactorings. A complete list of changes since the 1.0 releaes can be found here: http://jakarta.apache.org/commons/configuration/changes-report.html I have created a release candidate, which can be inspected at http://www.apache.org/~oheger/commons-configuration-1.1rc1/ (the tag for 1.1RC1 is named CONFIGURATION_1_1RC1). Here is my +1! Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: concurrency and starting a synchronized block
[collections] provides two Map implementations of interest in this
discussion:
FastHashMap - this map copies the whole map internally every timeput is
called. This avoids most of the synchronization issues, and gets are not
synchronized. However, we do not recommend its use because it _may_ not work
on some JVMs (no example of a failure has ever been reported, but...)
StaticBucketMap - this map synchronizes at a very fine grained level (each
bucket). In theory this should mean that the map still works in very very
multi threaded programs. However, bulk operations like putAll don't work as
expected, and in general its slower than a normal HashMap.
My recommendation is to just synchronize
synchronized(map) {
Object o = map.get(key);
if (o == null) {
map.put(key,new Object());
}
}
It is very unlikely that this is your performance bottleneck.
PS. I believe JDK 1.5 has an implementation of Doug Leas special concurrent
hash map
Stephen
From: David Graham [EMAIL PROTECTED]
FastHashMap states it is not portable in its javadoc so it should never be
used. Using non-portable classes defeats the entire purpose of using
Java.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: DBCP
--- Craig McClanahan [EMAIL PROTECTED] wrote:
Calling BasicDataSource.close() will only close the connections still
in the pool -- not the ones that have been checked out. It is
designed to be called only when your app is ready to shut down.
For normal usage, the best approach is something like this:
DataSource ds = ... get your data source reference;
Connection conn = null;
try {
conn = ds.getConnection();
... use the connection as needed ...
conn.close(); // Returns this connection to the pool
} catch (SQLException e) {
... deal with any exception ...
} finally {
if (conn != null) {
try {
conn.close();
} catch (SQLException e) {
...
}
}
}
It's this kind of drudgery that prompted me to volunteer on DbUtils.
Check it out if you're tired of JDBC resource cleanup.
http://jakarta.apache.org/commons/dbutils/
David
That way, you're always returning the connection to the pool, even if
an exception occurs while you're using it.
BTW, your MySQL admin will show active connections for all the entries
in the pool, as well as those that have been checked out and are in
use.
Craig
On Thu, 10 Feb 2005 10:14:17 -0800, Paul Hsu [EMAIL PROTECTED]
wrote:
Hi,
I have one question about DBCP. I like to know if any one have used
BasicDataSource.close(). In my program I set up a BasicDataSource and
get connection from MYSQL, I call BasicDataSource.close() right after
get connection, I still see the connectioin from MYSQL admin. I just
wonder this function is working?
thanks,
Paul
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
__
Do you Yahoo!?
Yahoo! Mail - Easier than ever with enhanced search. Learn more.
http://info.mail.yahoo.com/mail_250
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: concurrency and starting a synchronized block
Torsten Curdt wrote: Guys, forgive me if this too off topic... ...but I thought it is somehow related to collections that's why I am bringing it up here anyway. I bet someone of you will know Ignore what everyone else says on this list topic. ha. Use a ReentrantReadWriteLock from JDK 1.5. There's a backport to JDK 1.4 out on the net. Google for backport concurrent oswego or something Then you can do a lock.readLock().lock() on our gets and then do a writeLock on your puts. the writeLock will backup the readlock but if you only have readlocks they can all happen at once. Normally though its not too big a deal since gets() on a hashtable are O(1) Kevin -- Use Rojo (RSS/Atom aggregator). Visit http://rojo.com. Ask me for an invite! Also see irc.freenode.net #rojo if you want to chat. Rojo is Hiring! - http://www.rojonetworks.com/JobsAtRojo.html If you're interested in RSS, Weblogs, Social Networking, etc... then you should work for Rojo! If you recommend someone and we hire them you'll get a free iPod! Kevin A. Burton, Location - San Francisco, CA AIM/YIM - sfburtonator, Web - http://peerfear.org/ GPG fingerprint: 5FB2 F3E2 760E 70A8 6174 D393 E84D 8D04 99F1 4412 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: concurrency and starting a synchronized block
I guess this thread should end soon, but while we're still having some fun ... ;) ConcurrentHashMap can do concurrent put() operations and concurrent get() operations... and that's the tricky part. I just love all that stuff that Doug Lea has done. For those who haven't looked at util.concurrent, I recommend it. Sounds like others do as well. phil. Kevin A. Burton wrote: Torsten Curdt wrote: Guys, forgive me if this too off topic... ...but I thought it is somehow related to collections that's why I am bringing it up here anyway. I bet someone of you will know Ignore what everyone else says on this list topic. ha. Use a ReentrantReadWriteLock from JDK 1.5. There's a backport to JDK 1.4 out on the net. Google for backport concurrent oswego or something Then you can do a lock.readLock().lock() on our gets and then do a writeLock on your puts. the writeLock will backup the readlock but if you only have readlocks they can all happen at once. Normally though its not too big a deal since gets() on a hashtable are O(1) Kevin -- Whirlycott Philip Jacob [EMAIL PROTECTED] http://www.whirlycott.com/phil/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r153296 - in jakarta/commons/proper/logging/trunk: build.xml optional/build.xml optional/project.xml project.xml xdocs/index.xml
Author: rdonkin
Date: Thu Feb 10 13:57:11 2005
New Revision: 153296
URL: http://svn.apache.org/viewcvs?view=revrev=153296
Log:
Updated HEAD version.
Modified:
jakarta/commons/proper/logging/trunk/build.xml
jakarta/commons/proper/logging/trunk/optional/build.xml
jakarta/commons/proper/logging/trunk/optional/project.xml
jakarta/commons/proper/logging/trunk/project.xml
jakarta/commons/proper/logging/trunk/xdocs/index.xml
Modified: jakarta/commons/proper/logging/trunk/build.xml
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/logging/trunk/build.xml?view=diffr1=153295r2=153296
==
--- jakarta/commons/proper/logging/trunk/build.xml (original)
+++ jakarta/commons/proper/logging/trunk/build.xml Thu Feb 10 13:57:11 2005
@@ -64,7 +64,7 @@
property name=component.title value=Logging Wrapper Library/
!-- The current version number of this component --
- property name=component.version value=1.0.5-dev/
+ property name=component.version value=1.0.6-dev/
!-- The base directory for compilation targets --
property name=build.home value=${basedir}/target/
Modified: jakarta/commons/proper/logging/trunk/optional/build.xml
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/logging/trunk/optional/build.xml?view=diffr1=153295r2=153296
==
--- jakarta/commons/proper/logging/trunk/optional/build.xml (original)
+++ jakarta/commons/proper/logging/trunk/optional/build.xml Thu Feb 10 13:57:11
2005
@@ -21,7 +21,7 @@
!--
Logging component of the Jakarta Commons Subproject
-$Id: build.xml,v 1.1 2004/11/04 23:00:04 rdonkin Exp $
+$Id$
--
@@ -58,7 +58,7 @@
property name=component.title value=Logging Wrapper Library
(Optional Implementations)/
!-- The current version number of this component --
- property name=component.version value=1.0.5-dev/
+ property name=component.version value=1.0.6-dev/
!-- The base directory for compilation targets --
property name=build.home value=${basedir}/target/
Modified: jakarta/commons/proper/logging/trunk/optional/project.xml
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/logging/trunk/optional/project.xml?view=diffr1=153295r2=153296
==
--- jakarta/commons/proper/logging/trunk/optional/project.xml (original)
+++ jakarta/commons/proper/logging/trunk/optional/project.xml Thu Feb 10
13:57:11 2005
@@ -21,7 +21,7 @@
nameLogging/name
idcommons-logging-optional/id
- currentVersion1.0.5-dev/currentVersion
+ currentVersion1.0.6-dev/currentVersion
inceptionYear2001/inceptionYear
shortDescriptionCommons Logging (Optional
Implementations)/shortDescription
description
Modified: jakarta/commons/proper/logging/trunk/project.xml
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/logging/trunk/project.xml?view=diffr1=153295r2=153296
==
--- jakarta/commons/proper/logging/trunk/project.xml (original)
+++ jakarta/commons/proper/logging/trunk/project.xml Thu Feb 10 13:57:11 2005
@@ -21,7 +21,7 @@
nameLogging/name
idcommons-logging/id
- currentVersion1.0.5-dev/currentVersion
+ currentVersion1.0.6-dev/currentVersion
inceptionYear2001/inceptionYear
shortDescriptionCommons Logging/shortDescription
description
Modified: jakarta/commons/proper/logging/trunk/xdocs/index.xml
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/logging/trunk/xdocs/index.xml?view=diffr1=153295r2=153296
==
--- jakarta/commons/proper/logging/trunk/xdocs/index.xml (original)
+++ jakarta/commons/proper/logging/trunk/xdocs/index.xml Thu Feb 10 13:57:11
2005
@@ -58,6 +58,17 @@
section name=Releases
+subsection name='1.0.5 Release (Proposed)'
+ p
+strongNote:/strong emrelease candidate is currently under
preparation./em
+ /p
+p
+JCL 1.0.5 is a service release adding optional improved automatic memory
management
+for containers which do not support JCL explicit memory release
+during hot reployment (1.4+ JVMs only). For more details see the
+a href='guide.html#Classloader%20and%20Memory%20Management'user guide/a.
+/p
+/subsection
subsection name='1.0.4 Release'
p
The 1.0.4 release of commons-logging is a service
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33475] - [configuration] ClassNotFoundException on Sun App Server
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=33475. 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=33475 --- Additional Comments From [EMAIL PROTECTED] 2005-02-10 22:57 --- (In reply to comment #8) Or even cooler, we could use XMLConfiguration in ConfigurationFactory to parse the definition file. Then we could use the whole Configuration API to access the properties and could do wild things, too. Just a thought, but I enjoy such recursive stuff! If you can use XMLConfiguration to read your config files, I would recommend that. However in reference to the original posting, I think setting Digester's useContextClassLoader is the correct thing to do, and should not have any side-effects. If this flag is defined but there is no context classloader set, then digester will effectively ignore the flag. The only possibility for problems is where contextClassLoader is set but you don't want to use that to load user classes. And I can't see why that would ever happen. Cheers, Simon (one of the maintainers of commons-digester) -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE][configuration]Release 1.1
FWIW i've never regretted holding a release and i think the right decision's been made. - robert On Thu, 2005-02-10 at 19:43, Oliver Heger wrote: Of course, I don't want to force a release out which is not mature. Let's hold it. But I feel a bit disappointed that it seems to be so hard to get the required three +1s. I think we must be careful that we do not lose our momentum :-( Oliver Emmanuel Bourg wrote: I'm actually -1 for the release, I dropped the 1.1rc1 jar in my application yesterday and it broke with an exception related to the configuration reloading stuff. This may be linked to the issue reported by Jurgen Schlierf on the commons-user list. I'd like to investigate this bug before releasing the final 1.1. Emmanuel Bourg Oliver Heger wrote: Hi all, we need another +1 to get our release out. Nobody? Oliver Oliver Heger wrote: Dear community, since the 1.0 release of [configuration] a couple of new features have been added. The code base has been stable for a while now, so I think it is time to cut out a new 1.1 release before we start to implement further features and refactorings. A complete list of changes since the 1.0 releaes can be found here: http://jakarta.apache.org/commons/configuration/changes-report.html I have created a release candidate, which can be inspected at http://www.apache.org/~oheger/commons-configuration-1.1rc1/ (the tag for 1.1RC1 is named CONFIGURATION_1_1RC1). Here is my +1! Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester2] Additions
Hi Oliver,
On Thu, 2005-02-10 at 19:08 +0100, Oliver Zeigermann wrote:
Folks,
as I noticed Simon has done so much work on Digester2, I just wanted
to be sure that my scheduled additions still are appropriate and
aligned to the overall design. Here they are:
(1) XMLIORuleManager: A rule manager that takes an action and
unconditionally calls it on any event. It's useful to imitate xmlio
style processing, but not limited to this. One application might be
logging. As it is more general any proposal for a better name?
Quoting code sample from Simon:
// xmlio-style digester
Action myHandler = new AbstractAction() {
public void begin(
Context context,
String namespace, String name,
Attributes attrs) {
String path = context.getMatchPath();
if (path.equals(..)) {
} else {
}
}
public void body(...) {
}
}
RuleManager xmlioRuleManager = new XMLIORuleManager(myHandler);
Digester d = new Digester();
d.setRuleManager(xmlioRuleManager);
As an option it might be possible to register an action with any rule
manager that gets called unconditionally - epsecially for logging and
debugging this can be really helpful. However, I wasn't quite sure if
Simon was happy with that.
Adding functionality to DefaultRuleManager that returns a set of default
actions *if no other action matches the current path* is not a problem.
I'm all for it. And this would meet your requirements, yes? So I'm happy
for you to go with this if you agree. And as a bonus, implementation
should be trivial: a dozen lines or so. I'm not sure whether this API
should then be exposed via the RuleManager interface (ie required for
all RuleManagers) or just left on DefaultRuleManager.
Adding functionality that returns a set of actions *in addition to* the
actions that match the current path is trickier. In what order are they
returned? And can we avoid instantiating a new List object each time
getMatchingActions is called? I'm not saying I'm opposed to it, I'm just
not sure right now.
(2) Next to the body and bodySegment call back methods there might be
one that gives you the complete body of an element as a string
composed of all character and markup data. This might be useful when
you want to verbosely take over formatted mixed content like in XHTML.
For performance reasons there should be some mechanism that tells
digester when such content is needed on an element basis. Maybe
something returned by the begin method or - maybe cleaner - something
returned by an additional call back directly called after begin like
boolean requiresComposedBody(String namespace, String name) or
anything similar. This method could alternatively be part of an
additional or extended interface.
Yep. I'm in favour of this. I would prefer an eye to be kept on
performance; the requiresComposedBody solution doesn't tempt me
greatly as that is a call that must be made on each Action each time it
matches, and 99.999% of those calls will return false. I could live with
it if there is no better alternative. However if an action's begin
method could enable the body text collection and the end method disable
it then wouldn't that have the same effect without additional work when
the feature isn't being used? I agree it's a little less intuitive for
Action writers though...and I haven't thought it through fully.
Note that I am tentatively planning to do some significant rework of the
DefaultRuleManager class. But that certainly won't be for some weeks so
hack away! I guess you'll also be wanting to work on the Path class, so
the custom Action class can more easily test the current path? I'll make
sure I check on this list before altering this class (though I've got no
plans to do so).
Cheers,
Simon
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: benchmark4j? Open Java benchmarking code similar to log4j?
a OSS benchmarking tool would be cool but i'm unlikely to be able to
find the cycles to help you out...
providing that you're an ASF committer and happy licensing under ASL2,
then the sandbox can be a useful place to start out a project (whether
it ends up in the commons proper or not).
- robert
On Wed, 2005-02-09 at 20:32, Kevin A. Burton wrote:
A problem I'm having at work right now is that I need a simple
benchmarking tool across multiple libraries. The FeedParser is a good
example because I want to link to the code there but also in our
internal code which also has some intregration with our DB.
This way I can look at a histograph of operations per second and how all
of the systems interact.
I wrote a simple prototype and here's the javadoc:
/** * Benchmark that allows cheap and lightweight benchmarking (go
figure) of * arbitrary code. All you have to do is call inc() every
time a method * completes which will then increment the benchmark and
perform any operations * necessary to maintain the benchmark. * * This
class is lightweight (only requires a hashmap entry, and (24 bytes per
* benchmark) of storage with no external requirements. This class is
also * threadsafe so if you need to call this from multithreaded code
to benchmark * the you'll be ok. * * The benchmark is maintained as
number of inc()s per minute. This can be any * type of operation you
want. Technically the interval can be longer than a * minute but we
will end up with stale data. That's the tradeoff with this * type of
benchmark. Its cheap and easy to maintain but anything more than 60 *
seconds worth of data and you'll end up with a stale benchmark. * *
Internally we use an incremented value which is accumulated and reset
ever 60 * seconds. When we reset the benchmark we reset the current
value so that we * can start accumulating again. * * @author a
href=mailto:[EMAIL PROTECTED]Kevin Burton/a * @version $Id:
Adler32.java,v 1.4 2004/05/21 22:21:32 burton Exp $ */
Now it dawned on me that if this was OSS that it could be used similar to
log4j. One could integrate this with log4j to have it log its operations
every 60 seconds so that you could enable logging of benchmark information if
you're trying to debug performance.
It would also allow constructs such as:
Benchmark benchmark = Benchmark.getBenchmark( Foo.class );
try {
benchmark.enter();
//perform some slow complicated operation
} finally {
benchmark.exit();
}
Then I could enable the benchmarks logging at runtime. Since the benchmarks
only require 100 bytes or so (with hashmap overhead) one could add
benchmarking anywhere they wanted without much of a VM overhead.
Anyway... my NYE resolution was to make sure all of my util code becomes OSS
;).. Any interest in having this move into the sandbox or collaborating in
this somewhere?
Assuming there's interest that is. I need it for work so I'll probably work
on a proof of concept ASAP ...
Kevin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: concurrency and starting a synchronized block
WHIRLYCOTT wrote: I guess this thread should end soon, but while we're still having some fun ... ;) ConcurrentHashMap can do concurrent put() operations and concurrent get() operations... and that's the tricky part. I just love all that stuff that Doug Lea has done. For those who haven't looked at util.concurrent, I recommend it. Sounds like others do as well. I know... its good stuff. I blogged about it: http://www.peerfear.org/rss/permalink/2004/12/19/TheJavaUtilConcurrentPackageAndThreadConcurrency/ All the fun toys that are available ;) Kevin -- Use Rojo (RSS/Atom aggregator). Visit http://rojo.com. Ask me for an invite! Also see irc.freenode.net #rojo if you want to chat. Rojo is Hiring! - http://www.rojonetworks.com/JobsAtRojo.html If you're interested in RSS, Weblogs, Social Networking, etc... then you should work for Rojo! If you recommend someone and we hire them you'll get a free iPod! Kevin A. Burton, Location - San Francisco, CA AIM/YIM - sfburtonator, Web - http://peerfear.org/ GPG fingerprint: 5FB2 F3E2 760E 70A8 6174 D393 E84D 8D04 99F1 4412 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: benchmark4j? Open Java benchmarking code similar to log4j?
robert burrell donkin wrote: a OSS benchmarking tool would be cool but i'm unlikely to be able to find the cycles to help you out... providing that you're an ASF committer and happy licensing under ASL2, then the sandbox can be a useful place to start out a project (whether it ends up in the commons proper or not). Yeah... I was probably going to do that... I have a prototype implementation written already and we're using it at work. The cool part is that with two lines of code I can have any arbitrary benchmark logged. Kevin -- Use Rojo (RSS/Atom aggregator). Visit http://rojo.com. Ask me for an invite! Also see irc.freenode.net #rojo if you want to chat. Rojo is Hiring! - http://www.rojonetworks.com/JobsAtRojo.html If you're interested in RSS, Weblogs, Social Networking, etc... then you should work for Rojo! If you recommend someone and we hire them you'll get a free iPod! Kevin A. Burton, Location - San Francisco, CA AIM/YIM - sfburtonator, Web - http://peerfear.org/ GPG fingerprint: 5FB2 F3E2 760E 70A8 6174 D393 E84D 8D04 99F1 4412 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r153314 - jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/actions/BeanPropertySetterAction.java
Author: skitching
Date: Thu Feb 10 18:16:40 2005
New Revision: 153314
URL: http://svn.apache.org/viewcvs?view=revrev=153314
Log:
* added some javadoc
* removed trailing whitespace
Modified:
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/actions/BeanPropertySetterAction.java
Modified:
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/actions/BeanPropertySetterAction.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/actions/BeanPropertySetterAction.java?view=diffr1=153313r2=153314
==
---
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/actions/BeanPropertySetterAction.java
(original)
+++
jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/actions/BeanPropertySetterAction.java
Thu Feb 10 18:16:40 2005
@@ -1,19 +1,19 @@
/* $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;
@@ -38,13 +38,31 @@
* The name of the property to set:
* ul
* lican be specified when the action is created, or/li
- * lican be the name of the matched xml element (useful when the Action is
- * used with a pattern that can match multiple elements)./li
+ * lican be the name of the matched xml element. This is useful when the
+ * Action is used with a pattern that can match multiple elements, or
+ * can be used just because it requires less parameters!/li
* /ul
* p
* The text contained in the xml element has all leading and trailing
* whitespace removed from it before the property setter method is invoked
* on the target object.
+ * p
+ * Example:br
+ * Given rules:
+ * pre
+ * digester.addRule(/person, new CreateObjectAction(Person.class));
+ * digester.addRule(/person/name, new BeanPropertySetterAction());
+ * /pre
+ * the input
+ * pre
+ * [person]
+ *[name]myname[/name]
+ * [/person]
+ * /pre
+ * causes a Person object to be created, then setName(myname) is called on
it.
+ * p
+ * If you wish to map several child elements onto object properties, then you
+ * may wish to consider using the SetNestedPropertiesAction instead.
*/
public class BeanPropertySetterAction extends AbstractAction {
@@ -57,8 +75,8 @@
protected String propertyName = null;
/**
- * The identifier of the context scratch stack used to store the
- * body text passed to the body method, so that it can be used in
+ * The identifier of the context scratch stack used to store the
+ * body text passed to the body method, so that it can be used in
* the end method. This stack is per-action-instance, so that other
* instances of this class can't ever interfere with the data on this
* stack.
@@ -66,9 +84,9 @@
protected final Context.StackId BODY_TEXT_STACK =
new Context.StackId(BeanPropertySetterAction.class, bodytext, this);
-// ---
+// ---
// Constructors
-// ---
+// ---
/**
* Construct an instance that uses the xml element name to determine
@@ -77,7 +95,7 @@
public BeanPropertySetterAction() {
this((String)null);
}
-
+
/**
* Construct an instance that sets the given property.
*
@@ -87,15 +105,15 @@
this.propertyName = propertyName;
}
-// -
+// -
// Public Methods
-// -
+// -
/**
* Process the body text of this element.
*
* @param context is the current parse context.
- * @param namespace the namespace URI of the matching element, or an
+ * @param namespace the namespace URI of the matching element, or an
* empty string if the element has no namespace
* @param name the local name of the element.
* @param text
svn commit: r153315 - jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/actions/BeanPropertySetterActionTestCase.java
Author: skitching
Date: Thu Feb 10 18:17:10 2005
New Revision: 153315
URL: http://svn.apache.org/viewcvs?view=revrev=153315
Log:
Test cases for BeanPropertySetterAction
Added:
jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/actions/BeanPropertySetterActionTestCase.java
(with props)
Added:
jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/actions/BeanPropertySetterActionTestCase.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/actions/BeanPropertySetterActionTestCase.java?view=autorev=153315
==
---
jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/actions/BeanPropertySetterActionTestCase.java
(added)
+++
jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/actions/BeanPropertySetterActionTestCase.java
Thu Feb 10 18:17:10 2005
@@ -0,0 +1,108 @@
+/* $Id$
+ *
+ * Copyright 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 BeanPropertySetterActionTestCase class./p
+ */
+
+public class BeanPropertySetterActionTestCase extends TestCase {
+
+public static class TestObject {
+private String name;
+
+public void setName(String name) { this.name = name; }
+public String getName() { return name; }
+}
+
+// ---
+// Constructors
+// ---
+
+/**
+ * Construct a new instance of this test case.
+ *
+ * @param name Name of the test case
+ */
+public BeanPropertySetterActionTestCase(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(BeanPropertySetterActionTestCase.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 Rumplestiltskin /name +
+/root;
+
+InputSource source = new InputSource(new StringReader(inputText));
+
+Digester d = new Digester();
+TestObject testObject = new TestObject();
+
+BeanPropertySetterAction action = new BeanPropertySetterAction();
+d.addRule(/root/name, action);
+d.setInitialObject(testObject);
+d.parse(source);
+
+// string was passed ok, and surrounding whitespace was trimmed
+assertEquals(name property, Rumplestiltskin, testObject.getName());
+}
+}
Propchange:
jakarta/commons/proper/digester/branches/digester2/src/test/org/apache/commons/digester2/actions/BeanPropertySetterActionTestCase.java
--
svn:keywords = Id
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: concurrency and starting a synchronized block
There's also the original version here: http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html What does the backport offer that the original util.concurrent lib doesn't offer? phil. Kevin A. Burton wrote: WHIRLYCOTT wrote: I guess this thread should end soon, but while we're still having some fun ... ;) ConcurrentHashMap can do concurrent put() operations and concurrent get() operations... and that's the tricky part. I just love all that stuff that Doug Lea has done. For those who haven't looked at util.concurrent, I recommend it. Sounds like others do as well. I know... its good stuff. I blogged about it: http://www.peerfear.org/rss/permalink/2004/12/19/TheJavaUtilConcurrentPackageAndThreadConcurrency/ All the fun toys that are available ;) Kevin -- Whirlycott Philip Jacob [EMAIL PROTECTED] http://www.whirlycott.com/phil/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: concurrency and starting a synchronized block
On Thu, 2005-02-10 at 21:59 -0500, WHIRLYCOTT wrote: There's also the original version here: http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html What does the backport offer that the original util.concurrent lib doesn't offer? The JSR process made some minor alterations to the API provided by the original lib, left out a few minor classes, etc. By using the backport, updating to the real java.util.concurrent is just a matter of changing the import statements in your code. Coding to Doug's original API means your code isn't quite compatible with the java.util.concurrent implementation provided by java 1.5. The site you reference also implies that performance was improved in some places in the java.util versions. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33475] - [configuration] ClassNotFoundException on Sun App Server
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=33475. 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=33475 --- Additional Comments From [EMAIL PROTECTED] 2005-02-11 07:55 --- Simon, thank you for making things clearer. Then I am also +1 for applying this patch now. If we want to remove the dependency to digester, we can do this in the process of the refactoring of ConfigurationFactory. Emmanuel, are you going to apply this patch? -- 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]
[digester2] should useContextClassLoader be true by default?
Hi y'all, The discussion associated with commons-configuration bugzilla entry http://issues.apache.org/bugzilla/show_bug.cgi?id=33475 has made me wonder why useContextClassLoader is false by default. Can anyone see a reason why it should not be *true* by default in digester2? (I think it's too big a jump to change the default behaviour of digester 1.x...). In other words, in what circumstances would a thread have a context-class-loader set, but not want to use it to load user objects? If they are rare, then true would seem a better default. I would appreciate comments from people who are familiar with frameworks that manipulate classloaders, esp. Tomcat (and that definitely includes you, Craig!). Thanks, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester2] should useContextClassLoader be true by default?
On Fri, 11 Feb 2005 20:28:06 +1300, Simon Kitching [EMAIL PROTECTED] wrote: Hi y'all, The discussion associated with commons-configuration bugzilla entry http://issues.apache.org/bugzilla/show_bug.cgi?id=33475 has made me wonder why useContextClassLoader is false by default. Can anyone see a reason why it should not be *true* by default in digester2? (I think it's too big a jump to change the default behaviour of digester 1.x...). In other words, in what circumstances would a thread have a context-class-loader set, but not want to use it to load user objects? If they are rare, then true would seem a better default. I would appreciate comments from people who are familiar with frameworks that manipulate classloaders, esp. Tomcat (and that definitely includes you, Craig!). Thanks for the vote of confidence :-) The key issue, from a Digester perspective, is that it should work in a non-J2EE environment as well. We already cover half of that equation in the current discovery logic -- if there is no context class loader available, we fall back to the class loader from which Digester itself was loaded. Thefefore, even in a very simple J2SE application (with only the system class loader being involved), we do the right thing. In a J2EE environemnt, this doesn't matter -- the spec requires that it be set correctly for, for example, a webapp. Each webapp can presume that the context class loader will correspond to the set of classes visible in the /WEB-INF/classes and /WEB-INF/lib directories of that webapp (plus whatever additional classes are made visible by the app server). But what happens if there is a context class loader set, in a J2SE app, but it's not the desired one? To be honest, I haven't done much non-J2EE development -- but I cannot think of any case where a default to assume the context class loader was the right answer (if it is non-null, of course) is a bad thing -- therefore, I would support the proposal in a Digester 2.x world to make true the default for this, as long as the fallback logic continued to exist. Thanks, Simon Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
