It turns out that the Thread.setName exception was thrown but wasn't the cause of the applet misbehaviour, the problem (when reconnecting to the server) was in the ExecutorThreadModel class, when it tries to create a new thread on it's internat ThreadFactory a SecurityException arose
A workaround for it was to change the client SocketConnectorConfig, as in: SocketConnector connector = new SocketConnector(); SocketConnectorConfig scc = new SocketConnectorConfig(); scc.setThreadModel(ThreadModel.MANUAL); connector.setDefaultConfig(scc); On 10/24/07, Andres Martinez Quijano <[EMAIL PROTECTED]> wrote: > Oook! I created the ThreadUtil class and refactored all the > Thread.setName invocations to use the new class. > > Attached is the patch (sorry for the absolute paths) > > Does this do or shall I create an issue in the tracker? > > On 10/24/07, Trustin Lee <[EMAIL PROTECTED]> wrote: > > On 10/24/07, Andres Martinez Quijano <[EMAIL PROTECTED]> wrote: > > > Hi > > > > > > I've noticed that in several places (Executors and Connectors) it is > > > called the method Thread.setName > > > > > > In an applet context (I'm developing multiplayer games) this is > > > forbidden by the sandbox, and a SecurityException arises. > > > > > > I haven't looked deeply into the code... is this naming thing for > > > logging purposes only or does it have another meaning? > > > > It is often helpful for a developer to analyze full thread dump. > > > > > Can it be configured so in applet contexts for instance threads > > > doesn't get renamed? Or maybe wrap the call within a try / catch > > > > > > If any of the answers is yes, I can modify it and supply a patch > > > > Yes. We could create a class 'org.apache.mina.util.ThreadUtil' and > > 'org.apache.mina.util.ThreadUtil.setName(Thread)' method, which wraps > > Thread.setName() with a try / catch block. Please go ahead! > >
