DO NOT REPLY [Bug 21431] New: - Wrong PropertyDescriptor found
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21431. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21431 Wrong PropertyDescriptor found Summary: Wrong PropertyDescriptor found Product: Commons Version: unspecified Platform: All OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Bean Utilities AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I use the Bean Utilites, that comes with struts 1.1. I have my own class com.mydomain.mypackage.Component. But the found PropertyDescriptors are for the class java.awt.Component. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21431] - Wrong PropertyDescriptor found
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21431. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21431 Wrong PropertyDescriptor found --- Additional Comments From [EMAIL PROTECTED] 2003-07-09 10:59 --- Created an attachment (id=7190) Debug-Screenshot (Debugger is in function PropertyUtils.gerPropertyDescriptor(..) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/hivemind/src/test-data/TestConstructRegistry testBasic.xml testUptoDate.xml
hlship 2003/07/09 04:27:26 Modified:hivemind/xdocs index.xml hivemind .classpath project.xml hivemind/src/java/org/apache/commons/hivemind/service/impl LoggingInterceptorFactory.java hivemind/src/java/org/apache/commons/hivemind HiveMindMessages.properties HiveMind.java hivemind/src/test/hivemind/test/services/impl CountFactory.java hivemind/src/test/hivemind/test/services TestServices.java hivemind/src/META-INF hivemodule.xml hivemind/src/test/hivemind/test HiveMindTestCase.java hivemind/src/test-data/sample org.example.toolbar.ui.xml hivemind/src/test-data/TestConstructRegistry testBasic.xml testUptoDate.xml Added: hivemind/src/java/org/apache/commons/hivemind/service MethodFab.java ClassFactory.java ClassFab.java hivemind/src/java/org/apache/commons/hivemind/service/impl ClassFactoryImpl.java ClassFabImpl.java AbstractServiceInterceptorFactory.java MethodFabImpl.java AbstractLoggingInterceptor.java Log: Add infrastructure for creating interceptor classes dynamically using Javassist. Revision ChangesPath 1.3 +4 -5 jakarta-commons-sandbox/hivemind/xdocs/index.xml Index: index.xml === RCS file: /home/cvs/jakarta-commons-sandbox/hivemind/xdocs/index.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- index.xml 30 Jun 2003 23:04:28 - 1.2 +++ index.xml 9 Jul 2003 11:27:23 - 1.3 @@ -184,10 +184,9 @@ the application. /p -pThe a href=base-registry.htmlHiveMind module descriptor documentation/a -gives a general idea of what the documentation looks like. Since its documentation -for just the core HiveMind module, it doesn't really show off the bells and whistles -you get when multiple modules work together. +pThe a href=sample-registry/index.htmlHiveMind module descriptor documentation/a +gives a general idea of what the documentation looks like, using a hypothetical +collection of module descriptors. /p /section 1.1 jakarta-commons-sandbox/hivemind/src/java/org/apache/commons/hivemind/service/MethodFab.java Index: MethodFab.java === /* * * * The Apache Software License, Version 1.1 * * Copyright (c) 1999-2003 The Apache Software Foundation. All rights * reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * * 1. Redistributions of source code must retain the above copyright *notice, this list of conditions and the following disclaimer. * * 2. Redistributions in binary form must reproduce the above copyright *notice, this list of conditions and the following disclaimer in *the documentation and/or other materials provided with the *distribution. * * 3. The end-user documentation included with the redistribution, if *any, must include the following acknowlegement: * This product includes software developed by the *Apache Software Foundation (http://www.apache.org/). *Alternately, this acknowlegement may appear in the software itself, *if and wherever such third-party acknowlegements normally appear. * * 4. The names The Jakarta Project, Commons, and Apache Software *Foundation must not be used to endorse or promote products derived *from this software without prior written permission. For written *permission, please contact [EMAIL PROTECTED] * * 5. Products derived from this software may not be called Apache *nor may Apache appear in their names without prior written *permission of the Apache Group. * * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE * DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
DO NOT REPLY [Bug 21433] New: - StorageBeanBase should use a resource name when calling StatementUtils functions
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21433.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21433
StorageBeanBase should use a resource name when calling StatementUtils functions
Summary: StorageBeanBase should use a resource name when calling
StatementUtils functions
Product: Commons
Version: unspecified
Platform: Other
OS/Version: Other
Status: NEW
Severity: Enhancement
Priority: Other
Component: Sandbox
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
Statementutils cleverly provides a way by which one can execute a query against
a different schema by providing a resource name that can be identified by the
ConnectionAdapter.
Problem is StorageBeanBase ignores this etting, thus making thhis feature
impossibile to use without redefining every method of StorageBeanBase. Following
is a patch to StorageBeanBase (fetched from CVS) that adds a getResource() call
to every StatementUtil invocation, so that subclasses can override getResource
and define their own resource name.
This is a major problem for us.
Thanks in advance,
Umberto
Index: StorageBeanBase.java
===
RCS file:
/home/cvspublic/jakarta-commons-sandbox/scaffold/src/java/org/apache/commons/scaffold/sql/StorageBeanBase.java,v
retrieving revision 1.17
diff -u -r1.17 StorageBeanBase.java
--- StorageBeanBase.java2 Jan 2003 19:45:26 - 1.17
+++ StorageBeanBase.java9 Jul 2003 12:18:11 -
@@ -3,7 +3,6 @@
import java.sql.SQLException;
import java.sql.Timestamp;
-
import java.util.Collection;
import java.util.Iterator;
import java.util.List;
@@ -11,24 +10,18 @@
import java.util.Properties;
import org.apache.commons.beanutils.BeanUtils;
-
import org.apache.commons.scaffold.lang.ParameterException;
import org.apache.commons.scaffold.lang.PopulateException;
import org.apache.commons.scaffold.lang.PropertiesException;
import org.apache.commons.scaffold.lang.ResourceException;
import org.apache.commons.scaffold.lang.Tokens;
-
-import org.apache.commons.scaffold.lucene.SearchUtils;
import org.apache.commons.scaffold.lucene.Engine;
-
-import org.apache.commons.scaffold.sql.StatementUtils;
+import org.apache.commons.scaffold.lucene.SearchUtils;
import org.apache.commons.scaffold.text.ConvertUtils;
-
-import org.apache.commons.scaffold.util.ResourceUtils;
-import org.apache.commons.scaffold.util.StorageBean;
import org.apache.commons.scaffold.util.ProcessBeanBase;
import org.apache.commons.scaffold.util.ProcessResult;
import org.apache.commons.scaffold.util.ProcessResultBase;
+import org.apache.commons.scaffold.util.StorageBean;
// 78
@@ -106,6 +99,12 @@
*/
public class StorageBeanBase extends ProcessBeanBase implements StorageBean {
+ /**
+* Subclass override to specify which resource to use
+* when retrieving connection.
+*
+*/
+ protected static String resource=null;
/**
* Convenience method to check for null, empty String.
@@ -482,7 +481,7 @@
try {
int result = StatementUtils.executeUpdate(
- null,lookup(command),getParameters(command));
+ getResource(),lookup(command),getParameters(command));
}
catch (SQLException e) {
@@ -498,7 +497,7 @@
try {
int result = StatementUtils.executeUpdate(
- null,lookupRoot(command));
+ getResource(),lookupRoot(command));
}
catch (SQLException e) {
@@ -518,7 +517,7 @@
Integer result = null;
try {
result = (Integer) StatementUtils.getColumn(
-null,
+getResource(),
1,
lookup(command)
);
@@ -539,7 +538,7 @@
Integer result = null;
try {
result = (Integer) StatementUtils.getColumn(
-null,
+getResource(),
1,
lookup(command),
parameter
@@ -563,7 +562,7 @@
try {
-found = StatementUtils.getElement(null,target,
+found = StatementUtils.getElement(getResource(),target,
lookup(command),key);
}
@@ -586,7 +585,7 @@
try {
-return StatementUtils.getCollection(null,
+return StatementUtils.getCollection(getResource(),
target,lookup(command));
}
@@ -608,7 +607,7 @@
try {
-return StatementUtils.getCollection(null,
+
DO NOT REPLY [Bug 21433] - [scaffold] StorageBeanBase should use a resource name when calling StatementUtils functions
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21433. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21433 [scaffold] StorageBeanBase should use a resource name when calling StatementUtils functions [EMAIL PROTECTED] changed: What|Removed |Added Summary|StorageBeanBase should use a|[scaffold] StorageBeanBase |resource name when calling |should use a resource name |StatementUtils functions|when calling StatementUtils ||functions - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [HiveMind] Question about HiveMind scope and purpose
Howard M. Lewis Ship wrote: HiveMind is being very, very actively developed. I've been putting a lot of info onto my blog: http://www.freeroller.net/page/hlship/Weblog I realize that some aspects of Avalon and HiveMind overlap. I think our goals are a bit different. HiveMind is intended to form a lower-layer; Avalon is a services container, HiveMind is a services and configuration microkernel. The majority of HiveMind is related to building and contributing configuration elements. HiveMind expressly does not have the same kind of Inversion of Control that Avalon has; IoC or not is left to the developer. Avalon (or at least the Avalon containers I researched) require more explicit connection of services. I did not see anything akin to an Eclipse plugin model for handling configuration ... that's HiveMind's strong suit ... HiveMind's assembly stage occurs dynamically, at runtime. :) I understand completely where you are comming from. There are now three different container implementations in Avalon land now. Fortress and Phoenix are the released containers, and Merlin is still under development although it is fully functional and rather featureful. Groking what's what can be a bit daunting. We are in the process of identifying the most flexible code base and evolving into one code base which will help lessen the load to understand everything. That said, Avalon does firmly entrench the IoC pattern--which has paid for itself in spades on many projects--but enough of that here. Both Phoenix and Merlin have a MicroKernel, and Merlin has runtime assembly features. So there is more overlap than you might of origionally thought. However, more on that later. I know it sounds like not invented here syndrome, but I had a short window of opportunity to put something together, keep it open-source, but use it in a very large scale project at work. In this situation, it was faster, easier and politcally safer for me to build it myself than it would be to take the time to fully grok and adapt Avalon. Additionally, a key requirement for me is line precise error reporting [*]; this is a major amount of work to graft into an existing code base. Also quite understandable. As to politically safer, the politicing in Avalon land has gone down quite considerably in the last month or so. It is a much nicer place to be now. That said, at the time you started working on HiveMind things were probably in turmoil in Avalon--so I can understand your hesitance at that time. Ultimately, I see HiveMind fitting in below Avalon; perhaps it may be adopted as the way in which the Avalon container is configured, rather than the way services hosted within the Avalon container are configured. I am very interested in seeing how HiveMind and Avalon can cooperate. While HiveMind has a set of features and other goodies, there is some overlap. That overlap does not mean that one must survive and the other die, but it means that we might be able to cooperate on how to define different features/aspects that will work in both environments. I want to see where the two projects can cooperate, sharing experience and such. By helping each other understand the differences and similarities we can probably establish a good relationship. It will help the Avalon team understand where they have failed to meet your requirements, and it will help you understand the challenges we have already faced and how we overcame them. [*] In Tapestry, and now in HiveMind, XML configuration files are read and converted into descriptor objects, which are then used to create runtime objects. In Tapestry, it's component specifications used to create components and pages and such. In HiveMind it is more open-ended. The line precise bit is: when the XML files are read, the exact location (file, line and column) for each descriptor object is recorded as a property of the object. When the descriptor object is used Hmm. Have you seen my BXML project at d-haven? http://d-haven.org/bxml It will allow you to compile XML into a SAX producing object (i.e. compiling your configuration files so that reads are blazingly fast). It also provides line precise error messages. It compiles the XML file into an XMLReader compatible class. Anyway, I can probably leverage the lessons learned from that into the configuration reading code for Avalon... Where else are line-precise error messages used? to create a runtime object, this location property is applied to the runtime object. The end result is that exceptions in the runtime objects, long after files have been parsed, can be related back to exact locations within the input files. You don't have to sleuth it out from a stack trace, a property of the exception will be the exact location to look. This works out to be a tremendous productivity boost ... you spend very little time guessing at problems, instead the framework directs you to the exact problem. This is all combined with
Re: Re[2]: [dbcp] Do we need Referenceable?
On Tue, 2003-07-08 at 22:53, Anton Tagunov wrote: Hello John! JM I am confused (and it has been awhile since I last looked at what is JM required). A DataSource should implement at least one of Referencable JM and Serializable; the specification recommends both. Are you advocating JM that we implement neither? Yes. But probably I really do not understand something essential. Disclaimer: yet have not read all JNDI spec though. Okay, imagine we have a separate Factory and Product. Factory is ObjectFactory, it creates Product. You say it is recommended that Product implements Referenceable or Serializable. But how can this be utilized? I believe there is only one way for it: if we have an object of type Product Product product; and we have a writeable object of class javax.naming.Context Context context; then we may call context.bind( ..., product ); and instead of storing the product itself the context will store either a reference to it, obtained via product.getReference(); or product's serialized form. That sounds like a good description. With Tomcat we're in a different position. Tomcat takes ResourceParams and unconditionally creates a Reference object all by itself populating it with the config data. This Reference also contains the factory class we have configured. What happens if tomcat changes its process to use the standard jndi pattern described above? What about a developer wishing to use dbcp with another servlet container or app server? Why are you advocating that dbcp tie itself exclusively to implementation details of tomcat? (btw, i do use tomcat almost exclusively myself). But what use for our product to implement Referenceable then? It will never have Context.bind() called on it. How can you presume that? So I'm for implementing neither Referenceable nor Serializable. In fact BasicDataSourceFactory/BasicDataSource implement none of this and work find with Tomcat. AT As I understand Tomcat JNDI resource infrastructure, it is enough AT to have an object that implements javax.naming.spi.ObjectFactory JM Are you saying that we can assume that if we meet tomcat's requirements JM for binding to its jndi implementation, that we will meet the JM requirements for a generic jndi implementation? Or that we should only JM worry about tomcat's version? Let's face it. Tomcat makes such a specialized use of the Reference object that our factories this way or other fit only into Tomcat. I don't understand the basis for that statement. You appear to be advocating changes to require only use in tomcat, but jdbc2pool is not currently written that way. john mcnally - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dbcp] Do we need Referenceable?
On Tue, 2003-07-08 at 08:47, David Graham wrote: It does not seem overly complicated and the work is already done. Is there some bug that requires simplification of the design? Code rarely seems complicated to the original author and bugs are not the only triggers for refactoring. That class is over 1700 lines long and is fairly complex. The version I am looking at is 1500 lines. Here is the breakdown: 150 lines preamble - license and class javadoc 610 lines properties (getters/setters) and associated javadoc 150 lines ObjectFactory implementation 40 lines serialization code which leaves about 550 lines of what i consider logic that might require some analysis. It really is not that much. Are there groups of functionality int there that could be refactored into separate classes? The ObjectFactory implementation should be separated into its own class, but I just found it easier to implement ObjectFactory and Referenceable in the same class as they generally have to be modified together. The 40 lines of serializable code can be eliminated with a dependency on commons-lang or it can be moved to a different class, but its not that much savings. It could be possible to build a slightly less complicated version by not allowing specification of per user limits (such as max connections). But I'd still like to maintain a version that does allow it. john mcnally Maintaining a class that large is difficult. David __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.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]
cvs commit: jakarta-commons-sandbox/math/src/java/org/apache/commons/math/stat/univariate/rank Max.java Min.java
mdiggory2003/07/09 09:24:18
Modified:math/src/java/org/apache/commons/math/stat/univariate/moment
FourthMoment.java GeometricMean.java
FirstMoment.java Mean.java ThirdMoment.java
Kurtosis.java Variance.java Skewness.java
StandardDeviation.java SecondMoment.java
math/src/java/org/apache/commons/math/stat/univariate/summary
SumOfSquares.java Product.java Sum.java
SumOfLogs.java
math/src/java/org/apache/commons/math/stat/univariate
UnivariateStatistic.java
AbstractUnivariateStatistic.java
StorelessUnivariateStatistic.java
AbstractStorelessUnivariateStatistic.java
math/src/java/org/apache/commons/math/stat/univariate/rank
Max.java Min.java
Log:
In cases where getResult contains a statistical calculation, it now
checks if the internal state of the underlying statistic has changed
and only recalculates if this is true. this way muliple calls to getResult
when the staistic has not been incremented are less expensive
because it is only returning a property value.
Revision ChangesPath
1.5 +1 -1
jakarta-commons-sandbox/math/src/java/org/apache/commons/math/stat/univariate/moment/FourthMoment.java
Index: FourthMoment.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/math/src/java/org/apache/commons/math/stat/univariate/moment/FourthMoment.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- FourthMoment.java 8 Jul 2003 03:44:11 - 1.4
+++ FourthMoment.java 9 Jul 2003 16:24:16 - 1.5
@@ -95,7 +95,7 @@
/**
* @see
org.apache.commons.math.stat.univariate.StorelessUnivariateStatistic#getValue()
*/
-public double getValue() {
+public double getResult() {
return m4;
}
1.7 +16 -8
jakarta-commons-sandbox/math/src/java/org/apache/commons/math/stat/univariate/moment/GeometricMean.java
Index: GeometricMean.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/math/src/java/org/apache/commons/math/stat/univariate/moment/GeometricMean.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- GeometricMean.java8 Jul 2003 03:44:12 - 1.6
+++ GeometricMean.java9 Jul 2003 16:24:16 - 1.7
@@ -60,9 +60,12 @@
*
*/
public class GeometricMean extends SumOfLogs {
-
-private int n = 0;
+
+protected int n = 0;
+
+private double geoMean = Double.NaN;
+private double lastSum = 0.0;
/**
* @see
org.apache.commons.math.stat.univariate.StorelessUnivariateStatistic#increment(double)
*/
@@ -74,8 +77,12 @@
/**
* @see
org.apache.commons.math.stat.univariate.StorelessUnivariateStatistic#getValue()
*/
-public double getValue() {
-return Math.exp( super.getValue() / (double)n );
+public double getResult() {
+if (lastSum != super.getResult() || n == 1) {
+lastSum = super.getResult();
+geoMean = Math.exp(lastSum / (double) n);
+}
+return geoMean;
}
/**
@@ -83,9 +90,11 @@
*/
public void clear() {
super.clear();
+lastSum = 0.0;
+geoMean = Double.NaN;
n = 0;
}
-
+
/**
* Returns the geometric mean for this collection of values
* @param values Is a double[] containing the values
@@ -96,9 +105,8 @@
* @see
org.apache.commons.math.stat.univariate.UnivariateStatistic#evaluate(double[], int,
int)
*/
public double evaluate(double[] values, int begin, int length) {
-return Math.exp(super.evaluate(values, begin, length) / (double) length );
+return Math.exp(
+super.evaluate(values, begin, length) / (double) length);
}
-
-
}
1.3 +3 -3
jakarta-commons-sandbox/math/src/java/org/apache/commons/math/stat/univariate/moment/FirstMoment.java
Index: FirstMoment.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/math/src/java/org/apache/commons/math/stat/univariate/moment/FirstMoment.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- FirstMoment.java 8 Jul 2003 03:44:12 - 1.2
+++ FirstMoment.java 9 Jul 2003 16:24:16 - 1.3
@@ -88,7 +88,7 @@
n0 = (double)n;
v = dev / n0;
-m1 += v;
+m1 += v;
cvs commit: jakarta-commons-sandbox/math/src/test/org/apache/commons/math/stat/univariate StorelessUnivariateStatisticAbstractTest.java
mdiggory2003/07/09 09:28:30 Modified:math/src/test/org/apache/commons/math/stat/univariate StorelessUnivariateStatisticAbstractTest.java Log: Changing getValue to getResult. Revision ChangesPath 1.3 +3 -3 jakarta-commons-sandbox/math/src/test/org/apache/commons/math/stat/univariate/StorelessUnivariateStatisticAbstractTest.java Index: StorelessUnivariateStatisticAbstractTest.java === RCS file: /home/cvs/jakarta-commons-sandbox/math/src/test/org/apache/commons/math/stat/univariate/StorelessUnivariateStatisticAbstractTest.java,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- StorelessUnivariateStatisticAbstractTest.java 7 Jul 2003 23:19:21 - 1.2 +++ StorelessUnivariateStatisticAbstractTest.java 9 Jul 2003 16:28:30 - 1.3 @@ -80,11 +80,11 @@ statistic.increment(testArray[i]); } -assertEquals(expectedValue(), statistic.getValue(), getTolerance()); +assertEquals(expectedValue(), statistic.getResult(), getTolerance()); statistic.clear(); - -assertTrue(Double.isNaN(statistic.getValue())); + +assertTrue(Double.isNaN(statistic.getResult())); } - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dbcp] Do we need Referenceable?
--- John McNally [EMAIL PROTECTED] wrote: On Tue, 2003-07-08 at 08:47, David Graham wrote: It does not seem overly complicated and the work is already done. Is there some bug that requires simplification of the design? Code rarely seems complicated to the original author and bugs are not the only triggers for refactoring. That class is over 1700 lines long and is fairly complex. The version I am looking at is 1500 lines. Here is the breakdown: 150 lines preamble - license and class javadoc 610 lines properties (getters/setters) and associated javadoc 150 lines ObjectFactory implementation 40 lines serialization code which leaves about 550 lines of what i consider logic that might require some analysis. It really is not that much. Are there groups of functionality int there that could be refactored into separate classes? The ObjectFactory implementation should be separated into its own class, but I just found it easier to implement ObjectFactory and Referenceable in the same class as they generally have to be modified together. +1 on separating it into its own class. The 40 lines of serializable code can be eliminated with a dependency on commons-lang or it can be moved to a different class, but its not that much savings. Then lets add a dependency on commons-lang. I hate duplicating code even if it's 40 lines. IMO, thinking of class design in lines of code savings terms is wrong. We should design classes that have appropriate separation of concerns so that everything is reusable and self documenting. It could be possible to build a slightly less complicated version by not allowing specification of per user limits (such as max connections). But I'd still like to maintain a version that does allow it. We may as well keep one version with that capability. Thanks for identifying the areas for possible improvement! David john mcnally Maintaining a class that large is difficult. David __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.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] __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/io TestSAXBeanWriter.java
rdonkin 2003/07/09 11:10:24
Modified:betwixt/src/test/org/apache/commons/betwixt/io
TestSAXBeanWriter.java
Log:
Improved unit tests
Revision ChangesPath
1.5 +19 -10
jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/io/TestSAXBeanWriter.java
Index: TestSAXBeanWriter.java
===
RCS file:
/home/cvs/jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/io/TestSAXBeanWriter.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- TestSAXBeanWriter.java17 Feb 2003 19:41:57 - 1.4
+++ TestSAXBeanWriter.java9 Jul 2003 18:10:24 - 1.5
@@ -72,6 +72,7 @@
import junit.textui.TestRunner;
import org.apache.commons.betwixt.PersonBean;
+import org.apache.commons.betwixt.AbstractTestCase;
import org.apache.commons.logging.impl.SimpleLog;
import org.w3c.dom.Document;
import org.w3c.dom.Element;
@@ -88,7 +89,7 @@
* @author a href=mailto:[EMAIL PROTECTED]Martin van den Bemt/a
* @version $Id$
*/
-public class TestSAXBeanWriter extends TestCase {
+public class TestSAXBeanWriter extends AbstractTestCase {
public static final String XML = ?xml version='1.0'?PersonBean
id='1'age35/agenameJohn Smith/name/PersonBean;
@@ -102,14 +103,22 @@
// writer bean into string
StringWriter out = new StringWriter();
-SimpleLog log = new SimpleLog([TestWrite:SAXBeanWriter]);
-log.setLevel(SimpleLog.LOG_LEVEL_TRACE);
+//SimpleLog log = new SimpleLog([TestWrite:SAXBeanWriter]);
+//log.setLevel(SimpleLog.LOG_LEVEL_TRACE);
SAXBeanWriter writer = new SAXBeanWriter(new SAXContentHandler(out));
-writer.setLog(log);
+//writer.setLog(log);
writer.write(bean);
String beanString = out.getBuffer().toString();
-System.out.println(beanString);
+String xml = ?xml version='1.0'?PersonBeanage35/age
++ nameJohn Smith/name/PersonBean;
+
+
+xmlAssertIsomorphicContent(
+parseString(xml),
+parseString(beanString),
+true);
+
// test the result
DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
DocumentBuilder builder = factory.newDocumentBuilder();
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/digester TestIDRead.java
rdonkin 2003/07/09 11:27:50
Modified:betwixt/src/test/org/apache/commons/betwixt/digester
TestIDRead.java
Log:
Improved unit tests
Revision ChangesPath
1.6 +18 -6
jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/digester/TestIDRead.java
Index: TestIDRead.java
===
RCS file:
/home/cvs/jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/digester/TestIDRead.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- TestIDRead.java 9 Feb 2003 22:27:18 - 1.5
+++ TestIDRead.java 9 Jul 2003 18:27:49 - 1.6
@@ -64,6 +64,7 @@
import java.io.FileInputStream;
import java.io.InputStream;
+import java.io.StringWriter;
import junit.framework.Test;
import junit.framework.TestSuite;
@@ -100,11 +101,22 @@
}
public void testSimpleRead() throws Exception {
-BeanWriter writer = new BeanWriter();
+StringWriter out = new StringWriter();
+out.write(?xml version='1.0'?);
+BeanWriter writer = new BeanWriter(out);
IDBean bean = new IDBean(alpha,one);
bean.addChild(new IDBean(beta,two));
bean.addChild(new IDBean(gamma,three));
writer.write(bean);
+
+String xml =
IDBeannameone/namechildrenchildnametwo/namechildren/
++ idbeta/id/childchildnamethree/namechildren/
++ idgamma/id/child/childrenidalpha/id/IDBean;
+
+xmlAssertIsomorphicContent(
+parseString(xml),
+parseString(out.getBuffer().toString()),
+true);
BeanReader reader = new BeanReader();
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[math] Userguide
Just a thought (we've been around this subject before), I've often found that when JavaDoc includes descriptive usage and examples that its really promotes rapid understandng of the packages for me personally. What are the current opinions on the following ideas? 1.) Javadoc = Userguide? Embed the userguide into the javadoc (though I know we want to start playing with MathML in the userguide, I know we've discussed issues with browser plugins and Javadoc generation that may possibly complicate this subject) OR 2.) Use crosslinks throughout the Userguide and JavaDoc so they reference each other at specific points of interest. -M. -- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] Main Univariate Facade Implementations that work withUnivariateStatistics
I'm getting ready to commit these changes today, I thought I'd give a heads up before I did this and give one last opportunity for interaction. I plan to commit sometime this evening. Just to note again, these changes are to the Univariate Implementations to get them working with the UnivariateStatistic library. If we do decide to move away from using the Univariate Interfaces, this is a stepping stone in that direction. I would welcome others to explore alternate strategies for UnivariateStatistic containers/facades. -Mark Mark R. Diggory wrote: Phil Steitz wrote: Given the consensus to move in the direction of disaggregated statistics, I would agree that there is no internal need for StatUtils. As a final comment on this, I would like to point out that my opposition to this approach was based on what I now see was a naive view that we could actually agree on a set of commonly used univariate statistics and limit our support to these. I never envisioned Univariate as a large, monolithic interface. I see now that this is an inherently limiting perspective and I should not have proposed it. I was relying too much on my biased practical experience/observation that once you get past the basic stuff, practical applications drop off quickly. I was also overly concerned about performance and overhead, again largely due to my own experience and application needs. The one thing that I don't understand about the new approach and I would suggest reconsidering is why you want to retain the Univariate interfaces at all. As long as you have these and people depend on them, I don't think that you will really have the full extensibility that you want and you will have added complexity and overhead to deal with. Sort of the worst of both worlds. The only thing that you *need* is a way to aggregate data (actually you have this already -- just need shared aggregation). Why not just move to a model where a Univariate has a dynamic List of Statistics and do away with the getXXX methods in the Univariate interfaces altogether? Phil Phil, I really value your input and work, you really help keep us on track and to keep adventures like me from going too far overboard. I am approaching the contents of this patch in an attempt show how the usage of the individual UnvariateStatistics initially relates back to what we have already implemented. Do you think that Store/Univariate still provides a good example of how stats can be aggregated together under a beanlike interface? Maybe as such they are good initial examples of library usage. I do still believe you are right that here is a logical subset of statistics that could be categorized as Descriptive Statistics, and that we could place such a set within Univariate and still keep it simple and light weight. I also recognize theres always going to be an interest in expanding capabilities and having this modular UnviariateStatistic strategy at the core of the implementations makes various aggregations of statistics much more flexible and dynamic. I think the Store/Univariate Interface/Implementations show us an initial strategy for aggregation of the individual statistics under a bean-like interface. As such they are very useful still for immediate usage of a subset of statistics. Maybe we should keep them but document them as front end tools for users. Then also begin to work on something along the lines that Brent recommended for an Aggregation Container, but as a separate set of Interface/Implementations for now. What do you think? -Mark -- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/hivemind/src/java/org/apache/commons/hivemind/impl RegistryBuilder.java
hlship 2003/07/09 11:55:46 Modified:hivemind/xdocs localization.xml navigation.xml hivemind/xdocs/ant ConstructRegistry.xml hivemind/src/test/hivemind/test/ant TestConstructRegistry.java hivemind/src/java/org/apache/commons/hivemind/ant ConstructRegistry.java hivemind/src/xsl hivemind.xsl hivemind.css hivemind/src/java/org/apache/commons/hivemind/impl RegistryBuilder.java Added: hivemind/xdocs ioc.xml hivemind/src/test-data/TestConstructRegistry empty.jar testJars.xml module.jar Log: Extend ConstructRegistry Ant task to read deployment descriptors from inside JARs. Improve the registry documentation to include a master index of configurations and services. Revision ChangesPath 1.2 +4 -3 jakarta-commons-sandbox/hivemind/xdocs/localization.xml Index: localization.xml === RCS file: /home/cvs/jakarta-commons-sandbox/hivemind/xdocs/localization.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- localization.xml 2 Jul 2003 21:41:12 - 1.1 +++ localization.xml 9 Jul 2003 18:55:44 - 1.2 @@ -61,8 +61,9 @@ a href=apidocs/org/apache/commons/hivemind/Registry.htmlRegistry/a is created by the a href=apidocs/org/apache/commons/hivemind/impl/RegistryBuilder.htmlRegistryBuilder/a, -a locale may be specified. This is the locale for the Registry and, by extension for all Modules. -The locale may not be changed. By default, the JVM default locale is used. +a locale is specified. This is the locale for the Registry and, by extension, for all Modules +in the registry. +The locale may not be changed. /p /section 1.10 +1 -0 jakarta-commons-sandbox/hivemind/xdocs/navigation.xml Index: navigation.xml === RCS file: /home/cvs/jakarta-commons-sandbox/hivemind/xdocs/navigation.xml,v retrieving revision 1.9 retrieving revision 1.10 diff -u -r1.9 -r1.10 --- navigation.xml2 Jul 2003 21:41:12 - 1.9 +++ navigation.xml9 Jul 2003 18:55:44 - 1.10 @@ -6,6 +6,7 @@ item name=Services href=/services.html/ item name=Configurations href=/configuration.html/ item name=Localization href=/localization.html/ + item name=Inversion of Control href=/ioc.html/ item name=Module Descriptor href=/descriptor.html/ item name=HiveMind Registry href=/registry.html/ item name=Ant Tasks href=/ant/index.html collapse=true 1.1 jakarta-commons-sandbox/hivemind/xdocs/ioc.xml Index: ioc.xml === ?xml version=1.0? !-- $Id: ioc.xml,v 1.1 2003/07/09 18:55:44 hlship Exp $ -- !DOCTYPE document [ !ENTITY % common-links SYSTEM ../common/links.xml %common-links; ] document properties titleInversion of Control/title author email=[EMAIL PROTECTED]Howard M. Lewis Ship/author /properties body section name=Inversion of Control p Seems like a href=http://avalon.apache.org/framework/guide-patterns-ioc.html;bInversion of Control/b/a is all the rage these days. The a href=http://avalon.apache.org/;Avalon/a project is completely based around it. Avalon uses detailed assembly descriptions to tie services together ... there's no way an Avalon component can look up another component; in Avalon you explicitly connect services together. /p p That's the basic concept of Inversion of Control; you don't create your objects, you describe how they should be created. You don't connect your components and services in code, you describe the services required by each service your provide. The container creates the objects, wires them together and determines when methods are invoked. /p p HiveMind is much looser than Avalon. HiveMind doesn't have an explicit assembly stage; it wires together all the modules it can find at runtime. Service implementations may implement the a href=apidocs/org/apache/commons/hivemind/InitializeService.htmlInitializeService/a interface, which is essentially a post-creation callback; the implementation can, if it likes, look up other services by their well-known name. /p p On the other hand, HiveMind is responsible for creating services (including core implementations and interceptors). If you use the set-service-ref; element to initialize your services, you can get something very
[OT] Eclipse, Javadoc, and cvs in @version tags
I'm trying to setup a javadoc template in Eclipse to handle cvs verisioning in Javadoc comments. Does anyone have a good resource for this sort of thing? I just don't quite get where such templates/varables take effect (Does the CVS client have this capability, is it part of Eclipse or whatever)? Anyone who has tips on how to get such information to be automatically updated, I would be 110% grateful to. -Mark -- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] Userguide
Another FWIW comment since I'm not active on [math]. On Wed, 9 Jul 2003, Mark R. Diggory wrote: Date: Wed, 09 Jul 2003 14:31:32 -0400 From: Mark R. Diggory [EMAIL PROTECTED] Reply-To: Jakarta Commons Developers List [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Subject: [math] Userguide Just a thought (we've been around this subject before), I've often found that when JavaDoc includes descriptive usage and examples that its really promotes rapid understandng of the packages for me personally. I agree. What are the current opinions on the following ideas? 1.) Javadoc = Userguide? Embed the userguide into the javadoc (though I know we want to start playing with MathML in the userguide, I know we've discussed issues with browser plugins and Javadoc generation that may possibly complicate this subject) Many commons packages build user guide sorts of documentation into the top level package.html or overview.html file that automatically gets included in the javadoc generation. Especially for things like class libraries (where the target audience of the user guide is a developer who also needs the API information anyway), Javadocs seems like a natural place for this -- plus, it's very easy to hyperlink from the user guide examples directly to the corresponding class or method documentation. OR 2.) Use crosslinks throughout the Userguide and JavaDoc so they reference each other at specific points of interest. -M. Craig -- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/math/src/test/org/apache/commons/math/stat MixedListUnivariateImplTest.java StatUtilsTest.java UnivariateImplTest.java
mdiggory2003/07/09 14:45:24
Modified:math/src/java/org/apache/commons/math/stat Univariate.java
StoreUnivariate.java BeanListUnivariateImpl.java
UnivariateImpl.java TestStatisticImpl.java
AbstractStoreUnivariate.java
ListUnivariateImpl.java Frequency.java
StatUtils.java TestStatistic.java
StoreUnivariateImpl.java
math/src/test/org/apache/commons/math/stat
StatUtilsTest.java UnivariateImplTest.java
Added: math/src/java/org/apache/commons/math/stat
AbstractUnivariate.java
math/src/test/org/apache/commons/math/stat
MixedListUnivariateImplTest.java
Log:
Changes the Univariate implementations to use the UnivariateStatistic package. Slims
down StatUtils by removing some of the higher moments. Reimplmenets ListUnivariate to
work with NumberTransformers, turning into a Mixed Object List Univariate.
Revision ChangesPath
1.8 +26 -6
jakarta-commons-sandbox/math/src/java/org/apache/commons/math/stat/Univariate.java
Index: Univariate.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/math/src/java/org/apache/commons/math/stat/Univariate.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- Univariate.java 7 Jul 2003 23:25:13 - 1.7
+++ Univariate.java 9 Jul 2003 21:45:23 - 1.8
@@ -69,12 +69,21 @@
* reported statistics will be based on these valuesp
* The default windowSize is infinite -- i.e., all values added are included
* in all computations.
- *
- * @author a href=mailto:[EMAIL PROTECTED]Tim O'Brien/a
* @version $Revision$ $Date$
- *
*/
public interface Univariate {
+/**
+ * A LEPTOKURTIC set has a positive kurtosis (a high peak)
+ */
+public static int LEPTOKURTIC = 1;
+/**
+ * A MESOKURTIC set has a kurtosis of 0 - it is a normal distribution
+ */
+public static int MESOKURTIC = 0;
+/**
+ * A PLATYKURTIC set has a negative kurtosis (a flat peak)
+ */
+public static int PLATYKURTIC = -1;
/**
* Adds the value to the set of numbers
@@ -83,14 +92,14 @@
void addValue(double v);
/**
- * Returns the a href=http://www.xycoon.com/arithmetic_mean.htm
+ * Returns the a href=http://www.xycoon.com/arithmetic_mean.htm;
* arithmetic mean /a of the available values
* @return The mean or Double.NaN if no values have been added.
*/
double getMean();
/**
- * Returns the a href=http://www.xycoon.com/geometric_mean.htm
+ * Returns the a href=http://www.xycoon.com/geometric_mean.htm;
* geometric mean /a of the available values
* @return The geometricMean, Double.NaN if no values have been added,
* or if the productof the available values is less than or equal to 0.
@@ -127,6 +136,17 @@
*/
double getKurtosis();
+/**
+ * Returns the Kurtosis classification a distribution can be
+ * leptokurtic (high peak), platykurtic (flat peak),
+ * or mesokurtic (zero kurtosis).
+ *
+ * @return A static constant defined in this interface,
+ * StoredDeviation.LEPTOKURITC, StoredDeviation.PLATYKURTIC, or
+ * StoredDeviation.MESOKURTIC
+ */
+int getKurtosisClass();
+
/**
* Returns the maximum of the available values
* @return The max or Double.NaN if no values have been added.
1.7 +1 -43
jakarta-commons-sandbox/math/src/java/org/apache/commons/math/stat/StoreUnivariate.java
Index: StoreUnivariate.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/math/src/java/org/apache/commons/math/stat/StoreUnivariate.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- StoreUnivariate.java 7 Jul 2003 23:25:13 - 1.6
+++ StoreUnivariate.java 9 Jul 2003 21:45:23 - 1.7
@@ -60,51 +60,9 @@
* Univariate provides additional percentile functionality
* such as. This additional functionality comes with
* a price of increased storage costs.
- *
- * @author a href=mailto:[EMAIL PROTECTED]Tim O'Brien/a
+ * @version $Revision$ $Date$
*/
public interface StoreUnivariate extends Univariate {
-
-/**
- * A LEPTOKURTIC set has a positive kurtosis (a high peak)
- */
-public static int LEPTOKURTIC = 1;
-
-/**
- * A MESOKURTIC set has a kurtosis of 0 - it is a normal distribution
- */
-public static int MESOKURTIC = 0;
-
-/**
- * A PLATYKURTIC set
cvs commit: jakarta-commons-sandbox/math/src/test/org/apache/commons/math/stat/univariate InteractionTest.java
mdiggory2003/07/09 14:46:33 Modified:math/src/test/org/apache/commons/math/stat/univariate InteractionTest.java Log: Changes the Univariate implementations to use the UnivariateStatistic package. Slims down StatUtils by removing some of the higher moments. Reimplmenets ListUnivariate to work with NumberTransformers, turning into a Mixed Object List Univariate. Revision ChangesPath 1.2 +4 -4 jakarta-commons-sandbox/math/src/test/org/apache/commons/math/stat/univariate/InteractionTest.java Index: InteractionTest.java === RCS file: /home/cvs/jakarta-commons-sandbox/math/src/test/org/apache/commons/math/stat/univariate/InteractionTest.java,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- InteractionTest.java 7 Jul 2003 23:19:21 - 1.1 +++ InteractionTest.java 9 Jul 2003 21:46:33 - 1.2 @@ -119,10 +119,10 @@ k.increment(testArray[i]); } -assertEquals(mean,m.getValue(),tolerance); -assertEquals(var,v.getValue(),tolerance); -assertEquals(skew ,s.getValue(),tolerance); -assertEquals(kurt,k.getValue(),tolerance); +assertEquals(mean,m.getResult(),tolerance); +assertEquals(var,v.getResult(),tolerance); +assertEquals(skew ,s.getResult(),tolerance); +assertEquals(kurt,k.getResult(),tolerance); } - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21453] New: - NullPointerException in DBCP when used for client-server applications
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21453. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21453 NullPointerException in DBCP when used for client-server applications Summary: NullPointerException in DBCP when used for client- server applications Product: Commons Version: Nightly Builds Platform: PC URL: http://http:// OS/Version: Windows NT/2K Status: NEW Severity: Major Priority: Other Component: Dbcp AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Nullpointerexception with the below JNDI settings for client-server app My Server java file: private static String connectURI = jdbc:sapdb://LOCALHOST/mydb; private static String username = myusername; private static String password = mypassword; Properties env = new Properties(); env.put(Context.SECURITY_AUTHENTICATION,simple); env.put(Context.REFERRAL,follow); env.put(Context.SECURITY_PRINCIPAL, cn=myname); env.put(Context.SECURITY_CREDENTIALS,mypassword); env.put(com.sun.jndi.ldap.connect.pool, true); env.put(databaseName, mydb); env.put(user, username); env.put(password, password); env.put(url, connectURI); env.put(driver, com.sap.dbtech.jdbc.DriverSapDB); env.put(Context.INITIAL_CONTEXT_FACTORY, com.sun.jndi.ldap.LdapCtxFactory); env.put(Context.PROVIDER_URL, ldap://localhost:389/;); Context ctx = new InitialContext(env); DriverAdapterCPDS cpds = new DriverAdapterCPDS(); cpds.setUrl(connectURI); cpds.setUser(username); cpds.setPassword(password); cpds.setMaxActive(6); cpds.setDriver(com.sap.dbtech.jdbc.DriverSapDB); String dsbindString = cn=cpd,ou=JavaObjects,dc=mycompany,dc=com; ctx.rebind(dsbindString, cpds); Jdbc2PoolDataSource tds = new Jdbc2PoolDataSource(); tds.setJndiEnvironment (ctx.INITIAL_CONTEXT_FACTORY, com.sun.jndi.ldap.LdapCtxFactory); tds.setJndiEnvironment(ctx.PROVIDER_URL, ldap://localhost:389/;); tds.setDefaultMaxActive(3); tds.setDataSourceName(dsbindString); String pooldsbindString = cn=SapdbDSApacheJdbc,ou=JavaObjects,dc=mycompany,dc=com; ctx.rebind(pooldsbindString,tds); My Client java file: private static String connectURI = jdbc:sapdb://LOCALHOST/mydb; private static String username = myusername; private static String password = mypassword; String pooldsbindString = cn=SapdbDSApacheJdbc,ou=JavaObjects,dc=mycompany,dc=com; Properties env2 = new Properties(); env2.put(Context.INITIAL_CONTEXT_FACTORY, com.sun.jndi.ldap.LdapCtxFactory); env2.put(Context.PROVIDER_URL, ldap://localhost:389/;); env2.put(Context.SECURITY_AUTHENTICATION,simple); env2.put(Context.REFERRAL,follow); env2.put(Context.SECURITY_PRINCIPAL, cn=myname); env2.put(Context.SECURITY_CREDENTIALS,mypassword); env2.put(com.sun.jndi.ldap.connect.pool, true); env2.put(databaseName, mydb); env2.put(user, username); env2.put(password, password); env2.put(url, connectURI); env2.put(driver, com.sap.dbtech.jdbc.DriverSapDB); DirContext ctx2 = new InitialDirContext(env2); Jdbc2PoolDataSource ref = (Jdbc2PoolDataSource)ctx2.lookup(pooldsbindString); Connection cn = (Connection)ref.getConnection(username,password); Statement stmt = cn.createStatement(); - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: cvs commit: jakarta-commons/beanutils/src/test/org/apache/commons/beanutils PropertyUtilsTestCase.java TestBean.java
I'm confused as to what part of Section 8.3.1 of the Java Beans spec defines this
behaviour. I'm looking at version 1.01 - is there a newer revision?
quote
By default, we use design patterns to locate properties by looking for methods of the
form:
public PropertyType get PropertyName();
public void set PropertyName( PropertyType a);
If we discover a matching pair of getPropertyName and setPropertyName methods
that take and return the same type, then we regard these methods as defining a
read-write property whose name will be propertyName. We will use the
getPropertyName method to get the property value and the setPropertyName
method to set the property value. The pair of methods may be located either in the
same class or one may be in a base class and the other may be in a derived class.
If we find only one of these methods, then we regard it as defining either a read-only
or a writeonly property called propertyName
By default we assume that properties are neither bound nor constrained (see Section 7).
So a simple read-write property foo might be represented by a pair of methods:
public Wombat getFoo();
public void setFoo(Wombat w);
/quote
Section 8.3.2 goes on to note that ispropertyName, if present, will be used
preferentially for boolean properties.
However, at least this text does not specify what happens if the setMethod takes a
different type than the get method returns. There is nothing that suggests the get/is
method has precedence over the set method.
Am I missing something (either here, or in the spec)?
-AMT
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 03, 2003 12:10 PM
To: [EMAIL PROTECTED]
Subject: cvs commit: jakarta-commons/beanutils/src/test/org/apache/commons/beanutils
PropertyUtilsTestCase.java TestBean.java
craigmcc2003/07/03 12:10:27
Modified:beanutils/src/test/org/apache/commons/beanutils
PropertyUtilsTestCase.java TestBean.java
Log:
Add a unit test to verify the current JDK introspection of a bean with
the following method signatures:
public boolean isFoo();
public boolean getFoo();
public void setFoo(String foo);
According to Section 8.3.1 of the JavaBeans Specification, this
will get recognized as a read-only boolean property using isFoo
as the getter method. Therefore, all of the code in commons-beanutils
should make this same assumption as well.
One could argue that it would make more sense to not recognize foo
as a property at all, since the types on the getter and setter methods
are different. However, that's not the way the JavaBeans spec is worded,
and not the way that the JDK's introspection logic works either.
Revision ChangesPath
1.31 +31 -4
jakarta-commons/beanutils/src/test/org/apache/commons/beanutils/PropertyUtilsTestCase.java
Index: PropertyUtilsTestCase.java
===
RCS file:
/home/cvs/jakarta-commons/beanutils/src/test/org/apache/commons/beanutils/PropertyUtilsTestCase.java,v
retrieving revision 1.30
retrieving revision 1.31
diff -u -r1.30 -r1.31
--- PropertyUtilsTestCase.java12 May 2003 21:42:56 - 1.30
+++ PropertyUtilsTestCase.java3 Jul 2003 19:10:27 - 1.31
@@ -452,6 +452,33 @@
/**
+ * pNegative tests on an invalid property with two different boolean
+ * getters (which is fine, according to the JavaBeans spec) but a
+ * String setter instead of a boolean setter./p
+ *
+ * pAlthough one could logically argue that this combination of method
+ * signatures should not identify a property at all, there is a sentence
+ * in Section 8.3.1 making it clear that the behavior tested for here
+ * is correct: If we find only one of these methods, then we regard
+ * it as defining either a read-only or write-only property called
+ * emlt;property-namegt;/em./p
+ */
+public void testGetDescriptorInvalidBoolean() throws Exception {
+
+ PropertyDescriptor pd =
+ PropertyUtils.getPropertyDescriptor(bean, invalidBoolean);
+ assertNotNull(invalidBoolean is a property, pd);
+ assertNotNull(invalidBoolean has a getter method,
+ pd.getReadMethod());
+ assertNull(invalidBoolean has no write method,
+pd.getWriteMethod());
+ assertTrue(invalidBoolean getter method is isInvalidBoolean,
+isInvalidBoolean.equals(pd.getReadMethod().getName()));
+
+}
+
+
+/**
* Positive getPropertyDescriptor on property codelongProperty/code.
*/
public void testGetDescriptorLong() {
1.16 +35 -4
jakarta-commons/beanutils/src/test/org/apache/commons/beanutils/TestBean.java
Index: TestBean.java
===
RE: [OT] Eclipse, Javadoc, and cvs in @version tags
If it doesn't replace well use $Id: $ etc :) (in eclipse you type $$Id: $$ btw. Check if your files are actually checked in in kkv mode (see Team-Change ASCII/Binary property. I had everything checked in once (not here though) as ko, since that was / is the default in eclipse. Mvgr, Martin On Wed, 2003-07-09 at 22:17, Noel J. Bergman wrote: I'm trying to setup a javadoc template in Eclipse to handle cvs verisioning in Javadoc comments. @version $Revision$ Or @version CVS $Revision$ $Date$ Or @version $Id$ Or ... :-) I assume it happens on the server side but I'm not positive. On the server. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Martin van den Bemt [EMAIL PROTECTED] mvdb.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Java Bean Specification: PropertyUtilsTestCase.java TestBean.java
I'm confused as to what part of Section 8.3.1 of the Java Beans spec defines this
behaviour. I'm looking at version 1.01 - is there a newer revision?
quote
By default, we use design patterns to locate properties by looking for methods of the
form:
public PropertyType get PropertyName();
public void set PropertyName( PropertyType a);
If we discover a matching pair of getPropertyName and setPropertyName methods
that take and return the same type, then we regard these methods as defining a
read-write property whose name will be propertyName. We will use the
getPropertyName method to get the property value and the setPropertyName
method to set the property value. The pair of methods may be located either in the
same class or one may be in a base class and the other may be in a derived class.
If we find only one of these methods, then we regard it as defining either a read-only
or a writeonly property called propertyName
By default we assume that properties are neither bound nor constrained (see Section 7).
So a simple read-write property foo might be represented by a pair of methods:
public Wombat getFoo();
public void setFoo(Wombat w);
/quote
Section 8.3.2 goes on to note that ispropertyName, if present, will be used
preferentially for boolean properties.
However, at least this text does not specify what happens if the setMethod takes a
different type than the get method returns. There is nothing that suggests the get/is
method has precedence over the set method.
Am I missing something (either here, or in the spec)?
-AMT
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 03, 2003 12:10 PM
To: [EMAIL PROTECTED]
Subject: cvs commit: jakarta-commons/beanutils/src/test/org/apache/commons/beanutils
PropertyUtilsTestCase.java TestBean.java
craigmcc2003/07/03 12:10:27
Modified:beanutils/src/test/org/apache/commons/beanutils
PropertyUtilsTestCase.java TestBean.java
Log:
Add a unit test to verify the current JDK introspection of a bean with
the following method signatures:
public boolean isFoo();
public boolean getFoo();
public void setFoo(String foo);
According to Section 8.3.1 of the JavaBeans Specification, this
will get recognized as a read-only boolean property using isFoo
as the getter method. Therefore, all of the code in commons-beanutils
should make this same assumption as well.
One could argue that it would make more sense to not recognize foo
as a property at all, since the types on the getter and setter methods
are different. However, that's not the way the JavaBeans spec is worded,
and not the way that the JDK's introspection logic works either.
Revision ChangesPath
1.31 +31 -4
jakarta-commons/beanutils/src/test/org/apache/commons/beanutils/PropertyUtilsTestCase.java
Index: PropertyUtilsTestCase.java
===
RCS file:
/home/cvs/jakarta-commons/beanutils/src/test/org/apache/commons/beanutils/PropertyUtilsTestCase.java,v
retrieving revision 1.30
retrieving revision 1.31
diff -u -r1.30 -r1.31
--- PropertyUtilsTestCase.java12 May 2003 21:42:56 - 1.30
+++ PropertyUtilsTestCase.java3 Jul 2003 19:10:27 - 1.31
@@ -452,6 +452,33 @@
/**
+ * pNegative tests on an invalid property with two different boolean
+ * getters (which is fine, according to the JavaBeans spec) but a
+ * String setter instead of a boolean setter./p
+ *
+ * pAlthough one could logically argue that this combination of method
+ * signatures should not identify a property at all, there is a sentence
+ * in Section 8.3.1 making it clear that the behavior tested for here
+ * is correct: If we find only one of these methods, then we regard
+ * it as defining either a read-only or write-only property called
+ * emlt;property-namegt;/em./p
+ */
+public void testGetDescriptorInvalidBoolean() throws Exception {
+
+ PropertyDescriptor pd =
+ PropertyUtils.getPropertyDescriptor(bean, invalidBoolean);
+ assertNotNull(invalidBoolean is a property, pd);
+ assertNotNull(invalidBoolean has a getter method,
+ pd.getReadMethod());
+ assertNull(invalidBoolean has no write method,
+pd.getWriteMethod());
+ assertTrue(invalidBoolean getter method is isInvalidBoolean,
+isInvalidBoolean.equals(pd.getReadMethod().getName()));
+
+}
+
+
+/**
* Positive getPropertyDescriptor on property codelongProperty/code.
*/
public void testGetDescriptorLong() {
1.16 +35 -4
jakarta-commons/beanutils/src/test/org/apache/commons/beanutils/TestBean.java
Index: TestBean.java
===
cvs commit: jakarta-commons/lang/src/java/org/apache/commons/lang StringUtils.java
bayard 2003/07/09 16:54:16 Modified:lang/src/java/org/apache/commons/lang StringUtils.java Log: Removed the unnecessary 'A' from join's char separator javadocs. Revision ChangesPath 1.53 +3 -3 jakarta-commons/lang/src/java/org/apache/commons/lang/StringUtils.java Index: StringUtils.java === RCS file: /home/cvs/jakarta-commons/lang/src/java/org/apache/commons/lang/StringUtils.java,v retrieving revision 1.52 retrieving revision 1.53 diff -u -r1.52 -r1.53 --- StringUtils.java 8 Jul 2003 05:59:58 - 1.52 +++ StringUtils.java 9 Jul 2003 23:54:16 - 1.53 @@ -652,7 +652,7 @@ * pJoins the elements of the provided array into a single String * containing the provided list of elements./p * - * pNo delimiter is added before or after the list. A + * pNo delimiter is added before or after the list. * * @param array the array of values to join together * @param separator the separator character to use @@ -698,7 +698,7 @@ * pJoins the elements of the provided codeIterator/code into * a single String containing the provided elements./p * - * pNo delimiter is added before or after the list. A + * pNo delimiter is added before or after the list. * * @param iterator the codeIterator/code of values to join together * @param separator the separator character to use - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/mapper/src/share/org/apache/commons/mapper/jdbc JdbcHelper.java
dgraham 2003/07/09 17:27:30
Modified:mapper/src/share/org/apache/commons/mapper/jdbc
JdbcHelper.java
Log:
Added getConnection() method and made DataSource protected.
Revision ChangesPath
1.5 +397 -375
jakarta-commons-sandbox/mapper/src/share/org/apache/commons/mapper/jdbc/JdbcHelper.java
Index: JdbcHelper.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/mapper/src/share/org/apache/commons/mapper/jdbc/JdbcHelper.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- JdbcHelper.java 10 Jun 2003 04:14:31 - 1.4
+++ JdbcHelper.java 10 Jul 2003 00:27:29 - 1.5
@@ -81,377 +81,399 @@
*/
public class JdbcHelper {
-/**
- * An implementation of StatementPreparer that does nothing. Useful when there
- * are no replacement parameters to be set on the PreparedStatement.
- */
-private static final StatementPreparer NULL_PREPARER = new StatementPreparer() {
-public void prepareStatement(PreparedStatement stmt, Object obj)
-throws SQLException {
-; // do nothing
-}
-};
-
-/**
- * An implementation of StatementPreparer that fills a PreparedStatement
- * with values from an Object[].
- */
-private static final StatementPreparer ARRAY_PREPARER =
-new StatementPreparer() {
-public void prepareStatement(PreparedStatement stmt, Object obj)
-throws SQLException {
-
-Object[] args = (Object[]) obj;
-for (int i = 0; i args.length; i++) {
-stmt.setObject(i + 1, args[i]);
-}
-}
-};
-
-private DataSource ds = null;
-
-/**
- * Constructor for JdbcHelper.
- * @param ds The DataSource to get Connections from.
- */
-public JdbcHelper(DataSource ds) {
-super();
-this.ds = ds;
-}
-
-/**
- * Executes the given INSERT, UPDATE, or DELETE SQL statement. The
- * statement is executed in it's own transaction that will be committed or
rolled
- * back depending on any SQLExceptions thrown.
- * @param sql The SQL statement to execute.
- * @param preparer Initializes the PreparedStatement's IN (ie. '?') parameters.
- * @param prepareObject An object to pass to the preparer to setup the
- * PreparedStatement.
- * @throws MapperException
- * @return The number of rows updated.
- */
-public int executeUpdate(
-String sql,
-StatementPreparer preparer,
-Object prepareObject)
-throws MapperException {
-
-Connection conn = null;
-PreparedStatement stmt = null;
-boolean autoCommit = false;
-int rows = 0;
-
-try {
-conn = this.ds.getConnection();
-autoCommit = conn.getAutoCommit(); // save old value
-conn.setAutoCommit(false); // single transaction.
-
-stmt = conn.prepareStatement(sql);
-preparer.prepareStatement(stmt, prepareObject);
-rows = stmt.executeUpdate();
-
-conn.commit();
-
-} catch (SQLException e) {
-this.rollback(conn);
-throw new MapperException(e);
-} finally {
-this.setAutoCommit(autoCommit, conn);
-this.closeStatement(stmt);
-this.closeConnection(conn);
-}
-
-return rows;
-}
-
-/**
- * Executes the given INSERT, UPDATE, or DELETE SQL statement. The
- * statement is executed in it's own transaction that will be committed or
rolled
- * back depending on any SQLExceptions thrown.
- * @param sql The SQL statement to execute.
- * @param params An array of values to fill the sql '?' markers with.
- * @throws MapperException
- * @return The number of rows updated.
- */
-public int executeUpdate(String sql, Object[] params) throws MapperException {
-return this.executeUpdate(sql, ARRAY_PREPARER, params);
-}
-
-/**
- * Executes the given INSERT, UPDATE, or DELETE SQL statement. The
- * statement is executed in it's own transaction that will be committed or
rolled
- * back depending on any SQLExceptions thrown. This is
- * useful for queries with only one replacement parameter and is the equivalent
of
- * calling executeUpdate(sql, new Object[] { param }).
- * @param sql The SQL statement to execute.
- * @param param An object to fill one sql '?' marker with.
- * @throws MapperException
- * @return The number of rows updated.
- */
-public int executeUpdate(String sql, Object param) throws MapperException {
-
Removing WordWrapUtils.wordWrap Was: [lang] Javadocfixes and minorchanges
Anyone mind if I remove the wordWrap methods from WordWrapUtils? It does not implement the split parameter currently, and in that case it's hard to see what difference it has with the wrapText method. Hen On Tue, 8 Jul 2003, Fredrik Westermarck wrote: Hi! The following patch includes some javadoc fixes (RandomStringUtils, StringEscapeUtils, StringUtils, SystemUtils and WordWrapUtils), mostly formatting. In StringUtils I also changed rightPad(String, int), leftPad(String, int) and leftPad(String, int, char) to use ' ' instead of when calling left-/rightPad. I found some incomplete javadoc in StringUtils for join(Object[] array, char separator) and join(Iterator iterator, char separator). In WordWrapUtils the parameter split is never used in wordWrap(String, int, String, String). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/hivemind .classpath project.xml
dion2003/07/09 18:20:58 Modified:hivemind .classpath project.xml Log: Update classpath to handle uploaded location of javassist Removed mx4j from classpath as it wasn't being used and causing errors Revision ChangesPath 1.9 +1 -3 jakarta-commons-sandbox/hivemind/.classpath Index: .classpath === RCS file: /home/cvs/jakarta-commons-sandbox/hivemind/.classpath,v retrieving revision 1.8 retrieving revision 1.9 diff -u -r1.8 -r1.9 --- .classpath9 Jul 2003 11:27:23 - 1.8 +++ .classpath10 Jul 2003 01:20:57 - 1.9 @@ -20,8 +20,6 @@ classpathentry kind=var path=MAVEN_REPO/ant/jars/ant-1.5.1.jar/ classpathentry kind=var path=MAVEN_REPO/tapestry/jars/tapestry-3.0-beta-1a.jar/ classpathentry kind=var path=MAVEN_REPO/jboss/jars/jboss-j2ee-3.2.1.jar/ -classpathentry kind=var path=MAVEN_REPO/mx4j/jars/mx4j-jmx-1.1.1.jar/ -classpathentry kind=var -path=MAVEN_REPO/javassist/jars/javassist-2.5.1.jar sourcepath=DOWNLOADS/Misc/javassist-2.5.1.zip/ +classpathentry kind=var path=MAVEN_REPO/jboss/jars/javassist-2.5.1.jar/ classpathentry kind=output path=bin/ /classpath 1.12 +3 -2 jakarta-commons-sandbox/hivemind/project.xml Index: project.xml === RCS file: /home/cvs/jakarta-commons-sandbox/hivemind/project.xml,v retrieving revision 1.11 retrieving revision 1.12 diff -u -r1.11 -r1.12 --- project.xml 9 Jul 2003 11:27:23 - 1.11 +++ project.xml 10 Jul 2003 01:20:58 - 1.12 @@ -163,7 +163,8 @@ /dependency dependency - idjavassist/id + groupIdjboss/groupId + artifactIdjavassist/artifactId version2.5.1/version /dependency /dependencies - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: cvs commit: jakarta-commons/beanutils/src/test/org/apache/commons/beanutilsPropertyUtilsTestCase.java TestBean.java
On Wed, 9 Jul 2003, Arun Thomas wrote: Date: Wed, 9 Jul 2003 16:28:07 -0700 From: Arun Thomas [EMAIL PROTECTED] Reply-To: Jakarta Commons Developers List [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Subject: RE: cvs commit: jakarta-commons/beanutils/src/test/org/apache/commons/beanutils PropertyUtilsTestCase.java TestBean.java I'm confused as to what part of Section 8.3.1 of the Java Beans spec defines this behaviour. I'm looking at version 1.01 - is there a newer revision? No ... that's the most current. quote By default, we use design patterns to locate properties by looking for methods of the form: public PropertyType get PropertyName(); public void set PropertyName( PropertyType a); If we discover a matching pair of getPropertyName and setPropertyName methods that take and return the same type, then we regard these methods as defining a read-write property whose name will be propertyName. We will use the getPropertyName method to get the property value and the setPropertyName method to set the property value. The pair of methods may be located either in the same class or one may be in a base class and the other may be in a derived class. If we find only one of these methods, then we regard it as defining either a read-only or a writeonly property called propertyName This is the key sentence. The introspection code will find getFoo() and isFoo() that return boolean and pick isFoo(), but they won't find setFoo(boolean). Therefore, the JDK thinks that there is a read-only boolean property named foo. It would have made more sense to me for introspection to decide that there was no property at all because of the type mismatch on the setter, but alas that is not the way it actually works, so it's nothing BeanUtils can really do anything about anyway (i.e. I will veto any suggestion that BeanUtils define properties in any way different than what the standard JDK introspection does). By default we assume that properties are neither bound nor constrained (see Section 7). So a simple read-write property foo might be represented by a pair of methods: public Wombat getFoo(); public void setFoo(Wombat w); /quote Section 8.3.2 goes on to note that ispropertyName, if present, will be used preferentially for boolean properties. However, at least this text does not specify what happens if the setMethod takes a different type than the get method returns. There is nothing that suggests the get/is method has precedence over the set method. Am I missing something (either here, or in the spec)? I don't see anything explicit in the spec either ... all I see is what JDKs actually do. -AMT Craig -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, July 03, 2003 12:10 PM To: [EMAIL PROTECTED] Subject: cvs commit: jakarta-commons/beanutils/src/test/org/apache/commons/beanutils PropertyUtilsTestCase.java TestBean.java craigmcc2003/07/03 12:10:27 Modified:beanutils/src/test/org/apache/commons/beanutils PropertyUtilsTestCase.java TestBean.java Log: Add a unit test to verify the current JDK introspection of a bean with the following method signatures: public boolean isFoo(); public boolean getFoo(); public void setFoo(String foo); According to Section 8.3.1 of the JavaBeans Specification, this will get recognized as a read-only boolean property using isFoo as the getter method. Therefore, all of the code in commons-beanutils should make this same assumption as well. One could argue that it would make more sense to not recognize foo as a property at all, since the types on the getter and setter methods are different. However, that's not the way the JavaBeans spec is worded, and not the way that the JDK's introspection logic works either. Revision ChangesPath 1.31 +31 -4 jakarta-commons/beanutils/src/test/org/apache/commons/beanutils/PropertyUtilsTestCase.java Index: PropertyUtilsTestCase.java === RCS file: /home/cvs/jakarta-commons/beanutils/src/test/org/apache/commons/beanutils/PropertyUtilsTestCase.java,v retrieving revision 1.30 retrieving revision 1.31 diff -u -r1.30 -r1.31 --- PropertyUtilsTestCase.java 12 May 2003 21:42:56 - 1.30 +++ PropertyUtilsTestCase.java 3 Jul 2003 19:10:27 - 1.31 @@ -452,6 +452,33 @@ /** + * pNegative tests on an invalid property with two different boolean + * getters (which is fine, according to the JavaBeans spec) but a + * String setter instead of a boolean setter./p + * + * pAlthough one could logically argue that this combination of method + * signatures should not identify a property at all, there is a sentence + * in Section 8.3.1 making it clear
DO NOT REPLY [Bug 21455] New: - exception when logging in JDK 1.3 with Lumberjack
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21455.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21455
exception when logging in JDK 1.3 with Lumberjack
Summary: exception when logging in JDK 1.3 with Lumberjack
Product: Commons
Version: Nightly Builds
Platform: All
OS/Version: All
Status: NEW
Severity: Normal
Priority: Other
Component: Logging
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
The JDK 1.4 logging tests do not test for the Throwable class having the method
getStackTrace() which is only available in 1.4. Below is the exception and
sample source code to recreate. (first encountered in generic initialization of
the struts 1.1 ActionServlet which throws an empty ServletException when this
happens)
---
Exception in thread main java.lang.NoSuchMethodError
at org.apache.commons.logging.impl.Jdk14Logger.log(Jdk14Logger.java:116)
at org.apache.commons.logging.impl.Jdk14Logger.fatal
(Jdk14Logger.java:177)
at CommonsLoggingTest.main(CommonsLoggingTest.java:19)
---
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import java.util.logging.*;
public class CommonsLoggingTest {
protected static Log log = LogFactory.getLog(SchemaTest.class);
public static void main(String[] args) {
log.fatal(testing, new Exception(test));
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21455] - exception when logging in JDK 1.3 with Lumberjack
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21455. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21455 exception when logging in JDK 1.3 with Lumberjack [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |ASSIGNED - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re[4]: [dbcp] Do we need Referenceable?
Hello John, AT With Tomcat we're in a different position. JM What happens if tomcat changes its process to use the standard jndi JM pattern described above? What about a developer wishing to use dbcp JM with another servlet container or app server? Why are you advocating JM that dbcp tie itself exclusively to implementation details of tomcat? JM (btw, i do use tomcat almost exclusively myself). AT But what use for our product to implement Referenceable then? AT It will never have Context.bind() called on it. JM How can you presume that? Well, I'm changing my argumentation now, but not the outcome :) While the Referenceable and Serializable capabilities are generally useful for JNDI boun objects I think that with Pool objects this is not the case. In fact the Pool should be a sort of a singletone. Strictly one instance per the Context it has been bound to. (Yes I know there may be multiple JNDI paths leading to the same location, but lets assume that there is only one home context it is being bound to. And there should be strictly one pool per each binding to a home context.) Then the only meaningful reference that can exist to this object is the object itself. Or, we can have some static HashMap that maps id - instance, and then the id will be a good reference too, but essentially this is not different from a real object reference is it? The pool reference won't make sense out of JVM (or even maybe a classloader it came from). So I state: though in general it is advisable for JNDI bound objects to be Serializable/Referenceable with Pools this is not the case. A pool should be bound into JNDI directly, not a reference to it. Same with any quasi-singletone object (in the sense defined above). If someone will search for a way to use DBCP out of Tomcat with JNDI his best bet will be to a) initialize an instance of the Pool (not the factory even) with appropriate settings b) bind it to JNDI directly Any references would be meaningless. BTW I feel that Tomcat way of doing things with JNDI is also bad for us. It would be highly preferable to bind the Pool not the factory to the Cotext. (Since if more then one pool is configured in Tomcat, it may well happen that only a single factory will be instantiated, so I'm probably going to talk that over on Tomcat user or dev list, when I have time, ha-ha! :) - Anton - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21257] - [HttpClient][patch]A more flexible SSLProtocolSocketFactory WRT SSLSocketFactory.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21257. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21257 [HttpClient][patch]A more flexible SSLProtocolSocketFactory WRT SSLSocketFactory. [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21202] - wire logger skips empty line
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21202. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21202 wire logger skips empty line [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20240] - Cookies with null path attribute are rejected in the compatibility mode
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20240. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20240 Cookies with null path attribute are rejected in the compatibility mode [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 19373] - Performance Optimizations
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19373. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19373 Performance Optimizations [EMAIL PROTECTED] changed: What|Removed |Added Target Milestone|2.0 Beta 2 |2.0 Final - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 19868] - Exception handling in HttpClient requires redesign
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19868. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19868 Exception handling in HttpClient requires redesign [EMAIL PROTECTED] changed: What|Removed |Added Target Milestone|2.1 Final |2.1 Alpha 1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 10813] - RFC 2965 Support (Port sensitive cookies)
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10813. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10813 RFC 2965 Support (Port sensitive cookies) [EMAIL PROTECTED] changed: What|Removed |Added Target Milestone|2.1 Final |3.0 Final - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21210] - HeaderElement#parse(String) implementation is not optimal
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21210. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21210 HeaderElement#parse(String) implementation is not optimal [EMAIL PROTECTED] changed: What|Removed |Added Target Milestone|2.1 Final |2.1 Alpha 1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 16907] - Introduce Aspect oriented programming
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16907. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16907 Introduce Aspect oriented programming [EMAIL PROTECTED] changed: What|Removed |Added Target Milestone|2.1 Final |3.0 Final - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
