commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chad Woolley <li...@thewoolleyweb.com>
Subject Re: Digester / BeanUtils - No Such Accessible Method error
Date Fri, 13 Feb 2004 03:13:47 GMT
Simon,

Thanks for the response.  I'm taking a step back from this problem, and 
wondering if I should even be using Digester, rather than just manually 
writing my own parser:

1. I am only parsing a configuration file, so it is not likely to ever 
become very complex, and it's currently very simple.

2. My application is a framework, so by using Digester I am requiring 
the end user to have a few additional dependent jars on their classpath.

3. I could probably write a Sax parser for my existing functionality in 
the time it would take me to debug this Digester problem.

I think Digester would be great if I was going to parse multiple files, 
or more complex files, or if my application was a standalone app.  I 
also don't regret learning it, I'm sure it will come in useful in the 
future.

However, I think I'm going to gently shelve it for now and get out my 
Sax instead.  Any input on my decision is welcome.

Again, thank you very much for the response and offer for help.  I'll 
remain subscribed to this list, maybe in the future I can help someone 
and get a bit of good karma.

Thanks,
Chad



Simon Kitching wrote:
> On Fri, 2004-02-13 at 09:32, Chad Woolley wrote:
> 
>>Hello,
>>
>>I never got any bites on this, so here it is again with all the info in 
>>one place.
>>
>>I'd really like to resolve this, as it is preventing me from using 
>>Digester.  I guess I should try to write a failing unit test for it and 
>>submit it as a bug, but I'm not sure whether it is a problem with 
>>BeanUtils or Digester.  It really appears to be the JDK 
>>Method.getParameterTypes() that is behaving incorrectly, but that seems 
>>unlikely, it is probably some issue with another tool or my environment.
> 
> 
> If you can provide a simple test case that demonstrates the problem I
> would be happy to have a look at it (at least as far as the Digester
> part of the problem goes). However I am a fairly heavy user of Digester,
> and am not aware of any bugs that may cause this, so I would not have a
> clue where to start to duplicate the problem myself. 
> 
> I presume the code you included in your previous email is runnable
> "stand-alone"? If you directly email me the source code files I will
> give them a spin.
> 
> Have you tried enabling digester log output and checking that the right
> objects are being generated on the stack? Digester uses commons-logging,
> so for example putting a log4j.xml file in the classpath can be used to
> configure the logging. That will probably be my first step..
> 
> 
>> > Both the parent and child objects on the stack when I call 
>>Digester.addSetNext() are plain public java objects, with no 
>>superclasses, and all public methods.
> 
> 
> That sounds like it all should work.
> 
> 
>>>Here is the XML:
>>>
>>><?xml version="1.0" encoding="UTF-8"?>
>>><virtualmock xmlns="http://www.virtualmock.org/virtualmock.xsd">
>>>    <excluded-classes>
>>>        <exclusion-pattern>test.*</exclusion-pattern>
>>>    </excluded-classes>
>>>    <rules>
>>>        <rule>
>>>            
>>><rule-type>org.virtualmock.rule.AllRecordedCallsMustBeInvokedRule</rule-type>

>>>
>>>        </rule>
>>>    </rules>
>>></virtualmock>
>>>
>>>-------------------------------------
>>>
>>>Here is the Digester:
>>>
>>>        vmConfig = new VMConfig();
>>>
>>>        digester.push(vmConfig);
>>>        digester.setValidating(validate);
>>>
>>>        
>>>digester.addCallMethod("virtualmock/excluded-classes/exclusion-pattern",
>>>            "addClassExclusionPattern", 0);
>>>
>>>        digester.addObjectCreate("virtualmock/rules/rule", 
>>>RuleConfig.class);
>>>        digester.addBeanPropertySetter("virtualmock/rules/rule/rule-type",
>>>            "ruleType");
>>>        digester.addSetNext("virtualmock/rules/rule", "addRuleConfig", 
>>>"org.virtualmock.configuration.RuleConfig");
>>>
>>>        try {
>>>            digester.parse(inputStream);
>>>        } catch (SAXException saxException) {
>>>
>>>-------------------------------------
>>>
>>>Here is the Parent object:
>>>
>>>public class VMConfig {
>>>    private List classExclusionPatterns = null;
>>>    private List ruleConfigs = null;
>>>
>>>    public VMConfig() {
>>>        classExclusionPatterns = new ArrayList();
>>>        ruleConfigs = new ArrayList();
>>>    }
>>>
>>>    public List getClassExclusionPatterns() {
>>>        return classExclusionPatterns;
>>>    }
>>>
>>>    public List getRuleConfigs() {
>>>        return ruleConfigs;
>>>    }
>>>
>>>    public void addClassExclusionPattern(String classExclusionPattern) {
>>>        classExclusionPatterns.add(classExclusionPattern);
>>>    }
>>>
>>>    public void addRuleConfig(RuleConfig ruleConfig) {
>>>        ruleConfigs.add(ruleConfig);
>>>    }
>>>}
>>>
>>>-------------------------------------
>>>
>>>Here is the Child object:
>>>
>>>public class RuleConfig {
>>>    private String ruleType = null;
>>>
>>>    public void setRuleType(String ruleType) {
>>>        this.ruleType = ruleType;
>>>    }
>>>
>>>    public String getRuleType() {
>>>        return ruleType;
>>>    }
>>>
>>>    public RuleConfig() {
>>>        super();
>>>    }
>>>
>>>}
>>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: commons-user-help@jakarta.apache.org
>>
>>
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org


Mime
View raw message