[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: why cloning messageUnit ?
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;
> > arr = 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
> 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
> Marcel Ruff
> mailto:ruff at swand.lake.de