Glad to hear you made the right choice! ;-)After evaluating JiBX, Castor, JAXB, and several other tools it looks like we'll be using JiBX on an upcoming project. Thanks to Dennis and everyone that has helped us through our evaluation of JiBX!
I'm kind of hoping others will start adding content there. Like these below...One thing that I've learned over the years is that there is usually a right way to use a tool and many wrong ways. I'm guessing JiBX is no different. With that in mind are there any pitfalls we should watch out for and are there any best-practices we should adopt? Look like Dennis has added a "tips-and-tricks for general usage and suggestions" topic to the Wiki but hasn't added any content.
Some questions that come to my mind are:If you're only doing single-threaded operation you can just create a single MarshallingContext and a single UnmarshallingContext, then reuse them for each document. If you're multithreaded you'll need to make sure you don't have more than one thread using each of these at a time; you can either use a lock (by synchronizing on the context itself, for instance) to ensure this, or create separate contexts for each thread as needed. You can also pool these, if you really want to avoid any unnecessary overhead. If you're going to be creating multiple contexts it's worth keeping the BindingFactory around.
1) Should we maintain a reference for the BindingFactory and/or Marshaling/UnmarshalingContexts or create new one's for each document?
I haven't timed the context creation, but would expect that the overhead of creating one is on a par with that of marshalling or unmarshalling a fairly short document. That means that if you're working with large documents you probably won't notice the overhead of creating these, but if you're working with lots of small documents you'll definitely want to reuse them for best performance.
You're really best off with <structure> wherever possible, even inside <collection>. The <mapping> is really only intended for use with classes that either can be the root of a document, or are referred to anonymously (as type java.lang.Object, with the runtime type not known in advance). The only time you really want to rely on everything in a <collection> being mapped is when you don't know in advance what types are going to be present in the <collection>. A <mapping> also has some associated overhead, though this should normally be pretty small.2) When does a Mapping make better sense that a Structure? I've seen several instances where either could be used and have generally gone with a Structure except with collections.
Right now there's no good way to share components of binding definitions (the label/using approach is fairly ugly, and probably still broken in some edge cases), so I think people end up using <mapping> more than they should. For beta 4 I'll be adding a <template> element to the binding definition to allow for reusable structures without the overhead of a <mapping> or the
- Dennis
------------------------------------------------------- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click _______________________________________________ jibx-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jibx-users
