WW-4900 Makes BackgroundProcess transient #191
Conversation
| @@ -44,9 +45,8 @@ | |||
| * @param invocation The action invocation | |||
| * @param threadPriority The thread priority | |||
| */ | |||
| public BackgroundProcess(String threadName, final ActionInvocation invocation, int threadPriority) { | |||
| BackgroundProcess(String threadName, final ActionInvocation invocation, int threadPriority) { | |||
There was a problem hiding this comment.
In such case you are reducing re-usability of this class in other interceptors, user will have to copy this class if she wants to re-implement the interceptor
There was a problem hiding this comment.
Thanks 👍 I did not know user may want. fixed :)
There was a problem hiding this comment.
Yeah... this is a bit different than development of a normal app. This a framework that should be easily extendable by users and quite often we need to break good practices (like reducing scope) because users would like to use it. You wasn't the first one who did that ;-)
| @@ -75,7 +75,7 @@ public void run() { | |||
| * | |||
| * @throws Exception any exception thrown will be thrown, in turn, by the ExecuteAndWaitInterceptor | |||
| */ | |||
| protected void beforeInvocation() throws Exception { | |||
| private void beforeInvocation() throws Exception { | |||
There was a problem hiding this comment.
Reducing scope can affect users and blocks adding other implementations.
There was a problem hiding this comment.
Thanks 👍 . fixed :)
| @@ -86,7 +86,7 @@ protected void beforeInvocation() throws Exception { | |||
| * | |||
| * @throws Exception any exception thrown will be thrown, in turn, by the ExecuteAndWaitInterceptor | |||
| */ | |||
| protected void afterInvocation() throws Exception { | |||
| private void afterInvocation() throws Exception { | |||
There was a problem hiding this comment.
Same here, using protected allows users re-implementing this class easily
There was a problem hiding this comment.
Thanks 👍 . fixed :)
|
|
|
Was a good catch by junit 👍 I should have wait for background thread. fixed. thanks! |
|
Let's rock 👍 |
|
I think so , such huge object in session is too bad |
|
@tiztm , AFAIK token is just a simple string and shouldn't have any problem with serialize then de-serialize. Or maybe I didn't get something? |
Currently we won't support exec and wait from de-serialized session and maybe add this support some day on user demand. Why I think to drop such support? It's not a good practice to try serializing such large or variant unpredictable objects like action and invocation (CWE-579: J2EE Bad Practices: Non-serializable Object Stored in Session).