Bokeh running with GWT and tomcat

Community Support
1

We have a GWT application hosted on Apache tomcat that talks to a back end engine using SOAP / WSDL. We now need to add some fancy graphics / visualisations as to the state of our system (number or records processed, errors, etc.).

The web-browser, tomcat and engine all run on different computers, but all running windows.

One obvious way to do this would be to have an iframe that loads a page from the Bokeh server, possibly with tomcat acting as a front-end.

However, I would like to avoid having yet another service running that needs to be installed. Is it possible to compile bokeh using jython, and run it as a Tomcat application?

Simon

2

AFAIK you would be the first person to ever suggest compiling Bokeh using jython. My guess, based on the fact that Bokeh heavily uses meta-classes, NumPy, etc., is that this would probably not be successful. However, I actually have no direct experience with jython, so perhaps it is more capable than I assume. If you do try it, please report back what you find, for the benefit of others.

Thanks,

Bryan

···

On Aug 3, 2016, at 8:49 AM, Simon Callan <[email protected]> wrote:

We have a GWT application hosted on Apache tomcat that talks to a back end engine using SOAP / WSDL. We now need to add some fancy graphics / visualisations as to the state of our system (number or records processed, errors, etc.).

The web-browser, tomcat and engine all run on different computers, but all running windows.

One obvious way to do this would be to have an iframe that loads a page from the Bokeh server, possibly with tomcat acting as a front-end.

However, I would like to avoid having yet another service running that needs to be installed. Is it possible to compile bokeh using jython, and run it as a Tomcat application?

Simon

--
You received this message because you are subscribed to the Google Groups "Bokeh Discussion - Public" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/6301d7cf-0783-4048-af53-7648f2454481%40continuum.io\.
For more options, visit https://groups.google.com/a/continuum.io/d/optout\.

3

Actually, there is no reason why Bokeh shouldn’t work with Jython, as long as you stay away from the stuff that uses pandas/numpy.

The core logic and all the metaclasses and whatnot should work just fine with Jython.

···

On Wed, Aug 3, 2016 at 10:42 AM, Bryan Van de Ven [email protected] wrote:

AFAIK you would be the first person to ever suggest compiling Bokeh using jython. My guess, based on the fact that Bokeh heavily uses meta-classes, NumPy, etc., is that this would probably not be successful. However, I actually have no direct experience with jython, so perhaps it is more capable than I assume. If you do try it, please report back what you find, for the benefit of others.

Thanks,

Bryan

On Aug 3, 2016, at 8:49 AM, Simon Callan [email protected] wrote:

We have a GWT application hosted on Apache tomcat that talks to a back end engine using SOAP / WSDL. We now need to add some fancy graphics / visualisations as to the state of our system (number or records processed, errors, etc.).

The web-browser, tomcat and engine all run on different computers, but all running windows.

One obvious way to do this would be to have an iframe that loads a page from the Bokeh server, possibly with tomcat acting as a front-end.

However, I would like to avoid having yet another service running that needs to be installed. Is it possible to compile bokeh using jython, and run it as a Tomcat application?

Simon

–

You received this message because you are subscribed to the Google Groups “Bokeh Discussion - Public” group.

To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].

To post to this group, send email to [email protected].

To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/6301d7cf-0783-4048-af53-7648f2454481%40continuum.io.

For more options, visit https://groups.google.com/a/continuum.io/d/optout.

–

You received this message because you are subscribed to the Google Groups “Bokeh Discussion - Public” group.

To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].

To post to this group, send email to [email protected].

To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/27508E79-3681-430F-88B7-E591411FC675%40continuum.io.
For more options, visit https://groups.google.com/a/continuum.io/d/optout.

–

Peter Wang

CTO, Co-founder

4

This is roughly what I was expecting. I don’t think that we will be doing anything that requires numpy or any other non-pure-python code.

However,I suspect that getting bokeh to run under Tomcat may be the issue. It’s going to have its own opinion as to how network communications are done, and it may be necessary to strip out the Tornado web framework, and replace it with a wsgi (?) style interface.

It may not be worth the effort, compared to that required to get the python server running on windows, though Tornado does say that it is not recommended to run non-development code on windows.

···

On Wednesday, 3 August 2016 21:50:51 UTC+1, pwang wrote:

Actually, there is no reason why Bokeh shouldn’t work with Jython, as long as you stay away from the stuff that uses pandas/numpy.

The core logic and all the metaclasses and whatnot should work just fine with Jython.

On Wed, Aug 3, 2016 at 10:42 AM, Bryan Van de Ven [email protected] wrote:

AFAIK you would be the first person to ever suggest compiling Bokeh using jython. My guess, based on the fact that Bokeh heavily uses meta-classes, NumPy, etc., is that this would probably not be successful. However, I actually have no direct experience with jython, so perhaps it is more capable than I assume. If you do try it, please report back what you find, for the benefit of others.

Thanks,

Bryan

On Aug 3, 2016, at 8:49 AM, Simon Callan [email protected] wrote:

We have a GWT application hosted on Apache tomcat that talks to a back end engine using SOAP / WSDL. We now need to add some fancy graphics / visualisations as to the state of our system (number or records processed, errors, etc.).

The web-browser, tomcat and engine all run on different computers, but all running windows.

One obvious way to do this would be to have an iframe that loads a page from the Bokeh server, possibly with tomcat acting as a front-end.

However, I would like to avoid having yet another service running that needs to be installed. Is it possible to compile bokeh using jython, and run it as a Tomcat application?

Simon

5

The Bokeh wire protocol is fundamentally a websocket protocol. There's no way to re-tool the server to have a WSGI interface that would not also requiring having a drastically patched and custom BokehJS version as well. I'm not even sure it's possible in principle, without losing functionality. The old server didn't use websockets, and properly and easily synchronizing bidrectional updates was one of its primary shortcomings.

Bryan

···

On Aug 4, 2016, at 5:07 AM, Simon Callan <[email protected]> wrote:

This is roughly what I was expecting. I don't think that we will be doing anything that requires numpy or any other non-pure-python code.

However,I suspect that getting bokeh to run under Tomcat may be the issue. It's going to have its own opinion as to how network communications are done, and it may be necessary to strip out the Tornado web framework, and replace it with a wsgi (?) style interface.

It may not be worth the effort, compared to that required to get the python server running on windows, though Tornado does say that it is not recommended to run non-development code on windows.

On Wednesday, 3 August 2016 21:50:51 UTC+1, pwang wrote:
Actually, there is no reason why Bokeh shouldn't work with Jython, as long as you stay away from the stuff that uses pandas/numpy.

The core logic and all the metaclasses and whatnot should work just fine with Jython.

On Wed, Aug 3, 2016 at 10:42 AM, Bryan Van de Ven <[email protected]> wrote:
AFAIK you would be the first person to ever suggest compiling Bokeh using jython. My guess, based on the fact that Bokeh heavily uses meta-classes, NumPy, etc., is that this would probably not be successful. However, I actually have no direct experience with jython, so perhaps it is more capable than I assume. If you do try it, please report back what you find, for the benefit of others.

Thanks,

Bryan

> On Aug 3, 2016, at 8:49 AM, Simon Callan <[email protected]> wrote:
>
> We have a GWT application hosted on Apache tomcat that talks to a back end engine using SOAP / WSDL. We now need to add some fancy graphics / visualisations as to the state of our system (number or records processed, errors, etc.).
>
> The web-browser, tomcat and engine all run on different computers, but all running windows.
>
> One obvious way to do this would be to have an iframe that loads a page from the Bokeh server, possibly with tomcat acting as a front-end.
>
> However, I would like to avoid having yet another service running that needs to be installed. Is it possible to compile bokeh using jython, and run it as a Tomcat application?
>
> Simon

--
You received this message because you are subscribed to the Google Groups "Bokeh Discussion - Public" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/0a8782c8-dde1-457a-972b-21b4dd4ef3ed%40continuum.io\.
For more options, visit https://groups.google.com/a/continuum.io/d/optout\.

6

OK, I was wrong about WSGI. What I meant was replace the Tornado interface by something that tomcat supports.

It appears that Tomcat does support websockets, though as to how close to what bokeh needs this would be, I have no idea.

I think I’ll put this on the back-burner for when I’m feeling bored.

···

On Thursday, 4 August 2016 12:30:06 UTC+1, Bryan Van de ven wrote:

The Bokeh wire protocol is fundamentally a websocket protocol. There’s no way to re-tool the server to have a WSGI interface that would not also requiring having a drastically patched and custom BokehJS version as well. I’m not even sure it’s possible in principle, without losing functionality. The old server didn’t use websockets, and properly and easily synchronizing bidrectional updates was one of its primary shortcomings.

7

FWIW I don't mean to be completely discouraging. If you are looking for a serious project, then certainly we'd be happy to answer any questions we can. Just want to make it clear that porting off Tornado would definitely be a non-trivial effort.

Thanks,

Bryan

···

On Aug 4, 2016, at 7:19 AM, Simon Callan <[email protected]> wrote:

OK, I was wrong about WSGI. What I meant was replace the Tornado interface by something that tomcat supports.

It appears that Tomcat does support websockets, though as to how close to what bokeh needs this would be, I have no idea.

I think I'll put this on the back-burner for when I'm feeling bored.

On Thursday, 4 August 2016 12:30:06 UTC+1, Bryan Van de ven wrote:
The Bokeh wire protocol is fundamentally a websocket protocol. There's no way to re-tool the server to have a WSGI interface that would not also requiring having a drastically patched and custom BokehJS version as well. I'm not even sure it's possible in principle, without losing functionality. The old server didn't use websockets, and properly and easily synchronizing bidrectional updates was one of its primary shortcomings.

--
You received this message because you are subscribed to the Google Groups "Bokeh Discussion - Public" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/d846d762-852a-465a-9f6e-95cc6b394ef8%40continuum.io\.
For more options, visit https://groups.google.com/a/continuum.io/d/optout\.

8

The major issue is that this would be for work, and I don;t think that we could justify the time it would require, when we already have most of the infrastructure already present.

However, I will keep it in mind for when I want something serious to play with.

Simon

···

On Thursday, 4 August 2016 14:29:07 UTC+1, Bryan Van de ven wrote:

FWIW I don’t mean to be completely discouraging. If you are looking for a serious project, then certainly we’d be happy to answer any questions we can. Just want to make it clear that porting off Tornado would definitely be a non-trivial effort.

Thanks,

Bryan

On Aug 4, 2016, at 7:19 AM, Simon Callan [email protected] wrote:

OK, I was wrong about WSGI. What I meant was replace the Tornado interface by something that tomcat supports.

It appears that Tomcat does support websockets, though as to how close to what bokeh needs this would be, I have no idea.

I think I’ll put this on the back-burner for when I’m feeling bored.

On Thursday, 4 August 2016 12:30:06 UTC+1, Bryan Van de ven wrote:

The Bokeh wire protocol is fundamentally a websocket protocol. There’s no way to re-tool the server to have a WSGI interface that would not also requiring having a drastically patched and custom BokehJS version as well. I’m not even sure it’s possible in principle, without losing functionality. The old server didn’t use websockets, and properly and easily synchronizing bidrectional updates was one of its primary shortcomings.

–
You received this message because you are subscribed to the Google Groups “Bokeh Discussion - Public” group.

To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].

To post to this group, send email to [email protected].

To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/d846d762-852a-465a-9f6e-95cc6b394ef8%40continuum.io.

For more options, visit https://groups.google.com/a/continuum.io/d/optout.