I'm new to CXF, and I was trying to implement a CFX client in Ajax.
I had already implemented a client in Java but now I need to implement a client-side application to access CXF. I'm not even sure that it's possible to do that (Accessing CXF directly from client-side).
If it's possible then kindly direct me to some ajax code. If not, then please help me with your ideas for a web-based CFX client.
Thanks
I would like to know a good answer to this question too. However, I have what I deem to be an unsatisfactory answer! Code up a servlet that effectively wraps the java-based JAX-RS client so as to make it accessible via a 'normal' parameter-based web services API call (i.e. like http://mydomain:8080/service?param1=xxx). This you can then use with AJAX. However I don't like this since, in effect, the JAX-RS service is most probably already being delivered from a generic servlet (e.g. as is the case I believe for Jersey)
If anyone out there has got a better solution, I'd like to hear it.
Related
We are writing a mostly single-page, client-side app, but server-side/DB endpoints are still required of course, so the natural choice is SpringMVC (since we are a Java / Spring shop).
But this got me thinking why we need the cluttered, very old design for this app:
- Controller layer
- Service layer
- DAO layer
This app is mostly just the client side making AJAX calls with JSON for DB retrieval/persistence. Do I really need to go thru the Controller layer to receive requests, then invoke a Service method, which in turn invokes a DAO method?
At the same time, I don't want to write a REST Service because it could result in overhead and we may not support all of the REST requirements... but is it the right choice here? If I understand correctly, I would still need a RESTController on the presentation layer?
My goal is to just directly hit a Service method or, maybe even more directly, a DAO method. Is that how modern apps are written?
You cannot hit a DAO unless you expose it through an API of some sort that can be invoked remotely by the UI application; as a consequence, you need to write a service.
A convenient way of exposing a service is to either:
Use Spring MVC and use the controllers as stateless endpoints that provide a JSON/Protobuffer/XML sort of payload that is then parsed by your API (with JSON being the simplest option of them all, perhaps) or
Use Spring Boot, which uses Spring MVC under the hood.
Hope this helps and good luck with your project.
So. We started working with the Spring Cloud (and Spring Cloud Netflix) library to get service discovery and client-side load balancing in our Spring Boot-based services. Part of the reason was I also, incorrectly, though it would also support the retrying that seems to be very important in a setup like that.
Another question has explained that is not actually the case. Fair enough but the documentation could have been clear on that. Would have saved me from some wrong assumptions at least.
But after investigating the code. I cannot figure out why Ribbon HttpClient is used at all? The load balancer support is currently implemented with Ribbon.
But the code that does the actual HTTP request only deals with that though the Spring Cloud abstracted API. So it seems fairly pointless specifically use a (now deprecated) HttpClient from Ribbon when it could as well has used the implementation Spring RestTemplate would default to.
Seems like it would be a lot easier to understand the behavior of if it behaved like whatever client RestTemplate is configured to use or actually behaved like the Ribbon client with the support for configuring it to do what is supposed to be able to do (like retry).
Kristoffer,
I also was looking for re-try logic in the load balanced RestTemplate and it turned out the RestClient (even though its been deprecated) does have support for fail-over and a small change to the request factory seems to work for me.
Here is a link
I have been Googling a lot lately, but I find myself coming up short on answers.
I have a complete Spring MVC application secured by Spring Security and with services exposing logic to controllers (controllers -> service -> repository -> POJO's).
Currently all my controllers, except the login controller, serve nothing but JSON/XML and I want it to stay this way. I do not want to render different views on each controller.
However, what I want to be able to, is to separate the web application from the backend because in time I want to be able to integration with my service using more platforms than just a web browser.
Currently I have the regular Spring MVC application:
Configuration
Domain(POJO's)
Repository
Service
Controller
Login is done using a Thymeleaf rendered view and Spring Security which does nothing more than filtering all urls under the application root. After this, it is just a bunch of static files being served as resources:
Spring Controllers send a "{ontrollerName}/layout" to serve the AngularJS HTML partial used for all data under that given Spring Controller.
What I want, is a way to separate everything in the /webapp directory from the rest of my project. I have looked into a few different solutions here such as using Apache Proxy where my Apache Http server hosts the client code which communicate with the backend using Ajax to rest controllers, and Tomcat hosting the backend. However, I hear that proxying like this is not safe. I could however be dead wrong here.
So, the questions I hope to receive answers to are:
1. Is it fine to just write a client that uses Apache http server's Proxy to provide access to Ajax on the server?
If not; How should I proceed? Is it any point in trying to extract the client side from the /webapp directory or is this just some stupid idea I created because it seemed cool to be able to deploy them without having to relay on each others?
Is there any best practices in regards to how I structure a project with separate modules? Think Gradle build scripts for multi modules.
Should I think in different terms and use an approach not based on Spring MVC at all? If so, please advice me.
I hope this was clear enough to make sense for you guys.
The solution was to use the simpler approach of a restful API that did authentication over OAuth 2.
Basically the two best alternatives are a hybrid solution (part restful API and part server side rendering of pages) or a full blown restful API where you implement all functionality in a static web client. This way there is no need for multi-module projects and packing things together in one package.
Developed Rest API using Java/Spring MVC
Can we provide authentication for RestAPI? If yes, How?
Now I am struggling with authentication for RestApi. Can anyone send some examples regarding the same.
Accessing rest API through AJAX request.
Since you are already using Spring, you can use Spring security to provide security related functionality. This can give you one stop solution for your security needs. Common security mechanisms for Rest API's (basic, digest) and features are supported out of box and it's very easy to add your custom security too. For a start tutorial you can have a look here
Please let me know how to write a non soap web service. On the web I could find many tutorials to develop SOAP and REST based web services. But nothing really helpful for non soap. I would like to add custom http handling.
I am looking forward to host it on tomcat on a Windows machine. But any feasible options are welcome.
REST services are by far simpler to get a start on. You did not specify whether you are interested in a particular language but you tagged your question with the [tomcat] tag, so I can suggest Java. REST is a part of Java specifications now and a good way to start is the Oracle Java EE tutorial on REST.