H Ken,
Seems reasonable to me from a Mojarra perspective, since the Mojarra ResourceImpl class implements Externalizable. But the MyFaces ResourceImpl class does not. Probably need to hear from the MyFaces team to see what they think.
Neil
On Nov 13, 2012, at 1:39 PM, Ken Finnigan <kfinniga_at_redhat.com> wrote:
> Apologies, my example implementation of readExternal() for a class extending ResourceWrapper was a little off, it should be:
>
> public void readExternal(ObjectInput in) throws IOException, ClassNotFoundException {
> wrapped = (Resource) (Class.forName((String)in.readObject())).newInstance();
> wrapped.readExternal(in);
> }
>
> Ken
>
> From: "Ken Finnigan" <kfinniga_at_redhat.com>
> To: jsr344-experts_at_javaserverfaces-spec-public.java.net
> Sent: Tuesday, November 13, 2012 10:39:35 AM
> Subject: [jsr344-experts] Re: [1144-ResourceWrapperExternalizable] PROPOSAL
>
> After looking at the implementation implications for what I've proposed, I think some changes to the proposed solution are in order.
>
> As getWrapped() returns a Resource, we need to make Resource implement Externalizable instead of ResourceWrapper.
>
> This change would result in the following methods on Resource being added:
>
> public void writeExternal(ObjectOutput out) throws IOException {
> out.writeObject(resourceName);
> out.writeObject(libraryName);
> out.writeObject(contentType);
> }
> public void readExternal(ObjectInput in) throws IOException, ClassNotFoundException {
> resourceName = (String) in.readObject();
> libraryName = (String) in.readObject();
> contentType = (String) in.readObject();
> }
>
> Which would change the implementation of ResourceImpl by removing Externalizable from implements and modifying those methods to be:
>
> public void writeExternal(ObjectOutput out) throws IOException {
> super.writeExternal(out);
> out.writeLong(initialTime);
> out.writeLong(maxAge);
> }
>
> public void readExternal(ObjectInput in)
> throws IOException, ClassNotFoundException {
> super.readExternal(in);
> initialTime = in.readLong();
> maxAge = in.readLong();
> }
>
> Then ResourceWrapper would declare readExternal() and writeExternal() as abstract, like getWrapped().
>
> Then a possible implementation of ResourceWrapper would override them with the following, assuming the class called the instance it was wrapping "wrapped":
>
> public void writeExternal(ObjectOutput out) throws IOException {
> out.writeObject(wrapped.getClass().getName());
> wrapped.writeExternal(out);
> }
>
> public void readExternal(ObjectInput in) throws IOException, ClassNotFoundException {
> wrapped = Class.forName((String)in.readObject());
> wrapped.readExternal(in);
> }
>
> Regards
> Ken Finnigan
>
> From: "Ken Finnigan" <kfinniga_at_redhat.com>
> To: jsr344-experts_at_javaserverfaces-spec-public.java.net
> Sent: Tuesday, November 13, 2012 10:04:12 AM
> Subject: [jsr344-experts] [1144-ResourceWrapperExternalizable] PROPOSAL
>
> Hello Volunteers,
>
> Suggest modifying ResourceWrapper to implement Externalizable and alter the class javadoc to be something like:
>
> Provides a simple implementation of Resource that can be subclassed by developers wishing to provide specialized behavior to an existing Resource instance. The default implementation of all Resource methods is to call through to the wrapped Resource.
>
> Usage: extend this class, override getWrapped() to return the instance we are wrapping and implement Externalizable methods by calling their super equivalents.
>
> Method javadoc for writeExternal():
>
> Write the wrapped Resource to ObjectOutput such that it can be read by readExternal().
>
> Method javadoc for readExternal():
>
> Read the ObjectInput to recreate the wrapped Resource.
>
>
> Regards
> Ken Finnigan
>
>
>