Servlet and Web Start Blues

[JavaEnquirer]

I have a servlet which dynamically generates a jnlp file. I'll simplify
my problem for the sake of brevity. A 3rd party system invokes a URL
http://localhost:8080/blah/blah.jnlp - this is "pointing" at a servlet
which sends back a dynamically generated jnlp and launches a java
client. This works great. However, there are some occasions when I do
not want to send a jnlp file back, instead, some server side processing
occurs. Again, this works fine except that I get a blank web browser
window appearing which is not welcome ( or JWS attempts to launch
nothing and fails ). Note: I cannot build logic into the 3rd party app.

So, how do I configure my servlet to "send nothing back" and ensure no
blank web page is displayed on the client machine, or no attempt to
launch JWS is made? What content type do I need to set and should I
push anything down the response stream?

Mank thanks in advance.

 

[Joe Attardi]

So, how do I configure my servlet to "send nothing back" and ensure no
blank web page is displayed on the client machine, or no attempt to
launch JWS is made? What content type do I need to set and should I
push anything down the response stream?

I'm not sure this is possible. Even if the received content is empty, I
think that the HTTP response will trigger a browser window. If it's not
a 200 OK, but some error code, it still has to show a window so the
browser can display the error.

 

[JavaEnquirer]

Thanks for your input.

 

[Chris Uppal]

A 3rd party system invokes a URL
http://localhost:8080/blah/blah.jnlp - this is "pointing" at a servlet
which sends back a dynamically generated jnlp and launches a java
client. This works great. However, there are some occasions when I do
not want to send a jnlp file back, instead, some server side processing
occurs. Again, this works fine except that I get a blank web browser
window appearing which is not welcome ( or JWS attempts to launch
nothing and fails ). Note: I cannot build logic into the 3rd party app.

I know almost nothing about JWS but seems to me that you have a situation where
the user will expect an application to start (because they did whatever they
normally do to start it), but you don't want that to happen. That doesn't give
a very good UI. One option is, instead of trying to return "nothing", you
could return a very small JWS application which just displayed a screen with an
explanatory message.

-- chris

 

[Alun Harford]

I have a servlet which dynamically generates a jnlp file. I'll simplify
my problem for the sake of brevity. A 3rd party system invokes a URL
http://localhost:8080/blah/blah.jnlp - this is "pointing" at a servlet
which sends back a dynamically generated jnlp and launches a java
client. This works great. However, there are some occasions when I do
not want to send a jnlp file back, instead, some server side processing
occurs. Again, this works fine except that I get a blank web browser
window appearing which is not welcome ( or JWS attempts to launch
nothing and fails ). Note: I cannot build logic into the 3rd party app.

So, how do I configure my servlet to "send nothing back" and ensure no
blank web page is displayed on the client machine, or no attempt to
launch JWS is made? What content type do I need to set and should I
push anything down the response stream?

I don't think you can. Well... you *can* (get the underlying socket and
close it) but I think that probably breaks the HTTP standard so browser
behavior is probably undefined (I'm guessing here).

Alun Harford

 

[JavaEnquirer]

I know almost nothing about JWS but seems to me that you have a situation where
the user will expect an application to start (because they did whatever they
normally do to start it), but you don't want that to happen. That doesn't give
a very good UI. One option is, instead of trying to return "nothing", you
could return a very small JWS application which just displayed a screen with an
explanatory message.

Sounds crazy I know, but the JWS application isn't invoked by the user,
its invoked by the 3rd party application - sometimes human intervention
is required, sometimes not. I've managed to solve the problem now using
the old mutually exclusive server socket binding trick.