On Fri, 2004-03-12 at 11:35, robert burrell donkin wrote:
On 10 Mar 2004, at 23:58, Simon Kitching wrote:
One major issue though: the way that rules fire in reverse order at end
regularly catches users out (see Diego's email of today in the
commons-user list).
snipped useful section i
On Thu, 2004-03-11 at 12:02, robert burrell donkin wrote:
it's really a way to provide better support for immutable objects
(which Dimension is not. Doh!)
On 10 Mar 2004, at 22:52, robert burrell donkin wrote:
i'm thinking of adding a rule that constructs a non-bean (in other
words, a
On Sun, 2004-03-07 at 11:37, robert burrell donkin wrote:
On 4 Mar 2004, at 07:59, Jörg Schaible wrote:
Simon Kitching wrote on Wednesday, March 03, 2004 11:54 PM:
snip
In some ways it's nice,
because it is obvious to users, but of course every rule
added to Digester increases
On Mon, 2004-03-08 at 08:37, robert burrell donkin wrote:
i've committed an implemention plus some documentation.
Do you want this to be in the next release (which is hopefully very
soon)?
Unless you are very confident in the current design, it may be better to
wait until after the release to
On Thu, 2004-03-04 at 11:11, robert burrell donkin wrote:
On 3 Mar 2004, at 08:41, Jörg Schaible wrote:
Hi folks,
what about adding new rules to digester? In my project I have two
rules I can share:
1) AddToMapRule
Ctors:
AddToMapRule(int stackPosition, String key)
On Wed, 2004-03-03 at 10:42, Mark R. Diggory wrote:
I'm noticing difficulty in starting up my tomcat servers, that seems to
arise in the digester. I suspect this is caused by the digester having
difficulty acquiring the dtd due to the Sun site being down? Does anyone
have any tips on
On Mon, 2004-03-01 at 18:35, [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote on 29/02/2004 12:44:05 AM:
yoavs 2004/02/28 05:44:05
Added: jellyNOTICE.txt
Log:
Added NOTICE.txt per ASF directive,
http://www.apache.org/dev/apply-license.html.
Revision
On Sun, 2004-02-29 at 03:38, robert burrell donkin wrote:
On 28 Feb 2004, at 05:38, Henri Yandell wrote:
The Java version in the committers/ doesn't strip out @author. Just in
case you want to avoid having to change this now.
My mistake.
that'd be good. i think that simon's suggestions
Hi,
I'm willing to do the relicensing work for digester.
I've experimented with the ReplaceLicense tool in committers repo, and
it seems simple enough.
Unless anyone objects, I will apply/commit the new license in about 48
hours from now.
Note: I've grepped for copyright statements in
On Sat, 2004-02-28 at 14:55, Simon Kitching wrote:
Hi,
I'm willing to do the relicensing work for digester.
BTW, the relicensing stuff will strip out all the @author tags.
So I would like to add the following @authors to the contributors
section of the project.xml file:
* David H. Martin
On Fri, 2004-02-27 at 09:51, Gary Gregory wrote:
Hello,
A couple of comments:
- This method might be more at home in ArrayUtils.
- The method name should not start with a capital letter.
- When you submit a patch, do not forget to Javadocs boundary conditions and
special cases (null,
Hi Emmanuel,
Re your comments on bugzilla
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12997
I'd like to transfer this discussion to email rather than bugzilla form,
if that's ok. It's a pain typing and reading bugzilla comments :-)
I guess the problem is that the bugzilla entry is now
On Wed, 2004-02-18 at 13:59, John Keyes wrote:
We currently use the filename LICENSE.txt, to follow the steps
suggested in the guide we should drop the txt extension.
The jakarta-commons dir contains two files with very similar contents,
LICENSE and LICENSE.txt. Following the guidelines
On Mon, 2004-02-16 at 11:32, robert burrell donkin wrote:
(a few possible disconnected observations.)
betwixt is more focussed on automated mapping than digester. betwixt
bean reading rulesets can be freely mixed with digester rules but it's
designed (at the moment) around producing a
On Tue, 2004-02-17 at 10:38, David Graham wrote:
Any chance the commons-collections usage can be removed for this release? This was
brought up earlier and seemed to be supported. The last I checked digester made a
very minimal use of commons-collections anyways. Other packages using
On Mon, 2004-02-16 at 11:43, robert burrell donkin wrote:
On 12 Feb 2004, at 06:25, Simon Kitching wrote:
Hi Robert,
hi simon
A while ago there was some discussion about the newly added
MultiVariableExpander, and whether or not there was also a need for a
simple VariableExpander
On Tue, 2004-02-17 at 04:52, Simon Kitching wrote:
I only see *one* item as needing to be done prior to a release
Oh - and change the licence to version 2.0.
The email discussion about permission to relicense has died away.
I saw Craig's email saying it was ok, but nothing from the ASF
Hi,
As discussed on the user list, there appears to be a need to make calls
on objects other than the top-of-stack in a manner more flexible than
the limited SetNextRule and SetRootRule.
Attached is a patch which adds a targetOffset attribute to the
CallMethodRule to indicate which object on the
On Thu, 2004-02-12 at 12:07, Joe Germuska wrote:
Since you've already got working code, take this as just something to
think about -- but I recently was wishing for a map to complement the
stack; some place to put objects under names and then have other
rules refer to those objects by name.
Hi Robert,
A while ago there was some discussion about the newly added
MultiVariableExpander, and whether or not there was also a need for a
simple VariableExpander implementation.
You were going to look into whether MultiVariableExpander implements a
true superset of ant variable-expansion
On Tue, 2004-01-20 at 11:07, Ron Blaschke wrote:
I am posting this here because I think commons would be the
right place to put such a library. Please tell me if it's not.
The idea is to allow conversion for (almost?) any object into another.
I'd like to see code such as this working:
Have
I'm -0 on moving Digester (the project I mostly contribute to).
It's purely on philosophical grounds. While it's kind of the JIRA team
to grant free use of their product I would prefer to stay with something
free. I'm not opposed to commercial products but bug/issue tracking is a
core development
On Tue, 2004-01-13 at 16:02, Phil Steitz wrote:
--- Gary Gregory [EMAIL PROTECTED] wrote:
What is the motivation for this migration exactly ?
I am curious about that one too, but at this point it seems like a fait
accomplis.
Is it? I don't remember seeing a vote anywhere.
I think a MIME Multipart project is a great idea (whether independent or
part of codec), and would be willing to contribute some time to it.
I have written (and continue to maintain) a b2b framework for my
employer. We use ebxml over IBM MQSeries to transfer messages around,
and ebxml uses MIME
On Mon, 2004-01-12 at 17:14, Mark R. Diggory wrote:
Noel J. Bergman wrote:
Mark R. Diggory asked:
Shouldn't [mime] be dependent on JAF?
Why?
--- Noel
For a standardized cross platform means of resolving a streams mime-type
to an appropriate Object (File, String,
On Thu, 2004-01-08 at 10:56, robert burrell donkin wrote:
at first glance it seems that pretty much everything is there but i'd
like to double check before it's declared official. i like to ask first
just in case any other people have any strong feelings about not
mavenizing digester. (now
On Mon, 2003-12-29 at 16:39, Phil Steitz wrote:
The subject of @author tags has been discussed on and off here and
elsewhere with no apparent consensus. In a recent post to general@, Ted
Husted pointed to this post
http://tinyurl.com/yrlhu
by Greg Stein to community at apache.org, which
Hi,
My first thoughts on this patch were that a lot of work has gone into
this - and a lot of code been created.
And all this is just in order to support the existing
Digester.setSchema(...) method which causes Digester to validate the
input XML against a schema while parsing, right?
I'm
Hi Robert,
I think the code committed is just fine.
I like the versatile Substitutor interface; I can imagine all sorts of
uses for the ability to arbitrarily manipulate attribute values and body
text before rules see them other than just var expansion.
I also like the separation of this code
On Wed, 2003-12-03 at 22:59, ASHWIN Suresh wrote:
Sorry to jump in to this thread this way, and perhaps it is too late now.
But, have the people here considered using the term resolve
for this concept?
I don't think it is too late for suggestions like this. Any time before
the release is not
On Fri, 2003-12-05 at 11:17, Simon Kitching wrote:
Hi Robert,
I think the code committed is just fine.
On further thought, I have a more significant change to suggest.
I think the VariableSubstitutor and MultiVariableExpander classes should
be merged. VariableSubstitutor really is a nothing
Hi,
There's been no comment by anyone on the following emails.
This is just a reminder(I know everyone's busy).
http://marc.theaimsgroup.com/?l=jakarta-commons-devm=106979874724976w=2
http://marc.theaimsgroup.com/?l=jakarta-commons-devm=106989251623459w=2
Regards,
Simon
On Wed, 2003-12-03 at 12:34, robert burrell donkin wrote:
anyone care to volunteer to write something for the newsletter?
(we've got quite a bit of good new stuff and we'll probably be wanting
a release sometime soonish.)
I'll put my hand up. I'm free this evening (apart from looking at all
On Thu, 2003-11-27 at 00:01, Simon Kitching wrote:
Attached is a complete implementation of the variable expansion
feature. I do also have some unit tests for it, but unfortunately they
are still on my home PC so I will have to send them tomorrow.
And here it is (plus a patch to add the test
On Wed, 2003-11-26 at 09:52, robert burrell donkin wrote:
On 24 Nov 2003, at 23:54, Simon Kitching wrote:
I'm *really* in favour of providing expansion in body text as well as
attributes.
yep. but i'd favour a sequential approach. remy needs attributes right
now, so let's do attributes
On Tue, 2003-11-25 at 11:32, robert burrell donkin wrote:
i've finally found time to consider both proposals (apologies for the
delay).
1. i think that i like some parts of remy's solution but would prefer
the actual implementation to be pluggable through a strategy interface
On Tue, 2003-11-25 at 12:31, robert burrell donkin wrote:
On 24 Nov 2003, at 22:54, Simon Kitching wrote:
On Tue, 2003-11-25 at 11:32, robert burrell donkin wrote:
i've finally found time to consider both proposals (apologies for the
delay).
1. i think that i like some parts of remy's
On Wed, 2003-11-19 at 12:30, robert burrell donkin wrote:
hi simon
just to let you know that i would have committed your patch but there's
a broken lock in cvs :(
Thanks Robert.
Since the new rule is considered acceptable, here's a patch that adds
the tests to build.xml. Hope that CVS
On Wed, 2003-11-19 at 11:35, robert burrell donkin wrote:
hi simon
i've committed both patches.
would you be willing to knock up a test case for the second?
You're keeping me honest here :-)
Test case attached.
Index: org/apache/commons/digester/plugins/TestInline.java
can be achieved using a combination of the
* BeanPropertySetterRule and the ExtendedBaseRules rules manager; this
* Rule, however, works fine with the default RulesBase rules manager./p
*
* @author Simon Kitching
* @version $Revision: $ $Date: $
*/
public class SetNestedPropertiesRule
On Tue, 2003-11-18 at 11:32, Simon Kitching wrote:
Hi,
Attached is a rule which behaves like a cross between SetPropertiesRule
and BeanPropertySetterRule-with-trailing-wildcard-match.
I should mention that this rule comes in very useful when using the
Plugins module. That module does
Hi,
The first attached patch is just a fix for a minor javadoc problem
introduced in an earlier patch.
The second patch is perhaps more controversial: it allows a leading
slash on patterns for the PluginRules class.
ie /root/item is treated just like root/item.
This is useful because
Hi Remy,
On Wed, 2003-11-12 at 23:01, Remy Maucherat wrote:
Simon Kitching wrote:
Hi Remy,
I'm really keen to have this sort of feature in Digester.
I've had this kind of functionality in my local application for some
time now, but it's implemented in a rather different manner
On Wed, 2003-11-12 at 11:14, Samuel Cheung wrote:
I have a newbie question. What are the advantages/dis-advantages between
Digester vs xmlbean vs JAXB? My understanding is they convert XML file to
Java Class. Is that correct?
If that is the case, shouldn't one use JAXB over xmlbean and
of the Apache Digester for use with the ECN Connector.
* p
* This class applies variable substitution to all xml attributes and
* element-body-text before passing the data to any digester rules. This
* functionality could also have been implemented
* as a SAX filter...
*
* @author Simon Kitching
Hi,
I sent a patch to allow users of the plugins module to select the xml
attribute which specifies the plugin declaration or class.
This was sent 2003-11-03. Would someone please have a look and commit it
unless there are objections?
This patch *only* affects the plugins module. It's also the
Hi,
Regarding logging in Digester; I may have found a solution that will
keep all parties happy. Let me know what you think
Currently this class exists in the plugins module to handle logging:
public class LogUtils {
public static Log getLogger(Digester digester) {
if (digester ==
On Wed, 2003-10-29 at 12:34, robert burrell donkin wrote:
On Monday, October 27, 2003, at 10:17 PM, Simon Kitching wrote:
Hi,
hi simon
i'm not totally convinced that your patch is the best possible approach
but i think that it's an improvement so i've committed it. it's pretty
much
.
*
* @author Simon Kitching
*/
public class PluginAssertionFailure extends RuntimeException {
private Throwable cause = null;
/**
* @param cause underlying exception that caused this to be thrown
*/
public PluginAssertionFailure(Throwable cause) {
this(cause.getMessage
On Tue, 2003-10-28 at 02:53, robert burrell donkin wrote:
On Sunday, October 5, 2003, at 10:53 PM, Simon Kitching wrote:
On Sun, 2003-10-05 at 00:43, robert burrell donkin wrote:
snip
3. Exception handling
PluginAssertionError extends Error. i'm not very happy about this. IMHO
On Tue, 2003-10-28 at 12:12, robert burrell donkin wrote:
On Monday, October 27, 2003, at 10:41 PM, Simon Kitching wrote:
Just a note: I'm mostly on the side of a RuntimeException-based approach
already. I just proposed an Error-based exception to ensure the issue
was debated. A shame the debate
On Wed, 2003-10-22 at 11:27, Ricky Panaglucci wrote:
hello,
is it by design, that SetPropertyRule and
SetPropertiesRule use BeanUtils.populate()?
it would be usefull to use other binders as well.
Well, the term property in the name of these rules is intended to
refer to the definition of a
On Tue, 2003-10-21 at 05:16, Craig R. McClanahan wrote:
Remy Maucherat wrote:
Hi,
I'd like to add a feature to the digester, allowing property
replacement, similar to Ant. Basically, ${...} in an attribute value
would get replaced by a property value.
And +1 from me.
Could you
Hi Kumar,
You can use the ObjectParamRule to pass literal strings (or other
objects) to methods.
There is also a PathCallParamRule class in CVS, but it was added since
the last release so you would need to download it from CVS.
Regards,
Simon
On Tue, 2003-10-21 at 03:03, Kumar Pankaj wrote:
Hi Ricky,
You must be referring to
xmlrules/DigesterRuleParser.java
I'm no expert on the xmlrules package.
However it is normal practice for classes created solely for the purpose
of implementing function X to be declared private.
The PatternRule class appears to have been created *not* with
On Tue, 2003-10-21 at 10:29, robert burrell donkin wrote:
On Sunday, October 5, 2003, at 10:53 PM, Simon Kitching wrote:
snip
Hmm .. but calling Digester.setLogger probably doesn't override the
object known to the LogFactory...
What exactly is the purpose of being able to set the Log
On Tue, 2003-10-21 at 11:26, Craig R. McClanahan wrote:
Simon Kitching wrote:
Regarding your tomcat example, I will have to have a think about this.
I'm no expert on complex container architectures, nor on Tomcat, so if
you and the Avalon team say the setLog() approach is the only way to go
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
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
On Tue, 2003-10-07 at 03:09, Jean-Francois Arcand wrote:
Simon Kitching wrote:
On Sun, 2003-10-05 at 07:26, Jean-Francois Arcand wrote:
Doesn't it really suck that there is no parser-independent way of
enabling w3c-standard xml schema support? Is everybody absolutely sure
i'm also a bit confused why PluginDeclarationRule throws
ClassNotFoundException's when require attributes are missing from the xml.
this seems a wrong to me. (i've left these for the moment since it's
easier for people to examine the code when it's in cvs.) there are also a
few
On Wed, 2003-10-01 at 17:59, Simon Kitching wrote:
Hi,
Many many moons ago, I proposed a plugins extension for digester.
It is now ready for the world [yes, yes, brave words I know :-]
Follow-up comments:
*
The package overview is accessable via this direct link:
http://issues.apache.org
Hi,
Currently the Digester unit tests include some tests which deliberately
trigger failures.
This is fine - error handling should also be tested.
Unfortunately, when an error occurs, Digester calls log.warn or
log.error, which gets printed out in the middle of the junit output.
Yecch.
I also
On Wed, 2003-10-01 at 13:06, Simon Kitching wrote:
try {
Log oldLog = digester.getLogger();
digester.setLogger(new NoOpLog());
digester.parse(
TestAll.getInputStream(this, test2.xml));
digester.setLogger(oldLog);
}
catch(Exception e) {
// yay
On Mon, 2003-09-29 at 23:18, robert burrell donkin wrote:
i think that it's important that digester retains the smallest possible
set of core dependencies. but i'd like to be able to supply users (who
need this functionality) with more exotic toys such as regular expression
based pattern
On Mon, 2003-09-29 at 22:14, robert burrell donkin wrote:
Well, I just want to note that the original reason I raised the
possibility of returning ListIterator for matches was to resolve a
problem I had with implementing a Plugins module. I have since had an
epiphany :-) and have found a
On Sun, 2003-09-28 at 21:57, robert burrell donkin wrote:
i'm in favour of adding compiling the examples as part of the tests. (it'd
be even better to have some unit tests for them, maybe as example unit
tests for newbie developers)
rationale: there's nothing worse when trying to learn a
On Mon, 2003-09-29 at 03:40, robert burrell donkin wrote:
On Saturday, September 27, 2003, at 06:43 PM, Craig R. McClanahan wrote:
Simon Kitching wrote:
Hi,
The current Rules interface defines
public List match(String uri, String patern);
This is giving me significant
Hi,
The CursorableLinkedList class returns cursors which act like
ListIterators except that they continue to work when the list is
modified via other means (unlike ListIterator which throws
ConcurrentModificationException).
Unfortunately, there is one critical difference between cursors and
Hmm .. something appears to have filtered out the attachments.
Here they are again, in .tar.gz format this time.
On Sat, 2003-09-27 at 18:07, Simon Kitching wrote:
Hi,
The CursorableLinkedList class returns cursors which act like
ListIterators except that they continue to work when the list
On Fri, 2003-09-26 at 08:11, robert burrell donkin wrote:
hi simon
committed. many thanks and keep up the good work. i'll look forward to the
next installment :)
(i still want to find a way to get maven to generate html from the source
but that'll probably need to wait a little while.)
Hi,
The current Rules interface defines
public List match(String uri, String patern);
This is giving me significant problems for the Plugins module I am
working on. I also think it is simply the wrong type to be returning
here; a List has many operations available on it which are not
Hi,
When I posted my original example of digester usage (now checked in as
digester/src/examples/api/addressbook) I promised more.
Well, attached is a proposed follow-on example entitled Catalog
(library catalog), that demonstrates:
* how to use Digester.getRoot() to retrieve the root object
On Fri, 2003-09-19 at 05:03, Rodney Waldhoff wrote:
If there are no complaints, I'd like to deprecate CursorableLinkedList for
the 3.0 collections release, to be removed in the 4.0 release.
Bugger. I was just intending to propose using this class from within
commons-digester.
It would be no
On Fri, 2003-09-19 at 09:38, Rodney Waldhoff wrote:
Since both Craig and you have expressed an interest in keeping this class
around, I'm more than happy to leave it.
Let's remove implements Serializable for the 3.0 release, unless someone
feels like making it work (probably a missing a
As a user of, rather than contributor to, lang, I agree with Stephen.
While also a Queen's English user, the convention for programming
libraries is clearly established as US English. All the java standard
libraries use this convention, so it seems inconsistent to use other
spelling elsewhere. I
Hmm..are you sure that simply relying on atomic behaviour is what you
want here?
I'm not an expert on java's memory model, but suggest you give some
serious thought before removing any synchronized keywords.
As I understand it, atomic simply means that no two threads will ever
see intermediate
with the idea of using maven to create some kind of
documentation based on the source plus html contained in the files but i
don't have the time to do this right now.
- robert
On Saturday, August 2, 2003, at 07:15 AM, Simon Kitching wrote:
Hi,
Recently there was a suggestion
Hi,
Recently there was a suggestion on the users email group that some
digester examples would be helpful.
I felt this myself when starting to use digester.
So attached is a tar file containing a (proposed) initial example.
The tar file contains the tree:
examples
api
example1
Oh bugger :- here's the attachment.
On Sat, 2003-08-02 at 18:15, Simon Kitching wrote:
Hi,
Recently there was a suggestion on the users email group that some
digester examples would be helpful.
I felt this myself when starting to use digester.
So attached is a tar file containing
On Tue, 2003-07-29 at 10:36, robert burrell donkin wrote:
On Monday, July 28, 2003, at 11:50 AM, Pavel Lisovin wrote:
To everyone,
I am trying to parse XML file to get custom objects using digester-rules
xml
file
and wondering if there is an easy way to get XPath or match pattern
Hi Robert,
From this email, I presume that your implementation of pass return
value of CallMethodRule as parameter to another CallMethodRule requires
another stack?
Can you explain why the new stack is required?
Thanks,
Simon
On Mon, 2003-07-14 at 05:08, robert burrell donkin wrote:
i've
Hmm .. an import-stuff-into-xml project? Interesting...
I have in fact written exactly this for my current employer, for a
(continuously expanding) series of formats. We then apply stylesheets to
the results, for various purposes.
I doubt I could contribute any code, but can definitely confirm
Hi All,
I would like to use digester in a framework where I have plug-in
classes; something like ant's optional tasks..
Example:
top-level
fixed-tag foo=foo
fixed-subtag bar=bar/
/fixed-tag
plugin class=com.acme.plugin1
tag-for-plugin1 baz=baz
/plugin
choice.
- robert
On Sunday, May 12, 2002, at 11:48 PM, Simon Kitching wrote:
I have been using digester with java1.4 quite happily.
I now need to deploy the app on java1.3; I expected to have to place a
suitable xml parser implementation in the classpath.
However, it appears that Digester needs
compatibility
don't provide all the methods :-(
Cheers,
Simon
-Original Message-
From: Simon Kitching [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, May 14, 2002 11:05 AM
To: 'Jakarta Commons Developers List'
Subject: RE: digester needs SAXParser.getXMLReader
Robert, thanks for taking
Oh Damn, I'm wrong wrong wrong.
Robert, looks like you were right: there *is* an old JAXP implementation
in my path - it's java130/jre/lib/ext/xerces.jar (!)
Much to my surprise:
(a) the command javap -classpath xxx.jar javax.xml.parsers.SAXParser
looks *first* in the java distribution, and
701 - 787 of 787 matches
Mail list logo
