Jsp yes, javabean/servlet no :(
Jeff Rozycki
At work, all employees get webspace. I can get jsp's to parse but can
not get servlets or javabeans to work. Speaking with IT admins, users
do not have javabeans or servlet permissions. Atleast that is what I
was told me in a trouble ticket email.
What game plan should I take to develop my informational website,
working with what I have?
1) write methods inside the jsp
2) bag the project
3) insist on javabeans/servlet access
4) other
Basically, I want to have a website with "tips and tricks",
"department points of contacts", "weekly annoucements", etc..
dynamically generated from an Oracle database.
I have strong programming skills in other areas, but just a little
background in all this J2EE stuff.
Eric G
first time a JSP is requested a servlet is generated from the page, it's
compiled and then used to handle subsequent requests. Beans are just java
classes that adhere to a programming convention, ie get/set methods. So if
you can instantiate other classes, which I'm sure you can, then you should
be able to instantiate beans. If your beans are EJBs then your server must
also be an EJB container, which may be what IT meant. You can't use EJB's
because the the server is only a JSP/Servlet container.
The problem may be with accessing Oracle. Beans don't have to access a
database, but often do. If you don't have rights to access the database,
that would limit the usefullness of your application.
--
Eric
"Jeff Rozycki" <jroz...@digitalpublishers.com> wrote in message
news:4303e43d.03022...@posting.google.com...
Jeff Rozycki
I have no problem creating/creating Oracle database/tables using just the
jsp with, I guess it's called, a scriplet and java code. Since I am
relatively new to this, I read somewhere that this is poor design and I
should separate the logic out of my presentation.
I took a simple javabean example but the error-log file kept saying that
it could not find my Class. (I could however get <jsp:useBean id="cart"
scope="session" type="java.util.Vector" class="java.util.Vector" /> to
work) So I asked IT where individual users can place their own
javabeans and they said you can't/did not know )
So you are right, I can get a servlet to work, but not when I reference it
in a form action because I don't have the appropriate directory path.
How should webservers be setup to allow individual users their own servlet
dir (I think this is similar to cgi-bin) as well as a javabean directory
(can I just put the WEB-INF folder at the . level?)
All this work trying to get servlets and beans working, makes me think I
should just throw it all in a jsp file :)
-Thanks,
Jeff (could not wait for Google to update, so I reply using my nyx
account)
Jeff Rozycki wrote: > Hi,
Eric G
You're on the right track. In your web application's home directory place
the /WEB-INF folder and in that
a /classes folder. It might look something like:
<web server applications directory>/jeffsapp/*.jsp
<web server applications directory>/jeffsapp/WEB-INF/web.xml
<web server applications directory>/jeffsapp/WEB-INF/classes/*.class
<web server applications directory>/jeffsapp/WEB-INF/lib/*.jar
The folder /WEB-INF/classes will be in the class path and should hold all
your class files (in the appropriate package sub-folders) for servlets,
beans and helper/utility/other classes.
The folder /WEB-INF/lib would hold any JAR files you want added to the
classpath.
Alternatively you can put all the files in a WAR file and deploy that to
your web server:
jeffsapp.war (containing)
*.jsp
WEB-INF/web.xml
WEB-INF/classes/*.class
WEB-INF/lib/*.jar
Your servlets should be declared in the web.xml file if they're not already:
<servlet>
<servlet-name>JeffServlet1</servlet-name>
<servlet-class>com.yourcompany.jeff..SomeServlet</servlet-class>
<servlet-name>JeffServlet2</servlet-name>
<servlet-class>com.yourcompany.jeff..SomeOtherServlet</servlet-class>
</servlet>
etc.
Then they can be called with www.yoursite.com/jeffsapp/servlet/JeffServlet1
or if you want a better URL add servlet mappings:
<servlet-mapping>
<servlet-name>JeffServlet1</servlet-name>
<url-pattern>/myservlet</url-pattern>
</servlet-mapping>
then you can use the address www.yoursite.com/jeffsapp/myservlet (for GETs)
and a form action in a JSP can use action="/myservlet" (for POSTs)
You're right about keeping the database code and business logic out of the
JSP. It's best for maintenance and reuse to seperate presentation and logic
to JSP and beans. Generally speaking the less java code in the page the
better. But depending on the scale and purpose of your web app, if you find
yourself jumping through hoops to keep java scriptlets out of your JSP it
may not be worth the extra effort. If it's a small app that won't need much
maintenance, isn't going to have many developers and just needs to be done
quick, you do what you need to get the job done :).
--
Eric
"Jeff Rozycki" <jroz...@NOSPAM.nyx.net> wrote in message
news:10461183...@irys.nyx.net...
Kenny MacLeod
warsa...@yahoo.com says...
> The response from the IT admins doesn't sound right. JSPs are servlets, the
> first time a JSP is requested a servlet is generated from the page, it's
> compiled and then used to handle subsequent requests.
That's true from a technical perspective, but from an admin perspective,
they're very different. To a webmaster, JSPs are just web pages, like
any other HTML page. I can understand this restriction.
A simple solution would be to put all your bean definitions into a
seperate JSP file, and include that file inside your other JSPs. These
JSPs can then use those bean classes as they see fir.
Not pretty, but it should work OK.
kenny
Sol
> The response from the IT admins doesn't sound right. JSPs are servlets, the
> first time a JSP is requested a servlet is generated from the page, it's
> compiled and then used to handle subsequent requests.
the only difference is that servlets need special servlet directorys
and JSP's don't.
If you could access your database from the jsp pages then you should
be fine,except that you will have to rewrite each method for each JSP
page which kinda sucks
Michael Borgwardt
>>The response from the IT admins doesn't sound right. JSPs are servlets, the
>>first time a JSP is requested a servlet is generated from the page, it's
>>compiled and then used to handle subsequent requests.
>
>
> That's true from a technical perspective
Not even from a technical perspective, I think. AFAIK the JSP spec doesn't
specify this. JSPs *can* be (and practically always are) translated into
servlets, but they don't *have* to be.
Eric G
allows the full power of the Java language where as a static HTML page
doesn't. What the JSP can do may, and should, be limited by the security
policy. Given that a servlet container is provided for employees to use AND
that Jeff's JSPs worked I suspect it's actually a web app configuration
thing and not a restriction of what classes can not be instantiated.
I agree that technically a JSP does not have to be translated to a servlet,
but as you mentioned they practically always are. Much of the JSP spec
certainly discusses JSPs in the context of being a servlet and JSP is an
extension of servlet. So it's a safe bet that Jeff's JSPs are translated to
servlets by the servlet container.
--
Eric
"Michael Borgwardt" <bra...@brazils-animeland.de> wrote in message
news:b3fd75$1lriru$2...@ID-161931.news.dfncis.de...
Jeff Rozycki
Thanks everyone.
So to sum things up.
For me to do what Eric mentioned (WEB-INF, web.xml, etc), correct me
if I am wrong, but the IT admins must enable this, I cannot just
create the WEB-INF directory, or servlet directory and expect it to
work??
Sol mentioned writing individual methods in each JSP, but that it can
suck, I am assuming because of a lot of duplication. But if I use the
include directive, as Kenny mentioned, then I should be able to
eliminate the duplication and reuse my include files throughout,
right? I think they are basically recommending the same approach.
If it is possible to utilize the include directive to make my
class/methods available to my JSP's, then how is this different than
utilizing the classes/methods as beans? Is it because of poor
performance? Coding complexity?
-Thanks,
Jeff
Eric G
within the space on the server for your web app, then you should be able to
create the necessary folders. If however IT Admin is doing all the file
copying and/or restricting the folders you can have then you may be stuck.
Unless you can have a WAR file deployed to the server, then you would just
create the appropriate structure in the WAR.
Kenny's suggestion would work. Instead of a bean, create a JSP and put the
methods you want in the declaration directive <%! %>. Then include the
necessary JSP with the methods you want in your "real" JSP with the include
directive <%@ include ...%>. Kenny, is that what you had in mind? Or
defining the beans as inner classes of the JSP? Different functionality
could be isolated to different JSPs, so you could have databaseaccess.jsp or
someotherfunction.jsp, and only include what you need. Not as good as real
bean classes, but somewhat modular and reusable.
The included methods would become methods of your JSP so the syntax would be
a bit different.
With actual beans
<%@ page import="my.bean.package.MyBean" %>
<%
MyBean bean = new MyBean();
bean.someMethod();
%>
With included JSPs containing methods
<%@ include file="mybean.jsp" %>
<% someMethod(); %>
--
Eric
"Jeff Rozycki" <jroz...@digitalpublishers.com> wrote in message
news:4303e43d.0302...@posting.google.com...
Kenny MacLeod
warsa...@yahoo.com says...
>
> Kenny's suggestion would work. Instead of a bean, create a JSP and put the
> methods you want in the declaration directive <%! %>. Then include the
> necessary JSP with the methods you want in your "real" JSP with the include
> directive <%@ include ...%>. Kenny, is that what you had in mind? Or
> defining the beans as inner classes of the JSP? Different functionality
> could be isolated to different JSPs, so you could have databaseaccess.jsp or
> someotherfunction.jsp, and only include what you need. Not as good as real
> bean classes, but somewhat modular and reusable.
Exactly. Since you can define entire classes in a JSP (which compile as
java "local classes"), you can define all your beans in one (or many)
JSPs, and just include them as you go in your presentation JSPs.
> <%@ page import="my.bean.package.MyBean" %>
> <%
> MyBean bean = new MyBean();
> bean.someMethod();
> %>
You could probably still use the <jsp:useBean> syntax and not revert to
nasty scriptlets in your presentation JSPs.
kenny
Eric G
> > Kenny's suggestion would work. Instead of a bean, create a JSP and put
the
> > methods you want in the declaration directive <%! %>. Then include the
> > necessary JSP with the methods you want in your "real" JSP with the
include
> > directive <%@ include ...%>. Kenny, is that what you had in mind? Or
> > defining the beans as inner classes of the JSP? Different functionality
> > could be isolated to different JSPs, so you could have
databaseaccess.jsp or
> > someotherfunction.jsp, and only include what you need. Not as good as
real
> > bean classes, but somewhat modular and reusable.
>
> Exactly. Since you can define entire classes in a JSP (which compile as
> java "local classes"), you can define all your beans in one (or many)
> JSPs, and just include them as you go in your presentation JSPs.
>
That should work, though I have not tried it in practice because I've been
able to use standard beans. And of course you wouldn't need the import
anymore either.
Of course one thing to keep in mind if you modify one of the bean classes
all the JSPs including the page with the bean definitions will need to be
translated and compiled again. Because each bean is essentially duplicated
in every JSP that includes the JSP with the beans. For example, if you have
page1.jsp, page2.jsp and page3.jsp that included beans.jsp, every class
defined in beans.jsp will have a unique definition once included in page1,
page2 and page3. If you change a class, say MyBean, in beans.jsp and only
update page2.jsp, then page1 and page3 will have the original MyBean and
page2 will have the new MyBean.
> > <%@ page import="my.bean.package.MyBean" %>
> > <%
> > MyBean bean = new MyBean();
> > bean.someMethod();
> > %>
>
> You could probably still use the <jsp:useBean> syntax and not revert to
> nasty scriptlets in your presentation JSPs.
>
> kenny
Eric
Kenny MacLeod
warsa...@yahoo.com says...
>
> Of course one thing to keep in mind if you modify one of the bean classes
> all the JSPs including the page with the bean definitions will need to be
> translated and compiled again. Because each bean is essentially duplicated
> in every JSP that includes the JSP with the beans. For example, if you have
> page1.jsp, page2.jsp and page3.jsp that included beans.jsp, every class
> defined in beans.jsp will have a unique definition once included in page1,
> page2 and page3. If you change a class, say MyBean, in beans.jsp and only
> update page2.jsp, then page1 and page3 will have the original MyBean and
> page2 will have the new MyBean.
That's a good point. Furthermore, an instance of a bean created in
page1 will not be type-compatible with the same bean definition in
page2, since they're in reality entirely different classes.
So, for example, you couldn't create an instance of BeanA in page1, add
it to the request as an attribute, forward the request to page2, and
cast the attribute back to BeanA. You'd get a class cast exception.
Why did I recommend this approach again? :-)
kenny
Jeff Robertson
> I would hope a webmaster wouldn't treat JSP as any other HTML page. JSP
> allows the full power of the Java language where as a static HTML page
> doesn't. What the JSP can do may, and should, be limited by the security
> policy. Given that a servlet container is provided for employees to use AND
> that Jeff's JSPs worked I suspect it's actually a web app configuration
> thing and not a restriction of what classes can not be instantiated.
>
Maybe his IT department just meant that they won't provide him with
any way to compile Servlets/Beans *on the server*. Ie, no shell
account with access to a javac compiler.
Also, some servlet containers can be configured so that if you put a
.java file in the WEB-INF/classes directory, it will be automagically
compiled as needed for a servlet or a bean. Maybe his IT department
means that they do not support any such thing.
Kenny MacLeod
jeff_ro...@yahoo.com says...
>
> Maybe his IT department just meant that they won't provide him with
> any way to compile Servlets/Beans *on the server*. Ie, no shell
> account with access to a javac compiler.
>
> Also, some servlet containers can be configured so that if you put a
> .java file in the WEB-INF/classes directory, it will be automagically
> compiled as needed for a servlet or a bean. Maybe his IT department
> means that they do not support any such thing.
Another possibility is that the servlet container may not be webapp-
compliant.
e.g. iPlanet Web Server 4.1 supports servlets, but not without some
nasty configuration - it doesn't know what a webapp is.
kenny
Jeff Rozycki
O.K. I think I've convinced the person incharge of our webserver to
setup javabeans and servlets for individual users. But he does not
know how to do this. He asked me...
"Does it make sense for everyone to just throw their beans into one
directory? or should there be a definition (for where the beans are)
set up in the server for each application? As far as I know if we
created a cgi-bin like directory for javabeans you could not have sub
directories. Is that right or not?""
right now, I used netbeans and succesfully executed a javabean.
Netbeans setup the web app environment for me. When I try to view the
page outside of the IDE, our error log spits out:
[03/Mar/2003:19:06:56] info (32508): Internal Info: loading servlet
/homepages/users/eg42/timely.jsp
[03/Mar/2003:19:07:10] info (32508): JSP: JSP1x compiler threw
exception
org.apache.jasper.JasperException: Unable to load class CurrentBean
---
our directory structure for the webserver is like this:
H:\xLink\www-dev\homepages\users\eg42\
I am eg42. There are a bunch of other users under the users
directory. My directory for the test javabean is this:
H:\xLink\www-dev\homepages\users\eg42\timely.jsp
H:\xLink\www-dev\homepages\users\eg42\WEB-INF
and under WEB-INF:
web.xml
classes
lib
Kenny MacLeod
jroz...@digitalpublishers.com says...
> O.K. I think I've convinced the person incharge of our webserver to
> setup javabeans and servlets for individual users. But he does not
> know how to do this. He asked me...
>
> "Does it make sense for everyone to just throw their beans into one
> directory? or should there be a definition (for where the beans are)
> set up in the server for each application? As far as I know if we
> created a cgi-bin like directory for javabeans you could not have sub
> directories. Is that right or not?""
It depends on the server. If it's a servlet 2.2-compliant container,
then each web app gets it's own directory, under which is a WEB-INF
directory. This directory in turns contains a lib directory, which
should contain your code packages up as JAR files. The container picks
up the code dynamically, no config required, although you still have to
tell the server where your app directory sits.
If the server is not webapp-aware, then your admin will have to read the
manual :)
Note that there is no equivalent to the "user directory" concept in web
servers.
kenny
Jeff Rozycki
OK. My company's IT department has yet to set me up with a folder in
the CLASSPATH. But I can get this to work:
http://www-dev.ebnet.gdeb.com/homepages/groups/patran/time.jsp
filename: time.jsp
==
<%@ include file="includes/classes/currentTimeBean.jsp" %>
<HTML>
<BODY>
The time is: <BR>
<% CurrentTimeBean tjb = new CurrentTimeBean(); %>
<%= tjb.getHours() %>:<%= tjb.getMinutes() %>
</BODY>
</HTML>
==
filename: ./includes/classes/currentTimeBean.jsp
==
<%@ page import="java.util.*" %>
<%!
public class CurrentTimeBean {
private int hours;
private int minutes;
public CurrentTimeBean() {
Calendar now = Calendar.getInstance();
this.hours = now.get(Calendar.HOUR_OF_DAY);
this.minutes = now.get(Calendar.MINUTE);
}
public int getHours() {
return hours;
}
public int getMinutes() {
return minutes;
}
}
%>
==
but when I change time.jsp to use the useBean directive:
==
<%@ include file="includes/classes/currentTimeBean.jsp" %>
<HTML>
<BODY>
The time is: <BR>
<jsp:useBean id="myBean" scope="page" class="CurrentTimeBean"/>
</BODY>
</HTML>
==
I get the following error:
[10/Jun/2003:16:17:13] failure (30478): Internal error: exception
thrown from the servlet service function
(uri=/homepages/groups/patran/hello.jsp):
javax.servlet.ServletException: Cannot create bean of class
CurrentTimeBean, stack: javax.servlet.ServletException: Cannot create
bean of class CurrentTimeBean
at org.apache.jasper.runtime.PageContextImpl.handlePageException(PageContextImpl.java:384)
at _jsps._homepages._groups._patran._hello_jsp._jspService(_hello_jsp.java:121)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:126)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:826)
at com.netscape.server.http.servlet.NSServletRunner.Service(NSServletRunner.java:533)
, root cause: javax.servlet.ServletException: Cannot create bean of
class CurrentTimeBean
at _jsps._homepages._groups._patran._hello_jsp._jspService(_hello_jsp.java:104)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:126)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:826)
at com.netscape.server.http.servlet.NSServletRunner.Service(NSServletRunner.java:533)
I'd go with the working configuration but like Eric states, I'd have
to update all jsp files which reference the included class file or
else the jsp won't contained changed class. I assume if I can use the
useBean, that jsp files will automatically pick up a changed class.
Thanks for the help,
Jeff