Re: [configuration][patch] Support for object creation
Hello Eric, thank you for your response. Well, as far as I understand the Digester project, it is a tool that transforms an XML file into an object hierarchy based on certain rules. So one could argue that Digester could replace most of the stuff in the Configuration project by processing (XML) configuration files and creating specific objects an application could use to access its configuration. But the approach of Configuration seems to be a bit different and - as I think - for many applications that just whant to access configuration properties much easier to use: different configuration sources are collected and provided to an application as a single Configuration object. So an application needs only to obtain a Configuration object and query it for single properties instead of bothering with Digester rules. What my code does can be simply seen as adding a new data type to the properties already supported by Configuration: the type configurable object instance. So like an application can ask a Configuration object for a string or long property it can now obtain ready initialized objects. I think this is just an extension to Configuration and does not overlap with Digester. For an application that uses such configurable objects and that already is a client of Configuration it would be more convenient to access these objects directly through Configuration than to set up a set of Digester rules and call this component, too. My code is also not quite complicated; the initialization of the newly created object is internally handled by BeanUtils. The whole thing was intended to be an additional and easy to implement feature for Configuration. What do you think? Oli - Original Message - From: Eric Pugh [EMAIL PROTECTED] To: 'Jakarta Commons Developers List' [EMAIL PROTECTED] Sent: Tuesday, October 07, 2003 11:30 AM Subject: RE: [configuration][patch] Support for object creation Oliver.. Sorry I missed your earlier post.. So, have you looked at the Digester commons project? I think it does similar to what your code does.. It takes in an XML file with various rules about constructores etc and then builds the objects from that. There is also in (I think :-) ) beanutils a simple version of Digester that hides away a lot of the complexity of digester.. Could you highlight how your code and digester are different? It seems also that what you have done might be better applied to digester as a simple xml format.. Lastly, would it make sense to write a digester friendly configuration converter? In otherwords, something that would take a configuration objects, feed it to digester and get back objects? Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Digester][PATCH] ObjectParamRule support for XML rules
Hi,
I've added support for the ObjectParamRule in XML rules file for the
Digester. The syntax is as follows:
!--
ObjectParamRule
attrname - an arbitrary Object defined programatically, assigned if the
element pattern AND specified attribute name are matched
param - an arbitrary Object defined programatically, assigned when the
element pattern associated with the Rule is matched
type - class name for object
value - initial value for the object
--
!ELEMENT object-param-rule EMPTY
!ATTLIST object-param-rule
pattern CDATA #IMPLIED
paramnumber CDATA #REQUIRED
param CDATA #REQUIRED
attrname CDATA #IMPLIED
type CDATA #REQUIRED
value CDATA #IMPLIED
XML example:
object-param-rule paramnumber=0 type=java.lang.String
value=meter.serial/
Generaly, type attribute can be any Java type. The value can be a string
representation of any type that stnaddard ConvertUtils classes are capable
to convert into the corresponding object instance.
Tow files are patched:
DigesterRuleParser.java
digester-rules.dtd
Regards,
Anton
_
The new MSN 8: advanced junk mail protection and 2 months FREE*
http://join.msn.com/?page=features/junkmail
--- source/DigesterRuleParser.java 2003-04-16 12:23:52.0 +0400
+++ target/DigesterRuleParser.java 2003-10-07 11:37:58.0 +0400
@@ -68,7 +68,9 @@
import java.util.Set;
import java.util.StringTokenizer;
+import org.apache.commons.beanutils.ConvertUtils;
import org.apache.commons.collections.ArrayStack;
+import org.apache.commons.digester.*;
import org.apache.commons.digester.AbstractObjectCreationFactory;
import org.apache.commons.digester.BeanPropertySetterRule;
import org.apache.commons.digester.CallMethodRule;
@@ -249,6 +251,10 @@
digester.addRule(*/call-param-rule, new PatternRule(pattern));
digester.addSetNext(*/call-param-rule, add, ruleClassName);
+digester.addFactoryCreate(*/object-param-rule, new
ObjectParamRuleFactory());
+digester.addRule(*/object-param-rule, new
PatternRule(pattern));
+digester.addSetNext(*/object-param-rule, add, ruleClassName);
+
digester.addFactoryCreate(*/factory-create-rule, new
FactoryCreateRuleFactory());
digester.addRule(*/factory-create-rule, new
PatternRule(pattern));
digester.addSetNext(*/factory-create-rule, add, ruleClassName);
@@ -597,6 +603,42 @@
}
/**
+ * Factory for creating a ObjectParamRule
+ */
+protected class ObjectParamRuleFactory extends
AbstractObjectCreationFactory
+{
+public Object createObject(Attributes attributes) throws Exception
{
+// create callparamrule
+int paramIndex =
Integer.parseInt(attributes.getValue(paramnumber));
+String attributeName = attributes.getValue(attrname);
+String type = attributes.getValue(type);
+String value = attributes.getValue(value);
+
+Rule objectParamRule = null;
+
+// type name is requried
+if (type == null)
+throw new RuntimeException(Attribute 'type' is
requried.);
+
+// create object instance
+Object param = null;
+Class clazz = Class.forName(type);
+if (value == null)
+param = clazz.newInstance();
+else {
+param = ConvertUtils.convert(value, clazz);
+}
+
+if (attributeName == null) {
+objectParamRule = new ObjectParamRule( paramIndex, param);
+} else {
+objectParamRule = new ObjectParamRule( paramIndex,
attributeName, param);
+}
+return objectParamRule;
+}
+}
+
+/**
* Factory for creating a FactoryCreateRule
*/
protected class FactoryCreateRuleFactory extends
AbstractObjectCreationFactory {
--- source/digester-rules.dtd 2003-03-27 18:54:46.0 +0300
+++ target/digester-rules.dtd 2003-10-07 10:57:54.0 +0400
@@ -10,13 +10,13 @@
Digester is a framework for pattern-matching-based parsing of XML into
Java objects. See http://jakarta.apache.org/commons/digester.html.
--
-!ENTITY % rule-elements bean-property-setter-rule | call-method-rule |
call-param-rule |
+!ENTITY % rule-elements bean-property-setter-rule | call-method-rule |
call-param-rule | object-param-rule |
factory-create-rule | object-create-rule |
set-properties-rule | set-property-rule | set-top-rule |
set-next-rule
!-- digester-rules is the root element. --
-!ELEMENT digester-rules (pattern | include | bean-property-setter-rule |
call-method-rule | call-param-rule | factory-create-rule |
object-create-rule | set-properties-rule | set-property-rule | set-top-rule
| set-next-rule )*
+!ELEMENT digester-rules (pattern | include | bean-property-setter-rule |
call-method-rule | call-param-rule |
RE: [configuration] AbstractConfiguration
Re: [configuration] AbstractConfigurationKonstantin, I have applied your patchs.. Can you do a fresh CO and just verify I applied everything properly. The unit tests all run cleanly for me. Can't wait to see your JDBC configuration! Eric -Original Message- From: Konstantin Shaposhnikov [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 30, 2003 1:08 AM To: 'Jakarta Commons Developers List' Subject: Re: [configuration] AbstractConfiguration Eric, I perform code formatting of my changes to sources. See attached patch file. I also use Eclipse for the development. Unfortunately I am behind firewall, so I can't access cvs from eclipse (because for some reason it refuses to work with socks5 proxy server), so I create patch file using cvs diff command. Then I try to apply this patch to the unmodified sources using Eclipse and everything looks fine. As for checkstyle I think that It report a lot of useless warning. F.e. about final parameters. May be we can modify checkstyle configuration to turn them off or just ignore them. Now AbstractConfiguration has 175 warnings and BaseConfiguration - 21. I modify testBoolean to return Boolean instead of String. As for additional tests it seems to me that existing tests cover addProperty/addPropertyDirect functionality. Actually this tests were very helpful for me when I perform refactoring. Also I think that later I can refactor other Configuration classes to extend AbstractConfiguration. On 17:28 Mon 29 Sep , Eric Pugh wrote: [configuration] AbstractConfigurationKonstantin, The changes look good. And I checked through the Turbine codebase, and the changes you propose don't look like they will cause problems Could you do me a favor and submit a patch file? Not sure what editor you use, but Eclipse does a good job of creating patch files. Also, run the maven site and make sure your changes don't cause more checkstyle errors. You seem to use 2 spaces for a tab versus 4, a couple other little things as well. Although actually the BaseConfiguration needs lots of checkstyle help as it has 194 violations! Don't forget to add yourself to the contributor list in the project.xml and the @author tags;-) I agree with the testBoolean, it should return a boolean value I think as well. As far as the addProperty/addPropertyDirect, I would recommend that you add a unit test to the original code that tests it. then, apply your changes, and verify the tests work the same way. To be honest, I never had to look too closely at that part. So, if you can try and resolve some of those questions, and get the formatting in line with the standard style then I'll be happy to commit these changes. And then we can discuss your JDBC implementation which I am very curious to see... Eric -Original Message- From: Konstantin Shaposhnikov [mailto:[EMAIL PROTECTED] Sent: Sunday, September 28, 2003 8:16 PM To: 'Jakarta Commons Developers List' Subject: [configuration] AbstractConfiguration Hello Eric, Pease see attached files: AbstractConfiguration.java - AbstractConfiguration class, actually this is slightly modified BaseConfiguration class (I've addes some methods and made some methods abstract) BaseConfiguration.java - BaseConfiguration class modified to extend Abstract configuration TestBaseConfiguration.java - I add one test method to test new behaviour of getString method and default configuration. All tests are passed succesfully (maven test :) . I also put some my comments in the source code. Please review them. You are talking about getObject method but there is no such method in Configuration interface. May be it will be usefull to add it? As for a JDBCConfiguration class, I actually need very specific to my project configuration implementation (using Hibernate and special logic to access database). But we can discuss this class and may be I'll implement them for commons-configuration project. In any case I think that first we should refactor existing Configuration implementations to use AbstractConfiguration (of course if you accept it). On 17:41 Fri 26 Sep, Eric Pugh wrote: Konstantin, I like your idea about trying to make things easier. I have been wanting to write a JDBCConfiguration class, but haven't gotten around to it. The BaseConfiguration works the way it does I think because it keeps config values in two seperate lists, correct? One in memory, and one loaded by the user? What if we instead create an AbstractConfiguration class that overrides everything. Then, when you implement your own, you just override the methods you want? Similar to the
RE: [HiveMind] more on BuilderFactory
Could be a step in the right direction the question is: how much of XPath do we
support? A
little as possible, I think.
So ... translators become xpath functions ... that's cool.
I like this concept because its more unique to HiveMind, rather than just a crippled
version of
Digester.
--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/tapestry
http://jakarta.apache.org/commons/sandbox/hivemind/
http://javatapestry.blogspot.com
-Original Message-
From: news [mailto:[EMAIL PROTECTED] On Behalf Of Knut Wannheden
Sent: Tuesday, October 07, 2003 6:28 AM
To: [EMAIL PROTECTED]
Subject: Re: [HiveMind] more on BuilderFactory
The more I think about this, the more I wonder if the XML
processing rules and the BuilderFactory could be joined.
Afterall, they do very similar things...
Unlike in Digester the the HiveMind processing rules are
written in XML. So how about using a more declarative
notation? Take the schema from the Startup configuration
point of the case study (descriptions skipped):
element name=task
attribute name=order required=true/
attribute name=title required=true/
attribute name=class/
attribute name=service-id/
rules
create-object
class=com.oubliette.framework.startup.service.Task/
read-attribute attribute=order property=order
translator=int/
read-attribute attribute=title property=title/
read-attribute attribute=class property=executable
translator=class/
read-attribute attribute=service-id
property=executable translator=service/
invoke-parent method=addElement/
/rules
element name=invoke-static
attribute name=class required=true/
attribute name=method/
rules
create-object
class=com.oubliette.framework.startup.service.StaticTask/
read-attribute attribute=class property=className/
read-attribute attribute=method property=methodName/
invoke-parent method=setExecutable/
/rules
/element
/element
What if this were written in a more declarative way
(resembling a pipeline as in Cocoon or Jelly) using XPath
navigations to access attribute values:
element name=task
attribute name=order required=true/
attribute name=title required=true/
attribute name=class/
attribute name=service-id/
rules
invoke-parent method=addElement
object class=com.oubliette.framework.startup.service.Task
property name=order value={int(@order)}/
property name=title value=[EMAIL PROTECTED]/
property name=executable value={class(@class)}/
property name=executable value={service(@service-id)}/
/object
/invoke-parent
/rules
element name=invoke-static
attribute name=class required=true/
attribute name=method/
rules
invoke-parent method=setExecutable
object
class=com.oubliette.framework.startup.service.StaticTask
property name=className value=[EMAIL PROTECTED]/
property name=methodName value=[EMAIL PROTECTED]/
/object
/invoke-parent
/rules
/element
/element
Note that I've used an AVT notation as in XSLT here (e.g.
[EMAIL PROTECTED]) and the translators are accessed as XPath functions.
Just an idea that occured to me.
--knut
I had a few more ideas on how BuilderFactory can be improved. These
improvements mainly address the usage and extensibility of the
service.
Right now the BuilderFactory is very flexible, but this comes at a
cost:
the
syntax is fairly complicated: there are four attributes and 17
different nested elements...
I have been thinking if all the set... elements could be replaced
with a single property element. This element could then have a
translator (or
type) attribute; e.g.
property name=foo value=22 translator=int/
Having a single element would of course mean that the translator
feature
of
the XML processing rules can't be used anymore, as the rules don't
provide conditional processing mechanisms. But the
translation could
also be performed by the service itself, as the translator
to be used
is given. If there were some kind of translator registry the
BuilderFactory could then also easily support new (even custom)
translators, without requiring its syntax to change. E.g.
property name=foo value=22.33 translator=float/
This idea could of course even be taken a step further. The
translator attribute could be skipped all together. Then
the type of
the
corresponding
setter's attribute would tell BuilderFactory what
translator to use.
Afterall, the type specified by the setter needs to be
matched by the
translator. So specifying the type of the property in the
hivemodule.xml might be considered redundant by the user.
But what about set-configuration and set-service? If the setter
specifies a java.util.List parameter, then the corresponding
configuration could be looked up, and if an interface is
required then
a service could
Re: [HiveMind] more on BuilderFactory
Could be a step in the right direction the question is: how much of
XPath do we support? A
little as possible, I think.
Yes, I used XPath here; but it was more about illustrating how I think the
processing elements could be restructured into a more intuitive form. Of
course something else could be used as well. But I thought XPath would be a
good match for this kind of thing. For example, it could be convenient to
access values of parent or child elements. Why do you think as little as
possible of XPath should be supported? Because you intend to support OGNL
and/or Jython in the future? I like XPath because you can only navigate
with it.
So ... translators become xpath functions ... that's cool.
A possibility in XPath. But I haven't thought much about it...
I like this concept because its more unique to HiveMind, rather than just
a crippled version of
Digester.
As I see it the HiveMind processing rule mechanism is a hybrid of a stripped
down RelaxNG (to define the syntax) and an XMLified Digester (to define the
correspondance in Java code). IMHO the syntax for the processing rules
could be much improved. I've been playing with different ideas and came up
with the solution presented in the last mail.
Another approach would be to split the syntax definition and the rules part
and use a pattern matching style (a la XSLT) for the rules. This makes it
easy to read for a user of the configuration or service. Continuing with
the same example:
element name=task
attribute name=order required=true/
attribute name=title required=true/
attribute name=class/
attribute name=service-id/
element name=invoke-static
attribute name=class required=true/
attribute name=method/
/element
/element
rules
template match=/task
property setter-method=addElement
object class=com.oubliette.framework.startup.service.Task
property name=order value={int(@order)}/
property name=title value=[EMAIL PROTECTED]/
property name=executable value={class(@class)}/
property name=executable value={service(@service-id)}/
apply-templates/
/object
/property
/template
template match=/task/invoke-static
property setter-method=setExecutable
object class=com.oubliette.framework.startup.service.StaticTask
property name=className value=[EMAIL PROTECTED]/
property name=methodName value=[EMAIL PROTECTED]/
/object
/property
/template
/rules
Note that I also replace the invoke-parent elements by a property with a
setter-method attribute.
--knut
--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/tapestry
http://jakarta.apache.org/commons/sandbox/hivemind/
http://javatapestry.blogspot.com
-Original Message-
From: news [mailto:[EMAIL PROTECTED] On Behalf Of Knut Wannheden
Sent: Tuesday, October 07, 2003 6:28 AM
To: [EMAIL PROTECTED]
Subject: Re: [HiveMind] more on BuilderFactory
The more I think about this, the more I wonder if the XML
processing rules and the BuilderFactory could be joined.
Afterall, they do very similar things...
Unlike in Digester the the HiveMind processing rules are
written in XML. So how about using a more declarative
notation? Take the schema from the Startup configuration
point of the case study (descriptions skipped):
element name=task
attribute name=order required=true/
attribute name=title required=true/
attribute name=class/
attribute name=service-id/
rules
create-object
class=com.oubliette.framework.startup.service.Task/
read-attribute attribute=order property=order
translator=int/
read-attribute attribute=title property=title/
read-attribute attribute=class property=executable
translator=class/
read-attribute attribute=service-id
property=executable translator=service/
invoke-parent method=addElement/
/rules
element name=invoke-static
attribute name=class required=true/
attribute name=method/
rules
create-object
class=com.oubliette.framework.startup.service.StaticTask/
read-attribute attribute=class property=className/
read-attribute attribute=method property=methodName/
invoke-parent method=setExecutable/
/rules
/element
/element
What if this were written in a more declarative way
(resembling a pipeline as in Cocoon or Jelly) using XPath
navigations to access attribute values:
element name=task
attribute name=order required=true/
attribute name=title required=true/
attribute name=class/
attribute name=service-id/
rules
invoke-parent method=addElement
object class=com.oubliette.framework.startup.service.Task
property name=order value={int(@order)}/
property name=title value=[EMAIL PROTECTED]/
property name=executable value={class(@class)}/
property name=executable value={service(@service-id)}/
/object
/invoke-parent
/rules
element name=invoke-static
attribute name=class
Re: [HiveMind] more on BuilderFactory
No, just thinking in terms of build vs. new dependencies. We need to look at the XPath component and see how easy it would be the mate it to HiveMind. Or we could just do an XPath-lite. OK, I see what you mean. http://jakarta.apache.org/commons/jxpath/index.html JXPath is a great piece of software. Jaxen (http://jaxen.org/) is another good implementation. --knut - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[validator] Password fields [WAS] Re: cvs commit: jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript validateMaxLength.js validateMinLength.js
It is inherently insecure to reveal the specific details of password
validation in client side scripting. Validator and Struts should be as
secure as possible out of the box so I am -1 on this change. Please
revert the changes until we come up with a better solution. Bugzilla
isn't the easiest place to have this discussion so it might be better
suited for commons-dev.
I thought that the length was only revealed in the error message but it is
indeed shown in snippets like:
this.maxlength='4'; this.minlength='4';
I agree that the best solution at the moment is not to use validator on
password forms.
David
--- [EMAIL PROTECTED] wrote:
rleland 2003/10/06 20:00:15
Modified:
validator/src/javascript/org/apache/commons/validator/javascript
validateMaxLength.js validateMinLength.js
Log:
Bug#: 12473
Let max/min length also cover passwords fields.
If users don't want the password min/max parameters
revealed then they shouldn't use the validator.
Currently in struts the min/max values are still
in the html, anyway. There is no easy/clean workaround.
Just don't use validator.
Revision ChangesPath
1.3 +4 -3
jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript/validateMaxLength.js
Index: validateMaxLength.js
===
RCS file:
/home/cvs/jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript/validateMaxLength.js,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- validateMaxLength.js15 Aug 2003 20:22:03 - 1.2
+++ validateMaxLength.js7 Oct 2003 03:00:15 - 1.3
@@ -13,6 +13,7 @@
var field = form[oMaxLength[x][0]];
if (field.type == 'text' ||
+field.type == 'password' ||
field.type == 'textarea') {
var iMax = parseInt(oMaxLength[x][2](maxlength));
1.4 +4 -3
jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript/validateMinLength.js
Index: validateMinLength.js
===
RCS file:
/home/cvs/jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript/validateMinLength.js,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- validateMinLength.js15 Aug 2003 20:22:03 - 1.3
+++ validateMinLength.js7 Oct 2003 03:00:15 - 1.4
@@ -13,6 +13,7 @@
var field = form[oMinLength[x][0]];
if (field.type == 'text' ||
+field.type == 'password' ||
field.type == 'textarea') {
var iMin = parseInt(oMinLength[x][2](minlength));
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
__
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23652] New: - Password validation revealed in javascript
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=23652. 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=23652 Password validation revealed in javascript Summary: Password validation revealed in javascript Product: Commons Version: 1.1.1 Platform: Other OS/Version: Other Status: NEW Severity: Critical Priority: Other Component: Validator AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The javascript does not validate password fields for security reasons; however, any rules defined on a password field still show up in the javascript (they're just not used). The min/max length and mask properties reveal sensitive information about the server-side password validation structure. The best solution at this time is to not use validator to check password fields at all but we need a better solution in the long run. See bug# 12473 for other details. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [configuration][patch] Support for object creation
Eric, I thought again about your response and now I agree with you that my code does something which theoretically Digester could do, too. But using a Digester object in my implementation seems to be massive overhead. The approach with a digester friendly configuration converter is a good idea, this would be very generic and could support many use cases including my object creation. Unfortunately it seems to be quite difficult to implement such a converter. A possibility of communicating with Digester would be to let a Configuration object trigger SAX events. Because Digester implements the org.xml.sax.ContentHandler interface it would be able to process them (I suppose, I didn't look at the source) . This has also the advantage of enabling other XMLish style processing for Configuration. My problem is now that there must be a way of extracting all available keys from a Configuration object in the correct order to feed them into Digester. With the actual implementation of BaseConfiguration this seems to be impossible because all properties are simply stored in a map. Though this is a sequenced map their original structure is lost. This is especially fatal for XML documents whose tree like structure is messed up (maybe it is not as problematic for plain properties or other configuration sources). A simple example to proof this would be a document that describes database tables as in the following fragment: ?xml version=1.0 encoding=UTF-8? config table nameUsers/name fields field nameuid/name typelong/type /field field namelastName/name typejava.lang.String/type /field field namefirstName/name typejava.lang.String/type /field /fields /table table namedocuments/name fields field namedocid/name typelong/type /field field namedocName/name typejava.lang.String/type /field field nameauthorID/name typelong/type /field /fields /table /config After this document was parsed there is no way to find out which fields belong to which table. Are there some plans to deal with this problem? I think it could be worth thinking about it because XML as a configuration format is quite important and its tree-like structure is one of its main benefits. If the tree structure could somehow be saved, it would also be possible to extend the syntax of the property keys, e.g. conf.getList(table(1).fields.field.name); would return a vector with the names of all fields of the first table or something like that. Regards Oli - Original Message - From: Eric Pugh [EMAIL PROTECTED] To: 'Jakarta Commons Developers List' [EMAIL PROTECTED] Sent: Tuesday, October 07, 2003 11:30 AM Subject: RE: [configuration][patch] Support for object creation Oliver.. Sorry I missed your earlier post.. So, have you looked at the Digester commons project? I think it does similar to what your code does.. It takes in an XML file with various rules about constructores etc and then builds the objects from that. There is also in (I think :-) ) beanutils a simple version of Digester that hides away a lot of the complexity of digester.. Could you highlight how your code and digester are different? It seems also that what you have done might be better applied to digester as a simple xml format.. Lastly, would it make sense to write a digester friendly configuration converter? In otherwords, something that would take a configuration objects, feed it to digester and get back objects? Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[HiveMind] extending BuilderFactory
Hi, Since I would like to store the ids of object created in the BuilderFactory, I think I could have 2 choices to extend the functionality of the BuilderFactory from the document. (1) create a sub-class of BuilderFactory and overwrite the method createCoreServiceImplementation(), create a new service and use that service id in the invoke-factory configuration. (2) create a new interceptor which intercepts the call to method createCoreServiceImplementation() in the BuilderFactory and the corresponding configuration in the hivemindmodule.xml. Since using the 1st choice requires to copy the definitions of service hivemind.BuilderFactory from hivemind's to my copy of hivemindmodule.xml file, I prefer the 2nd way (more simple - in setup the configuration file hivemindmodule.xml - than the 1st one and not affected by the changes of parameters-schema defined in hivemind.BuilderFactory) and try it out. But I notes from the debug log that the system creates multiple instances of the BuilderFactory the interceptor - one for each invoke-factory config in the xml file. If I replace my interceptor with the hivemind.LoggingInterceptor, the behavior is the same. I would like to know if this is the system behavior if I add a interceptor in the service hivemind.BuilderFactory since the instantiation of interceptor requests the hivemind.BuilderFactory service. And could you suggest a better way to do that? Otherwise I will go for the 1st one. Thanks, Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [BeanUtils] Interesting Microbenchmarks
This would be great, and here's the good news: http://www.objectweb.org/wws/arc/architecture/2003-10/msg00048.html Chris Nokleberg wrote: I finally got around to adding a dedicated BeanCopier class to CGLIB. The API looks something like: BeanCopier copier = BeanCopier.create(bean1.getClass(), bean2.getClass()); copier.copy(bean1, bean2); The copiers are cached, but if you can reuse the very same instance you get much faster times, so I've benchmarked both ways. This is for 10 iterations on JDK 1.4.2_01 (Linux). CGLIB? Reuse copier? Duration -- - No N/A 4,110 ms-- PU.copyProperties(bean,bean) YesNo 87 ms YesYes 5 ms The results were better than I expected :-) The generated code is very simple which I think lets HotSpot really go to town. Chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [beanutils] some ideas
Okay, I suck on doing things 'tonight' :) Have been playing with the code though, as it's fun stuff. How are you feeling about drafting up the proposal etc Matt? One problem I've hit is that inheritence is kind of useless. You'll just get a ClassCast in most usages: Converter converter = ConverterRegistry.getConverter(String.class, java.sql.Date.class); preparedStatement.setDate(1, converter.convert(java.sql.Date.class, someString) ); If there's no sql.Date converter, it then finds a util.Date converter. Converts and promptly dies. Inheritence on the fromClass side may still make sense. For most people, this basically means Object-String. Hen On Mon, 29 Sep 2003, Henri Yandell wrote: I have a [convert] sitting on my laptop that I can commit into the sandbox tonight. It's just an extraction of tests/src from beanutils. I wasn't sure if that was the right way to go. Hen On Mon, 29 Sep 2003, Sgarlata Matt wrote: +1. Is someone going to step up and create the new [convert] sandbox component? I am not a committer, so I don't think I can help here. I would like to volunteer to draft the mandate for the project, which would basically summarize the issues discussed in this thread. Matt - Original Message - From: Henri Yandell [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Monday, September 29, 2003 12:53 AM Subject: Re: [beanutils] some ideas On Sun, 28 Sep 2003, Sgarlata Matt wrote: From: Henri Yandell [EMAIL PROTECTED] Can anyone think of any others? Something that would need deciding is what to do when the 'from' and the 'to' classes are the same. Should a String-String converter be looked for, or should it optimise it away. I suspect that there just shouldn't be any identity converters pre-registered, but people can always put them in if they wish to. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [beanutils] some ideas
Hi Henri, The past week has been insane, but I can commit to putting together the [convert] proposal this week since it shouldn't take long. If there's no sql.Date converter, it then finds a util.Date converter. Converts and promptly dies. Inheritence on the fromClass side may still make sense. For most people, this basically means Object-String. Why does it die, and what do you mean by 'die'? Matt - Original Message - From: Henri Yandell [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Tuesday, October 07, 2003 12:57 PM Subject: Re: [beanutils] some ideas Okay, I suck on doing things 'tonight' :) Have been playing with the code though, as it's fun stuff. How are you feeling about drafting up the proposal etc Matt? One problem I've hit is that inheritence is kind of useless. You'll just get a ClassCast in most usages: Converter converter = ConverterRegistry.getConverter(String.class, java.sql.Date.class); preparedStatement.setDate(1, converter.convert(java.sql.Date.class, someString) ); If there's no sql.Date converter, it then finds a util.Date converter. Converts and promptly dies. Inheritence on the fromClass side may still make sense. For most people, this basically means Object-String. Hen On Mon, 29 Sep 2003, Henri Yandell wrote: I have a [convert] sitting on my laptop that I can commit into the sandbox tonight. It's just an extraction of tests/src from beanutils. I wasn't sure if that was the right way to go. Hen On Mon, 29 Sep 2003, Sgarlata Matt wrote: +1. Is someone going to step up and create the new [convert] sandbox component? I am not a committer, so I don't think I can help here. I would like to volunteer to draft the mandate for the project, which would basically summarize the issues discussed in this thread. Matt - Original Message - From: Henri Yandell [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Monday, September 29, 2003 12:53 AM Subject: Re: [beanutils] some ideas On Sun, 28 Sep 2003, Sgarlata Matt wrote: From: Henri Yandell [EMAIL PROTECTED] Can anyone think of any others? Something that would need deciding is what to do when the 'from' and the 'to' classes are the same. Should a String-String converter be looked for, or should it optimise it away. I suspect that there just shouldn't be any identity converters pre-registered, but people can always put them in if they wish to. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - 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: [codec] should we release a version 1.2 now?
+1 for a 1.2 Maybe this time we'll make a release. :-) (I'm notorious for dropping the ball lately) What's left - 1. Let's make an attempt to increase coverage over the next few days - http://jakarta.apache.org/commons/codec/clover/index.html 2. Build out Javadocs - http://jakarta.apache.org/commons/codec/apidocs/index.html On Mon, 6 Oct 2003, Michael Becke wrote: I think 1.2 sounds better as well. URLCodec is also new in this release. Mike On Monday, October 6, 2003, at 03:05 PM, Gary Gregory wrote: A 1.1.1 release seems no longer appropriate since DigestUtils is a new feature; should we wrap up a 1.2 now? It feels like we had been planning a 1.1.1 for quite some time to capture some bug fixes. Gary - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- -- Tim O'Brien Evanston, IL (847) 863-7045 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] New commons proper component - pcollections
1-, I think... I am in favor of primitives support IN [collection] proper, /especially/ since 1.5 will not address this issue. For a feature that 1.4 or 1.5 would address I would see as a good thing a separate Jar for pre-1.4 or pre-1.5 setups. For example, in [lang], having the nested exception classes in the jar is obviously duplicative in a 1.4 setup. Now, I do recall some thread on this list about primitives collections but I do not recall if any agreement came on package names or 'jaring'. My concerns are (feel free to pour gas and set on fire any of these): (1) One more Jar file to keep track of on the class path, with this email list, with our product build, our customers, etc. All the pain that comes with having yet one more jar dependency in a product. (2) Conceptually, [collections] is one nice lump. Splitting it for collections of primitives vs. Objects is a subtlety I do not want 2 jars for, 2 packages fine but not two jars. Will one jar depend on the other? Gary -Original Message- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] Sent: Monday, October 06, 2003 17:06 To: Jakarta Commons Developers List Subject: [VOTE] New commons proper component - pcollections The [collections] component has been housing unreleased, but stable primitive collections code for some time. These are collections that store primitive arrays behind the scenes instead of objects. (Note that JDK1.5 does NOT address the need for these classes). Following discussion within the [collections] component on the best release strategy, we would like to create a new commons-PROPER component to house the code. The aim is to give this useful code room to grow without impacting the widely used main [collections] (object-based) component. It is important to emphasise that this is not new code - it is stable and ready for release. Thus commons-proper, rather than the sandbox, is the appropriate place for the new component. The proposal is attached for the new component 'pcollections'. (No one likes this name, but we haven't found a better one). Please vote as to whether you support this new commons-PROPER component. [ ] +1 Yes, lets create [pcollections] [ ] +0 [ ] -0 [ ] -1 No, I oppose this because Stephen
Re: [VOTE] New commons proper component - pcollections
In prowling this list, I've heard the too many jars argument very frequently. I think that I understand the complaint, but I have trouble understanding the boundaries. When making decisions of this kind, I think that it's not only important to consider the users, but also the codebase itself. While everyone is free to vote for whatever they want for whatever reason they wish, voting -1 to a proposal because it will create another jar doesn't seem right to me. How hard is it, really, to deal with another jar. You add another entry to your project.xml. You add another file to a directory. I understand that some production environments are not this free-spirited, but there has to be a limit. Take a look at the codebase for [collections]. It's monstrous. Think about the un-object-oriented-ness required for building a primitive collections library. There already are an unbelievable amount of primitive classes, and there will continue to be more. The scope and purpose of the [pcollections] and [collections] components are quite different. The first is extensions and utilities for working with the collections framework. The second involves the creation a new primitive implementation which is similar to the collections framework. In my opinion, there will not be much overlap. I've done some pseudo-ranting here, and I apologize, but my point is: These projects are more different than they appear, and adding another jar is a small price to pay for the proper separation and encapsulation of code. When there are too many lines of code, it's good to split one class into many. When there are too many classes, and a distinct separation appears between groups of those classes, it may be good to split one component into many. Gary Gregory wrote: 1-, I think... I am in favor of primitives support IN [collection] proper, /especially/ since 1.5 will not address this issue. For a feature that 1.4 or 1.5 would address I would see as a good thing a separate Jar for pre-1.4 or pre-1.5 setups. For example, in [lang], having the nested exception classes in the jar is obviously duplicative in a 1.4 setup. Now, I do recall some thread on this list about primitives collections but I do not recall if any agreement came on package names or 'jaring'. My concerns are (feel free to pour gas and set on fire any of these): (1) One more Jar file to keep track of on the class path, with this email list, with our product build, our customers, etc. All the pain that comes with having yet one more jar dependency in a product. (2) Conceptually, [collections] is one nice lump. Splitting it for collections of primitives vs. Objects is a subtlety I do not want 2 jars for, 2 packages fine but not two jars. Will one jar depend on the other? Gary -Original Message- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] Sent: Monday, October 06, 2003 17:06 To: Jakarta Commons Developers List Subject: [VOTE] New commons proper component - pcollections The [collections] component has been housing unreleased, but stable primitive collections code for some time. These are collections that store primitive arrays behind the scenes instead of objects. (Note that JDK1.5 does NOT address the need for these classes). Following discussion within the [collections] component on the best release strategy, we would like to create a new commons-PROPER component to house the code. The aim is to give this useful code room to grow without impacting the widely used main [collections] (object-based) component. It is important to emphasise that this is not new code - it is stable and ready for release. Thus commons-proper, rather than the sandbox, is the appropriate place for the new component. The proposal is attached for the new component 'pcollections'. (No one likes this name, but we haven't found a better one). Please vote as to whether you support this new commons-PROPER component. [ ] +1 Yes, lets create [pcollections] [ ] +0 [ ] -0 [ ] -1 No, I oppose this because Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[BeanUtils] Can we make converters not final?
Is there some particular reason why all the classes in org.apache.commons.beanutils.converters are final? This makes writing custom converters with very similar behavior to the standard ones a pain. If this is an OK change, I could write patches to do this, although it will be a while before I have time... Thanks, Matt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] New commons proper component - pcollections
Please see below. -Original Message- From: __matthewHawthorne [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 07, 2003 11:27 To: Jakarta Commons Developers List Subject: Re: [VOTE] New commons proper component - pcollections In prowling this list, I've heard the too many jars argument very frequently. I think that I understand the complaint, but I have trouble understanding the boundaries. When making decisions of this kind, I think that it's not only important to consider the users, but also the codebase itself. We could argue 'round and 'round but since this is not the most important point to me right now I'll let it drop for brevity's sake. While everyone is free to vote for whatever they want for whatever reason they wish, voting -1 to a proposal because it will create another jar doesn't seem right to me. How hard is it, really, to deal with another jar. You add another entry to your project.xml. You add another file to a directory. I understand that some production environments are not this free-spirited, but there has to be a limit. I agree with you in principle here. A -1 just for that reason is not what I meant to express. Take a look at the codebase for [collections]. It's monstrous. Think about the un-object-oriented-ness required for building a primitive collections library. There already are an unbelievable amount of primitive classes, and there will continue to be more. Now it sounds like [primitives] is a better project name than [pcollections]. In any case, my feeling is that size is, er, relative and should not alone direct the jarring of a component. In my mind, I would like to have [collections] be all things collection. The scope and purpose of the [pcollections] and [collections] components are quite different. The first is extensions and utilities for working with the collections framework. The second involves the creation a new primitive implementation which is similar to the collections framework. I think I see your point but... the way I see it (perhaps too simplistically) is like this: I want a typed Bag of DooDad's, ah! this [collection] class will help me. And I want a Bag of int's, ah! same answer as above. To me, this is all in the same conceptual lump. Ok, here is my main point: I seems nice and in-sync and well thought out if the /same/ library lets me use a /Collection of Integers/ or a /Collection of ints/. Maybe there even is some cross-conversion methods to let me try and measure it different both ways in my app. In my opinion, there will not be much overlap. I've done some pseudo-ranting here, and I apologize, Not at all! This is all very civilized :-) but my point is: These projects are more different than they appear, and adding another jar is a small price to pay for the proper separation and encapsulation of code. Ah... but from an app writer's POV, it would be nice it all appeared seamless. I've not had the need yet for this but I would have that porting from a Collection of Integers (CollectionUtils.typedCollection(collection Integer.class) and a Collection of ints (new ArrayIntList()) would be easy. For example, why not implement an RandomAccessIntList.add(Number) to help in this direction? When there are too many lines of code, it's good to split one class into many. When there are too many classes, and a distinct separation appears between groups of those classes, it may be good to split one component into many. Yes, it may be, or not. :-) Good chat, thanks. Gary Gary Gregory wrote: 1-, I think... I am in favor of primitives support IN [collection] proper, /especially/ since 1.5 will not address this issue. For a feature that 1.4 or 1.5 would address I would see as a good thing a separate Jar for pre-1.4 or pre- 1.5 setups. For example, in [lang], having the nested exception classes in the jar is obviously duplicative in a 1.4 setup. Now, I do recall some thread on this list about primitives collections but I do not recall if any agreement came on package names or 'jaring'. My concerns are (feel free to pour gas and set on fire any of these): (1) One more Jar file to keep track of on the class path, with this email list, with our product build, our customers, etc. All the pain that comes with having yet one more jar dependency in a product. (2) Conceptually, [collections] is one nice lump. Splitting it for collections of primitives vs. Objects is a subtlety I do not want 2 jars for, 2 packages fine but not two jars. Will one jar depend on the other? Gary -Original Message- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] Sent: Monday, October 06, 2003 17:06 To: Jakarta Commons Developers List Subject: [VOTE] New commons proper component - pcollections The [collections] component has been housing unreleased, but stable primitive collections code for some time. These are collections
Re: [beanutils] some ideas
On Tue, 7 Oct 2003, Sgarlata Matt wrote: Hi Henri, The past week has been insane, but I can commit to putting together the [convert] proposal this week since it shouldn't take long. No worries. If there's no sql.Date converter, it then finds a util.Date converter. Converts and promptly dies. Inheritence on the fromClass side may still make sense. For most people, this basically means Object-String. Why does it die, and what do you mean by 'die'? die as in, the idea dies. People will try to cast it immediately and get ClassCasts. So I'm struggling to see the advantage to the inheritence lookup. It's implemented though, so can happily commit it. Hen - Original Message - From: Henri Yandell [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Tuesday, October 07, 2003 12:57 PM Subject: Re: [beanutils] some ideas Okay, I suck on doing things 'tonight' :) Have been playing with the code though, as it's fun stuff. How are you feeling about drafting up the proposal etc Matt? One problem I've hit is that inheritence is kind of useless. You'll just get a ClassCast in most usages: Converter converter = ConverterRegistry.getConverter(String.class, java.sql.Date.class); preparedStatement.setDate(1, converter.convert(java.sql.Date.class, someString) ); If there's no sql.Date converter, it then finds a util.Date converter. Converts and promptly dies. Inheritence on the fromClass side may still make sense. For most people, this basically means Object-String. Hen On Mon, 29 Sep 2003, Henri Yandell wrote: I have a [convert] sitting on my laptop that I can commit into the sandbox tonight. It's just an extraction of tests/src from beanutils. I wasn't sure if that was the right way to go. Hen On Mon, 29 Sep 2003, Sgarlata Matt wrote: +1. Is someone going to step up and create the new [convert] sandbox component? I am not a committer, so I don't think I can help here. I would like to volunteer to draft the mandate for the project, which would basically summarize the issues discussed in this thread. Matt - Original Message - From: Henri Yandell [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Monday, September 29, 2003 12:53 AM Subject: Re: [beanutils] some ideas On Sun, 28 Sep 2003, Sgarlata Matt wrote: From: Henri Yandell [EMAIL PROTECTED] Can anyone think of any others? Something that would need deciding is what to do when the 'from' and the 'to' classes are the same. Should a String-String converter be looked for, or should it optimise it away. I suspect that there just shouldn't be any identity converters pre-registered, but people can always put them in if they wish to. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - 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: [VOTE] New commons proper component - pcollections
MH Take a look at the codebase for [collections]. It's monstrous. Think about the un-object-oriented-ness required for building a primitive collections library. There already are an unbelievable amount of primitive classes, and there will continue to be more. MH The scope and purpose of the [pcollections] and [collections] components are quite different. The first is extensions and utilities for working with the collections framework. The second involves the creation a new primitive implementation which is similar to the collections framework. I must strongly agree with what Matthew says here. The difference between collections and primitive collections seems very subtle and minor from a high level view. It seems perfectly natural to think of them together. However, when you get down to the low level you actually find them quite different. [collections] provides additions to an established framework in the JDK. pcollections creates something wholely new, styled after an existing API. This is demonstrated most clearly in the fact that the two groups of code are entirely independent. Each can be compiled without the other. (Except the test cases, and that has been dealt with) Other differences include the way code is developed, with pcollections potentially using code generation at some point. There is an additional point, in that [collections] is very widely dispersed and used. To increase its size by over 100% suggests that something should at least be looked at. MH These projects are more different than they appear, and adding another jar is a small price to pay for the proper separation and encapsulation of code. GG Ah... but from an app writer's POV, it would be nice it all appeared seamless. I've not had the need yet for this but I would have that porting from a Collection of Integers (CollectionUtils.typedCollection(collection Integer.class) and a Collection of ints (new ArrayIntList()) would be easy. It still is, but we ask you to include an additional jar. MH When there are too many lines of code, it's good to split one class into many. When there are too many classes, and a distinct separation appears between groups of those classes, it may be good to split one component into many. Yes, it may be, or not. :-) I'm very clear that it is good to split, manage and release separately in this case. GG Good chat, thanks. Ah, but we are lobbying for you to change your vote. If not to +1, at least to a 0. We need to convince you ;-) Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Chain]: k2d2 framework
Could you be more specific as to which classes or packages Chain might have in common wiht k2d2? Of course, many, many applications and frameworks include implementations of the Chain of Responsibility pattern. [Otherwise, it wouldn't be a pattern :)] The goal of this package is to provide an implementation that is independent of a larger framework, so that it can easily reused and shared between applications and frameworks. Chain is designed to do exactly one thing well, whereas it would appear that k2d2 has a larger mission. The Commons was formed so that packages like this could live outside of larger frameworks, like Avalon, Turbine, Struts, et al. So far, this strategy has been quite successful. -Ted. otisg wrote: Hello, I just learned about the Commons Sandbox's Chain project. After reading the proposal, I realized that Chain sounds very much like the k2d2 framework, which you can find at http://www.k2d2.org/framework/index.html. I believe this framework implements the same patterns as Chain. I have used k2d2 framework successfully and found no bugs in it. The new version (you can see the link at the top of the page), also includes code to deal with remote commands, I believe. Would it be too much to ask that whomever is working on Chain (Craig McClanahan, Ted Husted?, maybe others) to take a look at k2d2 and consider adopting that framework? Or, perhaps, the classes in k2d2 could be used as implementations of interfaces that Chain aims to define. The author of k2d2 has considered donating the code to Avalon a while back, I believe. Any feedback to this proposal would be appreciated. Thank you, Otis - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/lang/src/test/org/apache/commons/lang BitFieldTest.java
scolebourne2003/10/07 13:36:26
Modified:lang/src/test/org/apache/commons/lang BitFieldTest.java
Log:
Update licence
Tidy file
Revision ChangesPath
1.3 +80 -145
jakarta-commons/lang/src/test/org/apache/commons/lang/BitFieldTest.java
Index: BitFieldTest.java
===
RCS file:
/home/cvs/jakarta-commons/lang/src/test/org/apache/commons/lang/BitFieldTest.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- BitFieldTest.java 5 Oct 2003 15:46:55 - 1.2
+++ BitFieldTest.java 7 Oct 2003 20:36:26 - 1.3
@@ -1,13 +1,7 @@
-/*
- * $Header$
- * $Revision$
- * $Date$
- *
- *
- *
+/*
* The Apache Software License, Version 1.1
*
- * Copyright (c) 2001-2003 The Apache Software Foundation. All rights
+ * Copyright (c) 2002-2003 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -15,28 +9,28 @@
* are met:
*
* 1. Redistributions of source code must retain the above copyright
- *notice, this list of conditions and the following disclaimer.
+ *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 acknowledgement:
- * This product includes software developed by the
+ * 3. The end-user documentation included with the redistribution, if
+ *any, must include the following acknowledgement:
+ * 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.
+ *Alternately, this acknowledgement may appear in the software itself,
+ *if and wherever such third-party acknowledgements normally appear.
*
- * 4. The names Apache, The Jakarta Project, Commons, and Apache Software
+ * 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
+ *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,
- *Apache nor may Apache appear in their names without prior
- *written permission of the Apache Software Foundation.
+ * 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 Software Foundation.
*
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
* WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
@@ -56,9 +50,7 @@
* individuals on behalf of the Apache Software Foundation. For more
* information on the Apache Software Foundation, please see
* http://www.apache.org/.
- *
- */
-
+ */
package org.apache.commons.lang;
import junit.framework.Test;
@@ -69,15 +61,12 @@
/**
* Class to test BitField functionality
*
- * @author Scott Sanders (sanders at apache dot org)
+ * @author Scott Sanders
* @author Marc Johnson
- * @author Glen Stampoultzis ([EMAIL PROTECTED])
+ * @author Glen Stampoultzis
* @version $Id$
*/
-
-public class BitFieldTest
-extends TestCase
-{
+public class BitFieldTest extends TestCase {
public static void main(String[] args) {
TestRunner.run(suite());
@@ -97,18 +86,14 @@
*
* @param name
*/
-
-public BitFieldTest(String name)
-{
+public BitFieldTest(String name) {
super(name);
}
/**
* test the getValue() method
*/
-
-public void testGetValue()
-{
+public void testGetValue() {
assertEquals(bf_multi.getValue(-1), 127);
assertEquals(bf_multi.getValue(0), 0);
assertEquals(bf_single.getValue(-1), 1);
@@ -118,21 +103,17 @@
/**
* test the getShortValue() method
*/
-
-public void testGetShortValue()
-{
-assertEquals(bf_multi.getShortValue(( short ) -1), ( short ) 127);
-assertEquals(bf_multi.getShortValue(( short ) 0), ( short
cvs commit: jakarta-commons/httpclient release_notes.txt
olegk 2003/10/07 13:45:31 Modified:httpclient Tag: HTTPCLIENT_2_0_BRANCH release_notes.txt Log: Updated changelog Revision ChangesPath No revision No revision 1.9.2.4 +35 -0 jakarta-commons/httpclient/release_notes.txt Index: release_notes.txt === RCS file: /home/cvs/jakarta-commons/httpclient/release_notes.txt,v retrieving revision 1.9.2.3 retrieving revision 1.9.2.4 diff -u -r1.9.2.3 -r1.9.2.4 --- release_notes.txt 1 Aug 2003 03:22:00 - 1.9.2.3 +++ release_notes.txt 7 Oct 2003 20:45:31 - 1.9.2.4 @@ -1,3 +1,38 @@ +Release 2.0 Release Candidate 2 +--- +Changes since Release Candidate 1: + + * Javadoc enhancements. + + * 23284 - Fixed bug with URI.isIPv4address(). + + * 22969 - PostMethod#setParameter fixed to correctly overwrite existing parameters. + + * 22970 - Fixed bug with PostMethod#removeParameter return value. + + * Improved compliance to RFC 2617 + + * Added support for digest auth MD5-sess. + + * 22655 - Added support for stale digest nonce values. + + * 22968 - HttpConnection.isResponseAvailable() made a little more robust, particularly when + used by HeadMethod. + + * 22941 - Switched the order in which socket streams are closed: output stream closed first, + followed by input stream. + + * Added debugging for connection reclaiming. + + * Removed JCE initialization code specific to the Sun's implementation. + + * Fixed problem of Basic, Digest NTLM authentication schemes under certain circumstances + leaking passwords in clear text to the DEBUG log. + + * Fixed the problem with incorrect selection of the proxy authentication realm. + + * Changed URI.normalize() to ignore relative path normalization. + Release 2.0 Release Candidate 1 --- Changes since Release 2.0 Beta 2: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/httpclient release_notes.txt
olegk 2003/10/07 13:46:03 Modified:httpclient release_notes.txt Log: Updated changelog Revision ChangesPath 1.15 +47 -5 jakarta-commons/httpclient/release_notes.txt Index: release_notes.txt === RCS file: /home/cvs/jakarta-commons/httpclient/release_notes.txt,v retrieving revision 1.14 retrieving revision 1.15 diff -u -r1.14 -r1.15 --- release_notes.txt 18 Sep 2003 13:56:21 - 1.14 +++ release_notes.txt 7 Oct 2003 20:46:03 - 1.15 @@ -1,9 +1,16 @@ Changes on the CVS trunk: - * added support for MD5-sess Digest authentication scheme - - * improved compliance to RFC 2617 - + * 10790 - Implemented granular non-standards configuration and tracking. + + * 15435 - Implemented new preference architecture. + + * Deprecated the use of system properties: 'httpclient.useragent', + 'httpclient.authentication.preemptive'. + + * Refactored NameValuePair#equals method. + + * 16729 - Refactored retry/redirect/authentication logic. + * 10791 - Improved HTTP Version configuration and tracking. * 21880 - Content-Length Transfer-Encoding request headers formerly set by abstract @@ -15,7 +22,42 @@ * 19868 - Exception handling framework reworked. - * 21210 - Header parser competely rewritten. + * 21210 - Header parser completely rewritten. + +Release 2.0 Release Candidate 2 +--- +Changes since Release Candidate 1: + + * Javadoc enhancements. + + * 23284 - Fixed bug with URI.isIPv4address(). + + * 22969 - PostMethod#setParameter fixed to correctly overwrite existing parameters. + + * 22970 - Fixed bug with PostMethod#removeParameter return value. + + * Improved compliance to RFC 2617 + + * Added support for digest auth MD5-sess. + + * 22655 - Added support for stale digest nonce values. + + * 22968 - HttpConnection.isResponseAvailable() made a little more robust, particularly when + used by HeadMethod. + + * 22941 - Switched the order in which socket streams are closed: output stream closed first, + followed by input stream. + + * Added debugging for connection reclaiming. + + * Removed JCE initialization code specific to the Sun's implementation. + + * Fixed problem of Basic, Digest NTLM authentication schemes under certain circumstances + leaking passwords in clear text to the DEBUG log. + + * Fixed the problem with incorrect selection of the proxy authentication realm. + + * Changed URI.normalize() to ignore relative path normalization. Release 2.0 Release Candidate 1 --- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/lang project.xml
scolebourne2003/10/07 13:59:46
Modified:lang/src/java/org/apache/commons/lang SystemUtils.java
lang/src/test/org/apache/commons/lang SystemUtilsTest.java
lang project.xml
Log:
Add IS_OS_UNIX to SystemUtils
from Rafal Krupinski
Revision ChangesPath
1.24 +15 -1
jakarta-commons/lang/src/java/org/apache/commons/lang/SystemUtils.java
Index: SystemUtils.java
===
RCS file:
/home/cvs/jakarta-commons/lang/src/java/org/apache/commons/lang/SystemUtils.java,v
retrieving revision 1.23
retrieving revision 1.24
diff -u -r1.23 -r1.24
--- SystemUtils.java 22 Aug 2003 16:34:06 - 1.23
+++ SystemUtils.java 7 Oct 2003 20:59:46 - 1.24
@@ -67,6 +67,7 @@
* @author Gary Gregory
* @author Michael Becke
* @author Tetsuya Kaneuchi
+ * @author Rafal Krupinski
* @since 1.0
* @version $Id$
*/
@@ -625,6 +626,19 @@
* @since 2.0
*/
public static final boolean IS_OS_SUN_OS = getOSMatches(SunOS);
+
+/**
+ * pIs codetrue/code if this is POSIX compilant system,
+ * ie. any of AIX, HP-UX, Irix, Linux, MacOSX, Solaris or SUN OS./p
+ *
+ * pThe field will return codefalse/code if codeOS_NAME/code is
+ * codenull/code./p
+ *
+ * @since 2.1
+ */
+public static final boolean IS_OS_UNIX =
+IS_OS_AIX || IS_OS_HP_UX || IS_OS_IRIX || IS_OS_LINUX ||
+IS_OS_MAC_OSX || IS_OS_SOLARIS || IS_OS_SUN_OS;
/**
* pIs codetrue/code if this is Windows./p
1.7 +19 -7
jakarta-commons/lang/src/test/org/apache/commons/lang/SystemUtilsTest.java
Index: SystemUtilsTest.java
===
RCS file:
/home/cvs/jakarta-commons/lang/src/test/org/apache/commons/lang/SystemUtilsTest.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- SystemUtilsTest.java 18 Aug 2003 02:22:25 - 1.6
+++ SystemUtilsTest.java 7 Oct 2003 20:59:46 - 1.7
@@ -363,21 +363,33 @@
String osName = System.getProperty(os.name);
if (osName == null) {
assertEquals(false, SystemUtils.IS_OS_WINDOWS);
+assertEquals(false, SystemUtils.IS_OS_UNIX);
assertEquals(false, SystemUtils.IS_OS_SOLARIS);
assertEquals(false, SystemUtils.IS_OS_LINUX);
assertEquals(false, SystemUtils.IS_OS_MAC_OSX);
} else if (osName.startsWith(Windows)) {
-assertTrue(SystemUtils.IS_OS_WINDOWS);
+assertEquals(false, SystemUtils.IS_OS_UNIX);
+assertEquals(true, SystemUtils.IS_OS_WINDOWS);
} else if (osName.startsWith(Solaris)) {
-assertTrue(SystemUtils.IS_OS_SOLARIS);
+assertEquals(true, SystemUtils.IS_OS_SOLARIS);
+assertEquals(true, SystemUtils.IS_OS_UNIX);
+assertEquals(false, SystemUtils.IS_OS_WINDOWS);
} else if (osName.toLowerCase().startsWith(linux)) {
-assertTrue(SystemUtils.IS_OS_LINUX);
+assertEquals(true, SystemUtils.IS_OS_LINUX);
+assertEquals(true, SystemUtils.IS_OS_UNIX);
+assertEquals(false, SystemUtils.IS_OS_WINDOWS);
} else if (osName.startsWith(Mac OS X)) {
-assertTrue(SystemUtils.IS_OS_MAC_OSX);
+assertEquals(true, SystemUtils.IS_OS_MAC_OSX);
+assertEquals(true, SystemUtils.IS_OS_UNIX);
+assertEquals(false, SystemUtils.IS_OS_WINDOWS);
} else if (osName.startsWith(OS/2)) {
-assertTrue(SystemUtils.IS_OS_OS2);
+assertEquals(true, SystemUtils.IS_OS_OS2);
+assertEquals(false, SystemUtils.IS_OS_UNIX);
+assertEquals(false, SystemUtils.IS_OS_WINDOWS);
} else if (osName.startsWith(SunOS)) {
-assertTrue(SystemUtils.IS_OS_SUN_OS);
+assertEquals(true, SystemUtils.IS_OS_SUN_OS);
+assertEquals(true, SystemUtils.IS_OS_UNIX);
+assertEquals(false, SystemUtils.IS_OS_WINDOWS);
} else {
System.out.println(Can't test IS_OS value);
}
1.16 +8 -0 jakarta-commons/lang/project.xml
Index: project.xml
===
RCS file: /home/cvs/jakarta-commons/lang/project.xml,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- project.xml 2 Oct 2003 20:34:16 - 1.15
+++ project.xml 7 Oct 2003 20:59:46 - 1.16
@@ -267,6 +267,14 @@
/roles
/contributor
contributor
+ nameRafal Krupinski/name
+ email/email
+ organization/organization
+ roles
+roleJava Developer/role
+
cvs commit: jakarta-commons/lang project.xml
scolebourne2003/10/07 14:05:03 Modified:lang project.xml Log: Make the contributers list more readble Revision ChangesPath 1.17 +0 -250jakarta-commons/lang/project.xml Index: project.xml === RCS file: /home/cvs/jakarta-commons/lang/project.xml,v retrieving revision 1.16 retrieving revision 1.17 diff -u -r1.16 -r1.17 --- project.xml 7 Oct 2003 20:59:46 - 1.16 +++ project.xml 7 Oct 2003 21:05:03 - 1.17 @@ -92,403 +92,153 @@ contributors contributor nameChris Audley/name - email/email - organization/organization - roles -roleJava Developer/role - /roles /contributor contributor nameStephane Bailliez/name - email/email - organization/organization - roles -roleJava Developer/role - /roles /contributor contributor nameMichael Becke/name - email/email - organization/organization - roles -roleJava Developer/role - /roles /contributor contributor nameOla Berg/name - email/email - organization/organization - roles -roleJava Developer/role - /roles /contributor contributor nameStefan Bodewig/name - email/email - organization/organization - roles -roleJava Developer/role - /roles /contributor contributor nameJanek Bogucki/name - email/email - organization/organization - roles -roleJava Developer/role - /roles /contributor contributor nameMike Bowler/name - email/email - organization/organization - roles -roleJava Developer/role - /roles /contributor contributor nameSean Brown/name - email/email - organization/organization - roles -roleJava Developer/role - /roles /contributor contributor nameAlexander Day Chaffee/name - email/email - organization/organization - roles -roleJava Developer/role - /roles /contributor contributor nameGreg Coladonato/name - email/email - organization/organization - roles -roleJava Developer/role - /roles /contributor contributor nameJustin Couch/name - email/email - organization/organization - roles -roleJava Developer/role - /roles /contributor contributor nameRingo De Smet/name - email/email - organization/organization - roles -roleJava Developer/role - /roles /contributor contributor nameSteve Downey/name - email/email - organization/organization - roles -roleJava Developer/role - /roles /contributor contributor nameChristopher Elkins/name - email/email - organization/organization - roles -roleJava Developer/role - /roles /contributor contributor nameChris Feldhacker/name - email/email - organization/organization - roles -roleJava Developer/role - /roles /contributor contributor namePete Gieser/name - email/email - organization/organization - roles -roleJava Developer/role - /roles /contributor contributor nameMatthew Hawthorne/name - email/email - organization/organization - roles -roleJava Developer/role - /roles /contributor contributor nameMarc Johnson/name - email/email - organization/organization - roles -roleJava Developer/role - /roles /contributor contributor nameTetsuya Kaneuchi/name - email/email - organization/organization - roles -roleJava Developer/role - /roles /contributor contributor nameNissim Karpenstein/name - email/email - organization/organization - roles -roleJava Developer/role - /roles /contributor contributor nameEd Korthof/name - email/email - organization/organization - roles -roleJava Developer/role - /roles /contributor contributor nameHolger Krauth/name - email/email - organization/organization - roles -roleJava Developer/role - /roles /contributor contributor nameRafal Krupinski/name - email/email - organization/organization - roles -
RE: [VOTE] New commons proper component - pcollections
Ok, I change my vote to 0. We do use [collections] in our product but I am not coding with it right now so I will defer to you guys as to the ease of working with a mixed (Integer and int) collections model and other details. Gary -Original Message- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 07, 2003 13:21 To: Jakarta Commons Developers List Subject: Re: [VOTE] New commons proper component - pcollections MH Take a look at the codebase for [collections]. It's monstrous. Think about the un-object-oriented-ness required for building a primitive collections library. There already are an unbelievable amount of primitive classes, and there will continue to be more. MH The scope and purpose of the [pcollections] and [collections] components are quite different. The first is extensions and utilities for working with the collections framework. The second involves the creation a new primitive implementation which is similar to the collections framework. I must strongly agree with what Matthew says here. The difference between collections and primitive collections seems very subtle and minor from a high level view. It seems perfectly natural to think of them together. However, when you get down to the low level you actually find them quite different. [collections] provides additions to an established framework in the JDK. pcollections creates something wholely new, styled after an existing API. This is demonstrated most clearly in the fact that the two groups of code are entirely independent. Each can be compiled without the other. (Except the test cases, and that has been dealt with) Other differences include the way code is developed, with pcollections potentially using code generation at some point. There is an additional point, in that [collections] is very widely dispersed and used. To increase its size by over 100% suggests that something should at least be looked at. MH These projects are more different than they appear, and adding another jar is a small price to pay for the proper separation and encapsulation of code. GG Ah... but from an app writer's POV, it would be nice it all appeared seamless. I've not had the need yet for this but I would have that porting from a Collection of Integers (CollectionUtils.typedCollection(collection Integer.class) and a Collection of ints (new ArrayIntList()) would be easy. It still is, but we ask you to include an additional jar. MH When there are too many lines of code, it's good to split one class into many. When there are too many classes, and a distinct separation appears between groups of those classes, it may be good to split one component into many. Yes, it may be, or not. :-) I'm very clear that it is good to split, manage and release separately in this case. GG Good chat, thanks. Ah, but we are lobbying for you to change your vote. If not to +1, at least to a 0. We need to convince you ;-) Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Lang][PATCH] - SystemUtils.IS_OS_UNIX for POSIX compilant systems
Patch applied thanks. Stephen - Original Message - From: rufio [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, September 30, 2003 1:20 PM Subject: [Lang][PATCH] - SystemUtils.IS_OS_UNIX for POSIX compilant systems Hi! This patch adds org.apache.commons.lang.SystemUtils.IS_OS_UNIX This is usefull when you need UNIX but not any specific flavour. snip --- jakarta-commons/lang/src/java/org/apache/commons/lang/SystemUtils.java.orig 2003-09-30 14:04:05.0 +0200 +++ jakarta-commons/lang/src/java/org/apache/commons/lang/SystemUtils.java 2003-09-30 14:04:18.0 +0200 @@ -627,6 +627,16 @@ public static final boolean IS_OS_SUN_OS = getOSMatches(SunOS); /** + * pIs codetrue/code if this is POSIX compilant system, ie. any of AIX, HP-UX, Irix, Linux, MacOSX, Solaris or SUN OS./p + * + * pThe field will return codefalse/code if codeOS_NAME/code is + * codenull/code./p + * + * @author Rafal Krupinski + */ +public static final boolean IS_OS_UNIX = IS_OS_AIX || IS_OS_HP_UX || IS_OS_IRIX || IS_OS_LINUX || IS_OS_MAC_OSX || IS_OS_SOLARIS || IS_OS_SUN_OS; + +/** * pIs codetrue/code if this is Windows./p * * pThe field will return codefalse/code if codeOS_NAME/code is /snip Regards, Rufio -- nmap -sS -O -p80,81 www.microsoft.com [..] Running: Linux 2.5.X OS details: Linux Kernel 2.4.18 - 2.5.70 (X86) - 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/collections/src/test/org/apache/commons/collections/decorators TestFixedSizeSortedMap.java TestLazySortedMap.java TestPredicatedSortedMap.java TestUnmodifiableMap.java TestFixedSizeMap.java
scolebourne2003/10/07 15:20:58
Modified:collections/src/test/org/apache/commons/collections
TestBidiMap.java AbstractTestSortedMap.java
AbstractTestMap.java TestMapUtils.java
TestReferenceMap.java TestDoubleOrderedMap.java
TestFastHashMap.java TestBeanMap.java
TestTreeMap.java TestFastTreeMap.java
collections/src/test/org/apache/commons/collections/decorators
TestFixedSizeSortedMap.java TestLazySortedMap.java
TestPredicatedSortedMap.java
TestUnmodifiableMap.java TestFixedSizeMap.java
Log:
Enhance Map tests pre-release of testframework
Revision ChangesPath
1.6 +3 -3
jakarta-commons/collections/src/test/org/apache/commons/collections/TestBidiMap.java
Index: TestBidiMap.java
===
RCS file:
/home/cvs/jakarta-commons/collections/src/test/org/apache/commons/collections/TestBidiMap.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- TestBidiMap.java 6 Oct 2003 23:47:17 - 1.5
+++ TestBidiMap.java 7 Oct 2003 22:20:57 - 1.6
@@ -128,7 +128,7 @@
/**
* Override to indicate to AbstractTestMap this is a BidiMap.
*/
-protected boolean useDuplicateValues() {
+protected boolean isAllowDuplicateValues() {
return false;
}
1.3 +3 -3
jakarta-commons/collections/src/test/org/apache/commons/collections/AbstractTestSortedMap.java
Index: AbstractTestSortedMap.java
===
RCS file:
/home/cvs/jakarta-commons/collections/src/test/org/apache/commons/collections/AbstractTestSortedMap.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- AbstractTestSortedMap.java6 Oct 2003 23:44:56 - 1.2
+++ AbstractTestSortedMap.java7 Oct 2003 22:20:57 - 1.3
@@ -84,7 +84,7 @@
*
* @return false
*/
-protected boolean useNullKey() {
+protected boolean isAllowNullKey() {
return false;
}
1.4 +198 -128
jakarta-commons/collections/src/test/org/apache/commons/collections/AbstractTestMap.java
Index: AbstractTestMap.java
===
RCS file:
/home/cvs/jakarta-commons/collections/src/test/org/apache/commons/collections/AbstractTestMap.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- AbstractTestMap.java 5 Oct 2003 20:47:37 - 1.3
+++ AbstractTestMap.java 7 Oct 2003 22:20:57 - 1.4
@@ -79,32 +79,33 @@
* override one or more of the other protected methods. They're described
* below.
* p
- * BEntry Population Methods/BP
- *
+ * bEntry Population Methods/b
+ * p
* Override these methods if your map requires special entries:
+ *
+ * ul
+ * li[EMAIL PROTECTED] #getSampleKeys()}
+ * li[EMAIL PROTECTED] #getSampleValues()}
+ * li[EMAIL PROTECTED] #getNewSampleValues()}
+ * li[EMAIL PROTECTED] #getOtherKeys()}
+ * li[EMAIL PROTECTED] #getOtherValues()}
+ * /ul
*
- * UL
- * LI[EMAIL PROTECTED] #getSampleKeys()}
- * LI[EMAIL PROTECTED] #getSampleValues()}
- * LI[EMAIL PROTECTED] #getNewSampleValues()}
- * LI[EMAIL PROTECTED] #getOtherKeys()}
- * LI[EMAIL PROTECTED] #getOtherValues()}
- * /UL
- *
- * BSupported Operation Methods/BP
- *
+ * bSupported Operation Methods/b
+ * p
* Override these methods if your map doesn't support certain operations:
*
- * UL
- * LI [EMAIL PROTECTED] #useDuplicateValues()}
- * LI [EMAIL PROTECTED] #useNullKey()}
- * LI [EMAIL PROTECTED] #useNullValue()}
- * LI [EMAIL PROTECTED] #isAddRemoveModifiable()}
- * LI [EMAIL PROTECTED] #isChangeable()}
- * /UL
- *
- * BFixture Methods/BP
+ * ul
+ * li [EMAIL PROTECTED] #isPutAddSupported()}
+ * li [EMAIL PROTECTED] #isPutChangeSupported()}
+ * li [EMAIL PROTECTED] #isRemoveSupported()}
+ * li [EMAIL PROTECTED] #isAllowDuplicateValues()}
+ * li [EMAIL PROTECTED] #isAllowNullKey()}
+ * li [EMAIL PROTECTED] #isAllowNullValue()}
+ * /ul
*
+ * bFixture Methods/b
+ * p
* For tests on modification operations (puts and removes), fixtures are used
* to verify that that operation results in correct state for the map and its
* collection views. Basically, the modification is performed against your
@@ -139,13 +140,13 @@
* [EMAIL PROTECTED] #verifyValues()} method to verify that the values are unique
and in
* ascending order.P
*
- * BOther Notes/BP
- *
+ * bOther Notes/b
+ * p
* If your [EMAIL PROTECTED] Map} fails one of these tests by design, you
Re: [configuration] AbstractConfiguration
Hi Eric, Thank you for applying patches. Everything looks good for me. Unfortunately I don't have a lot of free time now because of my work and studying. So I can't perform any promised changes and additions in the near future. But I hope that I'll send you some patches as soon as I have some free time. As for JDBC Configuration I still have no clean idea how this class should work. It require a lot of parameters, such as name of the table with configuration properties, filed names for keys and values for proper working, database connection properties. Should it allow storing several configuration values under one key (as PropertiesConfiguration)? If you have some ideas about this type of Configuration please describe them. Konstantin. pgp0.pgp Description: PGP signature
Re: [Digester][PATCH] ObjectParamRule support for XML rules
Looks cool... Maybe it would be a good idea to provide a unit test for this new functionality too [if you have time]? [nb: I'm not a committer/maintainer]. Regards, Simon On Tue, 2003-10-07 at 20:47, Anton Maslovsky wrote: Hi, I've added support for the ObjectParamRule in XML rules file for the Digester. The syntax is as follows: !-- ObjectParamRule attrname - an arbitrary Object defined programatically, assigned if the element pattern AND specified attribute name are matched param - an arbitrary Object defined programatically, assigned when the element pattern associated with the Rule is matched type - class name for object value - initial value for the object -- !ELEMENT object-param-rule EMPTY !ATTLIST object-param-rule pattern CDATA #IMPLIED paramnumber CDATA #REQUIRED param CDATA #REQUIRED attrname CDATA #IMPLIED type CDATA #REQUIRED value CDATA #IMPLIED XML example: object-param-rule paramnumber=0 type=java.lang.String value=meter.serial/ Generaly, type attribute can be any Java type. The value can be a string representation of any type that stnaddard ConvertUtils classes are capable to convert into the corresponding object instance. Tow files are patched: DigesterRuleParser.java digester-rules.dtd Regards, Anton _ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail __ - 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: [digester][patch] xml schema support. removal
Simon Kitching wrote: Looking at this from the user point of view: Method setSchemaLocation(someURI) is valid, right? Users should be able to associate a single schema (in some schema language) with the document to be processed. And setSchemaLocation(someURI) is valid, because (a) the user should be able to specify the language of their schema, and (b) there is a unique and well-known identifying URI for each schema language [well, I damn well hope so]. The problem is simply with the feature URI(s) used to communicate this information from the user to the parser. So I think that neither setSchemaLocation nor setSchemaLanguage should be deprecated or removed; we simply need to find some reasonable way of implementing them. Option 1: Just put code like this into Digester.java: if (isXercesParser(parser)) // enable the schema language specified by the user // in a xerces-specific manner else if (isCrimsonParser(parser)) // ... else if (isSaxonParser(parser)) // else // try the old JAXP way, ie the current implementation Option 2: Factor the code out into a single class that holds the pseudo-code above. PRO: tweaking the parser-setting code doesn't require updating Digester.java; keep incidental code out of main Digester code to keep Digester class understandable. CON: an extra class Option 3: Factor the code out into a class per parser-type, possibly a factory class, etc. PRO: pure OO design; adding or changing parser-specific code requires no alterations to non-related code. CON: proliferation of classes. I'm +1 for Option 3. The problem we have right now only apply when schema is in the picture. So we may ends up with 2 classes, one that contains the actual schema implementation (works with Xerces 2.1 and Crimson (for the dtd parts)), one for Xerces 2.3 and up. At the worst, we cannot recognise the parser, and the default JAXP approach results in an unrecognised feature exception being thrown by the parser. This is how jaxp compliant parser are supposed to react right now. Have I missed something? If not, I would pick (in order) 2, 1, 3. (the main guiding principle being KISS). This is basically what you have done with Tomcat, no? I did 2, but I would have prefferred doing 3 :-). Now in Tomcat I have a lot of if parser == Xerces then bla bla which is ugly and error prone. 1 seems too parser centric and I don't like infinite if statement ;-) Now choosing between 2 and 3, I think 2 will still be available even if we implement 3. What do you think? Thanks, -- Jeanfrancois See my patch above. The first schema implemenation I've submitted to the digester team was parser-independent, except it only works with Xerces 2.0.1, 2.0.2 and 2.1 (2.2 was completely broken...truss me I spend a fair amount of time finding it was broken :-( ). Xerces 2.3- Xerces 2.5 still suppors schema in a parser-independent way, except validating schema DTD with the same parser is broken (and the jaxp spec is unclear about that part). If the majority of digester uses 2.1, the we are safe and we should not apply my patch. IMBW, but I think people use at least 2.3 I agree it should be fixed somehow. You have pointed out a definite bug in the current setup... Comments? Regards, Simon - 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: [beanutils] some ideas
You're right Walking up the inheritance heirarchy only makes sense on the from class side. Walking DOWN the inheritance heirarchy would actually do well on the to class side I think, but, of course, that's much more difficult to do. In short, the result of the conversion must be the desired class, or a descendant of the desired class so that casting can succeed. -AMT -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Tue 10/7/2003 9:57 AM To: Jakarta Commons Developers List Cc: Subject: Re: [beanutils] some ideas Okay, I suck on doing things 'tonight' :) Have been playing with the code though, as it's fun stuff. How are you feeling about drafting up the proposal etc Matt? One problem I've hit is that inheritence is kind of useless. You'll just get a ClassCast in most usages: Converter converter = ConverterRegistry.getConverter(String.class, java.sql.Date.class); preparedStatement.setDate(1, converter.convert(java.sql.Date.class, someString) ); If there's no sql.Date converter, it then finds a util.Date converter. Converts and promptly dies. Inheritence on the fromClass side may still make sense. For most people, this basically means Object-String. Hen On Mon, 29 Sep 2003, Henri Yandell wrote: I have a [convert] sitting on my laptop that I can commit into the sandbox tonight. It's just an extraction of tests/src from beanutils. I wasn't sure if that was the right way to go. Hen On Mon, 29 Sep 2003, Sgarlata Matt wrote: +1. Is someone going to step up and create the new [convert] sandbox component? I am not a committer, so I don't think I can help here. I would like to volunteer to draft the mandate for the project, which would basically summarize the issues discussed in this thread. Matt - Original Message - From: Henri Yandell [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Monday, September 29, 2003 12:53 AM Subject: Re: [beanutils] some ideas On Sun, 28 Sep 2003, Sgarlata Matt wrote: From: Henri Yandell [EMAIL PROTECTED] Can anyone think of any others? Something that would need deciding is what to do when the 'from' and the 'to' classes are the same. Should a String-String converter be looked for, or should it optimise it away. I suspect that there just shouldn't be any identity converters pre-registered, but people can always put them in if they wish to. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] jar file names
On Thu, 2 Oct 2003, Stephen Colebourne wrote: Are you familiar with the website creation aspect (I've not updated the website yet :-). Is there a doc/guide? DO we want to use maven for the site? Let me know if you want help here. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] New commons proper component - pcollections
I'm with Gary on the +0. First off, I think that [pcollections] is conceptually within the [collections] realm. People will be confused as to why it is a separate jar. However, if it only supports a Collections API, then it's not going to be as good as it should. It should have a primitive API as well. Splitting pcollections out has some definite perks though. Firstly it separates the releases to avoid two separate codebases having to release together. This is a big advantage. Secondly, it will help to highlight the pcollections code, without any JDK 1.6 [or something] problems when pcollections becomes unnecessary. Lastly, I've not seen a -1 from a collections developer. Rodney and Stephen seem to be agreed on it, so it's a choice I'm perfectly willing to follow. Hen On Tue, 7 Oct 2003, Gary Gregory wrote: Ok, I change my vote to 0. We do use [collections] in our product but I am not coding with it right now so I will defer to you guys as to the ease of working with a mixed (Integer and int) collections model and other details. Gary -Original Message- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 07, 2003 13:21 To: Jakarta Commons Developers List Subject: Re: [VOTE] New commons proper component - pcollections MH Take a look at the codebase for [collections]. It's monstrous. Think about the un-object-oriented-ness required for building a primitive collections library. There already are an unbelievable amount of primitive classes, and there will continue to be more. MH The scope and purpose of the [pcollections] and [collections] components are quite different. The first is extensions and utilities for working with the collections framework. The second involves the creation a new primitive implementation which is similar to the collections framework. I must strongly agree with what Matthew says here. The difference between collections and primitive collections seems very subtle and minor from a high level view. It seems perfectly natural to think of them together. However, when you get down to the low level you actually find them quite different. [collections] provides additions to an established framework in the JDK. pcollections creates something wholely new, styled after an existing API. This is demonstrated most clearly in the fact that the two groups of code are entirely independent. Each can be compiled without the other. (Except the test cases, and that has been dealt with) Other differences include the way code is developed, with pcollections potentially using code generation at some point. There is an additional point, in that [collections] is very widely dispersed and used. To increase its size by over 100% suggests that something should at least be looked at. MH These projects are more different than they appear, and adding another jar is a small price to pay for the proper separation and encapsulation of code. GG Ah... but from an app writer's POV, it would be nice it all appeared seamless. I've not had the need yet for this but I would have that porting from a Collection of Integers (CollectionUtils.typedCollection(collection Integer.class) and a Collection of ints (new ArrayIntList()) would be easy. It still is, but we ask you to include an additional jar. MH When there are too many lines of code, it's good to split one class into many. When there are too many classes, and a distinct separation appears between groups of those classes, it may be good to split one component into many. Yes, it may be, or not. :-) I'm very clear that it is good to split, manage and release separately in this case. GG Good chat, thanks. Ah, but we are lobbying for you to change your vote. If not to +1, at least to a 0. We need to convince you ;-) Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Convert] Mandate (draft)
Hen reminded me I promised to do this, so here is a first crack at a mandate for the proposed Convert sandbox component. One thing I was thinking about is the name. Convert is rather dull, how about calling it Morph instead? I don't know what format we want this mandate in, so for now I have a copy in M$ Word that I will convert (pun intended) to the appropriate format later. Here is a text copy of it: INTRODUCTION Convert is a framework for converting an arbitrary Java object into any other arbitrary Java object. The framework grew out of the conversion mechanism provided by the ConvertUtils class of the BeanUtils framework. One goal of the Convert framework is to integrate seamlessly with BeanUtils. POTENTIAL FEATURES - Provides a simple mechanism for converting an arbitrary Java object into any other arbitrary Java object. - Seamlessly integrates with BeanUtils. - Provides local-sensitive conversions for internationalization. - Allows converters to be written at an arbitrary level of granularity. For example, fine-grained converters can only convert objects of a single class to objects a single other class. Course-grained converters can convert an object of a single class to objects of a multitude of different classes. - (Related to the point above) Provides an automated conversion lookup mechanism that allows conversions for types that have not been specifically registered to be attempted by traversing the inheritance hierarchy of the classes involved in the conversion. - (Related to the point above) Provides a Go4 Strategy that defines how inheritance hierarchies are searched for converters. Some obvious Strategies are included in the Convert framework. - Allows different converters to be used under different circumstances. For example, one module of an application might require dates to be converted to strings one way while another part of the application requires a different standard for a different sent of users. - Provides a library of converters that may be extended by users of the Convert framework. - Provides a converter configuration mechanism that alleviates users from the task of building their own configuration structures. - Provides converters that operate on collections. For example, such a converter might change a List of Person into a List of String. - Allows the identity conversion (for example, String to String) to be turned on or off. PROJECT NAME This project is still in the conceptual phase and a name has not yet been decided upon. Possible names include: - Convert - Morph Matt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Convert] Mandate (draft)
Thanks Matt :) I'm going to go ahead and commit the codebase I've got at the moment. Continued inline... On Tue, 7 Oct 2003, Sgarlata Matt wrote: Hen reminded me I promised to do this, so here is a first crack at a mandate for the proposed Convert sandbox component. One thing I was thinking about is the name. Convert is rather dull, how about calling it Morph instead? I like dull :) Dull doesn't need marketing or religion, it just slowly gains users. I don't know what format we want this mandate in, so for now I have a copy in M$ Word that I will convert (pun intended) to the appropriate format later. Here is a text copy of it: If you look in a Commons project, it has a PROPOSAL.html. This is the format. However, it ought to be written by an Apache committer so your text below would be something I [or someone else] would splice in. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/convert - New directory
bayard 2003/10/07 19:49:58 jakarta-commons-sandbox/convert - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/convert/src - New directory
bayard 2003/10/07 19:50:58 jakarta-commons-sandbox/convert/src - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/convert/src/java/org - New directory
bayard 2003/10/07 19:50:59 jakarta-commons-sandbox/convert/src/java/org - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/convert/src/java - New directory
bayard 2003/10/07 19:50:58 jakarta-commons-sandbox/convert/src/java - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/convert/src/java/org/apache/commons - New directory
bayard 2003/10/07 19:50:59 jakarta-commons-sandbox/convert/src/java/org/apache/commons - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/convert/src/java/org/apache - New directory
bayard 2003/10/07 19:50:59 jakarta-commons-sandbox/convert/src/java/org/apache - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/convert/xdocs - New directory
bayard 2003/10/07 19:50:59 jakarta-commons-sandbox/convert/xdocs - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/convert/src/java/org/apache/commons/convert - New directory
bayard 2003/10/07 19:50:59 jakarta-commons-sandbox/convert/src/java/org/apache/commons/convert - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox project.xml
bayard 2003/10/07 20:00:02
Added: .project.xml
Log:
parent project.xml so that commons-sandbox maven projects can fit the same framework
as commons-proper
Revision ChangesPath
1.1 jakarta-commons-sandbox/project.xml
Index: project.xml
===
?xml version=1.0 encoding=UTF-8?
project
pomVersion3/pomVersion
idcommons-sandbox-master/id
nameCommons Sandbox Master Maven POM/name
currentVersion1.0/currentVersion
organization
nameApache Software Foundation/name
urlhttp://www.apache.org/url
logohttp://jakarta.apache.org/commons/images/jakarta-logo-blue.gif/logo
/organization
logo/images/logo.jpg/logo
packageorg.apache.commons.*/package
gumpRepositoryIdjakarta/gumpRepositoryId
urlhttp://jakarta.apache.org/commons/sandbox/${pom.artifactId.substring(8)}/index.html/url
issueTrackingUrlhttp://nagoya.apache.org//issueTrackingUrl
siteAddressjakarta.apache.org/siteAddress
siteDirectory/www/jakarta.apache.org/commons/sandbox/${pom.artifactId.substring(8)}//siteDirectory
distributionDirectory/www/jakarta.apache.org/builds/jakarta-commons-sandbox/${pom.artifactId.substring(8)}//distributionDirectory
repository
connectionscm:cvs:pserver:[EMAIL
PROTECTED]:/home/cvspublic:jakarta-commons-sandbox/${pom.artifactId.substring(8)}/connection
urlhttp://cvs.apache.org/viewcvs/jakarta-commons-sandbox/${pom.artifactId.substring(8)}//url
/repository
mailingLists
mailingList
nameCommons Dev List/name
subscribe[EMAIL PROTECTED]/subscribe
unsubscribe[EMAIL PROTECTED]/unsubscribe
archivehttp://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]/archive
/mailingList
mailingList
nameCommons User List/name
subscribe[EMAIL PROTECTED]/subscribe
unsubscribe[EMAIL PROTECTED]/unsubscribe
archivehttp://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]/archive
/mailingList
/mailingLists
build
nagEmailAddress[EMAIL PROTECTED]/nagEmailAddress
sourceDirectorysrc/java/sourceDirectory
unitTestSourceDirectorysrc/test/unitTestSourceDirectory
integrationUnitTestSourceDirectory/
aspectSourceDirectory/
!-- Unit test classes --
unitTest
includes
include**/Test*.java/include
/includes
/unitTest
!-- Integration unit test classes --
integrationUnitTestPatterns/integrationUnitTestPatterns
resources
includes
include**/*.properties/include
/includes
/resources
jars/jars
/build
/project
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/convert/xdocs convert.png
bayard 2003/10/07 20:00:47 Added: convert/xdocs convert.png Log: design document Revision ChangesPath 1.1 jakarta-commons-sandbox/convert/xdocs/convert.png Binary file - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/convert project.xml
bayard 2003/10/07 20:01:06 Added: convert project.xml Log: basic project.xml Revision ChangesPath 1.1 jakarta-commons-sandbox/convert/project.xml Index: project.xml === ?xml version=1.0 encoding=UTF-8? project extend../project.xml/extend nameConvert/name idcommons-convert/id logo/logo currentVersion0.1/currentVersion inceptionYear2003/inceptionYear shortDescriptionCommons Convert/shortDescription descriptionJava Conversion Utilities/description urlhttp://jakarta.apache.org/commons/convert//url developers developer nameHenri Yandell/name idbayard/id email[EMAIL PROTECTED]/email organizationApache Software Foundation/organization /developer /developers dependencies /dependencies build unitTest includes include**/*TestCase.java/include /includes /unitTest /build /project - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/convert/src/test/org/apache/commons/convert - New directory
bayard 2003/10/07 20:03:54 jakarta-commons-sandbox/convert/src/test/org/apache/commons/convert - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/convert/src/test/org - New directory
bayard 2003/10/07 20:03:54 jakarta-commons-sandbox/convert/src/test/org - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/convert/src/test - New directory
bayard 2003/10/07 20:03:54 jakarta-commons-sandbox/convert/src/test - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/convert/src/test/org/apache/commons/convert/util - New directory
bayard 2003/10/07 20:03:54 jakarta-commons-sandbox/convert/src/test/org/apache/commons/convert/util - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/convert/src/test/org/apache/commons/convert/array - New directory
bayard 2003/10/07 20:03:54 jakarta-commons-sandbox/convert/src/test/org/apache/commons/convert/array - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/convert/src/test/org/apache/commons/convert/format - New directory
bayard 2003/10/07 20:03:54 jakarta-commons-sandbox/convert/src/test/org/apache/commons/convert/format - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[digester] patches for unit tests
Hi,
Here's a patch to build.xml that forces all log objects to be NoOpLog
when running tests. This suppresses all the annoying output currently
generated.
Setting suppressLogOutputDuringTests=false in a build.properties file
will re-enable logging during tests again.
There might be a more compact way of doing this in the build.xml file;
ant specialists are welcome to optimise. In particular, if the
condition tag can be used outside a target tag, that would help.
Also attached is a patch to remove System.out.println(...) calls from
some of the unit tests.
Regards,
Simon
Index: build.xml
===
RCS file: /home/cvspublic/jakarta-commons/digester/build.xml,v
retrieving revision 1.47
diff -u -r1.47 build.xml
--- build.xml 4 Oct 2003 12:26:51 - 1.47
+++ build.xml 8 Oct 2003 03:03:45 -
@@ -99,6 +99,14 @@
!-- == Test Execution Defaults === --
+ property name=suppressLogOutputDuringTests value=true/
+ property name=log.factoryopt value=org.apache.commons.logging.Log/
+ property name=log.noop value=org.apache.commons.logging.impl.NoOpLog/
+ property name=log.class value=${log.noop}/
+
+ !--
+ property name=logclass value=org.apache.commons.logging.impl.NoOpLog/
+ --
!-- Construct unit test classpath --
path id=test.classpath
@@ -272,8 +280,12 @@
target name=test.factory depends=compile.tests
description=Run tests for loading Digester rules from XML ...
echo message=Running factory create tests .../
+condition property=logopt value=${log.factoryopt}=${log.class}
+ istrue value=${suppressLogOutputDuringTests}/
+/condition
java classname=${test.runner} fork=yes
failonerror=${test.failonerror}
+ jvmarg value=-D${logopt}/
arg value=org.apache.commons.digester.TestFactoryCreate/
classpath refid=test.classpath/
/java
@@ -282,8 +294,12 @@
target name=test.xmlrules depends=compile.tests
description=Run tests for loading Digester rules from XML ...
echo message=Running xmlrules tests .../
+condition property=logopt value=${log.factoryopt}=${log.class}
+ istrue value=${suppressLogOutputDuringTests}/
+/condition
java classname=${test.runner} fork=yes
failonerror=${test.failonerror}
+ jvmarg value=-D${logopt}/
arg value=org.apache.commons.digester.xmlrules.DigesterLoaderTestSuite/
classpath refid=test.classpath/
/java
@@ -293,8 +309,12 @@
target name=test.bpsr depends=compile.tests
description=Run tests for BeanPropertySetterRule ...
echo message=Running BeanPropertySetterRule tests .../
+condition property=logopt value=${log.factoryopt}=${log.class}
+ istrue value=${suppressLogOutputDuringTests}/
+/condition
java classname=${test.runner} fork=yes
failonerror=${test.failonerror}
+ jvmarg value=-D${logopt}/
arg value=org.apache.commons.digester.BeanPropertySetterRuleTestCase/
classpath refid=test.classpath/
/java
@@ -304,8 +324,12 @@
target name=test.callmethod depends=compile.tests
description=Run tests for CallMethodRule and CallParamRule ...
echo message=Running CallMethodRule tests .../
+condition property=logopt value=${log.factoryopt}=${log.class}
+ istrue value=${suppressLogOutputDuringTests}/
+/condition
java classname=${test.runner} fork=yes
failonerror=${test.failonerror}
+ jvmarg value=-D${logopt}/
arg value=org.apache.commons.digester.CallMethodRuleTestCase/
classpath refid=test.classpath/
/java
@@ -314,8 +338,12 @@
target name=test.objectparam depends=compile.tests
description=Run tests for ObjectParamRule ...
echo message=Running ObjectParamRule tests .../
+condition property=logopt value=${log.factoryopt}=${log.class}
+ istrue value=${suppressLogOutputDuringTests}/
+/condition
java classname=${test.runner} fork=yes
failonerror=${test.failonerror}
+ jvmarg value=-D${logopt}/
arg value=org.apache.commons.digester.ObjectParamRuleTestCase/
classpath refid=test.classpath/
/java
@@ -324,8 +352,12 @@
target name=test.digester depends=compile.tests
description=Run basic Digester unit tests ...
echo message=Running basic Digester tests .../
+condition property=logopt value=${log.factoryopt}=${log.class}
+ istrue value=${suppressLogOutputDuringTests}/
+/condition
java classname=${test.runner} fork=yes
failonerror=${test.failonerror}
+ jvmarg value=-D${logopt}/
arg value=org.apache.commons.digester.DigesterTestCase/
classpath refid=test.classpath/
/java
@@ -335,8 +367,12 @@
target name=test.matching depends=compile.tests
description=Run rule Digester test cases
echo message=Running rule Digester tests .../
+condition property=logopt value=${log.factoryopt}=${log.class}
+ istrue
cvs commit: jakarta-commons-sandbox/convert/src/java/org/apache/commons/convert ConvertUtils.java
bayard 2003/10/07 20:18:34 Modified:convert/src/java/org/apache/commons/convert ConvertUtils.java Log: commented out CollectionConverter until it is added Revision ChangesPath 1.2 +4 -4 jakarta-commons-sandbox/convert/src/java/org/apache/commons/convert/ConvertUtils.java Index: ConvertUtils.java === RCS file: /home/cvs/jakarta-commons-sandbox/convert/src/java/org/apache/commons/convert/ConvertUtils.java,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- ConvertUtils.java 8 Oct 2003 03:03:14 - 1.1 +++ ConvertUtils.java 8 Oct 2003 03:18:34 - 1.2 @@ -118,7 +118,7 @@ registry.register( new URLConverter(), String.class, java.net.URL.class ); registry.register( new ArrayConverter( registry ), String.class, Object[].class ); -registry.register( new CollectionConverter( registry ), String.class, java.util.Collection.class ); +//registry.register( new CollectionConverter( registry ), String.class, java.util.Collection.class ); } // aka Formatters - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Convert] Mandate (draft)
Henri Yandell wrote: Thanks Matt :) I'm going to go ahead and commit the codebase I've got at the moment. Continued inline... On Tue, 7 Oct 2003, Sgarlata Matt wrote: Hen reminded me I promised to do this, so here is a first crack at a mandate for the proposed Convert sandbox component. One thing I was thinking about is the name. Convert is rather dull, how about calling it Morph instead? I like dull :) Dull doesn't need marketing or religion, it just slowly gains users. The original Commons Charter recommended dull functional names as well -- in the sense that the names should be as descriptive as possible of the underlying functionality, not some made-up word or association that nobody has a clue about. Why that text disappeared is something I need to research separately. In the mean time (and as a Jakarta PMC member as well as an active Commons contributor), -1 on foo-foo names for Commons packages that don't have any linkage to reality. +1 on convert (or something similar) to cover this particular functional area. If your code can't earn new users on its own merits without a whiz-bang name, it doesn't belong in Jakarta Commons. I don't know what format we want this mandate in, so for now I have a copy in M$ Word that I will convert (pun intended) to the appropriate format later. Here is a text copy of it: If you look in a Commons project, it has a PROPOSAL.html. This is the format. However, it ought to be written by an Apache committer so your text below would be something I [or someone else] would splice in. Hen Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[convert] initial code commit
Code now committed to commons-sandbox. There's also an object diagram in
the xdocs directory.
{braindump}
I've got a CollectionsConverter which currently does not pass tests. Not
sure it's finished either. So not committed yet.
The ArrayConverter ought to replace all the array converters in BeanUtils,
so it might be worth committing to BeanUtils if nothing comes of
[convert].
I dumped the old ConvertUtils and ConvertUtilsBean and coded from scratch.
ConvertRegistry is the name for my replacement, which acts solely as an
instance. No attempts to be bean-like or to act as a special static thing.
Those may be tacked on later on.
Currently it uses inheritence for both fromClass and toClass. Recent mail
on the list explain why I think it's bad for toClass.
The string sub-package is a direct copy of BeanUtils, with the array ones
removed.
//H? and // TODO are both notations I use to indicate questions/todos.
You need the project.xml I just commited to the sandbox top level to
build using Maven. No ant build as yet.
I've ignored Locale concepts and default values to keep things simpler.
{/braindump}
Apologies for playing with this on my own for a week. I was having fun :)
Hen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [validator] Password fields [WAS] Re: cvs commit: jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript validateMaxLength.js validateMinLength.js
David Graham wrote:
It is inherently insecure to reveal the specific details of password
validation in client side scripting. Validator and Struts should be as
secure as possible out of the box so I am -1 on this change. Please
revert the changes until we come up with a better solution. Bugzilla
isn't the easiest place to have this discussion so it might be better
suited for commons-dev.
I thought that the length was only revealed in the error message but it is
indeed shown in snippets like:
this.maxlength='4'; this.minlength='4';
I agree that the best solution at the moment is not to use validator on
password forms.
David
Also the server side validations reveal max/min lengths, there.
Currently, the validator server side
validations are loosely coupled. A solution would be to prevent the user
from using max/min length
checks either client or server side would increase coupling. One
possible attempt to solve this
by placing an optional attribute for the user to tell us that the field is
a password so we could disallow maxlength or minlength would not work
because they would just
not mark the field as a 'password'.
A proactive step might be to have the generated javascript create a
dialog if the field is a
'password' field and it attempts to validate a max/minlength constraint.
It would warn them that
validating max/min fields is discouraged. A client side validation would
be allowed by setting parameter
in the html:javascript tag. This would catch both client side and
server side cases, given that javascript
is enabled.
Generally though I believe it would be cleanest if the commons-validator
didn't dictate what field types
could/could not be validated. This decision could be left up to the
enclosing framework, as I described
above.
--- [EMAIL PROTECTED] wrote:
rleland 2003/10/06 20:00:15
Modified:
validator/src/javascript/org/apache/commons/validator/javascript
validateMaxLength.js validateMinLength.js
Log:
Bug#: 12473
Let max/min length also cover passwords fields.
If users don't want the password min/max parameters
revealed then they shouldn't use the validator.
Currently in struts the min/max values are still
in the html, anyway. There is no easy/clean workaround.
Just don't use validator.
Revision ChangesPath
1.3 +4 -3
jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript/validateMaxLength.js
Index: validateMaxLength.js
===
RCS file:
/home/cvs/jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript/validateMaxLength.js,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- validateMaxLength.js 15 Aug 2003 20:22:03 - 1.2
+++ validateMaxLength.js 7 Oct 2003 03:00:15 - 1.3
@@ -13,6 +13,7 @@
var field = form[oMaxLength[x][0]];
if (field.type == 'text' ||
+field.type == 'password' ||
field.type == 'textarea') {
var iMax = parseInt(oMaxLength[x][2](maxlength));
1.4 +4 -3
jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript/validateMinLength.js
Index: validateMinLength.js
===
RCS file:
/home/cvs/jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript/validateMinLength.js,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- validateMinLength.js 15 Aug 2003 20:22:03 - 1.3
+++ validateMinLength.js 7 Oct 2003 03:00:15 - 1.4
@@ -13,6 +13,7 @@
var field = form[oMinLength[x][0]];
if (field.type == 'text' ||
+field.type == 'password' ||
field.type == 'textarea') {
var iMin = parseInt(oMinLength[x][2](minlength));
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
__
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Convert] Mandate (draft)
Replying inline to describe what parts are in the code I just submitted: On Tue, 7 Oct 2003, Sgarlata Matt wrote: Hen reminded me I promised to do this, so here is a first crack at a mandate for the proposed Convert sandbox component. One thing I was thinking about is the name. Convert is rather dull, how about calling it Morph instead? I went with convert, but names are easy to change. INTRODUCTION Convert is a framework for converting an arbitrary Java object into any other arbitrary Java object. The framework grew out of the conversion mechanism provided by the ConvertUtils class of the BeanUtils framework. One goal of the Convert framework is to integrate seamlessly with BeanUtils. Currently I'm assuming that BeanUtils would keep their ConvertUtils and ConvertUtilsBean. Those classes would wrap ConvertRegistry. Just a wild assumption at the moment. The system is Object-Object, though I suspect that 95% of converters will be String-Object or Object-String. I did have a Parser and a Formatter interface to highlight which ones were String-Object or Object-String, but hadn't used them anywhere so pulled them before commiting. POTENTIAL FEATURES - Provides a simple mechanism for converting an arbitrary Java object into any other arbitrary Java object. Probably about 4 lines needed at the moment :) Not quite simple, but that can be wrapped. - Seamlessly integrates with BeanUtils. - Provides local-sensitive conversions for internationalization. Have ignored this. I think it's indicative of a larger problem of getting context arguments to a Converter. - Allows converters to be written at an arbitrary level of granularity. For example, fine-grained converters can only convert objects of a single class to objects a single other class. Course-grained converters can convert an object of a single class to objects of a multitude of different classes. - (Related to the point above) Provides an automated conversion lookup mechanism that allows conversions for types that have not been specifically registered to be attempted by traversing the inheritance hierarchy of the classes involved in the conversion. Implemented. Probably should only apply to the fromClass side, which just means that the ConvertRegistry should be a ClassMap of HashMap, and not a ClassMap of ClassMap. - (Related to the point above) Provides a Go4 Strategy that defines how inheritance hierarchies are searched for converters. Some obvious Strategies are included in the Convert framework. I submitted ClassMap to Collections a while back, but it lacked a pluggable inheritence strategy. I've got a pluggable inheritence strategy in there now, so opinions on this would be much appreciated. - Allows different converters to be used under different circumstances. For example, one module of an application might require dates to be converted to strings one way while another part of the application requires a different standard for a different sent of users. Different registries? :) No idea on different inputs required other than fromClass/toClass. Context again. - Provides a library of converters that may be extended by users of the Convert framework. Need to look at Stephen's JODA converters for another batch. Need to finish coding CollectionConverter [problems in the number of Class types going on]. - Provides a converter configuration mechanism that alleviates users from the task of building their own configuration structures. Commons Configuration? Needs to be a separate jar to the central convert jar I think. - Provides converters that operate on collections. For example, such a converter might change a List of Person into a List of String. What gets really painful is, what if they want to convert a List of Person into a String[]. Just how do they specify that. Collection C of X to Collection C of Y is easy enough, but converting Collection type at the same time causes problems with the registering. This is part of why inheritence started to hurt. I think we should be able to request a converter of: ArrayList-String[] and it would be smart enough to build a chain of converters. Association rather than Inheritence. - Allows the identity conversion (for example, String to String) to be turned on or off. Nothing done on this. PROJECT NAME This project is still in the conceptual phase and a name has not yet been decided upon. Possible names include: - Convert - Morph +1 Convert. It's been in informal use for quite a while. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] New commons proper component - pcollections
Stephen Colebourne wrote: There is an additional point, in that [collections] is very widely dispersed and used. To increase its size by over 100% suggests that something should at least be looked at. This is not an issue. If a class is not used it will not be be loaded into the JVM. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [convert] initial code commit
To save people effort, the design doc is: http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/convert/xdocs/convert.png?rev=HEADcontent-type=text/vnd.viewcvs-markup Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Convert] Mandate (draft)
The system is Object-Object, though I suspect that 95% of converters will be String-Object or Object-String. It would also be nice to have Object-primitive as well. Particularly when combined with the chaining you mention later on. You could convert Object-Integer, then Integer-int. Though the creation of an extra object may be a waste in some cases. Just something to think about. I'm very interested in this project btw, but have very little available time. Regards, Adrian Sutton, Software Engineer Ephox Corporation www.ephox.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [validator] Password fields [WAS] Re: cvs commit: jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript validateMaxLength.js validateMinLength.js
--- Robert Leland [EMAIL PROTECTED] wrote:
David Graham wrote:
It is inherently insecure to reveal the specific details of password
validation in client side scripting. Validator and Struts should be as
secure as possible out of the box so I am -1 on this change. Please
revert the changes until we come up with a better solution. Bugzilla
isn't the easiest place to have this discussion so it might be better
suited for commons-dev.
I thought that the length was only revealed in the error message but it
is
indeed shown in snippets like:
this.maxlength='4'; this.minlength='4';
I agree that the best solution at the moment is not to use validator on
password forms.
David
Also the server side validations reveal max/min lengths, there.
Currently, the validator server side
validations are loosely coupled. A solution would be to prevent the user
from using max/min length
checks either client or server side would increase coupling. One
possible attempt to solve this
by placing an optional attribute for the user to tell us that the field
is
a password so we could disallow maxlength or minlength would not work
because they would just
not mark the field as a 'password'.
A proactive step might be to have the generated javascript create a
dialog if the field is a
'password' field and it attempts to validate a max/minlength constraint.
It would warn them that
validating max/min fields is discouraged. A client side validation would
be allowed by setting parameter
in the html:javascript tag. This would catch both client side and
server side cases, given that javascript
is enabled.
Generally though I believe it would be cleanest if the commons-validator
didn't dictate what field types
could/could not be validated. This decision could be left up to the
enclosing framework, as I described
above.
Validator won't be dictating anything; it just won't validate password
fields on the client side out of the box. Indeed, the options you mention
above would be dictating behavior to the client.
As we can see from the change you committed, adding password field
checking is trivial. It should be the developer's conscious decision to
patch the code and reveal password rules to the client, not Validator's.
Quoting from http://jakarta.apache.org/site/mission.html part of every
Apache project is, security as a mandatory feature. We would violate
this principal if we reveal password validation rules on the client side.
The validation rules are only exposed if you use Struts' html:javascript
tag on the form. You can still use Validator for password fields if you
don't include javascript validation and use only server side checks. A
warning in the Struts user's guide may be the best we can do because
Validator has no real way of knowing what fields are passwords.
I'm still -1 on this last commit for the reasons stated. Please revert
this change to not validate password fields in the javascript.
David
--- [EMAIL PROTECTED] wrote:
rleland 2003/10/06 20:00:15
Modified:
validator/src/javascript/org/apache/commons/validator/javascript
validateMaxLength.js validateMinLength.js
Log:
Bug#: 12473
Let max/min length also cover passwords fields.
If users don't want the password min/max parameters
revealed then they shouldn't use the validator.
Currently in struts the min/max values are still
in the html, anyway. There is no easy/clean workaround.
Just don't use validator.
Revision ChangesPath
1.3 +4 -3
jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript/validateMaxLength.js
Index: validateMaxLength.js
===
RCS file:
/home/cvs/jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript/validateMaxLength.js,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- validateMaxLength.js 15 Aug 2003 20:22:03 - 1.2
+++ validateMaxLength.js 7 Oct 2003 03:00:15 - 1.3
@@ -13,6 +13,7 @@
var field = form[oMaxLength[x][0]];
if (field.type == 'text' ||
+field.type == 'password' ||
field.type == 'textarea') {
var iMax = parseInt(oMaxLength[x][2](maxlength));
1.4 +4 -3
jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript/validateMinLength.js
Index: validateMinLength.js
===
RCS file:
/home/cvs/jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript/validateMinLength.js,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- validateMinLength.js 15 Aug 2003
Re: [validator] Password fields [WAS] Re: cvs commit: jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript validateMaxLength.js validateMinLength.js
David Graham wrote: The validation rules are only exposed if you use Struts' html:javascript Not true they are exposed by server side validation also. The error messages clearly state the min/max values. I'm still -1 on this last commit for the reasons stated. Please revert this change to not validate password fields in the javascript. +1, will do it tomorrow. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Convert] Mandate (draft)
The system is Object-Object, though I suspect that 95% of converters will be String-Object or Object-String. I'm thinking that this could be useful for JNDI Object and State Factories. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Convert] Mandate (draft)
+0 on the general concept of exploring a conversion support package. More comments below. Sgarlata Matt wrote: Hen reminded me I promised to do this, so here is a first crack at a mandate for the proposed Convert sandbox component. One thing I was thinking about is the name. Convert is rather dull, how about calling it Morph instead? See previous mails. -1 on any name that is not totally focused on the functionality being supported. I don't know what format we want this mandate in, so for now I have a copy in M$ Word that I will convert (pun intended) to the appropriate format later. Here is a text copy of it: If you don't publish in some open format (txt, html, ...), you have just lost the majority of your potential audience :-). INTRODUCTION Convert is a framework for converting an arbitrary Java object into any other arbitrary Java object. The framework grew out of the conversion mechanism provided by the ConvertUtils class of the BeanUtils framework. One goal of the Convert framework is to integrate seamlessly with BeanUtils. POTENTIAL FEATURES - Provides a simple mechanism for converting an arbitrary Java object into any other arbitrary Java object. - Seamlessly integrates with BeanUtils. That only works if you push us BeanUtils committers towards a portable way to replace the standard singleton instances that are available in the latest nightly builds, plus convince us why it's important enough to go to a 2.x version number (adding new dependencies is a very non-trivial exercise for existing users of a Commons package, so i'm -1 on adding any without a change to the major verson number. - Provides local-sensitive conversions for internationalization. How does this go beyond what the locale subpackage of BeanUtils already provides? - Allows converters to be written at an arbitrary level of granularity. For example, fine-grained converters can only convert objects of a single class to objects a single other class. Course-grained converters can convert an object of a single class to objects of a multitude of different classes. My advice is to implement coarse-grainedness based on inheritance hierarchy (if there's no converter for java.sql.Date, use the one for its superclass java.util.Date instead). - (Related to the point above) Provides an automated conversion lookup mechanism that allows conversions for types that have not been specifically registered to be attempted by traversing the inheritance hierarchy of the classes involved in the conversion. Yep. And don't forget to make the lookup mechanism work in a servlet container, where individual webapps might want individual resolutions (even if the conversion package is in a parent class loader). - (Related to the point above) Provides a Go4 Strategy that defines how inheritance hierarchies are searched for converters. Some obvious Strategies are included in the Convert framework. - Allows different converters to be used under different circumstances. For example, one module of an application might require dates to be converted to strings one way while another part of the application requires a different standard for a different sent of users. - Provides a library of converters that may be extended by users of the Convert framework. - Provides a converter configuration mechanism that alleviates users from the task of building their own configuration structures Class libraries like this should provie configuration mechansims should be provided through APIs. Support for automatic processing of things like properties files or XML configuration documents should be optional ease-of-use features, not fundamental requirements. - Provides converters that operate on collections. For example, such a converter might change a List of Person into a List of String. - Allows the identity conversion (for example, String to String) to be turned on or off. You haven't mentioned the most important consideration -- whether conversion is an Object-Object use case, or whether it's actually bidirectional (Object-String and String-Object). There is room in the world for conversion packages that support both viewpoints; however, pretending that a single Object-Object package can support both is the biggest weakness in the current BeanUtils conversion model. FWIW, JavaServer Faces is likely to end up with an explicitly bidirectional Object-String and String-Object) conversion API. This makes sense because JavaServer Faces is rooted in an environment that represents nearly all business data as Strings. But it's worth evaluating this pattern for general purpose use as well. PROJECT NAME This project is still in the conceptual phase and a name has not yet been decided upon. Possible names include: - Convert +1 - Morph -1 on any foo-foo name, as per my previous response. Morph isn't the worst possible choice, but it's definitely worse than convert. Matt Craig
Re: [convert] initial code commit
Henri Yandell wrote:
You need the project.xml I just commited to the sandbox top level to
build using Maven. No ant build as yet.
The former requirement doesn't cause me any grief. The later is an
absolute prerequisite if you would like nightly builds produced like we
do for the other commons and sandbox packages. Fortunately, it's fairly
easy to create such a thing: maven ant:generate-build and then check
in the corresponding build.xml file.
I've ignored Locale concepts and default values to keep things simpler.
Locale concepts are the only thing that makes conversion issues even
mildly interesting :-).
{/braindump}
Apologies for playing with this on my own for a week. I was having fun :)
Hen
Craig
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [validator] Password fields [WAS] Re: cvs commit: jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript validateMaxLength.js validateMinLength.js
Robert Leland wrote: David Graham wrote: The validation rules are only exposed if you use Struts' html:javascript Not true they are exposed by server side validation also. The error messages clearly state the min/max values. But even that is only exposed if you use the validator framework's minLength checks. If I didn't want to expose the fact that I cared about such things, I'd use two different validation mechanisms: * On the login screen, I'd use nothing except (perhaps) a required validation. * On the admin screen that lets me change my own password, I'd write a custom validator method + appropriate JavaScript -- or, more likely, implemented this as a server side check that approved a proposed password (minimum length, appropriate mixture of letters and digits, not in a dictionary, ...) without exposing *anything* about why a password might get rejected. Of course, there's a usability issue here, too ... if you impose particular rules for passwords in the code but don't tell your users about what the rules are, you're bound to frustrate them when they try to set their own passwords to a new value, but don't know why you're not allowing the proposed value. Anyone who objects to exposing a minimum password length rule to the general public shoudn't be employing such a validation rule on their login screens in the first place. I'm still -1 on this last commit for the reasons stated. Please revert this change to not validate password fields in the javascript. +1, will do it tomorrow. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/jelly build.xml
dion2003/10/07 22:38:32
Modified:jellybuild.xml
Log:
Remove absolute paths
Revision ChangesPath
1.78 +6 -6 jakarta-commons/jelly/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-commons/jelly/build.xml,v
retrieving revision 1.77
retrieving revision 1.78
diff -u -r1.77 -r1.78
--- build.xml 1 Oct 2003 08:21:31 - 1.77
+++ build.xml 8 Oct 2003 05:38:32 - 1.78
@@ -1,7 +1,7 @@
?xml version=1.0 encoding=UTF-8?
!--build.xml generated by maven from project.xml version 1.0-beta-4-SNAPSHOT
- on date October 1 2003, time 1817--
+ on date October 8 2003, time 1532--
project default=jar name=commons-jelly basedir=.
property name=defaulttargetdir value=target
@@ -33,7 +33,7 @@
/mkdir
javac destdir=${classesdir} deprecation=true debug=true optimize=false
excludes=**/package.html
src
-pathelement location=C:\source\jakarta\jakarta-commons\jelly\src\java
+pathelement location=src\java
/pathelement
/src
classpath
@@ -44,13 +44,13 @@
/classpath
/javac
copy todir=${classesdir}
- fileset dir=C:\source\jakarta\jakarta-commons\jelly\src\java
+ fileset dir=src\java
include name=**/*.properties
/include
/fileset
/copy
copy todir=${testclassesdir}
- fileset dir=C:\source\jakarta\jakarta-commons\jelly\src\test
+ fileset dir=src\test
include name=META-INF/services/*
/include
include name=**/*.jelly
@@ -115,7 +115,7 @@
/pathelement
/classpath
batchtest todir=${testreportdir}
-fileset dir=C:\source\jakarta\jakarta-commons\jelly\src\test
+fileset dir=src\test
include name=**/Test*.java
/include
/fileset
@@ -127,7 +127,7 @@
/mkdir
javac destdir=${testclassesdir} deprecation=true debug=true
optimize=false excludes=**/package.html
src
-pathelement location=C:\source\jakarta\jakarta-commons\jelly\src\test
+pathelement location=src\test
/pathelement
/src
classpath
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/jelly build.xml
dion2003/10/07 22:42:46
Modified:jellybuild.xml
Log:
Use forward slashes
Revision ChangesPath
1.79 +6 -6 jakarta-commons/jelly/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-commons/jelly/build.xml,v
retrieving revision 1.78
retrieving revision 1.79
diff -u -r1.78 -r1.79
--- build.xml 8 Oct 2003 05:38:32 - 1.78
+++ build.xml 8 Oct 2003 05:42:46 - 1.79
@@ -1,7 +1,7 @@
?xml version=1.0 encoding=UTF-8?
!--build.xml generated by maven from project.xml version 1.0-beta-4-SNAPSHOT
- on date October 8 2003, time 1532--
+ on date October 8 2003, time 1541--
project default=jar name=commons-jelly basedir=.
property name=defaulttargetdir value=target
@@ -33,7 +33,7 @@
/mkdir
javac destdir=${classesdir} deprecation=true debug=true optimize=false
excludes=**/package.html
src
-pathelement location=src\java
+pathelement location=src/java
/pathelement
/src
classpath
@@ -44,13 +44,13 @@
/classpath
/javac
copy todir=${classesdir}
- fileset dir=src\java
+ fileset dir=src/java
include name=**/*.properties
/include
/fileset
/copy
copy todir=${testclassesdir}
- fileset dir=src\test
+ fileset dir=src/test
include name=META-INF/services/*
/include
include name=**/*.jelly
@@ -115,7 +115,7 @@
/pathelement
/classpath
batchtest todir=${testreportdir}
-fileset dir=src\test
+fileset dir=src/test
include name=**/Test*.java
/include
/fileset
@@ -127,7 +127,7 @@
/mkdir
javac destdir=${testclassesdir} deprecation=true debug=true
optimize=false excludes=**/package.html
src
-pathelement location=src\test
+pathelement location=src/test
/pathelement
/src
classpath
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22654] - [Maven] Migrate checkstyle.properties to XML
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=22654. 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=22654 [Maven] Migrate checkstyle.properties to XML --- Additional Comments From [EMAIL PROTECTED] 2003-10-07 08:10 --- Odi, I just realized that you have committed the patch. Do you think the bug report can be closed or there is still something that you would like to do about it? Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IBMJSSE implementation issue
Oleg, Thank you for your additional research, if I enable the log I have : DEBUG org.apache.commons.httpclient.HttpClient - Java version: 1.3.1 DEBUG org.apache.commons.httpclient.HttpClient - Java vendor: IBM Corporation DEBUG org.apache.commons.httpclient.HttpClient - Java class path: C:\Laurent\wsad\workspace\Laurent Test;C:\Laurent\wsad\lib\commons-httpclient-2.0-rc1.jar;C:\Laurent\wsad\work space\Toolbox;C:\Program Files\IBM\WebSphere Studio\eclipse\plugins\org.apache.xerces_4.0.7\xercesImpl.jar;C:\Program Files\IBM\WebSphere Studio\runtimes\aes_v4_jars\lib\xerces.jar;C:\Program Files\IBM\WebSphere Studio\runtimes\base_v5\java\jre\lib\ext\activation.jar;C:\Laurent\wsad\lib\ jakarta-regexp-1.2.jar;C:\Laurent\wsad\lib\jce1_2_2.jar;C:\Laurent\wsad\lib\ junit.jar;C:\Laurent\wsad\lib\local_policy.jar;C:\Laurent\wsad\lib\sunjce_pr ovider.jar;C:\Laurent\wsad\lib\US_export_policy.jar;C:\Laurent\wsad\lib\jdbc 2_0-stdext.jar;C:\Laurent\wsad\lib\struts.jar;C:\Laurent\wsad\lib\commons-co dec-1.1.jar;C:\Program Files\IBM\WebSphere Studio\runtimes\base_v5\java\jre\lib\ext\mail.jar;C:\Laurent\wsad\lib\log4j- 1.2.8.jar;C:\Laurent\wsad\lib\commons-logging.jar;C:\Laurent\wsad\lib\jcert. jar;C:\Laurent\wsad\lib\jnet.jar;C:\Laurent\wsad\lib\jsse.jar;C:\Laurent\wsa d\lib\commons-httpclient.jar DEBUG org.apache.commons.httpclient.HttpClient - Operating system name: Windows 2000 DEBUG org.apache.commons.httpclient.HttpClient - Operating system architecture: x86 DEBUG org.apache.commons.httpclient.HttpClient - Operating system version: 5.0 DEBUG org.apache.commons.httpclient.HttpClient - SUN 1.2: SUN (DSA key/parameter generation; DSA signing; SHA-1, MD5 digests; SecureRandom; X.509 certificates; JKS keystore) DEBUG org.apache.commons.httpclient.HttpClient - IBMJCE 1.2: IBMJCE Provider implements the following: HMAC-SHA1, MD2, MD5, MARS, SHA, MD2withRSA, MD5withRSA, SHA1withRSA, RSA, SHA1withDSA, RC2, RC4, Seal)implements the following: Signature algorithms : SHA1withDSA, SHA1withRSA, MD5withRSA, MD2withRSA Cipher algorithms : Blowfish, AES, DES, TripleDES, PBEWithMD2AndDES, PBEWithMD2AndTripleDES, PBEWithMD2AndRC2, PBEWithMD5AndDES, PBEWithMD5AndTripleDES, PBEWithMD5AndRC2, PBEWithSHA1AndDES PBEWithSHA1AndTripleDES, PBEWithSHA1AndRC2 PBEWithSHAAnd40BitRC2, PBEWithSHAAnd128BitRC2 PBEWithSHAAnd40BitRC4, PBEWithSHAAnd128BitRC4 PBEWithSHAAnd2KeyTripleDES, PBEWithSHAAnd3KeyTripleDES Mars, RC2, RC4, RSA, Seal Message authentication code (MAC) : HmacSHA1, HmacMD2, HmacMD5 Key agreement algorithm : DiffieHellman Key (pair) generator : Blowfish, DiffieHellman, DSA, AES, DES, TripleDES, HmacMD5, HmacSHA1, Mars, RC2, RC4, RSA, Seal Message digest : MD2, MD5, SHA-1 Algorithm parameter generator : DiffieHellman, DSA Algorithm parameter : Blowfish, DiffieHellman, AES, DES, TripleDES, DSA, Mars, PBEwithMD5AndDES, RC2 Key factory : DiffieHellman, DSA, RSA Secret key factory : Blowfish, AES, DES, TripleDES, Mars, RC2, RC4, Seal PKCS5Key, PBKDF1 and PBKDF2(PKCS5Derived Key). Certificate : X.509 Secure random : IBMSecureRandom Key store : JCEKS, PKCS12KS (PKCS12), JKS DEBUG org.apache.commons.httpclient.HttpClient - IBMJSSE 1.4: IBM JSSE provider DEBUG org.apache.commons.httpclient.HttpClient - IBMCertPath 1.0: IBMCertPath Provider implements the following: CertificateFactory : X.509 CertPathValidator : PKIX CertStore : Collection, LDAP CertPathBuilder : PKIX DEBUG org.apache.commons.httpclient.HttpClient - IBMPKCS11 1.2: IBMPKCS11 Provider implements the following: MD2withRSA, MD5withRSA, SHA1withRSA, RSA, SHA1withDSA)implements the following: Signature algorithms : SHA1withDSA, SHA1withRSA, MD5withRSA, MD2withRSA Key (pair) generator : DSA, RSA Algorithm parameter generator : DSA Algorithm parameter : DSA Certificate : X.509 Secure random : IBMSecureRandom Key store : PKCS11 (PKCS11KS) DEBUG org.apache.commons.httpclient.methods.GetMethod - enter GetMethod(String) DEBUG org.apache.commons.httpclient.HttpClient - enter HttpClient.executeMethod(HttpMethod) DEBUG org.apache.commons.httpclient.HttpClient - enter HttpClient.executeMethod(HostConfiguration,HttpMethod,HttpState) DEBUG org.apache.commons.httpclient.HttpConnection - HttpConnection.setSoTimeout(0) DEBUG org.apache.commons.httpclient.HttpConnection - enter HttpConnection.open() DEBUG org.apache.commons.httpclient.HttpConnection - enter HttpConnection.closeSockedAndStreams() DEBUG org.apache.commons.httpclient.HttpConnection - enter HttpConnection.releaseConnection() java.net.SocketException: Socket closed at java.net.PlainSocketImpl.socketGetOption(Native Method) at java.net.PlainSocketImpl.getOption(PlainSocketImpl.java:214) at java.net.Socket.getSendBufferSize(Socket.java:548) at org.apache.commons.httpclient.HttpConnection.open(HttpConnection.java:700) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:625) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:500) at
RE: IBMJSSE implementation issue
Laurent, I did some additional tests. With the java.net.Socket.getSendBufferSize method call commented out, HttpClient works with IBMJSSE 1.0 without a hitch. However, I think you should try to get IBM to look at the problem. To me this clearly looks like a bug in their implementation of JSSE. Oleg -Original Message- From: Laurent Garcia [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 07, 2003 10:07 To: Commons HttpClient Project Subject: Re: IBMJSSE implementation issue Oleg, Thank you for your additional research, if I enable the log I have : DEBUG org.apache.commons.httpclient.HttpClient - Java version: 1.3.1 DEBUG org.apache.commons.httpclient.HttpClient - Java vendor: IBM Corporation DEBUG org.apache.commons.httpclient.HttpClient - Java class path: C:\Laurent\wsad\workspace\Laurent Test;C:\Laurent\wsad\lib\commons-httpclient-2.0-rc1.jar;C:\Laurent\wsad\work space\Toolbox;C:\Program Files\IBM\WebSphere Studio\eclipse\plugins\org.apache.xerces_4.0.7\xercesImpl.jar;C:\Program Files\IBM\WebSphere Studio\runtimes\aes_v4_jars\lib\xerces.jar;C:\Program Files\IBM\WebSphere Studio\runtimes\base_v5\java\jre\lib\ext\activation.jar;C:\Laurent\wsad\lib\ jakarta-regexp-1.2.jar;C:\Laurent\wsad\lib\jce1_2_2.jar;C:\Laurent\wsad\lib\ junit.jar;C:\Laurent\wsad\lib\local_policy.jar;C:\Laurent\wsad\lib\sunjce_pr ovider.jar;C:\Laurent\wsad\lib\US_export_policy.jar;C:\Laurent\wsad\lib\jdbc 2_0-stdext.jar;C:\Laurent\wsad\lib\struts.jar;C:\Laurent\wsad\lib\commons-co dec-1.1.jar;C:\Program Files\IBM\WebSphere Studio\runtimes\base_v5\java\jre\lib\ext\mail.jar;C:\Laurent\wsad\lib\log4j- 1.2.8.jar;C:\Laurent\wsad\lib\commons-logging.jar;C:\Laurent\wsad\lib\jcert. jar;C:\Laurent\wsad\lib\jnet.jar;C:\Laurent\wsad\lib\jsse.jar;C:\Laurent\wsa d\lib\commons-httpclient.jar DEBUG org.apache.commons.httpclient.HttpClient - Operating system name: Windows 2000 DEBUG org.apache.commons.httpclient.HttpClient - Operating system architecture: x86 DEBUG org.apache.commons.httpclient.HttpClient - Operating system version: 5.0 DEBUG org.apache.commons.httpclient.HttpClient - SUN 1.2: SUN (DSA key/parameter generation; DSA signing; SHA-1, MD5 digests; SecureRandom; X.509 certificates; JKS keystore) DEBUG org.apache.commons.httpclient.HttpClient - IBMJCE 1.2: IBMJCE Provider implements the following: HMAC-SHA1, MD2, MD5, MARS, SHA, MD2withRSA, MD5withRSA, SHA1withRSA, RSA, SHA1withDSA, RC2, RC4, Seal)implements the following: Signature algorithms : SHA1withDSA, SHA1withRSA, MD5withRSA, MD2withRSA Cipher algorithms : Blowfish, AES, DES, TripleDES, PBEWithMD2AndDES, PBEWithMD2AndTripleDES, PBEWithMD2AndRC2, PBEWithMD5AndDES, PBEWithMD5AndTripleDES, PBEWithMD5AndRC2, PBEWithSHA1AndDES PBEWithSHA1AndTripleDES, PBEWithSHA1AndRC2 PBEWithSHAAnd40BitRC2, PBEWithSHAAnd128BitRC2 PBEWithSHAAnd40BitRC4, PBEWithSHAAnd128BitRC4 PBEWithSHAAnd2KeyTripleDES, PBEWithSHAAnd3KeyTripleDES Mars, RC2, RC4, RSA, Seal Message authentication code (MAC) : HmacSHA1, HmacMD2, HmacMD5 Key agreement algorithm : DiffieHellman Key (pair) generator : Blowfish, DiffieHellman, DSA, AES, DES, TripleDES, HmacMD5, HmacSHA1, Mars, RC2, RC4, RSA, Seal Message digest : MD2, MD5, SHA-1 Algorithm parameter generator : DiffieHellman, DSA Algorithm parameter : Blowfish, DiffieHellman, AES, DES, TripleDES, DSA, Mars, PBEwithMD5AndDES, RC2 Key factory : DiffieHellman, DSA, RSA Secret key factory : Blowfish, AES, DES, TripleDES, Mars, RC2, RC4, Seal PKCS5Key, PBKDF1 and PBKDF2(PKCS5Derived Key). Certificate : X.509 Secure random : IBMSecureRandom Key store : JCEKS, PKCS12KS (PKCS12), JKS DEBUG org.apache.commons.httpclient.HttpClient - IBMJSSE 1.4: IBM JSSE provider DEBUG org.apache.commons.httpclient.HttpClient - IBMCertPath 1.0: IBMCertPath Provider implements the following: CertificateFactory : X.509 CertPathValidator : PKIX CertStore : Collection, LDAP CertPathBuilder : PKIX DEBUG org.apache.commons.httpclient.HttpClient - IBMPKCS11 1.2: IBMPKCS11 Provider implements the following: MD2withRSA, MD5withRSA, SHA1withRSA, RSA, SHA1withDSA)implements the following: Signature algorithms : SHA1withDSA, SHA1withRSA, MD5withRSA, MD2withRSA Key (pair) generator : DSA, RSA Algorithm parameter generator : DSA Algorithm parameter : DSA Certificate : X.509 Secure random : IBMSecureRandom Key store : PKCS11 (PKCS11KS) DEBUG org.apache.commons.httpclient.methods.GetMethod - enter GetMethod(String) DEBUG org.apache.commons.httpclient.HttpClient - enter HttpClient.executeMethod(HttpMethod) DEBUG org.apache.commons.httpclient.HttpClient - enter HttpClient.executeMethod(HostConfiguration,HttpMethod,HttpState) DEBUG org.apache.commons.httpclient.HttpConnection - HttpConnection.setSoTimeout(0) DEBUG org.apache.commons.httpclient.HttpConnection - enter HttpConnection.open() DEBUG org.apache.commons.httpclient.HttpConnection - enter HttpConnection.closeSockedAndStreams() DEBUG org.apache.commons.httpclient.HttpConnection - enter
Is there still anything that blocks 2.0RC2 release?
Is there still anything that blocks 2.0RC2 release? Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is there still anything that blocks 2.0RC2 release?
Not that I know of. Mike On Tuesday, October 7, 2003, at 04:33 AM, Kalnichevski, Oleg wrote: Is there still anything that blocks 2.0RC2 release? Oleg - 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: Is there still anything that blocks 2.0RC2 release?
Mike, What is the outcome of this one? Is there anything we may need to do regarding automatic connection release in abnormal situations http://marc.theaimsgroup.com/?t=10644270561r=1w=2 Oleg -Original Message- From: Michael Becke [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 07, 2003 14:17 To: Commons HttpClient Project Subject: Re: Is there still anything that blocks 2.0RC2 release? Not that I know of. Mike On Tuesday, October 7, 2003, at 04:33 AM, Kalnichevski, Oleg wrote: Is there still anything that blocks 2.0RC2 release? Oleg - 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: delete cookies from HttpState
Yue, That can be done, of course. Feel free to file a feature request in the bugzilla. Oleg On Mon, 2003-10-06 at 19:43, Yue Luo wrote: Hi, I wonder if in the next release a method like deleteAllCookies() could be added to HttpState. I am developing a driver for a web benchmark and want to recycle HttpState instead of creating a new one. Thanks. Yue - 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: Is there still anything that blocks 2.0RC2 release?
Mike, Are there any reasons for NOT automatically releasing connection? I can't think of any. We should still require HttpMethod#releaseConnection() to be called explicitly regardless if there was an exception or not, but in those cases where we can be sure that the connection is not needed anymore, we should do it automatically. Oleg On Tue, 2003-10-07 at 17:41, Michael Becke wrote: Yes, a final decision still needs to be made on that one. Do you have any thoughts? Mike Kalnichevski, Oleg wrote: Mike, What is the outcome of this one? Is there anything we may need to do regarding automatic connection release in abnormal situations http://marc.theaimsgroup.com/?t=10644270561r=1w=2 Oleg -Original Message- From: Michael Becke [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 07, 2003 14:17 To: Commons HttpClient Project Subject: Re: Is there still anything that blocks 2.0RC2 release? Not that I know of. Mike On Tuesday, October 7, 2003, at 04:33 AM, Kalnichevski, Oleg wrote: Is there still anything that blocks 2.0RC2 release? Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is there still anything that blocks 2.0RC2 release?
Oleg, Generally speaking I agree. I wanted to look at it more carefully though to verify that a method that throws an exception has no case for holding on to the connection. If you cannot think of any reason, then that's good enough for me. Mike Oleg Kalnichevski wrote: Mike, Are there any reasons for NOT automatically releasing connection? I can't think of any. We should still require HttpMethod#releaseConnection() to be called explicitly regardless if there was an exception or not, but in those cases where we can be sure that the connection is not needed anymore, we should do it automatically. Oleg On Tue, 2003-10-07 at 17:41, Michael Becke wrote: Yes, a final decision still needs to be made on that one. Do you have any thoughts? Mike Kalnichevski, Oleg wrote: Mike, What is the outcome of this one? Is there anything we may need to do regarding automatic connection release in abnormal situations http://marc.theaimsgroup.com/?t=10644270561r=1w=2 Oleg -Original Message- From: Michael Becke [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 07, 2003 14:17 To: Commons HttpClient Project Subject: Re: Is there still anything that blocks 2.0RC2 release? Not that I know of. Mike On Tuesday, October 7, 2003, at 04:33 AM, Kalnichevski, Oleg wrote: Is there still anything that blocks 2.0RC2 release? Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is there still anything that blocks 2.0RC2 release?
Generally speaking I agree. I wanted to look at it more carefully though to verify that a method that throws an exception has no case for holding on to the connection. If you cannot think of any reason, then that's good enough for me. Mike, You should not put too much faith into it. You are the one who knows connection pooling best. If you need more time, take more time. Besides, I personally see no pressing need to include any changes of what so ever into 2.0 release. Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is there still anything that blocks 2.0RC2 release?
Oleg, Okay, I'll take a look at this when I get a chance. Let's go ahead and proceed with a rc2 without this change. If I can get to it in time we can include it, if not we won't. Mike Oleg Kalnichevski wrote: Generally speaking I agree. I wanted to look at it more carefully though to verify that a method that throws an exception has no case for holding on to the connection. If you cannot think of any reason, then that's good enough for me. Mike, You should not put too much faith into it. You are the one who knows connection pooling best. If you need more time, take more time. Besides, I personally see no pressing need to include any changes of what so ever into 2.0 release. Oleg - 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]
[VOTE] 2.0 RC2 release
I propose that we mark the latest code in CVS HTTPCLIENT_2_0_BRANCH as RC2 and proceed with a release. Please vote as follows: -- Vote: HttpClient 2.0 RC2 release [ ] +1 I am in favor of the release, and will help support it. [ ] +0 I am in favor of the release, but am unable to help support it. [ ] -0 I am not in favor of the release. [ ] -1 I am against this proposal (must include a reason). -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23663] - Connections are not release when a recoverable exception occurs.
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=23663. 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=23663 Connections are not release when a recoverable exception occurs. --- Additional Comments From [EMAIL PROTECTED] 2003-10-08 00:12 --- Created an attachment (id=8487) patch 1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23663] - Connections are not release when a recoverable exception occurs.
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=23663. 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=23663 Connections are not release when a recoverable exception occurs. --- Additional Comments From [EMAIL PROTECTED] 2003-10-08 00:13 --- This patch should take care of the problem. The connection should definitely be released in this case since it is closed. This patch should be applied before rc2 is tagged. Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
