You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Vernon Wu <ve...@gatewaytech.com> on 2002/05/30 05:04:57 UTC

Unable to find setter: a problem with custom tag in TC 4.0.4b2

Hi, all,

I run into an error message on Tomcat 4.0.4b2 when I use a custom tag in a JSP   file. The error message is:

/jsp/fullsearchlist/content.jsp(4,0) Unable to find setter method for attribute:   numItems

The code fragment is  the followings:

public abstract class ListTag extends TagSupport {
	// ...
  protected int numItems = -1;
	//...

  // setters
  public void setNumItems(String numItemsStr) {
    numItems = Integer.parseInt(numItemsStr);
  }
}

public abstract class SearchListTag extends ListTag {
	//...
  // setters (overloaded to fix bug in tomcat)
  public void setNumItems(String numItemsStr) {
    super.setNumItems(numItemsStr);
  }
}

public class FullSearchListTag extends SearchListTag {
	//...
  public void setNumItems(String numItemsStr) {
    super.setNumItems(numItemsStr);
  }
}

I have tried to remove the setNumItems method from SearchList and/or   FullSearchList, but can't resolute the problem. 
I
learn that there was a bug led to this problem in the early version of Tomcat. Is   the bug unresolved yet? How I can
overcome this problem?

Thanks very much in advance.

Vernon



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Unable to find setter: a problem with custom tag in TC 4.0.4b2

Posted by Vernon Wu <ve...@gatewaytech.com>.
I don't run the PetStore at all, but use a small portion of the framework with a litte modification. I don't observe any 
compatible problem other than the tag names changed in the new tld file.

Here is the jsp file.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
<%@ page contentType='text/html; charset=UTF-8' %>
<%@ taglib uri="/WEB-INF/tlds/taglib.tld" prefix="mm" %>

<p>
<mm:fullSearchList numItems="15" emptyList="No matches found.">
</p>


<table width="100%" border="0" cellspacing="1" cellpadding="0" align="center">
<mm:items>
  <tr> 
    <td rowspan="3">&nbsp;</td>
    <td><mm:matchAttribute attribute="headline"/></td>
  </tr>
  <tr> 
    <td>&nbsp;</td>
  </tr>
  <tr> 
    <td><mm:matchAttribute attribute="age"/></td>
  </tr>
  <tr> 
    <td><mm:matchAttribute attribute="id"/></td>
    <td><mm:matchAttribute attribute="location"/></td>
  </tr>
</mm:items>
  <tr> 
  <mm:prevForm action='<%=response.encodeURL("full-search-action.do")%>'>
    <td><a href="">Previous</a></td>
  </mm:prevForm>

  <mm:nextForm action='<%=response.encodeURL("full-search-action.do")%>'>
    <td>
      <div align="right"><a href="">Next</a></div>
    </td>
  </mm:nextForm>
  </tr>
</table>
</mm:fullSearchList>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If I change the numItems as not request in the tld file and remove it in this jsp file. It can be translated and verything is 
fine. Otherwise, the exception occures and as you know no Java file is created in the work directory. Strange enough, 
the emptyList is done in the same fashion and has no problem at all. 



6/2/2002 8:05:41 AM, Phillip Morelock <su...@phillipmorelock.com> wrote:

>Are you just running the pet store example, cold or with your own edits?
>how old is it?  You must be running tomcat 4, right?  maybe the example is
>for 3, although in theory most stuff is backward compatible...
>
>Also, it might help of course to see some jsp -- I assume you're already
>doing everything "right" of course.  You didn't respond about what you found
>under the /work directory for this.  What do you see there?  I am assuming
>nothing.
>
>fillup
>
>
>On 6/1/02 1:46 AM, "Vernon Wu" <ve...@gatewaytech.com> wrote:
>
>> 
>> Thanks very much, Philip for your quick response.
>> 
>> You are right. Theoretically, the numItems should be declaimed as a private
>> but not protected attribute. I, however,
>> don't think that is the cause, but why the TC keeps a blind eye on the setter
>> method. The fragment of code is based on
>> petstore 1.1.2 to have list of items. The commend, "setters (overloaded to fix
>> bug in tomcat)", is made by the PetStore
>> team. So I can assume there was a bug at the time. Now, the question whether
>> the bug is still there.
>> 
>> I had have a look at the stack trace and can't find any cue of the problem at
>> all.  Here is it:
>> 
>> 2002-05-30 04:20:25 ApplicationDispatcher[/mm] Servlet.service() for servlet
>> jsp threw exception
>> org.apache.jasper.compiler.CompileException:
>> /jsp/fullsearchlist/content.jsp(4,0) Unable to find setter method for
>> attribute: numItems
>> at 
>> org.apache.jasper.compiler.TagBeginGenerator.generateSetters(TagBeginGenerator
>> .java:214)
>> at 
>> org.apache.jasper.compiler.TagBeginGenerator.generateServiceMethodStatements
>> (TagBeginGenerator.java:332)
>> at 
>> org.apache.jasper.compiler.TagBeginGenerator.generate(TagBeginGenerator.java:3
>> 94)
>> at org.apache.jasper.compiler.JspParseEventListener$GeneratorWrapper.generate
>> (JspParseEventListener.java:834)
>> at 
>> org.apache.jasper.compiler.JspParseEventListener.generateAll(JspParseEventList
>> ener.java:241)
>> at 
>> org.apache.jasper.compiler.JspParseEventListener.endPageProcessing(JspParseEve
>> ntListener.java:197)
>> at org.apache.jasper.compiler.Compiler.compile(Compiler.java:215)
>> at org.apache.jasper.servlet.JspServlet.loadJSP(JspServlet.java:552)
>> at 
>> org.apache.jasper.servlet.JspServlet$JspServletWrapper.loadIfNecessary(JspServ
>> let.java:177)
>> at 
>> org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.java
>> :189)
>> at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:382)
>> at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:474)
>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
>> at 
>> org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.ja
>> va:683)
>> at 
>> org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher
>> .java:574)
>> at 
>> org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.j
>> ava:497)
>> at 
>> 
>org.apache.jasper.runtime.JspRuntimeLibrary.include(JspRuntimeLibrary.java:819>
>)
>> at org.apache.jasper.runtime.PageContextImpl.include(PageContextImpl.java:391)
>> at com.vernonwu.waf.view.template.Section.render(Section.java:41)
>> at com.vernonwu.waf.view.template.tags.RenderTag.doEndTag(RenderTag.java:57)
>> at org.apache.jsp.hscf$jsp._jspService(hscf$jsp.java:167)
>> at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:107)
>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
>> at 
>> org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.java
>> :202)
>> at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:382)
>> at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:474)
>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
>> at 
>> org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.ja
>> va:683)
>> at 
>> org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher
>> .java:574)
>> at 
>> org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.j
>> ava:497)
>> at 
>> 
>org.apache.jasper.runtime.JspRuntimeLibrary.include(JspRuntimeLibrary.java:819>
>)
>> at org.apache.jasper.runtime.PageContextImpl.include(PageContextImpl.java:391)
>> at com.vernonwu.waf.view.template.Region.render(Region.java:35)
>> at com.vernonwu.waf.view.template.tags.RenderTag.doEndTag(RenderTag.java:61)
>> at org.apache.jsp.page$jsp._jspService(page$jsp.java:2198)
>> at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:107)
>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
>> at 
>> org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.java
>> :202)
>> at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:382)
>> at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:474)
>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
>> at 
>> org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.ja
>> va:683)
>> at 
>> org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher
>> .java:431)
>> at 
>> org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.j
>> ava:355)
>> at 
>> com.vernonwu.waf.controller.web.action.HTMLActionRouter.route(HTMLActionRouter
>> .java:44)
>> at 
>> com.vernonwu.waf.controller.web.ActionServlet.routeAction(ActionServlet.java:9
>> 7)
>> at 
>> com.vernonwu.waf.controller.web.ActionServlet.service(ActionServlet.java:61)
>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
>> at 
>> org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.ja
>> va:683)
>> at 
>> org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher
>> .java:431)
>> at 
>> org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.j
>> ava:355)
>> at org.apache.jasper.runtime.PageContextImpl.forward(PageContextImpl.java:414)
>> at 
>> org.apache.jsp.validate_0002dfullsearch$jsp._jspService(validate_0002dfullsear
>> ch$jsp.java:93)
>> at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:107)
>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
>> at 
>> org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.java
>> :202)
>> at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:382)
>> at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:474)
>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
>> at 
>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFi
>> lterChain.java:247)
>> at 
>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChai
>> n.java:193)
>> at 
>> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java
>> :243)
>> at 
>> 
>org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566>
>)
>> at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
>> at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
>> at 
>> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java
>> :190)
>> at 
>> 
>org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566>
>)
>> at 
>> 
>org.apache.catalina.valves.CertificatesValve.invoke(CertificatesValve.java:246>
>)
>> at 
>> 
>org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564>
>)
>> at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
>> at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
>> at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2347)
>> at 
>> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180)
>> at 
>> 
>org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566>
>)
>> at 
>> org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.ja
>> va:170)
>> at 
>> 
>org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564>
>)
>> at 
>> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:170)
>> at 
>> 
>org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564>
>)
>> at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:468)
>> at 
>> 
>org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564>
>)
>> at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
>> at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
>> at 
>> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:1
>> 74)
>> at 
>> 
>org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566>
>)
>> at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
>> at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
>> at 
>> org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.java:10
>> 17)
>> at 
>> org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:1115)
>> at java.lang.Thread.run(Thread.java:536)
>> 
>> 
>> 6/2/2002 7:08:08 AM, Phillip Morelock <su...@phillipmorelock.com>
>> wrote:
>> 
>>> I don't know if this is the desired answer, and don't have time to think
>>> about the Java language issues here, but a quick fix would be to change:
>>> 
>>> protected int numItems = -1;
>>> 
>>> to
>>> 
>>> private int numItems = -1;
>>> 
>>> Then remove the overrides from Search and FullSearch classes.  Then ensure
>>> that all access to the numItems variable occurs through getNumItems() and
>>> setNumItems() in the base class, ListTag.
>>> 
>>> I have a feeling this has something to do with the fact that jsp:setProperty
>>> can take two courses:
>>> 1.  Set a public variable directly if it has the same name
>>> 2.  Prepend "set" and adjust capitalization, as you seem to have
>>> anticipated.
>>> 
>>> I would think, though, that option #1 would be excluded in this case because
>>> the java compiler would refuse to compile your jsp if it thought you were
>>> exactly trying to address a non-permitted variable (which the protected
>>> variable shouldn't be permitted).
>>> 
>>> Can you send the stack trace of the exception?  Also, do you know that the
>>> translated version of your page (the .java file it gets converted into) is
>>> in the /work directory?  Check that out (_if_ tomcat got past the
>>> translation phase, this is why you need to provide the stack trace) and you
>>> can usually pinpoint your problem.
>>> 
>>> fillup
>>> 
>>> P.S.  Subclasses inherit all the public methods of all superclasses, so I
>>> don't really understand your overrides.
>>> 
>>> On 5/29/02 8:04 PM, "Vernon Wu" <ve...@gatewaytech.com> wrote:
>>> 
>>>> Hi, all,
>>>> 
>>>> I run into an error message on Tomcat 4.0.4b2 when I use a custom tag in a
>>>> JSP
>>>> file. The error message is:
>>>> 
>>>> /jsp/fullsearchlist/content.jsp(4,0) Unable to find setter method for
>>>> attribute:   numItems
>>>> 
>>>> The code fragment is  the followings:
>>>> 
>>>> public abstract class ListTag extends TagSupport {
>>>> // ...
>>>> protected int numItems = -1;
>>>> //...
>>>> 
>>>> // setters
>>>> public void setNumItems(String numItemsStr) {
>>>>   numItems = Integer.parseInt(numItemsStr);
>>>> }
>>>> }
>>>> 
>>>> public abstract class SearchListTag extends ListTag {
>>>> //...
>>>> // setters (overloaded to fix bug in tomcat)
>>>> public void setNumItems(String numItemsStr) {
>>>>   super.setNumItems(numItemsStr);
>>>> }
>>>> }
>>>> 
>>>> public class FullSearchListTag extends SearchListTag {
>>>> //...
>>>> public void setNumItems(String numItemsStr) {
>>>>   super.setNumItems(numItemsStr);
>>>> }
>>>> }
>>>> 
>>>> I have tried to remove the setNumItems method from SearchList and/or
>>>> FullSearchList, but can't resolute the problem.
>>>> I
>>>> learn that there was a bug led to this problem in the early version of
>>>> Tomcat.
>>>> Is   the bug unresolved yet? How I can
>>>> overcome this problem?
>>>> 
>>>> Thanks very much in advance.
>>>> 
>>>> Vernon
>>>> 
>>>> 
>>>> 
>>>> --
>>>> To unsubscribe, e-mail:
>>>> <ma...@jakarta.apache.org>
>>>> For additional commands, e-mail:
>>>> <ma...@jakarta.apache.org>
>>>> 
>>> 
>>> 
>>> --
>>> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
>>> For additional commands, e-mail: <ma...@jakarta.apache.org>
>>> 
>>> 
>> 
>> 
>> 
>> 
>> --
>> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
>> For additional commands, e-mail: <ma...@jakarta.apache.org>
>> 
>
>
>--
>To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Installing/Configuring Tomcat 3.3.1

Posted by Alexis Michelle Goldstein <am...@columbia.edu>.
I got it, thanks so much!

Regards,

Alexis


On Sat, 1 Jun 2002, Phillip Morelock wrote:

> > SET JAVA_HOME=C:\JDK1.3.1_03
>
> also:
> SET TOMCAT_HOME=C:\Where\You\Put\Tomcat
>
> and to make it not "flash away quickly" I think you can start tomcat
> differently.
>
> you probably do
> startup.bat
> or
> startup
>
> try
> tomcat.bat start
>
> instead i think (could be wrong, don't have windows).
>
> fillup
>
>
> On 6/1/02 5:18 PM, "Alexis Michelle Goldstein" <am...@columbia.edu> wrote:
>
> > Dear all,
> >
> > I am at my wit's end trying to configure Tomcat on my laptop.
> >
> > I've tried tomcat 3.3.1, Tomcat 4.0.3 and now 4.0.1 to no avail, each with
> > their own problems.  The closest I've gotten is with 3.3.1, so I'm trying
> > that again.  Previously, I'd been able to get the Tomcat server up and
> > running, and my only problem was with my java comiler.  I (unreasonably)
> > decided to start all over again with another version (the one my book
> > walked me through).  Now I can't even start the server.  It begins for a
> > few secods (in anoher msdos window that says "JAVA") and then shuts
> > down almost immediately.  I can just barely read something that
> > flashes across that appears to be "exception in 'main'"
> > or some kind of exception.
> >
> >
> > I've been following instructions first at:
> > http://archive.coreservlets.com/Using-Tomcat-3.2.html or
> > http://www.moreservlets.com/Using-Tomcat-4.html
> >
> > now I'm using
> > http://jakarta.apache.org/tomcat/tomcat-3.3-doc/tomcat-ug.html
> >
> > I've changed my memory settings to 4096, but still when I run startup,
> > the new window opens up only for a few seconds before shutting down again.
> >
> > I also modified config.sys as follows
> > SHELL=C:\COMMAND.COM /E:4096 /P
> >
> > I am using windows 98, have set autoexec.bat to read:
> > SET JAVA_HOME=C:\JDK1.3.1_03
> >
> > and I appended my PATH to inlcude the last bit, as mcafee
> > already has a PATH setting in my autoexec.bat:
> >
> > SET PATH=%PATH%;C:\PROGRA~1\NETWOR~1\MCAFEE~1;C:\JDK1.3.1_03\BIN
> >
> > Obviously I have no clue what I'm doing so I'm just trying to follow
> > instructions.  Are there settings I may have set for my attempts at
> > installing previous version that need to be changed? I'm really at a loss
> > and would appreciate any suggestions as to other user guides online or if
> > anyone has any insights.
> >
> > Thanks,
> >
> > Alexis
> >
> >
> > --
> > To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> > For additional commands, e-mail: <ma...@jakarta.apache.org>
> >
>
>
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Installing/Configuring Tomcat 3.3.1

Posted by Phillip Morelock <su...@phillipmorelock.com>.
> SET JAVA_HOME=C:\JDK1.3.1_03

also:
SET TOMCAT_HOME=C:\Where\You\Put\Tomcat

and to make it not "flash away quickly" I think you can start tomcat
differently.

you probably do 
startup.bat
or
startup

try 
tomcat.bat start

instead i think (could be wrong, don't have windows).

fillup


On 6/1/02 5:18 PM, "Alexis Michelle Goldstein" <am...@columbia.edu> wrote:

> Dear all,
> 
> I am at my wit's end trying to configure Tomcat on my laptop.
> 
> I've tried tomcat 3.3.1, Tomcat 4.0.3 and now 4.0.1 to no avail, each with
> their own problems.  The closest I've gotten is with 3.3.1, so I'm trying
> that again.  Previously, I'd been able to get the Tomcat server up and
> running, and my only problem was with my java comiler.  I (unreasonably)
> decided to start all over again with another version (the one my book
> walked me through).  Now I can't even start the server.  It begins for a
> few secods (in anoher msdos window that says "JAVA") and then shuts
> down almost immediately.  I can just barely read something that
> flashes across that appears to be "exception in 'main'"
> or some kind of exception.
> 
> 
> I've been following instructions first at:
> http://archive.coreservlets.com/Using-Tomcat-3.2.html or
> http://www.moreservlets.com/Using-Tomcat-4.html
> 
> now I'm using
> http://jakarta.apache.org/tomcat/tomcat-3.3-doc/tomcat-ug.html
> 
> I've changed my memory settings to 4096, but still when I run startup,
> the new window opens up only for a few seconds before shutting down again.
> 
> I also modified config.sys as follows
> SHELL=C:\COMMAND.COM /E:4096 /P
> 
> I am using windows 98, have set autoexec.bat to read:
> SET JAVA_HOME=C:\JDK1.3.1_03
> 
> and I appended my PATH to inlcude the last bit, as mcafee
> already has a PATH setting in my autoexec.bat:
> 
> SET PATH=%PATH%;C:\PROGRA~1\NETWOR~1\MCAFEE~1;C:\JDK1.3.1_03\BIN
> 
> Obviously I have no clue what I'm doing so I'm just trying to follow
> instructions.  Are there settings I may have set for my attempts at
> installing previous version that need to be changed? I'm really at a loss
> and would appreciate any suggestions as to other user guides online or if
> anyone has any insights.
> 
> Thanks,
> 
> Alexis
> 
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
> 


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Installing/Configuring Tomcat 3.3.1

Posted by Alexis Michelle Goldstein <am...@columbia.edu>.
Dear all,

I am at my wit's end trying to configure Tomcat on my laptop.

I've tried tomcat 3.3.1, Tomcat 4.0.3 and now 4.0.1 to no avail, each with
their own problems.  The closest I've gotten is with 3.3.1, so I'm trying
that again.  Previously, I'd been able to get the Tomcat server up and
running, and my only problem was with my java comiler.  I (unreasonably)
decided to start all over again with another version (the one my book
walked me through).  Now I can't even start the server.  It begins for a
few secods (in anoher msdos window that says "JAVA") and then shuts
down almost immediately.  I can just barely read something that
flashes across that appears to be "exception in 'main'"
or some kind of exception.


I've been following instructions first at:
http://archive.coreservlets.com/Using-Tomcat-3.2.html or
http://www.moreservlets.com/Using-Tomcat-4.html

now I'm using
http://jakarta.apache.org/tomcat/tomcat-3.3-doc/tomcat-ug.html

I've changed my memory settings to 4096, but still when I run startup,
the new window opens up only for a few seconds before shutting down again.

I also modified config.sys as follows
SHELL=C:\COMMAND.COM /E:4096 /P

I am using windows 98, have set autoexec.bat to read:
SET JAVA_HOME=C:\JDK1.3.1_03

and I appended my PATH to inlcude the last bit, as mcafee
already has a PATH setting in my autoexec.bat:

SET PATH=%PATH%;C:\PROGRA~1\NETWOR~1\MCAFEE~1;C:\JDK1.3.1_03\BIN

Obviously I have no clue what I'm doing so I'm just trying to follow
instructions.  Are there settings I may have set for my attempts at
installing previous version that need to be changed? I'm really at a loss
and would appreciate any suggestions as to other user guides online or if
anyone has any insights.

Thanks,

Alexis


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Unable to find setter: a problem with custom tag in TC 4.0.4b2

Posted by Phillip Morelock <su...@phillipmorelock.com>.
Are you just running the pet store example, cold or with your own edits?
how old is it?  You must be running tomcat 4, right?  maybe the example is
for 3, although in theory most stuff is backward compatible...

Also, it might help of course to see some jsp -- I assume you're already
doing everything "right" of course.  You didn't respond about what you found
under the /work directory for this.  What do you see there?  I am assuming
nothing.

fillup


On 6/1/02 1:46 AM, "Vernon Wu" <ve...@gatewaytech.com> wrote:

> 
> Thanks very much, Philip for your quick response.
> 
> You are right. Theoretically, the numItems should be declaimed as a private
> but not protected attribute. I, however,
> don't think that is the cause, but why the TC keeps a blind eye on the setter
> method. The fragment of code is based on
> petstore 1.1.2 to have list of items. The commend, "setters (overloaded to fix
> bug in tomcat)", is made by the PetStore
> team. So I can assume there was a bug at the time. Now, the question whether
> the bug is still there.
> 
> I had have a look at the stack trace and can't find any cue of the problem at
> all.  Here is it:
> 
> 2002-05-30 04:20:25 ApplicationDispatcher[/mm] Servlet.service() for servlet
> jsp threw exception
> org.apache.jasper.compiler.CompileException:
> /jsp/fullsearchlist/content.jsp(4,0) Unable to find setter method for
> attribute: numItems
> at 
> org.apache.jasper.compiler.TagBeginGenerator.generateSetters(TagBeginGenerator
> .java:214)
> at 
> org.apache.jasper.compiler.TagBeginGenerator.generateServiceMethodStatements
> (TagBeginGenerator.java:332)
> at 
> org.apache.jasper.compiler.TagBeginGenerator.generate(TagBeginGenerator.java:3
> 94)
> at org.apache.jasper.compiler.JspParseEventListener$GeneratorWrapper.generate
> (JspParseEventListener.java:834)
> at 
> org.apache.jasper.compiler.JspParseEventListener.generateAll(JspParseEventList
> ener.java:241)
> at 
> org.apache.jasper.compiler.JspParseEventListener.endPageProcessing(JspParseEve
> ntListener.java:197)
> at org.apache.jasper.compiler.Compiler.compile(Compiler.java:215)
> at org.apache.jasper.servlet.JspServlet.loadJSP(JspServlet.java:552)
> at 
> org.apache.jasper.servlet.JspServlet$JspServletWrapper.loadIfNecessary(JspServ
> let.java:177)
> at 
> org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.java
> :189)
> at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:382)
> at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:474)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
> at 
> org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.ja
> va:683)
> at 
> org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher
> .java:574)
> at 
> org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.j
> ava:497)
> at 
> 
org.apache.jasper.runtime.JspRuntimeLibrary.include(JspRuntimeLibrary.java:819>
)
> at org.apache.jasper.runtime.PageContextImpl.include(PageContextImpl.java:391)
> at com.vernonwu.waf.view.template.Section.render(Section.java:41)
> at com.vernonwu.waf.view.template.tags.RenderTag.doEndTag(RenderTag.java:57)
> at org.apache.jsp.hscf$jsp._jspService(hscf$jsp.java:167)
> at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:107)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
> at 
> org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.java
> :202)
> at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:382)
> at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:474)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
> at 
> org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.ja
> va:683)
> at 
> org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher
> .java:574)
> at 
> org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.j
> ava:497)
> at 
> 
org.apache.jasper.runtime.JspRuntimeLibrary.include(JspRuntimeLibrary.java:819>
)
> at org.apache.jasper.runtime.PageContextImpl.include(PageContextImpl.java:391)
> at com.vernonwu.waf.view.template.Region.render(Region.java:35)
> at com.vernonwu.waf.view.template.tags.RenderTag.doEndTag(RenderTag.java:61)
> at org.apache.jsp.page$jsp._jspService(page$jsp.java:2198)
> at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:107)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
> at 
> org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.java
> :202)
> at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:382)
> at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:474)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
> at 
> org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.ja
> va:683)
> at 
> org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher
> .java:431)
> at 
> org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.j
> ava:355)
> at 
> com.vernonwu.waf.controller.web.action.HTMLActionRouter.route(HTMLActionRouter
> .java:44)
> at 
> com.vernonwu.waf.controller.web.ActionServlet.routeAction(ActionServlet.java:9
> 7)
> at 
> com.vernonwu.waf.controller.web.ActionServlet.service(ActionServlet.java:61)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
> at 
> org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.ja
> va:683)
> at 
> org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher
> .java:431)
> at 
> org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.j
> ava:355)
> at org.apache.jasper.runtime.PageContextImpl.forward(PageContextImpl.java:414)
> at 
> org.apache.jsp.validate_0002dfullsearch$jsp._jspService(validate_0002dfullsear
> ch$jsp.java:93)
> at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:107)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
> at 
> org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.java
> :202)
> at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:382)
> at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:474)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
> at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFi
> lterChain.java:247)
> at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChai
> n.java:193)
> at 
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java
> :243)
> at 
> 
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566>
)
> at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
> at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
> at 
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java
> :190)
> at 
> 
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566>
)
> at 
> 
org.apache.catalina.valves.CertificatesValve.invoke(CertificatesValve.java:246>
)
> at 
> 
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564>
)
> at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
> at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
> at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2347)
> at 
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180)
> at 
> 
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566>
)
> at 
> org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.ja
> va:170)
> at 
> 
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564>
)
> at 
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:170)
> at 
> 
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564>
)
> at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:468)
> at 
> 
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564>
)
> at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
> at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
> at 
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:1
> 74)
> at 
> 
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566>
)
> at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
> at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
> at 
> org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.java:10
> 17)
> at 
> org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:1115)
> at java.lang.Thread.run(Thread.java:536)
> 
> 
> 6/2/2002 7:08:08 AM, Phillip Morelock <su...@phillipmorelock.com>
> wrote:
> 
>> I don't know if this is the desired answer, and don't have time to think
>> about the Java language issues here, but a quick fix would be to change:
>> 
>> protected int numItems = -1;
>> 
>> to
>> 
>> private int numItems = -1;
>> 
>> Then remove the overrides from Search and FullSearch classes.  Then ensure
>> that all access to the numItems variable occurs through getNumItems() and
>> setNumItems() in the base class, ListTag.
>> 
>> I have a feeling this has something to do with the fact that jsp:setProperty
>> can take two courses:
>> 1.  Set a public variable directly if it has the same name
>> 2.  Prepend "set" and adjust capitalization, as you seem to have
>> anticipated.
>> 
>> I would think, though, that option #1 would be excluded in this case because
>> the java compiler would refuse to compile your jsp if it thought you were
>> exactly trying to address a non-permitted variable (which the protected
>> variable shouldn't be permitted).
>> 
>> Can you send the stack trace of the exception?  Also, do you know that the
>> translated version of your page (the .java file it gets converted into) is
>> in the /work directory?  Check that out (_if_ tomcat got past the
>> translation phase, this is why you need to provide the stack trace) and you
>> can usually pinpoint your problem.
>> 
>> fillup
>> 
>> P.S.  Subclasses inherit all the public methods of all superclasses, so I
>> don't really understand your overrides.
>> 
>> On 5/29/02 8:04 PM, "Vernon Wu" <ve...@gatewaytech.com> wrote:
>> 
>>> Hi, all,
>>> 
>>> I run into an error message on Tomcat 4.0.4b2 when I use a custom tag in a
>>> JSP
>>> file. The error message is:
>>> 
>>> /jsp/fullsearchlist/content.jsp(4,0) Unable to find setter method for
>>> attribute:   numItems
>>> 
>>> The code fragment is  the followings:
>>> 
>>> public abstract class ListTag extends TagSupport {
>>> // ...
>>> protected int numItems = -1;
>>> //...
>>> 
>>> // setters
>>> public void setNumItems(String numItemsStr) {
>>>   numItems = Integer.parseInt(numItemsStr);
>>> }
>>> }
>>> 
>>> public abstract class SearchListTag extends ListTag {
>>> //...
>>> // setters (overloaded to fix bug in tomcat)
>>> public void setNumItems(String numItemsStr) {
>>>   super.setNumItems(numItemsStr);
>>> }
>>> }
>>> 
>>> public class FullSearchListTag extends SearchListTag {
>>> //...
>>> public void setNumItems(String numItemsStr) {
>>>   super.setNumItems(numItemsStr);
>>> }
>>> }
>>> 
>>> I have tried to remove the setNumItems method from SearchList and/or
>>> FullSearchList, but can't resolute the problem.
>>> I
>>> learn that there was a bug led to this problem in the early version of
>>> Tomcat.
>>> Is   the bug unresolved yet? How I can
>>> overcome this problem?
>>> 
>>> Thanks very much in advance.
>>> 
>>> Vernon
>>> 
>>> 
>>> 
>>> --
>>> To unsubscribe, e-mail:
>>> <ma...@jakarta.apache.org>
>>> For additional commands, e-mail:
>>> <ma...@jakarta.apache.org>
>>> 
>> 
>> 
>> --
>> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
>> For additional commands, e-mail: <ma...@jakarta.apache.org>
>> 
>> 
> 
> 
> 
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
> 


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Unable to find setter: a problem with custom tag in TC 4.0.4b2

Posted by Vernon Wu <ve...@gatewaytech.com>.
Thanks very much, Philip for your quick response.

You are right. Theoretically, the numItems should be declaimed as a private but not protected attribute. I, however, 
don't think that is the cause, but why the TC keeps a blind eye on the setter method. The fragment of code is based on 
petstore 1.1.2 to have list of items. The commend, "setters (overloaded to fix bug in tomcat)", is made by the PetStore 
team. So I can assume there was a bug at the time. Now, the question whether the bug is still there.

I had have a look at the stack trace and can't find any cue of the problem at all.  Here is it:

2002-05-30 04:20:25 ApplicationDispatcher[/mm] Servlet.service() for servlet jsp threw exception
org.apache.jasper.compiler.CompileException: /jsp/fullsearchlist/content.jsp(4,0) Unable to find setter method for 
attribute: numItems
	at org.apache.jasper.compiler.TagBeginGenerator.generateSetters(TagBeginGenerator.java:214)
	at org.apache.jasper.compiler.TagBeginGenerator.generateServiceMethodStatements
(TagBeginGenerator.java:332)
	at org.apache.jasper.compiler.TagBeginGenerator.generate(TagBeginGenerator.java:394)
	at org.apache.jasper.compiler.JspParseEventListener$GeneratorWrapper.generate
(JspParseEventListener.java:834)
	at org.apache.jasper.compiler.JspParseEventListener.generateAll(JspParseEventListener.java:241)
	at org.apache.jasper.compiler.JspParseEventListener.endPageProcessing(JspParseEventListener.java:197)
	at org.apache.jasper.compiler.Compiler.compile(Compiler.java:215)
	at org.apache.jasper.servlet.JspServlet.loadJSP(JspServlet.java:552)
	at org.apache.jasper.servlet.JspServlet$JspServletWrapper.loadIfNecessary(JspServlet.java:177)
	at org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.java:189)
	at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:382)
	at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:474)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
	at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:683)
	at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:574)
	at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:497)
	at org.apache.jasper.runtime.JspRuntimeLibrary.include(JspRuntimeLibrary.java:819)
	at org.apache.jasper.runtime.PageContextImpl.include(PageContextImpl.java:391)
	at com.vernonwu.waf.view.template.Section.render(Section.java:41)
	at com.vernonwu.waf.view.template.tags.RenderTag.doEndTag(RenderTag.java:57)
	at org.apache.jsp.hscf$jsp._jspService(hscf$jsp.java:167)
	at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:107)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
	at org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.java:202)
	at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:382)
	at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:474)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
	at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:683)
	at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:574)
	at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:497)
	at org.apache.jasper.runtime.JspRuntimeLibrary.include(JspRuntimeLibrary.java:819)
	at org.apache.jasper.runtime.PageContextImpl.include(PageContextImpl.java:391)
	at com.vernonwu.waf.view.template.Region.render(Region.java:35)
	at com.vernonwu.waf.view.template.tags.RenderTag.doEndTag(RenderTag.java:61)
	at org.apache.jsp.page$jsp._jspService(page$jsp.java:2198)
	at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:107)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
	at org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.java:202)
	at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:382)
	at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:474)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
	at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:683)
	at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:431)
	at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:355)
	at com.vernonwu.waf.controller.web.action.HTMLActionRouter.route(HTMLActionRouter.java:44)
	at com.vernonwu.waf.controller.web.ActionServlet.routeAction(ActionServlet.java:97)
	at com.vernonwu.waf.controller.web.ActionServlet.service(ActionServlet.java:61)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
	at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:683)
	at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:431)
	at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:355)
	at org.apache.jasper.runtime.PageContextImpl.forward(PageContextImpl.java:414)
	at org.apache.jsp.validate_0002dfullsearch$jsp._jspService(validate_0002dfullsearch$jsp.java:93)
	at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:107)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
	at org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.java:202)
	at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:382)
	at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:474)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:243)
	at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
	at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:190)
	at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
	at org.apache.catalina.valves.CertificatesValve.invoke(CertificatesValve.java:246)
	at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
	at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
	at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2347)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180)
	at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
	at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:170)
	at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564)
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:170)
	at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564)
	at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:468)
	at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
	at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:174)
	at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
	at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
	at org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.java:1017)
	at org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:1115)
	at java.lang.Thread.run(Thread.java:536)


6/2/2002 7:08:08 AM, Phillip Morelock <su...@phillipmorelock.com> wrote:

>I don't know if this is the desired answer, and don't have time to think
>about the Java language issues here, but a quick fix would be to change:
> 
>protected int numItems = -1;
>
>to
>
>private int numItems = -1;
>
>Then remove the overrides from Search and FullSearch classes.  Then ensure
>that all access to the numItems variable occurs through getNumItems() and
>setNumItems() in the base class, ListTag.
>
>I have a feeling this has something to do with the fact that jsp:setProperty
>can take two courses:
>1.  Set a public variable directly if it has the same name
>2.  Prepend "set" and adjust capitalization, as you seem to have
>anticipated.
>
>I would think, though, that option #1 would be excluded in this case because
>the java compiler would refuse to compile your jsp if it thought you were
>exactly trying to address a non-permitted variable (which the protected
>variable shouldn't be permitted).
>
>Can you send the stack trace of the exception?  Also, do you know that the
>translated version of your page (the .java file it gets converted into) is
>in the /work directory?  Check that out (_if_ tomcat got past the
>translation phase, this is why you need to provide the stack trace) and you
>can usually pinpoint your problem.
>
>fillup
>
>P.S.  Subclasses inherit all the public methods of all superclasses, so I
>don't really understand your overrides.
>
>On 5/29/02 8:04 PM, "Vernon Wu" <ve...@gatewaytech.com> wrote:
>
>> Hi, all,
>> 
>> I run into an error message on Tomcat 4.0.4b2 when I use a custom tag in a JSP
>> file. The error message is:
>> 
>> /jsp/fullsearchlist/content.jsp(4,0) Unable to find setter method for
>> attribute:   numItems
>> 
>> The code fragment is  the followings:
>> 
>> public abstract class ListTag extends TagSupport {
>> // ...
>> protected int numItems = -1;
>> //...
>> 
>> // setters
>> public void setNumItems(String numItemsStr) {
>>   numItems = Integer.parseInt(numItemsStr);
>> }
>> }
>> 
>> public abstract class SearchListTag extends ListTag {
>> //...
>> // setters (overloaded to fix bug in tomcat)
>> public void setNumItems(String numItemsStr) {
>>   super.setNumItems(numItemsStr);
>> }
>> }
>> 
>> public class FullSearchListTag extends SearchListTag {
>> //...
>> public void setNumItems(String numItemsStr) {
>>   super.setNumItems(numItemsStr);
>> }
>> }
>> 
>> I have tried to remove the setNumItems method from SearchList and/or
>> FullSearchList, but can't resolute the problem.
>> I
>> learn that there was a bug led to this problem in the early version of Tomcat.
>> Is   the bug unresolved yet? How I can
>> overcome this problem?
>> 
>> Thanks very much in advance.
>> 
>> Vernon
>> 
>> 
>> 
>> --
>> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
>> For additional commands, e-mail: <ma...@jakarta.apache.org>
>> 
>
>
>--
>To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Unable to find setter: a problem with custom tag in TC 4.0.4b2

Posted by Phillip Morelock <su...@phillipmorelock.com>.
I don't know if this is the desired answer, and don't have time to think
about the Java language issues here, but a quick fix would be to change:
 
protected int numItems = -1;

to

private int numItems = -1;

Then remove the overrides from Search and FullSearch classes.  Then ensure
that all access to the numItems variable occurs through getNumItems() and
setNumItems() in the base class, ListTag.

I have a feeling this has something to do with the fact that jsp:setProperty
can take two courses:
1.  Set a public variable directly if it has the same name
2.  Prepend "set" and adjust capitalization, as you seem to have
anticipated.

I would think, though, that option #1 would be excluded in this case because
the java compiler would refuse to compile your jsp if it thought you were
exactly trying to address a non-permitted variable (which the protected
variable shouldn't be permitted).

Can you send the stack trace of the exception?  Also, do you know that the
translated version of your page (the .java file it gets converted into) is
in the /work directory?  Check that out (_if_ tomcat got past the
translation phase, this is why you need to provide the stack trace) and you
can usually pinpoint your problem.

fillup

P.S.  Subclasses inherit all the public methods of all superclasses, so I
don't really understand your overrides.

On 5/29/02 8:04 PM, "Vernon Wu" <ve...@gatewaytech.com> wrote:

> Hi, all,
> 
> I run into an error message on Tomcat 4.0.4b2 when I use a custom tag in a JSP
> file. The error message is:
> 
> /jsp/fullsearchlist/content.jsp(4,0) Unable to find setter method for
> attribute:   numItems
> 
> The code fragment is  the followings:
> 
> public abstract class ListTag extends TagSupport {
> // ...
> protected int numItems = -1;
> //...
> 
> // setters
> public void setNumItems(String numItemsStr) {
>   numItems = Integer.parseInt(numItemsStr);
> }
> }
> 
> public abstract class SearchListTag extends ListTag {
> //...
> // setters (overloaded to fix bug in tomcat)
> public void setNumItems(String numItemsStr) {
>   super.setNumItems(numItemsStr);
> }
> }
> 
> public class FullSearchListTag extends SearchListTag {
> //...
> public void setNumItems(String numItemsStr) {
>   super.setNumItems(numItemsStr);
> }
> }
> 
> I have tried to remove the setNumItems method from SearchList and/or
> FullSearchList, but can't resolute the problem.
> I
> learn that there was a bug led to this problem in the early version of Tomcat.
> Is   the bug unresolved yet? How I can
> overcome this problem?
> 
> Thanks very much in advance.
> 
> Vernon
> 
> 
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
> 


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>