X-Git-Url: https://git.teslayout.com/public/public/public/?a=blobdiff_plain;f=include%2Fanna%2Fdiameter%2Fcodec%2FMessage.hpp;h=c8dab7c1b7ff5b92dcfe890c7c86dd1208efcb4d;hb=b9cb59210ce2a02d8246f1a9a1acfcfdcd892f3a;hp=9f3c85f75cb89d251cfe0b9dd7bf83162cf4bdda;hpb=e7dbacff41163bf8cefb267daae84d96056ebc86;p=anna.git

diff --git a/include/anna/diameter/codec/Message.hpp b/include/anna/diameter/codec/Message.hpp
index 9f3c85f..c8dab7c 100644
--- a/include/anna/diameter/codec/Message.hpp
+++ b/include/anna/diameter/codec/Message.hpp
@@ -148,28 +148,28 @@ class Message {
   const anna::diameter::stack::Command *getStackCommand(CommandId id) const throw(anna::RuntimeException);
 
   void setFailedAvp(const parent_t &parent, AvpId wrong, const char *wrongName = NULL) throw(anna::RuntimeException);
-  	  // During message decoding and validation, the first wrong avp is stored and all the tracking is managed to find out its
-      //  nested path for the case of grouped avps with wrong avps inside. Remember the RFC 6733, section 7.5:
-      //
-      //				   In the case where the offending AVP is embedded within a Grouped AVP,
-	  //				   the Failed-AVP MAY contain the grouped AVP, which in turn contains
-	  //				   the single offending AVP.  The same method MAY be employed if the
-	  //				   grouped AVP itself is embedded in yet another grouped AVP and so on.
-	  //				   In this case, the Failed-AVP MAY contain the grouped AVP hierarchy up
-	  //				   to the single offending AVP.  This enables the recipient to detect
-  	  //				   the location of the offending AVP when embedded in a group.
-      //
-      // The first wrong avp found will set the final result code, as the RFC recommends:
-      //
-	  //				   The value of the Result-Code AVP will provide information on the reason
-	  //				   for the Failed-AVP AVP.  A Diameter answer message SHOULD contain an
-	  //				   instance of the Failed-AVP AVP that corresponds to the error
-	  //				   indicated by the Result-Code AVP.  For practical purposes, this
-      //				   Failed-AVP would typically refer to the first AVP processing error
-	  //				   that a Diameter node encounters.
-  	  //
-      // The message keeps the list (reverse order) of avps hierarchy (in case of grouping) for the final Failed-AVP construction,
-      // which is done at the end of decoding or validation, and only the first wrong avp is stored with its corresponding path.
+  // During message decoding and validation, the first wrong avp is stored and all the tracking is managed to find out its
+  //  nested path for the case of grouped avps with wrong avps inside. Remember the RFC 6733, section 7.5:
+  //
+  //           In the case where the offending AVP is embedded within a Grouped AVP,
+  //           the Failed-AVP MAY contain the grouped AVP, which in turn contains
+  //           the single offending AVP.  The same method MAY be employed if the
+  //           grouped AVP itself is embedded in yet another grouped AVP and so on.
+  //           In this case, the Failed-AVP MAY contain the grouped AVP hierarchy up
+  //           to the single offending AVP.  This enables the recipient to detect
+  //           the location of the offending AVP when embedded in a group.
+  //
+  // The first wrong avp found will set the final result code, as the RFC recommends:
+  //
+  //           The value of the Result-Code AVP will provide information on the reason
+  //           for the Failed-AVP AVP.  A Diameter answer message SHOULD contain an
+  //           instance of the Failed-AVP AVP that corresponds to the error
+  //           indicated by the Result-Code AVP.  For practical purposes, this
+  //           Failed-AVP would typically refer to the first AVP processing error
+  //           that a Diameter node encounters.
+  //
+  // The message keeps the list (reverse order) of avps hierarchy (in case of grouping) for the final Failed-AVP construction,
+  // which is done at the end of decoding or validation, and only the first wrong avp is stored with its corresponding path.
 
 
 protected:
@@ -280,10 +280,21 @@ public:
   void setPotentiallyReTransmittedMessageBit(bool activate = true) throw() { if(activate) a_flags |= TBitMask; else a_flags &= (~TBitMask); }
 
   /**
-     Sets the message application id
+     Sets the message application id.
+
+     The codec engine could be configured to force a stack selection based in this field value: see #selectStackWithApplicationId.
+     In multistack applications (which also shall be monothreaded), you only have to take care about how to apply this method: the thing
+     is that you must not interleave message builds which belongs to different stacks. For example, you could think about setting the
+     message header for message A using stack A. Then, start to add the message header fields for a second message B using another stack B.
+     Following you would add the message A avps, but then, the stack is not going to be automatically changed (this is only done through this
+     method). The result could be unexpected when adding/encoding messages with a dictionary which does not correspond.
+
+     @warning do not interleave build/encode operations between different messages which uses different stacks over the same codec engine.
+     It seems common sense, but it is not bad to advice about this.
+
      @param aid Application-id.
   */
-  void setApplicationId(U32 aid) throw() { a_applicationId = aid; }
+  void setApplicationId(U32 aid) throw();
 
   /**
      Sets the message hop-by-hop