Hi Leif,
One thing that may not be emphasized enough in the documentation is that
the class you pass to the getFactory() method can be any class that has
a top-level <mapping> definition in the binding you want to use - it
doesn't have to be the actual root object for marshalling or
unmarshalling. So the problem you're describing really only comes up in
cases where there are multiple binding definitions in use. By
definition, each binding is self contained and doesn't know about other
bindings you may be using. This means it's up to the application to
figure out which binding to use for a particular document. I give the
example of controlling JiBX with front-end code to show how this can be
done: http://jibx.sourceforge.net/tutorial/binding-custom.html#frontend
It's admittedly not a perfect solution, though. I'd like to come up with
some sort of metastructure for bindings in 2.0 that both allows one
binding to use portions of another binding at runtime, and provides some
better way for the user to access the appropriate binding information.
Suggestions are welcome!
- Dennis
Leif Stainsby wrote:
Hi,
The BindingDirectory requires that one know the Class name that will be
involved in the marshalling/unmarshalling tasks, i.e.:
static IBindingFactory getFactory(java.lang.Class clas)
static IBindingFactory getFactory(java.lang.String name,
java.lang.Class clas)
This is very natural when marshalling as you already have the Class
instance. However, when unmarshalling from some character stream, it
isn't necessarily the case that the Class is known. It might be nice to
have JiBX provide a lookup mechanism from QName (uri:local-name) to the
mapped Class name, since this information is present in the binding
files. This would allow a more natural usage where you could then
obtain a factory without an argument:
static IBindingFactory getFactory()
and JiBX would determine the desired mapping in the context of that apps
runtime environment (perhaps by scanning the class path for <binding/>
file instances and extracting mappings). Has anyone else encountered
this issue? Can JiBX already do this somehow?
There are two cases where this would be extremely convenient:
1) An app which has many different model Classes mapped via JiBX and
which are spread across many different Java packages.
2) An app which is composed of several sub-components, each of which
has it's own JiBX binding file (after all JiBX is becoming ubiquitous!)
and Classes spread over several packages.
The second scenario is really just the evolution of the first as JiBX
becomes more widely used. Both scenarios suggest that a common solution
would be more appropriate than leaving it up to the individual apps.
I've played around with a solution based on UmarshallingContext to the
point where I can capture simple mappings (with both name and class
attributes) within a defined directory, but, there's obviously more
required (abstract mappings, extended mappings, structure/@map-as etc.)
to have a full solution.
Does anyone have suggestions on how to approach this task? Or
alternatives, perhaps?
Thanks in advance,
...Leif
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
jibx-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jibx-users
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
jibx-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jibx-users
