Telerik has an how-to on Configure a Java Application to Use Fiddler. That does not seem to work (meaning it seems to have no effect) with our Netty based application, which I assume is because that would only apply to applications that use the default J2SE built-in HTTP libraries? Also see Java Networking and Proxies in the Java SE docs.
Is there a standard way of configuring a Netty based application for picking up proxying, or would I need to manually add a handler to the channel pipeline that would change the HTTP requests (and responses?) to use the proxy? If the latter, is there a standard handler I could employ that has all the logic for setting headers, changing urls, etc. built-in?
There is a proxy package in Netty, in which HttpProxyHandler seems to be what you are looking for, with regards to the last question on whether there is standard handler built-in. Have not used it, though, so cannot say whether or not it picks up on those system props.
Related
We have service which mostly use gRPC. So we just use netty+io.grpc and need no extra frameworks here.
But we also need to support some HTTP requests for our infrastructure team.
And I think it will be better to reuse Netty (EventLoopGroup, ChannelFactory, etc) which we already configured.
So basically I need small HTTP routing library for already configured Netty.
But most of HTTP over Netty frameworks like Vert.x, Jooby, Ratpack or Armeria, manage Netty by their-self and just too complex for my case.
It will be simpler to me just use HttpServer from JDK and doesn't care about a bit of context switches because of over creating event loops.
But I really want to get clean solution.
I'm open to any suggestions.
My application uses a custom binary protocol which is implemented with Netty. Recently I changed it to use Netty's websocket implementation. It works quite well.
My application also has a Jetty web server included and it offers websockets, too. Now I want to reduce the opened ports my server needs and handle all http traffic with one port.
I see three options:
Use either Netty or Jetty to proxy the traffic which belongs to the other implementation.
Reimplement the custom protocol on Jetty without the use of Netty's channels and piplines.
Create a custom implementation of Netty's channels that sends and receives it's data not over a socket but the methods Jetty's WebSocketListener offers.
Since Netty provides such a good api for writing binary protocols and a proxy sounds like extra problems to me I tend using the third approach. It shouldn't be too difficult to implement even though I don't know how to do it, yet.
Any thoughts what would be the best option and how I should implement it?
Jetty 9 supports both it's own Jetty Websocket API as well as the standard JSR 356 API, for what I assume are historical reasons (Jetty's API precedes the final JSR 356).
I've looked over the basic documentation of both APIs, as well as some examples. Both APIs seem fairly complete and rather similar. However, I need to choose one over the other for a new project I'm writing, and I'd like to avoid using an API that might be deprecated in the future or might turn out to be less feature-rich.
So are there any important differences between the two except for the obvious fact that one is standardized?
Implementor of both on Jetty here :)
The Jetty WebSocket API came first, and the JSR-356 API is built on top of it.
The JSR-356 API does a few things that the Jetty WebSocket API does not, such as
Decoder's for automatic Bin/Text to Object conversion
Encoder's for automatic Object to Bin/Text conversion
Path Param handling (aka automatic URI Template to method param mapping)
However, the Jetty WebSocket API can do things the JSR-356 API cannot.
WebSocketCreator logic for arbitrary creation of the WebSocket endpoint, with access to the HttpServletRequest
Better control of timeouts
Finer buffer / memory configurations
You can manage WebSocket Extensions
Supports Reg-ex based Path mappings for endpoints
Access to raw Frame events
WebSocket client supports HTTP proxies (JSR-356 standalone client has no configuration options for proxies)
WebSocket client supports better connect logic with timeouts
WebSocket client supports SSL/TLS (JSR-356 standalone client has no configuration options for SSL/TLS)
Access to the both InetAddress endpoint information from the active WebSocket Session object
Access to UpgradeRequest from active WebSocket Session object
Better support for stateless endpoints
Read events support suspend/resume logic to allow application some basic tcp backpressure / flow control
Filter based or Servlet based configuration (the JSR-356 approach requires upgrade to occur before all other servlet and filter processing)
Hope this helps, if you want more details, please use the jetty-users mailing list, as this sort of question is really inappropriate for stackoverflow.
I have a running Scheduled Singleton, that's collecting data from Couchbase DB nodes through REST API, and I also have a Camel component which is responsible for sending Error reports and statistics to an external tool. Other Camel components in our system can use this "Error reporting" Endpoint just fine. How can i make my singleton useful in this setting?
(I'm looking for something like in a Junit Test for Camel, the ProducerTemplate.)
If you really can't grab the Camel Context you have a few other options.
If you are in the same JVM and have camel-core in the startup classpath - fire up another CamelContext and use the direct-vm or vm component.
If you are comfortable with JMX, you can access your Camel context via JMX and send a message to any endpoint using that protocol. A bit of boiler plate, but does not require you to be in the same JVM or even same machine.
Fire up an embedded ActiveMQ and use that for inter module communication. I like this approach since it's probably easier than JMX and very easy to de couple the sender/receiver from each other (say you want to send from another system). However, some performance overhead.
Use any other direct external protocol. ZMQ, jetty/http,RMI. Each with their own drawback or benefit. Depends a bit on your knowledge and requirements (if you are a RMI guru, you may think that's a nice path).
I have spent some time on investigating what Endpoint.publish can and cannot do, and it appears that you very quickly enter undocumented territory.
In case you build a simple stand alone application which expose one or more #WebService annotated classes with Endpoint.publish and you then run into a situation where you cannot use Endpoint.publish any more (for any reason) what is then the simplest migration path?
I know that you can create a WAR with sun-jaxws.xml and optionally Metro jars which you can then deploy to an embedded web server (like Jetty or Winstone) but I like the simple "take THIS class and expose it at THIS url" API of Endpoint.publish() without any XML or full containers.
Is there a good way to do this?
It's been said that you can an instance of com.sun.net.httpserver.HttpServer to customize the HTTP behavior of the endpoint. It's always a good idea to be cautious of com.sun APIs but it might be appropriate depending your situation. There's an HttpsServer subclass that can be used to provide SSL, for example.
The process seems to be:
Use HttpServer.create(new InetSocketAddress(listenPortNumber), waitQueueDepth) to create a server instance.
Use server.createContext("/path") to create a context that will host the endpoint.
Create an endpoint with Endpoint.create(new RpcLitEndpoint()). It's not clear where RpcLitEndpoint is defined or whether it's strictly required; it may be part of Metro JAX-WS.
Call endpoint.publish(context) to associate the endpoint with the HttpServer (or HttpsServer) instance.
When done, use endpoint.stop and server.stop to shut down.
There's also a blog entry on blogs.oracle.com describing the creation of custom network transports. It didn't have enough detail for me to get a great understanding from a quick scan, but maybe you can get more out of it.