commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "BRABANT Benjamin (JIRA)" <>
Subject [jira] [Updated] (DIGESTER-176) [Digester] Problem when adding multiple FactoryCreateRule for the same pattern
Date Mon, 17 Jun 2013 06:01:23 GMT


BRABANT Benjamin updated DIGESTER-176:

    Attachment: OverrideFactoryCreateTestCase.patch

Patch containing the failing TestCase. Note that the problem I initially try to highlight
is showing by the assert {{Attribute Override Failed (4)}}, but writing the test, I also obtained
a fail for the assert {{Attribute not passed (19)[true]}}
> [Digester] Problem when adding multiple FactoryCreateRule for the same pattern
> ------------------------------------------------------------------------------
>                 Key: DIGESTER-176
>                 URL:
>             Project: Commons Digester
>          Issue Type: Bug
>    Affects Versions: 3.2
>         Environment: Operating System : Windows 7 x32 bits
>            Reporter: BRABANT Benjamin
>            Priority: Minor
>         Attachments: OverrideFactoryCreateTestCase.patch
> Hello,
> I actually use digester API in a project in which I have to initialize components of
a system according to an XML configuration. The complete ClassName of the factories in charge
of loading the associated components is specified in the configuration file (hereinbelow a
simplified example). Thus, the loader class in charge of loading components, read the XML
file and, thanks to the {{overriddenByAttribute(String attributeName)}} function provided
by the {{FactoryCreateBuilder}} class, execute the right factory method specified by the XML
"factory" attribute.
> A problem appeared when I try to load several components of the same type (=> same
XML pattern) which are initialized from different factories (below the sample to illustrate
the description !).
> *XML Config File :*
> {code:xml}
> <loader>
>   <components>
>     <collectors>
>       <collector id="collector" class="" factory=""
/> <!-- The first collector component to load -->
>       <collector id="command" class="" factory=""
/> <!-- The second collector component to load -->
>     </collectors>
>     <analyzers>
>       <analyzer id="analyzer" class="foo.baz.DefaultAnalyzer" factory="foo.baz.DefaultAnalyzerFactory"
/> <!-- The only analyzer component to load -->
>     </analyzers>
>   </components>
> </loader>
> {code}
> *AbstractRulesModule Implementation :*
> {|borderStyle=solid}
> package foo;
> import org.apache.commons.digester3.binder.AbstractRulesModule;
> public class LoaderConfigurationModule extends AbstractRulesModule {
> 	\@Override
> 	protected void configure() \{
> 		forPattern("loader/components/collectors/collector")
> 				.factoryCreate().ofType(AbstractCollectorFactory.class).overriddenByAttribute("factory")
> 				.setNext("addCollector");
> 		forPattern("loader/components/analyzers/analyzer")
> 				.factoryCreate().ofType(AbstractAnalyzerFactory.class).overriddenByAttribute("factory")
> 				.setNext("addAnalyzer");
> 	\}
> }
> {code}
> When I execute the Digester.parse() method (after passing on the LoaderConfigurationModule
to the DigesterLoader), I obtain the result below :
> {noformat}
> 2013-06-10 [main] INFO  - Loading Collector [class]...
> 2013-06-10 [main] INFO  - Loading Collector [class]...
> 2013-06-10 [main] INFO  - Loading Analyzer [class foo.baz.DefaultAnalyzer]...
> {noformat} 
> In fact, when having the same pattern (here _loader/components/collectors/collector_)
for multiple creation factories, the digester only use the first instance for the pattern
(in this case]. We realize that the Analyzer which is associated
with another pattern is correctly initialized.
> I hope being clear in my explanation, thus I would like you (please :) ) to explain me
if I am doing a mistake in my code or if it's really a bug in the digester and if you have
an idea to solve that. I am trying to find a solution too, but being new in this project,
it is not very easy for me. I will post my find in case of success in my search !
> Thanks for reading and sorry for my bad english !
> EDIT [17/06/2013] : I attached the patch adding the failing TestCase

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

View raw message