Need help with jsp and java bean

[The_ScareCrow]

A department has built there own site using jsp. I need to get this up and running through cf7.1

I have created a server instance, so this is seperate from the rest of the intranet.
Basically, I think I have to "install" the javabean. But don't know how.

Code added to the web.xml
<servlet-mapping>
<servlet-name>controller</servlet-name>
<url-pattern>*.do</url-pattern>
</servlet-mapping>

The login page is called through a link
127.0.0.1/servlet/Controller?page=login

The jsp code is as attached (initial login page)

There is a file "LoginBean.java"

Now for the error

jrun.jsp.tags.GetProperty$NoSuchPropertyException: (/loginPage.jsp:13) The bean loginBean does not have a enteredcustomerid property
at jrun.jsp.tags.GetProperty.init(GetProperty.java:78)
at jrun.jsp.tags.GetProperty.doStartTag(GetProperty.java:39)
at jrun__loginPage2ejspe._jspService(jrun__loginPage2ejspe.java:75)
at jrun.jsp.runtime.HttpJSPServlet.service(HttpJSPServlet.java:43)
at jrun.jsp.JSPServlet.service(JSPServlet.java:119)
at jrun.servlet.ServletInvoker.invoke(ServletInvoker.java:91)
at jrun.servlet.JRunInvokerChain.invokeNext(JRunInvokerChain.java:42)
at jrun.servlet.JRunRequestDispatcher.invoke(JRunRequestDispatcher.java:257)
at jrun.servlet.ServletEngineService.dispatch(ServletEngineService.java:541)
at jrun.servlet.http.WebService.invokeRunnable(WebService.java:172)
at jrunx.scheduler.ThreadPool$ThreadThrottle.invokeRunnable(ThreadPool.java:426)
at jrunx.scheduler.WorkerThread.run(WorkerThread.java:66)

jrun.jsp.runtime.UncaughtPageException: Unhandled exception thrown from /loginPage.jsp:13
at jrun.jsp.runtime.Utils.handleException(Utils.java:57)
at jrun.jsp.runtime.JRunPageContext.handlePageException(JRunPageContext.java:384)
at jrun__loginPage2ejspe._jspService(jrun__loginPage2ejspe.java:119)
at jrun.jsp.runtime.HttpJSPServlet.service(HttpJSPServlet.java:43)
at jrun.jsp.JSPServlet.service(JSPServlet.java:119)
at jrun.servlet.ServletInvoker.invoke(ServletInvoker.java:91)
at jrun.servlet.JRunInvokerChain.invokeNext(JRunInvokerChain.java:42)
at jrun.servlet.JRunRequestDispatcher.invoke(JRunRequestDispatcher.java:257)
at jrun.servlet.ServletEngineService.dispatch(ServletEngineService.java:541)
at jrun.servlet.http.WebService.invokeRunnable(WebService.java:172)
at jrunx.scheduler.ThreadPool$ThreadThrottle.invokeRunnable(ThreadPool.java:426)
at jrunx.scheduler.WorkerThread.run(WorkerThread.java:66)


Any help please...

Ken

[cecropin]

Ken,

Based on the erorr it seems as though there's no property within the bean called "enteredcustomerid". Where's the Java code for the bean? Are you certain the JSP code itself is correct?

-Tim

[The_ScareCrow]

quote:

---

Are you certain the JSP code itself is correct?

---

I have seen the app running under tomcat.
I was given a folder containing the pages for the app and told if I install under the webroot on tomcat it would work.
But, as we don't want to run tomcat, and it looks as though I should be able to run it under cf7 I thought I would try.

quote:

---

Where's the Java code for the bean?

---

As I know nothing about java, I assume this is the file called "LoginBean.java" which is located in the same directory as the login page.

Under the web-inf folder the is a folder called classes.
If I copy files into this, do I then need to "install" them with cf some how ?

The code in the LoginBean.java file is attached.

Ken

[cecropin]

Ken,

I have no idea how this would have run even on Tomcat because the two methods getenteredcustomerid and getenteredpassword are not in accordance to JavaBean specs. The methods should be "getEnteredCustomerId" and "getEnteredPassword". The JavaBean properties need to adhere to the naming convention. I can't find a good reference for this at the moment. But I did reproduce your error and was able to resolve it by making the changes above. You'll also have to change the property value from within the JSP to match the case of the getter.

With regard to deployment. Technically it's the .class file that's being utilized, you happen to have the JRun web app instance set to autocompile and reload servlets, JSPs, and helper classes for the two previously mentioned items. You can confirm this by inspecting the compile></compile> and <reload></reload> tags in jrun-web.xml.

If you update the Java file where it's currently located (WEB-INF/classes) and update the JSP it should fix the problem.

Also one last note, you are technically using JRun to run the application and not CF MX 7.

Regards,
Tim

[The_ScareCrow]

Thanks for your help Tim.

quote:

---

You can confirm this by inspecting the compile></compile> and <reload></reload> tags in jrun-web.xml.

---

This is my jrun-web.xml

<?xml version="1.0" encoding="ISO-8859-1"?>

<!DOCTYPE jrun-web-app PUBLIC "-//Macromedia, Inc.//DTD jrun-web 1.0//EN" " http://www.macromedia.com/dtd/jrun-web.dtd">

<jrun-web-app>

<session-config>
<persistence-config>
<active>false</active>
</persistence-config>
</session-config>

</jrun-web-app>

quote:

---

If you update the Java file where it's currently located (WEB-INF/classes) and update the JSP it should fix the problem.

---

I have changed the code in the loginBean.java file to,
public String getEnteredCustomerId()
{
return enteredcustomerid;
}

public String getEnteredPassword()
{
return enteredpassword;
}


But, where do I need to change it in the jsp.
There is an index.html page with a link which has an href of
servlet/Controller?page=login

The login.jsp page is attached.

quote:

---

If you update the Java file where it's currently located (WEB-INF/classes)

---

I assume you mean the LoginBean.java file ?
This is located in the web root with the loginPage.jsp.
The only thing in the web-inf/classes folder are dot classes files

Ken

[cecropin]

Hmmm... seems odd that JRun ever found the bean to begin with since compile and reload were never set to true.

Also I didn't take notice of this earlier, but since you're accessing the JSP via a servlet there's a lot that's potentially going on behind the scenes and I don't have full access to your code so it's a bit difficult to square this away, but let's try to simply our troubleshooting.

First go ahead and make a copy of the existing jrun-web.xml incase you need to revert back. Add the following lines after the </session-config> tag (note this is the closing tag).
============================
<compile>true</compile>
<reload>true</reload>
===========================

Again this will force your JSPs and helper classes to recompile. Restart the JRun instance for this to take effect.

Since your JavaBean seems to indicate it's not part of a package you should place the file modified Java source code LoginBean.java at
%app_webroot%\WEB-INF\classes

Make sure the filename is "LoginBean.java" it is case sensitive. Your login JSP page should remain in the webroot. I am using the term webroot a quite loosely, because if you were using IIS you could configure your directories differently. Does the directory WEB-INF already exist with directories such as cfusion, classes, lib, jsp, etc.. underneath it?

You said that your login JSP page contains the code....
<%@ page import="LoginBean"%>
<jsp:useBean id="loginBean" scope="session" class="LoginBean"/>
<html>
<head>
<title>Bibliography Database - Login Option</title>
</head>
<body>
<h3 align="c....

The line <jsp:getProperty name="loginBean" property="enteredcustomerid"/> and <jsp:getProperty name="loginBean" property="enteredpassword"/> should be changed since your Java code has changed. It should be
<jsp:getProperty name="loginBean" property="EnteredCustomerId"/>
<jsp:getProperty name="loginBean" property="EnteredPassword"/>

This is the only change needed for the JSP.

Now before running anything, take a looke at %webroot%\WEB-INF\classes is there a file called LoginBean.class in there? If so note the timestamp. Access your JSP page directory http://localhost/login.jsp.

This should display the login form correctly. There's something funky going on with my JRun instance and on the first try I'll get a 500 error, but if I close the browser and access the page again it will display correctly. Also you should see that the classes directory has a new or updated LoginBean.class file.

Give this a whirl and tell me what happens. In your comments your refer to loginBean.java, LoginBean.java, login.jsp, and loginPage.jsp. Please note that the references should correspond to your files and case-sensitivity is very important.

You've definitely got a lot of ground to cover in understanding the relationship between servlets, JSP, classes, and how to deploy to a J2EE web app server. You may want to checkout a good introductory J2EE book like Beginning J2EE 1.4 by James Weaver. ISBN 978-1-59059-341-7

-Tim

[The_ScareCrow]

Still getting the same error, probably missing something.

quote:

---

You've definitely got a lot of ground to cover in understanding the relationship between servlets, JSP, classes, and how to deploy to a J2EE web app server.

---

Yes, and no time to read. I'm the lone developer for an intranet that covers 25 hospitals, about 100 clinics and about 30,000 users.

This was developed by a women in the diabetes department, (for a uni course and to be used by the department)
She just gave me a folder.
Now, I have notice in this folder is a web-inf folder, so not sure if this is causing a problem.

So, this is what she gave me

diabetes/
LoginBean.java
LoginPage.jsp
WEB-INF/
web.xml
web_frim_beans.xml
classess/

I have attached the contents of these to xml documents.

In the classes folder there are 3 files to do with the login
LoginBean.class
LoginHandler.class
loginPageGenerator.class

If you could see your way to explain what I need to do to get this to work it would be great. But I do understand if this is not feasible.

I can install this on a multiserver cf install under jrun4 with IIS
eg. folder structure

JRun4/servers/cfusion/

wwwroot/rpa/diabetes/

Ken

[cecropin]

Ken,

Your directory listing doesn't have indentation when posted in the textarea so I'm guess it's actually like I have it listed below? This is the structure I would expect.

The full app itself has a number of issues such as servlet mapping that needs to be resolved. That first servlet-mapping tag you added at the beginning of your post isn't sufficient, but that's not what's really important at this time. This is what I'd like you to do, because we want to get the bean to work with the JSP only those 2 basic elements should be in play (for now).

Please use a multiserver configuration so that you should have the JRun structure listed below.

Place the file LoginPage.jsp at JRun4\servers\cfusion\cfusion-ear\cfusion-war\LoginPage.jsp.
Place the modified LoginBean.java file at JRun4\servers\cfusion\cfusion-ear\cfusion-war\WEB-INF\classes\LoginBean.java

Access the URL http://<dns>/LoginPage.jsp
What happens? You shouldn't get an error but if you do let's do this.

Make a copy of LoginPage.jsp at the same directory and name it LoginPage2.jsp. Edit this file such that the first 2 lines read:
<%@ page import="LoginBean2"%>
<jsp:useBean id="loginBean" scope="session" class="LoginBean2"/>

I've enclosed the full code below.

Access the URL http://<dns>/LoginPage2.jsp It should give you an error that the LoginBean2 doesn't exist or cannot be found.

Now copy LoginBean.java where is lies and rename it to LoginBean2.java. Edit the file so that the first line now reads:
public class LoginBean2

Also edit the constructor to read:
public LoginBean2()

full code attached below. Now access http://<dns>/LoginPage2.jsp It should definitely display the login form "Bibliograph Database - Login Menu". If it doesn't I'm quickly running out of ideas, because this is as trimmed down as it can get. By using the LoginPage2 and LoginBean2 we eliminate any caching or non-recompile issues. I've tested all the attached code myself so I know it works.

Hope this gets us somewhere.
-Tim

[The_ScareCrow]

We have lift off......
The loginPage.jsp would not work in the location you gave, but when I copied it to the web root it did. I assume this is because of the web connector.But of cause the login gives an error, I assume because of the servlet mapping as you said.

Can you shed some light on this ?

That is:
When using the link in the index.html page (servlet/Controller?page=login) and when you try to login (servlet/LoginHandler)

You get a page not found error.

Ken

[cecropin]

Ken,

I really don't know why the Controller servlet is being referenced, because you weren't given a Controller.class file and without that you can't reference /servlets/Controller.

I'd disregard that for the time being and access the login page via the JSP file.

Servlets are really just .class files that extend a particular class and respond to HTTP requests. At the end of the day servlets are .class files which respond to the HTTP request. JSPs are automatically converted to servlets and the servlet's what's really running, just like CFMs are converted to Java code and the Java code is what's really running. The only servlet I see you using at this point is LoginHandler.

Add the tags below to web.xml after any other <servlet> tags which aren't commented out. The original servlet reference you provided doesn't match the URL you're posting to, loginHandler and LoginHandler are different cases and you need to pay very close attention to this when dealing with Java.

Once that's added you should be able to restart JRun and get some real action out of the app. I have no idea what's behind the LoginHandler code so I can't tell you what will happen. If you have an error with that or want to prove that the request is passing to the servlet then change LoginPage.jsp so that it posts to "/servlet/TestServlet". Create a file called TestServlet.java in the classes directory with the code below. Also add the servlet reference below. Since I coded that simple example I know it works.

That should about cover the basics. The rest really depends on your app and code.
-Tim

[The_ScareCrow]

Tim,
I spent some time looking through the folders and sub folders in what I was given.
I found all the java files 2 levels down in a web-inf/classes folder.

All the servlet code, as in
<servlet>
<servlet-name>LoginHandler</servlet-name>
<servlet-class>LoginHandler</servlet-class>
</servlet>

is in the web_frim_beans.xml page

One question
How does this file get read when the server starts ?

Ken

[cecropin]

Ken,

I'm not sure if it's just based on J2EE specifications or what, but all Java web applications will effectively read the web.xml located in /WEB-INF upon initialization. Frequently there are other XML initialization/configurations files that are specific to the web application or the web application server.

For instance if you look in /WEB-INF you'll notice jrun-web.xml, j2ee-web.xml, etc... For the most part you can just reliably expect that web.xml will be processed. With regard to the web_frim_beans.xml, I'm really not sure how that particular file gets processed and why the original developer decided to code the servlet mappings in there rather than web.xml. You can either ask the developer about that or just manually copy and paste all the essential <servlet> and <servlet-mapping> nodes to web.xml.

-Tim

[The_ScareCrow · Accepted solution]

Tim,

I would like to thank you for your help on this. If I ever run into you at an event, drinks are on me.

I created a new server instance through the cf admin, this created all the required files folders.
Although the jrun-web.xml was not in the web-inf folder. So I copied it to this location and inserted your bit of code.
I then copied the code from the web.xml and the web_frim_beans.xml which we with the application and pasted them into the web.xml of the server instance.
I then copied all the files from the classes folder of the application to the classes folder of the server instance.
I then copied only the application files to the cfusion.war folder that was created.

I then stopped and restarted the server instance, but because of the case in the login page it did not work.
So, I then made the changes as you suggested to the loginPage.jsp and the LoginBean.java file.

I then stopped and restarted the server instance again.

All worked as it should.

Again, thank you.

Ken