Re: mod_perl2 compiling error
I could never install Apache2::Request successfully. I'm running RH Linux as4,2.6.9 kernel. 2007/8/23, Manoj Bist <[EMAIL PROTECTED]>: > Hi Jon, > > Which OS platform are you working on? > > On platforms like ubuntu linux you can get precompile packages for all > these modules. > You just need to do: sudo apt-get install . > > An option like this may already be available on your development platform. > > -Manoj. > > On 8/22/07, jónJósef Bjarnason <[EMAIL PROTECTED]> wrote: > > Thanks. > > > > I had to compile Perl again, then mod_perl2. > > mod_perl works now, nothing else thoguh, > > Problems compiling DBI, DBD..etc. (MySql on a different machine) > > > > I´m getting therevery slowly. > > Thank you all for your time and help. > > > > Regards > > Jon > > > > > > Þann 8/22/2007, skrifaði "Manoj Bist" <[EMAIL PROTECTED]>: > > > > >In general to create a shared object the constituent object files > > >should be PICable. Look for Makefile(s) which compile the individual > > >source files. It would have a variable like 'CFLAGS'. Adding '-fPIC' > > >to it should take care of it. > > > > > > > > >On 8/21/07, jónJósef Bjarnason <[EMAIL PROTECTED]> wrote: > > >> When running make for mod_perl 2.0.3 I get an error telling me to use > > >> -fPIC option. > > >> Does anyone know where to put that compiling option ? > > >> > > >> Regards > > >> Jon > > >> > > >> Apache 2.2.4 > > >> Perl 5.8.8 > > >> mod_perl 2.0.3 > > >> Ubuntu 6.06 LTS 64bit AMD > > >> > > >> when compiling -o mod_perl.so: > > >> `a local symbol' can not be used when making a shared > > >> object; recompile with -fPIC > > >> > > >
RE: Special characters
Hi everyone,
Thanks for everyones help and suggestions. I found the problem with the special
characters. I guess mod_perl doesn't take the environment variables from the
server so you have to set them in the httpd.conf file. The code I used to fix
it is below:
PerlSetEnv NLS_LANG AMERICAN_AMERICA.WE8ISO8859P1 PerlPassEnv NLS_LANG
Once again thanks for your help.
Dan King
Software Developer
Canadian Resident Matching Service
613.237.0075 ext. 241
(Toll free) 877.CARMS.42
171 Nepean Street, Suite 300
Ottawa, ON, CANK2P 0B4
www.carms.ca
This e-mail message, including any attachments, is for the sole use of the
intended recipients and may contain confidential and or privileged information.
If you are not the intended recipient or this information has been forwarded
in error, please contact the sender by reply e-mail and destroy copies of the
original message. Ce message (incluant toute pièce jointe) s'adresse
uniquement au(x) destinataire(s) prévu(s) ou à une personne autorisée à le
recevoir en son (leur) nom. Il pourrait contenir des renseignements
confidentiels ou protégés. Si vous l'avez reçu par erreur, nous vous prions
d'en informer l'auteur dans les meilleurs délais, de ne pas divulguer son
contenu et de le supprimer de votre système. Merci.
-Original Message-
From: Manoj Bist [mailto:[EMAIL PROTECTED]
Sent: August 21, 2007 3:16 PM
To: Dan King
Cc: modperl@perl.apache.org
Subject: Re: Special characters
You need to know the encoding of the characters you are using in perl
and handle them accordingly.
The following link should have sufficient information to help you
trouble shoot this.
http://search.cpan.org/~jhi/perl-5.8.0/pod/perluniintro.pod
On 8/21/07, Dan King <[EMAIL PROTECTED]> wrote:
>
>
>
>
> I am having issues running a web application, called OTRS, that uses DBI and
> DBD::Oracle. When I insert special characters, such as é or â they show up
> as question marks in the database when looking at them from sqlplus or
> through the web application. I am running the web app on Apache v1 with an
> Oracle 10g backend both on Solaris 9. The reason I am asking the question
> here is I am wondering if mod perl does any conversion of text that is typed
> into a text box.
>
>
>
> I have been able to successfully insert and read the special characters
> using sqlplus from the command line of the server running the web app,
> apache and Oracle as well as creating a small perl test script that looks as
> follows:
>
>
>
>
>
>
>
> #!/usr/local/bin/perl
>
>
>
> use warnings;
>
>
>
> use strict;
>
>
>
> use Data::Dumper;
>
>
>
> use DBI;
>
>
>
> use DBD::Oracle;
>
>
>
>
>
>
>
> my $dbh = DBI->connect("dbi:Oracle:host=localhost;sid=QAT",
> "rm_ticket", "rm_ticket");
>
>
>
> my $sql = qq{ UPDATE signature SET text='çè' WHERE id=1 };
>
>
>
> my $sth = $dbh->prepare($sql);
>
>
>
> $sth->execute();
>
>
>
> $sth->finish();
>
>
>
> $dbh->disconnect;
>
>
>
>
>
>
>
> The reading script looks as follows:
>
>
>
>
>
>
>
> #!/usr/local/bin/perl
>
>
>
> use warnings;
>
>
>
> use strict;
>
>
>
> use Data::Dumper;
>
>
>
> use DBI;
>
>
>
> use DBD::Oracle;
>
>
>
>
>
>
>
> my $dbh = DBI->connect("dbi:Oracle:host=localhost;sid=QAT",
> "rm_ticket", "rm_ticket");
>
>
>
> my $sql = qq{ SELECT text from signature };
>
>
>
> my $sth = $dbh->prepare($sql);
>
>
>
> $sth->execute();
>
>
>
> my($text);
>
>
>
> $sth->bind_columns(undef, \$text);
>
>
>
> print "Text of signature:\n\n";
>
>
>
> while( $sth->fetch() ) {
>
>
>
> print "Object: $text\n";
>
>
>
> }
>
>
>
> $sth->finish();
>
>
>
> $dbh->disconnect;
>
>
>
>
>
>
>
> Does anyone know why I can successfully write and read from the database
> when I am not using the web application but when I use the web application
> the special characters fail to work properly?
>
>
>
>
>
> Dan King
> Software Developer
> Canadian Resident Matching Service
> 613.237.0075 ext. 241
> (Toll free) 877.CARMS.42
> 171 Nepean Street, Suite 300
> Ottawa, ON, CANK2P 0B4
> www.carms.ca
>
>
>
> This e-mail message, including any attachments, is for the sole use of the
> intended recipients and may contain confidential and or privileged
> information. If you are not the intended recipient or this information has
> been forwarded in error, please contact the sender by reply e-mail and
> destroy copies of the original message. Ce message (incluant toute pièce
> jointe) s'adresse uniquement au(x) destinataire(s) prévu(s) ou à une
> personne autorisée à le recevoir en son (leur) nom. Il pourrait contenir des
> renseignements confidentiels ou protégés. Si vous l'avez reçu par erreur,
> nous vous prions d'en informer l'auteur dans les meilleurs délais, de ne pas
> divulguer son contenu et de le supprimer de votre système. Merci.
>
>
Re: Special characters
Dan King wrote: > I guess mod_perl doesn't take the environment variables from the server so > you have to set them in the httpd.conf file. The code I used to fix it is > below: That's not exactly true. From the mod_perl docs: However, Apache (or mod_perl) don't pass on environment variables from the shell by default; you'll have to specify these using either the standard PassEnv or mod_perl's PerlPassEnv directives. It's not that they can't, it's that by default they don't pass anything you don't tell it to. And it's not mod_perl, it's Apache. > PerlSetEnv NLS_LANG AMERICAN_AMERICA.WE8ISO8859P1 PerlPassEnv NLS_LANG If you're setting NLS_LANG correctly in your environment, you can simply make that PerlPassEnv NLS_LANG Or if you want to make it available to anything else that might need it PassEnv NLS_LANG -- Michael Peters Developer Plus Three, LP
Re: Internal Server Error
On 8/21/07, Jeff Pang <[EMAIL PROTECTED]> wrote:
> >PerlHandler Package::Name
> >
> >instead of:
> >
> >PerlHandler Package::Name->handler
> >
>
> So on the first case,we need to write the handler as
> sub handler { my $r = shift; ...}
> because Apache may call the function directly as Package::Name::handler.
>
> on the second case,we write handler as,
> sub handler { my $class = shift; my $r = shift; ... }
> because '->' is a method calling.
For method handlers, you also have to declare it differently.
In mod_perl 1:
sub handler ($$) {
In mod_perl 2:
sub handler : method {
- Perrin
Re: Internal Server Error
On 8/21/07, Foo JH <[EMAIL PROTECTED]> wrote: > Are there any technical advantages with either method, or is it a > TIMTOWDI option given to the developers? You can structure your code differently with method handlers, in ways that appeal to some people. There's an example here: http://modperlbook.org/html/ch06_12.html - Perrin
Re: Internal Server Error
2007/8/24, Perrin Harkins <[EMAIL PROTECTED]>:
> On 8/21/07, Jeff Pang <[EMAIL PROTECTED]> wrote:
> > >PerlHandler Package::Name
> > >
> > >instead of:
> > >
> > >PerlHandler Package::Name->handler
> > >
> >
> > So on the first case,we need to write the handler as
> > sub handler { my $r = shift; ...}
> > because Apache may call the function directly as Package::Name::handler.
> >
> > on the second case,we write handler as,
> > sub handler { my $class = shift; my $r = shift; ... }
> > because '->' is a method calling.
>
> For method handlers, you also have to declare it differently.
>
> In mod_perl 1:
> sub handler ($$) {
>
why it need prototype in mp1's method handler?
Re: Internal Server Error
On 8/23/07, Foo JH <[EMAIL PROTECTED]> wrote: > I've read http://perldoc.perl.org/attributes.html about attributes, but > it does not seem to suggest that tagging the method attribute to > subroutine has any programming advantages, unless you're interested to > list the subroutines with that attribute. But I suspect there's more to it. It tells mod_perl that the handler should be called as a method. http://perl.apache.org/docs/2.0/user/porting/compat.html#Method_Handlers - Perrin
Re: Internal Server Error
Hello Perrin,
I'm interested in how you defined your handler with the 'method' attribute:
sub handler : method {
...
I've read http://perldoc.perl.org/attributes.html about attributes, but
it does not seem to suggest that tagging the method attribute to
subroutine has any programming advantages, unless you're interested to
list the subroutines with that attribute. But I suspect there's more to it.
Perhaps you can clue me in on this?
Perrin Harkins wrote:
On 8/21/07, Jeff Pang <[EMAIL PROTECTED]> wrote:
PerlHandler Package::Name
instead of:
PerlHandler Package::Name->handler
So on the first case,we need to write the handler as
sub handler { my $r = shift; ...}
because Apache may call the function directly as Package::Name::handler.
on the second case,we write handler as,
sub handler { my $class = shift; my $r = shift; ... }
because '->' is a method calling.
For method handlers, you also have to declare it differently.
In mod_perl 1:
sub handler ($$) {
In mod_perl 2:
sub handler : method {
- Perrin
Re: Internal Server Error
On 8/23/07, Jeff Pang <[EMAIL PROTECTED]> wrote: > why it need prototype in mp1's method handler? Subroutine attributes did not exist before perl 5.6. - Perrin
