XPages: Observer and Observable

2
votes

I've been trying to use Java Observer and Observable in a multi-user XPages application, but I'm running into identity conflicts. I'll explain.

Say A and B have the same view on their screens, a list of documents with Readers fields. We want to keep those screens synchronised as much as possible. If A changes something, B might be receiving updates, depending on his rights and roles. We achieved to do this using WebSockets, but I want to see if there's a better way, i.e. without send a message to the client telling it to re-fetch the screen.

Using the Observer mechanism, B can observe changes and push the changed screen to the user. The tricky part here is that if I call notifyObservers as user A, and I walk through all the observables, A will be executing the Observer.update() method, and not B.

I also thought of using a Timer-like solution, but I'd probably end up with the same conflicts.

Question: is there any way I can properly switch sessions in XPages? Or should I wait for Publish/Subscribe in the XPages server?

1
javaxpages
I would love to see a blog post on your websockets solution 😀 - Per Henrik Lausten
Hehe, I could do that indeed... just to give a few quick hints: Redis, Jedis, socket.io, node.js, server-client comm only. Credits to Andrew Hook (his website has vanished, no idea why). - D.Bugger
stomp with/over sock-js would also solve your problem, but indirectly it also uses websockets - Kumar Ashutosh

1 Answers

1
votes

I can see 3 possible actions:

  • Use the SudoUtils from XPages-Scaffolding to run code on behalf
  • Use DominoJNA to access the data with a different user id (not for the faint of heart)
  • Just notify the client using the websocket - preferably via webworker. It then would make a fetch (the artist formerly known as Ajax) to see if changes are needed in the client UI. While this has the disadvantage of incurring a network interlude (websocket + fetch) it has the advantage that you don't need to mess with impersonisation which always carries the risk of something going wrong.

For the first two I would want to pack them into an OSGi bundle to be independent from the particularities of Java loaded from an NSF

Old answer

Your observer needs to be in an application context, so you can update any Observer. The observer then would use a websocket to the client to tell it: update this ONE record. The tricky part, needs planning: have individual websocket addresses, so you notify only the ones that need notification