I have a few questions regarding the SAX object model and the way handlers are invoked.

When I register a model using TXMLObject.register(), does this cause my registered TSAXObjectModel instance to be the one used to service queries? More imporantly, the registered instance has an instance of my ElementHandler - which is not thread safe nor do I want to use it for every collection - can I be sure that this instance is used only for the accessor involved in my query?

Also, my document handler never seems to be used. Anyone know when it get’s involved in a query or update? The Message example just has it forwarding everything to the element handler - I could do the same, I guess, I’d just want to know why.

Lastly, is there any problem with mixing DOM and SAX object models? I’d like to use SAX for fetches and DOM for update and insert.

The Tamino API 4J has some inbuilt object model support, e.g. DOM, JDOM. For SAX based handling you need to define the classes for SAX based handling, create a TSAXObjectModel object and register it. This is only registered for the runtime life of your class(es), i.e. the information is not persisted anywhere.

When you obtain an TXMLObjectAccessor you need to specify which object model to use. So for example if you wish to get individual documents as DOM instances you can ask for it when you obtain a TXMLObjectAccessor, e.g.:

  
TXMLObjectAccessor tacc = tcon.newXMLObjectAccessor (
TAccessLocation.newInstance(COLLECTION),
TDOMObjectModel.getInstance() ) ;
</pre><BR><BR>For SAX based handling you could do the following:<BR><BR><pre class="ip-ubbcode-code-pre">  

TSAXObjectModel mysaxmodel = new TSAXObjectModel (....
TXMLObjectModel.register (mysaxmodel);

TXMLObjectAccessor tacc = tcon.newXMLObjectAccessor (
TAccessLocation.newInstance(COLLECTION), mysaxmodel) ;

By asking for a TXMLObjectAccessor and specifying the registered object model your handlers will be used.

I recommend that you have a look at this sample for a complete example of using SAX based handling with the Tamino API for Java.

Hope this helps.

Thanks for the reply. I saw the sample and while it’s illustrative, it’s a little simplistic (‘message’ is not a very complicated document).

Let me restate my question:

I create the object model as you describe:

model = new TSAXObjectModel( collection() , MyClass.class, MyClass.class, doc, elem);
TXMLObjectModel.register(model);

Where “MyClass” represents the document and element and “doc” and “elem” are my document and element handler, respectively.

My concern centers around the model’s element handler and the ‘register’ method. “register()” implies that this object model is somewhere kept in a global (static) list of object models and that it will be used at some point.

My implementation (as well as the Message example) builds the result set in the element handler. This means that if the registered object model is used in two fetches simultaniously (e.g. from 2 threads) then the result set will be garbage.

What I want to do is create a sax event handler (or at least result set collector) on a per TXMLObjectAccessor basis. I don’t want to register my element handler (with my object model).

Is this any clearer?

To give some perspective on my goal - we’re using an XML<->object mapping framework similar to Castor. For performance reasons, we’d rather not create a DOM element then the object from that, we’d rather just create the object directly as the input stream is being read and interpreted (using sax).

The other part of my question (regarding mixing SAX and DOM object models) has to do with the fact that we can create objects from SAX events, but it’s easier to go from object->DOM. Any thoughts on mixing - sax for read, dom for write?

Thanks.

Maybe the method name register() is probably unfortunate in this instance. When you use the Tamino API for Java one of the objects that instantiated is the TXMLObjectModel. This has a list of object models you can use when you ask for a TXMLObjectAccessor(). When you register your SAX handler it added this to a list. This information is not persisted anywhere so when the JVM ends this information is lost. So when you re-run the program the initial list of object models is reset and you have to register your SAX handler again in order to use it.

If you have a Java program with say two threads and you register your SAX Handler it is not automatically used. You have to explicity ask for a particular object model to use when obtaining a TXMLObjectAccessor. If both threads both ask to use the same handler then you have a problem on your hands: you need to make it thread-safe. So you could have one thread that does:

TXMLObjectAccessor tacc = tcon.newXMLObjectAccessor ( TAccessLocation.newInstance(COLLECTION), mysaxmodel) ;

and another thread that uses the in-build (and thread safe) DOM object mode :

TXMLObjectAccessor tacc = tcon.newXMLObjectAccessor(TAccessLocation.newInstance(COLLECTION), TDOMObjectModel.getInstance());

for example.

With regards to SAX/DOM mixing, I cannot see any issues with mixing the two provided you have the means of creating DOM objects from objects.

Hope this clarifies things.