| 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.. | |||||