CORBA::MARSHAL exceptions usually occur because of one of these reasons:
- IDL mismatches between client and server (causing unexpected payload differences)
- Crappy ORB products that don't know how to unmarshal complex but valid payloads correctly
Reason #2 is really unlikely nowadays, as ORBs have matured enough that this rarely happens. As long as you're using ORB products on both the client and server side that were built in this century then you're probably ok. That leaves reason #1.
The IDL for the method you're calling is (I believe) from this document, and looks like this:
interface NotificationIRPOperations {
NotificationIRPConstDefs::SubscriptionId attach_push (
in Object manager_reference,
in long time_tick,
in NotificationCategorySet notification_category_set,
in string filter
)
raises (Attach, ParameterNotSupported, InvalidParameter, AlreadySubscribed,
AtLeastOneNotificationCategoryNotSupported);
Note the first parameter, it's of type Object
. However in your code, you're passing a string. However the IDL type Object
maps to org.omg.CORBA.Object
in Java, not to a String
. I would have expected to see you pass objNotiServer
instead for this parameter.
So either your IDL is mismatched with what your server is expecting (likely), or your IDL compiler isn't following the basic IDL-to-Java mapping rules (unlikely).
Either way, something smells bad there. I don't believe that the ORB will implicitly call ORB.string_to_object()
for you, so that would lead to a regular string being sent on the network when the server is actually expecting a stringified Object reference. The difference is subtle but it might be the reason why the server is throwing a MARSHAL
back at you.
So your first port of call should be a check on the IDL file that you're using to build your client. Make sure that you've got the exact and correct IDL for the server you're trying to call. If there's any mismatch at all then MARSHAL
exceptions will happen, and happen a lot.