You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by "Martin Grigorov (JIRA)" <ji...@apache.org> on 2014/06/24 15:17:25 UTC

[jira] [Commented] (WICKET-5627) broadcastMessage(): hook to set more thread-local context before rendering components

    [ https://issues.apache.org/jira/browse/WICKET-5627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14042087#comment-14042087 ] 

Martin Grigorov commented on WICKET-5627:
-----------------------------------------

I think it would be better to use the IWebSocketSettings to add an additional executor.
So the code would be something like:
{code}
private void sendPayload(final WebSocketPayload payload, final Page page)
	{
		IWebSocketSettings webSocketSettings = IWebSocketSettings.Holder.get(application);
		webSocketSettings.getSendPayloadExecutor().run(new Runnable()
		{
			@Override
			public void run()
			{
				if (pageId != NO_PAGE_ID)
				{
					page.send(application, Broadcast.BREADTH, payload);
				}
				else
				{
					ResourceReference reference = new SharedResourceReference(resourceName);
					IResource resource = reference.getResource();
					if (resource instanceof WebSocketResource)
					{
						WebSocketResource wsResource = (WebSocketResource) resource;
						wsResource.onPayload(payload);
					}
					else
					{
						throw new IllegalStateException(
								String.format("Shared resource with name '%s' is not a %s but %s",
										resourceName, WebSocketResource.class.getSimpleName(),
										Classes.name(resource.getClass())));
					}
				}
			}
		});
	}
{code}

The default impl will just do: runnable.run().
Your impl could do anything before and/or after running the runnable.
The main problem is that Native WebSocket module because non-experimental few releases ago and now it is not allowed to add new methods to IWebSocketSettings interface ... :-/

My usual workaround for this kind problem is to add the new method only to the impl (WebSocketSettings) and add some checks before using it. I.e. the new method will be used only if IWebSocketSettings.Holder.get(application) returns an instance of WebSocketSettings.

If there is no better idea and no one objects against the workaround then I'll implement it for 6.17.0.

> broadcastMessage(): hook to set more thread-local context before rendering components
> -------------------------------------------------------------------------------------
>
>                 Key: WICKET-5627
>                 URL: https://issues.apache.org/jira/browse/WICKET-5627
>             Project: Wicket
>          Issue Type: Improvement
>          Components: wicket-native-websocket
>    Affects Versions: 6.16.0
>            Reporter: Andrei Badea
>            Assignee: Martin Grigorov
>         Attachments: proof-of-concept.diff
>
>
> Our application uses Spring Security for authentication and authorization. We want to push rendered components to clients via WebSocketRequestHandler.add().
> The problem we are hitting is that (at least) the component rendering needs to take place in the (Spring Security) context of the user to whom the component "belongs". Effectively, next to the ThreadContext.set... calls in AbstractWebSocketProcessor.broadcastMessage(), we would like to call SecurityContextHolder.setContext(). To do that, we would need some sort of hook that is invoked before sendPayload() is called.
> I am happy to provide a patch, but would rather discuss the approach first. For instance, if this hook is simply an overridable method such as AWSP.broadcastMessageToPage() in the attached proof of concept, it would be fairly invasive to use from the Wicket user's perspective. The user would have to:
> * subclass the respective AbstractWebSocketProcessor server-specific subclass
> * subclass the respective server-specific web filter
> * in the filter, override a (newly introduced) newWebSocketProcessor() method to return the custom AbstractWebSocketProcessor subclass
> Do you see a better way, or perhaps more in line with the direction you want to take Wicket's WebSocket API?



--
This message was sent by Atlassian JIRA
(v6.2#6252)