7 a.m.
As per https://issues.jboss.org/browse/GTNPORTAL-3257, when a failure
occurs after the REST request handler completes (i.e. JCR commit), the
response is still sent successfully to the client.
Wanted to get some feedback on this. From my perspective this is
something that should probably be handled by the RestServlet in eXo WS.
I don't think there's anything the actual REST service should do to
handle these scenarios. If we are in agreement I can create a JIRA with
eXo WS.
- Nick
7:42 a.m.
Why not simply calling session.save (what you mean by JCR commit) in your
rest component? No exception should be thrown by RequestLifeCycle.end()
On Tue, Sep 10, 2013 at 12:00 PM, Nick Scavelli <nscavell(a)redhat.com> wrote:
As per https://issues.jboss.org/browse/GTNPORTAL-3257, when a failure
occurs after the REST request handler completes (i.e. JCR commit), the
response is still sent successfully to the client.
Wanted to get some feedback on this. From my perspective this is something
that should probably be handled by the RestServlet in eXo WS. I don't think
there's anything the actual REST service should do to handle these
scenarios. If we are in agreement I can create a JIRA with eXo WS.
- Nick
_______________________________________________
gatein-dev mailing list
gatein-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/gatein-dev
8:28 a.m.
Yes I was going to add that this is what I would call a workaround. For
one you are assuming that my REST service knows about a JCR and that I
need to save/commit this session. Also anything else that might be done
during a RequestLifecycle.end() that might cause a failure and the
request to not complete successfully would have to be handled by the
rest service as well no ?
I also don't think this is how requests are handled by the portal
application either. I'm not sure what the exact solution is but I'm
assuming that the REST response should not be completed until the
RestServlet knows everything is finished.
On 09/10/2013 08:42 AM, Nicolas Filotto wrote:
Why not simply calling session.save (what you mean by JCR commit) in
your rest component? No exception should be thrown by
RequestLifeCycle.end()
On Tue, Sep 10, 2013 at 12:00 PM, Nick Scavelli <nscavell(a)redhat.com
<mailto:nscavell@redhat.com>> wrote:
As per https://issues.jboss.org/browse/GTNPORTAL-3257, when a
failure occurs after the REST request handler completes (i.e. JCR
commit), the response is still sent successfully to the client.
Wanted to get some feedback on this. From my perspective this is
something that should probably be handled by the RestServlet in
eXo WS. I don't think there's anything the actual REST service
should do to handle these scenarios. If we are in agreement I can
create a JIRA with eXo WS.
- Nick
_______________________________________________
gatein-dev mailing list
gatein-dev(a)lists.jboss.org <mailto:gatein-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/gatein-dev
3:47 p.m.
I think you are missing the point. If an exception is thrown from
RequestLifecycle.end() for whatever reason, the response is still
completed (flushed). The root cause of the exception is another subject
matter, which I think was a replication issue in EPP 5.2.
- Nick
On 09/10/2013 10:19 AM, Nicolas Filotto wrote:
What is the code of you Rest component and the stack trace ?
3:57 a.m.
What you don't understand is the fact RequestLifecycle.end() has not been
designed to throw any exception except IllegalStateException if you check
the signature of the method but this exception never occurs in practice, if
it occurs it means that RequestLifecycle.begin/RequestLifecycle.end were
not in a try/finally block which should never be the case.
So knowing that you can either
1. Throw a RuntimeException but if you do that it would mean that you
did not implement properly the method ComponentRequestLifecycle.endRequest
as no exception should be thrown from these methods.
2. You caught the exception inside your
method ComponentRequestLifecycle.endRequest, in that case we have no way to
know that it failed
The rest component sent a response code 200 because the code of your rest
component has been executed successfully which is true since the failure
occurred outside. It is your job to manage all the possible failures inside
your rest component to return the correct code and error message according
to the situation. Here is a good example
https://github.com/exodev/jcr/blob/master/exo.jcr.component.webdav/src/ma...,
this is our Webdav connector based on eXo WS as you can see we manage
ourself all the possible failures. It is what you are supposed to do.
On Tue, Sep 10, 2013 at 8:47 PM, Nick Scavelli <nscavell(a)redhat.com> wrote:
I think you are missing the point. If an exception is thrown from
RequestLifecycle.end() for whatever reason, the response is still completed
(flushed). The root cause of the exception is another subject matter, which
I think was a replication issue in EPP 5.2.
- Nick
On 09/10/2013 10:19 AM, Nicolas Filotto wrote:
> What is the code of you Rest component and the stack trace ?
>
9:43 a.m.
On 09/11/2013 04:57 AM, Nicolas Filotto wrote:
What you don't understand is the fact RequestLifecycle.end() has
not
been designed to throw any exception except IllegalStateException if
you check the signature of the method but this exception never occurs
in practice, if it occurs it means that
RequestLifecycle.begin/RequestLifecycle.end were not in a try/finally
block which should never be the case.
Ok I misspoke. RequestLifecycle.end() is not
throwing the exception but
the actual ComponentRequestLifecycle object (ChromatticManager in this
case) and the exception is returned in the map. But my point is still valid.
A REST component (or any component/service for that matter) should not
be responsible for errors that occur during a RequestLifecycle.end().
However I think it's a slightly larger issue as I can reproduce the same
scenario in the portal. For example I can add the byteman script
http://paste.fedoraproject.org/38733/37891033 and edit/save the
navigation and UI says the request was successful however the data was
not saved.
And before we have another "why don't you just save the session in the
component" discussion, I hope we can all see the larger/potential issue.
The question really is if it's a common enough scenario that is worth
addressing.
So knowing that you can either
1. Throw a RuntimeException but if you do that it would mean that you
did not implement properly the method
ComponentRequestLifecycle.endRequest as no exception should be
thrown from these methods.
2. You caught the exception inside your
method ComponentRequestLifecycle.endRequest, in that case we have
no way to know that it failed
The rest component sent a response code 200 because the code of your
rest component has been executed successfully which is true since the
failure occurred outside. It is your job to manage all the possible
failures inside your rest component to return the correct code and
error message according to the situation. Here is a good example
https://github.com/exodev/jcr/blob/master/exo.jcr.component.webdav/src/ma...,
this is our Webdav connector based on eXo WS as you can see we manage
ourself all the possible failures. It is what you are supposed to do.
Thanks for
the link but I know how to handled exceptions in my REST
component, or in general for that matter.
On Tue, Sep 10, 2013 at 8:47 PM, Nick Scavelli <nscavell(a)redhat.com
<mailto:nscavell@redhat.com>> wrote:
I think you are missing the point. If an exception is thrown from
RequestLifecycle.end() for whatever reason, the response is still
completed (flushed). The root cause of the exception is another
subject matter, which I think was a replication issue in EPP 5.2.
- Nick
On 09/10/2013 10:19 AM, Nicolas Filotto wrote:
What is the code of you Rest component and the stack trace ?
10:20 a.m.
I understand your point now, you are right RequestLifeCycle.end() doesn't
seem to be used properly everywhere as we never check if an exception has
been raised. Frankly speaking, I did not even realize that this method even
returns something as the return value is not even unit tested as far as I
can see in the kernel.
RequestLifeCycle.end() is called in many places in the code so if we
decided to change the logic to manage it "properly", it could be considered
as a massive behavior change so I don't thing that it is doable in a
maintenance branch but I guess it can be done in the future versions.
Feel free to create a JIRA issue in the eXo WS project, I will see what I
can do for eXo JCR 1.16.
Thanks for the feedback
8:32 a.m.
Yes this is a tricky one indeed (as this is used quite a bit in GateIn
code as well). I created a JIRA
https://jira.exoplatform.org/browse/WS-284 for it, so we can track for
the REST scenario.
On 09/11/2013 11:20 AM, Nicolas Filotto wrote:
I understand your point now, you are right RequestLifeCycle.end()
doesn't seem to be used properly everywhere as we never check if an
exception has been raised. Frankly speaking, I did not even realize
that this method even returns something as the return value is not
even unit tested as far as I can see in the kernel.
RequestLifeCycle.end() is called in many places in the code so if we
decided to change the logic to manage it "properly", it could be
considered as a massive behavior change so I don't thing that it is
doable in a maintenance branch but I guess it can be done in the
future versions.
Feel free to create a JIRA issue in the eXo WS project, I will see
what I can do for eXo JCR 1.16.
Thanks for the feedback
4086
days inactive
4099
days old
8 comments
2 participants
participants (2)
-
Nick Scavelli -
Nicolas Filotto