Jason Wilson wrote:
> I have some jsp pages that now break in Tomcat 5.0.16.
> In particular, my use of the jsp:useBean tag is no
> longer working, it fails to compile.
>
> ## <jsp:useBean id="myListBean" scope="session"
> class="java.util.List"/>
>
> In the generated servlet, it attempts to do a
>
> ## java.util.List myListBean = new java.util.List();
>
> which does not work, since it is not a concrete class.
>
> In the version of Tomcat I was working with (4.1.*),
> it didn't use a hard coded constructor, for example:
>
> ## myListBean = (java.util.List)
> java.beans.Beans.instantiate(this.getClass().getClassLoader(),
> "java.util.List");
>
> Using reflection to call the constructordid not create
> a compile time error. This was good, in any case,
> because my JSP is never supposed to instantiate these
> beans, they are created by a servlet that forwards the
> request to them.
>
> Does anyone know why this new JSP servlet generator
> uses this type of constructor? It seems like it would
> break A LOT of code out there, where a JPS page uses
> the useBean to get a bean that is supposed to already
> be existing in the specified scope. Or are we
> supposed to only put concrete objects in our class
> types, and only those that have a no-arg constructor?
>
> Is there something new in the jsp 2.0 spec that allows
> me to define a bean that will never be instantiated in
> the page itself?
>
> My workaround is to remove all the jsp:useBean tags
> and just use scriptlets to get at the objects.
>
> ## <% java.util.List myList = (java.util.List)
> session.getAttribute("myList"); %>
>
> Once again, is there anyway that I can use jsp:useBean
> with classes like java.util.List or even classes that
> I have written that do not provide a no-arg
> constructor?

I did run into this issue, and the classes of the objects specified in
useBean *must* be JavaBeans (I did check the specification). So this
means, indeed, a concrete class with a no arg constructor.

> ## myListBean = (java.util.List)
> java.beans.Beans.instantiate(this.getClass().getClassLoader(),
> "java.util.List");
would create an error at runtime. I think the compile time error is more
honest and prevents sloppy coding, so I did go in and changed some JSP
code from JBoss management pages. Yes, I know, the code is never
supposed to be run blabla, but still, bugs do happen ;-)

--
xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
R�my Maucherat
Senior Developer & Consultant
JBoss Group (Europe) S�RL
xxxxxxxxxxxxxxxxxxxxxxxxxxxxx


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@(protected)
For additional commands, e-mail: tomcat-user-help@(protected)