Comment puis-je identifier dans quel contexte d'applet Java s'exécute sans transmettre d'ID ?

Question

Je fais partie d'une équipe qui développe une assez grosse applet Java Swing.La plupart de notre code est hérité et il existe des tonnes de références singleton.Nous les avons tous regroupés dans un seul singleton « Application Context ».Ce dont nous avons maintenant besoin, c'est de créer un moyen de séparer le contexte partagé (partagé entre toutes les applets actuellement affichées) et le contexte non partagé (spécifique à chaque applet actuellement affichée).

Cependant, nous n'avons pas d'identifiant à chacun des emplacements qui appellent le singleton, et nous ne souhaitons pas non plus propager l'identifiant à tous les emplacements.Quelle est la manière la plus simple d'identifier dans quel contexte d'applet nous exécutons ?(J'ai essayé de jouer avec les chargeurs de classe, les groupes de threads, les identifiants de thread...jusqu'à présent, je n'ai rien trouvé qui me permette d'identifier l'origine de l'appel).

Answer 1

Les célibataires sont mauvais, à quoi vous attendez-vous ?;)

L'approche la plus complète serait peut-être de charger la majeure partie de l'applet dans un autre chargeur de classe (utilisez java.net.URLClassLoader.newInstance).Utilisez ensuite un WeakHashMap pour associer le chargeur de classe à une applet.Si vous pouviez diviser la majeure partie du code en un chargeur de classe commun (en tant que parent de chaque chargeur de classe par applet) et dans la base de code normale de l'applet, ce serait plus rapide mais plus de travail.

Autres astuces :

Si vous avez accès à un composant, vous pouvez utiliser Component.getParent à plusieurs reprises ou SwingUtilities.getRoot.

Si vous êtes dans un thread d'instance par applet, vous pouvez configurer un ThreadLocal.

À partir de l'EDT, vous pouvez lire l'événement en cours dans la file d'attente (java.awt.EventQueue.getCurrentEvent()) et éventuellement en trouver un composant.Vous pouvez également envoyer une EventQueue avec une méthode dispatchEvent remplacée.

Answer 2

Si je vous comprends bien, l'idée est d'obtenir un objet "singleton" différent pour chaque objet appelant ou "contexte".Une chose que vous pouvez faire est de créer une variable globale locale du thread dans laquelle vous écrivez l'ID du contexte actuel.(Cela peut être fait avec AOP.) Ensuite, dans le getter singleton, l'ID de contexte est récupéré du thread local pour être utilisé comme clé de l'instance "singleton" correcte pour le contexte appelant.

Concernant AOP il ne devrait y avoir aucun problème à l'utiliser dans les applets puisque, en fonction de vos points de coupe, les conseils sont tissés à la compilation et un JAR est ajouté aux dépendances d'exécution.Par conséquent, aucune preuve particulière de l'AOP ne devrait subsister au moment de l'exécution.

Answer 3

@Hugo concernant threadlocal :

J'ai réfléchi à cette solution.Cependant, à partir d'expériences, j'ai trouvé deux problèmes avec cette approche :

1. Les threads partagés (connexions au serveur, etc.) posent problème.Cela peut cependant être résolu en accordant une attention particulière à ces threads (ils sont tous sous mon contrôle et sont à peu près isolés du code existant).
2. Le fil EDT est partagé entre toutes les applets.Je n'ai pas réussi à trouver un moyen de forcer la création d'un nouveau thread EDT pour chaque applet.Cela signifie que le threadlocal de l'EDT serait partagé entre les applets.Celui-ci, je ne sais pas comment le résoudre.Suggestions?