You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by "Philippe M. Chiasson" <go...@cpan.org> on 2003/12/09 21:04:27 UTC
[Patch mp2] PerlSections namespace
It's been a long time that perl sections have been having trouble with
recursive inclusion. This has been discussed before and has to do with
the fact that all PerlSections are evaluated in the same namespace
Apache::ReadSections.
The following patch follows a similar design than ModPerl::Registry,
putting each <Perl> block in it's own namespace, based on filename &
lineno.
This now prevents infinite-recursion problems and makes $Includes from
within <Perl> sections work fine.
There is still one little problem left with this, people will not be
able to put stuff directly in the Apache::ReadSections namespace
themselves. I do have a plan for fixing that as well in a subsequent
patch.
As usual, look at it and tell me if it breaks more stuff than it fixes
;-)
I had to introduce a function in mod_perl_util.c, modperl_file2package,
that makes a package-safe name from a filepath, so maybe it could be
exposed and used by ModPerl::Registry as well?
Index: todo/release
===================================================================
RCS file: /home/cvs/modperl-2.0/todo/release,v
retrieving revision 1.5
diff -u -I$Id: -r1.5 release
--- todo/release 1 Dec 2003 19:11:19 -0000 1.5
+++ todo/release 9 Dec 2003 19:34:34 -0000
@@ -27,11 +27,6 @@
A few issues with <Perl> sections:
http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=106074969831522&w=2
-* Recursive <Perl> sections:
- http://www.gossamer-threads.com/archive/mod_perl_C1/dev_F4/%5BMP2_-_BUG_%5D_Issue_handing_Apache_config._error_messages_P70501/
- and
- http://mathforum.org/epigone/modperl/dartrimpcil
-
* Fixing Apache->warn("foo")
Report: http://mathforum.org/epigone/modperl-dev/noxtramcay/3D11A4E5.6010202@stason.org
Index: t/conf/extra.last.conf.in
===================================================================
RCS file: /home/cvs/modperl-2.0/t/conf/extra.last.conf.in,v
retrieving revision 1.9
diff -u -I$Id: -r1.9 extra.last.conf.in
--- t/conf/extra.last.conf.in 17 Nov 2003 01:11:06 -0000 1.9
+++ t/conf/extra.last.conf.in 9 Dec 2003 19:34:34 -0000
@@ -19,6 +19,7 @@
};
#This is a comment
$TestDirective::perl::comments="yes";
+$TestDirective::perl::PACKAGE = __PACKAGE__;
</Perl>
<Perl >
@@ -26,6 +27,10 @@
$TestDirective::perl::filename = __FILE__;
$TestDirective::perl::dollar_zero = $0;
$TestDirective::perl::line = __LINE__;
+</Perl>
+
+<Perl >
+$Include = "@ServerRoot@/conf/perlsection.conf";
</Perl>
### --------------------------------- ###
Index: t/conf/perlsection.conf
===================================================================
RCS file: t/conf/perlsection.conf
diff -N t/conf/perlsection.conf
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ t/conf/perlsection.conf 9 Dec 2003 19:34:34 -0000
@@ -0,0 +1,3 @@
+<Perl >
+$TestDirective::perl::Included++;
+</Perl>
Index: t/response/TestDirective/perldo.pm
===================================================================
RCS file: /home/cvs/modperl-2.0/t/response/TestDirective/perldo.pm,v
retrieving revision 1.5
diff -u -I$Id: -r1.5 perldo.pm
--- t/response/TestDirective/perldo.pm 17 Nov 2003 01:11:06 -0000 1.5
+++ t/response/TestDirective/perldo.pm 9 Dec 2003 19:34:34 -0000
@@ -10,15 +10,21 @@
sub handler {
my $r = shift;
- plan $r, tests => 9;
+ plan $r, tests => 11;
ok t_cmp('yes', $TestDirective::perl::worked);
- ok not exists $Apache::ReadConfig::Location{'/perl_sections'};
+ ok t_cmp(qr/extra_last_conf::line_\d+$/, $TestDirective::perl::PACKAGE, '__PACKAGE__');
- ok exists $Apache::ReadConfig::Location{'/perl_sections_saved'};
-
- ok t_cmp('PerlSection', $Apache::ReadConfig::Location{'/perl_sections_saved'}{'AuthName'});
+ my %Location;
+ {
+ no strict 'refs';
+ %Location = %{$TestDirective::perl::PACKAGE . '::Location'};
+ }
+
+ ok not exists $Location{'/perl_sections'};
+ ok exists $Location{'/perl_sections_saved'};
+ ok t_cmp('PerlSection', $Location{'/perl_sections_saved'}{'AuthName'});
ok t_cmp('yes', $TestDirective::perl::comments);
@@ -29,6 +35,8 @@
ok $TestDirective::perl::line > 3;
ok t_cmp("-e", $0, '$0');
+
+ ok t_cmp(1, $TestDirective::perl::Included, "Include");
Apache::OK;
}
Index: src/modules/perl/modperl_cmd.c
===================================================================
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_cmd.c,v
retrieving revision 1.51
diff -u -I$Id: -r1.51 modperl_cmd.c
--- src/modules/perl/modperl_cmd.c 17 Nov 2003 01:11:06 -0000 1.51
+++ src/modules/perl/modperl_cmd.c 9 Dec 2003 19:34:34 -0000
@@ -399,8 +399,18 @@
if (!(package_name = apr_table_get(options, "package"))) {
package_name = apr_pstrdup(p, MP_DEFAULT_PERLSECTION_PACKAGE);
- apr_table_set(options, "package", package_name);
}
+
+ package_name = modperl_section2package(p, package_name,
+ parms->directive->filename,
+ parms->directive->line_num);
+
+ apr_table_set(options, "package", package_name);
+
+ MP_TRACE_s(MP_FUNC, "PerlSection from file=%s, line=%d placed in %s\n",
+ parms->directive->filename,
+ parms->directive->line_num,
+ package_name);
line_header = apr_psprintf(p, "\n#line %d %s\n",
parms->directive->line_num,
Index: src/modules/perl/modperl_util.c
===================================================================
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_util.c,v
retrieving revision 1.58
diff -u -I$Id: -r1.58 modperl_util.c
--- src/modules/perl/modperl_util.c 25 Nov 2003 20:31:29 -0000 1.58
+++ src/modules/perl/modperl_util.c 9 Dec 2003 19:34:34 -0000
@@ -769,3 +769,45 @@
}
}
#endif
+
+#define MP_VALID_PKG_CHAR(c) (isalnum(c)||c==':'||c=='_')
+static const char *modperl_file2package(apr_pool_t *p, const char *file)
+{
+ char *package;
+ char *c;
+
+ c = package = apr_pcalloc(p, strlen(file));
+
+ /* First, skip invalid prefix characters */
+ while (!MP_VALID_PKG_CHAR(*file)) {
+ file++;
+ }
+
+ /* Then, replace bad characters with '_' */
+ while (*file) {
+ if (MP_VALID_PKG_CHAR(*file)) {
+ *c = *file;
+ }
+ else {
+ /* Replace many bad characters with only one '_' */
+ while (*(file+1) && !MP_VALID_PKG_CHAR(*(file+1))) {
+ file++;
+ }
+
+ *c = '_';
+ }
+
+ c++;
+ file++;
+ }
+
+ return package;
+}
+
+const char *modperl_section2package(apr_pool_t *p, const char *namespace, const char *filename, int lineno)
+{
+ return apr_psprintf(p, "%s::%s::line_%d", namespace, modperl_file2package(p, filename), lineno);
+}
+
+
+
Index: src/modules/perl/modperl_util.h
===================================================================
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_util.h,v
retrieving revision 1.48
diff -u -I$Id: -r1.48 modperl_util.h
--- src/modules/perl/modperl_util.h 22 Sep 2003 23:46:19 -0000 1.48
+++ src/modules/perl/modperl_util.h 9 Dec 2003 19:34:34 -0000
@@ -159,4 +159,6 @@
void modperl_apr_table_dump(pTHX_ apr_table_t *table, char *name);
#endif
+const char *modperl_section2package(apr_pool_t *p, const char *namespace, const char *filename, int lineno);
+
#endif /* MODPERL_UTIL_H */
--
--------------------------------------------------------------------------------
Philippe M. Chiasson /gozer\@(cpan|ectoplasm)\.org/ 88C3A5A5 (122FF51B/C634E37B)
http://gozer.ectoplasm.org/ F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3 A5A5
Q: It is impossible to make anything foolproof because fools are so ingenious.
perl -e'$$=\${gozer};{$_=unpack(P7,pack(L,$$));/^JAm_pH\n$/&&print||$$++&&redo}'
Re: [Patch mp2] PerlSections namespace
Posted by "Philippe M. Chiasson" <go...@cpan.org>.
On Wed, 2003-12-10 at 12:53, Geoffrey Young wrote:
> >>package Apache::Foo;
> >>$Apache::ReadConfig::PerlFixupHandler = "Apache::Foo";
> >>sub handler { };
> >>
> >>now, PerlModule Apache::Foo automatically installs a PerlFixupHandler :)
> >>there are a few modules on CPAN that do this, IIRC.
> >
> >
> > Yes, but this has always been partially broken as it is.
> >
> > For example:
> >
> > package Apache::Foo;
> > $Apache::ReadConfig::Alias = qw(/some/path /some/alias);
> >
> >
> > If you only do :
> >
> > PerlModule Apache::Foo
> >
> > and have no <Perl> sections in your httpd.conf, that code will not
> > happen
>
> really? I'll have to check that :)
>
> >
> > If you have more than one <Perl> section, you'll get warnings about
> > re-defining an Alias directive for the same location, as the content of
> > Apache::ReadConfig:: will be read and processed for every <Perl> block.
>
> ugh, that's bad.
Yes, and when someone reported that problem in mp2, I thought I could
look at mp1 to see how that problem was avoided, but it wasn't. When I
ported <Perl> sections from mp1 to mp2, I sadly ported a lot of existing
problems/bugs as well ;-p
Time to fix it all, I guess.
> >
> >
> >
> >>it's similar to Apache->server->add_config() in mp2, but I've found that
> >>method really not worth the trouble - it's goverened by overrides, so you
> >>can never really trust that it will add the configuration data you pipe into it.
> >
> >
> > Can you give me one such example ?
>
> as I mentioned in reply to stas, add_config is equivalent to .htaccess files
> - so wherever .htaccess files are disallowed, so are add_config() additions.
Really? That's not quite DWIMy, isn't it? I would have thought
differently. That would be a bit sucky.
It's strange though, because <Perl> sections (and processing of
Apache::ReadConfig is dont thru add_config I believe).
Are you sure about this ?
> --Geoff
--
--------------------------------------------------------------------------------
Philippe M. Chiasson /gozer\@(cpan|ectoplasm)\.org/ 88C3A5A5 (122FF51B/C634E37B)
http://gozer.ectoplasm.org/ F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3 A5A5
Q: It is impossible to make anything foolproof because fools are so ingenious.
perl -e'$$=\${gozer};{$_=unpack(P7,pack(L,$$));/^JAm_pH\n$/&&print||$$++&&redo}'
Re: [Patch mp2] PerlSections namespace
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
>>package Apache::Foo;
>>$Apache::ReadConfig::PerlFixupHandler = "Apache::Foo";
>>sub handler { };
>>
>>now, PerlModule Apache::Foo automatically installs a PerlFixupHandler :)
>>there are a few modules on CPAN that do this, IIRC.
>
>
> Yes, but this has always been partially broken as it is.
>
> For example:
>
> package Apache::Foo;
> $Apache::ReadConfig::Alias = qw(/some/path /some/alias);
>
>
> If you only do :
>
> PerlModule Apache::Foo
>
> and have no <Perl> sections in your httpd.conf, that code will not
> happen
really? I'll have to check that :)
>
> If you have more than one <Perl> section, you'll get warnings about
> re-defining an Alias directive for the same location, as the content of
> Apache::ReadConfig:: will be read and processed for every <Perl> block.
ugh, that's bad.
>
>
>
>>it's similar to Apache->server->add_config() in mp2, but I've found that
>>method really not worth the trouble - it's goverened by overrides, so you
>>can never really trust that it will add the configuration data you pipe into it.
>
>
> Can you give me one such example ?
as I mentioned in reply to stas, add_config is equivalent to .htaccess files
- so wherever .htaccess files are disallowed, so are add_config() additions.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [Patch mp2] PerlSections namespace
Posted by "Philippe M. Chiasson" <go...@cpan.org>.
On Wed, 2003-12-10 at 11:51, Geoffrey Young wrote:
> > Am I
> > correct to say that people don't need to work directly with
> > Apache::ReadConfig? I think the only place this is needed when people
> > mix config with non-config perl code in <Perl>, so that they need to
> > switch 'package Apache::ReadConfig;' to start feeding things into the
> > config.
>
> no, you can also add entries directly to the Apache::ReadConfig namespace in
> order to add configuration data.
>
> package Apache::Foo;
> $Apache::ReadConfig::PerlFixupHandler = "Apache::Foo";
> sub handler { };
>
> now, PerlModule Apache::Foo automatically installs a PerlFixupHandler :)
> there are a few modules on CPAN that do this, IIRC.
Yes, but this has always been partially broken as it is.
For example:
package Apache::Foo;
$Apache::ReadConfig::Alias = qw(/some/path /some/alias);
If you only do :
PerlModule Apache::Foo
and have no <Perl> sections in your httpd.conf, that code will not
happen
If you have more than one <Perl> section, you'll get warnings about
re-defining an Alias directive for the same location, as the content of
Apache::ReadConfig:: will be read and processed for every <Perl> block.
> it's similar to Apache->server->add_config() in mp2, but I've found that
> method really not worth the trouble - it's goverened by overrides, so you
> can never really trust that it will add the configuration data you pipe into it.
Can you give me one such example ?
I can imagine a <Perl> section in a <virtualhost> block might not (yet)
have access to the right Apache::Server object to add it's configuration
to... Is that what you mean ?
> --Geoff
>
>
--
--------------------------------------------------------------------------------
Philippe M. Chiasson /gozer\@(cpan|ectoplasm)\.org/ 88C3A5A5 (122FF51B/C634E37B)
http://gozer.ectoplasm.org/ F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3 A5A5
Q: It is impossible to make anything foolproof because fools are so ingenious.
perl -e'$$=\${gozer};{$_=unpack(P7,pack(L,$$));/^JAm_pH\n$/&&print||$$++&&redo}'
Re: [Patch mp2] PerlSections namespace
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
>> especially when you take in to account that extra steps are needed for
>> when
>> ordering is important (like rewrite rules).
>
>
> True. One needs to use Tie::IxHash for this purpose.
or Tie::DxHash, depending on the complexity of what you need to accomplish.
it's very messy.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [Patch mp2] PerlSections namespace
Posted by Stas Bekman <st...@stason.org>.
Philippe M. Chiasson wrote:
[...]
> I'll put this thread in todo/ and push it on my stack ;-)
I hope you won't call detach() on it ;)
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [Patch mp2] PerlSections namespace
Posted by "Philippe M. Chiasson" <go...@cpan.org>.
On Thu, 2003-12-11 at 11:01, Stas Bekman wrote:
> > Yes, and I am planning on writing 2 subclasses to Apache::PerlSections
> > to handle either a namespace name, or a hash ref, as in:
> >
> > package My::Config;
> > $Location{'/foo'} = { [...] };
> > @Alias = qw(/this /that);
> > and
> > Apache::PerlSection->add_namespace("My::Config");
> >
> > or
> >
> > my %My::Config = (
> > 'Location' => { '/foo' => { [...]}},
> > 'Alias' => qw(/this /that),
> > );
> > and
> > Apache::PerlSection->add_hash(\%My::Config);
>
> ah, it can be an array or a scalar too, so a more generic name would be a
> better choice, I believe. just call it add()? or add_var()?
>
> Also if you prototype add() to accept an SV, you won't need to pass a
> reference, which is confusing in the case of a scalar.
Yes, I do like the sound of Apache::perlSection->add_[type]()
> In which case we may want to provide an equivalent to add_config() as well.
> Since they all add config. e.g. have:
>
> Apache::PerlSection->add_namespace("My::Config");
> Apache::PerlSection->add_string("User $foo");
> my %hash = ...;
> Apache::PerlSection->add(%hash);
Might as well accept this as well:
Apache::PerlSection->add_glob(\*My::Config);
> notice that add_string is exactly the same as $s->add_config.
I'll put this thread in todo/ and push it on my stack ;-)
> __________________________________________________________________
> Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
> http://stason.org/ mod_perl Guide ---> http://perl.apache.org
> mailto:stas@stason.org http://use.perl.org http://apacheweek.com
> http://modperlbook.org http://apache.org http://ticketmaster.com
--
--------------------------------------------------------------------------------
Philippe M. Chiasson /gozer\@(cpan|ectoplasm)\.org/ 88C3A5A5 (122FF51B/C634E37B)
http://gozer.ectoplasm.org/ F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3 A5A5
Q: It is impossible to make anything foolproof because fools are so ingenious.
perl -e'$$=\${gozer};{$_=unpack(P7,pack(L,$$));/^JAm_pH\n$/&&print||$$++&&redo}'
Re: [Patch mp2] PerlSections namespace
Posted by Stas Bekman <st...@stason.org>.
> Yes, and I am planning on writing 2 subclasses to Apache::PerlSections
> to handle either a namespace name, or a hash ref, as in:
>
> package My::Config;
> $Location{'/foo'} = { [...] };
> @Alias = qw(/this /that);
> and
> Apache::PerlSection->add_namespace("My::Config");
>
> or
>
> my %My::Config = (
> 'Location' => { '/foo' => { [...]}},
> 'Alias' => qw(/this /that),
> );
> and
> Apache::PerlSection->add_hash(\%My::Config);
ah, it can be an array or a scalar too, so a more generic name would be a
better choice, I believe. just call it add()? or add_var()?
Also if you prototype add() to accept an SV, you won't need to pass a
reference, which is confusing in the case of a scalar.
In which case we may want to provide an equivalent to add_config() as well.
Since they all add config. e.g. have:
Apache::PerlSection->add_namespace("My::Config");
Apache::PerlSection->add_string("User $foo");
my %hash = ...;
Apache::PerlSection->add(%hash);
notice that add_string is exactly the same as $s->add_config.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [Patch mp2] PerlSections namespace
Posted by Stas Bekman <st...@stason.org>.
Philippe M. Chiasson wrote:
[...]
> Yes, and I am planning on writing 2 subclasses to Apache::PerlSections
> to handle either a namespace name, or a hash ref, as in:
>
> package My::Config;
> $Location{'/foo'} = { [...] };
> @Alias = qw(/this /that);
> and
> Apache::PerlSection->add_namespace("My::Config");
>
> or
>
> my %My::Config = (
> 'Location' => { '/foo' => { [...]}},
> 'Alias' => qw(/this /that),
> );
> and
> Apache::PerlSection->add_hash(\%My::Config);
>
>
> So, in the end, we can have it all ;-) (method names subject to change
> though)
yay, beautiful! gozer++
and then we will deprecate Apache::ReadConfig on its own.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [Patch mp2] PerlSections namespace
Posted by "Philippe M. Chiasson" <go...@cpan.org>.
On Thu, 2003-12-11 at 10:11, Stas Bekman wrote:
> Geoffrey Young wrote:
> >
> > Stas Bekman wrote:
> >
> >>Philippe M. Chiasson wrote:
> >>
> >>
> >>>>so maybe at startup it's not a bad idea after all :)
> >>>
> >>>
> >>>
> >>>So, does this mean that you don't have a specific objection against
> >>>deprecating (or tossing) direct access to %Apache::ReadConfig:: in the
> >>>future in favor of ->add_config("User foo") ?
> >>
> >>
> >>The problem with add_config() is that it wants a string as if you've
> >>written it in httpd.conf language. Taking an access to
> >>%Apache::ReadConfig:: away takes away the ability to use perl structs to
> >>autovivify complex constructs. e.g. how do you build a complex vhost
> >>with nested containers using add_config?
> >
> >
> > well, it might be different than it was, but I guess it ends up being
> > similar to Apache->httpd_conf
>
> Yup
> http://perl.apache.org/docs/2.0/user/porting/compat.html#C_Apache_E_gt_httpd_conf_
> (and I have a typo in it, will fix shortly)
>
> > Apache->server->add_config([ <<END ]);
> > <VirtualHost $vhost>
> > ServerName $name
> > ServerAlias $alias
> > </VirtualHost>
> > END
> >
> > in truth, now that I look at it, I'm not sure that's any more or less
> > difficult or flexible than
> >
> > %directives = (
> >
> > ServerName => $name,
> > ServerAlias => $alias,
> > );
> >
> > $VirtualHost{$vhost} = \%directives;
>
> but that's a simple example. If you want to have more complex config and if
> you have some engine that generates each component separately it's going to be
> harder to put them together. It's just so intuitive to use perl structs for
> that purpose.
Yes, and I am planning on writing 2 subclasses to Apache::PerlSections
to handle either a namespace name, or a hash ref, as in:
package My::Config;
$Location{'/foo'} = { [...] };
@Alias = qw(/this /that);
and
Apache::PerlSection->add_namespace("My::Config");
or
my %My::Config = (
'Location' => { '/foo' => { [...]}},
'Alias' => qw(/this /that),
);
and
Apache::PerlSection->add_hash(\%My::Config);
So, in the end, we can have it all ;-) (method names subject to change
though)
> > especially when you take in to account that extra steps are needed for when
> > ordering is important (like rewrite rules).
>
> True. One needs to use Tie::IxHash for this purpose.
Yes, I am aware of this problem, and will be fixing it as well.
> >>may be we could have an alternative method, accepting an SV (e.g. a hash
> >>ref which represents a container) which perl will then convert to a
> >>string and feed to add_config?
> >
> >
> > I suppose that could work too.
See above examples.
> Cool.
--
--------------------------------------------------------------------------------
Philippe M. Chiasson /gozer\@(cpan|ectoplasm)\.org/ 88C3A5A5 (122FF51B/C634E37B)
http://gozer.ectoplasm.org/ F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3 A5A5
Q: It is impossible to make anything foolproof because fools are so ingenious.
perl -e'$$=\${gozer};{$_=unpack(P7,pack(L,$$));/^JAm_pH\n$/&&print||$$++&&redo}'
Re: [Patch mp2] PerlSections namespace
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>
> Stas Bekman wrote:
>
>>Philippe M. Chiasson wrote:
>>
>>
>>>>so maybe at startup it's not a bad idea after all :)
>>>
>>>
>>>
>>>So, does this mean that you don't have a specific objection against
>>>deprecating (or tossing) direct access to %Apache::ReadConfig:: in the
>>>future in favor of ->add_config("User foo") ?
>>
>>
>>The problem with add_config() is that it wants a string as if you've
>>written it in httpd.conf language. Taking an access to
>>%Apache::ReadConfig:: away takes away the ability to use perl structs to
>>autovivify complex constructs. e.g. how do you build a complex vhost
>>with nested containers using add_config?
>
>
> well, it might be different than it was, but I guess it ends up being
> similar to Apache->httpd_conf
Yup
http://perl.apache.org/docs/2.0/user/porting/compat.html#C_Apache_E_gt_httpd_conf_
(and I have a typo in it, will fix shortly)
> Apache->server->add_config([ <<END ]);
> <VirtualHost $vhost>
> ServerName $name
> ServerAlias $alias
> </VirtualHost>
> END
>
> in truth, now that I look at it, I'm not sure that's any more or less
> difficult or flexible than
>
> %directives = (
>
> ServerName => $name,
> ServerAlias => $alias,
> );
>
> $VirtualHost{$vhost} = \%directives;
but that's a simple example. If you want to have more complex config and if
you have some engine that generates each component separately it's going to be
harder to put them together. It's just so intuitive to use perl structs for
that purpose.
> especially when you take in to account that extra steps are needed for when
> ordering is important (like rewrite rules).
True. One needs to use Tie::IxHash for this purpose.
>>may be we could have an alternative method, accepting an SV (e.g. a hash
>>ref which represents a container) which perl will then convert to a
>>string and feed to add_config?
>
>
> I suppose that could work too.
Cool.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [Patch mp2] PerlSections namespace
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
Stas Bekman wrote:
> Philippe M. Chiasson wrote:
>
>>> so maybe at startup it's not a bad idea after all :)
>>
>>
>>
>> So, does this mean that you don't have a specific objection against
>> deprecating (or tossing) direct access to %Apache::ReadConfig:: in the
>> future in favor of ->add_config("User foo") ?
>
>
> The problem with add_config() is that it wants a string as if you've
> written it in httpd.conf language. Taking an access to
> %Apache::ReadConfig:: away takes away the ability to use perl structs to
> autovivify complex constructs. e.g. how do you build a complex vhost
> with nested containers using add_config?
well, it might be different than it was, but I guess it ends up being
similar to Apache->httpd_conf
Apache->server->add_config([ <<END ]);
<VirtualHost $vhost>
ServerName $name
ServerAlias $alias
</VirtualHost>
END
in truth, now that I look at it, I'm not sure that's any more or less
difficult or flexible than
%directives = (
ServerName => $name,
ServerAlias => $alias,
);
$VirtualHost{$vhost} = \%directives;
especially when you take in to account that extra steps are needed for when
ordering is important (like rewrite rules).
>
> may be we could have an alternative method, accepting an SV (e.g. a hash
> ref which represents a container) which perl will then convert to a
> string and feed to add_config?
I suppose that could work too.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [Patch mp2] PerlSections namespace
Posted by Stas Bekman <st...@stason.org>.
Philippe M. Chiasson wrote:
>>so maybe at startup it's not a bad idea after all :)
>
>
> So, does this mean that you don't have a specific objection against
> deprecating (or tossing) direct access to %Apache::ReadConfig:: in the
> future in favor of ->add_config("User foo") ?
The problem with add_config() is that it wants a string as if you've written
it in httpd.conf language. Taking an access to %Apache::ReadConfig:: away
takes away the ability to use perl structs to autovivify complex constructs.
e.g. how do you build a complex vhost with nested containers using add_config?
may be we could have an alternative method, accepting an SV (e.g. a hash ref
which represents a container) which perl will then convert to a string and
feed to add_config?
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [Patch mp2] PerlSections namespace
Posted by "Philippe M. Chiasson" <go...@cpan.org>.
On Wed, 2003-12-10 at 14:14, Geoffrey Young wrote:
> >> add_config() is equivalent to an .htaccess file - whatever overrides
> >> govern
> >> .htaccess files' ability to have directives inserted into the
> >> configuration
> >> will apply to add_config() as well. that is very different from
> >> ReadConfig's blind addition of directives into the config.
> >
> >
> > I thought it was behaving differently when called at the server startup.
> > In any case it's not pretty so it's not a good substitute...
>
> looks like you're right. I tried to whip up some examples at startup but I
> couldn't find any. I guess the failures I'm remembering were request time,
> when I tried to inject "Requires valid-user" or something on-the-fly and was
> denied by AllowOverride none.
That does make sense at runtime indeed. You don't want any registry to
be able to define new aliases and all at runtime when AllowOverride is
none.
> so maybe at startup it's not a bad idea after all :)
So, does this mean that you don't have a specific objection against
deprecating (or tossing) direct access to %Apache::ReadConfig:: in the
future in favor of ->add_config("User foo") ?
> --Geoff
--
--------------------------------------------------------------------------------
Philippe M. Chiasson /gozer\@(cpan|ectoplasm)\.org/ 88C3A5A5 (122FF51B/C634E37B)
http://gozer.ectoplasm.org/ F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3 A5A5
Q: It is impossible to make anything foolproof because fools are so ingenious.
perl -e'$$=\${gozer};{$_=unpack(P7,pack(L,$$));/^JAm_pH\n$/&&print||$$++&&redo}'
Re: [Patch mp2] PerlSections namespace
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
>> add_config() is equivalent to an .htaccess file - whatever overrides
>> govern
>> .htaccess files' ability to have directives inserted into the
>> configuration
>> will apply to add_config() as well. that is very different from
>> ReadConfig's blind addition of directives into the config.
>
>
> I thought it was behaving differently when called at the server startup.
> In any case it's not pretty so it's not a good substitute...
looks like you're right. I tried to whip up some examples at startup but I
couldn't find any. I guess the failures I'm remembering were request time,
when I tried to inject "Requires valid-user" or something on-the-fly and was
denied by AllowOverride none.
so maybe at startup it's not a bad idea after all :)
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [Patch mp2] PerlSections namespace
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>>>well, as I said, add_config() can't accomplish the same thing. in fact,
>>>every time I've tried to use add_config() the way I want I haven't
>>>been able
>>>to. not that it's not useful for some things, but it's not useful for
>>>the
>>>level of trickery that I'm used to being able to do with ReadConfig.
>>
>>
>>What do you mean, it can't? It just feeds the config sections as if you
>>have written them in httpd.conf. I fail to see how it fails.
>
>
> add_config() is equivalent to an .htaccess file - whatever overrides govern
> .htaccess files' ability to have directives inserted into the configuration
> will apply to add_config() as well. that is very different from
> ReadConfig's blind addition of directives into the config.
I thought it was behaving differently when called at the server startup. In
any case it's not pretty so it's not a good substitute...
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [Patch mp2] PerlSections namespace
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
>> well, as I said, add_config() can't accomplish the same thing. in fact,
>> every time I've tried to use add_config() the way I want I haven't
>> been able
>> to. not that it's not useful for some things, but it's not useful for
>> the
>> level of trickery that I'm used to being able to do with ReadConfig.
>
>
> What do you mean, it can't? It just feeds the config sections as if you
> have written them in httpd.conf. I fail to see how it fails.
add_config() is equivalent to an .htaccess file - whatever overrides govern
.htaccess files' ability to have directives inserted into the configuration
will apply to add_config() as well. that is very different from
ReadConfig's blind addition of directives into the config.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [Patch mp2] PerlSections namespace
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>>>it's similar to Apache->server->add_config() in mp2, but I've found that
>>>method really not worth the trouble - it's goverened by overrides, so you
>>>can never really trust that it will add the configuration data you
>>>pipe into it.
>>
>>
>>That's exactly why people do *not* need to work directly with
>>Apache::ReadConfig - they have Apache->server->add_config() (and we are
>>talking about mp2). If people can achieve the same thing without using
>>Apache::ReadConfig, I think it should be completely deprecated, which
>>avoids the problem altogether. That's why I wanted to know if there are
>>cases where it's absolutely needed and you can't go without it.
>
>
> well, as I said, add_config() can't accomplish the same thing. in fact,
> every time I've tried to use add_config() the way I want I haven't been able
> to. not that it's not useful for some things, but it's not useful for the
> level of trickery that I'm used to being able to do with ReadConfig.
What do you mean, it can't? It just feeds the config sections as if you have
written them in httpd.conf. I fail to see how it fails. The issue is that you
completely lose the usefulness of using perl structures to accomplish that.
>>I think this case:
>>
>><Perl>
>> package Foo;
>> my $whatever = whatever();
>> package Apache::ReadConfig;
>> $User = $whatever;
>></Perl>
>>
>>can now become:
>>
>><Perl>
>> package Foo;
>> my $whatever = whatever();
>> Apache->server->add_config("$User $whatever");
>></Perl>
>
>
> this is entirely different than what I'm talking about.
I know. I was just showing a different, unrelated case where we need to deal
with Apache::ReadConfig.
>>Though it's probably not going to be simple for creating more complex
>>config directives, e.g complex containers. Can you think of a good
>>solution for that case?
>
>
> I haven't tried add_config for containers, but it's interface seems
> straightforward enough (when it works at all).
Yes, but you will need to manually concatenate the config section, you can't
use perl structures for that.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [Patch mp2] PerlSections namespace
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
>> it's similar to Apache->server->add_config() in mp2, but I've found that
>> method really not worth the trouble - it's goverened by overrides, so you
>> can never really trust that it will add the configuration data you
>> pipe into it.
>
>
> That's exactly why people do *not* need to work directly with
> Apache::ReadConfig - they have Apache->server->add_config() (and we are
> talking about mp2). If people can achieve the same thing without using
> Apache::ReadConfig, I think it should be completely deprecated, which
> avoids the problem altogether. That's why I wanted to know if there are
> cases where it's absolutely needed and you can't go without it.
well, as I said, add_config() can't accomplish the same thing. in fact,
every time I've tried to use add_config() the way I want I haven't been able
to. not that it's not useful for some things, but it's not useful for the
level of trickery that I'm used to being able to do with ReadConfig.
>
> I think this case:
>
> <Perl>
> package Foo;
> my $whatever = whatever();
> package Apache::ReadConfig;
> $User = $whatever;
> </Perl>
>
> can now become:
>
> <Perl>
> package Foo;
> my $whatever = whatever();
> Apache->server->add_config("$User $whatever");
> </Perl>
this is entirely different than what I'm talking about.
>
> Though it's probably not going to be simple for creating more complex
> config directives, e.g complex containers. Can you think of a good
> solution for that case?
I haven't tried add_config for containers, but it's interface seems
straightforward enough (when it works at all).
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [Patch mp2] PerlSections namespace
Posted by "Philippe M. Chiasson" <go...@cpan.org>.
On Wed, 2003-12-10 at 12:06, Stas Bekman wrote:
> Geoffrey Young wrote:
> >>Am I
> >>correct to say that people don't need to work directly with
> >>Apache::ReadConfig? I think the only place this is needed when people
> >>mix config with non-config perl code in <Perl>, so that they need to
> >>switch 'package Apache::ReadConfig;' to start feeding things into the
> >>config.
> >
> >
> > no, you can also add entries directly to the Apache::ReadConfig namespace in
> > order to add configuration data.
> >
> > package Apache::Foo;
> > $Apache::ReadConfig::PerlFixupHandler = "Apache::Foo";
> > sub handler { };
> >
> > now, PerlModule Apache::Foo automatically installs a PerlFixupHandler :)
> > there are a few modules on CPAN that do this, IIRC.
> >
> > it's similar to Apache->server->add_config() in mp2, but I've found that
> > method really not worth the trouble - it's goverened by overrides, so you
> > can never really trust that it will add the configuration data you pipe into it.
>
> That's exactly why people do *not* need to work directly with
> Apache::ReadConfig - they have Apache->server->add_config() (and we are
> talking about mp2). If people can achieve the same thing without using
> Apache::ReadConfig, I think it should be completely deprecated, which avoids
> the problem altogether. That's why I wanted to know if there are cases where
> it's absolutely needed and you can't go without it.
Like I just said, one problem is that from within a <Perl> block, you
would possibly need to have access to the current server object.
Otherwise you'll be adding your configuration to the topmost server, and
not the current VHost your <Perl> section is in.
But if that's the only issue preventing getting rid of
Apache::ReadConfig alltogether, I would be more than happy to make the
right server object accessible from within <Perl> sections in a global
variable or sth similar.
> I think this case:
>
> <Perl>
> package Foo;
> my $whatever = whatever();
> package Apache::ReadConfig;
> $User = $whatever;
> </Perl>
>
> can now become:
>
> <Perl>
> package Foo;
> my $whatever = whatever();
> Apache->server->add_config("$User $whatever");
> </Perl>
>
> Though it's probably not going to be simple for creating more complex config
> directives, e.g complex containers. Can you think of a good solution for that
> case?
Could probably make use of a subclass of Apache::PerlSections for this.
PerlModule Foo
package Foo;
use Apache::PerlSections::Processor;
$User = 'gozer';
$Location{"/this"} = { "Options" => "+ExecCGI"};
Apache::PerlSections::Processor->readnamespace("Foo");
Or something like that.
> __________________________________________________________________
> Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
> http://stason.org/ mod_perl Guide ---> http://perl.apache.org
> mailto:stas@stason.org http://use.perl.org http://apacheweek.com
> http://modperlbook.org http://apache.org http://ticketmaster.com
--
--------------------------------------------------------------------------------
Philippe M. Chiasson /gozer\@(cpan|ectoplasm)\.org/ 88C3A5A5 (122FF51B/C634E37B)
http://gozer.ectoplasm.org/ F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3 A5A5
Q: It is impossible to make anything foolproof because fools are so ingenious.
perl -e'$$=\${gozer};{$_=unpack(P7,pack(L,$$));/^JAm_pH\n$/&&print||$$++&&redo}'
Re: [Patch mp2] PerlSections namespace
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>>Am I
>>correct to say that people don't need to work directly with
>>Apache::ReadConfig? I think the only place this is needed when people
>>mix config with non-config perl code in <Perl>, so that they need to
>>switch 'package Apache::ReadConfig;' to start feeding things into the
>>config.
>
>
> no, you can also add entries directly to the Apache::ReadConfig namespace in
> order to add configuration data.
>
> package Apache::Foo;
> $Apache::ReadConfig::PerlFixupHandler = "Apache::Foo";
> sub handler { };
>
> now, PerlModule Apache::Foo automatically installs a PerlFixupHandler :)
> there are a few modules on CPAN that do this, IIRC.
>
> it's similar to Apache->server->add_config() in mp2, but I've found that
> method really not worth the trouble - it's goverened by overrides, so you
> can never really trust that it will add the configuration data you pipe into it.
That's exactly why people do *not* need to work directly with
Apache::ReadConfig - they have Apache->server->add_config() (and we are
talking about mp2). If people can achieve the same thing without using
Apache::ReadConfig, I think it should be completely deprecated, which avoids
the problem altogether. That's why I wanted to know if there are cases where
it's absolutely needed and you can't go without it.
I think this case:
<Perl>
package Foo;
my $whatever = whatever();
package Apache::ReadConfig;
$User = $whatever;
</Perl>
can now become:
<Perl>
package Foo;
my $whatever = whatever();
Apache->server->add_config("$User $whatever");
</Perl>
Though it's probably not going to be simple for creating more complex config
directives, e.g complex containers. Can you think of a good solution for that
case?
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [Patch mp2] PerlSections namespace
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> Am I
> correct to say that people don't need to work directly with
> Apache::ReadConfig? I think the only place this is needed when people
> mix config with non-config perl code in <Perl>, so that they need to
> switch 'package Apache::ReadConfig;' to start feeding things into the
> config.
no, you can also add entries directly to the Apache::ReadConfig namespace in
order to add configuration data.
package Apache::Foo;
$Apache::ReadConfig::PerlFixupHandler = "Apache::Foo";
sub handler { };
now, PerlModule Apache::Foo automatically installs a PerlFixupHandler :)
there are a few modules on CPAN that do this, IIRC.
it's similar to Apache->server->add_config() in mp2, but I've found that
method really not worth the trouble - it's goverened by overrides, so you
can never really trust that it will add the configuration data you pipe into it.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [Patch mp2] PerlSections namespace
Posted by Stas Bekman <st...@stason.org>.
Philippe M. Chiasson wrote:
[...]
>>>>You mean it will break their code. In which case I'd suggest not to commit
>>>>this patch till you get it all ready.
>>>
>>>
>>>Yeah, well, things are already broken quite a bit w/r to <Perl >
>>>sections, so I wanted to fix a problem at a time, even though if it
>>>temporarely introduces another little different problem.
>>
>>Yes, but your change is going to introduce a new problem, and if it's not
>>fixed by the time of the new release, it'll break people's code which worked
>>fine with the previous release. Not too friendly, hey? And I think we should
>>do a new release rsn. What do you think?
>
> You are quite right about this. Especially with a release on the
> horizon. In that case, I'd lean towards solution #1, easily achieved by
> having PerlSections iterate over symbols in the generated namespace AND
> %Apache::ReadConfig on each pass. This ends up being just like before,
> and would fix recursive <Perl > section problems as well.
What about doing #3 - at the end of each block feed it to Apache and somehow
mark that block as processed, so it won't be rerun again? e.g. by moving the
symbols into a special package, which is not ReadConfig?
>>I think you also have a problem of ordering thing. As you may end up with
>>overriding order problem, no? I think 1 is safer and making it deprecated will
>>eventually make the problem go away completely. Am I correct to say that
>>people don't need to work directly with Apache::ReadConfig? I think the only
>>place this is needed when people mix config with non-config perl code in
>><Perl>, so that they need to switch 'package Apache::ReadConfig;' to start
>>feeding things into the config.
>
>
> As far as I can tell, now that we have Apache::Server->add_config, I'd
> be more than happy to deprecate direct usage of the
> %Apache::ReadConfig:: namespace.
As you can see in the other sub-thread, it's not going to be simple.
> Ordering as of today is still a problem anyways (in Location,
> VirtualHost and other containers). In mp1 we were using Tie::IxHash to
> work around this, and I am planning on doing the same thing in the near
> future to address that problem.
That's good.
>>OK, but I can still see how it it breaks. Consider:
>>
>>foo-/baz => foo_baz
>>foo/-baz => foo_baz
>>
>>whereas this works:
>>
>>foo-/baz => foo_::baz
>>foo/-baz => foo::_baz
>>
>>I think you shouldn't replace groups of chars with a single _, you must
>>preserve the lent
>
>
> Correct, I didn't realize that. One question I have though is for win32.
>
> Would it be 100% safe to :
>
> 1. replace occurences of '/' and '\' (path separators) with '::'
careful here, as you have \\ too, you don't want to end up with ::::
> 2. replace non alphanumeric with '_'
if you assume 1:1, then yes (length doesn't change)
> 3. insure resulting package doesn't start with '::' or numeric
rather check that it starts with alpha or '_' ;)
> I know File::Spec would be the nicest way of going around doing it:
>
> my $name = join('::', File::Spec->splitpath($filename));
> $name =~ s/[^a-zA-Z0-9]/_/g;
absolutely ;)
[...]
>>I don't think there is a good solution here, as you apply a lossful
>>transformation. We have the same problem with registry, but nobody has ever
>>complained, since most files include alphanumerics only.
>
>
> So, can we agree on what will agree to be doing ? Then I'll be happy to
> write it, stick it in modperl_util.c, expose it thru ModPerl::Util (for
> registry) and use it for PerlSection's namespaces
I think your proposition above is fine. (it's the same as the alg used by
RegistryCooker, just reproduce it from that perl code 1:1).
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [Patch mp2] PerlSections namespace
Posted by "Philippe M. Chiasson" <go...@cpan.org>.
On Wed, 2003-12-10 at 11:49, Stas Bekman wrote:
> Philippe M. Chiasson wrote:
> > On Tue, 2003-12-09 at 17:44, Stas Bekman wrote:
> >
> >>Philippe M. Chiasson wrote:
> >>
> >>>It's been a long time that perl sections have been having trouble with
> >>>recursive inclusion. This has been discussed before and has to do with
> >>>the fact that all PerlSections are evaluated in the same namespace
> >>>Apache::ReadSections.
> >>>
> >>>The following patch follows a similar design than ModPerl::Registry,
> >>>putting each <Perl> block in it's own namespace, based on filename &
> >>>lineno.
> >>
> >>Coolio ;)
> >>
> >>
> >>>This now prevents infinite-recursion problems and makes $Includes from
> >>>within <Perl> sections work fine.
> >>>
> >>>There is still one little problem left with this, people will not be
> >>>able to put stuff directly in the Apache::ReadSections namespace
> >>>themselves. I do have a plan for fixing that as well in a subsequent
> >>>patch.
> >>
> >>You mean it will break their code. In which case I'd suggest not to commit
> >>this patch till you get it all ready.
> >
> >
> > Yeah, well, things are already broken quite a bit w/r to <Perl >
> > sections, so I wanted to fix a problem at a time, even though if it
> > temporarely introduces another little different problem.
>
> Yes, but your change is going to introduce a new problem, and if it's not
> fixed by the time of the new release, it'll break people's code which worked
> fine with the previous release. Not too friendly, hey? And I think we should
> do a new release rsn. What do you think?
You are quite right about this. Especially with a release on the
horizon. In that case, I'd lean towards solution #1, easily achieved by
having PerlSections iterate over symbols in the generated namespace AND
%Apache::ReadConfig on each pass. This ends up being just like before,
and would fix recursive <Perl > section problems as well.
> > Now that we are sticking <Perl> sections in their own distinct
> > namespaces, it means that for people who put stuff directly in
> > Apache::ReadConfig, I can think of 2 ways of handling it.
>
> > 1. Apache::PerlSections defaults to reading from the unique package and
> > also process the contents of Apache::ReadConfig.
> >
> > Problem with this (same as it is right now) , is that since people just
> > add to the %Apache::ReadConfig:: namespace, each time a <Perl> block
> > ends, the sum of its content is fed back into apache, so you get
> > warnings and errors, since directives are processed multiple times.
> >
> > 2. Leave %Apache::ReadConfig:: alone until right after the config phase
> > and feed it to Apache::PerlSections in one go
> >
> > Problem with this that processing of Apache::ReadConfig (for modules and
> > code that push into it themselves) will be delayed at the very end and
> > might break existing things that expects it to be processed at the end
> > of the <Perl> block that ran...
> >
> > I dunno about anybody else, but I prefer solution 2, but what do you
> > think?
>
> I think you also have a problem of ordering thing. As you may end up with
> overriding order problem, no? I think 1 is safer and making it deprecated will
> eventually make the problem go away completely. Am I correct to say that
> people don't need to work directly with Apache::ReadConfig? I think the only
> place this is needed when people mix config with non-config perl code in
> <Perl>, so that they need to switch 'package Apache::ReadConfig;' to start
> feeding things into the config.
As far as I can tell, now that we have Apache::Server->add_config, I'd
be more than happy to deprecate direct usage of the
%Apache::ReadConfig:: namespace.
Ordering as of today is still a problem anyways (in Location,
VirtualHost and other containers). In mp1 we were using Tie::IxHash to
work around this, and I am planning on doing the same thing in the near
future to address that problem.
> [...]
>
> >>>I had to introduce a function in mod_perl_util.c, modperl_file2package,
> >>>that makes a package-safe name from a filepath, so maybe it could be
> >>>exposed and used by ModPerl::Registry as well?
> >>
> >>Good idea. I've just introduced the opposite function package2filename (to fix
> >>the problems in modperl_mgv). I'm not sure it fits registrycooker, since it
> >>doesn't drop /, whereas your function does, collapsing everything into a
> >>single word. It may have problems, since these two distinct names will map
> >>into the same namespace:
> >>
> >>foo/barbaz
> >>foobar/baz
> >>
> >>so the concept of dropping / is wrong. You need to replace each '/' with '::'.
> >
> >
> > I am not dropping it, just if it's at the beginning, for example
> >
> > foo/barbaz => foo_barbaz
> > foobar/baz => foobar_baz
> >
> > //foobar/baz => foobar_baz
> > /foobar/baz => foobar_baz
>
> OK, but I can still see how it it breaks. Consider:
>
> foo-/baz => foo_baz
> foo/-baz => foo_baz
>
> whereas this works:
>
> foo-/baz => foo_::baz
> foo/-baz => foo::_baz
>
> I think you shouldn't replace groups of chars with a single _, you must
> preserve the lent
Correct, I didn't realize that. One question I have though is for win32.
Would it be 100% safe to :
1. replace occurences of '/' and '\' (path separators) with '::'
2. replace non alphanumeric with '_'
3. insure resulting package doesn't start with '::' or numeric
I know File::Spec would be the nicest way of going around doing it:
my $name = join('::', File::Spec->splitpath($filename));
$name =~ s/[^a-zA-Z0-9]/_/g;
> >>modperl_file2package has its own problems ;) a stash name can't start with
> >>numerical and ':'. See below:
> >
> >
> > Can't start with a numerical? Oh, I'll make sure I check for that as
> > well then.
>
> It can start only with _ or alpha
>
> >>[...]
> >>
> >>>+#define MP_VALID_PKG_CHAR(c) (isalnum(c)||c==':'||c=='_')
> >>>+static const char *modperl_file2package(apr_pool_t *p, const char *file)
> >>>+{
> >>>+ char *package;
> >>>+ char *c;
> >>>+
> >>>+ c = package = apr_pcalloc(p, strlen(file));
> >>>+
> >>>+ /* First, skip invalid prefix characters */
> >>>+ while (!MP_VALID_PKG_CHAR(*file)) {
> >>>+ file++;
> >>>+ }
> >>
> >>You need here:
> >>
> >>#define MP_VALID_PKG_FIRST_CHAR(c) (isalpha(c) || c == '_')
> >>
> >>/* First, skip invalid prefix characters */
> >>while (!MP_VALID_PKG_FIRST_CHAR(*file)) {
> >> file++;
> >>}
> >>
> >>Neither you can have a single ':' in the package name (or triple, etc), so you
> >>should check that they come in doubles...
> >
> >
> > Well, even simpler, if I just remove ':' from the allowed characters,
> > I'll avoid that problem (and keep the string the same size or smaller)
> >
> > So
> >
> > C:\FooBar\Baz\Bof => C_FooBar_Baz_Bof
>
> I think you shouldn't replace groups of chars with a single _, you must
> preserve their length, but even then you are prone to collisions:
>
> foo--+bar => foo___bar
> foo+--bar => foo___bar
>
> I don't think there is a good solution here, as you apply a lossful
> transformation. We have the same problem with registry, but nobody has ever
> complained, since most files include alphanumerics only.
So, can we agree on what will agree to be doing ? Then I'll be happy to
write it, stick it in modperl_util.c, expose it thru ModPerl::Util (for
registry) and use it for PerlSection's namespaces
> __________________________________________________________________
> Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
> http://stason.org/ mod_perl Guide ---> http://perl.apache.org
> mailto:stas@stason.org http://use.perl.org http://apacheweek.com
> http://modperlbook.org http://apache.org http://ticketmaster.com
--
--------------------------------------------------------------------------------
Philippe M. Chiasson /gozer\@(cpan|ectoplasm)\.org/ 88C3A5A5 (122FF51B/C634E37B)
http://gozer.ectoplasm.org/ F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3 A5A5
Q: It is impossible to make anything foolproof because fools are so ingenious.
perl -e'$$=\${gozer};{$_=unpack(P7,pack(L,$$));/^JAm_pH\n$/&&print||$$++&&redo}'
Re: [Patch mp2] PerlSections namespace
Posted by Stas Bekman <st...@stason.org>.
Philippe M. Chiasson wrote:
> On Tue, 2003-12-09 at 17:44, Stas Bekman wrote:
>
>>Philippe M. Chiasson wrote:
>>
>>>It's been a long time that perl sections have been having trouble with
>>>recursive inclusion. This has been discussed before and has to do with
>>>the fact that all PerlSections are evaluated in the same namespace
>>>Apache::ReadSections.
>>>
>>>The following patch follows a similar design than ModPerl::Registry,
>>>putting each <Perl> block in it's own namespace, based on filename &
>>>lineno.
>>
>>Coolio ;)
>>
>>
>>>This now prevents infinite-recursion problems and makes $Includes from
>>>within <Perl> sections work fine.
>>>
>>>There is still one little problem left with this, people will not be
>>>able to put stuff directly in the Apache::ReadSections namespace
>>>themselves. I do have a plan for fixing that as well in a subsequent
>>>patch.
>>
>>You mean it will break their code. In which case I'd suggest not to commit
>>this patch till you get it all ready.
>
>
> Yeah, well, things are already broken quite a bit w/r to <Perl >
> sections, so I wanted to fix a problem at a time, even though if it
> temporarely introduces another little different problem.
Yes, but your change is going to introduce a new problem, and if it's not
fixed by the time of the new release, it'll break people's code which worked
fine with the previous release. Not too friendly, hey? And I think we should
do a new release rsn. What do you think?
> Now that we are sticking <Perl> sections in their own distinct
> namespaces, it means that for people who put stuff directly in
> Apache::ReadConfig, I can think of 2 ways of handling it.
> 1. Apache::PerlSections defaults to reading from the unique package and
> also process the contents of Apache::ReadConfig.
>
> Problem with this (same as it is right now) , is that since people just
> add to the %Apache::ReadConfig:: namespace, each time a <Perl> block
> ends, the sum of its content is fed back into apache, so you get
> warnings and errors, since directives are processed multiple times.
>
> 2. Leave %Apache::ReadConfig:: alone until right after the config phase
> and feed it to Apache::PerlSections in one go
>
> Problem with this that processing of Apache::ReadConfig (for modules and
> code that push into it themselves) will be delayed at the very end and
> might break existing things that expects it to be processed at the end
> of the <Perl> block that ran...
>
> I dunno about anybody else, but I prefer solution 2, but what do you
> think?
I think you also have a problem of ordering thing. As you may end up with
overriding order problem, no? I think 1 is safer and making it deprecated will
eventually make the problem go away completely. Am I correct to say that
people don't need to work directly with Apache::ReadConfig? I think the only
place this is needed when people mix config with non-config perl code in
<Perl>, so that they need to switch 'package Apache::ReadConfig;' to start
feeding things into the config.
[...]
>>>I had to introduce a function in mod_perl_util.c, modperl_file2package,
>>>that makes a package-safe name from a filepath, so maybe it could be
>>>exposed and used by ModPerl::Registry as well?
>>
>>Good idea. I've just introduced the opposite function package2filename (to fix
>>the problems in modperl_mgv). I'm not sure it fits registrycooker, since it
>>doesn't drop /, whereas your function does, collapsing everything into a
>>single word. It may have problems, since these two distinct names will map
>>into the same namespace:
>>
>>foo/barbaz
>>foobar/baz
>>
>>so the concept of dropping / is wrong. You need to replace each '/' with '::'.
>
>
> I am not dropping it, just if it's at the beginning, for example
>
> foo/barbaz => foo_barbaz
> foobar/baz => foobar_baz
>
> //foobar/baz => foobar_baz
> /foobar/baz => foobar_baz
OK, but I can still see how it it breaks. Consider:
foo-/baz => foo_baz
foo/-baz => foo_baz
whereas this works:
foo-/baz => foo_::baz
foo/-baz => foo::_baz
I think you shouldn't replace groups of chars with a single _, you must
preserve the lent
>>modperl_file2package has its own problems ;) a stash name can't start with
>>numerical and ':'. See below:
>
>
> Can't start with a numerical? Oh, I'll make sure I check for that as
> well then.
It can start only with _ or alpha
>>[...]
>>
>>>+#define MP_VALID_PKG_CHAR(c) (isalnum(c)||c==':'||c=='_')
>>>+static const char *modperl_file2package(apr_pool_t *p, const char *file)
>>>+{
>>>+ char *package;
>>>+ char *c;
>>>+
>>>+ c = package = apr_pcalloc(p, strlen(file));
>>>+
>>>+ /* First, skip invalid prefix characters */
>>>+ while (!MP_VALID_PKG_CHAR(*file)) {
>>>+ file++;
>>>+ }
>>
>>You need here:
>>
>>#define MP_VALID_PKG_FIRST_CHAR(c) (isalpha(c) || c == '_')
>>
>>/* First, skip invalid prefix characters */
>>while (!MP_VALID_PKG_FIRST_CHAR(*file)) {
>> file++;
>>}
>>
>>Neither you can have a single ':' in the package name (or triple, etc), so you
>>should check that they come in doubles...
>
>
> Well, even simpler, if I just remove ':' from the allowed characters,
> I'll avoid that problem (and keep the string the same size or smaller)
>
> So
>
> C:\FooBar\Baz\Bof => C_FooBar_Baz_Bof
I think you shouldn't replace groups of chars with a single _, you must
preserve their length, but even then you are prone to collisions:
foo--+bar => foo___bar
foo+--bar => foo___bar
I don't think there is a good solution here, as you apply a lossful
transformation. We have the same problem with registry, but nobody has ever
complained, since most files include alphanumerics only.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [Patch mp2] PerlSections namespace
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
>
> 2. Leave %Apache::ReadConfig:: alone until right after the config phase
> and feed it to Apache::PerlSections in one go
>
> Problem with this that processing of Apache::ReadConfig (for modules and
> code that push into it themselves) will be delayed at the very end and
> might break existing things that expects it to be processed at the end
> of the <Perl> block that ran...
>
> I dunno about anybody else, but I prefer solution 2, but what do you
> think?
in all the stuff I've done with adding directly to the ReadConfig namespace,
I don't _think_ I've ever relied on the exact placement of the directives.
so, it _sounds_ ok to me (at the moment :)
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [Patch mp2] PerlSections namespace
Posted by "Philippe M. Chiasson" <go...@cpan.org>.
On Tue, 2003-12-09 at 17:44, Stas Bekman wrote:
> Philippe M. Chiasson wrote:
> > It's been a long time that perl sections have been having trouble with
> > recursive inclusion. This has been discussed before and has to do with
> > the fact that all PerlSections are evaluated in the same namespace
> > Apache::ReadSections.
> >
> > The following patch follows a similar design than ModPerl::Registry,
> > putting each <Perl> block in it's own namespace, based on filename &
> > lineno.
>
> Coolio ;)
>
> > This now prevents infinite-recursion problems and makes $Includes from
> > within <Perl> sections work fine.
> >
> > There is still one little problem left with this, people will not be
> > able to put stuff directly in the Apache::ReadSections namespace
> > themselves. I do have a plan for fixing that as well in a subsequent
> > patch.
>
> You mean it will break their code. In which case I'd suggest not to commit
> this patch till you get it all ready.
Yeah, well, things are already broken quite a bit w/r to <Perl >
sections, so I wanted to fix a problem at a time, even though if it
temporarely introduces another little different problem.
Now that we are sticking <Perl> sections in their own distinct
namespaces, it means that for people who put stuff directly in
Apache::ReadConfig, I can think of 2 ways of handling it.
1. Apache::PerlSections defaults to reading from the unique package and
also process the contents of Apache::ReadConfig.
Problem with this (same as it is right now) , is that since people just
add to the %Apache::ReadConfig:: namespace, each time a <Perl> block
ends, the sum of its content is fed back into apache, so you get
warnings and errors, since directives are processed multiple times.
2. Leave %Apache::ReadConfig:: alone until right after the config phase
and feed it to Apache::PerlSections in one go
Problem with this that processing of Apache::ReadConfig (for modules and
code that push into it themselves) will be delayed at the very end and
might break existing things that expects it to be processed at the end
of the <Perl> block that ran...
I dunno about anybody else, but I prefer solution 2, but what do you
think?
> > As usual, look at it and tell me if it breaks more stuff than it fixes
> > ;-)
>
> I suppose it was a proof of concept, since you need to fix quite a few style
> things (long lines, some missing indent, missing spaces around ops).
Yes, you supposed right ;-) I just wanted review on it.
> > I had to introduce a function in mod_perl_util.c, modperl_file2package,
> > that makes a package-safe name from a filepath, so maybe it could be
> > exposed and used by ModPerl::Registry as well?
>
> Good idea. I've just introduced the opposite function package2filename (to fix
> the problems in modperl_mgv). I'm not sure it fits registrycooker, since it
> doesn't drop /, whereas your function does, collapsing everything into a
> single word. It may have problems, since these two distinct names will map
> into the same namespace:
>
> foo/barbaz
> foobar/baz
>
> so the concept of dropping / is wrong. You need to replace each '/' with '::'.
I am not dropping it, just if it's at the beginning, for example
foo/barbaz => foo_barbaz
foobar/baz => foobar_baz
//foobar/baz => foobar_baz
/foobar/baz => foobar_baz
>
> modperl_file2package has its own problems ;) a stash name can't start with
> numerical and ':'. See below:
Can't start with a numerical? Oh, I'll make sure I check for that as
well then.
> [...]
> > +#define MP_VALID_PKG_CHAR(c) (isalnum(c)||c==':'||c=='_')
> > +static const char *modperl_file2package(apr_pool_t *p, const char *file)
> > +{
> > + char *package;
> > + char *c;
> > +
> > + c = package = apr_pcalloc(p, strlen(file));
> > +
> > + /* First, skip invalid prefix characters */
> > + while (!MP_VALID_PKG_CHAR(*file)) {
> > + file++;
> > + }
>
> You need here:
>
> #define MP_VALID_PKG_FIRST_CHAR(c) (isalpha(c) || c == '_')
>
> /* First, skip invalid prefix characters */
> while (!MP_VALID_PKG_FIRST_CHAR(*file)) {
> file++;
> }
>
> Neither you can have a single ':' in the package name (or triple, etc), so you
> should check that they come in doubles...
Well, even simpler, if I just remove ':' from the allowed characters,
I'll avoid that problem (and keep the string the same size or smaller)
So
C:\FooBar\Baz\Bof => C_FooBar_Baz_Bof
> __________________________________________________________________
> Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
> http://stason.org/ mod_perl Guide ---> http://perl.apache.org
> mailto:stas@stason.org http://use.perl.org http://apacheweek.com
> http://modperlbook.org http://apache.org http://ticketmaster.com
--
--------------------------------------------------------------------------------
Philippe M. Chiasson /gozer\@(cpan|ectoplasm)\.org/ 88C3A5A5 (122FF51B/C634E37B)
http://gozer.ectoplasm.org/ F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3 A5A5
Q: It is impossible to make anything foolproof because fools are so ingenious.
perl -e'$$=\${gozer};{$_=unpack(P7,pack(L,$$));/^JAm_pH\n$/&&print||$$++&&redo}'
Re: [Patch mp2] PerlSections namespace
Posted by Stas Bekman <st...@stason.org>.
Philippe M. Chiasson wrote:
> It's been a long time that perl sections have been having trouble with
> recursive inclusion. This has been discussed before and has to do with
> the fact that all PerlSections are evaluated in the same namespace
> Apache::ReadSections.
>
> The following patch follows a similar design than ModPerl::Registry,
> putting each <Perl> block in it's own namespace, based on filename &
> lineno.
Coolio ;)
> This now prevents infinite-recursion problems and makes $Includes from
> within <Perl> sections work fine.
>
> There is still one little problem left with this, people will not be
> able to put stuff directly in the Apache::ReadSections namespace
> themselves. I do have a plan for fixing that as well in a subsequent
> patch.
You mean it will break their code. In which case I'd suggest not to commit
this patch till you get it all ready.
> As usual, look at it and tell me if it breaks more stuff than it fixes
> ;-)
I suppose it was a proof of concept, since you need to fix quite a few style
things (long lines, some missing indent, missing spaces around ops).
> I had to introduce a function in mod_perl_util.c, modperl_file2package,
> that makes a package-safe name from a filepath, so maybe it could be
> exposed and used by ModPerl::Registry as well?
Good idea. I've just introduced the opposite function package2filename (to fix
the problems in modperl_mgv). I'm not sure it fits registrycooker, since it
doesn't drop /, whereas your function does, collapsing everything into a
single word. It may have problems, since these two distinct names will map
into the same namespace:
foo/barbaz
foobar/baz
so the concept of dropping / is wrong. You need to replace each '/' with '::'.
modperl_file2package has its own problems ;) a stash name can't start with
numerical and ':'. See below:
[...]
> +#define MP_VALID_PKG_CHAR(c) (isalnum(c)||c==':'||c=='_')
> +static const char *modperl_file2package(apr_pool_t *p, const char *file)
> +{
> + char *package;
> + char *c;
> +
> + c = package = apr_pcalloc(p, strlen(file));
> +
> + /* First, skip invalid prefix characters */
> + while (!MP_VALID_PKG_CHAR(*file)) {
> + file++;
> + }
You need here:
#define MP_VALID_PKG_FIRST_CHAR(c) (isalpha(c) || c == '_')
/* First, skip invalid prefix characters */
while (!MP_VALID_PKG_FIRST_CHAR(*file)) {
file++;
}
Neither you can have a single ':' in the package name (or triple, etc), so you
should check that they come in doubles...
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org