 |
GlassFish supports configurable AJP Connector.
Posted by amyroh on August 15, 2006 at 01:50 PM | Comments (21)
We have heard some comments from the community regarding the need to configure AJP Connector in GlassFish. I have gone ahead and expose the AJP Connector parameters in GlassFish so it's easy to configure the connector using a properties file.
Quick blog on how to configure AJP Connector in GlassFish
(1) First, install mod_jk - see Jeanfrancois's blog
for more details
(2) Copy three necessary jars from tomcat and jakarta-commons
* tomcat-ajp.jar
* commons-logging.jar
* commons-modeler.jar
to $GLASSFISH_HOME/lib/.
(3) Enable mod_jk by adding :
$GLASSFISH_HOME/bin/asadmin create-jvm-options -Dcom.sun.enterprise.web.connector.enableJK=8009
(4) Create a glassfish-jk.properties file
(5) Let GlassFish know where you'd like to load glassfish-jk.properties
from by adding :
$GLASSFISH_HOME/bin/asadmin create-jvm-options -Dcom.sun.enterprise.web.connector.enableJK.propertyFile=/home/amyroh/glassfish_home/domains/domain1/config/glassfish-jk.properties
(6) Restart GlassFish.
You can configure your AJP Connector starting GlassFish V2 build 13 (will be promoted on 8/16) or any nightly builds after 8/12/06.
Bookmark blog post: del.icio.us Digg DZone Furl Reddit
Comments
Comments are listed in date ascending order (oldest first) | Post Comment
-
Hi,
Thanks for very useful information. I am also trying to configure glassfish with AJP connector. I have followed your instruction and eveything seems to work until I send a request to Apache. When I send a request to Apache, it forwards it to glassfish, but I get an error;
java.lang.NullPointerException
at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:199)
at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:282)
at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:754)
at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:684)
at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:876)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:653)
at java.lang.Thread.run(Thread.java:595)
Can you also please let me know why do we need 'glassfish-jk.properties' and what information needs to go in.
Thanks!
Posted by: muhammad_raza on August 25, 2006 at 04:51 AM
-
Hi,
Which GlassFish build are you using? You don't need glassfish-jk.properties if you're just using default jk properties. Could you file a bug with server.log and your set up so we can better track and fix the problem?
Thanks,
Amy
Posted by: amyroh on August 25, 2006 at 12:49 PM
-
Hi,
Thanks for your reply. I have tried this with following;
glassfish-installer-v2-b13.jar
glassfish-installer-v2-b14.jar
I am using Apache HTTP Server 2.2.3 , tomcat-ajp.jar (tomcat-5.5.17), commons-logging-1.0.4, commons-modeler-1.1 and with JDK 1.5
But unfortunately I got the same error. I will file a bug with server.log and other relevant information. Meanwhile if you have any other idea, please let me know.
Thanks for you help.
Muhammad
Posted by: muhammad_raza on August 29, 2006 at 09:04 AM
-
Hi,
Thanks the information and I follow the steps but encounter a problem. When I specified another port, say 8109, I found that glassfish still stick to port 8009. After that, I specified the jk.properties file with channelSocket.port, but glassfish still sticks to 8009. I looked at glassfish log and find following messages:
>Can't find home, jk2.properties not loaded
>ajp13 listening on /0.0.0.0:8009
>Jk running ID=0 time=10/170 config=null
My environment is:
1) Glassfish build v2 b14
2) logging-1.1, modeler-2.0, tomcat-ajp ( 5.5.12 )
3) WindowXP platform.
Kindly advise what configuration do I miss. Thanks alot.
Posted by: whtsang22 on August 30, 2006 at 10:15 AM
-
Hi,
Have you enabled the jk by defining jvm-options "com.sun.enterprise.web.connector.enableJK" and "com.sun.enterprise.web.connector.enableJK.propertyFile"? It looks like you did enable it according to the log you provided.
To change the port, you'd need to do
$GLASSFISH_HOME/bin/asadmin create-jvm-options -Dcom.sun.enterprise.web.connector.enableJK=new_port_number
or
$GLASSFISH_HOME/bin/asadmin create-jvm-options -Dcom.sun.enterprise.web.connector.enableJK.propertyFile=path_to_glassfish-jk.properties
The glassfish-jk.properties would contain the AJP Connector attributes that you want to configure. For your case, the propertyFile would contain port=new_port_number
Hope this helps. Please file a bug if you still experience a problem with your environment and detailed server.log so it'll be easier for me to take a look.
Thanks,
Amy
Posted by: amyroh on August 31, 2006 at 02:53 PM
-
First let me say thanks for your blog. Between your blog and Jean's I have been able to integrate Apache and Glassfish to support multiple virtual hosts (i.e., one Apache instance tied to multiple Glassfish instances).
Recently however I have been having a problem with Glassfish throwing exceptions during appserver initialization. Today I just discovered the solution to the problem and thought I would post it here in case anyone else is having the same problem.
The problem is that my webapps each includes their own log4J jar file. As long as I configured the webapps' sun-web.xml file to set "delegate=false" everything worked fine. Now that I have started incorporating JAX-WS into the webapps however I have been told that I have to set "delegate=true" in order for JAX-WS to work properly (please confirm - is this true?). Once I do that however Glassfish throws exceptions when trying to load the log4j jar included with my webapp.
Today I discovered the problem is due to log4j residing in a different classloader (my webapp's classloader) than the commons-logging jar (loaded by the appserver classloader). During initialization commons-logging tries to determine which logging implementation is being used. When it detects log4J it tries to initialize it but fails due to the classloaders being different.
A solution that seems to work is to remove the log4J jars from my webapps and instead place it in the appserver lib along with commons-logging.jar. Once I did that glassfish now (almost) initializes properly.
The reason I say almost is that one exception is still being thrown by OpenESB. It seems that the httpsoap BC is having the same problem experienced by my webapps prior to the solution. I have enclosed the stack trace FYI:
[#|2006-12-09T12:37:55.715-0500|WARNING|sun-appserver-pe9.0|javax.enterprise.system.stream.err|_ThreadID=15;_ThreadName=Thread-38;_RequestID=7dad96c9-b901-4f5a-a0df-5cdef66caf26;|java.lang.ExceptionInInitializerError
at com.sun.jbi.httpsoapbc.OutboundMessageProcessor.(OutboundMessageProcessor.java:146)
at com.sun.jbi.httpsoapbc.OutboundReceiver.run(OutboundReceiver.java:115)
at java.lang.Thread.run(Thread.java:595)
Caused by: org.apache.commons.logging.LogConfigurationException: org.apache.commons.logging.LogConfigurationException: org.apache.commons.logging.LogConfigurationException: Class org.apache.commons.logging.impl.Log4JLogger does not implement Log
at org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:532)
at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:272)
at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:246)
at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:395)
at org.apache.commons.httpclient.HttpClient.(Unknown Source)
... 3 more
Caused by: org.apache.commons.logging.LogConfigurationException: org.apache.commons.logging.LogConfigurationException: Class org.apache.commons.logging.impl.Log4JLogger does not implement Log
at org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogFactoryImpl.java:416)
at org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:525)
... 7 more
Caused by: org.apache.commons.logging.LogConfigurationException: Class org.apache.commons.logging.impl.Log4JLogger does not implement Log
at org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogFactoryImpl.java:412)
... 8 more
|#]
As I am now starting to use openESB I need to find a fix for this exception as well. Any suggestions/workarounds would be appreciated!
Steve
Posted by: snies00 on December 09, 2006 at 02:07 PM
-
I think I may have also found a solution for the httpsoap BC exception. Since commons-logging.jar exists in the appserver's classloader (to make the ajp connector work) I removed the commons-logging jar from the "${domainDir}/jbi/bindings/com.sun.httpsoapbc-1.0-2/install_root" directory. I then restarted the appserver. Although I don't have the means yet to test the httpsoap BC at least there aren't any more exceptions listed in the server log.
Posted by: snies00 on December 09, 2006 at 08:12 PM
-
Hi,
I enable AJP connector (to setup Apache httpd as frontend). But I'm having UTF-8 issues with my request parameters. So I setup in glassfish-jk.properties file URIEncoding=UTF-8 (I've check using the jconsole - the property correctly affected) but no effect.
This property works perfectly If I'm using Tomcat (defining as attribute of connector in server.xml).
Thanks for you help.
Tim.
Posted by: timkh on January 09, 2007 at 06:04 AM
-
Thanks, snies00 for posting your findings.
Posted by: amyroh on January 09, 2007 at 12:23 PM
-
timkh, can you try the following to see if your environment is loading
glassfish-jk.properties correctly?
edit domain.xml for web-container to "FINEST"
restart glassfish
check server.log to see if it contains similar message as below
[#|2007-01-09T12:09:16.743-0800|FINEST|sun-appserver-pe9.1|javax.enterprise.system.container.web|_ThreadID=1
1;_ThreadName=Thread-5;ClassName=com.sun.enterprise.web.PEWebContainer;MethodName=configureJKProperties;_Req
uestID=9311312d-d3f2-44fb-80e4-ba5510f5b16a;|Loading
glassfish-jk.properties from
/home/amy/glassfish/domains/domain1/config/glassfish-jk.properties|#]
If glassfish-jk.properties are not found, exception should be shown
instead. quick check to see if the properties file getting picked up
correctly.
If you see the message but URIEncoding is still not getting set, please
file a bug so I can take a look at it.
Thanks,
Amy
Posted by: amyroh on January 09, 2007 at 12:33 PM
-
Hi Amy
Yes, I've got this message in the log (... Loading glassfish-jk.properties from ...)
Also, I would like to confim that this property is set properly in the PECoyoteConnector, I saw that via Mbean using JConsole.
The problem is that I'm still having UTF-8 issues even the URIEncoding is set properly.
Thanks, Tim.
Posted by: timkh on January 10, 2007 at 01:57 AM
-
Hi Amy, The first part of configuring glassfish with AJP is working means, till enabling the port 8009. I'm trying to use Apache 2.2 with mod_proxy_ajp. I don't understand how to point it to say the admin port. http://servername:4848. e.g: ProxyPass * ajp://localhost:8009/ using apache mod_proxy_ajp, when I go to http://servername it must go to http://servername:4848
Posted by nnaga at February 20, 2007 06:45 AM
Posted by: nnaga on February 20, 2007 at 06:46 AM
-
Hi Tim,
Could you file an issue if you're still having problem with encoding so we can better track it? It'll be great if you could attach a test case to produce/verify the issue.
Thanks,
Amy
Posted by: amyroh on February 20, 2007 at 02:41 PM
-
Hi nnaga,
Have you configured Apache to use mod_proxy and does your setting work with Tomcat?
You can find more info on Apache proxy support from
http://tomcat.apache.org/tomcat-5.0-doc/proxy-howto.html. I've never tried this personally but let us know your findings.
Thanks,
Amy
Posted by: amyroh on February 20, 2007 at 02:47 PM
-
Hi Amy,
It worked :-). Thanks, I tried to resinstall the whole glassfish setup as non-privileged user and added now, now port 8009 is not opening at all. I could see the JK values unders the JVM options.
Any methods to troubleshoot ajp listener, is this something to with user privileges. I'm now trying with the same with root user on a another installation.
Posted by: nnaga on February 22, 2007 at 06:47 AM
-
Thanks Amy, It worked like a charm until the last glassfish promoted build (v2 b41). From now on, the C2BConverter constructor is protected, and AJP connector fails to initialize. I created an issue #2766 for that.
Posted by: ritola on April 02, 2007 at 01:50 AM
-
Thanks ritola for reporting. The issue has been fixed and should be available in the next promoted build v2 b42. Please let us know if you still experience the issue.
Posted by: amyroh on April 02, 2007 at 10:50 AM
-
Hi Amy,
why do not bundle ajp protocol support into GF 2.0 via default ?
https://glassfish.dev.java.net/issues/show_bug.cgi?id=3078
http://www.wiik.de/blog/2007/05/27/glassfish-and-apache/
-- Thorleif Wiik
Posted by: thorleif on May 28, 2007 at 01:09 PM
-
You may also want to note that this does not work with the jars from the latest 5.5.x version of the Tomcat library tomcat-ajp.jar. I used 5.5.25 and received:
java.lang.NoSuchMethodError:org.apache.coyote.Response.getContentLengthLong()J.
However using version 5.5.16 seemed to resolve the issue.
Posted by: joeybobo on September 19, 2007 at 02:25 PM
-
I'm desperately trying to get sticky sessions working with mod_jk/glassfish! I'm using glassfish build v2 58g. I'm guessing the jvmRoute needs to be set app server side but can't figure how to set this (it's not one of the AJP connector properties is it unless I'm being particularly dumb?).
Incidentally I can confirm above that the jars from tomcat 5.5.25 didn't work for me either - I regressed them to 5.5.16 as above, all ok.
Posted by: ocoro02 on October 02, 2007 at 04:23 AM
-
Thank you for your post. Sorry in advance for my English as it is not my native language.
I am new to Glassfish and have used JRun . I am wondering does the mod_jk module for apache together with the tomcat receiving end have support for the DocumentRoot within the virtual hosts.
What I am trying to do is letting glassfish determine it's document root for a request based on the settings in apache's VirtualHost tag. This works fine with JRun. JRun has it's own connector for apache and that connector may send the documentroot to the JRun server. I am wondering if the mod_jk (or ajp protocol) do this aswell and if the tomcat-ajp component uses this information.
I might be completely wrong about this as it might not be the design of the application server. Maybe someone can enlighten me
Greetz EE
Posted by: eecolor on December 08, 2007 at 07:08 PM
|