| From: SMTP%"[email protected]" 11-MAR-1997 10:35:43.11
To: "DEC" <[email protected]>
CC:
Subj: ASAP Objectbroker problem reply #3259 (fwd)
Return-Path: [email protected]
Received: by asimov.mro.dec.com (UCX V4.1-12, OpenVMS V6.2 VAX);
Tue, 11 Mar 1997 10:35:39 -0500
Received: from pobox1.pa.dec.com by fluid.mro.dec.com (5.65v4.0/1.1.8.2/19Nov96-0448PM)
id AA12983; Tue, 11 Mar 1997 10:35:49 -0500
Received: by pobox1.pa.dec.com; id AA10062; Tue, 11 Mar 97 07:35:51 -0800
Received: from mail.4seasons.com by mail1.digital.com (5.65 EXP 4/12/95 for V3.2/1.0/WV)
id AA01868; Tue, 11 Mar 1997 07:26:26 -0800
Received: from mail.4seasons.com ([198.3.126.145]) by mail.4seasons.com (8.6.12/8.6.9) with ESMTP id RAA06300; Tue, 11 Mar 1997 17:34:24 +0100
Message-Id: <[email protected]>
From: "Marcella" <[email protected]>
To: "DEC" <[email protected]>
Subject: ASAP Objectbroker problem reply #3259 (fwd)
Date: Tue, 11 Mar 1997 10:24:44 -0400
X-Msmail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1155
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Customer# 912024
DS# 3590947
PIN# 120970
Hello,
In response to your answer (ObjectBroker, log #3259):
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...
> >
> > A.v.H.
> > ------
> >
> >
> > > >
> > > > ----------
> > > > > From: [email protected]
<[email protected]>
> > > > > To: [email protected]
> > > > > Cc: [email protected]
> > > > > Subject: ASAP Objectbroker problem reply #3259
> > > > > Date: Tuesday, March 04, 1997 10:20 AM
> > > > >
> > > > > Marcella,
> > > > >
> > > > > In response to your call (log #3259) the ObjectBroker
development group
> > > > offers
> > > > > the following.
> > > > >
> > > > > Have you 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.
> > > > >
> > > > > =================
> > > > > ASAP info logged
> > > > > =================
> > > > >
> > > > > Brief Description of Problem:
> > > > > -----------------------------
> > > > >
> > > > > OBJECTBROKER V2.6 DII question.
> > > > >
> > > > > Hello,
> > > > >
> > > > > 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);
> > > > > | ....
> > > > > | 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.
> > > > > 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?)
> > > >
> > >
> > >
> > > --
> Customer # 912024
> Discount Agreement # 3590947
>
+--------------------------------------------------------------------------+
> | Four Seasons Software Tamar Bercovitz-Klein
|
> | Director R&D Operations
|
> | Tel. : (908) 248 6667 E-mail : [email protected]
|
> | Fax : (908) 248 6675 Web site : http://www.4seasons.com
|
>
+--------------------------------------------------------------------------+
|
| POSTED IN OBJECTBROKER_DEVELOPMENT
<<< SEND::HOT_FILES:[NOTES$LIBRARY]OBJECTBROKER_DEVELOPMENT.NOTE;1 >>>
-< ObjectBroker Development >-
================================================================================
Note 2447.2 OBJECTBROKER V2.6 DII problem 2 of 2
HYDRA::AMORELLI 42 lines 11-MAR-1997 12:39
--------------------------------------------------------------------------------
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..
|