I am relatively new to JAVA and am trying to build a back-end application which will call another server where the data is present.
I have to do GET, POST, PUT and PATCH(can live without PATCH) operations to an external server in the intranet. I can hit the exposed service using postman app (using custom header)but want to do the similar action from my Java code, get the output in my Tomcat Server.
I have limitations in modifying dependencies to the POM file or adding jars to the library, so am looking for a solution other than Jersey.
You can use HttpURLConnection (which extends URLConnection) to handle the http requests and these classes are part of JDK itself so you don't need any external jar files, I suggest you look here for basics on these and look here for examples.
Most of the places, I look for provides me the answer for GET. I see
some POST too, but my requirement is mainly for PUT.
In order to place PUT, DELETE, etc.. http operations, you can use httpConnectionObj.setRequestMethod("PUT") or httpConnectionObj.setRequestMethod("DELETE") as given in an example here.
you could set up a simple java.net.Socket instance and implement the calls yourself - then you don't need any dependencies.
http://www.cafeaulait.org/course/week12/22.html
java.net.HttpURLConnection seems to be the way to go then. This might i.e. be initialized like so: (HttpURLConnection) new URL(url).openConnection()
Related
I want to write a program in java to make http request and print for me only the information I Want. For example there's this website: "https://br.investing.com/currencies/usd-brl"
And here I need to get only the information about the dolar value in real time. How do I do that in java? I thought it would be more easy using an API but I have no idea on how to do it.
I have no idea where to start or resources i should be using, I need to use only native java resources no third party modules.
there isn't API at 'investing.com' but simple widget. you should crawl the data OR using API via another site.
i think the Exchange rate information is provided by not only investing.com but also several finance service. And you can using Class URL, HttpUrlConnection in java.net to request for data to target url you need.
https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/net/URL.html
I'm new to this and I need my Java program to send http or https requests on the different websites(for example, Amazon)
so it can get the HTML code and than I would be able to find information(price on some goods) that I need via Pattern class.
Did anybody faced with that task? Maybe you used JSON or other tools? Thank you.
It seems that Amazon have an API. You should using instead of trying to parse their website.
Regarding libs to call webservices in JAVA, you could use Retrofit.
There are several parts to what you are asking:
Constructing / determining what to include in the HTTP request
Issuing the actual HTTP request
Parsing the response
The first and last are dependent on the particular service / API you are invoking, though if the API response is in a standard format (e.g. JSON), there are libraries that can help you interpret the response (though exactly which fields in the response mean something to you, will depend on the particular API and your application). Issuing the HTTP request, itself, is something that can be done with a number of different libraries, including the builtin HttpURLConnection / URL classes, as well as third party libraries such as the Apache HttpComponents or the Google HTTP Java Client Library, the latter of which includes libraries for parsing common output formats, as well.
I need to access some web-services from java.
But it is an overkill for my task to use generated from WSDL java classes. I just need to get responce and pass it to the script, which will handle everything else.
Also it would be better not to generate classes for new data source but just add WSDL file for a new web-service data source and add new script for it.
But I also do not want to throw WSDL away, and reinvent custom configuration for describing this ws-data sources.
Is there any java WSDL-specific tool that can help me?
Thanks
Without understanding entirely what you're trying to achieve, you don't need to use wsimport to generate proxy classes to call a service. You can use javax.xml.ws.Service.create() to create a service, then have jax-ws generate a dynamic port and use that. You can also create a Dispatch mechanism from there that you can use to invoke the service and will get you a Response that contains the payload of the message.
Without more detail about what you're trying, can't really tell if that's what you're implying you need or not. But sounds like it.
At an even lower level, you could create an HTTPRequest to call a service and pass in the appropriate payload, and that would get you direct access to the response. But that seems like too low a level, and using the Service class and Dispatch interface (from which you get the Response) gets you to the same core response data but handles the other service wrapping.
SoapUI comes with extensive support for testing WSDL / SOAP based services.
I want to step through the jetty source code as it responds to a typical servlet request.
How can I do this?
Do I need to download the source code?
Where is the entry point where I should be setting the breakpoint?
Yes you can do it.
Yes, you need to download the source (unless you like to read bytecode in your debugger :) ), if you're using Maven, then you can let maven do the downloading for you
It's possible to do it with a "standard" Jetty setup, but I find it much easier to build a quick embedded-jetty server for these tasks. Even if you're not familiar with embedding jetty, it's not hard to learn, and will help you to get your head around how Jetty handles servlets. See the embedding jetty documentation
The location for the breakpoint will depend on exactly which version of Jetty you're using, and how far into Jetty's internals you want to go.
You can set a breakpoint in the constructor for HttpConnection that will allow you to look at how Jetty reads from a raw TCP/IP socket, parses the HTTP headers, and then creates a request and response object for each HTTP request.
If you just want to see how the dispatching to servlets works (the matching of requested URLs against path mappings, the instantiation of new servlets, etc) then try a breakpoint in ServletHandler.doHandle
If you want something in between, then Server.handle is a good place - that will happen after the incoming stream has been parsed, but before Jetty has made any decisions about how the request should be handled.
yes, you would need to download the source code (unless you want to step through javap output). Last time i checked, i think there was a Server.handle() method which was the "main" entry point.
I am working on a project where we'd like to pull content from one of our legacy applications, BUT, we'd like to avoid showing the "waiting for www.somehostname.com/someproduct/..." to the user.
We can easily add another domain that points to the same server, but we still have the problem of the someproduct context root in the url. Simply changing the context root is not an option since there are hundreds of hard coded bits in the legacy app that refer to the existing context root.
What I'd like to do is be able to send a request to a different context root (Say /foo/bar.do), and have it actually go to /someproduct/bar.do, (but without a redirect, so the browser still shows /foo/bar.do).
I've found a few URL rewriting options that do something similar, but so far they seem to all be restricted to catching/forwarding requests only to/from the same context root.
Is there any project out there that handles this type of thing? We are using weblogic 10.3 (on legacy app it is weblogic 8). Ideally we could host this as part of the new app, but if we had to, we could also add something to the old app.
Or, is there some completely different solution that would work better that we haven't though of?
Update: I should mention that we already originally suggested using apace with mod_rewrite or something similar, but management/hosting are giving the thumbs down to this solution. :/
Update 2 More information:
The places where the user is able to see the old url / context root have to do with pages/workflows that are loaded from the old app into an iframe in the new app.
So there is really nothing special about the communication between the two apps that client could see, it's plain old HTTPS handled by the browser.
I think you should be able to do this using a fairly simple custom servlet.
At a high level, you'd:
Map the servlet to a mapping like /foo/*
In the servlet's implementation, simply take the request's pathInfo, and use that to make a request to the legacy site (using HttpUrlConnection or the Apache Commons equivalent).
Pipe the response to the client (some processing may be necessary to handle the headers).
Why not front weblogic with Apache.
This is a very standard setup and will bring lots of other advantages also. URL rewriting in apache is extremely well supported and the documentation is excellent.
Don't be put off by the setup it's fairly simple and you can run apache on the same box if necessary.
Using Restlet would allow you to do this. The Redirector object can be used. See here and here for example.
If you instead serve out a JSP page you can use the tag to do the request server side.
Then the user will not even know that the resource was external.
http://java.sun.com/products/jsp/syntax/1.2/syntaxref1214.html
a bit more context for the API the client is working against would help here to give a solution that could work. Are you trying to provide a complete new API totally different from the legacy Java EE app? What artifact is serving the API (Servlet, EJB, REST service)?
If you have the API provided by a different enterprise application then I suppose you simply use a Pojo class to work as a gateway to the legacy app wich of cause can then be reachable via another context root than the new service app. This solution would assume you know all legacy API methods and can map them to the calls for the new API.
For a generic solution where you don't have to worry about what methods are called. I am curious if the proxy approach could really work. Would the user credentials also be served correctly to the legacy system by URL re-writing? Would you have to switch to a different user for the legacy calls instead of using the origin caller? Is that possible with URL re-writing. Not sure if that could work in a secure context.
Maybe you can provide a bit more information here.