Re: why cloning messageUnit ?

[Cyrille Giquello <cyrille at ktaland.com>]

Marcel Ruff a écrit :

> Cyrille Giquello wrote:
> > Hi,
> >
> > a perhaps stupide question, but I really ask me it ...
> >
> > Why there Cloning messageUnit before sending message ?
> >
> > For exemple in :
> >
> > in engine.ClientInfo.java.notifyAboutLogin()
> >
> >            MessageUnitWrapper msgUnitWrapper = messageQueue.pull();
> >             if (msgUnitWrapper == null)
> >                break;
> >             MessageUnit msg = msgUnitWrapper.getMessageUnitClone();
> >             msg.qos = getUpdateQoS((String)null, msgUnitWrapper,
> > iMessage, numMessages);
> >             if (Log.TRACE) Log.trace(ME, "Flushing message #" + iMessage
> > + ": " + msg.qos);
> >             MessageUnit[] arr = new MessageUnit[1];
> >             arr[0] = msg;
> >             // TODO: emails can also be sent to the logged off client!
> >             cbInfo.sendUpdate(this, msgUnitWrapper,arr);
> >
> > If we're pulling the message from the queue, it is no more in the queue,
> > so why cloning it before sending ?
> >
> > I needing to understand some background because I've planning to
> > "trying" to hack xmlBlaster and add a behavior : when PTP persistents
> > messages are sending to client, erasing them from file-system if they
> > were sending to the destination.
>
> Hi Cyrille,
>
> the messageUnit handle is a reference only, everybody who has
> this handle can manipulate the content.
>
> So if a new publish arrives, the new content would override the
> old content in the queue, if it would be the same instance.
>
> Another reason is that the callback plugin can't do any harm if
> manipulating the messageUnit for example in the native plugin.
>
>  From a security aspect, the core classes should never have dangling
> references around in the neighbours garden. Yes, even the most
> trusted neighbour could misuse it.
> In our case, I_XmlBlaster.java is the gateway into the xmlBlaster core,
> no other entry point is existing.
> So we can control security very simple.
> As all the String arguments are immutable, there is no problem.
> Only the publish has a week argument which we should change
> in a future version as well.
> A bad behaving protocol plugin driver could do funny things with this.
>
> There are some other patterns in Java to address the readonly object
> problem.
>
> In C++, there are even more possibilities to enforce readonly, the C++
> "const" is much more usefull than the Java "final".
>
> Probably we should switch forward to C++ again :-).

Thanks a lot for your nice lesson Marcel !

I'm so much switching between langages and projects
that I need some text like that to refresh my brain.

Thanx & Bye
Cyrille



> Marcel
>
> --
> Marcel Ruff
> mailto:ruff at swand.lake.de
> http://www.lake.de/home/lake/swand/
> http://www.xmlBlaster.org