Re: [mdr-users] custom implementation recycling?

That's correct. In addition to these four slots, you can use 
"properties" - a key-value pairs for the same purpose as slots 
(getProperty(), setProperty() methods). The advantage of slots is that 
they are faster (to work with and to de-serialize). These are 
undocumented features we use in some MDR applications. The methods are 
defined in StorableBaseObject.
Martin

SainTiss wrote:

>As far as I can see, it works up to 4... So you could say you get a fixed 
>number of "hidden slots" (i.e. 4), which you can use to store information you 
>don't want to be (trivially) accessible through the JMI interfaces...
>
>At least that's how I understand this...
>
>Kind Regards,
>
>Hans
>
>On Tuesday 14 June 2005 18:54, Steffen Zschaler wrote:
>  
>
>>I've still got a question on this. I don't know much on how the slots
>>work, but what do I do if I have more than one attribute to store? Do I
>>just say getSlot2()? Where do these methods come from?
>>
>>Best regards,
>>
>>Steffen
>>
>>SainTiss wrote:
>>    
>>
>>>Hi,
>>>
>>>Hmm, is this an "undocumented feature"? I can't seem to find any
>>>information on this... Is there any?
>>>
>>>Still, it seems to work, so thanks :)
>>>
>>>Also, since I read you recently became a father, congratulations :)
>>>
>>>Kind Regards,
>>>
>>>Hans
>>>
>>>On Tue, 14 Jun 2005 16:22:05 +0200
>>>
>>>Martin Matula <[email protected]> wrote:
>>>      
>>>
>>>>SainTiss wrote:
>>>>        
>>>>
>>>>>Apparently, it's got more to do with garbage collection being handled
>>>>>differently on different systems, instead of different JDK's as I
>>>>>erroneously thought...
>>>>>
>>>>>Point is, I was trying to add an attribute to the custom implementation,
>>>>>which is not present in the MOF model... So obviously I would need the
>>>>>same custom implementation be associated with the same JMI object all
>>>>>the time, otherwise the value of my additional attribute wouldn't be
>>>>>preserved...
>>>>>
>>>>>Unfortunately, it seems that these custom implementation wrappers can be
>>>>>garbage collected when there is no reference to them or their wrapped
>>>>>JMI object in scope. If I keep a reference to the custom implementation
>>>>>wrapper, then it seems like the JMI object is assigned the same wrapper
>>>>>if it's fetched from MDR later on... But I'm not sure if I can count on
>>>>>that...
>>>>>          
>>>>>
>>>>Yes, you can count on that. This is how it works.
>>>>
>>>>        
>>>>
>>>>>Also, keeping references to these wrappers isn't the most pretty
>>>>>solution...
>>>>>
>>>>>Is there a solution/workaround here?
>>>>>          
>>>>>
>>>>A better solution would be to use getSlotX()/setSlotX() methods in the
>>>>underlying storable object to store the value of the additional
>>>>attribute - this way you can be sure the value is persisted with the
>>>>values of other modeled attributes.
>>>>Your custom impl. code could look like this:
>>>>
>>>>public void setAttribute(String value) {
>>>>   _getDelegate().setSlot1(value);
>>>>}
>>>>
>>>>public String getAttribute() {
>>>>   return (String) _getDelegate().getSlot1();
>>>>}
>>>>
>>>>Regards,
>>>>Martin
>>>>        
>>>>
>
>  
>