summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
Diffstat
-rw-r--r--TAO/ChangeLogs/ChangeLog-02a21
-rw-r--r--TAO/tao/GIOP_Assorted_Headers.h4
-rw-r--r--TAO/tao/GIOP_Message_Accept_State.h12
-rw-r--r--TAO/tao/GIOP_Message_Base.cpp11
-rw-r--r--TAO/tao/GIOP_Message_Base.h15
-rw-r--r--TAO/tao/GIOP_Message_Base.i11
-rw-r--r--TAO/tao/GIOP_Message_Connectors.cpp21
-rw-r--r--TAO/tao/GIOP_Message_Connectors.h9
-rw-r--r--TAO/tao/GIOP_Server_Request.h3
-rw-r--r--TAO/tao/Pluggable_Messaging.h61
-rw-r--r--TAO/tao/Pluggable_Messaging_Utils.cpp1
-rw-r--r--TAO/tao/Pluggable_Messaging_Utils.h23
-rw-r--r--TAO/tao/Pluggable_Messaging_Utils.i11
-rw-r--r--TAO/tao/operation_details.h1
-rw-r--r--TAO/tao/target_identifier.cpp4
-rw-r--r--TAO/tao/target_identifier.h21
-rw-r--r--TAO/tao/target_identifier.i3
17 files changed, 216 insertions, 16 deletions
diff --git a/TAO/ChangeLogs/ChangeLog-02a b/TAO/ChangeLogs/ChangeLog-02a
index 6289e9a102c..5a900bf273d 100644
--- a/TAO/ChangeLogs/ChangeLog-02a
+++ b/TAO/ChangeLogs/ChangeLog-02a
@@ -1,3 +1,24 @@
+Fri Mar 17 14:20:01 2000 Carlos O'Ryan <coryan@uci.edu>
+
+ * tao/GIOP_Assorted_Headers.h:
+ * tao/GIOP_Message_Accept_State.h:
+ * tao/GIOP_Message_Base.h:
+ * tao/GIOP_Message_Base.i:
+ * tao/GIOP_Message_Base.cpp:
+ * tao/GIOP_Message_Connectors.h:
+ * tao/GIOP_Message_Connectors.cpp:
+ * tao/GIOP_Server_Request.h:
+ * tao/Pluggable_Messaging.h:
+ * tao/Pluggable_Messaging_Utils.h:
+ * tao/Pluggable_Messaging_Utils.i:
+ * tao/Pluggable_Messaging_Utils.cpp:
+ * tao/operation_details.h:
+ * tao/target_identifier.h:
+ * tao/target_identifier.i:
+ * tao/target_identifier.cpp:
+ Made an overall review of Bala's coding style and basic
+ design. Left many @@ comments for him.
+
Fri Mar 17 14:17:00 2000 Shawn Hannan <hannan@cs.wustl.edu>
* orbsvcs/LifeCycle_Service/Criteria_Evaluator.cpp:
diff --git a/TAO/tao/GIOP_Assorted_Headers.h b/TAO/tao/GIOP_Assorted_Headers.h
index b5923da9bfb..d10e888a8be 100644
--- a/TAO/tao/GIOP_Assorted_Headers.h
+++ b/TAO/tao/GIOP_Assorted_Headers.h
@@ -20,6 +20,10 @@
#define TAO_GIOP_ASSORTED_HEADERS_H
#include "tao/GIOPC.h"
+// @@ Bala, please pick the names of your files better.
+// First there is only one header here. But GIOP_Headers is better
+// (i.e. sounds more profesional) than 'assorted' (that sounds like
+// a recipe for vegetable soup)
class TAO_GIOP_Locate_Request_Header
{
diff --git a/TAO/tao/GIOP_Message_Accept_State.h b/TAO/tao/GIOP_Message_Accept_State.h
index 1d03230037c..c62d507c5f3 100644
--- a/TAO/tao/GIOP_Message_Accept_State.h
+++ b/TAO/tao/GIOP_Message_Accept_State.h
@@ -19,7 +19,11 @@
#include "tao/GIOP_Server_Request.h"
#include "tao/GIOP_Assorted_Headers.h"
-
+// @@ Bala: do we want to have separate classes for the server side
+// and client side? IMHO not, with bi-directional connections the
+// differences will be completely blurred.
+// Please think about designs that do not require separate state
+// objects, a good side effect: that should reduce code size...
class TAO_GIOP_Message_Accept_State
{
// = TITLE
@@ -28,6 +32,7 @@ class TAO_GIOP_Message_Accept_State
// = DESCRIPTION
// An abstract base class for different versions of GIOP. This is
// similar to the base class in the strategy pattern
+ // @@ Bala: Is it an strategy or not!?
//
public:
@@ -56,6 +61,11 @@ public:
private:
};
+// @@ Bala: again you have the inheritance reversed! A 1.1 server (or
+// client) must support 1.0, but not vice-versa.
+// @@ Bala: a physical design issue: if the protocol is truly
+// pluggable then you should be able to (and you should) put the
+// classes for each protocol in separate files.
class TAO_GIOP_Message_Accept_State_11 :
public TAO_GIOP_Message_Accept_State
{
diff --git a/TAO/tao/GIOP_Message_Base.cpp b/TAO/tao/GIOP_Message_Base.cpp
index d10bb15183f..ed6bcd55922 100644
--- a/TAO/tao/GIOP_Message_Base.cpp
+++ b/TAO/tao/GIOP_Message_Base.cpp
@@ -43,6 +43,7 @@
# include "tao/GIOP_Message_Base.i"
#endif /* __ACE_INLINE__ */
+// @@ Bala: the no-op comments again.
TAO_GIOP_Message_Base::TAO_GIOP_Message_Base (void)
{
//no-op
@@ -62,7 +63,13 @@ TAO_GIOP_Message_Base::
msg.reset ();
TAO_GIOP_Message_Type type = TAO_GIOP_MESSAGERROR;
-
+
+ // @@ Bala: notice that you have to do this translation between the
+ // 'pluggable' types and the GIOP types (there are more efficient
+ // ways to do this, btw).
+ // But only GIOP implements exactly these messages, does that sound
+ // really like a good idea?
+
// First convert the Pluggable type to the GIOP specific type.
switch (t)
{
@@ -131,6 +138,8 @@ TAO_GIOP_Message_Base::
TAO_Target_Specification &spec,
TAO_OutputCDR &cdr)
{
+ // @@ Bala: Why not do this right, the application should call the
+ // methods below directly!
switch (header_type)
{
case TAO_PLUGGABLE_MESSAGE_REQUEST_HEADER:
diff --git a/TAO/tao/GIOP_Message_Base.h b/TAO/tao/GIOP_Message_Base.h
index f89ece505aa..0979e8152e3 100644
--- a/TAO/tao/GIOP_Message_Base.h
+++ b/TAO/tao/GIOP_Message_Base.h
@@ -22,10 +22,16 @@
#define TAO_GIOP_MESSAGE_H
#include "tao/Pluggable_Messaging.h"
+// @@ Bala: Please try not to #include stuff too many times:
+// GIOP_Utils.h includes Pluggable_Messaging already.
#include "tao/GIOP_Utils.h"
-#include "tao/debug.h"
+// @@ Bala: I bet you only need this file in the .cpp file, not in the
+// .h file!
+#include "tao/debug.h"
+// @@ Bala: we put all this stuff in a single line. I hate it too,
+// but the tools that generate man pages get confused otherwise.
class TAO_Export TAO_GIOP_Message_Base :
public TAO_Pluggable_Messaging_Interface
{
@@ -85,10 +91,15 @@ protected:
// are along the critical path such fancy stuff results in reduced
// performance. But let it me here till we get to a time where in we
// are forced to use these methods
+ // @@ Bala: we will never need this, right? Each protocol knows how
+ // to parse its messages, right?
+
const size_t header_len (void);
// This will give the size of the header for different versions of
// GIOP.
-
+
+ // @@ Bala: it makes *NO SENSE* to return const size_t! and some
+ // compliers hate it...
const size_t message_size_offset (void);
// This will give the message_size offset as specified by different
// versions of GIOP
diff --git a/TAO/tao/GIOP_Message_Base.i b/TAO/tao/GIOP_Message_Base.i
index 5b1d898f6dd..98edbef4674 100644
--- a/TAO/tao/GIOP_Message_Base.i
+++ b/TAO/tao/GIOP_Message_Base.i
@@ -43,7 +43,13 @@ TAO_GIOP_Message_Base::message_type_offset (void)
#endif /*if 0*/
-
+// @@ Bala: this is a virtual method. There are very few circumstances
+// where the compiler is able to optimize this call. And there are
+// even few compilers that actually implement that optimization.
+// Furthermore, many compilers cannot inline functions this complex.
+// Finally, you may want to move the debugging messages to helper
+// functions, so there is less coupling and the header files are
+// lighter.
ACE_INLINE int
TAO_GIOP_Message_Base::parse_magic_bytes (
TAO_GIOP_Message_State *state)
@@ -82,6 +88,9 @@ TAO_GIOP_Message_Base::parse_magic_bytes (
return 0;
}
+// @@ Bala: please look at the implementation of ACE_DEBUG and think
+// about how complex this method would be if inlined, there is no way
+// that the compiler can actually inline it!
ACE_INLINE int
TAO_GIOP_Message_Base::parse_header (TAO_GIOP_Message_State *state)
{
diff --git a/TAO/tao/GIOP_Message_Connectors.cpp b/TAO/tao/GIOP_Message_Connectors.cpp
index 4361406d2ae..e248c9a40c9 100644
--- a/TAO/tao/GIOP_Message_Connectors.cpp
+++ b/TAO/tao/GIOP_Message_Connectors.cpp
@@ -15,7 +15,20 @@ TAO_GIOP_Message_Connectors::
parse_reply (TAO_Message_State_Factory &mesg_state,
TAO_Pluggable_Connector_Params &params)
{
-
+ // @@ Bala: See how the message state is a per-protocol thing?
+ // Wouldn't it be better to have each protocol define its own
+ // message state and just use that type directly (i.e no
+ // message_state base class). As far as i can see (but i may be
+ // wrong), only very tightly related messaging protocols and
+ // transport protocols can use the same message state (for
+ // example GIOP 1.x and GIOP Lite). Furthermore, if i'm proven
+ // wrong and there is common functionality among different
+ // pluggable messaging protocols, we can simply re-factor at that
+ // point.
+ // IMHO the right approach is to factor out common functionality
+ // and interfaces 'a posteriori', otherwise we will define
+ // ackward interfaces that will have to be changed anyway!
+
// Cast to the GIOP Message state
TAO_GIOP_Message_State *state = ACE_dynamic_cast (TAO_GIOP_Message_State *,
&mesg_state);
@@ -43,7 +56,9 @@ TAO_GIOP_Message_Connectors::
"extracting reply status\n"));
return -1;
}
-
+
+ // @@ Bala: More silly translations!
+
// Pass the right Pluggable interface code to the transport layer
switch (rep_stat)
{
@@ -291,5 +306,7 @@ CORBA::Octet
TAO_GIOP_Message_Connector_10:: minor_version (void)
{
// Any harm in hardcoding??
+ // @@ Bala: of course not... but don't cast stuff that doen't need
+ // casting! return 0 is enough.
return (CORBA::Octet) 0;
}
diff --git a/TAO/tao/GIOP_Message_Connectors.h b/TAO/tao/GIOP_Message_Connectors.h
index 977d2e3f68b..0d18b855f78 100644
--- a/TAO/tao/GIOP_Message_Connectors.h
+++ b/TAO/tao/GIOP_Message_Connectors.h
@@ -16,6 +16,10 @@
// Balachandran Natarajan <bala@cs.wustl.edu>
//
// ============================================================================
+
+// @@ Bala: Please be consisten about the macros, if you are not,
+// somebody will use the same one in another file, it is hard to find
+// them and change them automatically, etc. etc.
#ifndef TAO_GIOP_MESSAGE_CONNECTORS_
#define TAO_GIOP_MESSAGE_CONNECTORS_
#include "tao/GIOP_Message_Base.h"
@@ -96,6 +100,11 @@ private:
// Our minor and major versions
};
+// @@ Bala: this is *COMPLETELY* backwards, this way we have to change
+// all the classes everytime a new version comes out. We also may want
+// to compile TAO with only support for GIOP 1.1 (say because this is
+// an embedded application that does not need the cool GIOP 1.1 and
+// 1.2 features)!
class TAO_Export TAO_GIOP_Message_Connector_10:
public TAO_GIOP_Message_Connector_11
{
diff --git a/TAO/tao/GIOP_Server_Request.h b/TAO/tao/GIOP_Server_Request.h
index 50337e61a52..330d8d64cb9 100644
--- a/TAO/tao/GIOP_Server_Request.h
+++ b/TAO/tao/GIOP_Server_Request.h
@@ -22,6 +22,9 @@
#define TAO_GIOP_SERVER_REQUEST_H
#include "tao/corbafwd.h"
+// @@ Bala: there is a reasons why the rest of the #includes are after
+// the pragma once, think about it.
+
//#include "tao/GIOP_Utils.h"
#include "tao/GIOP_Message_Base.h"
diff --git a/TAO/tao/Pluggable_Messaging.h b/TAO/tao/Pluggable_Messaging.h
index fd3bc96a384..2cdeef48368 100644
--- a/TAO/tao/Pluggable_Messaging.h
+++ b/TAO/tao/Pluggable_Messaging.h
@@ -16,10 +16,26 @@
// Balachandran Natarajan <bala@cs.wustl.edu>
//
// ============================================================================
+
+// @@ Bala: please try to be consistent among:
+// - The name of the file
+// - The name of the macro protecting the file against multiple
+// #includes
+// - The name of the class or classes in the file.
+//
+// In this case you have: Pluggable_Messaging.h, PLUGGABLE_MESSAGE_H
+// and Pluggable_Messaging_Interface.
+//
#ifndef TAO_PLUGGABLE_MESSAGE_H
#define TAO_PLUGGABLE_MESSAGE_H
#include "tao/corbafwd.h"
+
+// @@ It seems like you don't need to #include all this stuff, please
+// use forward declarations when possible. The rules are not that
+// bad, if you only need pointers and references a forward
+// reference is enough.
+
#include "tao/Pluggable.h"
#include "tao/target_identifier.h"
#include "tao/Pluggable_Messaging_Utils.h"
@@ -52,7 +68,20 @@ public:
int two_way = 1) = 0;
// This is a complement of the previous method. This method sends
// the CDR through the transport layer
-
+
+ // @@ Bala: here is one example of things that should be more
+ // decoupled, for example you could have methods
+ //
+ // write_request_header()
+ // write_reply_header()
+ // write_locate_request_header()
+ //
+ // of course some of them would return an error if the pluggable
+ // messaging protocol does not support it. Furthermore, maybe the
+ // right approach is to have *each* pluggable messaging define its
+ // own methods. Then the pluggable transport will deal with them.
+ // Don't jump into this yet, it is only an idea for discussion.
+ //
virtual CORBA::Boolean
write_message_header (const TAO_Operation_Details &opdetails,
TAO_Pluggable_Header_Type header_type,
@@ -64,7 +93,8 @@ public:
// influenced by GIOP, which has the protocol header, followed by
// the message specific header with the message at the end.
-
+ // @@ Bala: What if the protocol only has message headers and not
+ // 'protocol headers'?
virtual CORBA::Boolean write_protocol_header (TAO_Pluggable_Message_Type t,
TAO_OutputCDR &msg)
= 0;
@@ -73,13 +103,24 @@ public:
// necessary, but our Invocation classes seesm to be looking for
// something like this. Further, the invocation classes seem to do
// what our IDL compiler wants.
-
-
+ // @@ Bala: Please see my comments on the Connector_Params
+ // struct. BTW, 'Connector_Params' is a horrible name. "request
+ // params" or something like that sounds better.
virtual int parse_reply (TAO_Message_State_Factory &state,
TAO_Pluggable_Connector_Params &params) = 0;
// Parse the reply..
+ // @@ Bala: calling this 'connector' is confusing, the Connector and
+ // Acceptor patterns are engraved in our minds to mean
+ // something different.
+ // @@ I believe that 'process message' is a better name, first, it
+ // is a single message that you are processing (singular), next it
+ // is a generic message, there is nothing 'Connector' about it.
+ // @@ I just thought that you may mean Connector as in IIOP_Connect
+ // or UIOP_Connect files. Those files are "accidental" from the
+ // perspective of the pluggable protocols framework. Think about
+ // them as dirty laundry ;-) ;-)
virtual int process_connector_messages (TAO_Transport *transport,
TAO_ORB_Core *orb_core,
TAO_InputCDR &input,
@@ -88,6 +129,8 @@ public:
// server side processing
protected:
+ // @@ Bala: is this a good name? Why not just "send mesage", or
+ // something like that?
int transport_message (TAO_Transport *transport,
TAO_OutputCDR &stream,
int two_way = 1,
@@ -100,8 +143,8 @@ protected:
// error checking in a seperate place for ease of maintenance.
};
-
-
+// @@ Bala: note the separator
+// ****************************************************************
class TAO_Export TAO_Message_State_Factory
{
@@ -109,7 +152,13 @@ class TAO_Export TAO_Message_State_Factory
// Generic definitions for Message States.
//
// = DESCRIPTION
+ // @@ Bala: please read your first sentence, it makes no sense..
// This would represnt the state of the incoming message states.
+ //
+ // @@ Bala: how do you know if other protocols support fragments,
+ // or need them? What about Dgram based protocol where there
+ // are no partial reads?
+ //
// As the ORB processes incoming messages it need to keep track of
// how much of the message has been read. if there are any
// fragments following this message etc. This class attempts to
diff --git a/TAO/tao/Pluggable_Messaging_Utils.cpp b/TAO/tao/Pluggable_Messaging_Utils.cpp
index 35878ff4dec..016d5b7d0cd 100644
--- a/TAO/tao/Pluggable_Messaging_Utils.cpp
+++ b/TAO/tao/Pluggable_Messaging_Utils.cpp
@@ -5,3 +5,4 @@
#include "tao/Pluggable_Messaging_Utils.i"
#endif /* __ACE_INLINE__ */
+// @@ Bala: don't forget the RCSID stuff.
diff --git a/TAO/tao/Pluggable_Messaging_Utils.h b/TAO/tao/Pluggable_Messaging_Utils.h
index a01bce36619..2037294676a 100644
--- a/TAO/tao/Pluggable_Messaging_Utils.h
+++ b/TAO/tao/Pluggable_Messaging_Utils.h
@@ -16,10 +16,17 @@
// Balachandran Natarajan <bala@cs.wustl.edu>
//
// ============================================================================
+// @@ Bala: blank lines don't cost you any money, please don't try to
+// save them, i can borrow you some if you need them ;-)
#ifndef TAO_PLUGGABLE_MESSAGING_UTILS_H
#define TAO_PLUGGABLE_MESSAGING_UTILS_H
#include "tao/IOPC.h"
+// @@ Bala: It is not clear that all protocol would use a request id
+// or that they will be able to pass a service context around. OTOH
+// we can always leave the svc_ctx empty for protocols that don't
+// support it. And use an internal table to map request ids to
+// whatever underlying request token is used.
class TAO_Export TAO_Pluggable_Connector_Params
{
// = TITLE
@@ -38,10 +45,20 @@ public:
CORBA::ULong request_id_;
// The request id for which the reply we (connector) has received
+ // @@ Bala: this is (again) an GIOPism (to coin a word). Other
+ // protocol may choose to send different *messages* instead.
CORBA::ULong reply_status_;
// The reply status
};
+// @@ Bala: Please do not polute the global namespace, and this is C++
+// not C, you can say
+// enum TAO_Foo { bar, baz, qux };
+// @@ Bala: this is a GIOPism too, there is no such thing as locate
+// request in HTTP (the basis for SOAP and XIOP), i don't know about
+// HTTP-NG, but i wouldn't be surprised if it had. Furthermore, some
+// very influential people (Michi) is arguing against it in the OMG.
+//
typedef enum HeaderType
{
// = TITLE
@@ -51,7 +68,10 @@ typedef enum HeaderType
TAO_PLUGGABLE_MESSAGE_LOCATE_REQUEST_HEADER
}TAO_Pluggable_Header_Type;
-
+// @@ Bala: This is a hopeless GIOPism. it should not be exposed in
+// the Pluggable Messaging generic classes. What we should think
+// about is what *methods* are required to expose this functionality
+// to the rest of the ORB.
typedef enum MessageType
{
// = DESCRIPTION
@@ -71,6 +91,7 @@ typedef enum MessageType
TAO_PLUGGABLE_MESSAGE_FRAGMENT = 7
}TAO_Pluggable_Message_Type;
+// @@ Bala: This is a hopeless GIOPism.
typedef enum Exception_Types
{
// = DESCRIPTION
diff --git a/TAO/tao/Pluggable_Messaging_Utils.i b/TAO/tao/Pluggable_Messaging_Utils.i
index 4672e66902b..e79855e654b 100644
--- a/TAO/tao/Pluggable_Messaging_Utils.i
+++ b/TAO/tao/Pluggable_Messaging_Utils.i
@@ -7,5 +7,16 @@ TAO_Pluggable_Connector_Params::TAO_Pluggable_Connector_Params (void)
request_id_ (0),
reply_status_ (0)
{
+ // @@ Bala: this comment is as useful as a hole in the head. First
+ // the constructor is *not* a no-op, the initialization section was
+ // non-trivial, and the constructor sets up the virtual table and a
+ // bunch of other things. Furthermore I can *see* that the function
+ // is empty, the comment is just adding noise. It reminds me of the
+ // following example of what *not* to put in a comment:
+ //
+ // Display display; // the display
+ //
+ // ;-) ;-)
+
//no-op
}
diff --git a/TAO/tao/operation_details.h b/TAO/tao/operation_details.h
index 64ffba59d3a..914721ad67f 100644
--- a/TAO/tao/operation_details.h
+++ b/TAO/tao/operation_details.h
@@ -18,6 +18,7 @@
#include "tao/corbafwd.h"
#include "tao/IOPC.h"
+// @@ Bala: Why is this not part of the RequestHeader?!
class TAO_Operation_Details
{
// = TITLE
diff --git a/TAO/tao/target_identifier.cpp b/TAO/tao/target_identifier.cpp
index 536aed72317..7b012040b26 100644
--- a/TAO/tao/target_identifier.cpp
+++ b/TAO/tao/target_identifier.cpp
@@ -1,7 +1,11 @@
+// @@ Bala: please put a blank before the $Id
//$Id$
+// @@ Bala: please leave a blank like here.
#include "tao/target_identifier.h"
#if !defined (__ACE_INLINE__)
#include "target_identifier.i"
#endif /* !defined INLINE */
+// @@ Bala: please put the RCSID macros.
+
diff --git a/TAO/tao/target_identifier.h b/TAO/tao/target_identifier.h
index 295cc6e2d31..129a4b8ece5 100644
--- a/TAO/tao/target_identifier.h
+++ b/TAO/tao/target_identifier.h
@@ -16,8 +16,12 @@
// = AUTHOR
// Balachandran Natarajan <bala@cs.wustl.edu>
// ============================================================================
+
+// @@ Bala: Please don't start global macros with _ and an uppercase
+// character. Those names are reserved for the implementation.
#ifndef _TAO_TARGET_SPECIFICATION_H_
#define _TAO_TARGET_SPECIFICATION_H_
+
#include "tao/Object_KeyC.h"
#include "tao/IOPC.h"
@@ -28,9 +32,17 @@ class TAO_Target_Specification
// A class to encapsulate all the ways of specifying targets.
//
// = DESCRIPTION
- // This is a sort of auxillary class. The motivation behind this
+ // @@ Bala: This is too colloquial for a coment, don't you think?
+ // This is a sort of auxillary class.
+
+ // @@ Bala: do we have examples of how other protocols map object
+ // keys? What if they pass something around that does not fit
+ // this model?
+ // The motivation behind this
// is GIOP 1.2 althought I foresee other messaging protocols doing
- // something similar. The Invocation classes (client side) were
+ // something similar.
+
+ // The Invocation classes (client side) were
// passing the object key that they had extracted from the
// profiles with every invocation. This extraction would be done
// based on the policies that are specified for the client side
@@ -56,6 +68,11 @@ public:
void target_specifier (IOP::IOR *ior,
CORBA::ULong prof_index);
// Specification of targets
+ // @@ Bala: I think i know what these methods use, but other users
+ // may not!
+ // @@ Bala: please document the life-cycle constraint in this class
+ // they are very counter-intuitive. In fact it may be better just
+ // to make a copy of the class!
const TAO_ObjectKey* object_key (void);
// Returns the object key after a check of the stored specifier. If
diff --git a/TAO/tao/target_identifier.i b/TAO/tao/target_identifier.i
index 9f79b1bcb21..9011b327880 100644
--- a/TAO/tao/target_identifier.i
+++ b/TAO/tao/target_identifier.i
@@ -13,6 +13,9 @@ ACE_INLINE void
TAO_Target_Specification::target_specifier (const TAO_ObjectKey &key)
{
this->specifier_ = TAO_Target_Specification::Key_Addr;
+ // @@ Bala: this is a good recipe for a crash, if the <key> was on
+ // the stack or is otherwise destroyed then you are in big
+ // trouble.
this->u_.object_key_ = ACE_const_cast (TAO_ObjectKey *,
&key);
}
View Lorry Controller Status