wsrp message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [wsrp] What faults to throw when property writes are
- From: Rich Thompson <richt2@us.ibm.com>
- To: wsrp@lists.oasis-open.org
- Date: Fri, 4 Apr 2003 08:38:54 -0500
My opinions are intertwined with <rt/>
Rich Thompson
| Andre Kramer <andre.kramer@eu.citrix.com>
04/04/2003 03:38 AM
|
To:
wsrp@lists.oasis-open.org
cc:
Subject:
[wsrp] What faults to throw when property
writes are |
Yesterday, we said we would continue to use this list
for spec &
implementation discussion. So here goes one set of questions I would be
interested to hear people's opinion on:
In section 6.3.3 we say that "the producer MUST throw a fault message
if the
processing the interaction requires changing its persistent state"
if
"readOnly". We don't say what the fault MUST be. PortletStateChangeRequired
I presume ...
<rt>We talked about whether to specify the fault
to throw and decided to leave it up to the Producer. Interface.PortletStateChangeRequired
is certainly a leading candidate.</rt>
Later, we say that "Interface.PortletStateChangeRequired" MAY
be throw if
the "producer implements access control that prevents Portlets from
updating
persistent state". Surely that should be a security (Top Level Security.)
exception ;-)
<rt>Why would that be a security exception?
The scenario is that a Portlet attempts to write a property that the Producer
will not allow it to write. Presumably the Producer informs the Portlet
of this with an exception and the Portlet decides whether it can proceed
without having changed that property or whether the invocation should fail.
If the decision is to fail, this statement encourages (but doesn't require)
that the Interface.PortletStateChangedRequired fault message be returned.
Of course, it is possible that the Portlet doesn't catch the Producer's
exception and the actual fault returned is a serialization of that internal
error.</rt>
Also, what actual fault should be thrown for the following cases (note
that
not all the operations declare a throws PortletStateChangeRequired)?
- a Portlet attempts to set a property in getMarkup.
<rt>Spec prohibits this. The Producer should
throw an exception to the Portlet on the attempt.</rt>
Should the producer throw a fault or silently discard the update or generate
an error markup fragment?
<rt>The Portlet could decide to return a fault
instead of markup ... probably OperationFailed. But fundamentally this
would be a non-conformant Portlet</rt>
- a Consumer attempts to update a preference on a publicly offered portlet.
Should the producer throw a fault or silently discard the update or generate
an error markup fragment? Can we allow writes in some cases (admin
level
consumers)?
<rt>I think a Security.AccessDenied fault message
would be appropriate. The detail message should specify that setting properties
on Producer Offered Portlets is not allowed.</rt>
While we are not required to align all the above, interop and testing would
be improved if we tighten property update fault semantics.
regards,
Andre
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]