Multiple TransactionListeners per application

[Artur Signell]

There is no method for finding existing TransactionListeners? from an ApplicationContext? (ie. getTransactionListeners()). If each Application instance registers an own listener all listeners will be called when a single HTTP request is made.

For me it is unclear why TransactionListeners? are Context dependent and not Application dependent. By having eg a map that maps Applications <-> TransactionListeners? a listener would only be called for the application it has been registered to. This would make much more sense to me as everything else is related to an Application.

Why would I ever want to know that the user has refreshed another Application on the same server? Using this for inter Application communication sounds dangerous. Could even be a security risk if server is configured to use same session for all applications (current default behaviour?) and different persons are managing different applications on the server.

[Joonas Lehtinen]

We should find the status in 5.1.0 and either fix this or list is as future improvement

[Jani Laakso]

I agree with your comments, inspecting..

[Jani Laakso]

Artur, please note that TransactionListener? code is not thread safe. Suggest you ensure that this issue does not cause any problems with your TK4 application. Typical scenario where e.g. concurrentModificationException could be thrown is on occasion where client requests two Toolkit resources paraller way, let say images, at the same time (Firefox opens two socket connections per host) => there's no code that is run inside synchronized block even though it is required.

[Jani Laakso]

Checked from Joonas: API is valid and works correctly. (side-note: it's not thread-safe though).

[Joonas Lehtinen]

• Security is not an issue here as all Application instances within one session are readable by the appilcation anyway
• getAllTransactionListeners() method would be a nice add-on, but is it really needed?
• Reason for giving this service on context level is to maintain separation between application and web. The purpose of this is to demote use of this function as the results will vary (a lot) depending on how the adapter evolves. This might be just an academic exercise, but on the other hand there is no pressing reasons for moving this to Application.
• Use-cases for listening requests to "some other" application might be sparse, but I would guess that I you can find use-case for using transaction listeners in the first place (please do not), then you might find a use-case or using them between multiple applications (controlled by you)

[Joonas Lehtinen]

Milestone User Interface Library 5.1.2 deleted