Harold Ensle wrote:
"Raymond DeCampo" <rd******@spa m-I-am-not.twcny.rr.co m> wrote in message
news:Va******** *********@twist er.nyroc.rr.com ...
Harold Ensle wrote:
I am using Jserv on apache and I cannot instantiate from a class file in
JSP.
I was using servlets before and any class I put in the same directory
(or
other directories indicated with a classpath in the Jservproperties
file)
would work fine. But JSP files (which are in a different directory)
cannot
seem to find my classes no matter where I put them...whether in a
classpath
or not. I even put them in the WEB_INF/classes folder and still nothing.
I have searched everywhere for an answer. Does anyone know???
Harold,
Perhaps you should post some sample code and describe the directory
structure of your WAR. One question comes to mind however: did you
import the desired classes with <@page import="" @> ?
Ray
Thank you for the reply. This seems to be part of the problem. So I now have
something
like:
<%@ page import="ZClass" %>
<%
ZClass zc=new ZClass(1);
%>
The class itself has:
public class ZClass
{
ZClass(int x)
{
......
}
}
Now the JSP is acting like it finds the class (no error on the import)
but it is saying there is no constructor of the type to be found.
But I see a constructor there. What did I do wrong?
(I think Java hates me.)
I would wager that the issue is that you didn't declare the constructor
public, like so:
public class ZClass
{
public ZClass(int x)
{
......
}
}
Java defines four access levels: public, protected, private and package
or default. Package level is the default that is used when no access
specifier is, well, specified. (IMHO, it would have been better to make
an explicit keyword for package level and require one.) Public,
protected and private behave as one would expect from other OO
languages. Package level defines an access level within a package; any
class within the same package can access the method, variable, etc.
This provides functionality similar to C++ friends. Note that unless
the package is sealed, nothing prevents others from creating classes in
the same package and exploiting the access, if you care about that sort
of thing.
Another interesting thing is that the access levels in descending order
are public, protected, package and private. That means that protected
implies package. Which means that you cannot have methods, variables
etc that are visible to the subclass but not to the other members of the
package. (IMHO, I would have preferred public, package, protected and
private; or even something not well-ordered where package and protected
are unrelated.)
Ray
