I was taking a look at WebSockets last week and made a few thoughts on how to implement the server side with the Java Servlet API. I didn't spend too much time, but ran into the following problems during a few tests with Tomcat, which seem impossible to solve without patching the container or at least making container specific modifications to the HttpServletResponse implementation:
The WebSocket specification mandate a defined message in the 101 HTTP response. HttpServletResponse.setStatus(int code, String message) is deprecated without mentioning a usable replacement. After changing the default Tomcat configuration, I made Tomcat honor my message string, but since the method is deprecated, I'm not sure if this will work with other servlet containers.
The WebSocket specification require a specified order of the first few headers in the HTTP response to the connection upgrade request. The servlet API does not offer a method to specify the order of the response headers and Tomcat adds its own headers to the response, placing a few of them before any headers, which are added by the servlet implementation.
Since the content length of the response is not known when committing the header, Tomcat automatically switches to chunked transfer encoding for the response, which is incompatible with the WebSocket specification.
Am I missing something obvious, or is it really not possible to integrate WebSocket server endpoints in a servlet based web app?
There is an implementation in Jetty. We can hope that tomcat and jetty find a compatible API.
The Glassfish Atmosphere project will do what you want. There is a servlet you can define to do all the work.
jWebSocket claims to run as a Tomcat application. Unfortunately some files are missing in the binary distribution of jWebSocket. Some people are trying to recompile jWebSocket and get the necessary files, since the source code is available. All in all, jWebSocket does not seem as a reliable product.
Yes there is a very good one (open source and completely free): http://www.jWebSocket.org
Related
We've got a lot of applications based on Jetty. For historical reasons; these have been sitting behind Apache servers. One of the duties of Apache has been rewrites, and we want to move to using just Jetty. But we are hitting some snags when it comes to porting it. Specifically Cookie path rewrites. Is it even possible in Jetty?
The original config for Apache looks like this:
ProxyPassMatch ^/${basePattern}/${market}/(${appContextName}/.*) http://127.0.0.1:8080/app/${symbol_dollar}1 retry=0
ProxyPassReverse / http://127.0.0.1:8080/
ProxyPassInterpolateEnv on
ProxyPassReverseCookiePath /appCookiePath /${basePattern}/${market}/${appContextName} interpolate
I've looked at the code for both Rule (from the rewrite API) as well as Jetty Handlers. I can't really find anything in those APIs that would let me rewrite the Cookies... Any pointers?
There is no built in feature of Jetty for rewriting Set-Cookie headers or Cookie headers.
If you are not afraid of Java code, you could create a CookiePathHandler that is placed at the start of the Server handler list to perform this logic for you in java code.
Pop into jetty-users mailing list or #jetty on chat.freenode.net for help (if you've never written a Jetty handler before)
I have a client software that is written in C++/C# and a database. Now I don't want the client to access the database directly, so I thought about placing an application server in the middle. This one should get a short request from the client, ask the database for new data, do some filtering (that can't be done in sql) and then return the data to the client.
My search for this kind of software brought me to Glassfish or Tomcat but my problem in understanding is, that these always want to talk http with html/jsp. Because most of my data is encrypted anyways, I don't need such plain text protocols and would be totally happy with something that just takes a byte stream.
On the other hand would it be nice to have a server handle the thread pool for me (don't want to implement all that from scratch).
After more than a day of searching / testing I'm even more confused than at the beginning (ejb, beans, servlet, websocket, ... so many things to google before understanding just the simplest tutorials).
TL;DR: how do I get Tomcat/Glassfish to just open a socket and create a new thread for every request, without any HTML/CSS/JSP involved?
Jetty and Tomcat are so called servlet container and thus primarly targeted at HTTP exchanges. Glassfish is an application server that uses a servlet container as one of its modules. I would stop thinking in that direction - that's all more like web applications and web services - some levels too high what you are asking for.
I think you should more look into sth. like Netty which is merley a "high performance protocol" server. Take a look at the documentation here (even some sort of tutorial there which might fit your use case).
GlassFish is an "enterprise application server", targeting the Java EJB specification. That's surely overdone for your purpose. You can give Tomcat a try. It is a "servlet container", targeting Java Servlet specification. Servlets have one purpose: listening to an incoming URL (request), executing Java code and returning a response, usually over HTTP.
For sure, you may start your own (plain) ServerSocket, for example using a ServletContextListener (which will be started once your application starts). But you should go for a higher protocol to send the data, like Hessian and Burlap, which is implemented in both, Java and C++ and easy to set up.
I have a JAX-WS web service exposed through the simple Endpoint interface (example)
If I understand the API correctly, as an alternative to directly calling Endpoint.publish (which uses the Sun's HTTP Server), we can:
Create the Endpoint --> Endpoint e = Endpoint.create(impl);
Publish the Endpoint ---> e.publish(context);
Can I use this e.publish(..) API to publish to an embedded tomcat server? (example)
The javadoc of the Publish method is pretty confusing to me.
Although it is more than two years old, this answer to a related question still applies. If you want to deploy to tomcat, no matter whether it is running in embedded mode or normal, you need to package a war and place it in the webapps directory.
To be usable with the publish() method in the way described in your question, tomcat would have to provide a Sun HTTP Server Service Provider Implementation, which it does not. An alternative to Sun's HTTP Server is for example Jetty.
I have a website (python/django) that needs to use a load of Java resources that may or may not be on the same server. Therefore I am writing a mini webserver in Java that will receive a request and then when processing is finished, POST some data back to a url on the site.
I have got the java code receiving connections on sockets and responding with some simple HTML.
My problem is that I will POST data to the Java server and that code needs to act on the data. How do I go about reading the data that is posted in the HTML request, if it is even possible. If not, is there any other way you would do this.
If you think I am going about this in completely the wrong way then please tell me and I will consider another method, but after conversing with some Java developers, this seemed like the best way for what I was doing.
Thanks
You probably don't need to write a http server yourself, just use some lightweight java web server/servlet container like jetty or simple
and looks here if you still want to know how to parse a http POST request http://www.jmarshall.com/easy/http/#postmethod
In your case I probably wouldn't work with low level socket connections.
I recommend you to use a servlet container with some sort of webservice or maybe only a simple servlet depending on your needs. With a servlet you can easily access the POST data, process it and return something to the caller.
If you don't want to use a stand alone servlet container like Tomcat you can try an embeddable servlet container like Jetty or winstone servlet container.
If you need something more sophisticated you can use some webservice technology like JAX-RS or JAX-WS. This allows you to provide a fully featured API for your Java resources in an easy way.
I am trying to consume the Exchange 2010 Web Service interface using JAX-WS. I'm using JAX-WS 2.2 RI (Metro 2.0). 2.1 exhibited the same problem.
I am running into trouble with Exchange, which returns "HTTP/1.1 415 Cannot process the message because the content type 'text/xml;charset=utf-8' was not the expected type 'text/xml; charset=utf-8'." as a reponse (2.1 quoted the charset value, otherwise same response).
Apparently I need to dictate the exact Content-type header for Exchange to be happy.
Is there a way for me to do this without forcing me to manually rebuild the dependency? I currently rely on published maven artifacts, and would like to continue doing this if at all possible.
The consuming process is a regular J2SE app, with no containers in sight. I have control of the application and can add pretty much anything required to the applications scope, but can not add out-of-process items like proxy servers. The client classes were generated from local WSDL, but the charset specification is derived from constants declared in the jaxws RI implementation, not the generated code. The resulting HTTP transport is thus handled by the standard http/https client from Sun JRE5 or JRE6.
From this thread (giving a cached link, because currently java.net forums are down), it appears that the fault is ultimately that your Exchange Web Service 2010 demands a space after the semicolon - something NOT part of the w3c spec.
A solution might be to put something (depending on your setup) in front of the metro to change the header.
You could try some of the following approaches:
Use reflection to change the Metro constant.
Use AOP (I can't tell you how exactly)
See where is this constant defined in Metro, create a package javax.xml.ws.etc (or com.sun.etc.. in your sources, and copy-paste the source for that class, changing the constant.