You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by Stas Bekman <st...@stason.org> on 2003/08/08 07:22:27 UTC
new mp2 package: Apache::porting
Now that ModPerl::MethodLookup handles mp1 methods as well, I've decided to
put together a package that will further assist the porting process. All the
needed bits are there already, this package just makes things a bit easier to
setup.
Notice that its purpose is to assist the porting process, not provide the
backcompatibility layer, so it dies every time it has to say something.
I'm considering to put it into the core, next to Apache/compat.pm.
You just need to load it at the server startup, and it installs
UNIVERSAL::AUTOLOAD at the child_init phase. Please give it a try (you need
the latest cvs to use it):
--- /dev/null 1969-12-31 16:00:00.000000000 -0800
+++ lib/Apache/porting.pm 2003-08-07 22:19:08.000000000 -0700
@@ -0,0 +1,49 @@
+package Apache::porting;
+
+use strict;
+use warnings FATAL => 'all';
+
+use Carp 'croak';
+
+use ModPerl::MethodLookup ();
+use Apache::ServerUtil;
+
+use Apache::Const -compile => 'OK';
+
+our $AUTOLOAD;
+
+my %avail_methods = map { $_ => 1 }
+ (ModPerl::MethodLookup::avail_methods(),
+ ModPerl::MethodLookup::avail_methods_compat());
+
+# unfortunately it doesn't seem to be possible to install
+# *UNIVERSAL::AUTOLOAD at the server startup, httpd segfaults,
+# child_init seems to be the first stage where it works.
+Apache->server->push_handlers(PerlChildInitHandler => \&porting_autoload);
+
+sub porting_autoload {
+ *UNIVERSAL::AUTOLOAD = sub {
+ # This is a porting module, no compatibility layers are allowed in
+ # this zone
+ croak("Apache::porting can't be used with Apache::compat")
+ if exists $ENV{"Apache/compat.pm"};
+
+ (my $method = $AUTOLOAD) =~ s/.*:://;
+
+ # we skip DESTROY methods
+ return if $method eq 'DESTROY';
+
+ # we don't handle methods that we don't know about
+ croak "Undefined subroutine $AUTOLOAD called"
+ unless defined $method && exists $avail_methods{$method};
+
+ my ($hint, @modules) =
+ ModPerl::MethodLookup::lookup_method($method, @_);
+ $hint ||= "Can't find method $AUTOLOAD";
+ croak $hint;
+ };
+
+ return Apache::OK;
+}
+
+1;
I'm also trying to handle the mp1 core packages that are no longer exist, by
overriding CORE::require, but I'm stuck at not being able to do 'goto
&CORE::require', since in pure perl you can't reference core functions (at
least I couldn't figure out how to do that) :( Any idea how to resolve that?
### handling removed packages ###
my %packages = (
'Apache::Constants' => [qw(Apache::Const)],
'Apache::Table' => [qw(APR::Table)],
'Apache::File' => [qw(Apache::Response Apache::RequestRec)],
'Apache' => [qw(ModPerl::Util Apache::Module)],
);
BEGIN {
# in case someone has already overriden require respect that
# my $sub = *CORE::GLOBAL::require{CODE} || *CORE::require{CODE};
# my $sub = \&CORE::GLOBAL::require || \&CORE::require{CODE};
#my $sub = \&CORE::require;
*CORE::GLOBAL::require = sub {
#die "require called with @_";
my $package = $_[0];
$package =~ s|/|::|g;
$package =~ s|.pm$||;
if ($packages{$package}) {
my $msg = "mod_perl 2.0 API doesn't include package '$package'.";
my @replacements = @{ $packages{$package}||[] };
if (@replacements) {
$msg .= "'$package' has moved to " .
join " ", map qq/'$_'/, @replacements;
}
croak $msg;
}
else {
my ($package, $filename, $line) = caller;
# call the original function
CORE::require(@_);
#eval "package $package; CORE::require(@_)";
#goto &$sub;
#$sub->(@_);
}
};
}
__________________________________________________________________
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: new mp2 package: Apache::porting
Posted by Stas Bekman <st...@stason.org>.
Stas Bekman wrote:
> Geoffrey Young wrote:
>
>>
>>
>> Stas Bekman wrote:
>>
>>> Now that ModPerl::MethodLookup handles mp1 methods as well, I've
>>> decided to put together a package that will further assist the
>>> porting process. All the needed bits are there already, this package
>>> just makes things a bit easier to setup.
>>>
>>> Notice that its purpose is to assist the porting process, not provide
>>> the backcompatibility layer, so it dies every time it has to say
>>> something.
>>>
>>> I'm considering to put it into the core, next to Apache/compat.pm.
>>
>>
>>
>> this is a nice idea. go ahead and put it in.
>
>
> Thanks Geoff, I have also advanced on the require overriding, still need
> to do some polishing.
Ok, it's in now. Seems that the override of GLOBAL::CORE::require works. Now
if I only could succeed to assign UNIVERSAL::AUTOLOAD before the child_init
phase. It segfaults now if I do that earlier. If you have any ideas how to
resolve it please let me know. See:
http://perl.apache.org/docs/2.0/api/Apache/porting.html#Culprits
__________________________________________________________________
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: new mp2 package: Apache::porting
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>
>
> Stas Bekman wrote:
>
>> Now that ModPerl::MethodLookup handles mp1 methods as well, I've
>> decided to put together a package that will further assist the porting
>> process. All the needed bits are there already, this package just
>> makes things a bit easier to setup.
>>
>> Notice that its purpose is to assist the porting process, not provide
>> the backcompatibility layer, so it dies every time it has to say
>> something.
>>
>> I'm considering to put it into the core, next to Apache/compat.pm.
>
>
> this is a nice idea. go ahead and put it in.
Thanks Geoff, I have also advanced on the require overriding, still need to do
some polishing.
>> I'm also trying to handle the mp1 core packages that are no longer
>> exist, by overriding CORE::require, but I'm stuck at not being able to
>> do 'goto &CORE::require', since in pure perl you can't reference core
>> functions (at least I couldn't figure out how to do that) :( Any idea
>> how to resolve that?
>
>
> personally, I'm less and less convinced that compat.pm is a good idea.
> as mp2 gets more mature, everybody is starting to find that it has
> problems, the biggest being that if you use (or any modules that relies
> on it uses it) it you can't use the mp2 api anymore. so, what we're
> largely seeing is modules skipping compat and porting their code to the
> new api (AuthCookie comes to mind).
That's because it's partially broken. Scott has suggested to use source
filters to make Apache::compat pragmatic, which will change the API only in
the scope of the Apache::compat pragma, but I didn't have a chance to try it out.
> whether you agree with this assessment or not, you mentioned working on
> more pressing issues :) in my mind, compat.pm is at the bottom of the
> list, since it probably won't end up working out anyway, or by the time
> we make it work people will have figured out the new api and it will be
> a non-issue.
I'm not so sure about its irrelevance, time will show. In any case back
porting to Apache::compat shows users how to change their code to use mp2 API,
so it's a good thing.
In any case I'm trying to make the porting less painful. I taught about 6
classes in the last 2 months and most people seems to be less interested in
the new features, but more in the porting process.
__________________________________________________________________
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: new mp2 package: Apache::porting
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
Stas Bekman wrote:
> Now that ModPerl::MethodLookup handles mp1 methods as well, I've decided
> to put together a package that will further assist the porting process.
> All the needed bits are there already, this package just makes things a
> bit easier to setup.
>
> Notice that its purpose is to assist the porting process, not provide
> the backcompatibility layer, so it dies every time it has to say something.
>
> I'm considering to put it into the core, next to Apache/compat.pm.
this is a nice idea. go ahead and put it in.
>
> I'm also trying to handle the mp1 core packages that are no longer
> exist, by overriding CORE::require, but I'm stuck at not being able to
> do 'goto &CORE::require', since in pure perl you can't reference core
> functions (at least I couldn't figure out how to do that) :( Any idea
> how to resolve that?
personally, I'm less and less convinced that compat.pm is a good idea. as
mp2 gets more mature, everybody is starting to find that it has problems,
the biggest being that if you use (or any modules that relies on it uses it)
it you can't use the mp2 api anymore. so, what we're largely seeing is
modules skipping compat and porting their code to the new api (AuthCookie
comes to mind).
whether you agree with this assessment or not, you mentioned working on more
pressing issues :) in my mind, compat.pm is at the bottom of the list,
since it probably won't end up working out anyway, or by the time we make it
work people will have figured out the new api and it will be a non-issue.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org