--- Remy Maucherat <[EMAIL PROTECTED]> wrote:
> 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
> ;-)

Well, I guess it makes sense the useBean tag requires
it to be a bean.  Perhaps I should be hoping for a
jsp:useObject that uses any object (and expects it to
already exist, and doesn't try to construct it).  As
it stands, I expect to be able to use any object
passed from my servlets, and use them by interface or
polymorphically as I choose.  For this reason, using
the scriptlet seems to be my best option.  The useBean
tries to construct objects, and I never want my JSP
page to be able to construct them.

My general design is to have the servlets handle all
the object construction, navigation, logic, etc, and
the JSP pages get objects from the request or session
and use them to display information in the HTML.  With
this design, I never want the JSP page to instantiate
objects.  Therefore, I probably shouldn't be using the
useBean anyway.  Back to scriptlets I suppose :)

> 
> -- 
> 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]
> 


__________________________________
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to