CGIServlet - php

2011-09-02 Thread throwsCode 

Hi all:

I'm trying to implement PHP on tomcat 7.0.20 with no luck.  Does anyone know
how I can tell whether the CGIServlet is running?  

I uncommented all of the sections indicated in the Tomcat document.

Though I think I am making the right call, I am receiving a 400 error.

CALL made form file 'index.html'


FILE located in directory WEB-INF/cgi/echoInfo.php
  

One other thing that concerns me.  In every other option for running php
including Apache there is some direction with regard to where you must place
the php.ini file.  I have found no direction for the php.ini file in the
Tomcat documentation or on the Internet for specifically Tomcat.  Does
anyone know how Tomcat or Eclipse, is pointed at the php.ini file?


Your assistance is greatly appreciated.

TC
-- 
View this message in context: 
http://old.nabble.com/CGIServlet---php-tp32390310p32390310.html
Sent from the Tomcat - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: CGIServlet - php

2011-09-02 Thread throwsCode 

Hi all:

An update I entered the following directly into my browser:
  http://localhost:8080/secondDynamicWeb/cgi-bin/echoInfo.php

And got the a 404 Error - Servlet CGI not available.

>From this it appears that the servlet is not available but has been defined
because the URL pattern /cgi-bin/ appears to call the Servlet as defined in
the web.xml

Which I have set as follows:


cgi
   
org.apache.catalina.servlets.CGIServlet

  debug
  6


  cgiPathPrefix
  WEB-INF/cgi


  executable
  

 5

 
AND 


cgi
/cgi-bin/*


I would appreciate any advice you might offer.

TC





-- 
View this message in context: 
http://old.nabble.com/CGIServlet---php-tp32390310p32390388.html
Sent from the Tomcat - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: CGIServlet - php

2011-09-02 Thread throwsCode 

Hi Hassan:

I am predominantly a JSF/Facelets/IceFaces developer but recently I have
been asked to assist some non-profits which calls for php.  I would like to
use my existing development environment which is Eclipse and Tomcat.  If I
can discover the secrets to php in Tomcat that would be the best for me.

I really hate when everyone says they support a particular framework or
language but provide no examples and sketchy instructions.  It would be nice
to be a part of a large organization with expertise in each and every area.

I'll work on it for another day or two before I abandon the Tomcat approach.

Thanks for you comments.

TC
-- 
View this message in context: 
http://old.nabble.com/CGIServlet---php-tp32390310p32390812.html
Sent from the Tomcat - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: CGIServlet - php

2011-09-03 Thread throwsCode 

Thanks Hassan:

I could use all the luck I can get.  I was on NetBeans a couple years back
but had to bail when they pretty much abandoned web developers.  Oracle put
the nail in the coffin but it all began with the killing of Woodstock and
the Visual Development Environment and that is on Sun.  

Looking back I never should have jumped on that Woodstock ride.  Too soon
old, too late smart.

TC
-- 
View this message in context: 
http://old.nabble.com/CGIServlet---php-tp32390310p32392261.html
Sent from the Tomcat - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: CGIServlet - php

2011-09-03 Thread throwsCode 

Wow thanks Konstantin a lot of good questions and suggestions.  Please give
me some time to put together a cogent reply.  I have looked at hundreds of
documents and thousands of Internet pages so it will take me some time to
filter the ones that I thought applied and actually tried.

With regard to Tomcat 7 the main document is CGI How To (very small) this I
believe I implemented, no joy.  The second document that had some value was
the CGIServlet Class document.  I did go through FAQ and copied some stuff
but its not at my finger tips, I'll include the references in my reply.  

With regard to your comments on php.ini it is exactly this lack of clarity
that frustrates me.  You start moving each of these pieces of the puzzle to
different places in the system based on well meaning comments from the
Internet or any other source and you are sure to become lost.  Basically its
a hope I get the right combination approach.  

Don't get me wrong I am most thankful for the suggestions but it is not the
kind of direction I hope to get from an Apache project.  I know the
CGIServlet document defines itself as a beta effort - which apparently it
has been for four or five years.  I think its time for Tomcat to decide
emough already our core target market does not need this capability, drop
it; or maybe it is important to a significant portion of our market, support
it.  Living in the land of in between is serving no one well.

My desire is to make this capability available in my development environment
(Eclipse / Tomcat).  Essentially I want to test as much of the php
component/application as I can before deploying them to a client's
production environment which I doubt will be Tomcat.

Much thanks, please expect a reply to your questions by Monday.

TC
-- 
View this message in context: 
http://old.nabble.com/CGIServlet---php-tp32390310p32393205.html
Sent from the Tomcat - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: CGIServlet - php

2011-09-03 Thread throwsCode 

Terence, Ken, Mark thanks for all your input.  Much to consider.

Mark your the first person who replied who sounds like they have actually
run php and tomcat.  Despite your concerns, this gives me the confidence
that i can get it running with all this help.

Perhaps I'm wrong but I don't think at this point I need to concern myself
with the lack of security as it relates to Tomcat.  I am setting up a pure
development environment.  I don't know what the production server
environment will be.  I will of course pay attention to the many security
risks defined in the PHP manual.

Zend Debugging is setup and working as far as phpScript is concerned.  If I
can get the Tomcat piece to work I think I will have a good development
environment.

I'll let everyone know how this all turns out in the next couple days.

Thanks much.

TC
-- 
View this message in context: 
http://old.nabble.com/CGIServlet---php-tp32390310p32394151.html
Sent from the Tomcat - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: CGIServlet - php

2011-09-04 Thread throwsCode 

Thanks Mark:

If I'm reading this right you did in a couple hours what I have been working
on for eight days.  FM!

Retracing my steps is proving difficult, so many paths taken and abandoned.

Thanks for demonstrating one definitive solution.

TC
-- 
View this message in context: 
http://old.nabble.com/CGIServlet---php-tp32390310p32396552.html
Sent from the Tomcat - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

JULI prefix not recognized?

2011-06-22 Thread throwsCode 

Hi all;

I sure that is going to turnout to be a stupid question but I've played with
it for two days and made no progress.  I can create a JULI handler as long
as I don't apply a prefix, here is the logging.properties file (keeping it
as simple as possible):

THIS WORKS FINE 
---
handlers = org.apache.juli.FileHandler, java.util.logging.ConsoleHandler
.handlers = org.apache.juli.FileHandler, java.util.logging.ConsoleHandler
org.apache.juli.FileHandler.level = FINE
org.apache.juli.FileHandler.directory = ${user.home}
org.apache.juli.FileHandler.prefix = localhost.
java.util.logging.ConsoleHandler.level = FINE
java.util.logging.ConsoleHandler.formatter =
java.util.logging.SimpleFormatter
---

THIS FAILS 
---
handlers = 1pae.org.apache.juli.FileHandler,
java.util.logging.ConsoleHandler
.handlers = org.apache.juli.FileHandler, java.util.logging.ConsoleHandler
1pae.org.apache.juli.FileHandler.level = FINE
1pae.org.apache.juli.FileHandler.directory = ${user.home}
1pae.org.apache.juli.FileHandler.prefix = localhost.
java.util.logging.ConsoleHandler.level = FINE
java.util.logging.ConsoleHandler.formatter =
java.util.logging.SimpleFormatter
---

THE FOLLOWING ERROR OCCURS ON TOMCAT STARTUP:
---
Can't load log handler "1pae.org.apache.juli.FileHandler"
java.lang.ClassNotFoundException: 1pae.org.apache.juli.FileHandler
java.lang.ClassNotFoundException: 1pae.org.apache.juli.FileHandler
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.util.logging.LogManager$3.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.util.logging.LogManager.loadLoggerHandlers(Unknown Source)
at java.util.logging.LogManager.initializeGlobalHandlers(Unknown Source)
at java.util.logging.LogManager.access$900(Unknown Source)
at java.util.logging.LogManager$RootLogger.addHandler(Unknown Source)
at java.util.logging.LogManager$3.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.util.logging.LogManager.loadLoggerHandlers(Unknown Source)
at java.util.logging.LogManager.addLogger(Unknown Source)
at java.util.logging.LogManager$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.util.logging.LogManager.(Unknown Source)
at java.util.logging.Logger.getLogger(Unknown Source)
at org.apache.juli.logging.DirectJDKLog.(DirectJDKLog.java:71)
at 
org.apache.juli.logging.DirectJDKLog.getInstance(DirectJDKLog.java:178)
at org.apache.juli.logging.LogFactory.getInstance(LogFactory.java:171)
at org.apache.juli.logging.LogFactory.getInstance(LogFactory.java:243)
at org.apache.juli.logging.LogFactory.getLog(LogFactory.java:298)
at org.apache.catalina.startup.Bootstrap.(Bootstrap.java:55)

The tomcat-juli.jar is available as demonstrated in the first example that
works.  Why is the prefix not being recognized?

Your assistance is greatly appreciated.

TC
-- 
View this message in context: 
http://old.nabble.com/JULI-prefix-not-recognized--tp31907205p31907205.html
Sent from the Tomcat - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: JULI prefix not recognized?

2011-06-22 Thread throwsCode 

Thanks Konstantin:

I thought the JULI Classes automatically replaced the java.util.logging
Classes with the same name.  Thanks for catching that, I'll checkout
catalina.sh and try to figure this out.

TC



throwsCode wrote:
> 
> Hi all;
> 
> I sure that is going to turnout to be a stupid question but I've played
> with it for two days and made no progress.  I can create a JULI handler as
> long as I don't apply a prefix, here is the logging.properties file
> (keeping it as simple as possible):
> 
> THIS WORKS FINE 
> ---
> handlers = org.apache.juli.FileHandler, java.util.logging.ConsoleHandler
> .handlers = org.apache.juli.FileHandler, java.util.logging.ConsoleHandler
> org.apache.juli.FileHandler.level = FINE
> org.apache.juli.FileHandler.directory = ${user.home}
> org.apache.juli.FileHandler.prefix = localhost.
> java.util.logging.ConsoleHandler.level = FINE
> java.util.logging.ConsoleHandler.formatter =
> java.util.logging.SimpleFormatter
> ---
> 
> THIS FAILS 
> ---
> handlers = 1pae.org.apache.juli.FileHandler,
> java.util.logging.ConsoleHandler
> .handlers = org.apache.juli.FileHandler, java.util.logging.ConsoleHandler
> 1pae.org.apache.juli.FileHandler.level = FINE
> 1pae.org.apache.juli.FileHandler.directory = ${user.home}
> 1pae.org.apache.juli.FileHandler.prefix = localhost.
> java.util.logging.ConsoleHandler.level = FINE
> java.util.logging.ConsoleHandler.formatter =
> java.util.logging.SimpleFormatter
> ---
> 
> THE FOLLOWING ERROR OCCURS ON TOMCAT STARTUP:
> ---
> Can't load log handler "1pae.org.apache.juli.FileHandler"
> java.lang.ClassNotFoundException: 1pae.org.apache.juli.FileHandler
> java.lang.ClassNotFoundException: 1pae.org.apache.juli.FileHandler
>   at java.net.URLClassLoader$1.run(Unknown Source)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at java.net.URLClassLoader.findClass(Unknown Source)
>   at java.lang.ClassLoader.loadClass(Unknown Source)
>   at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
>   at java.lang.ClassLoader.loadClass(Unknown Source)
>   at java.util.logging.LogManager$3.run(Unknown Source)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at java.util.logging.LogManager.loadLoggerHandlers(Unknown Source)
>   at java.util.logging.LogManager.initializeGlobalHandlers(Unknown Source)
>   at java.util.logging.LogManager.access$900(Unknown Source)
>   at java.util.logging.LogManager$RootLogger.addHandler(Unknown Source)
>   at java.util.logging.LogManager$3.run(Unknown Source)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at java.util.logging.LogManager.loadLoggerHandlers(Unknown Source)
>   at java.util.logging.LogManager.addLogger(Unknown Source)
>   at java.util.logging.LogManager$1.run(Unknown Source)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at java.util.logging.LogManager.(Unknown Source)
>   at java.util.logging.Logger.getLogger(Unknown Source)
>   at org.apache.juli.logging.DirectJDKLog.(DirectJDKLog.java:71)
>   at
> org.apache.juli.logging.DirectJDKLog.getInstance(DirectJDKLog.java:178)
>   at org.apache.juli.logging.LogFactory.getInstance(LogFactory.java:171)
>   at org.apache.juli.logging.LogFactory.getInstance(LogFactory.java:243)
>   at org.apache.juli.logging.LogFactory.getLog(LogFactory.java:298)
>   at org.apache.catalina.startup.Bootstrap.(Bootstrap.java:55)
> 
> The tomcat-juli.jar is available as demonstrated in the first example that
> works.  Why is the prefix not being recognized?
> 
> Your assistance is greatly appreciated.
> 
> TC
> 

-- 
View this message in context: 
http://old.nabble.com/JULI-prefix-not-recognized--tp31907205p31907973.html
Sent from the Tomcat - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: JULI prefix not recognized?

2011-06-23 Thread throwsCode 

Hi Konstantin:

I added the following argument to the Apache Tomcat Server Run
Configuration:

-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager

It worked just as you suggested it would; however, it requires the argument
be placed in the VM arguments section.  I have many small clients that on
occassion share VMs with other Tomcat Servers.  Is there a way to do the
same without the Runtime Argument?

Thanks much.

TC





Konstantin Kolinko wrote:
> 
> 2011/6/23 throwsCode :
>>
>> I sure that is going to turnout to be a stupid question but I've played
>> with
>> it for two days and made no progress.  I can create a JULI handler as
>> long
>> as I don't apply a prefix, here is the logging.properties file (keeping
>> it
>> as simple as possible):
>>
> 
>> Can't load log handler "1pae.org.apache.juli.FileHandler"
>> java.lang.ClassNotFoundException: 1pae.org.apache.juli.FileHandler
>> java.lang.ClassNotFoundException: 1pae.org.apache.juli.FileHandler
> (...)
>>        at java.util.logging.LogManager.loadLoggerHandlers(Unknown Source)
>>        at java.util.logging.LogManager.initializeGlobalHandlers(Unknown
>> Source)
> 
> You are using wrong LogManager.
> You need to use org.apache.juli.ClassLoaderLogManager and not the default
> one.
> 
> See how catalina.sh does it.
> 
> Best regards,
> Konstantin Kolinko
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 
> 
> 

-- 
View this message in context: 
http://old.nabble.com/JULI-prefix-not-recognized--tp31907205p31915598.html
Sent from the Tomcat - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: JULI prefix not recognized?

2011-06-23 Thread throwsCode 

Thanks Konstantin:

I appreciate all the great information.  I'm going to look into log4j while
I'm involved with logging.  Hopefully by the end there will be a clear
winner between java.util.logging, JULI, and log4j, based on our needs.
 
Much Thanks.

TC




Konstantin Kolinko wrote:
> 
> 2011/6/24 throwsCode :
>>
>> Hi Konstantin:
>>
>> I added the following argument to the Apache Tomcat Server Run
>> Configuration:
>>
>> -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
>>
>> It worked just as you suggested it would; however, it requires the
>> argument
>> be placed in the VM arguments section.  I have many small clients that on
>> occassion share VMs with other Tomcat Servers.  Is there a way to do the
>> same without the Runtime Argument?
>>
> 
> Embedding?
> 
> I am afraid that there is no other way.
> 
> This property configures java.util.logging implementation used by VM.
> 
> IIRC in java.util.logging there exists a method that allows to reset
> logging configuration,  but I think it only allows to reconfigure
> handlers, and does not support replacing LogManager at runtime.
> 
> You can look into JRE sources  to see at what time the value of
> "java.util.logging.manager" property is being read.
> 
> 
> (*) You may have better luck by configuring Tomcat to use log4j (see
> relevant section in our logging.html).  With log4j you can go without
> ClassLoaderLogManager and without logging.properties, but there is one
> caveat:
>- Tomcat (using commons-logging) and webapps that use
> commons-logging will detect presence of log4j and use it instead of
> java.util.logging
>- Any web-applications that use java.util.logging will try to use
> default LogManager implementation, and will suffer from PermGen memory
> leaks during redeployments and restarts. Because default LogManager
> from JRE will keep their classes in memory.
> 
> The (*) is theory. I have not tested it in practice.
> 
> Best regards,
> Konstantin Kolinko
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 
> 
> 

-- 
View this message in context: 
http://old.nabble.com/JULI-prefix-not-recognized--tp31907205p31916749.html
Sent from the Tomcat - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org