Re: [wsrp] Portlet lifecycles and CCP's

[Subbu Allamaraju <subbu@bea.com>]

> first.
> 
>>The spec does require this indirectly. All handles created within a
>>registrationContext are required to become invalid after deregister().
> 
> 
> That's true they are invalid, therefor a smart producer would most probably
> destroy them.
> However I think we require this step explicitly (not indirectly).
> See 8.4:
> 
>   The Consumer MUST inform the Producer that a Consumer Configured Portlet
>   will no longer be used by invoking destroyPortlets() and MUST NOT
>   consider a Portlet to have been destroyed until destroyPortlets() has
>   been successfully invoked for that Portlet.
> 
> I would say you can indirectly assume that a producer will destroy the
> resources after deregister().
> And why make a distinction between the registered case and not registered
> case (where producer does not req' registration - here you need to destroy
> these explicitly).

Right, good catch. In either case, the CCPs become invalid from the 
Consumer's perspective.

But your observation brings up an interesting point. If we already 
require that Consumers MUST destroy CCPs, why require the Producer to 
make those handles invalid after deregister()? The Producer could very 
well return, e.g., an HandlesInUse fault, and let Consumer call 
destroyPortlets() before deregister(). From the interface design 
perspective, it is possible to argue that this approach is inconsistent 
with the way we handle sessions and cookies.

I can see the use case for the current behavior (particularly with lazy 
consumers), but the reader must put these two sides together to 
understand CCP handling.

> 
> 
>>This means that all cloned portlets become invalid even without the
>>Consumer calling destroyPortlets() first. From the consumer's
>>perspective, those CCPs no longer exist after deregister().
> 
> right, implementations would do that, but from the producer perspective
> it's difference between invalid and destroyed :-)

May be not. Extending Andre's point, destroy and invalid may mean the 
same for the Producer, depending on the implementation. For both 
operations, the producer may just flip a boolean in its datastore.

> Really riding the §'s now :-)

Oh ya :-)

Subbu