Re: [wsrp-comment] 5.4.2.1 Event handling: Is a note needed stating how theproducer should interpret eventsParams.portletStateChange

While this additional statement could
make sense, one could also argue that the exchanged structures already
encourage such an implementation as the Producer can only return a single
clone. Personally I am fine either way.

There is a related issue regarding advice
to the Consumer regarding sending parallel handleEvent invocations which
all have portletStateChange="cloneBeforeWrite". This is a case
where it would be onerous , at best, for the Producer to try and connect
the invocations relative to reusing a clone produced early in the process.

Rich 

Nathan E Lipke <>

09/12/2007 12:39 PM

To



cc

Subject

[wsrp-comment] 5.4.2.1 Event handling:
Is a note needed stating how the producer should interpret eventsParams.portletStateChange

In the following use-case the interpretation of 

eventsParams.portletStateChange may need to be clarified.

   1. The consumer sends a handle events message, such that:

         1. eventsParams.portletStateChange is "cloneBeforeWrite"

         2. eventParams.events contains

               1. event1

               2. event2

   2. The producer receives the message and dispatches the events
to the

      portlet (in the order of event1 then event2)

         1. During processing of event1 a state change
is made such that

            an implicit  clone occurs

         2. During then processing of event2 another
state change happens

          * At this point another clone should
not happen, rather the

            portletStateChange field is effectively

            "readWrite")

The note could read something like:

During an invocation of HandleEvents where the portletStateChange field

is "cloneBeforeWrite" the producer MUST NOT clone the portlet
more than 

once. The portlet may change its state after the clone, as though the 

portletStateChange field was "readWrite".

Thanks,

Nate

Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries
 and  affiliated entities,  that may be confidential,  proprietary,
 copyrighted  and/or legally privileged, and is intended solely
for the use of the individual or entity named in this message. If you are
not the intended recipient, and have received this message in error, please
immediately return this by email and then delete it.