Yes, yet another thread about flexibility with collections. To start, I have read the other threads and seen the currently accepted work-arounds. But I'll give a little background first. I'm working with extremely large schemas (two of them) and generating java interfaces via SDO. There is then custom code that builds the impl classes for the interfaces and generates the binding file at the same time. After this, the <bind> ant task is used to compile the bindings during our build process.
So now, I'm tasked with adding flexibility to the schema handling and run into the (perhaps infamous) flexible collections hangup. I do need to provide marshalling and unmarshalling, so in order to use the allow-repeats="true" trick, I have to separate the binding file into direction="input" and direction="output" files, or so my current understanding leads me to believe. Problem #1, this library is used by a lot of applications, most of which also use a separate library to handle the boilerplate marshalling and unmarshalling code, but not all. Therein lies the problem. I can't see any way around having to give the name for the binding files when getting the MarshallingContext even though there's is only one for an input and one for an output. I feel like jibx should know this already, but I understand why it doesn't. So, short of just biting the bullet and breaking the library for those that do not use the boilerplate library that I can actually update, I'm at a loss for how to handle this. Is there a way to specify a default binding implementation when the single-argument version of createMarshallingContext( class ) is called? If that were possible, I could just define a rigid (non-flexible) as the default and those consumers simply wouldn't get the added flexibility. Problem #2, the schemas change, a lot. Sometimes upwards of 2-3 times per month. This is why we wrote code-gen for the classes and binding files themselves originally. There would have to be from 30-40 custom unmarshallers/marshallers to handle each structure that contains collections that we need to make flexible as of today. You can see how this option has the potential to be rather unwieldy for maintenance and thus isn't the preferred choice. Are there any options I'm overlooking for accomplishing this? We're currently using 1.1.5, but are probably going to update to 1.2.2 if it helps us along in this regard. ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ jibx-users mailing list jibx-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jibx-users
