You are viewing a plain text version of this content. The canonical link for it is here.
Posted to taglibs-user@tomcat.apache.org by Antony Paul <an...@hotmail.com> on 2003/12/16 06:26:20 UTC
Serialising javax.servlet.jsp.jstl.sql.ResultImpl
Hi,
I am using Result to pass data from servlet to JSP. I use this to
display the result of a search 20 rows per page. ie. I have to keep it in
session. Since it is not serializable it is throwing
java.io.NotSerializableException when context is reloaded. Earlier I was
using beanutils RowSetDynaClass instead of Result. Is there any way to
serialize it. I think Result is a map of Strings only.
Antony Paul.
---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-user-help@jakarta.apache.org
Re: Serialising javax.servlet.jsp.jstl.sql.ResultImpl
Posted by Felipe Leme <ja...@felipeal.net>.
Kris,
Let's wait until bugzilla is back - I don't remember the details of that
bug; maybe we could re-open it anyway (if it's not really a problem with
the specification).
Felipe
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.
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-user-help@jakarta.apache.org
Re: Serialising javax.servlet.jsp.jstl.sql.ResultImpl
Posted by Pierre Delisle <Pi...@Sun.COM>.
I checked with the gurus, and the conclusion is as expected:
while having ResultImpl implement interface Serializable exposes a
portability issue, it shouldn't be a spec violation.
I therefore suggest we fix ResultImpl to implement interface Serializable,
and insert a comment in the Release Notes stating that relying on the
serializability of Result objects might not be portable across
different implementations of the JSTL spec.
Please let me know if there is any other related issue.
-- Pierre
[Shawn, thanks for dropping the law books a few minutes to
come help us out :-)]
Shawn Bayern wrote:
> On Tue, 16 Dec 2003, Kris Schneider wrote:
>
>
>>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.
>
>
> The important distinction here isn't between "interface" and
> "implementation" but between "specification" and "implementation."
> Regardless whether an interface should typically be extended by an
> interface or implemented by a class (which I'll address in a moment),
> Pierre's concern here is that the enhancement request shouldn't be
> addressed by an implementation of the JSTL specification on its own.
>
> While I don't think it would strictly violate the JSTL specification for a
> JSTL implementation to have one of its classes (which implements a
> specified interface) implement another arbitrary interface, it would
> certainly be poor practice for users to rely on this nonstandard behavior
> (and thus probably irresponsible for an implementation to promote it).
>
> As for the specific point about whether interfaces should extend or
> implementations should implement, I don't think the analogies you raise
> are apposite: Map indeed doesn't extend Serializable, but this is only
> because there's no call for all implementations of Map to be Serializable.
> The JSTL specification could conceivable require that all implementations
> of a standard interface also implement Serializable, but the most elegant
> way for it to accomplish this is to have the standard interface extend
> Serializable itself. Indeed, this approach is very common: note the
> number of subinterfaces to Serializable (i.e., the number of interfaces
> that extend Serializable) in the J2SDK 1.4 API.
>
> Shawn
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: taglibs-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: taglibs-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-user-help@jakarta.apache.org
Re: Serialising javax.servlet.jsp.jstl.sql.ResultImpl
Posted by Shawn Bayern <ba...@essentially.net>.
On Tue, 16 Dec 2003, Kris Schneider wrote:
> 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.
The important distinction here isn't between "interface" and
"implementation" but between "specification" and "implementation."
Regardless whether an interface should typically be extended by an
interface or implemented by a class (which I'll address in a moment),
Pierre's concern here is that the enhancement request shouldn't be
addressed by an implementation of the JSTL specification on its own.
While I don't think it would strictly violate the JSTL specification for a
JSTL implementation to have one of its classes (which implements a
specified interface) implement another arbitrary interface, it would
certainly be poor practice for users to rely on this nonstandard behavior
(and thus probably irresponsible for an implementation to promote it).
As for the specific point about whether interfaces should extend or
implementations should implement, I don't think the analogies you raise
are apposite: Map indeed doesn't extend Serializable, but this is only
because there's no call for all implementations of Map to be Serializable.
The JSTL specification could conceivable require that all implementations
of a standard interface also implement Serializable, but the most elegant
way for it to accomplish this is to have the standard interface extend
Serializable itself. Indeed, this approach is very common: note the
number of subinterfaces to Serializable (i.e., the number of interfaces
that extend Serializable) in the J2SDK 1.4 API.
Shawn
---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-user-help@jakarta.apache.org
Re: Serialising javax.servlet.jsp.jstl.sql.ResultImpl
Posted by Kris Schneider <kr...@dotech.com>.
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 <Pi...@Sun.COM>:
> 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 <kr...@dotech.com>:
> >
> >
> >>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 <ja...@felipeal.net>:
> >>
> >>
> >>>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 <ma...@dotech.com>
> >>D.O.Tech <http://www.dotech.com/>
--
Kris Schneider <ma...@dotech.com>
D.O.Tech <http://www.dotech.com/>
---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-user-help@jakarta.apache.org
Re: Serialising javax.servlet.jsp.jstl.sql.ResultImpl
Posted by Pierre Delisle <Pi...@Sun.COM>.
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 <kr...@dotech.com>:
>
>
>>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 <ja...@felipeal.net>:
>>
>>
>>>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 <ma...@dotech.com>
>>D.O.Tech <http://www.dotech.com/>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-user-help@jakarta.apache.org
Re: Serialising javax.servlet.jsp.jstl.sql.ResultImpl
Posted by Kris Schneider <kr...@dotech.com>.
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 <kr...@dotech.com>:
> 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 <ja...@felipeal.net>:
>
> > 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 <ma...@dotech.com>
> D.O.Tech <http://www.dotech.com/>
--
Kris Schneider <ma...@dotech.com>
D.O.Tech <http://www.dotech.com/>
---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-user-help@jakarta.apache.org
Re: Serialising javax.servlet.jsp.jstl.sql.ResultImpl
Posted by Kris Schneider <kr...@dotech.com>.
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 <ja...@felipeal.net>:
> 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 <ma...@dotech.com>
D.O.Tech <http://www.dotech.com/>
---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-user-help@jakarta.apache.org
Re: Serialising javax.servlet.jsp.jstl.sql.ResultImpl
Posted by Felipe Leme <ja...@felipeal.net>.
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...
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-user-help@jakarta.apache.org
Re: Serialising javax.servlet.jsp.jstl.sql.ResultImpl
Posted by Kris Schneider <kr...@dotech.com>.
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...
Quoting Antony Paul <an...@hotmail.com>:
> Hi,
> I am using Result to pass data from servlet to JSP. I use this to
> display the result of a search 20 rows per page. ie. I have to keep it in
> session. Since it is not serializable it is throwing
> java.io.NotSerializableException when context is reloaded. Earlier I was
> using beanutils RowSetDynaClass instead of Result. Is there any way to
> serialize it. I think Result is a map of Strings only.
>
> Antony Paul.
--
Kris Schneider <ma...@dotech.com>
D.O.Tech <http://www.dotech.com/>
---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-user-help@jakarta.apache.org