Improved the documentation in rev. 1735441
Jacopo
On Thu, Mar 17, 2016 at 11:17 AM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:
> +1, thanks Scott for the idea and explanation!
>
> Jacques
>
>
> Le 17/03/2016 10:51, Jacopo Cappellato a écrit :
>
>> Thanks to all of you for your valuab
+1, thanks Scott for the idea and explanation!
Jacques
Le 17/03/2016 10:51, Jacopo Cappellato a écrit :
Thanks to all of you for your valuable feedback.
For now we could, as recommended by Scott, improve the documentation to
make it clear when and how the auth and in-validate events can safely
Thanks to all of you for your valuable feedback.
For now we could, as recommended by Scott, improve the documentation to
make it clear when and how the auth and in-validate events can safely be
used(i.e. to call services that don't change the status of any system).
Regards,
Jacopo
On Tue, Feb 2
I've been aware of this for a while and always assumed that the intention
was for the auth and in-validate events to only use idempotent services
that exist to validate the service call. I don't mind if we remove them
for async calls but we do lose the feature that the caller is immediately
notifi
This issue is exactly the reason why the refactoring thread issued by
Sharan is important. Quite honestly looking at that code gave me sore eyes
and the whole thing needs refactoring. Sorry to deviate.
Anyway I think we all sort of agree on the solution.
Taher Alkhateeb
On Feb 23, 2016 2:02 PM, "
Yes exactly my thoughts: it could be a C/P error, but it's still weird. Maybe a
refactoring was done at some point and this was forgotten.
Note: this code is pre Apache era
Jacques
Le 23/02/2016 11:46, Jacopo Cappellato a écrit :
Jacques,
the code that runs pre-invoke in runSync is quite dif
Jacques,
the code that runs pre-invoke in runSync is quite different from the code
in runAsync; on the other hand the first parts of the two methods in very
similar.
Jacopo
On Tue, Feb 23, 2016 at 11:13 AM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:
> Yes, but then why only those ca
Yes, but then why only those cases? And why not pre-invoke for instance?
Jacques
Le 23/02/2016 10:35, gil portenseigne a écrit :
Hi Taher,
The only thing i can see around this matter is if the seca fail during invoke,
no job is created ?
My 0,02 cts
Gil
On 23/02/2016 10:27, Taher Alkhateeb
Taher,
yours are all valid questions and I don't have a precise answer for them:
it may be that it was done by design (as Gil said for example to allow the
creation in the queue of "valid" jobs only) or just for a copy/paste
pattern...
Jacopo
On Tue, Feb 23, 2016 at 10:35 AM, gil portenseigne <
Hi Taher,
The only thing i can see around this matter is if the seca fail during
invoke, no job is created ?
My 0,02 cts
Gil
On 23/02/2016 10:27, Taher Alkhateeb wrote:
Hi Jacopo,
So to understand correctly, you want to disable all SECA executions
(triggered by evalRules) when the call hap
Hi Jacopo,
So to understand correctly, you want to disable all SECA executions
(triggered by evalRules) when the call happens to runAsync.
Any idea why it was there in the first place? It seems strange to have such
a flaw in the design deep in the service engine. If an async service
eventually tr
Hi Taher,
yes you are in the right place: the proposal is to remove, from the
ServiceDispatcher.runAsync method, the code following the two comments:
// pre-auth ECA
and
// pre-validate ECA
Jacopo
On Tue, Feb 23, 2016 at 7:10 AM, Taher Alkhateeb wrote:
> Hi Jacopo,
>
> I'm trying to find wh
Hi Jacopo,
I'm trying to find where the logic described above is happening, am I in
the right place at ServiceDispatcher on the runAsync method right next to
the checking of pre-auth ECA rules?
Taher Alkhateeb
On Mon, Feb 22, 2016 at 5:45 PM, Jacopo Cappellato <
jacopo.cappell...@hotwaxsystems.c
On 22/02/2016 15:45, Jacopo Cappellato wrote:
[...]
Proposed fix: we could simply remove the execution of "auth" and
"in-validate" secas when the async service is invoked, and defer their
execution at the time the service is actually executed (i.e. picked from
the queue and run).
Any comments?
Hi all,
I am sharing here the result of an analysis that Nameet Jain and I did to
figure out why, under some circumstances the same seca service was executed
twice.
The problem is that, when a service is executed as "async" the secas
attached to the "auth" and "in-validate" events are executed tw
15 matches
Mail list logo
