Re: [mdr-users] custom implementation recycling?

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

-- 
Ark Linux - Linux for the Masses (http://arklinux.org)

If we cannot live so as to be happy, let us at least live so as to deserve it
 -- Immanuel Hermann Fichte

Capitalism: 
You don't have any cows. The bank will not lend you money to buy cows, 
because you don't have any cows to put up as collateral.

Representative Democracy:
You have two cows. Your neighbors pick someone to tell you who gets the milk. 

In a world without walls and fences, who needs windows and gates?

I'm a fool. Therefore I'm not.

Hans Schippers
Aspirant FWO - Vlaanderen
Formal Techniques in Software Engineering (FoTS)
University of Antwerp
Middelheimlaan 1
2020 Antwerpen - Belgium
Phone: +32 3 265 38 71
Fax: +32 3 265 37 77

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQBCrxINXlnUYIbmLOQRAq54AKCd22vaDo9FCKpTWut7nLyF6Kr4YwCeJ1H8
ZWY66d6yNpztBCJgzZulmKk=
=piIt
-----END PGP SIGNATURE-----