Title: | ObjectBroker Development - BEA Systems' CORBA |
Notice: | See note 2 for kit locations; note 4 for training |
Moderator: | RECV::GUMBEL d |
Created: | Thu Dec 27 1990 |
Last Modified: | Fri Jun 06 1997 |
Last Successful Update: | Fri Jun 06 1997 |
Number of topics: | 2482 |
Total number of notes: | 13057 |
Hi, One of our partners is having a problem with ObjectBroker 2.6. Any ideas? Thanks, Carl ================ I'am using CORBA DII (ObjectBroker V2.6 for NT, with C) to map our 4GL language onto CORBA. Mapping procedures is going fine now, but I do have a problem with functions (i.e. functions which do return a result, which is defined by a typedef). Example: I can't access 'fSwapBlob' with DII without getting an exception: | typedef sequence<octet> blob; | interface Store | { | void SwapFloat(IN float newValue, OUT float oldValue); | .... To invoke CORBA object functions with DII, I'am using: | result->argument._type = CORBA_OperationDef__get_result(..); to set the returned datatype for the to be invoked request. This works fine when basic CORBA types are returned, but not when a 'typedef' result is returned. When I send the actual request, objectBroker returns an exception 'CORBA_MARSHAL' (i.e. 'OBB_INV_MRSHERR (e)'). The remote method seems to be invoked correctly. Simplied example: 'aFunction1()' goes fine, but 'aFunction2' fails: | typedef float Money; | interface Bank | { | float aFunction1() | Money aFunction2() | } When I check the kind of the returned datatype for 'aFunction2', the datatype 'kind' is float, so I accept it and handles it just like 'aFunction1'. Questions: 1) Is my assumption correct (CORBA_OperationDef__get_result() can be used to build a request and 'hides' typedefs, just alike CORBA_create_operation_list() does)? Or am I doing some buggy programming? 2) How can I solve this 'typedef' problem for function results, i.e. how can I handle a function which returns a 'blob'? (an example?) | void SwapBlob (IN blob newValue, OUT blob oldValue); | | float fSwapFloat(IN float newValue, OUT float oldValue); | .... | blob fSwapBlob (IN blob newValue, OUT blob oldValue); | } I also can't replace 'blob' by 'sequence<octet>' as result of 'fSwapBlob', because the IDL compiler doesn't accept this.
T.R | Title | User | Personal Name | Date | Lines |
---|---|---|---|---|---|
2447.1 | REQUE::BOWER | Peter Bower, ObjectBroker | Mon Mar 03 1997 17:18 | 9 | |
Has the customer registered a typecode lookup routine ? If you are using the DII, you need to register a typecode lookup routine in order for the ORB to be able to unmarshal the complex datatype. Check out a generated stub for an example. Note: you can call OBB_exception_errortext to get more information about system exceptions. | |||||
2447.2 | HYDRA::AMORELLI | Tue Mar 11 1997 12:39 | 42 | ||
Hi. Thanks for the help so far. Here's more from the partner. Thanks, Carl ========= In response to your answer... Maybe I need to reformulate my question (see REASONS): Are you sure ObjectBroker's implemention of | result->argument._type = CORBA_OperationDef__get_result(..); is correct? (If it does set the proper typecode, during the request handling a TC-lookup routine shouldn't be needed, because all required typecode information is already available in the request settings.) REASONS: I didn't registered a type-code lookup routine, because: A) Without such TC-lookup routine, procedures with user-defined arguments (i.e. my 'blob') are already going fine, so why also not for function results? In other words, why does: | result->argument._type = CORBA_OperationDef__get_result(..); not set the proper (user-defined) typecode, just alike | CORBA_create_operation_list(..); does for the operation arguments? B) I can't find it in the CORBA standard, I trying to prevent to write CORBA-implementation specific code, for portability. C) When I look at the generated stubs, such tc-lookup-routine is implemented by C-code with 'hardcoded' type information, which was generated from the repository. I don't want hardcoded type-information in my program, that's why I'am using DII instead of generated stubs... Either your answer implies I still need to generate stubs when I'am using DII, which is a solution I can't use, or maybe there's a more dynamic way (without hardcoding typeinfo) to implement such routine.. |