[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [xmlblaster-devel] LOCAL not working?
On Thu, 2003-09-18 at 10:29, Marcel Ruff wrote:
> Peter Antman wrote:
> > Meetings all day yesterday, but now I have something that works; but as
> > far as I understand it not designed exactly the way your stuff seems to
> > be heading.
> >
> > Here's the deal:
> >
> > You must use a Global which contains the serverside engine global in its
> > ObjectEntry "ServerNodeScope". The cloning process for each
> > XmlBlasterAccess instance must therefore include ServerNodeScope.
> >
> > The LocalConnections is simple: look up the engine.Global, get the stuff
> > you need from it and just delegate.
> >
> > LocalCallbackImpl must also have access to the engine.Global. There it
> > simply adds itself as an ObjectEntry with its raw adress as key. It
> > implements a new interface ServerNodeScope wich the serverside callback
> > expect to find in the ObjectEntry.
>
> The coolest way would be if we could get a pointer of the
> callback instance which we pass as a string and
> the ask the classloader to resolve the object instance
> again from this pointer (like in C).
>
> This is the stringified object on CORBA:
> <callback type='IOR'>
> IOR:10000010033200000099000010....
> </callback>
>
> A LOCAL 'pointer':
> <callback type='LOCAL'>
> 0x68F44A
> </callback>
>
>
> lc = (I_LocalCallback)Classloader.getObject("0x68F44A");
>
> This way we don't need to pass it via Global.
>
> But i think this is not possible in Java.
:-)
In JBoss they use a registry for that purpose:
public class Registry
{
public static Map entries = Collections.synchronizedMap(new
HashMap());
public static void bind(final Object key, final Object value) {
entries.put(key, value);
}
public static Object unbind(final Object key) {
return entries.remove(key);
}
public static Object lookup(final Object key) {
return entries.get(key);
}
}
I generally think that XmlBlaster have a problem with lookups and
naming: that has been strapped into the Global, but also makes these
stuffs tightly coupled to each others.
Even more generally: I would love to see a new/other container
architecture for XmlBlaster, based on the IoC(3) pattern, and/or JMX
(http://www.picocontainer.org/)
I was planning to test such a revision, but sort of stumbled on all the
different behaviours of the plugins (some are plugins, some are
factories, and some are dynamicly configured factories....)
>
> So putting the object into a hashtable in Global
> (made unique with hashCode()) and retrieve it
> again as you do is probably the best way.
>
> <callback type='LOCAL'>
> LOCAL:0x3456556
> </callback>
>
> >
> > Here are some snippets from LocalCallbackImpl:
> >
> > public synchronized final void initialize(Global glob, String
> > loginName,
> > CallbackAddress callbackAddress,
> > I_CallbackExtended cbClient) throws XmlBlasterException {
> > this.glob = (glob == null) ? Global.instance() : glob;
> > this.log = this.glob.getLog("local");
> > this.ME = "LocalCallbackImpl-" + loginName;
> > this.callbackId = "LOCAL:"+this.hashCode();
> > this.cbClient = cbClient;
> >
> > // Set this object an the engine.Global so that the server cb
> > handler
> > // can find it.
> > engineGlob =
> > (org.xmlBlaster.engine.Global)glob.getObjectEntry("ServerNodeScope");
> > if (engineGlob == null)
> > throw new XmlBlasterException(this.glob,
> > ErrorCode.INTERNAL_UNKNOWN, ME + ".init", "could not retreive the
> > ServerNodeScope. Am I really on the server side ?");
> >
> > // Ad the driver to the "naming" store.
> > engineGlob.addObjectEntry(callbackId,this);
> >
> > }
> >
> > public String getCbAddress() throws XmlBlasterException {
> > return callbackId;
> > }
> >
> > public String[] update(String cbSessionId, MsgUnitRaw[] msgUnitArr)
> > throws XmlBlasterException
> > {
> > if (msgUnitArr == null) throw new XmlBlasterException(ME,
> > "Received update of null message");
> > if (log.CALL) log.call(ME, "Entering update(" + cbSessionId + ")
> > of " + msgUnitArr.length + " messages");
> >
> > return cbClient.update(cbSessionId, msgUnitArr);
> > }
> >
> > The serverside part is CallbackLocalDriver. Its job is to lookup the
> > client part in the ObjectEntry and just delegate to it.
> >
> > public final void init(Global glob, CallbackAddress callbackAddress)
> > throws XmlBlasterException {
> > this.glob = glob;
> > this.log = glob.getLog("local");
> > this.callbackAddress = callbackAddress;
> > String callbackId = callbackAddress.getRawAddress();
> > try {
> > localCallback = ( I_LocalCallback
> > )glob.getObjectEntry(callbackId);
> >
> > if ( localCallback == null) {
> > throw new XmlBlasterException(this.glob,
> > ErrorCode.INTERNAL_UNKNOWN, ME + ".init", "could not retreive the
> > LocalCallbackImpl, was there really one started");
> > } // end of if ()
> >
> > }
> > catch (Throwable e) {
> > log.error(ME, "The given callback id ='" + callbackId + "' is
> > invalid: " + e.toString());
> > throw new XmlBlasterException(glob,
> > ErrorCode.RESOURCE_CONFIGURATION_ADDRESS, "Local-CallbackHandleInvalid",
> > "The given callback Id is invalid: " + e.toString());
> > }
> > }
> >
> > public final String[] sendUpdate(MsgUnitRaw[] msgArr) throws
> > XmlBlasterException
> > {
> > if (msgArr == null || msgArr.length < 1)
> > throw new XmlBlasterException(glob,
> > ErrorCode.INTERNAL_ILLEGALARGUMENT, ME, "Illegal sendUpdate()
> > argument");
> > if (log.TRACE) log.trace(ME, "xmlBlaster.update() to " +
> > callbackAddress.getSecretSessionId());
> >
> > try {
> > return
> > localCallback.update(callbackAddress.getSecretSessionId(), msgArr);
> > } catch (XmlBlasterException xmlBlasterException) {
> >
> > // WE ONLY ACCEPT ErrorCode.USER... FROM CLIENTS !
> > if (xmlBlasterException.isUser())
> > throw xmlBlasterException;
> >
> > throw new XmlBlasterException(glob,
> > ErrorCode.USER_UPDATE_ERROR, ME,
> > "Local Callback of " + msgArr.length +
> > " messages to client [" +
> > callbackAddress.getSecretSessionId() + "] failed.",
> > xmlBlasterException);
> > }
> > }
> >
> > What do you say about this?
>
> Yes this was my intention as well.
>
> Marcel
So it's ok to commit?
//Peter
> >
> > //Peter
> >
> > On Mon, 2003-09-15 at 23:58, Marcel Ruff wrote:
> >
> >>Michele Laghi wrote:
> >>
> >>>Hi Peter,
> >>>you'r right. The implementation of the native access has not been
> >>>completed yet.
> >>
> >>I have started on it but hadn't time to finish it.
> >>There are probably one/two days open
> >>for finishing implementation, adding testsuite and docu and a little demo client.
> >>If you do it its fine, otherwise one day i will complete it.
> >>The native access is to be seen in conjunction with the
> >>runlevel manager to load the native client, see
> >>http://www.xmlBlaster.org/xmlBlaster/doc/requirements/engine.runlevel.howto.html
> >>
> >>regards
> >>
> >>Marcel
> >>
> >>PS: The Euro wasn't introduced in Sweden, so my
> >>Kroner lying around somewhere won't be valueless :-)
;-)
> >>
> >>>Michele
> >>>
> >>>
> >>>Peter Antman wrote:
> >>>
> >>>
> >>>>Hi,
> >>>>am I right if I have found that client.protocol.local is not working, or
> >>>>should it be able to get it to work (yes, I do have access to
> >>>>engine.Global), but I am getting exceptions on the server callback part
> >>>>(and looking into the code I get the impression that something is
> >>>>missing).
> >>>>
> >>>>//Peter
> >>>
> >>>
> >>>
> >>
> >>--
> >>http://www.xmlBlaster.org
>
>
> --
> http://www.xmlBlaster.org
--
------------------------------------------------------------
Peter Antman Chief Technology Officer, Development
Technology in Media, Box 34105 100 26 Stockholm
WWW: http://www.tim.se WWW: http://www.backsource.org
Email: pra at tim.se
Phone: +46-(0)8-506 381 11 Mobile: +46-(0)704 20 58 11
------------------------------------------------------------