Got a solution to the CFServlet problem from Randy Nielsen of Macromedia,
and it turns out to be quite an interesting dilemma that surprised even him.
He got the solution from John Zhao. Thanks to both for patient and able
assistance! :-)
The problem (and reason why it failed in this case when it had worked
elsewhere) was that I was trying to run the test against the demo servlets
installed with JRun. Turns out that "In order to provide compatibility with
JRun 2.3.3, which did not have the concept of a Web application, the CF/JRun
engineers restricted CFSERVLET to accessing the default application only
(the default app is under <jrun-root>/servers/default/default-app). ")
Yowsa. Take note, kids. This applies to more than just the demo apps, of
course. If you create your own apps other than the default app, you won't be
able to run CFServlet against them. (Anyone have experience to suggest
otherwise?)
Randy offered to update the LiveDocs CF and JRun pages to reflect this
knowledge (and I suggested a KB article would be welcome). He also will log
it as an enhancement (or bug). Any opinions? I suggested that it could be
fixed with a new attribute that allowed specification of the context (web
app) to be used, if other then "default-app".
/charlie
PS One other thing. I did have to make those updates listed below to
local.properties, even though they should have been done by running the
connector. I think what happened is that I'd run the connector in 3.0, then
installed 3.1, which reverted them back to blank values. My IIS connection
was indeed working, even though these were blank, suggesting I'd not run the
connector in 3.1. Hope that may be useful for others.
-----Original Message-----
From: Charles Arehart [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, September 05, 2001 9:38 PM
To: JRun-Talk
Subject: CFServlet problem/questions
Folks, this is a long-ish note with a few questions about trials and
tribulations of getting CFServlet to work on a new machine and Jrun
install--first getting "Could not connect to JRun Connector Proxy", then
after some tweaking getting "404 file not found, could not get dispatcher".
I know this sort of problem has been raised in the list before, and I
researched the archives and applied some suggested fixes, yet still I'm not
able to solve the problem. Well, I was able to change the problem.
I'd appreciate the attention of kindly souls willing to work through it.
I've tried to provide lots of useful info, both for solving the problem and
for future users who may read this in the archives and have similar
problems.
But besides just asking how to fix the problem, I'd like to ask a few other
questions about using the tag which seem rather sparsely documented,
especially in the CF docs.
(For you JRun users not using ColdFusion, it's a way within CF to call upon
a JRun servlet to extract its output, and even share information between the
servlet and the CF program. It's discussed in Chapter 43 of the 3.1 manual,
Developing Applications with JRun).
The docs make it seem easy enough to use:
<CFSERVLET CODE="ServletName" JRUNPROXY="ip:port"></CFSERVLET>
but there are a couple of things that aren't explained. First, consider
trying to call one of the demo servlets. If it runs successfully when called
from within a browser at the URL:
http://127.0.0.1:8101/demo/servlet/DateServlet, then what would be the
correct specification of the CFServlet tag?
In other words, is the same port used in the URL to be specified in the
CFServlet? The CF docs would lead one to believe so. They read that the
ProxyPort attribute is "the port number at which JRun is listening. By
default, JRun listens at port 8081." But the JRun docs mentioned above
instead say it should be the "JRun server connector port specified when
running the JRun Connector Wizard." Further, in the code example offered on
the same page, it says it's the port specified as the
"jcp.endpoint.main.port property in the local.properties file for the JRun
server you want to access". That's certainly different, and I think could
confuse a lot of people.
Anyway, in my case, it's listed as 51000, so the tag becomes <CFServlet
JrunProxy="127.0.0.1:51000">
Now about the class. Some newcomers may be really confused by this. In the
URL from the browser, we needed to add "demo/servlet", but a message in the
archives of this list from 11/22/00 indicates that CFServlet expects to find
the class in <webapplication>/WEB-INF/classes subdirectory. Fortunately,
that's the case for the DateServlet demo app, so it should be able to be
specified simply as:
<CFServlet JrunProxy="127.0.0.1:51000" CODE="DateServlet">
Unfortunately, I get the dreaded "Could not connect to JRun Connector
Proxy". Could it be that the port 51000 is conflicting with some other
application using that port? (This machine also has CF5, with the built-in
JRun services it offers for doing CFGraph and the new management services).
In fact, that raises another question: is there a tool that will help
identify what ports are already taken by running applications, so that if
this is indeed a conflict I can know which other apps use this port, and
which ports are free to be used?
Still, that may all be a red herring. I read yet another message in the
archive (from 9/10/2001) that suggested the following changes:
In local.properties file.
1. Add the letters jcp to the servlets.services line.
servlet.services=jndi,jdbc,web,mail,url,{servlet.webapps},jcp
2. Set the JCP bind address to the IP address.
jcp.endpoint.main.bindaddress=x.x.x.x
I did that, changing the bindaddress to 127.0.0.1. When I restarted the
server, I now see in the default-event.log:
09/05 20:58:14 info (jcp) jcp listening on 127.0.0.1:51000
That line wasn't there before in the log, so is this suggestion of needing
to add the jcp to servlet.services correct? If so, why isn't it documented?
And is my use of bindaddress correct? I'm just doing this testing on a
localhost. Even if this were a production server, where the CF and Jrun
servers were on the same machine, would 127.0.0.1 be ok to use?
Still, when I ran the CFServlet code above I got "404 Not Found
Could not get dispatcher"
I feel so close, but it's late, and while I might find this on my own with
more work, I do wonder if others may have had similar experiences and would
appreciate this rambling tale of woe. :-)
The event log entry is:
09/05 20:59:07 info (JRun) com.allaire.jrun.cfx.CFServletInvoker: init
09/05 20:59:07 warning (JRun) Got an exception in getNamedDispatcher.
[java.lang.ClassNotFoundException: DateServlet [DateServlet]]
java.lang.ClassNotFoundException: DateServlet [DateServlet]
at
allaire.jrun.servlet.JRunServletLoader.loadClass(../servlet/JRunServletLoade
r.java:430)
at java.lang.ClassLoader.loadClass(ClassLoader.java:253)
at
allaire.jrun.servlet.JRunServletLoader.loadServletInstance(../servlet/JRunSe
rvletLoader.java:194)
at
allaire.jrun.servlet.JRunServletLoader.loadServletInstance(../servlet/JRunSe
rvletLoader.java:161)
at
allaire.jrun.servlet.JRunServletLoader.loadServlet(../servlet/JRunServletLoa
der.java:149)
at
allaire.jrun.servlet.JRunSE.getServletReference(../servlet/JRunSE.java:1705)
at
allaire.jrun.servlet.JRunSE.getNamedDispatcher(../servlet/JRunSE.java:1962)
at
com.allaire.jrun.cfx.CFServletInvoker.service(../../../com/allaire/jrun/cfx/
CFServletInvoker.java:69)
at
allaire.jrun.servlet.JRunServletPool.service(../servlet/JRunServletPool.java
:90)
at allaire.jrun.servlet.JRunSE.service(../servlet/JRunSE.java:1416)
at
allaire.jrun.session.JRunSessionService.service(../session/JRunSessionServic
e.java:1082)
at allaire.jrun.servlet.JRunSE.runServlet(../servlet/JRunSE.java:1270)
at
allaire.jrun.servlet.JRunNamedDispatcher.forward(../servlet/JRunNamedDispatc
her.java:39)
at allaire.jrun.servlet.JRunSE.service(../servlet/JRunSE.java:1552)
at allaire.jrun.servlet.JRunSE.service(../servlet/JRunSE.java:1460)
at allaire.jrun.servlet.JvmContext.dispatch(../servlet/JvmContext.java:344)
at allaire.jrun.jrpp.ProxyEndpoint.run(../jrpp/ProxyEndpoint.java:391)
at allaire.jrun.ThreadPool.run(../ThreadPool.java:272)
at allaire.jrun.WorkerThread.run(../WorkerThread.java:75)
OK, so it can't find the servlet. But I know it exists, so it must be
something about how it's trying to find it.
Any thoughts on that would be appreciated. Thanks ever so much for your
patience in getting to this point.
/charlie
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Get the mailserver that powers this list at http://www.coolfusion.com
Archives: http://www.mail-archive.com/[email protected]/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
