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