JiBX Marhsaller - multi-object support

[rwilcom]

Does/Can the marshaller property on the endpoint take in a list of marshaller beans so that the enpoint can return multiple types of classes. For example, I want one method in my endpoint to return ObjectX and another to return ObjectY - the endpoint takes in a Message object that steers the inovke into the proper method - and those methods may return different types. JiBX could resolve the object type through its binding map - right?

Seems like the only alternative to that is to map multiple endpoints and have a singe in/out object for each method (yuk!).

[Arjen Poutsma]

Does/Can the marshaller property on the endpoint take in a list of marshaller beans so that the enpoint can return multiple types of classes. For example, I want one method in my endpoint to return ObjectX and another to return ObjectY - the endpoint takes in a Message object that steers the inovke into the proper method - and those methods may return different types. JiBX could resolve the object type through its binding map - right?

Well, I could add that, but it would solve anything for you. If you look at the Jibx documentation here: http://jibx.sourceforge.net/runtime.html, you will see that a JiBX IBindingDirectory (and therefore IUnmarshallingContext and IMarshallingContext) is bound to a single class. Basically, there is no way to find out a suitable unmarshaller for a given piece of input xml, or a suitable marshaller for a given object. You always have to given it a class. If there is a way, please tell me.

Seems like the only alternative to that is to map multiple endpoints and have a singe in/out object for each method (yuk!).

Yup, it sucks, due to JiBX's API. All that speed you get comes with a price .

Cheers,

[rwilcom]

I don't know your underlying code structure layout so this may or may not work - the response (outgoing) object could be marshalled by just doing an <Object>.getClass() on it - the class returned will be the actual class (polymorphed).... the request (incoming) the XML coming in is a more difficult problem - the only semi-clean way to manage that is to require the user to send the JiBX mapped (base) class name in a header (HTTP or SOAP or ?) - then you would have to peel that out and do a Class.forName(..) on that value before invoking JiBX. I'm not even sure you would have to define the marhalling in this case - it would be automatically defined. (?)

Unfortunitly, this is not a very symmetric solution so I wouldn't suggest it! Just thought I would kick around some ideas. Bottom line is that it would sure be nice just to send/receive objects without breaking out all of the possibilities in the context file per end point.

thanks.
Ron

[Arjen Poutsma]

Yeah, it would be nice. Unfortunately, I don't see any way to add it in a nice way (especially for the unmarshalling, like you indicated). Of course, you could try and guess the correct binding context by looking at the content, but that would seriously slow things down. And the main reason for using Jibx is speed, so it makes no sense.

It would be nice if Dennis, the creator of JiBX, would solve this, because I don't think there is a way I can.

Cheers,