Fwd: Multiple comp_root bug (extra ARG)

(This is the same message I submitted a few days ago to mason users 
list, wishing at least for some hints on how to overcome this bug)


There's an ancient bug in HTML::Mason that I for one hate very much, but
never had the chance to hunt it down. So, let me share it once again,
maybe anyone comes up with some ideas about what traps should I setup
so I could catch and kill this little beast. TIA ;-)

The software version doesn't matter, it happened with H/M 0.8x,
it still happens with 1.31 (same thing with perl versions, both stable
and devel)

The filesystem layout:
    /web
      /foo           : vhost
      ....           : --"--
      /shared        : shared components

Configuration:
    Apache 1, mod_perl builtin, libapreq 1 etc.
    Each vhost gets its own ApacheHandler, data_directory, etc, and uses
    a multiple component root system like this:
      comp_root => [
          [ private => $r->document_root ],
          [ shared  => '/web/shared'     ], # the SECOND, remember this
      ]

Let's make a (hopefully) self explanatory shared component:
%# BOF: /web/shared/echo
<%flags>
	inherit => undef
</%flags>
<%once>
	use Data::Dumper ();
</%once>
<%init>
    local $Data::Dumper::Indent = 1;
    local $Data::Dumper::Sortkeys = 1;
    local $Data::Dumper::Terse = 1;

    $m->clear_buffer;
    $r->content_type('text/plain; charset=UTF-8');
    $m->print(Data::Dumper::Dumper(\%ARGS));
    $m->abort;
</%init>
%# EOF: /web/shared/echo

Let's test it with some args:

$ GET -Pu 'http://foo/echo?bar=foo;echo=yes'
GET http://foo/echo?bar=foo;echo=yes
{
    'bar' => 'foo',
    'echo' => 'yes'
}

Everything OK up to this point. Please notice the name of the component
('echo') and the presence of an argument with the same name ('echo' again).

Let's move now this test component to the "proper" directory:
$ mkdir /web/shared/tests/
$ mv /web/shared/echo /web/shared/tests/

Let's repeat the first test:

$ GET -Pu 'http://foo/tests/echo?bar=foo;echo=yes'
GET http://foo/tests/echo?bar=foo;echo=yes
{
    'bar' => 'foo',
    'echo' => undef
}

Wrong! The beast appeared, ate our 'echo' argument and provided us
another undefined one :(

One more test for conformity. Let's duplicate this "echo" component
into a "bravo" one, in the same "testing" area:
$ ln -s echo /web/shared/tests/bravo
$ GET -Pu 'http://foo/tests/zecho?bar=foo;echo=yes'
GET http://foo/tests/zecho?bar=foo;echo=yes
{
    'bar' => 'foo',
    'echo' => 'yes',
    'zecho' => undef
}

OK, so this beast seems to work like this:
- appears only when called for secondary comp_root components, and only
when it is not a top level component
- provides an undefined extra ARGS with the same name as the base
component, overriding the previous possible value

AFAIR, there's also a similar side effect on dhandlers too, but I'll
do more digging in my backlogs another time. :(

Thanks again for your patience and hopefully a skilled hunter will
bring this beast down for the rest of us. ;-)

-- 
Marius Feraru