Here's a comment from ResultImpl.java: It is not part of the JSTL API; it serves merely as a back-end to ResultSupport's static methods.
Also, the 1.0 spec only references Result and ResultSupport. I don't see how it's a spec issue if ResultImpl is changed to implement Serializable. It *would* be a spec issue for Result to extend Serializable, but that doesn't seem necessary. Is it just because the class is packaged in javax.servlet.jsp.jstl.sql as opposed to org.apache.taglibs.standard? Quoting Felipe Leme <[EMAIL PROTECTED]>: > Kris, > > There was already a bug opened for this issue (can't find which one > while bugzilla is down) and it was marked as RESOLVE LATER because the > problem is in the JSTL specification, not at Jakarta's implementation > itself. As JSTL 1.1 specification has reached its final status, this bug > can't be fixed now, only on the next specification. > > Felipe > > > Kris Schneider wrote: > > >While it could be argued it's not a bug, it certainly would be a nice > >enhancement to have ResultImpl implement Serializable. There are, however, > a > >couple of things you can do in the meantime. Depending on your needs, you > could > >just store the SortedMap[] returned by getRows in the session. Or you > could > >create your own Result implementation that is serializable - the code in > >ResultImpl isn't really all that complex. Unfortunately, Bugzilla appears to > be > >unreachable or I'd see about submitting an enhancement request... -- Kris Schneider <mailto:[EMAIL PROTECTED]> D.O.Tech <http://www.dotech.com/> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
