eventbusbridge: onclose serverside

[stefa_n]

Hi,

there seems to be no way that the server can detect a closing connection

or did I miss sth.?

[Joern Bernhardt]

I made a pull request for that, but I didn't receive any comments for it yet..

https://github.com/vert-x/vert.x/pull/241

[Tim Fox]

I'd like to get this functionality in, but I need to look at it closely because it involves API changes.

Also, since it includes API changes, it would also need to be implemented in JS/Ruby/Groovy/Python and docs would need to be updated. The current pull request only contains Java changes and no docs changes.

[Joern Bernhardt]

I guess you also want some tests written for it. I'm not sure, how to do that yet, but hopefully I have some time to learn that next week.
I won't be able to deliver wrappers for Ruby/Groovy/Python, since I'm not very familiar with those languages. Reading is ok, but writing... And no one wants to have bad designed APIs...

If anyone wants to help to get this done quicker, feel free to improve - I won't be able to deliver more than tests, docs and JS-wrapper before end of next week.

[Joern Bernhardt]

The documentation about the Java part is done and I created a separate pull request over here: https://github.com/vert-x/vert.x/pull/319

Developing the JS API doesn't seem very straight forward actually, as I haven't used Rhino yet, only plain javascript without Java integration. I don't know how fast I can accomplish that...

I also couldn't find any tests of the SockJS server/bridge... Am I missing them somewhere? My only idea was to use some kind of base SockJS client for the tests, but since I cannot find something like that in the tests, I have to admit I don't really have a clue how to write a test for that part... Any ideas?

[Tim Fox]

Hi Joern,

On 09/08/2012 22:20, Joern Bernhardt wrote:

The documentation about the Java part is done and I created a separate pull request over here: https://github.com/vert-x/vert.x/pull/319

Thanks, will take a look.

Developing the JS API doesn't seem very straight forward actually, as I haven't used Rhino yet, only plain javascript without Java integration. I don't know how fast I can accomplish that...

I can help you with that.

I also couldn't find any tests of the SockJS server/bridge... Am I missing them somewhere? My only idea was to use some kind of base SockJS client for the tests, but since I cannot find something like that in the tests, I have to admit I don't really have a clue how to write a test for that part... Any ideas?

The SockJS server is not currently tested as part of the test suite, but is manually tested by running the SockJS client and protocol tests against it before any release. We also have a few examples which use the event bus bridge functionality, which are validated before every release so they act as manual tests too.

Ideally we should integrate these as part of the test suite, although integrating end-end tests which involve a browser would be tricky (any suggestions?)

On Friday, August 3, 2012 1:22:04 PM UTC+2, Joern Bernhardt wrote:

I guess you also want some tests written for it. I'm not sure, how to do that yet, but hopefully I have some time to learn that next week.
I won't be able to deliver wrappers for Ruby/Groovy/Python, since I'm not very familiar with those languages. Reading is ok, but writing... And no one wants to have bad designed APIs...

If anyone wants to help to get this done quicker, feel free to improve - I won't be able to deliver more than tests, docs and JS-wrapper before end of next week.


On Thursday, August 2, 2012 2:26:09 PM UTC+2, Tim Fox wrote:

I'd like to get this functionality in, but I need to look at it closely because it involves API changes.

Also, since it includes API changes, it would also need to be implemented in JS/Ruby/Groovy/Python and docs would need to be updated. The current pull request only contains Java changes and no docs changes.

On Thursday, August 2, 2012 9:21:23 AM UTC+1, Joern Bernhardt wrote:

I made a pull request for that, but I didn't receive any comments for it yet..

https://github.com/vert-x/vert.x/pull/241

On Thursday, August 2, 2012 9:43:58 AM UTC+2, stefa_n wrote:

Hi,

there seems to be no way that the server can detect a closing connection

or did I miss sth.?

--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To view this discussion on the web, visit https://groups.google.com/d/msg/vertx/-/CK6ssLHzQCAJ.
To post to this group, send an email to ve...@googlegroups.com.
To unsubscribe from this group, send email to vertx+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/vertx?hl=en-GB.

[Tim Fox]

On 10/08/2012 08:20, Tim Fox wrote:

Hi Joern,

On 09/08/2012 22:20, Joern Bernhardt wrote:

The documentation about the Java part is done and I created a separate pull request over here: https://github.com/vert-x/vert.x/pull/319

Thanks, will take a look.

Developing the JS API doesn't seem very straight forward actually, as I haven't used Rhino yet, only plain javascript without Java integration. I don't know how fast I can accomplish that...

I can help you with that.

I also couldn't find any tests of the SockJS server/bridge... Am I missing them somewhere? My only idea was to use some kind of base SockJS client for the tests, but since I cannot find something like that in the tests, I have to admit I don't really have a clue how to write a test for that part... Any ideas?

The SockJS server is not currently tested as part of the test suite, but is manually tested by running the SockJS client and protocol tests against it before any release. We also have a few examples which use the event bus bridge functionality, which are validated before every release so they act as manual tests too.

For now, I would recommend creating new examples which demonstrate the new functionality, it's better than nothing.

[Joern Bernhardt]

Hi Tim,

On Friday, August 10, 2012 9:22:16 AM UTC+2, Tim Fox wrote:

On 10/08/2012 08:20, Tim Fox wrote:

Hi Joern,

On 09/08/2012 22:20, Joern Bernhardt wrote:

The documentation about the Java part is done and I created a separate pull request over here: https://github.com/vert-x/vert.x/pull/319

Thanks, will take a look.

Developing the JS API doesn't seem very straight forward actually, as I haven't used Rhino yet, only plain javascript without Java integration. I don't know how fast I can accomplish that...

I can help you with that.

Thanks, maybe I'll need that :)
 

I also couldn't find any tests of the SockJS server/bridge... Am I missing them somewhere? My only idea was to use some kind of base SockJS client for the tests, but since I cannot find something like that in the tests, I have to admit I don't really have a clue how to write a test for that part... Any ideas?

The SockJS server is not currently tested as part of the test suite, but is manually tested by running the SockJS client and protocol tests against it before any release. We also have a few examples which use the event bus bridge functionality, which are validated before every release so they act as manual tests too.

For now, I would recommend creating new examples which demonstrate the new functionality, it's better than nothing.

I'll set up a little example application. If I can't make a JS example run, I'll ask here again.

[Joern Bernhardt]

Hi Tim,

both pull requests are updated now.

https://github.com/vert-x/vert.x/pull/241
https://github.com/vert-x/vert.x/pull/319

I've added a javascript example and everything seemed to work.

So there should be now: The Java implementation+documentation, Java manual documentation, JavaScript wrapper, JavaScript manual documentation, JavaScript example+documentation in the README file and the build.gradle was changed to provide vertxbus.js in the JS-example.

Is there anything more needed? As you suggested, I provided an example app - I don't know a way how tests could be written against it without some kind of browser base...

Side note: In the docs authTimeout and authAddress as options for the SockJSServer.bridge() function are not really mentioned that you can use them.

Joern