Castle supports different kinds of Dynamic Proxy. How can I setup kind of proxy to use, when
regestering a component with WindsorContainer
using InterceptorAttribute?
Related
In my two different firm components I've used common instance of a service.
I want to reset instance of singleton service. Is any built in function available?
I'm trying to implement REST service in a liferay portlet. Found no way other than using JSON web services in liferay. I don't need to implement web services to interact with the database directly, meaning I dont want to build services to use Json web service. Is there anyway to implement REST web services in a liferay portlet without involving service building, more like a custom web service? Also provide any examples available if possible. Thanks in advance.
For Spring based portlets, there's an excellent and still valid blog Using RESTFul services with Liferay that describes implementing REST services with Spring MVC controllers and Liferay PortalDelegateServlet.
Another option might be to handle the REST calls as resource requests (it. to implement a controller with resource mappings - #ResourceMapping).
Since Liferay version 7.0 there is support in Liferay for deploying JAX-RS endpoints as OSGi services.
In Liferay 7.0 you need to use what is called RestExtender (https://dev.liferay.com/es/develop/tutorials/-/knowledge_base/7-0/jax-ws-and-jax-rs)
From Liferay 7.1 version there is also support for JAX-RS OSGi Whiteboard, which also allows to deploy JAX-RS applications as services and adds a lot more flexibility (https://osgi.org/specification/osgi.cmpn/7.0.0/service.jaxrs.html) (https://dev.liferay.com/es/develop/tutorials/-/knowledge_base/7-1/jax-rs)
I want to build a RESTful service/API. I used some framework like play to build it but I want to try other more efficient ways. I heard that Jersey is a common library for building a REST API, and Spring is also a good framework. But I also saw some solutions like Spring+Jersey. Thus, I am a little confused about those REST API solutions.
Can anyone tell me what is the difference among those? Jersey REST, Spring REST and Spring+Jersey REST?
My goal is building a couple of REST APIs that take JSON as input/output. I have jar file as the backend process logic to process the input a JSON/object and return a JSON/object.
Jersey is the JAX-RS API example implementation provided by Sun, while Spring REST is of course Spring's implementation of the same API/JSRs. The major difference is that Spring REST easily integrates into other Spring APIs (if you wish) such as Spring Data Rest.
There are a few noteworthy differences between them - you can "embed" Jersey Resources (known in Spring as Controllers) within each other, to enable a separate class that is responsible for the sub-path of a certain path, while this doesn't appear to be available in Spring right now (you have to define the full path). Also, in my opinion Jersey gives better "out of the box" error responses (such as why it can not map a JSON payload to a Java bean using Jackson) while Spring is a bit more configurable but plainer without some additional work.
In the end the difference in choosing between them usually comes down to - are you already or do you plan to integrate any other Spring libraries into your application? If so Spring REST is the way to go as you'll have a much easier time integrating it, otherwise it is really just personal preference which you'd prefer to use. Personally I like Jersey but the power of other related Spring projects (such as Spring HATEOAS which I highly recommend) makes Spring the better choice. I don't think there will be a real determining factor in your case.
As your "gold" target is a simple API with JSON input/output, I'd recommend you follow the Spring REST guide.
One major difference is in the area of unit testing support.
Jersey Test Framework does not lend itself for mocking server side code - For example, if your REST Resource depended on a Service, you would like to mock the service when testing resource methods. However, Jersey Tests run a separate container and unit tests sort of make calls to the running instance of your REST resource - at this point of time, I have not found any documentation or way for mocking server side code.
On the contrary, Spring MVC tests do not require any containers - and are more well integrated with its controllers. Dependency Injection can be used to inject mock services / DAOs to have better unit tests.
I also find that documentation on Spring projects are more mature when compared to Jersey.
One subtle difference is in the instantiation of the resource (Jersey) or controller (Spring) objects.
Jersey new's a resource object for each request. Whereas, by default Spring treats controllers as beans with default scope of singleton. This can be overridden with a #Scope annotation (although if you do that it will get flagged by Sonar).
This default behavior of Spring has bitten our application several times. With the controller class being a singleton, all class members are effectively static. So values set handling one request will still be there for the next.
This is something to be aware of if your using Spring. My suggestion is to #Scope the controller class as prototype, even though that will earn you a warning if you do Sonar scans.
Our RESTful application need to support 'partial responses' to limit bandwith.
By this I mean that the REST client tells the URI service which fields of the resource it is interested in.
For instance: api/v1/users/123/fields=firstName,lastName,birthDate
We're using Jackson parser to convert our DTO's to a JSON structure.
The problem is that we cannot tell at runtime to 'skip' some properties.
We should need to create a class at runtime with a variable amount of properties to accomplish this. But I don't think this is possible in Java, it is a static language after all.
While searching the internet we found some semi-solutions by just returning a java.util.Map containing the requested properties or filtering out properties by the Jackson parser.
Especially the latter seems a 'hacking solution' to me. It seems that Spring MVC doesn't provide an out-of-the-box solution for this issue...
Is there any alternative in the Java world we can use to solve this issue?
How about Yoga
Yoga extends JAX-RS and SpringMVC RESTful servers to provide GData and LinkedIn style field selectors.
Choose which fields you want to see at call-time
Navigate entity relationships in a single call for complex views
Much faster speeds in high-latency (e.g. mobile) apps
Streamline client development
Browsable APIs
I want to build a WCF Server with MySQL Database which can communicate with differents Clients on differents OS. Is that Possible?
if Yes, how should i go? any tutorials which can help me?
Cheers
Is that Possible?
Yes, interoperability was one of the main concerns of the WCF designers.
how should i go?
There are so many options you need to consider, for example security, reliability...
But mainly basicHttpBinding is probably the most interoperable SOAP-based binding. Just google for samples of basicHttpBinding.
On another account, the most interoperable WCF approach is WCF REST which can allow use of JSON that any client can understand, even the browser. However, implementation of WCF REST has quite a few design problems (outside scope of this question) and I would suggest using ASP NET MVC to implement passing JSON objects over HTTP. For security, you can use HTTPS.