[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference pamsrc::objectbroker_development

Title:ObjectBroker Development - BEA Systems' CORBA
Notice:See note 2 for kit locations; note 4 for training
Moderator:RECV::GUMBELd
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

2447.0. "OBJECTBROKER V2.6 DII problem" by HYDRA::AMORELLI () Mon Mar 03 1997 16:28

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.RTitleUserPersonal
Name
DateLines
2447.1REQUE::BOWERPeter Bower, ObjectBrokerMon Mar 03 1997 17:189
    
    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.2HYDRA::AMORELLITue Mar 11 1997 12:3942
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..