It has changed due to support for redirections and jobs in the console.
However, the assumption was already wrong with 4.0.x, for example:
*karaf*@root()> thread-name = { ((($.context bundle) loadClass
java.lang.Thread) currentThread) name }
((($.context bundle) loadClass java.lang.Thread) currentThread) name
*karaf*@root()> echo $(thread-name)
Karaf local console user karaf
*karaf*@root()> echo foo | echo $(thread-name)
pipe-[echo, $(thread-name)]
As you can see, in the second case, the thread is not the main one.
In Karaf 4.1.x, you can launch jobs in the background using the & operator,
or move them in the background at a later time using ^Z + fg. So jobs have
to be launched in a separate thread.
On the security side, the way to obtain the karaf user is to use the jaas
subject. It should be propagated throughout the session (though I just
found KARAF-5183). I think if you're using a InheritableThreadLocal, it
should almost work (though you'll have the same problems as described in
KARAF-5183 I suppose).
2017-06-07 16:45 GMT+02:00 Nicolas Brasey <[email protected]>:
> Hi guys!
>
> We are currently migrating from karaf 4.0.8 to 4.1.1 and discovered a new
> behavior in the shell. The new karaf does not dedicate a thread to the
> shell session, that means different commands in the same shell session
> might run in a different thread, which break our authentication mechanism
> which is maintained in a threadlocal.
>
> In the past, we never experienced karaf using different threads for
> executing different commands in the same shell session.
>
> So the question is: Is this change intentional from the Karaf team, or our
> assumption to have a single threaded session is wrong ?
>
> Thanks a lot!
>
> Nicolas
>
--
------------------------
Guillaume Nodet
