unsubscribe
Jason Wolfe
Application Developer
iVolution Interactive
[EMAIL PROTECTED]
http://www.ivolutionmedia.com
970.980.9619
-----Original Message-----
From: Christof Wessely [mailto:[EMAIL PROTECTED]]
Sent: Friday, September 07, 2001 9:34 AM
To: JRun-Talk
Subject: RE: CFServlet problem/questions
My answer got somehow lost, so I try again:
Charles,
I have done a bit of work with ColdFusion and Jrun working together and
share your views about documentation.
I have a solution for your problem, but it is not an expert one.
If you add something like the following entry to the classpath
definition of the Jrun default server:
D:/JRun/servers/default/demo-app/WEB-INF/classes
(make sure that you are using forward slashes, always restart the
default server after changes to the classpath)
then the following coldfusion code will work:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <html>
<head>
<title>Untitled</title>
</head>
<body>
hello coldfusion here
<CFServlet JrunProxy="127.0.0.1:51000" CODE="DateServlet"></CFSERVLET>
</body> </html>
Cheers,
Chris
-----Original Message-----
From: Charles Arehart [mailto:[EMAIL PROTECTED]]
Sent: 07 September 2001 03:49
To: JRun-Talk
Subject: RE: CFServlet problem/questions
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/JRunServletL
oade
r.java:430)
at java.lang.ClassLoader.loadClass(ClassLoader.java:253)
at
allaire.jrun.servlet.JRunServletLoader.loadServletInstance(../servlet/JR
unSe
rvletLoader.java:194)
at
allaire.jrun.servlet.JRunServletLoader.loadServletInstance(../servlet/JR
unSe
rvletLoader.java:161)
at
allaire.jrun.servlet.JRunServletLoader.loadServlet(../servlet/JRunServle
tLoa
der.java:149)
at
allaire.jrun.servlet.JRunSE.getServletReference(../servlet/JRunSE.java:1
705)
at
allaire.jrun.servlet.JRunSE.getNamedDispatcher(../servlet/JRunSE.java:19
62)
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/JRunSessionSe
rvic
e.java:1082)
at
allaire.jrun.servlet.JRunSE.runServlet(../servlet/JRunSE.java:1270)
at
allaire.jrun.servlet.JRunNamedDispatcher.forward(../servlet/JRunNamedDis
patc
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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Structure your ColdFusion code with Fusebox. Get the official book at
http://www.fusionauthority.com/bkinfo.cfm
Archives: http://www.mail-archive.com/[email protected]/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
