cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Turner <je...@apache.org>
Subject Re: input module stopped working
Date Tue, 20 May 2003 12:54:46 GMT
On Mon, May 19, 2003 at 02:11:22PM +0100, Jeremy Quinn wrote:
> 
> On Monday, May 19, 2003, at 01:23 AM, Jeff Turner wrote:
> 
> >Jeremy Quinn wrote:
> >...
> >>I still get an error (but the samples still work), but this time it  
> >>is  an NPF:
> >>java.lang.NullPointerException
> >>    at   
> >>org.apache.cocoon.components.modules.input.XMLFileModule.getContextObj 
> >>ec t(XMLFileModule.java:284)

Well, I finally got a chance to properly replicate the problem, and fixed
the problem about 5 mins after the M2 tag was made ;(  Sorry you've been
the guinea-pig in all this.

Anyway, you can still get your configuration working with M2, by
changing this:

  <component-instance
    class="org.apache.cocoon.components.modules.input.ChainMetaModule"
    logger="core.modules.input" name="iniva">
    <input-module name="request-param"/>
    <input-module name="simplemap">
      <prefix>/vars/</prefix>
      <input-module name="iniva-conf"/>
    </input-module>
  </component-instance>

to:

  <component-instance
    class="org.apache.cocoon.components.modules.input.ChainMetaModule"
    logger="core.modules.input" name="iniva">
    <input-module name="request-param"/>
    <input-module name="simplemap">
      <prefix>/vars/</prefix>
      <input-module name="iniva-conf">
        <file src="cocoon://iniva/xconf"/>      <-- Extra element -->
      </input-module>
    </input-module>
  </component-instance>

> Has something changed in the way we are supposed to set up custom input  
> modules?

Not really, just overzealous error checking without understanding all
use-cases.  Take yours:

  <component-instance
    class="org.apache.cocoon.components.modules.input.XMLFileModule"
    logger="core.modules.xml" name="iniva-conf">
    <file src="cocoon://iniva/xconf"/>
  </component-instance>

  <component-instance
    class="org.apache.cocoon.components.modules.input.ChainMetaModule"
    logger="core.modules.input" name="iniva">
    <input-module name="request-param"/>
    <input-module name="simplemap">
      <prefix>/vars/</prefix>
      <input-module name="iniva-conf"/>
    </input-module>
  </component-instance>

As you may know, input modules are configured statically (at startup
time) in the configure() method, and then additionally, may be
(re)configured dynamically (at runtime) via the modeConf argument to the
various methods.

In the above config, 'iniva-conf' is configured statically with
Configuration:

<...>
    <file src="cocoon://iniva/xconf"/>
</...>

and then reconfigured dynamically when used inside the 'simplemap', with
Configuration:

<.../>

(because the <input-module name="iniva-conf"/> element has no body)

The XMLFileModule code assumed that a non-null dynamic Configuration
ought to have at least a <file src="..."/> nested element.  Otherwise
there's no point, and the user has likely made a mistake (read: I spent a
few days _making_ this mistake and getting silent failures:).  So there
is an explicit check for <file>, which is what blew up your
configuration.

This suggests the workaround for M2: simply duplicate the <file>
configuration element.

I think the correct fix is to keep the <file> check, and to make
SimpleMappingMetaModule smarter, to not reconfigure host modules with
empty Configurations.

Ugh.  We really need typed Configurations in Avalon.  It would make
hundreds of API contracts stronger, and allow better error reporting.


--Jeff

> regards Jeremy
> 

Mime
View raw message