Using the UnmarshallingContext from your own top-level code you can call ctx.getUnmarshaller(ctx.getNamespace(), ctx.getName()) and check the result returned. If it's nonnull you can use the returned IUnmarshaller instance to unmarshal the element to the appropriate object type; if it's null you can skip past the element (which currently requires counting the nested elements to see when you've reached the end, but I'll add a skipElement() method to handle this directly for 1.0).
- Dennis
Chris Chen wrote:
I actually don't mind jibx taking control over the entire stream. In fact, my vision is to have JiBX become the main underlying parser for ALL incoming XML fragment. All I want is an automated way to turn incoming XML fragment into Java objects.
That does pose a problem though. If Dennis can hopefully answer this question for me. Is it possible for Jibx to parse and bypass unknown xml fragments that was not registered in the binding definition? So for instance:
<a xmlns="fragment:a"> <b xmlns="registered:fragment:b">test data</b> <c xmlns="unregistered:fragment:c">Unknown</c> </a>
Say I registered A and B in the binding definition. But as in the case of Jabber, there could be many different custom messages being sent back and forth that may either be user-implemented custom features or a feature that my library does not support. Will I be able to specify in some way that tells jibx not to throw an exception because of an unrecognized fragment?
I am guessing no considering that jibx is written to parse a known document structure.
My best assumption to get around this is likely, as you said, use the UnmarshallingContext and manually check which ones are recognized and which ones are not.
Guess I'm still a bit too hopeful for this near-zero coding xml-to-object translation process.
Thanks, Chris
On Mar 21, 2005, at 10:23 AM, Dennis Sosnoski wrote:
There are some major issues in passing the input stream around, since the parser is going to buffer data (which means it reads more than it actually consumes).
A better solution for this type of requirement is to just use an org.jibx.runtime.impl.UnmarshallerContext directly. This internally wraps an XPP3 parser, and provides methods which allow you to access things at the parser level (this is what is done for the org.jibx.extras.DomElementMapper and similar document model handler classes). You can use these methods from your control code, then call the unmarshalObject() method when you've gotten to a tag you want to unmarshal. Since you're in control of the process you can stream these objects.
- Dennis
Chris Hill wrote:
Haha, that is pretty funny! Well, my original implementation used yaja and dom4j, but I ended up spending a lot of time using dom4j to convert my jabber objects into useful bits, and boy was it a waste of time and processing. I gutted yaja's dom4j transformer and created a jibx transformer instead which is like trading in a tank for a porsche. :)
Anyway I've had the exact same idea about jibx, just passing jibx a stream to parse the individual xml fragments. My problem was that I was already using yaja, and yaja handled all the connections, streams and auth and I didn't want to write that all from scratch.
The other (not a big) problem with passing jibx an xml socket InputStream is that jibx would need a way to take that stream and fragment it into little parts. From your last mail I wasn't sure exactly what you'd be doing with jibx, but now I have a pretty good idea. Creating a JibxXmlStream object would be something that would have to be added to jibx internally. Jibx uses the XPP3 pull parser, so you'd have to write a pull parser(ideally with xpp3) that would fragment the xml stream before passing it to the jibx parser(which would then parse it).
Additionally, you would have to map packets to unmarshallers. I've already got this set up in my SAX parser and it looks like this:
public void addPacketType(String type,String factoryType, Class theClass) {
if (!validPacketTypes.contains(type)) {
validPacketTypes.put(type.toString(), type);
if(theClass != null){
try{
IBindingFactory bf = BindingDirectory.getFactory(factoryType,theClass);
IUnmarshallingContext uctx = bf.createUnmarshallingContext();
packetUnmarshallers.put(type.toString(), uctx);
}catch(JiBXException e){
System.out.println("Could not create unmarshaller for :"+type);
}
}
}
}
So you'd put that code into the JibxXmlStream object, and here's how the pseudo-code would work:
//create some sort of raw xml stream
XMLStream xs = new XMLStream();
//create our jibx stream handler
JibxXmlStream jxs = new JibxXmlStream( xs );
//register that we'd like jibx to create java objects out of jabber:iq:agents xml
jxs.addPacketType( "jabber:iq:agents" , "jabber:iq:agents" , JabberIqAgents.class);
//give our stream handler an object that would like to be notified of jabber:iq:agents objects
jxs.addListener("jabber:iq:agents",myListener);
You'd need to create a binding definition for all classes that you want to be transformed, and a java class (see the jibx docs). Then use JibxXmlStream.addPacketType() to add the definitions like above. Then all jabber:iq:agents elements would be automagically converted into java objects, and passed to any listener registered with the stream.
Alas, I'm sad to say that I've had this idea for about 6 months now. I've been working on other aspects of the project, and so this is all just a big long ramble with no real code. I hope it helps you tho, and gives you something to think about! Your goal of creating near zero coding is very realistic with jibx. But I guess it depends on how 'near' to zero you expect to get.
Happy jabbering!
Peace C
Chris Chen wrote:
Thanks for the quick reply.
Funny thing is that what I'm trying to do is parse jabber streams! :) My current implementation works with SAX. However, I was contemplating the fact where I can create a new framework that allows near-zero parsing code. So what I would do is simply create a normal Java object, and something like JiBX could parse the xml stream and fill in the object automatically for me.
I was looking at the IUnmarshallingContext, and it accepts an InputStream or Reader. My guess is that you can pass the jabber connection stream to JiBX to parse the individual xml fragments (ie. jabber:iq:agents). If JiBX doesn't close the stream, then I believe it will work out fine.
My main goal is to find a way to support near-zero coding to support any future messages coming out. near-zero coding or just creating simple model objects.
Thanks, Chris
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
jibx-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jibx-users
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ jibx-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jibx-users
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ jibx-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jibx-users
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ jibx-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jibx-users
