headers
craig | 1 Jan 2009 06:27
Favicon

problem porting to threaded mode

Trying to shift our largely mod_perl2 web site to an Apache2 threaded  
MPM and perl ithreads.

The following works under the non-threaded prefork MPM:

use DB_File;
my  <at> dbs;       # array of hash references
my  <at> dbModTime; # mod times of db files
my  <at> dbfns;     # array of database pathnames

# executed before fork into child processes
sub post_config {
  my $db;
  my $s = $_[3];
  # tie the DBs and get their mod times
  for ($db = 0; $db <  <at> dbfn; $db++) {
    $dbs[$db] = {};
    tie %{$dbs[$db]}, "DB_File", $dbfn[$db], O_RDONLY
       or die ((caller 0)[3]. " can't tie " . $dbfn[$db] . ": $!");
    $dbModTime[$db] = (CORE::stat($dbfn[$db]))[9]
       or die ((caller 0)[3]. " can't stat " . $dbfn[$db] . ": $!");
} }

The routines that use the databases re-stat the DB files and untie and  
re-tie a DB
that has changed. Each child process must do this for itself.
In the threaded environment, any thread within a process may discover  
that such
an untie and re-tie is necessary, but such an operation should be  
effective
(Continue reading)

Permalink | Reply | 0 comments |
headers
André Warnier | 1 Jan 2009 13:58

Re: HTTP Response Headers fixup

As a complement to this thread, I would like to reproduce an answer 
received on the Tomcat list, from Rainer Jung, the developer/maintainer 
of the mod_jk module.
It explains why I wasn't (and can't) get any success doing what I wanted 
with either mod_headers or a mod_perl connection output filter (which I 
tried).

Rainer Jung :

Apache 2 has hooks for modules, but also filters. The hooks allow to 
interact with request processing at certain stages and the modules 
decide, whether they allow other modules to be called in the same hook.

mod_headers is a filter, which allows to manipulate requests and 
responses much like servlet filters during the reading and writing of 
request resp. response. Thus you can use mod_headers to change headers 
after they are returned by mod_jk.

Unfortunately the Content-Type header is a different beast. Inside 
Apache it is not only a response header, but a more complex data type. 
You can set a different Content-Type header with mod_headers, but since 
the internal structure remains unchanged it will be overwritten again by 
Apache.

As a result I see no way to change an existing character set in a 
Content-Type header.

 > I have tried changing the Content-Type header in a servlet filter under
 > Tomcat. However, that also has the side-effect that the servlet then,
 > for its response, really uses the new character encoding specified in
(Continue reading)

Permalink | Reply | 4 comments |
headers
Torsten Foertsch | 1 Jan 2009 14:32
Picon
Gravatar

Re: HTTP Response Headers fixup

On Thu 01 Jan 2009, André Warnier wrote:
> Unfortunately the Content-Type header is a different beast. Inside
> Apache it is not only a response header, but a more complex data
> type. You can set a different Content-Type header with mod_headers,
> but since the internal structure remains unchanged it will be
> overwritten again by Apache.
>
> As a result I see no way to change an existing character set in a
> Content-Type header.

Try to create a request output filter that sets $r->content_type, 
removes itself and returns DECLINED.

Torsten

--

-- 
Need professional mod_perl support?
Just hire me: torsten.foertsch <at> gmx.net
Permalink | Reply | 3 comments |
headers
André Warnier | 1 Jan 2009 14:41

Re: HTTP Response Headers fixup

Torsten Foertsch wrote:
[...]
> 
> Try to create

-  a request output filter
that I can do

- that sets $r->content_type,
that sounds easy

- removes itself
that, I'm not quite sure how to go about it

- and returns DECLINED.
that is also easy

But thanks anyway.  If that works, it would be a lot easier than the 
response wrapper under Tomcat, or than fixing that damn servlet.
Permalink | Reply | 0 comments |
headers
Mark Hedges | 1 Jan 2009 15:23

a2c controller method names

> > - a lot of times people use references to other
> > structures when they should subclass... these references
> > function only to re-map arguments to other modules,
> > which is ridiculous.
>
>
> Careful on the should.  It can seem extra and possibly
> confusing but isn't always.  Delegation is a valid pattern
> that is cleaner than inheriting at times, particularly
> when you're mixing in a few different modules at the same
> time to do something.  If you're merely extending an
> existing, then yes, inheritance is good. 
> Multi-directional multi-inheritance can get really
> messy... (as I dug myself out of in development recently
> myself)  if you haven't read, at least scan...

Regarding your comment about inheritance vs. references -
something I hadn't thought much about.  A) I need to prefix
all my internal method names with 'a2c_' to stay out of
the controller namespace.  B) You can't have any controller
subroutines with the same names as anything in the
Apache2::Request* family, which (slightly) limits your
choice of allowable URL's.  But I think it's worth it so
that '$self' is the Apache object.  What do people think?

I wonder how easy it would be to add controller subroutine
attributes for which ones are allowed or not, ala Catalyst,
instead of the controller having to provide an
'allowed_methods' method.
(Continue reading)

Permalink | Reply | 5 comments |
headers
André Warnier | 1 Jan 2009 21:26

Re: HTTP Response Headers fixup

Torsten Foertsch wrote:
> On Thu 01 Jan 2009, André Warnier wrote:
>> Unfortunately the Content-Type header is a different beast. Inside
>> Apache it is not only a response header, but a more complex data
>> type. You can set a different Content-Type header with mod_headers,
>> but since the internal structure remains unchanged it will be
>> overwritten again by Apache.
>>
>> As a result I see no way to change an existing character set in a
>> Content-Type header.
> 
> Try to create a request output filter that sets $r->content_type, 
> removes itself and returns DECLINED.
> 
Torsten, you're the greatest.
It works perfectly, even without having the filter remove itself (which 
I did not know how to do).

Here is the minimal filter :

package AM::FixupContentType;
# Fixes bad servlet-generated Content-Type header, when used in 
iso-latin-2 environment.
# Idea from Torsten Foetsch.

$AM::FixupContentType::VERSION = '0.01';

use strict;
use warnings FATAL => 'all';
use mod_perl2 2.000001;
(Continue reading)

Permalink | Reply | 1 comment |
headers
Mark Hedges | 1 Jan 2009 22:22

Re: a2c controller method names


On Thu, 1 Jan 2009, Mark Hedges wrote:
>
> Regarding your comment about inheritance vs. references -
> something I hadn't thought much about.  A) I need to prefix
> all my internal method names with 'a2c_' to stay out of
> the controller namespace.  B) You can't have any controller
> subroutines with the same names as anything in the
> Apache2::Request* family, which (slightly) limits your
> choice of allowable URL's.  But I think it's worth it so
> that '$self' is the Apache object.  What do people think?

Talking to myself again. I think I can make it work either
way.  Apache2::Controller won't use Apache2::Request as a
base, but it will still instantiate the Apache2::Request
object and put it in $self->{r}.  Then if you want to use
Apache2::Request as a base in your controller module to
access those methods via $self, you can.  Otherwise, don't.

Mark
Permalink | Reply | 2 comments |
headers
David Ihnen | 2 Jan 2009 17:47

Re: a2c controller method names

Mark Hedges wrote:
> On Thu, 1 Jan 2009, Mark Hedges wrote:
>   
>> Regarding your comment about inheritance vs. references -
>> something I hadn't thought much about.  A) I need to prefix
>> all my internal method names with 'a2c_' to stay out of
>> the controller namespace.  B) You can't have any controller
>> subroutines with the same names as anything in the
>> Apache2::Request* family, which (slightly) limits your
>> choice of allowable URL's.  But I think it's worth it so
>> that '$self' is the Apache object.  What do people think?
>>     
>
> Talking to myself again. I think I can make it work either
> way.  Apache2::Controller won't use Apache2::Request as a
> base, but it will still instantiate the Apache2::Request
> object and put it in $self->{r}.  Then if you want to use
> Apache2::Request as a base in your controller module to
> access those methods via $self, you can.  Otherwise, don't.
>   

For a compromise between them you could also do the 'fake delegate' 
where your AUTOLOAD subroutine checks if $self->{r}->can(($AUTOLOAD =~ 
/::(.+?)$/)[0]) returns a CODE ref and delegates the call to that routine.

The downside is that you're overlapping namespaces, as you mentioned 
before, which has its own complications.

I think you're right, its better to be explicit about choosing the 
request object when you want to do a request object method.  That works
(Continue reading)

Permalink | Reply | 1 comment |
headers
David Ihnen | 2 Jan 2009 17:59

Re: a2c controller method names

Mark Hedges wrote:
> I wonder how easy it would be to add controller subroutine
> attributes for which ones are allowed or not, ala Catalyst,
> instead of the controller having to provide an
> 'allowed_methods' method.
>   
Sounds like something JSON::RPC::Server::CGI does with :private and 
:public modifiers on the subroutine definitions, I think they're called 
'fields', might be worth a look to see how they did that.

A thought on this matter particularly.

Though JSON::RPC::Server::CGI was just fine about calling my methods 
with its dispatch, it could not find the ability to instantiate my 
object first.  In fact, it always called them in static context with 
itself as the first parameter, which I found quite limiting.

This simply didn't work for my object structure and way I wanted to OOP 
the program.  (I got around it by making a static class that implimented 
an allowed_subroutines function that instantiated and effectively 
manually delegated calls to the appropriate subroutines, blowing the 
nice :public list right into irrelevancy)

It would have been nicer as a dispatching framework if it either A. 
would instantiate my object (through a defined interface like 
->new($server)) first THEN call the method or B. defined a 
hook-handle/decline interface not that different from apache so that I 
can custom define how you check for availability (rather than the 
:public list or ->can), instantiate if relevant, and call subroutines in 
my particular object.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Mark Hedges | 2 Jan 2009 18:10

Re: a2c controller method names


On Fri, 2 Jan 2009, David Ihnen wrote:

> Mark Hedges wrote:
> > I wonder how easy it would be to add controller
> > subroutine attributes for which ones are allowed or not,
> > ala Catalyst, instead of the controller having to
> > provide an 'allowed_methods' method.
> >
>
> It would have been nicer as a dispatching framework if it
> either A. would instantiate my object (through a defined
> interface like ->new($server)) first THEN call the method
> or B. defined a hook-handle/decline interface not that
> different from apache so that I can custom define how you
> check for availability (rather than the :public list or
> ->can), instantiate if relevant, and call subroutines in
> my particular object.
>
> I guess I'm saying consider the interface flexibility as
> you design the framework - there may be interest in doing
> something in the realm of setup before calling the method.

I see.  I guess that was something like my original thought
of making you provide allowed_methods() which returns an
array.  It's not much harder to type than :public
everywhere, gives you a central list ("which methods are
allowed?" is easier to answer from looking at the top of the
package), gives you flexibility/dynamism/inheritance, and
the results get cached by Apache2::Controller::Funk in a
(Continue reading)

Permalink | Reply | 0 comments |

Gmane