Re: [VOTE] New committer: Sean Sullivan
+1 Welcome! --Jeff On Tue, Jun 04, 2002 at 02:39:02PM -0500, [EMAIL PROTECTED] wrote: I would like to nominate Sean Sullivan as a committer for the Jakarta Commons project. Sean has been active in providing patches and support the HttpClient project over the last several months and I think he would be a good addition to the community. Marc Saegesser -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] New committer: Sean Sullivan
I would like to nominate Sean Sullivan as a committer for the Jakarta Commons project. Sean has been active in providing patches and support the HttpClient project over the last several months and I think he would be a good addition to the community. +1. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: BETWIXT : Failing testcases..
From: Jon Scott Stevens [EMAIL PROTECTED] on 6/4/02 4:03 PM, Martin van den Bemt [EMAIL PROTECTED] wrote: Betwixt fails on the scarab tests.. On the betwixt site the scarab tests are not included though.. It is failing on the TestScarabSettings.java line 196 (about), it is the assertEquals(UI, gao.getChildOption()); I seem to suffer a bit with the same problems (it looks like it, that is), which I mentioned in an earlier mail.. Mvgr, Martin Yup. Jason is supposed to be fixing this...;-) Those test cases show that betwixt has some pretty serious bugs in it. It is actually failing before that test is run because betwixt is trying to call the a method on the wrong object... I'm working on this, should have it fixed shortly James _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/tags/core IncludeTag.java
werken 2002/06/05 00:00:58
Modified:jelly/src/java/org/apache/commons/jelly JellyContext.java
jelly/src/java/org/apache/commons/jelly/expression/jexl
JexlExpression.java
jelly/src/java/org/apache/commons/jelly/tags/core
IncludeTag.java
Log:
The core:include tag now can tag 2 additional attributes:
inhert=(true|false) which describes that the included
jellyscript inherits all variables from the one that
actually uses the include.
export=(true|false) which describes that the included
jellyscript exports all of its locally-set variables
to the one that actually uses the include.
Things seem to still work.
Revision ChangesPath
1.9 +60 -0
jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/JellyContext.java
Index: JellyContext.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/JellyContext.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- JellyContext.java 30 May 2002 16:47:17 - 1.8
+++ JellyContext.java 5 Jun 2002 07:00:58 - 1.9
@@ -97,6 +97,12 @@
/** The parent context */
private JellyContext parent;
+
+/** Do we inherit variables from parent context? */
+private boolean shouldInherit = false;
+
+/** Do we export our variables to parent context? */
+private boolean shouldExport = false;
/**
* The class loader to use for instantiating application objects.
@@ -148,6 +154,36 @@
return parent;
}
+public void setExport(boolean shouldExport) {
+this.shouldExport = shouldExport;
+}
+
+public boolean getExport() {
+return this.shouldExport;
+}
+
+public void setInherit(boolean shouldInherit) {
+this.shouldInherit = shouldInherit;
+}
+
+public boolean getInherit() {
+return this.shouldInherit;
+}
+
+public Object getScopedVariable(String name) {
+if ( getInherit() ) {
+return findVariable( name );
+}
+
+return getVariable( name );
+}
+
+public void setScopedVariable(String name, Object value) {
+if ( getExport() ) {
+getParent().setScopedVariable( name, value );
+}
+}
+
/**
* Finds the variable value of the given name in this context or in any other
parent context.
* If this context does not contain the variable, then its parent is used and
then its parent
@@ -167,11 +203,18 @@
/** @return the value of the given variable name */
public Object getVariable(String name) {
+if ( getInherit() ) {
+return getParent().findVariable( name );
+}
return variables.get(name);
}
/** Sets the value of the given variable name */
public void setVariable(String name, Object value) {
+if ( getExport() ) {
+getParent().setVariable( name, value );
+return;
+}
if (value == null) {
variables.remove(name);
}
@@ -328,6 +371,23 @@
URL newJellyContextURL = getJellyContextURL(url);
JellyContext newJellyContext = new JellyContext(this, newJellyContextURL);
+script.run(newJellyContext, output);
+}
+
+public void runScript(String uri, XMLOutput output,
+ boolean export, boolean inherit) throws Exception {
+URL url = getResource(uri);
+if (url == null) {
+throw new JellyException(Could not find Jelly script: + url);
+}
+Script script = compileScript(url);
+
+URL newJellyContextURL = getJellyContextURL(url);
+JellyContext newJellyContext = new JellyContext(this, newJellyContextURL);
+
+newJellyContext.setExport( export );
+newJellyContext.setInherit( inherit );
+
script.run(newJellyContext, output);
}
1.5 +84 -24
jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/expression/jexl/JexlExpression.java
Index: JexlExpression.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/expression/jexl/JexlExpression.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- JexlExpression.java 17 May 2002 15:18:14 - 1.4
+++ JexlExpression.java 5 Jun 2002 07:00:58 - 1.5
@@ -1,7 +1,7 @@
/*
- * $Header:
cvs commit: jakarta-commons-sandbox/betwixt/src/java/org/apache/commons/betwixt/expression MethodUpdater.java
jstrachan2002/06/05 00:57:07
Modified:betwixt/src/test/org/apache/commons/betwixt/scarab
GlobalAttributeOption.java GlobalAttribute.java
TestScarabSettings.java
betwixt project.properties build.xml
betwixt/src/java/org/apache/commons/betwixt/io
BeanCreateRule.java
betwixt/src/java/org/apache/commons/betwixt/expression
MethodUpdater.java
Log:
Fixed a bug with betwixt that was causing the wrong context to be used when
attempting to set properties.
The bug was actually due to multiple similar rules being fired at the same time; the
second copy of the rule would think it was nested inside the former, causing the wrong
context to be used to set properties.
Have we explicitly ignore multiple rules which removes this problem (as well as
avoiding redundant processing).
betwixt now passes all unit test cases.
Revision ChangesPath
1.4 +5 -1
jakarta-commons-sandbox/betwixt/src/test/org/apache/commons/betwixt/scarab/GlobalAttributeOption.java
Index: GlobalAttributeOption.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/betwixt/src/test/org/apache/commons/betwixt/scarab/GlobalAttributeOption.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- GlobalAttributeOption.java1 Jun 2002 18:46:59 - 1.3
+++ GlobalAttributeOption.java5 Jun 2002 07:57:07 - 1.4
@@ -73,7 +73,7 @@
* pcodeGlobalAttributeOption/code is a sample bean for use by the test
cases./p
*
* @author a href=mailto:[EMAIL PROTECTED];Jason van Zyl/a
- * @version $Id: GlobalAttributeOption.java,v 1.3 2002/06/01 18:46:59 jon Exp $
+ * @version $Id: GlobalAttributeOption.java,v 1.4 2002/06/05 07:57:07 jstrachan Exp
$
*/
public class GlobalAttributeOption implements Serializable
{
@@ -86,6 +86,10 @@
*/
public GlobalAttributeOption()
{
+}
+
+public String toString() {
+return super.toString() + [name= + name + ;childOption= + childOption +
];
}
public void setName(String name)
1.4 +5 -1
jakarta-commons-sandbox/betwixt/src/test/org/apache/commons/betwixt/scarab/GlobalAttribute.java
Index: GlobalAttribute.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/betwixt/src/test/org/apache/commons/betwixt/scarab/GlobalAttribute.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- GlobalAttribute.java 1 Jun 2002 18:46:59 - 1.3
+++ GlobalAttribute.java 5 Jun 2002 07:57:07 - 1.4
@@ -72,7 +72,7 @@
* pcodeGlobalAttribute/code is a sample bean for use by the test cases./p
*
* @author a href=mailto:[EMAIL PROTECTED];Jason van Zyl/a
- * @version $Id: GlobalAttribute.java,v 1.3 2002/06/01 18:46:59 jon Exp $
+ * @version $Id: GlobalAttribute.java,v 1.4 2002/06/05 07:57:07 jstrachan Exp $
*/
public class GlobalAttribute implements Serializable
{
@@ -92,6 +92,10 @@
public GlobalAttribute()
{
globalAttributeOptions = new ArrayList();
+}
+
+public String toString() {
+return super.toString() + [options= + globalAttributeOptions + ];
}
public void addGlobalAttributeOption(GlobalAttributeOption
globalAttributeOption)
1.7 +6 -2
jakarta-commons-sandbox/betwixt/src/test/org/apache/commons/betwixt/scarab/TestScarabSettings.java
Index: TestScarabSettings.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/betwixt/src/test/org/apache/commons/betwixt/scarab/TestScarabSettings.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- TestScarabSettings.java 1 Jun 2002 19:08:56 - 1.6
+++ TestScarabSettings.java 5 Jun 2002 07:57:07 - 1.7
@@ -81,7 +81,7 @@
* Test harness which round trips a Scarab's settings xml file
*
* @author a href=mailto:[EMAIL PROTECTED];Jason van Zyl/a
- * @version $Id: TestScarabSettings.java,v 1.6 2002/06/01 19:08:56 jon Exp $
+ * @version $Id: TestScarabSettings.java,v 1.7 2002/06/05 07:57:07 jstrachan Exp $
*/
public class TestScarabSettings extends AbstractTestCase
{
@@ -120,7 +120,6 @@
ScarabSettings ss = (ScarabSettings) reader.parse(
new
FileInputStream(src/test/org/apache/commons/betwixt/scarab/scarab-settings.xml));
-/*
// now lets output it to a buffer
StringWriter buffer = new StringWriter();
write(ss, buffer);
@@ -133,6 +132,7 @@
System.out.println(text);
+/*
cvs commit: jakarta-commons-sandbox/betwixt .cvsignore
jstrachan2002/06/05 00:58:39 Modified:betwixt .cvsignore Log: added maven log to list of stuff for cvs to ignore Revision ChangesPath 1.4 +1 -0 jakarta-commons-sandbox/betwixt/.cvsignore Index: .cvsignore === RCS file: /home/cvs/jakarta-commons-sandbox/betwixt/.cvsignore,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- .cvsignore28 May 2002 13:38:26 - 1.3 +++ .cvsignore5 Jun 2002 07:58:39 - 1.4 @@ -5,3 +5,4 @@ .project foo.txt +maven.log -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/jrcs project.xml
jvanzyl 2002/06/05 04:01:25 Modified:jrcs project.xml Log: More updates to the POM. Revision ChangesPath 1.3 +6 -2 jakarta-commons-sandbox/jrcs/project.xml Index: project.xml === RCS file: /home/cvs/jakarta-commons-sandbox/jrcs/project.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- project.xml 5 Jun 2002 10:41:54 - 1.2 +++ project.xml 5 Jun 2002 11:01:25 - 1.3 @@ -19,11 +19,15 @@ /description urlhttp://jakarta.apache.org/commons/jrcs/url - cvsWebUrlhttp://cvs.apache.org/viewcvs/jakarta/jakarta-commons-sandbox/jrcs//cvsWebUrl issueTrackingUrlhttp://nagoya.apache.org:8080/scarab/servlet/scarab//issueTrackingUrl siteAddressjakarta.apache.org/siteAddress siteDirectory/www/jakarta.apache.org/turbine/maven//siteDirectory - distributionDirectory/www/jakarta.apache.org/builds/jakarta-turbine-maven//distributionDirectory + distributionDirectory/www/jakarta.apache.org/builds/commons/jrcs/distributionDirectory + + repository + connectionscm:cvs:pserver:[EMAIL PROTECTED]:/home/cvspublic:jakarta-commons-sandbox/connection +urlhttp://cvs.apache.org/viewcvs/jakarta-commons-sandbox/jrcs/url + /repository mailingLists mailingList -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/jrcs project.xml
jvanzyl 2002/06/05 04:03:29 Modified:jrcs project.xml Log: Once again. Revision ChangesPath 1.4 +1 -3 jakarta-commons-sandbox/jrcs/project.xml Index: project.xml === RCS file: /home/cvs/jakarta-commons-sandbox/jrcs/project.xml,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- project.xml 5 Jun 2002 11:01:25 - 1.3 +++ project.xml 5 Jun 2002 11:03:29 - 1.4 @@ -61,10 +61,8 @@ dependencies dependency - namejakarta-oro/name - typerequired/type + idjakarta-oro/id version1.3/version - jaroro.jar/jar urlhttp://jakarta.apache.org/oro//url /dependency -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/configuration project.xml
jvanzyl 2002/06/05 04:04:31 Modified:configuration project.xml Log: Updating POM for the b4 release of Maven. Revision ChangesPath 1.6 +10 -15jakarta-commons-sandbox/configuration/project.xml Index: project.xml === RCS file: /home/cvs/jakarta-commons-sandbox/configuration/project.xml,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- project.xml 11 May 2002 14:47:11 - 1.5 +++ project.xml 5 Jun 2002 11:04:31 - 1.6 @@ -1,7 +1,7 @@ ?xml version=1.0? project - version2/version + pomVersion3/pomVersion namecommons-configuration/name idcommons-configuration/id currentVersion1.0-dev/currentVersion @@ -20,13 +20,16 @@ /description urlhttp://jakarta.apache.org/commons/sandbox/configuration//url - cvsWebUrlhttp://cvs.apache.org/viewcvs/jakarta-commons-sandbox/configuration//cvsWebUrl - cvsModulejakarta-commons-sandbox/configuration/cvsModule issueTrackingUrlhttp://nagoya.apache.org/scarab/servlet/scarab//issueTrackingUrl siteAddressjakarta.apache.org/siteAddress siteDirectory/www/jakarta.apache.org/commons/sandbox/configuration//siteDirectory distributionDirectory/www/jakarta.apache.org/builds/jakarta-commons-sandbox//distributionDirectory + repository + connectionscm:cvs:pserver:[EMAIL PROTECTED]:/home/cvspublic:jakarta-commons-sandbox/connection +urlhttp://cvs.apache.org/viewcvs/jakarta-commons-sandbox/configuration//url + /repository + branches /branches @@ -68,31 +71,23 @@ dependency namecommons-collections/name - typerequired/type - version1.0/version - jarcommons-collections.jar/jar + version2.0/version /dependency dependency namecommons-logging/name - typerequired/type version1.0/version - jarcommons-logging-1.0.jar/jar /dependency /dependencies build nagEmailAddress[EMAIL PROTECTED]/nagEmailAddress -sourceDirectories - sourceDirectorysrc/java/sourceDirectory -/sourceDirectories - + +sourceDirectorysrc/java/sourceDirectory unitTestSourceDirectorysrc/test/unitTestSourceDirectory integrationUnitTestSourceDirectory/ - -aspectSourceDirectories -/aspectSourceDirectories +aspectSourceDirectories/ !-- Unit test classes -- unitTestPatterns -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Messenger DTDs, XSDs...?
From: Spam Cut [EMAIL PROTECTED]
Hi,
I was wondering if someone could point me to
documentation for the messenger and subscriptions
xml config files. There seem to be many attributes for
the subscriptions xml config file that aren't
described in the overview. Is there any documentation
for these in some form (DTD, XSD, Text File, PDF File,
etc...)?
Unfortunately not yet.
Messenger is using the Digester which means that the schema can be soft
coded. This allows you to plugin your own implementations of things (like
your own SessionFactory in the messenger.xml file or your own
MessageListener or MDO implementaiton in the subscription.xml file) and then
configure those within the same document.
e.g.
public class MyMDO extends MessengerMDO {
public void setFoo(String foo);
public void setBar(int bar);
}
then in subscription.xml I could do...
subscriptions
subscription connection=myQueueConnection subject=in.queue
listener className=MyMDO foo=valueOfFoo bar=1234/
/subscription
/subscriptions
So that the 'foo' and 'bar' attributes above come really from the underlying
MessageListener / MDO.
Though I totally agree with you that the common elements/attributes should
be properly documented. I've added this to the todo list so it'll get done
one day (hopefully soon). As usual, any contributions are greatfully
received ;-)
James
_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] move Betwixt into commons proper (was Re: Betwixt MethodUpdaters)
+1 from a non-participant... On 6/5/02 6:49 AM, James Strachan [EMAIL PROTECTED] wrote: - Original Message - From: Jason van Zyl [EMAIL PROTECTED] It now looks like the bugs have been squashed so how about we propose to move Betwixt up to the commons proper and do a release? Sounds good with me. Lets do it in 2 stages, move to commons proper first, then leave it a couple of days to check that noone can find any more bugs, then lets call another vote to release it. So here's the first vote, to move betwixt to commons proper. Already there's 4 developers and several projects using betwixt so I think it passes all the conditions. http://jakarta.apache.org/commons/sandbox/betwixt/developer-list.html I'm +1 James _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Geir Magnusson Jr. Research Development, Adeptra Inc. [EMAIL PROTECTED] +1-203-247-1713 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] move Betwixt into commons proper (was Re: Betwixt MethodUpdaters)
+1 on moving Betwixt into commons proper. On Wed, 5 Jun 2002, James Strachan wrote: - Original Message - From: Jason van Zyl [EMAIL PROTECTED] It now looks like the bugs have been squashed so how about we propose to move Betwixt up to the commons proper and do a release? Sounds good with me. Lets do it in 2 stages, move to commons proper first, then leave it a couple of days to check that noone can find any more bugs, then lets call another vote to release it. So here's the first vote, to move betwixt to commons proper. Already there's 4 developers and several projects using betwixt so I think it passes all the conditions. http://jakarta.apache.org/commons/sandbox/betwixt/developer-list.html I'm +1 James _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] Re: Betwixt MethodUpdaters, James Strachan Re: Betwixt MethodUpdaters, Jason van Zyl [VOTE] move Betwixt into commons proper (was Re: Betwixt MethodUpdaters), James Strachan Re: [VOTE] move Betwixt into commons proper (was Re: Betwixt MethodUpdaters), Geir Magnusson Jr. Re: [VOTE] move Betwixt into commons proper (was Re: Betwixt MethodUpdaters), Michael A. Smith Re: [VOTE] move Betwixt into commons proper (was Re: Betwixt MethodUpdaters), Jon Scott Stevens RE: [VOTE] move Betwixt into commons proper (was Re: Betwixt MethodUpdaters), Vincent Massol Re: [VOTE] move Betwixt into commons proper (was Re: Betwixt MethodUpdaters), Craig R. McClanahan Re: [VOTE] move Betwixt into commons proper (was Re: Betwixt MethodUpdaters), robert burrell donkin -- Chronological -- -- Thread -- [EMAIL PROTECTED]"> Reply via email to [VOTE] move Betwixt into commons proper (was Re: Betwixt MethodUpdaters), James Strachan Re: [VOTE] move Betwixt into commons proper (was Re: Betwixt MethodUpdaters), Geir Magnusson Jr. Re: [VOTE] move Betwixt into commons proper (was Re: Betwixt MethodUpdaters), Michael A. Smith Re: [VOTE] move Betwixt into commons proper (was Re: Betwixt MethodUpdaters), Jon Scott Stevens RE: [VOTE] move Betwixt into commons proper (was Re: Betwixt MethodUpdaters), Vincent Massol Re: [VOTE] move Betwixt into commons proper (was Re: Betwixt MethodUpdaters), Craig R. McClanahan Re: [VOTE] move Betwixt into commons proper (was Re: Betwixt MethodUpdaters), robert burrell donkin -- Chronological -- -- Thread -- [EMAIL PROTECTED]"> Reply via email to Re: [VOTE] move Betwixt into commons proper (was Re: Betwixt MethodUpdaters), Geir Magnusson Jr. Re: [VOTE] move Betwixt into commons proper (was Re: Betwixt MethodUpdaters), Michael A. Smith Re: [VOTE] move Betwixt into commons proper (was Re: Betwixt MethodUpdaters), Jon Scott Stevens Re: [VOTE] move Betwixt into commons proper (was Re: Betwixt MethodUpdaters), dion Re: [VOTE] move Betwixt into commons proper (was Re: Betwixt MethodUpdaters), Ivelin Ivanov Re: [VOTE] move Betwixt into commons proper (was Re: Betwixt MethodUpdaters), James Strachan [Betwixt] what's the plan?, robert burrell donkin Re: [Betwixt] what's the plan?, James Strachan Re: [Betwixt] what's the plan?, Martin van den Bemt Re: [Betwixt] what's the plan?, James Strachan Re: [Betwixt] what's the plan?, robert burrell donkin Re: [VOTE] move Betwixt into commons proper (was Re: Betwixt MethodUpdaters), Ivelin Ivanov -- Chronological -- -- Thread -- [EMAIL PROTECTED]"> Reply via email to Re: [VOTE] move Betwixt into commons proper (was Re: Betwixt MethodUpdaters) Geir Magnusson Jr. Re: [VOTE] move Betwixt into commons proper (was Re: Betwixt MethodUpdaters) Michael A. Smith Re: [VOTE] move Betwixt into commons proper (was Re: Betwixt MethodUpdaters) Jon Scott Stevens Re: [VOTE] move Betwixt into commons proper (was Re: Betwixt MethodUpdaters) dion Re: [VOTE] move Betwixt into commons proper (was Re: Betwixt MethodUpdaters) James Strachan [Betwixt] what's the plan? robert burrell donkin Re: [Betwixt] what's the plan? James Strachan Re: [Betwixt] what's the plan? Martin van den Bemt Re: [Betwixt]
[PATCH] Betwixt. setting namemapper for attributes.
Hi James,
Finally found the problem. The nameMapper is also used for attributes..
so if I have an xml file like
PHYSICAL_SCHEMA autocreate=yes/
You end up with trouble ;).. Since autocreate will be mapped to the
attribute AUTOCREATE, which doesn't exist.
So I added an extra nameMapper setter (setAttributeNameMapper), which
you can call if you want to use a different nameMapper for attributes.
I have chosen not to make a specific attributenamemapper Interface /
abstract class for simplicity and easier reuse of code..
The default is to use the normal NameMapper, so no backward
compatibility issues on this.
If you don't mind, I will make my testcases a little bit later.
(hopefully tonight, or else on sunday, since I am off sailing for a
couple of days..)
Hope you wil apply the patch however, ran all tests and it doesn't break
backward compatibility.
Hope it is usefull for you too ;)
Mvgr,
Martin
Index: XMLIntrospector.java
===
RCS file: /home/cvspublic/jakarta-commons-sandbox/betwixt/src/java/org/apache/commons/betwixt/XMLIntrospector.java,v
retrieving revision 1.28
diff -u -r1.28 XMLIntrospector.java
--- XMLIntrospector.java 3 Jun 2002 20:51:08 - 1.28
+++ XMLIntrospector.java 5 Jun 2002 15:03:48 -
@@ -93,6 +93,7 @@
* Later requests for the same class will return the cached value./p
*
* @author a href=mailto:[EMAIL PROTECTED];James Strachan/a
+ * @author a href-mailto:[EMAIL PROTECTED];Martin van den Bemt/a
* @version $Id: XMLIntrospector.java,v 1.28 2002/06/03 20:51:08 jon Exp $
*/
public class XMLIntrospector {
@@ -123,6 +124,12 @@
/** The strategy used to convert bean type names into element names */
private NameMapper nameMapper;
+/**
+ * The strategy used to convert bean type names into attribute names
+ * It will default to the normal nameMapper.
+ */
+private NameMapper attributeNameMapper;
+
/** Base constructor */
public XMLIntrospector() {
}
@@ -329,13 +336,32 @@
}
return nameMapper;
}
+/**
+ * @return the strategy used to convert bean type names into attribute
+ * names. If no attributeNamemapper is known, it will default to the NameMapper
+ */
+public NameMapper getAttributeNameMapper() {
+if (attributeNameMapper == null) {
+attributeNameMapper = getNameMapper();
+}
+return attributeNameMapper;
+}
/**
* Sets the strategy used to convert bean type names into element names
+ * @param nameMapper
*/
public void setNameMapper(NameMapper nameMapper) {
this.nameMapper = nameMapper;
}
+
+/**
+ * Sets the strategy used to convert bean type names into attribute names
+ * @param nameMapper
+ */
+public void setAttributeNameMapper(NameMapper nameMapper) {
+this.attributeNameMapper = nameMapper;
+}
@@ -508,7 +534,7 @@
elements.add( nodeDescriptor );
}
-nodeDescriptor.setLocalName( getNameMapper().mapTypeToElementName( propertyDescriptor.getName() ) );
+nodeDescriptor.setLocalName( getAttributeNameMapper().mapTypeToElementName( propertyDescriptor.getName() ) );
nodeDescriptor.setPropertyName( propertyDescriptor.getName() );
nodeDescriptor.setPropertyType( type );
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [HttpClient] Post parameters
Thanks for the reply, Marc. I think that, while the official specification is important, it is more important to stick with the defacto spec (or at least offer an option to use defacto spec behavior). Given that neither Netscape, Mozilla, nor IE follow the spec (that is, passing params to the redirected URL), and because most sites specifically state that they support one of these browsers and no others, there will be a lot of web sites out there that depend on that behavior. For example, the application that I am trying to monitor uses the redirect to say I'm done processing, now view this other page, rather than to say You really should have gone here in the first place. I think a lot of applications out there were built that way (especially JSP applications) because it worked on IE and Netscape. At this point in the game, I would be very surprised if IE and Netscape ever did implement the spec correctly because they would be keeping their customers from using many sites and hence, would lose market share. Also, if anything would implement the spec correctly, Mozilla would, and the app I'm monitoring works fine with Mozilla. I can try my hand at internally creating a GetMethod on redirect, but I don't have a lot of confidence that I will consider everything that probably should be considered. I support your idea of creating a new GetMethod for redirects. It's a much more O-O way to go and it could help clean up the HttpMethodBase#execute method too. I would probably also argue that when spec-compliant behavior is needed, creating a new PostMethod for the redirect would be better too. The simplification and improved maintainability of the code would more than offset the minor overhead from creation of another instance. Even if, in some probably rare case, it becomes a performance problem then an internal pool of PostMethods can be used. Thanks, let me know how to proceed or whether I should wait for someone else to change it. Jonathan --- [EMAIL PROTECTED] wrote: [NOTE: I've been away from the HttpClient stuff for a while due to other priorities with the DDJ and other duties (like trying to keep three small airplanes flying when all they want to do is break down). I'm slowly pulling myself back from the abyss and I hope to become more active in this stuff again soon]. The response to a 302 redirect of a POST method is *SUPPOSED* to contain all the original data (query string, request body). The 302 redirect tells the client that requested resource is now available at a different (possibly temporary) URI. The client should therefore resend the original request to the new URI provided in the 302 responses Location header. The client is also required to ASK THE USER FOR PERMISSION before redirecting a POST request. This is because the user may not want to send the data to the new URI (it might be to a different host, use different security, etc.). Now, having said all that, most browsers *DO THIS WRONG*. When they receive a 302 response for *any* method they always send a GET to the new URI, instead of resending the original request. This is spelled out quitely clearly in RFC 2616 (section 10.3.3). It has been this way from the begining; the browser developers just got it wrong and haven't fixed it yet. What is truly horrible, though, is that there are some server applications out there that *require* this broken client behavior. The Yahoo! login process is my favorite whipping boy for this, but there are others. The architecture of HttpClient/HttpMultiClient makes it very difficult to implement the broken behavior because it can't change a POST into a GET. It is passed a class of type GetMethod or PostMethod (or UrlGetMethod or UrlPostMethod) and it can't change the type of the class it got. The best idea I've had so far is to create a new GetMethod class internally, send that request and then copy the response data from the temporary GET method back into the original POST method got in the first place. If anyone has any better ideas I'd love to hear them. Marc Saegesser -Original Message- From: Jonathan Carlson [mailto:[EMAIL PROTECTED]] Sent: Monday, June 03, 2002 4:17 PM To: [EMAIL PROTECTED] Subject: [HttpClient] Post parameters After experienced undesired behavior and looking at the code it appears that POST parameters are also being passed to the redirected page. I've tried fixing this with a little tweak, but I am realizing that it may be more involved than I had originally thought. Has anyone else experienced this? I'm using the 5/28 nightly build. Jonathan = Jonathan Carlson [EMAIL PROTECTED] Minneapolis, Minnesota __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL
[JXPATH] best approch for customization
Hi, all, I have a question regarding the best approach for customizing JXPath. I looked at providing a NodePointer implementation but was not convinced this was the right course and also deterred by the large interface. I like what JXPath provides out-of-the-box with regards to JavaBean support, but instead of allowing clients unvetted access to the whole of my API I would prefer to restrict access. The initial idea was to provide a new JXPathIntospector implementation that hands off to a 'GuardHandler' if the context object implements a well-known tag interface, otherwise it would follow the normal JavaBean resolution. The 'GuardHandler' (implemtation of DynamicPropertyHandler) guards against using any methods not defined for the given bean. I then realised the JXPathIntrospector is not configurable which lead me to the NodePointer. I'm now wondering the best approach. Any guidance would be much appreciated. cheers, steve. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] Betwixt. setting namemapper for attributes.
Hmm.. hold back on the patch ;))..
Found another issue.. It is also using the attributenamemapper for
subelemenents.. Fixing that now..
Mvgr,
Martin
On Wed, 2002-06-05 at 17:18, Martin van den Bemt wrote:
Hi James,
Finally found the problem. The nameMapper is also used for attributes..
so if I have an xml file like
PHYSICAL_SCHEMA autocreate=yes/
You end up with trouble ;).. Since autocreate will be mapped to the
attribute AUTOCREATE, which doesn't exist.
So I added an extra nameMapper setter (setAttributeNameMapper), which
you can call if you want to use a different nameMapper for attributes.
I have chosen not to make a specific attributenamemapper Interface /
abstract class for simplicity and easier reuse of code..
The default is to use the normal NameMapper, so no backward
compatibility issues on this.
If you don't mind, I will make my testcases a little bit later.
(hopefully tonight, or else on sunday, since I am off sailing for a
couple of days..)
Hope you wil apply the patch however, ran all tests and it doesn't break
backward compatibility.
Hope it is usefull for you too ;)
Mvgr,
Martin
Index: XMLIntrospector.java
===
RCS file:
/home/cvspublic/jakarta-commons-sandbox/betwixt/src/java/org/apache/commons/betwixt/XMLIntrospector.java,v
retrieving revision 1.28
diff -u -r1.28 XMLIntrospector.java
--- XMLIntrospector.java 3 Jun 2002 20:51:08 - 1.28
+++ XMLIntrospector.java 5 Jun 2002 15:03:48 -
@@ -93,6 +93,7 @@
* Later requests for the same class will return the cached value./p
*
* @author a href=mailto:[EMAIL PROTECTED];James Strachan/a
+ * @author a href-mailto:[EMAIL PROTECTED];Martin van den Bemt/a
* @version $Id: XMLIntrospector.java,v 1.28 2002/06/03 20:51:08 jon Exp $
*/
public class XMLIntrospector {
@@ -123,6 +124,12 @@
/** The strategy used to convert bean type names into element names */
private NameMapper nameMapper;
+/**
+ * The strategy used to convert bean type names into attribute names
+ * It will default to the normal nameMapper.
+ */
+private NameMapper attributeNameMapper;
+
/** Base constructor */
public XMLIntrospector() {
}
@@ -329,13 +336,32 @@
}
return nameMapper;
}
+/**
+ * @return the strategy used to convert bean type names into attribute
+ * names. If no attributeNamemapper is known, it will default to the NameMapper
+ */
+public NameMapper getAttributeNameMapper() {
+if (attributeNameMapper == null) {
+attributeNameMapper = getNameMapper();
+}
+return attributeNameMapper;
+}
/**
* Sets the strategy used to convert bean type names into element names
+ * @param nameMapper
*/
public void setNameMapper(NameMapper nameMapper) {
this.nameMapper = nameMapper;
}
+
+/**
+ * Sets the strategy used to convert bean type names into attribute names
+ * @param nameMapper
+ */
+public void setAttributeNameMapper(NameMapper nameMapper) {
+this.attributeNameMapper = nameMapper;
+}
@@ -508,7 +534,7 @@
elements.add( nodeDescriptor );
}
-nodeDescriptor.setLocalName( getNameMapper().mapTypeToElementName(
propertyDescriptor.getName() ) );
+nodeDescriptor.setLocalName( getAttributeNameMapper().mapTypeToElementName(
propertyDescriptor.getName() ) );
nodeDescriptor.setPropertyName( propertyDescriptor.getName() );
nodeDescriptor.setPropertyType( type );
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] Betwixt. setting namemapper for attributes.
How about if the XMLIntrospector had an 'elementNameMapper' and an
'attributeNameMapper' properties (both of type NameMapper) then you could
use upper case element names and lower case attribute names, but still keep
the same implementations of NameMapper? i.e. then it allows you to
configure each mechanism seperately. We should probably change the method
name of NameMapper to something a little more suitable, like
convertToXmlName()?
James
- Original Message -
From: Martin van den Bemt [EMAIL PROTECTED]
To: Jakarta Commons Developers List [EMAIL PROTECTED]
Sent: Wednesday, June 05, 2002 4:50 PM
Subject: Re: [PATCH] Betwixt. setting namemapper for attributes.
Hmm.. hold back on the patch ;))..
Found another issue.. It is also using the attributenamemapper for
subelemenents.. Fixing that now..
Mvgr,
Martin
On Wed, 2002-06-05 at 17:18, Martin van den Bemt wrote:
Hi James,
Finally found the problem. The nameMapper is also used for attributes..
so if I have an xml file like
PHYSICAL_SCHEMA autocreate=yes/
You end up with trouble ;).. Since autocreate will be mapped to the
attribute AUTOCREATE, which doesn't exist.
So I added an extra nameMapper setter (setAttributeNameMapper), which
you can call if you want to use a different nameMapper for attributes.
I have chosen not to make a specific attributenamemapper Interface /
abstract class for simplicity and easier reuse of code..
The default is to use the normal NameMapper, so no backward
compatibility issues on this.
If you don't mind, I will make my testcases a little bit later.
(hopefully tonight, or else on sunday, since I am off sailing for a
couple of days..)
Hope you wil apply the patch however, ran all tests and it doesn't break
backward compatibility.
Hope it is usefull for you too ;)
Mvgr,
Martin
Index: XMLIntrospector.java
===
RCS file:
/home/cvspublic/jakarta-commons-sandbox/betwixt/src/java/org/apache/commons/
betwixt/XMLIntrospector.java,v
retrieving revision 1.28
diff -u -r1.28 XMLIntrospector.java
--- XMLIntrospector.java 3 Jun 2002 20:51:08 - 1.28
+++ XMLIntrospector.java 5 Jun 2002 15:03:48 -
@@ -93,6 +93,7 @@
* Later requests for the same class will return the cached value./p
*
* @author a href=mailto:[EMAIL PROTECTED];James Strachan/a
+ * @author a href-mailto:[EMAIL PROTECTED];Martin van den Bemt/a
* @version $Id: XMLIntrospector.java,v 1.28 2002/06/03 20:51:08 jon
Exp $
*/
public class XMLIntrospector {
@@ -123,6 +124,12 @@
/** The strategy used to convert bean type names into element names
*/
private NameMapper nameMapper;
+/**
+ * The strategy used to convert bean type names into attribute
names
+ * It will default to the normal nameMapper.
+ */
+private NameMapper attributeNameMapper;
+
/** Base constructor */
public XMLIntrospector() {
}
@@ -329,13 +336,32 @@
}
return nameMapper;
}
+/**
+ * @return the strategy used to convert bean type names into
attribute
+ * names. If no attributeNamemapper is known, it will default to
the NameMapper
+ */
+public NameMapper getAttributeNameMapper() {
+if (attributeNameMapper == null) {
+attributeNameMapper = getNameMapper();
+}
+return attributeNameMapper;
+}
/**
* Sets the strategy used to convert bean type names into element
names
+ * @param nameMapper
*/
public void setNameMapper(NameMapper nameMapper) {
this.nameMapper = nameMapper;
}
+
+/**
+ * Sets the strategy used to convert bean type names into attribute
names
+ * @param nameMapper
+ */
+public void setAttributeNameMapper(NameMapper nameMapper) {
+this.attributeNameMapper = nameMapper;
+}
@@ -508,7 +534,7 @@
elements.add( nodeDescriptor );
}
-nodeDescriptor.setLocalName(
getNameMapper().mapTypeToElementName( propertyDescriptor.getName() ) );
+nodeDescriptor.setLocalName(
getAttributeNameMapper().mapTypeToElementName(
propertyDescriptor.getName() ) );
nodeDescriptor.setPropertyName( propertyDescriptor.getName() );
nodeDescriptor.setPropertyType( type );
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] Betwixt. setting namemapper for attributes.
If I am not mistaking the only change that is need then is to change the
current setNameMapper(..) to setElementNameMapper(..).
Since the attributeNameMapper is already a NameMapper type ;)
The suggestion was merely a mind spin, that it maybe better to use an
AttributeNameMapper type, so it is more clear. That mind spin came from
the fact that I thought that attributes were always read, not caring
about naming rules.. Since the setAttributeNameMapper is pretty clear, I
don't think we can leave it simple.
I am using the HyphenatedNameMapper for my elements
and the DecapitalizeNameMapper for my attributes ;)
My renewed patch will be sent tonight (seems like it is working, but
didn't get to parse the complete xml file yet).
BTW I am now manually testing the thing I have the deadline on, which
makes life a little bit less stressfull ;)
Mvgr,
Martin
On Wed, 2002-06-05 at 17:53, James Strachan wrote:
How about if the XMLIntrospector had an 'elementNameMapper' and an
'attributeNameMapper' properties (both of type NameMapper) then you could
use upper case element names and lower case attribute names, but still keep
the same implementations of NameMapper? i.e. then it allows you to
configure each mechanism seperately. We should probably change the method
name of NameMapper to something a little more suitable, like
convertToXmlName()?
James
- Original Message -
From: Martin van den Bemt [EMAIL PROTECTED]
To: Jakarta Commons Developers List [EMAIL PROTECTED]
Sent: Wednesday, June 05, 2002 4:50 PM
Subject: Re: [PATCH] Betwixt. setting namemapper for attributes.
Hmm.. hold back on the patch ;))..
Found another issue.. It is also using the attributenamemapper for
subelemenents.. Fixing that now..
Mvgr,
Martin
On Wed, 2002-06-05 at 17:18, Martin van den Bemt wrote:
Hi James,
Finally found the problem. The nameMapper is also used for attributes..
so if I have an xml file like
PHYSICAL_SCHEMA autocreate=yes/
You end up with trouble ;).. Since autocreate will be mapped to the
attribute AUTOCREATE, which doesn't exist.
So I added an extra nameMapper setter (setAttributeNameMapper), which
you can call if you want to use a different nameMapper for attributes.
I have chosen not to make a specific attributenamemapper Interface /
abstract class for simplicity and easier reuse of code..
The default is to use the normal NameMapper, so no backward
compatibility issues on this.
If you don't mind, I will make my testcases a little bit later.
(hopefully tonight, or else on sunday, since I am off sailing for a
couple of days..)
Hope you wil apply the patch however, ran all tests and it doesn't break
backward compatibility.
Hope it is usefull for you too ;)
Mvgr,
Martin
Index: XMLIntrospector.java
===
RCS file:
/home/cvspublic/jakarta-commons-sandbox/betwixt/src/java/org/apache/commons/
betwixt/XMLIntrospector.java,v
retrieving revision 1.28
diff -u -r1.28 XMLIntrospector.java
--- XMLIntrospector.java 3 Jun 2002 20:51:08 - 1.28
+++ XMLIntrospector.java 5 Jun 2002 15:03:48 -
@@ -93,6 +93,7 @@
* Later requests for the same class will return the cached value./p
*
* @author a href=mailto:[EMAIL PROTECTED];James Strachan/a
+ * @author a href-mailto:[EMAIL PROTECTED];Martin van den Bemt/a
* @version $Id: XMLIntrospector.java,v 1.28 2002/06/03 20:51:08 jon
Exp $
*/
public class XMLIntrospector {
@@ -123,6 +124,12 @@
/** The strategy used to convert bean type names into element names
*/
private NameMapper nameMapper;
+/**
+ * The strategy used to convert bean type names into attribute
names
+ * It will default to the normal nameMapper.
+ */
+private NameMapper attributeNameMapper;
+
/** Base constructor */
public XMLIntrospector() {
}
@@ -329,13 +336,32 @@
}
return nameMapper;
}
+/**
+ * @return the strategy used to convert bean type names into
attribute
+ * names. If no attributeNamemapper is known, it will default to
the NameMapper
+ */
+public NameMapper getAttributeNameMapper() {
+if (attributeNameMapper == null) {
+attributeNameMapper = getNameMapper();
+}
+return attributeNameMapper;
+}
/**
* Sets the strategy used to convert bean type names into element
names
+ * @param nameMapper
*/
public void setNameMapper(NameMapper nameMapper) {
this.nameMapper = nameMapper;
}
+
+/**
+ * Sets the strategy used to convert bean type names into attribute
names
+ * @param nameMapper
+ */
+public void setAttributeNameMapper(NameMapper nameMapper) {
+
Re: [PATCH] Betwixt. setting namemapper for attributes.
From: Martin van den Bemt [EMAIL PROTECTED] If I am not mistaking the only change that is need then is to change the current setNameMapper(..) to setElementNameMapper(..). Since the attributeNameMapper is already a NameMapper type ;) Agreed. The suggestion was merely a mind spin, that it maybe better to use an AttributeNameMapper type, so it is more clear. That mind spin came from the fact that I thought that attributes were always read, not caring about naming rules.. Since the setAttributeNameMapper is pretty clear, I don't think we can leave it simple. I am using the HyphenatedNameMapper for my elements and the DecapitalizeNameMapper for my attributes ;) Yes, both of type NameMapper. So all I meant was let XMLIntrospector have 2 properties, of type NameMapper, one for elements and one for attributes. My renewed patch will be sent tonight (seems like it is working, but didn't get to parse the complete xml file yet). BTW I am now manually testing the thing I have the deadline on, which makes life a little bit less stressfull ;) Cool. James _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] Betwixt. setting namemapper for attributes.
i'll deprecate the current setNameMapper then and point it to setElementNameMapper, so we keep backwardcompatible ;) Mvgr, Martin On Wed, 2002-06-05 at 18:21, James Strachan wrote: From: Martin van den Bemt [EMAIL PROTECTED] If I am not mistaking the only change that is need then is to change the current setNameMapper(..) to setElementNameMapper(..). Since the attributeNameMapper is already a NameMapper type ;) Agreed. The suggestion was merely a mind spin, that it maybe better to use an AttributeNameMapper type, so it is more clear. That mind spin came from the fact that I thought that attributes were always read, not caring about naming rules.. Since the setAttributeNameMapper is pretty clear, I don't think we can leave it simple. I am using the HyphenatedNameMapper for my elements and the DecapitalizeNameMapper for my attributes ;) Yes, both of type NameMapper. So all I meant was let XMLIntrospector have 2 properties, of type NameMapper, one for elements and one for attributes. My renewed patch will be sent tonight (seems like it is working, but didn't get to parse the complete xml file yet). BTW I am now manually testing the thing I have the deadline on, which makes life a little bit less stressfull ;) Cool. James _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
test
testing my mail protocols. *** Richard A. Sitze[EMAIL PROTECTED] CORBA Interoperability WebServices IBM WebSphere Development
Re: [VOTE] move Betwixt into commons proper (was Re: Betwixt MethodUpdaters)
I'm +1 on this...but I want you guys to wait a bit until I do more testing... -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] Betwixt. setting namemapper for attributes.
From: Martin van den Bemt [EMAIL PROTECTED] i'll deprecate the current setNameMapper then and point it to setElementNameMapper, so we keep backwardcompatible ;) +1. James _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [HttpClient] Post parameters
Hi Marc,
You asked for suggestions. As I said in my previous note,
chaining to other instances of HttpMethod would probably
help improve the readability and maintainability of the
HttpMethodBase class.
Here are more specifics on the implementation I would
suggest:
1) Have an ivar defined something like:
private HttpMethod redirectedTo = null;
2) Instead of looping inside #execute to handle redirects,
populate the redirectedTo ivar with a new HttpMethod
impl with the results of a new HttpMethod method like
this pseudocode:
GetMethod implementation:
public HttpMethod createRedirectMethod(String path) {
GetMethod gm = new GetMethod(path);
// assuming requestHeaders can be made protected
gm.requestHeaders = this.requestHeaders;
return gm;
}
PostMethod implementation:
public HttpMethod createRedirectMethod(String path) {
if (useOfficialRedirectSpec) {
PostMethod pm = new PostMethod(path);
pm.requestHeaders = this.requestHeaders;
pm.parameters = this.parameters;
return pm;
} else {
GetMethod gm = new GetMethod(path);
gm.requestHeaders = this.requestHeaders;
return gm;
}
}
This will do several things:
a) Keep knowledge of subclasses out of the abstract
HttpMethodBase.
b) Avoid adding any more if statements to #execute.
c) Allow for other subclasses that can define their
own behavior without modifying the superclass.
3) Change the get methods (like #getResponseBody and
#getResponseCode) to forward the request to the
redirectedTo instance if it's not null. Otherwise
return your own values. This will allow for cleaner
handling of multiple redirects and fewer bugs.
Jonathan
=
Jonathan Carlson
[EMAIL PROTECTED]
Minneapolis, Minnesota
__
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/tags/ant TaskTag.java
werken 2002/06/05 10:05:22
Modified:jelly/src/java/org/apache/commons/jelly/tags/ant
TaskTag.java
Log:
Modified TaskTag to call through ant's normal property-resolution
code.
Revision ChangesPath
1.5 +20 -3
jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/tags/ant/TaskTag.java
Index: TaskTag.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/tags/ant/TaskTag.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- TaskTag.java 2 Jun 2002 17:29:02 - 1.4
+++ TaskTag.java 5 Jun 2002 17:05:21 - 1.5
@@ -69,6 +69,7 @@
import org.apache.commons.jelly.XMLOutput;
import org.apache.tools.ant.Task;
+import org.apache.tools.ant.Project;
/**
* A tag which invokes an Ant Task
@@ -92,18 +93,34 @@
// Tag interface
//-
public void doTag(XMLOutput output) throws Exception {
+
task.init();
-
+
// run the body first to configure the task via nested
getBody().run(context, output);
-
-task.execute();
+
+// task.execute();
+task.perform();
}
// TaskSource interface
//-
public Object getTaskObject() {
return task;
+}
+
+
+public void setAttribute(String name,
+ Object value)
+{
+// Catch the normal setAttribute, and call throw Ant's
+// normal property-deref routines.
+Project project = task.getProject();
+
+String newValue = project.replaceProperties( (String) value );
+
+super.setAttribute( name,
+newValue );
}
// Properties
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/tags/ant TaskTag.java
werken 2002/06/05 10:14:38 Modified:jelly/src/java/org/apache/commons/jelly/tags/ant TaskTag.java Log: Patch to allow it to work with ant-1.4.x instead of requiring 1.5 API. Revision ChangesPath 1.6 +4 -1 jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/tags/ant/TaskTag.java Index: TaskTag.java === RCS file: /home/cvs/jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/tags/ant/TaskTag.java,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- TaskTag.java 5 Jun 2002 17:05:21 - 1.5 +++ TaskTag.java 5 Jun 2002 17:14:38 - 1.6 @@ -70,6 +70,7 @@ import org.apache.tools.ant.Task; import org.apache.tools.ant.Project; +import org.apache.tools.ant.ProjectHelper; /** * A tag which invokes an Ant Task @@ -117,7 +118,9 @@ // normal property-deref routines. Project project = task.getProject(); -String newValue = project.replaceProperties( (String) value ); +String newValue = ProjectHelper.replaceProperties( project, + (String) value, + project.getProperties() ); super.setAttribute( name, newValue ); -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Digester - NPE in CallMethodRule constructor?
On Monday, June 3, 2002, at 08:29 PM, Matt Smith wrote: In CallMethodRule.java, v1.16, line 230: digester.getClassLoader().loadClass(paramTypes[i]); is contained in a constructor that does not set the digester. Assumedly the digester is supposed to be set using the new way of maing the association (addRule), but this constructor accesses the digester before it's been set, so I think this will always cause an NPE. Am I missing something? no matt - it was me who was missing something when i converted that class to use the 'new' way :) thanks - robert -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/tags/core ImportTag.java CoreTagLibrary.java
werken 2002/06/05 11:03:38
Modified:jelly/src/java/org/apache/commons/jelly/tags/core
CoreTagLibrary.java
Added: jelly/src/java/org/apache/commons/jelly/tags/core
ImportTag.java
Log:
Added jelly:import uri=location/ which is semantically
equivalent to jelly:include uri=location inherit=false export=true/
Like include, import allows the configuration of the 'inherit'
attribute, which defaults to false.
Revision ChangesPath
1.10 +6 -5
jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/tags/core/CoreTagLibrary.java
Index: CoreTagLibrary.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/tags/core/CoreTagLibrary.java,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- CoreTagLibrary.java 23 May 2002 23:33:35 - 1.9
+++ CoreTagLibrary.java 5 Jun 2002 18:03:38 - 1.10
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/tags/core/CoreTagLibrary.java,v
1.9 2002/05/23 23:33:35 jstrachan Exp $
- * $Revision: 1.9 $
- * $Date: 2002/05/23 23:33:35 $
+ * $Header:
/home/cvs/jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/tags/core/CoreTagLibrary.java,v
1.10 2002/06/05 18:03:38 werken Exp $
+ * $Revision: 1.10 $
+ * $Date: 2002/06/05 18:03:38 $
*
*
*
@@ -57,7 +57,7 @@
* information on the Apache Software Foundation, please see
* http://www.apache.org/.
*
- * $Id: CoreTagLibrary.java,v 1.9 2002/05/23 23:33:35 jstrachan Exp $
+ * $Id: CoreTagLibrary.java,v 1.10 2002/06/05 18:03:38 werken Exp $
*/
package org.apache.commons.jelly.tags.core;
@@ -75,7 +75,7 @@
/** Describes the Taglib. This class could be generated by XDoclet
*
* @author a href=mailto:[EMAIL PROTECTED];James Strachan/a
- * @version $Revision: 1.9 $
+ * @version $Revision: 1.10 $
*/
public class CoreTagLibrary extends TagLibrary {
@@ -93,6 +93,7 @@
registerTag(otherwise, OtherwiseTag.class);
// other tags
registerTag(include, IncludeTag.class);
+registerTag(import, ImportTag.class);
// extensions to JSTL
registerTag(expr, ExprTag.class);
1.1
jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/tags/core/ImportTag.java
Index: ImportTag.java
===
/*
* $Header:
/home/cvs/jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/tags/core/ImportTag.java,v
1.1 2002/06/05 18:03:38 werken Exp $
* $Revision: 1.1 $
* $Date: 2002/06/05 18:03:38 $
*
*
*
* The Apache Software License, Version 1.1
*
* Copyright (c) 1999-2002 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in
*the documentation and/or other materials provided with the
*distribution.
*
* 3. The end-user documentation included with the redistribution, if
*any, must include the following acknowlegement:
* This product includes software developed by the
*Apache Software Foundation (http://www.apache.org/).
*Alternately, this acknowlegement may appear in the software itself,
*if and wherever such third-party acknowlegements normally appear.
*
* 4. The names The Jakarta Project, Commons, and Apache Software
*Foundation must not be used to endorse or promote products derived
*from this software without prior written permission. For written
*permission, please contact [EMAIL PROTECTED]
*
* 5. Products derived from this software may not be called Apache
*nor may Apache appear in their names without prior written
*permission of the Apache Group.
*
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
* WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
NullPointerException when performing addCallMethod
Hi
I am trying to parse an XML document that has a numeric attribute (size)
in one of its elements. I was trying to invoke a setNumber(int value)
method in the bean by adding a CallMethodRule and a CallParamRule:
digester.addCallMethod(result/stats,
setNumber, 1, new String[] {java.lang.Integer});
digester.addCallParam(result/stats, 0, size);
This code throws a NullPointerException in the CallMethodRule(String
methodName,int paramCount, String paramTypes[]) constructor (in line
229). (I am using digester 1.2 over Linux with the Sun Java 1.3.1).I
have been looking for the error cause, and I have found that the
constructor uses a digester.getClassLoader().load... method when the
paramTypes array specified is not empty.
Well, looking at the digester source code, it seems that the
CallMethodRule is created in the addCallMethod method, so in that
constructor the digester object has not been set (the setDigester method
is invoked in the addRule method of the Digester class, after creating
the CallMethodRule). So, IMHO, the NullPointerException will appear
whenever a non-empty paramTypes array is specified in the CallMethodRule
creation, because the Digester object will never be set in that point of
the program. Do you think that this is correct?
I have been also looking at the RuleTestCase, and there are no tests
checking this constructor with a non-empty paramTypes array, so this
situation is not tested.
In my opinion, the ClassLoader must be obtained using another object and
a new test line should be added in the TestCase.
What do you think about this? Is this correct? Has anybody had this
problem before?
Thanks,
Álvaro Barge
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Messenger DTDs, XSDs...?
Thanks for your reply. I am *somewhat* familiar with
Digester. I know that it is common practice for
XML-Java mapping utilities to use setter methods to
populate beans from attributes/elements with the same
name (setFoo(String foo) with attribute/element
'foo'). However, I found in another posting...
http://nagoya.apache.org/eyebrowse/ReadMsg?[EMAIL PROTECTED]msgId=77976
...that one could use durable subscriptions in the
following manner:
messenger name=foo durable=true
factory transacted=true
...
My question is... is there any way that I could have
known that without reading it on the mailing list? I
looked at the Messenger interface and I couldn't find
a setter method such as setDurable(boolean durable).
Maybe I can browse the source code... where in the
source code is the attribute durable handled?
Thank You!
--- James Strachan [EMAIL PROTECTED] wrote:
From: Spam Cut [EMAIL PROTECTED]
Hi,
I was wondering if someone could point me to
documentation for the messenger and
subscriptions
xml config files. There seem to be many attributes
for
the subscriptions xml config file that aren't
described in the overview. Is there any
documentation
for these in some form (DTD, XSD, Text File, PDF
File,
etc...)?
Unfortunately not yet.
Messenger is using the Digester which means that the
schema can be soft
coded. This allows you to plugin your own
implementations of things (like
your own SessionFactory in the messenger.xml file or
your own
MessageListener or MDO implementaiton in the
subscription.xml file) and then
configure those within the same document.
e.g.
public class MyMDO extends MessengerMDO {
public void setFoo(String foo);
public void setBar(int bar);
}
then in subscription.xml I could do...
subscriptions
subscription connection=myQueueConnection
subject=in.queue
listener className=MyMDO foo=valueOfFoo
bar=1234/
/subscription
/subscriptions
So that the 'foo' and 'bar' attributes above come
really from the underlying
MessageListener / MDO.
Though I totally agree with you that the common
elements/attributes should
be properly documented. I've added this to the todo
list so it'll get done
one day (hopefully soon). As usual, any
contributions are greatfully
received ;-)
James
_
Do You Yahoo!?
Get your free @yahoo.com address at
http://mail.yahoo.com
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
=
[EMAIL PROTECTED]
__
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] Betwixt. setting namemapper for attributes.
James, Also strugling with the setWrapCollectionsInElement(). It is never used btw, so I explain here what I think was intended, can you please confirm that, since I am making it work that way ;) First the use case if it is set to true : mainelement elements element/ element/ /elements /mainelement methods : addElement(Element element) and List getElements() now if it is set to false (the thing I need) mainelement element/ element/ /mainelement methods : addElement(Element element) and List getElements() The second sample isn't working correctly. Is the second case intended to be working like that when it is set to false? I am assuming that at the moment, so I can actually parse the damned xml thing ;), but it would be nice if it is usable.. I will set the default to true, since that is the current behaviour and we need backwards compaitibility ;). Mvgr, Martin On Wed, 2002-06-05 at 18:42, James Strachan wrote: From: Martin van den Bemt [EMAIL PROTECTED] i'll deprecate the current setNameMapper then and point it to setElementNameMapper, so we keep backwardcompatible ;) +1. James _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/jelly/src/test/org/apache/commons/jelly/expression - New directory
jstrachan2002/06/05 12:00:17 jakarta-commons-sandbox/jelly/src/test/org/apache/commons/jelly/expression - New directory -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[PATCH] Small Documentation Error in NestableException
Hi all, I couldn't seem to find the page on the Jakarta site that specifies how to create a proper diff patch. There where some small documentation errors for org.apache.commons.lang.exception.NestableException that I stubbed my toe on when I first tried to use it. Eric cvs -z9 -q diff -w -i NestableException.java (in directory C:\java\jakarta-commons-sandbox\lang\src\java\org\apache\commons\lang\except ion\) Index: NestableException.java === RCS file: /home/cvspublic/jakarta-commons-sandbox/lang/src/java/org/apache/commons/lan g/exception/NestableException.java,v retrieving revision 1.1 diff -w -i -r1.1 NestableException.java 79c79 * 1 import org.apache.commons.NestedException; --- * 1 import org.apache.commons.lang.exception.NestableException; 94c94 * 16 throw new NestedException(foo, e); --- * 16 throw new NestableException(foo, e); 102c102 * 24 throw new NestedException(bar, e); --- * 24 throw new NestableException(bar, e); 116c116 * rethrown as NestedException: bar --- * rethrown as NestableException: bar 119c119 * rethrown as NestedException: foo --- * rethrown as NestableException: foo 126a127 * @author a href=mailto:[EMAIL PROTECTED];Eric Pugh/a -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: NullPointerException when performing addCallMethod
hi Álvaro
someone else reported this recently. i'm in the process of creating a fix
and test case.
- robert
On Wednesday, June 5, 2002, at 07:01 PM, Álvaro Barge wrote:
Hi
I am trying to parse an XML document that has a numeric attribute (size)
in one of its elements. I was trying to invoke a setNumber(int value)
method in the bean by adding a CallMethodRule and a CallParamRule:
digester.addCallMethod(result/stats,
setNumber, 1, new String[] {java.lang.Integer});
digester.addCallParam(result/stats, 0, size);
This code throws a NullPointerException in the CallMethodRule(String
methodName,int paramCount, String paramTypes[]) constructor (in line 229)
. (I am using digester 1.2 over Linux with the Sun Java 1.3.1).I have
been looking for the error cause, and I have found that the constructor
uses a digester.getClassLoader().load... method when the paramTypes
array specified is not empty.
Well, looking at the digester source code, it seems that the
CallMethodRule is created in the addCallMethod method, so in that
constructor the digester object has not been set (the setDigester method
is invoked in the addRule method of the Digester class, after creating
the CallMethodRule). So, IMHO, the NullPointerException will appear
whenever a non-empty paramTypes array is specified in the CallMethodRule
creation, because the Digester object will never be set in that point of
the program. Do you think that this is correct?
I have been also looking at the RuleTestCase, and there are no tests
checking this constructor with a non-empty paramTypes array, so this
situation is not tested.
In my opinion, the ClassLoader must be obtained using another object and
a new test line should be added in the TestCase.
What do you think about this? Is this correct? Has anybody had this
problem before?
Thanks,
Álvaro Barge
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED].
org
For additional commands, e-mail: mailto:[EMAIL PROTECTED].
org
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-commons/beanutils/src/test/org/apache/commons/beanutils BeanUtilsTestCase.java
rdonkin 2002/06/05 13:46:38
Modified:beanutils/src/java/org/apache/commons/beanutils
BeanUtils.java
beanutils/src/test/org/apache/commons/beanutils
BeanUtilsTestCase.java
Log:
Committed 'NoSuchMethod for read only properties and NullPointer when populating
primitives' patch submitted by Tomas Viberg. this is one of those patches that i
thought long and hard about committing. this isn't a part of beanutils that i'm
particularly familiar with but no one spoke up on the list when i asked so i'm going
to back my judgement. if i've got it wrong, i'm sure someone will be kind enough to
commit a correction. this patch changes the behaviour of two problematic setProperty
issues. when a setProperty was called on a read only method, the previous behaviour
was to throw a InvocationTargetException. this patch now returns (after logging). when
an primitive property was set with a null, a NullPointerException was throw. now, the
null is converted.
Revision ChangesPath
1.23 +25 -7
jakarta-commons/beanutils/src/java/org/apache/commons/beanutils/BeanUtils.java
Index: BeanUtils.java
===
RCS file:
/home/cvs/jakarta-commons/beanutils/src/java/org/apache/commons/beanutils/BeanUtils.java,v
retrieving revision 1.22
retrieving revision 1.23
diff -u -r1.22 -r1.23
--- BeanUtils.java17 May 2002 07:25:50 - 1.22
+++ BeanUtils.java5 Jun 2002 20:46:38 - 1.23
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-commons/beanutils/src/java/org/apache/commons/beanutils/BeanUtils.java,v
1.22 2002/05/17 07:25:50 jstrachan Exp $
- * $Revision: 1.22 $
- * $Date: 2002/05/17 07:25:50 $
+ * $Header:
/home/cvs/jakarta-commons/beanutils/src/java/org/apache/commons/beanutils/BeanUtils.java,v
1.23 2002/06/05 20:46:38 rdonkin Exp $
+ * $Revision: 1.23 $
+ * $Date: 2002/06/05 20:46:38 $
*
*
*
@@ -87,7 +87,7 @@
* @author Chris Audley
* @author Rey François
* @author Gregor Raýman
- * @version $Revision: 1.22 $ $Date: 2002/05/17 07:25:50 $
+ * @version $Revision: 1.23 $ $Date: 2002/06/05 20:46:38 $
*/
public class BeanUtils {
@@ -509,8 +509,14 @@
/**
- * Set the specified property value, performing type conversions as
- * required to conform to the type of the destination property.
+ * pSet the specified property value, performing type conversions as
+ * required to conform to the type of the destination property./p
+ *
+ * pIf the property is read only then the method returns
+ * without throwing an exception./p
+ *
+ * pIf codenull/code is passed into a property expecting a primitive
value,
+ * then this will be converted as if it were a codenull/code string./p
*
* @param bean Bean on which setting is to be performed
* @param name Property name (can be nested/indexed/mapped/combo)
@@ -619,12 +625,24 @@
return; // Skip this property setter
}
if (descriptor instanceof MappedPropertyDescriptor) {
+if (((MappedPropertyDescriptor) descriptor).getMappedWriteMethod()
== null) {
+log.debug(Skipping read-only property);
+return; // Read-only, skip this property setter
+}
type = ((MappedPropertyDescriptor) descriptor).
getMappedPropertyType();
} else if (descriptor instanceof IndexedPropertyDescriptor) {
+if (((IndexedPropertyDescriptor)
descriptor).getIndexedWriteMethod() == null) {
+log.debug(Skipping read-only property);
+return; // Read-only, skip this property setter
+}
type = ((IndexedPropertyDescriptor) descriptor).
getIndexedPropertyType();
} else {
+if (descriptor.getWriteMethod() == null) {
+log.debug(Skipping read-only property);
+return; // Read-only, skip this property setter
+}
type = descriptor.getPropertyType();
}
}
@@ -652,7 +670,7 @@
newValue = value;
}
} else { // Value into scalar
-if (value instanceof String) {
+if (value instanceof String || (value == null type.isPrimitive())) {
newValue = ConvertUtils.convert((String) value, type);
} else if (value instanceof String[]) {
newValue = ConvertUtils.convert(((String[]) value)[0],
1.10 +11 -7
cvs commit: jakarta-commons/digester/src/test/org/apache/commons/digester RuleTestCase.java
rdonkin 2002/06/05 14:23:24
Modified:digester/src/java/org/apache/commons/digester
CallMethodRule.java
digester/src/test/org/apache/commons/digester
RuleTestCase.java
Log:
Fixed bug with CallMethodRule introduced when constructors accepting the digester as
a parameter were depricated. CallMethodRule now waits until the digester is set before
loading classes from classnames
Revision ChangesPath
1.17 +38 -13
jakarta-commons/digester/src/java/org/apache/commons/digester/CallMethodRule.java
Index: CallMethodRule.java
===
RCS file:
/home/cvs/jakarta-commons/digester/src/java/org/apache/commons/digester/CallMethodRule.java,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -r1.16 -r1.17
--- CallMethodRule.java 18 Apr 2002 21:23:44 - 1.16
+++ CallMethodRule.java 5 Jun 2002 21:23:23 - 1.17
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-commons/digester/src/java/org/apache/commons/digester/CallMethodRule.java,v
1.16 2002/04/18 21:23:44 rdonkin Exp $
- * $Revision: 1.16 $
- * $Date: 2002/04/18 21:23:44 $
+ * $Header:
/home/cvs/jakarta-commons/digester/src/java/org/apache/commons/digester/CallMethodRule.java,v
1.17 2002/06/05 21:23:23 rdonkin Exp $
+ * $Revision: 1.17 $
+ * $Date: 2002/06/05 21:23:23 $
*
*
*
@@ -82,7 +82,7 @@
*
* @author Craig McClanahan
* @author Scott Sanders
- * @version $Revision: 1.16 $ $Date: 2002/04/18 21:23:44 $
+ * @version $Revision: 1.17 $ $Date: 2002/06/05 21:23:23 $
*/
public class CallMethodRule extends Rule {
@@ -223,14 +223,11 @@
this.paramTypes[i] = abc.getClass();
}
} else {
-this.paramTypes = new Class[paramTypes.length];
-for (int i = 0; i this.paramTypes.length; i++) {
-try {
-this.paramTypes[i] =
-digester.getClassLoader().loadClass(paramTypes[i]);
-} catch (ClassNotFoundException e) {
-this.paramTypes[i] = null; // Will cause NPE later
-}
+// copy the parameter class names into an array
+// the classes will be loaded when the digester is set
+this.paramClassNames = new String[paramTypes.length];
+for (int i = 0; i this.paramClassNames.length; i++) {
+this.paramClassNames[i] = paramTypes[i];
}
}
@@ -303,9 +300,37 @@
*/
protected Class paramTypes[] = null;
-
+/**
+ * The names of the classes of the parameters to be collected.
+ * This attribute allows creation of the classes to be postponed until the
digester is set.
+ */
+private String paramClassNames[] = null;
+
// - Public Methods
+/**
+ * Set the associated digester.
+ * If needed, this class loads the parameter classes from their names.
+ */
+public void setDigester(Digester digester)
+{
+// call superclass
+super.setDigester(digester);
+// if necessary, load parameter classes
+if (this.paramClassNames != null) {
+this.paramTypes = new Class[paramClassNames.length];
+for (int i = 0; i this.paramClassNames.length; i++) {
+try {
+this.paramTypes[i] =
+
digester.getClassLoader().loadClass(this.paramClassNames[i]);
+} catch (ClassNotFoundException e) {
+// use the digester log
+digester.getLogger().error((CallMethodRule) Cannot load class
+ this.paramClassNames[i], e);
+this.paramTypes[i] = null; // Will cause NPE later
+}
+}
+}
+}
/**
* Process the start of this element.
1.13 +33 -5
jakarta-commons/digester/src/test/org/apache/commons/digester/RuleTestCase.java
Index: RuleTestCase.java
===
RCS file:
/home/cvs/jakarta-commons/digester/src/test/org/apache/commons/digester/RuleTestCase.java,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- RuleTestCase.java 18 Apr 2002 21:23:44 - 1.12
+++ RuleTestCase.java 5 Jun 2002 21:23:24 - 1.13
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-commons/digester/src/test/org/apache/commons/digester/RuleTestCase.java,v
1.12 2002/04/18 21:23:44 rdonkin Exp $
- * $Revision: 1.12 $
- * $Date: 2002/04/18 21:23:44 $
+ * $Header:
Re: Digester - NPE in CallMethodRule constructor?
this should now be fixed in the latest version in cvs. - robert On Monday, June 3, 2002, at 08:29 PM, Matt Smith wrote: In CallMethodRule.java, v1.16, line 230: digester.getClassLoader().loadClass(paramTypes[i]); is contained in a constructor that does not set the digester. Assumedly the digester is supposed to be set using the new way of maing the association (addRule), but this constructor accesses the digester before it's been set, so I think this will always cause an NPE. Am I missing something? -Matt -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]. org For additional commands, e-mail: mailto:[EMAIL PROTECTED]. org -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH][BeanUtils] NoSuchMethod for read only properties and NullPointer when populating primitives
(after a bit of consideration) i've now committed this patch. this isn't really a bit of beanutils i've been heavily involved with, so if anyone has strong opinions that it this is wrong, i won't be upset if they want to fix it in some other way. - robert On Sunday, May 26, 2002, at 06:17 PM, Tomas Viberg wrote: Comments, anyone? Regards / Tomas - Original Message - From: Tomas Viberg To: [EMAIL PROTECTED] Sent: Sunday, May 19, 2002 7:29 PM Subject: [PATCH] BeanUtils - read only properties and null value conversion Hello, I humbly submit a patch for BeanUtils.java, correcting the following errors: 1. When you try to populate a read-only property, the populate method throws a NoSuchMethodException (wrapped in an InvocationTargetException), since there is no check that the property has a setter method. 2. When you try to populate a primitive property with a null value, you get a NullPointerException, since no data type conversion is applied to null values. I have also patched BeanUtilsTestCase.java to include setting a primitive property to null and attempting to set a read-only (simple) property. Regards, Tomas Viberg, [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]. org For additional commands, e-mail: mailto:[EMAIL PROTECTED]. org -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]. org For additional commands, e-mail: mailto:[EMAIL PROTECTED]. org -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [JXPATH] best approch for customization
Steve, You don't actually need to implement NodePointer. All you need to implement is a NodePointerFactory, which is a very simple interface. Try the following: 1. Create a class implementing NodePointerFactory. In the createNodePointer() methods (two implementations are required) check for the token interface. 2. If the object passed to the factory implements the token interface, return a DynamicPointer a la DynamicPointerFactory 3. If the object does not implement the token interface, return null - that'll let other factories to do their usual job. 4. Very importantly, make the getOrder() method return a number that is less than BeanPointerFactory.BEAN_POINTER_FACTORY_ORDER, so it would take precedence over that one. 5. Register the new factory with JXPathContextReferenceImpl I hope this helps. - Dmitri - Original Message - From: Stephen Bartlett [EMAIL PROTECTED] To: Jakarta Commons Developers List (E-mail) [EMAIL PROTECTED] Sent: Wednesday, June 05, 2002 1:14 AM Subject: [JXPATH] best approch for customization Hi, all, I have a question regarding the best approach for customizing JXPath. I looked at providing a NodePointer implementation but was not convinced this was the right course and also deterred by the large interface. I like what JXPath provides out-of-the-box with regards to JavaBean support, but instead of allowing clients unvetted access to the whole of my API I would prefer to restrict access. The initial idea was to provide a new JXPathIntospector implementation that hands off to a 'GuardHandler' if the context object implements a well-known tag interface, otherwise it would follow the normal JavaBean resolution. The 'GuardHandler' (implemtation of DynamicPropertyHandler) guards against using any methods not defined for the given bean. I then realised the JXPathIntrospector is not configurable which lead me to the NodePointer. I'm now wondering the best approach. Any guidance would be much appreciated. cheers, steve. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[PATCH][Collections] SequencedHashMap collection view bugs
Bugs fixed: 1. keySet().remove(Object) incorrectly returned false after a successful removal of a null key. 2. The removeAll(Collection) and retainAll(Collection) methods of the collection views (keySet, entrySet and values) were not updating the modCount; therefore an iterator over a collection view would not raise a ConcurrentModificationException after those operations. -Paul seq_hash_map.diff Description: Binary data -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: jdbcpool
Thanks for the reply, I had found the autoReconnect parameter and that seeme to solve my problem. I heard there is an over head associated with that though but I don't believe it to be a problem for me at this time. On Tue, 2002-06-04 at 22:22, Glenn Nielsen wrote: If your are using the mm.mysql JDBC driver add the autoReconnect=true arg to your mysql connect url. With this the mysql jdbc driver will reconnect to the db if it looses the connection. Then you can set your minIdle to 1, and your mysql db can timeout its connection after the default 8 hours. But that one idle connection in dbcp can reconnect if needed. Regards, Glenn Dennis Muhlestein wrote: I'm using the commons-pool, commons-dbcp to connect to mysql from tomcat 4. Everything works fine when I develop but if I leave the site unattened for a period of time, mysql times out the connections in the pool. I'd really like to set the maxIdle parameter to 0 so that if there are idle connections they leave the pool. Basically setting the min pool size to 0 is what I want to do. I haven't seen a minPoolSize parameter though. The documentation says if I set maxIdle to 0 that means unlimited. That won't work I guess. Is there a solution to this problem? Thanks Dennis -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | -- -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] move Betwixt into commons proper (was Re: Betwixt MethodUpdaters)
I'm +1. -- dIon Gillard, Multitask Consulting Work: http://www.multitask.com.au Developers: http://adslgateway.multitask.com.au/developers Geir Magnusson Jr. To: Jakarta Commons Developers List [EMAIL PROTECTED] geirm@adeptra cc: .comSubject: Re: [VOTE] move Betwixt into commons proper (was Re: Betwixt MethodUpdaters) 06/05/02 10:11 PM Please respond to Jakarta Commons Developers List +1 from a non-participant... On 6/5/02 6:49 AM, James Strachan [EMAIL PROTECTED] wrote: - Original Message - From: Jason van Zyl [EMAIL PROTECTED] It now looks like the bugs have been squashed so how about we propose to move Betwixt up to the commons proper and do a release? Sounds good with me. Lets do it in 2 stages, move to commons proper first, then leave it a couple of days to check that noone can find any more bugs, then lets call another vote to release it. So here's the first vote, to move betwixt to commons proper. Already there's 4 developers and several projects using betwixt so I think it passes all the conditions. http://jakarta.apache.org/commons/sandbox/betwixt/developer-list.html I'm +1 James _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Geir Magnusson Jr. Research Development, Adeptra Inc. [EMAIL PROTECTED] +1-203-247-1713 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Test III
tried to re-create the problem and noticed interesting/different results. In this last case I create a new mail message (not responding), and I see what looks like (to my Notes mail reader) plain text results on the commons mailing list, and HTML on axis-dev. My personal setting is plain text for internet mail. By generating this message to both mailing lists at the same time, and two interested parties, I hope to further determine what is happening... *** Richard A. Sitze[EMAIL PROTECTED]
