Felipe de Jesús Molina Bravo wrote:
Try rebuilding apache and mod_perl - it may be trying to load a
version of DbXML at runtime different than what it was built
with. I've seen similar problems in the past and rebuilding
mp/httpd is usually a good fix after el
I'm not 100% sure of this, but looking at the messages below, mentioning
"Apache" rather than "Apache2", I have the feeling that your application
is trying to use mod_perl 1.xxx, rather than 2.xxx.
Have a look here :
http://perl.apache.org/docs/2.0/rename.html
green tom wrote:
I'm trying to ru
I'm trying to run the dev versions of an website in Apache 2.2.9, and
using mod_perl 2.0 (dso mode)(on fedora 9 , for reference). and my web
server started with no Error prompted .but when I run one of the page
code ,it failed .i checked the error logs and got the error below :
--
On Oct 15, 2008, at 11:11, Cosimo Streppone wrote:
On Wed, Oct 15, 2008 at 12:31 PM, Mark wrote:
[...]
Then Perrin wrote:
JavaScript is okay, but can be a problem when people hit back
expecting to use the form again and the button is still disabled.
You could always trigger some javascript
On Wed, Oct 15, 2008 at 2:44 AM, Shibi NS <[EMAIL PROTECTED]> wrote:
> CGI.pm version 3.15
Update.
- Perrin
Mark Stosberg wrote:
So how might an implementation look?
I would either make the uuid the primary key (might affect performance since it's not an integer,
but a string) or a unique key for the same table. Then you don't have anything else to keep track of
(no extra tables, etc).
Every so
> Take some elements from the form and search for an add in the past
> . We did one recently where we took the email address,
> recipient and amount from the form and then made sure that the same
> data hadn't already been submitted in the last 24 hours - working on
> the principle that a
On Wed, Oct 15, 2008 at 12:31 PM, Mark wrote:
We had a "double submit" bug that allowed a form to be submitted twice
when we weren't fully prepared for that. [...]
One approach we are considering is change the submit action on forms
with JavaScript, so it disables the submit button
That's th
On Wed, 15 Oct 2008 13:51:21 -0400
Michael Peters <[EMAIL PROTECTED]> wrote:
> Mark Stosberg wrote:
>
> > At one point in the past I did a variation of this where we put the next ID
> > of
> > a related database sequence in the form, and this would become the new
> > primary
> > key when insert
On 15 Oct 2008, at 18:49, Mark Stosberg wrote:
On Wed, 15 Oct 2008 12:41:55 -0400
"Perrin Harkins" <[EMAIL PROTECTED]> wrote:
On Wed, Oct 15, 2008 at 12:31 PM, Mark Stosberg
<[EMAIL PROTECTED]> wrote:
We had a "double submit" bug that allowed a form to be submitted
twice when we
weren't fu
Mark Stosberg wrote:
At one point in the past I did a variation of this where we put the next ID of
a related database sequence in the form, and this would become the new primary
key when inserted, and it would of course not allow the same primary key to be
used twice. That worked, but I realize
On Wed, 15 Oct 2008 12:41:55 -0400
"Perrin Harkins" <[EMAIL PROTECTED]> wrote:
> On Wed, Oct 15, 2008 at 12:31 PM, Mark Stosberg <[EMAIL PROTECTED]> wrote:
> > We had a "double submit" bug that allowed a form to be submitted twice when
> > we
> > weren't fully prepared for that. We are still rese
On Wed, Oct 15, 2008 at 12:31 PM, Mark Stosberg <[EMAIL PROTECTED]> wrote:
> We had a "double submit" bug that allowed a form to be submitted twice when we
> weren't fully prepared for that. We are still researching the best practices
> to
> address this a general case. One approach we are conside
On Tue, 30 Sep 2008 10:06:26 -0400
Mark Stosberg <[EMAIL PROTECTED]> wrote:
> On Mon, 29 Sep 2008 17:04:29 -0400
> "Perrin Harkins" <[EMAIL PROTECTED]> wrote:
>
> > On Mon, Sep 29, 2008 at 3:00 PM, Mark Stosberg <[EMAIL PROTECTED]> wrote:
> > > We have a large, busy, database application that rel
On Tue 14 Oct 2008, Torsten Foertsch wrote:
> On Tue 14 Oct 2008, André Warnier wrote:
> > When I try this, I get an Apache error with the following logfile
> > message : [Tue Oct 14 16:10:40 2008] [error] [client
> > 84.158.163.207] $r->add_config() has failed: SetHandler not allowed
> > here at /
On Wed 15 Oct 2008, André Warnier wrote:
> > I think you're wanting:
> >
> > $r->set_handlers(PerlFixupHandler => sub
> > {$_[0]->handler('modperl')});
>
> Yes. That works.
Better to return something sane from the handler:
sub {$_[0]->handler('modperl');0} # 0==Apache2::Const::OK
Also co
Thanks.
Duh.
Clinton Gormley wrote:
$r->set_handlers(PerlFixupHandler => \{$_[0]->handler('modperl')});
The funny thing is, the way I understand that code above is to mean :
"take a reference to the piece of code between the curly brackets, and
pass that code reference as the 2d argume
> $r->set_handlers(PerlFixupHandler => \{$_[0]->handler('modperl')});
> The funny thing is, the way I understand that code above is to mean :
> "take a reference to the piece of code between the curly brackets, and
> pass that code reference as the 2d argument to $r->set_handlers()".
> But
Help ! (please)
To make a long story short, I created an Apache/mod_perl module for AAA,
which after major help from Torsten Foertsch now works fine... on one
system, but not on another relatively similar one. The module is called
AUTH::StarLogCookie.
the critical line is line 419 of the mo
19 matches
Mail list logo
