Search results for query: *

Try compiling apache 2.0 See if that works for you. So far you have tried compiling 1.3.x and you have tried a binary installation. Try downloading the latest 2.0 (not 2.1) and executing this ./configure --prefix=/usr/local/apache2

No man, read what I wrote. You are using ./configure --prefix=/usr/local/lib/apache why are you installing apache into a LIBRARY DIRECTORY? You have to understand that this is not a place for apps. Run it like this ./configure --prefix=/usr/local/apache and it may give you a different...

Why are you installing apache into the libs directory? That may be causing a conflict since apache itself will want to install libs there and it might be getting circular. Try /usr/local/apache instead for your prefix. its a long show but its a shot :)

No, ths java servlet route is pretty easy. Directly calling a C or COM lib will be even harder. You get into library wrapping in XS etc etc.

Your taking many distinct concepts and meshing them into one thing that is not really a real thing. 1) You can't call java libs directly from perl 2) You can't pass in memory structures (variables) between Java and Perl (at least not easily) You need perl to act like a webbrowser and request a...

You are trying to do something technical. Thi is not jargon. Look,the servlet is running as a webapp. You can't just "call" the library, you have to access the webapp. This is the core concept here. The libary must run in a servlet context via a webserver. This means you must make perl emulate...

Using $sth->{'mysql_insertid'}; is a mysql specific construct and will not cross to other databases. Not a big deal if your doing one off code but in any sustainable system that sort of dependancy is not a super fun thing. Don';t get me wrong, I do it all the time and it hurts :)

A simple VBSCript app is probably your best bet. I'd look in that direction.

modperl is a tool that integrates perl directly into the apache webserver resulting in huge speedups and lots of new functionality. One of those functions is the ability to continue to maintain data between requests. With CGI after each request all your data is lost or unreliable.

CGI is not going to help you here, CGI requires more then perl, it requires a webserver and you won't be installing that on your users IPAQ's! I agree with Paul, build a custom app, you can even do it in VBScript probably and still run it in a webcontext, just locally.

Use Net::SMTP, your probably missing some headers AOL and Yahoo require. Why hand assemble SMTP protocol when there are perfectly nice modules to handle that for you?

%D is in milliseconds, %T is in seconds. Both should give total client connection time according to the docs but it does seem a bit vague, test it and let us know.

Since your using RPM your kind of in the worst spot. I suggest telling redhat to completely remove apache and modperl, going into the perl directory and removing the 'Apache' directory (where modperl puts its apache module) and then reinstalling both. You have a version conflict in your core...

What configure options are you passing?

Not sure on the constants stuff but your take on the globals is correct. Keep in mind that these are all local to the process running perl. So in a web context such global declarations are not shared across apache memory space. You can use modperl for that if you'd like. I've built some high...

You can't really just 'call' java classes and expect them to act like a servlet. A servlet is basically a specific java class in a web context, similiar to the difference between a 'cgi script' and a 'perl script'. The only way to handle this cleanly is to use LWP to make your POST or GET...

Just a note, this practice is discouraged if you want to make your code cleanly cross-database compatible. As a victim of many migrations from mysql to other systems (oracle/firebird etc) this can really hurt. Minimally you should isolate your database calls into a single module so that you...

Eclipse IDE has a perl plugin now as well. I havent tried it but have heard good things.

At the simplest level do this. 1) Push all requests to Machine A (Apache 2) 2) Define a virtual host for each site on Machine A 3) For the tomcat site instead of having a DocumentRoot on Machine A, define a ProxyPass configuration that passes all of these requests to Machine B Take a look in...

I have one CATALINA_BASE but virtual hosts don't care about that. A VHOST in server.xml can be anywhere on your box and function. For us, each developer has their websites directly off their home directory. That directory is placed into the vhost context in server.xml and everyone is happy...