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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
