Pierre, Thanks for looking into it. To be honest, I'm surprised it took this long to surface ;-). As for whether Result should actually extend Serializable, I'm usually of the mind that an interface shouldn't extend Serializable and that it's an "implementation detail". Consider the core collection interfaces and classes: neither Map nor SortedMap extend Serializable and AbstractMap doesn't implement it. TreeMap, however, does implement it. Another example would be the ResultSet and RowSet interfaces, neither of which extend Serializable.
Quoting Pierre Delisle <[EMAIL PROTECTED]>: > Ideally, javax.servlet.jsp.jstl.sql.Result should be spec'ed as > implementing the Serializable interface, so serialization is not left > up to the implementor of the spec but is consistently applied across > all implementations of the spec. We'll make sure this is fixed in > the next rev of the spec. > > In the meantime, is it a spec violation to have an implementation of > the Result interface (in our case ResultImpl) implement the > Serializable interface? Maybe it is not, as Kris argues. However, the > danger here is that if one vendor does support Serializable and the > other does not, then a webapp would not be portable. And the specs > are very strict on compatibility/portability issues... > > I'll consult with a few spec gurus and report back... > > Thanks, > > -- Pierre > > Kris Schneider wrote: > > A couple of other points to consider. According to the Serialization > Spec, > > adding Serializable to a class is a compatible change. In addition, a > > serializable class must have access to the no-arg constructor of its > first > > nonserializable superclass. Since ResultImpl extends Object, it meets > that > > requirement as well. > > > > Quoting Kris Schneider <[EMAIL PROTECTED]>: > > > > > >>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/> -- 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]
