Hi
Following a more exhaustive review of f:websockets, I have found some
inconsistencies related to the way how a connection is specified.
Please note there is no mention of jsf.push.init(...) in the
javascript documentation, but the package jsf.push is there.
Here is an example:
<script type="text/javascript">
jsf.push.init(8080,'clock?1e4ac202-2b21-434f-8431-de5d5e4d37fe',
socketOpen,socketListener,socketClose,true);</script>
If you use "jsf" javascript package, every method there should be specified
without exceptions. I know this feature is a "work in progress" but I just
wanted to notice this fact.
Other thing to notice is there is a session token used to identify the
connection. This is something related to state management, so I was
expecting
a method inside ResponseStateManager, in the same way there is a method
there called:
public String getCryptographicallyStrongTokenFromSession(FacesContext
context)
to handle protected views. Something like:
public String
getCryptographicallyStrongTokenForWebsocketSession(FacesContext context)
It is only the token generation what we need here, not the websocket
session handling.
At last, there is a problem with passing params to assemble the url used
for the connection in the client. It has been a long standing policy in JSF
to generate urls on the server and pass them to the client. But in the
javascript documentation a new variable was added called:
jsf.contextpath
with description "... The result of calling
ExternalContext.getRequestContextPath(). ..."
It looks like something recently added, so I guess it should be something
related to jsf.push.init(...) script.
The problem here is there is no way for the server to override this path,
and in cases like portlets for example, it is necessary to provide a way
to override this part properly. So the url used to connect must be built
fully on the server and use the known ViewHandler - ExternalContext
pattern. Additionally, embed this variable in the js file breaks any
caching strategy. If the content is dynamic, embed it as an inline script,
but in this case it is better to avoid that.
regards,
Leonardo Uribe