¿Cómo puedo identificar en qué contexto de Java Applet se ejecuta sin pasar una ID?

Question

Formo parte de un equipo que desarrolla un gran applet de Swing Java. La mayor parte de nuestro código es heredado y hay toneladas de referencias singleton. Los agrupamos todos en un solo singleton "Contexto de aplicación". Lo que ahora necesitamos es crear una forma de separar el contexto compartido (compartido en todos los applets que se muestran actualmente) y el contexto no compartido (específico de cada applet que se muestra actualmente).

Sin embargo, no tenemos una identificación en cada una de las ubicaciones que llaman al singleton, ni queremos propagar la identificación a todas las ubicaciones. ¿Cuál es la forma más fácil de identificar en qué contexto de applet estamos ejecutando? (He intentado jugar con cargadores de clases, grupos de hilos, identificadores de subprocesos ... hasta ahora no pude encontrar nada que me permita identificar el origen de la llamada).

Answer 1

Los singleton son malvados, ¿qué esperas? ;)

Quizás el enfoque más completo sería cargar la mayor parte del applet en un cargador de clases diferente (use java.net.URLClassLoader.newInstance). Luego use un WeakHashMap para asociar el cargador de clases con un applet. Si pudieras dividir la mayor parte del código en un cargador de clases común (como padre de cada cargador de clases por applet) y en la base de código de applet normal, eso sería más rápido pero más trabajo.

Otros hacks:

Si usted tiene acceso a cualquiera de los componentes, se pueden utilizar repetidamente o Component.getParent SwingUtilities.getRoot.

Si se encuentra en un subproceso de instancia por subprograma, puede configurar un ThreadLocal.

Desde el EDT, puede leer el evento actual de la cola (java.awt.EventQueue.getCurrentEvent()), y posiblemente encuentre un componente de eso. Como alternativa, inserte un EventQueue con un método de evento dispatch reemplazado.

Answer 2

Si le entiendo correctamente, la idea es obtener un objeto "singleton" diferente para cada objeto llamante o "contexto". Una cosa que puede hacer es crear una variable global local de subprocesos donde escriba la ID del contexto actual. (Esto se puede hacer con AOP). Luego, en el captador de singleton, la ID de contexto se extrae del hilo local para usarla como clave para la instancia de "singleton" correcta para el contexto de llamada.

En cuanto a AOP no debería haber ningún problema al utilizarlo en applets ya que, dependiendo de sus cortes de punto, los consejos se tejen en tiempo de compilación y se agrega un JAR a las dependencias de tiempo de ejecución. Por lo tanto, ninguna evidencia especial de AOP debe permanecer en tiempo de ejecución.

Answer 3

@Hugo respecto ThreadLocal:

pensé en esa solución. Sin embargo, de los experimentos encontré dos problemas con ese enfoque:

1. El hilo compartido (conexiones de servidor, etc.) es problemático. Sin embargo, esto se puede resolver prestando especial atención a estos hilos (todos están bajo mi control y están bastante aislados del código heredado).
2. El hilo EDT se comparte en todos los applets. No pude encontrar una manera de forzar la creación de un nuevo hilo EDT para cada applet. Esto significa que el threadlocal para el EDT se compartiría entre los applets. Este no tengo idea de cómo resolverlo. Sugerencias?