You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@deltaspike.apache.org by Rudy De Busscher <rd...@gmail.com> on 2013/10/21 16:05:56 UTC
[Proposal] messages stored but not tied to JSF system.
All,
With the JsfMessage interface, you can add messages to the FacesContext so
that they are displayed on screen the next rendering.
But what if your CDI beans are used within a JSF context AND a REST
context. When processing the REST request, there is no facesContext
available and exceptions occur.
My proposal is to have, aside the JsfMessage interface, a similar one,
something like BusinessMessage, that works exactly the same but which
doesn't store the message in FacesContext but in a custom ThreadLocal
variable.
Then the messages can be picked up by a REST interceptor and added to the,
for example, JSON response. But it can also be picked up by a JSF
lifecycle interceptor.
I can commit the code which I have developped for a demo application that
uses it.
WDYT?
Regards
Rudy
Re: [Proposal] messages stored but not tied to JSF system.
Posted by Rudy De Busscher <rd...@gmail.com>.
How the information is sent back to the clients is something for each
project individual. We can't generify that in DeltaSpike, I guess.
I have the following filter
*@Provider*
*public class WrapResponseFilter implements ContainerResponseFilter {*
* @Override*
* public void filter(ContainerRequestContext requestContext,
ContainerResponseContext responseContext) throws*
* IOException {*
*
*
* Object entity = responseContext.getEntity();*
* ObjectMapper mapper = new ObjectMapper();*
* String payload = mapper.writeValueAsString(entity);*
*
*
* Transfer result = new Transfer();*
* result.setData(payload);*
* *
* List<Message> messages =
BusinessMessageContext.getCurrentInstance().getMessages();*
* for (Message msg : messages) {*
* result.addMesssage(msg);
*
* }*
* responseContext.setEntity(mapper.writeValueAsString(result));*
*
*
* .......*
* }
*
*}*
Rudy
On 21 October 2013 16:40, John D. Ament <jo...@gmail.com> wrote:
> We face this issue as well, but more generally how to handle messaging
> back to REST clients. For example, when we're not returning back a
> 200 OK we include some messages back for error handling to display to
> the GUI what happened. These could be complex objects with
> substitutions as well.
>
> To do this, all of our POJOs back to the client extend from a base
> class which can include these variables. It's then up to the client
> to figure out how to render these messages.
>
> What did you have in mind for consolidating?
>
> On Mon, Oct 21, 2013 at 10:05 AM, Rudy De Busscher
> <rd...@gmail.com> wrote:
> > All,
> >
> > With the JsfMessage interface, you can add messages to the FacesContext
> so
> > that they are displayed on screen the next rendering.
> >
> > But what if your CDI beans are used within a JSF context AND a REST
> > context. When processing the REST request, there is no facesContext
> > available and exceptions occur.
> >
> > My proposal is to have, aside the JsfMessage interface, a similar one,
> > something like BusinessMessage, that works exactly the same but which
> > doesn't store the message in FacesContext but in a custom ThreadLocal
> > variable.
> >
> > Then the messages can be picked up by a REST interceptor and added to
> the,
> > for example, JSON response. But it can also be picked up by a JSF
> > lifecycle interceptor.
> >
> > I can commit the code which I have developped for a demo application that
> > uses it.
> >
> > WDYT?
> >
> > Regards
> > Rudy
>
Re: [Proposal] messages stored but not tied to JSF system.
Posted by "John D. Ament" <jo...@gmail.com>.
We face this issue as well, but more generally how to handle messaging
back to REST clients. For example, when we're not returning back a
200 OK we include some messages back for error handling to display to
the GUI what happened. These could be complex objects with
substitutions as well.
To do this, all of our POJOs back to the client extend from a base
class which can include these variables. It's then up to the client
to figure out how to render these messages.
What did you have in mind for consolidating?
On Mon, Oct 21, 2013 at 10:05 AM, Rudy De Busscher
<rd...@gmail.com> wrote:
> All,
>
> With the JsfMessage interface, you can add messages to the FacesContext so
> that they are displayed on screen the next rendering.
>
> But what if your CDI beans are used within a JSF context AND a REST
> context. When processing the REST request, there is no facesContext
> available and exceptions occur.
>
> My proposal is to have, aside the JsfMessage interface, a similar one,
> something like BusinessMessage, that works exactly the same but which
> doesn't store the message in FacesContext but in a custom ThreadLocal
> variable.
>
> Then the messages can be picked up by a REST interceptor and added to the,
> for example, JSON response. But it can also be picked up by a JSF
> lifecycle interceptor.
>
> I can commit the code which I have developped for a demo application that
> uses it.
>
> WDYT?
>
> Regards
> Rudy