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

Manik Surtani manik at jboss.org
Tue Aug 29 11:54:58 EDT 2006


Exactly.  Reading/writing with byte[]'s or NIO ByteBuffers will be  
meaningless given the mandated format of the bytes in question.
--
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 29 Aug 2006, at 14:28, Vladimir Blagojevic wrote:

> 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
>>
>>




More information about the jbosscache-dev mailing list