Bonjour, Comme je l'ai montré pendant la réunion dev, actuellement, et ce que j'avais compris de la gestion du multi contexte passait par l'implémentation d'un wikittyProxy qui encapsule deux wikitty proxy, un principal et un second dit fallback. Il s'avère que cette solution ne serait pas celle souhaitée/adéquate/optimisée. Donc la vraie solution serait une nouvelle implémentation de wikitty service, la grande question que je me pose, est comment le faire ? Les wikitty services sont instancié par une factory qui permet au différentes couches d'être correctement positionné dans la pile d'appel pour les services. Je suppose que du coup le multicontexte devrait se mettre dans la pile aussi un peu comme ça: wikitty.WikittyService.components=org.nuiton.wikitty.services.WikittyServiceStorage,\ org.nuiton.wikitty.services.WikittyServiceNotifier,\ org.nuiton.wikitty.services.WikittyServiceCached,\ org.nuiton.wikitty.services.WikittyServiceSecurity,\ org.nuiton.wikitty.services.WikittyServiceAccessStat,\ org.nuiton.wikitty.publication.WikittyServiceMultiContext Donc le service principal serait en dessous dans la pile, mais comment je fais pour le service fallback ? Dans le fichier property j'aurais une pile bis sous un autre nom que du coup le multiservice instanciera avec une factory ? par exemple : wikitty.fallback=org.nuiton.wikitty.services.WikittyServiceCajoClient Ou une autre solution ? Le service fallback pourra être statique si j'ai bien compris, on pourrait lire dessus, mais écrire seulement dans le principal ? Ca doit être une propriété qui change le comportement du service multicontexte ? Manoël
Bonjour, La solution à été trouvée et implémenté, le service fonctionne, le système de prefix permet un second service, comme suit dans l'exemple de properties: wikitty.service.server.url=http://localhost:1111/wikitty wikitty.WikittyService.components=\ org.nuiton.wikitty.services.WikittyServiceCajoClient,\ org.nuiton.wikitty.publication.WikittyPublicationFallbackService wikitty.fallback.prefix=fallback wikitty.fallback.wikitty.service.server.url=http://localhost:2222/wikitty wikitty.fallback.WikittyService.components=org.nuiton.wikitty.services.WikittyServiceCajoClient La propriété wikitty.fallback.prefix, permet à la classe WikittyPublicationFallbackService de demander à la WikittyServiceFactory d'instancier le bon fallback service (en utilisant donc le principe de prefix déjà présent dans la factory). Par contre un problème est apparut, c'est que le fallback service qui est un cajo client aussi, prend la même url que le mainService, puisque le constructeur cajo considère que le nom de la propriété pour l'adresse est : wikitty.service.server.url. Une solution que je vois, normalement pas très compliquée, serait que la factory réécrive les propriétés qui ont le prefix en amputant ce prefix, écrasant donc les propriétés du même nom précédemment enregistrées. Exemple en reprenant le même fichier de propriété, mais après "l'amputation" : wikitty.WikittyService.components=\ org.nuiton.wikitty.services.WikittyServiceCajoClient,\ org.nuiton.wikitty.publication.WikittyPublicationFallbackService wikitty.fallback.prefix=fallback wikitty.service.server.url=http://localhost:2222/wikitty wikitty.fallback.WikittyService.components=org.nuiton.wikitty.services.WikittyServiceCajoClient L'ancienne propriété donnant l'url a été écrasé par la "nouvelle" qui est celle du fallback mais amputé du prefix, ce qui va permettre au fallback de correctement s'instancier avec la bonne propriété. Eventuellement l'écrasement des propriétés ne devrait pas forcément se faire dans le même application config, mais un clone qui sera passé en paramètre des autres services. Cette solution pourrait permettre d'avoir des WikittyPublicationFallbackService qui contiennent d'autre WikittyPublicationFallbackService, quelque soit la nature des services finaux qu'ils contiendrons. Voilà, je ne sais pas si j'ai été très clair. A moins qu'il y ait une solution plus simple ou qui existe déjà, je pourrais évidement le gérer au niveau du WikittyPublicationFallbackService mais je pense pas que ce soit son rôle de gérer ça, lui n'est pas sensé connaitre ou déterminer la nature exact des services qui le composent. Manoël
participants (1)
-
Manoël Fortun