[jbosscache-dev] Method storeEntireState is ambiguous with null parameter

[Vladimir Blagojevic]

But it will be almost impossible for this hypothetical cacheloader
implementor to decode the state using ByteBuffer and follow
interoperability requirement. Since we have to keep interoperability
between all cacheloaders the exact sequence of stream (un)wrapping has
to be used. For example if byte based FileCacheLoader writes a state ,
as it does now like this:


	  ByteArrayOutputStream out_stream=new
ByteArrayOutputStream(1024);
         ObjectOutputStream    out=new
MarshalledValueOutputStream(out_stream);
         loadStateFromFilessystem(subtree, out);
         out.close();
         
         return out_stream.toByteArray();

then the cacheloader reader of this state has to reverse these exact
streams unless they really reallly know what they are doing. 

If we have 4 stream based methods then we (StateTransferIntegrator and
StateTransferGenerator) control which streams we pass to cacheloader
implementors. They have to read/write NodeData objects (as per contract)
to the stream anyway and there is never a problem of stream corruption.
Cacheloader implementors only worry about reading/writing NodeData
objects.

> -----Original Message-----
> From: Bela Ban 
> Sent: Tuesday, August 29, 2006 8:53 AM
> To: Vladimir Blagojevic
> Cc: Manik Surtani; jbosscache-dev at lists.jboss.org
> Subject: Re: [jbosscache-dev] Method storeEntireState is 
> ambiguous with null parameter
> 
> +1 from me, although some folks might like the simplicity of byte[]. 
> Although, to unmarshal, most folks will create an input 
> stream off of the byte array anyway.
> 
> Oops, NO, this doesn't work ! What about people who'd like to 
> use java.nio.ByteBuffer ? There is *no* stream notion in NIO !!!
> 
> E.g.
> 
> byte[] state;
> ByteBuffer buf=ByteBuffer.wrap(state);
> buf.getInt();
> bug.getLong();
> etc etc
> 
> Okay, I change my vote to -1...
> 
> Vladimir Blagojevic wrote:
> > We really should.
> >
> > In the light of our recent conversations it really does not 
> make sense 
> > to keep byte based methods. Cacheloader implementors can 
> easily make a 
> > mistake and disrupt interoperability with other cacheloader 
> > implementations. Another argument for having only 4 stream based 
> > methods is that cacheloader implementors do not have to implement 
> > separate methods for streaming and byte based transfer.
> >
> > Brian and I talked about this extensively.
> >
> > Let have another vote on this. 
> >
> >
> >   
> >> -----Original Message-----
> >> From: Manik Surtani [mailto:manik at jboss.org]
> >> Sent: Tuesday, August 29, 2006 8:01 AM
> >> To: Vladimir Blagojevic
> >> Cc: jbosscache-dev at lists.jboss.org
> >> Subject: Re: [jbosscache-dev] Method storeEntireState is ambiguous 
> >> with null parameter
> >>
> >> Are we not going to pull the byte[] methods from the interface, as 
> >> per your conversation with Brian?
> >> --
> >> Manik Surtani
> >>
> >> Lead, JBoss Cache
> >> JBoss, a division of Red Hat
> >>
> >> Email: manik at jboss.org
> >> Telephone: +44 7786 702 706
> >> MSN: manik at surtani.org
> >> Yahoo/AIM/Skype: maniksurtani
> >>
> >>
> >> On 25 Aug 2006, at 17:25, Vladimir Blagojevic wrote:
> >>
> >>     
> >>> Hi,
> >>>
> >>> As you might be aware Cacheloader 2.0 will add 4 methods
> >>>       
> >> for streaming
> >>     
> >>> state transfer:
> >>>
> >>> void storeEntireState(InputStream s); void storeState(Fqn 
> >>> subtree,InputStream s); void loadEntireState(OutputStream 
> s); void 
> >>> loadState(Fqn subtree,OutputStream s);
> >>>
> >>> There is a slight problem will method overloading, namely
> >>>       
> >> we have now
> >>     
> >>> two methods:
> >>>
> >>> void storeEntireState(byte[] state) throws Exception; void 
> >>> storeEntireState(InputStream is) throws Exception;
> >>>
> >>> which are properly overloaded. However, java compiler will
> >>>       
> >> complain if
> >>     
> >>> somebody invokes
> >>>
> >>> cacheloader.storeEntireState(null);
> >>>
> >>> Workaround is to declare actual parameter explicitly , i.e:
> >>>
> >>>
> >>> byte [] nullstate = null;
> >>> cacheloader.storeEntireState(nullstate);
> >>>
> >>> so that compiler can distinguish which overloaded method 
> to invoke.
> >>> This is the case with our own BdbjeTest that was invoking 
> >>> cl.storeEntireState(null);
> >>>
> >>> Does anyone have any complaints or concerns? If not, I
> >>>       
> >> would proceed
> >>     
> >>> with adding stream based methods to CacheLoader and adding noop 
> >>> implementation methods to all implementers of CacheLoader 
> interface.
> >>>
> >>> _______________________________________________
> >>> jbosscache-dev mailing list
> >>> jbosscache-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
> >>>       
> >>     
> >
> > _______________________________________________
> > jbosscache-dev mailing list
> > jbosscache-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/jbosscache-dev
> >
> >   
> 
> --
> Bela Ban
> Lead JGroups / Manager JBoss Clustering Group JBoss - a 
> division of Red Hat
> 
>