With Wiremock you can define a proxy so that if none of defined stub mappings match for a given request, Wiremock forwards that request to a given host:port. Is that behaviour available with Spring Cloud Contract DSL ?
I could not find anything of that feature in SCC documentation (with my browser find command).
That approach is not present via the dsl. You can create wiremock proxies and package them to a stub jar yourself. Then stub runner could pick those and start such a proxy.
Related
https://docs.spring.io/spring-boot/docs/current/reference/html/howto-embedded-web-servers.html
Spring boot allows changing the web server, other than the embedded Tomcat server. Does Vertx provide similar capability?
Vert.x is implemented over netty (A lightweight event-driven network application framework).
Under the hood, starting a Vert.x HttpServer bootstraps a Netty server by default: meaning you cannot switch to another implementation.
While it should be possible to use Vertx with any web server, Vertx comes with a HttpServer in the Vert.x-Web package that can deliver static files and has routing options, role and security features and many more.
All of these are optional, yet pretty easy to use/implement if you follow the documentation. Also see all the other available modules.
If you use the Vertx webserver module you don't need a container like Tomcat, you can deploy a fat-jar and start that like any java application.
You could as well use nginx as a reverse proxy in front of vertx. This setup gives you more flexibility and you can use the full power of nginx for serving static files, your ssl configuration, gziping etc.
As i am automatically able to access the WADL file for my application without doing any manual effort, through below formatted URL:
http://{host}:{port}/{context_root}/{resource}/application.wadl
But now need to know, how this will be generated, I am using jersy 2.0 API over Weblogic Server for REST implementation.
If it is automatically generated then what environment and API needed for this ?
Some wiki Or docs URL will be appreciated.
I think you are looking for this from the Jersey Documentation, which seems to be responsible for the WADL Generation.
17.2. Configuration
WADL generation is enabled in Jersey by default. This means that
OPTIONS methods are added by default to each resource and an
auto-generated /application.wadl resource is deployed too. To override
this default behavior and disable WADL generation in Jersey, setup the
configuration property in your application:
jersey.config.server.wadl.disableWadl=true
This property can be setup in a web.xml if the Jersey application is
deployed in the servlet with web.xml or the property can be returned
from the Application. getProperties(). See Deployment chapter for more
information on setting the application configuration properties in
various deployments.
WADL support in Jersey is implemented via ModelProcessor extension.
This implementation enhances the application resource model by adding
the WADL providing resources. WADL ModelProcessor priority value is
high (i.e. the priority is low) as it should be executed as one of the
last model processors. Therefore, any ModelProcessor executed before
will not see WADL extensions in the resource model. WADL handling
resource model extensions (resources and OPTIONS resource methods) are
not added to the application resource model if there is already a
matching resource or a resource method detected in the model. In other
words, if you define for example your own OPTIONS method that would
produce "application.wadl" response content, this method will not be
overridden by WADL model processor. See Resource builder chapter for
more information on ModelProcessor extension mechanism.
https://jersey.java.net/documentation/latest/wadl.html#d0e13189
You can check in Weblogic documentation as well:
http://docs.oracle.com/cd/E24329_01/web.1211/e24983/develop.htm#RESTF240
i have osgi services service-1.0.0.jar and service-1.1.0.jar they are implementation of service-api-1.0.0.jar
both these service-1.0.0.jar and service-1.1.0.jar have same service name and packages.
service are registered by bundle-activator
lets assume bundle activator is com.abc.xyz.MyActivator - 1.0.0 and 1.1.0
issue I am facing is when I deploy these services and lookup using service tracker and filter on version I want, I always get same implementation regardless of what version chosen.
this makes me believe that what i am trying to achieve is not doable.
I need multiple implementation of service packaged in separate bundles with difference of version and be able to choose dynamically at runtime.
I am trying this in jboss-6.1.1 eap
if i keep different package name in versions looks like it is able to understand that these are 2 different services but when package names are same i get same service implementation.
am i doing something wrong? has anybody tried this?
is it correct that OSGI allow you to deploy multiple versions of service?
UPDATE After using unique package names for MyActivator in 1.0.0 and 1.1.0 looks like the services are able to maintain the uniqueness.
Does that mean Activators has to unique across bundles?
I assume that service-api-1.0.0.jar exports the package which defines the service interface. In that case, it sounds like you have two implementations of the same version of the service. Not different implementations of different versions of the service. So from a service user point of view, the services are that same: they are from the same service api package version.
I think you are using the OSGi services in a strange way. As a client you should not look into the implemention bundles to determine versions or other informations.
Instead you should use the service interface and service properties to distinguish between services.
So for example you can have a property version and publish the first service with version=1 and the second with version=2. Then you can filter for this property to get a specific service.
Using reflection is also a rather unusual thing. Better try to provide classes in the interface package that you use to exchange data between client and service. This will make the client less dependent on the service impl.
If you have multiple implementations of the same service API, and a client queries for an implementation of the service API, it could get any of the implementations. And that's good because the client shouldn't care.
Say for example you have a Greeting interface with multiple implementations registered as services, possibly by multiple bundles. If a client asks OSGi for a Greeting service then OSGi will simply pick one. After all, if you just ask for a Greeting without specifying anything else then you should accept any implementation. Clients certainly shouldn't care which particular bundle the service comes from: this is the nature of decoupling.
Incidentally, when this happens OSGi normally chooses the implementation that was registered first (actually the one with the lowest service.id, which is an ever-incrementing number, so it's effectively the same thing). This is probably why you see OSGi consistently choosing one particular service.
If your client needs to distinguish between service implementations then you can add properties to the published services and filter on those services. For example one bundle could publish a Greeting service with property language=en_US (i.e. US English) and another could publish a Greeting service with language=de. If your client only wants greetings in English then it can use a filter like (language=en*).
I went through http://cxf.apache.org/docs/jax-rs-client-api.html documentation but I am still not sure which type of rest client should be used in what use cases?
Can anyone point out the use cases / constraints with examples that would help me in choosing the right client API.
CXF 3.0 implement the JAXRS 2.0 client API, it makes your code can work with other JAXRS implementation without changing anything.
But if you are still using CXF 2.x, you need to chose between the Proxy Based API and WebClient API.
The Proxy Based API is much like the CXF JAXWS Client API, you can just invoke the service from a Proxy which implement the interface of SEI. It has some shortcomings, you cannot specify the http hears or write a generic client to invoke the different JAXRS services.
With the help of CXF WebClient API, you can invoke the JAXRS services in a normal HTTP client way, which just fill the gap of Proxy Based API.
You can find more information about those clients API here.
I have a webservice running on jboss server. I can't change it to netty because i'm using other features of jboss. But i want to use finagles futures from the client. Is there a way ?
The Future class used in Finagle is part of Twitter's util project, which is open source. com.twitter.util.Future is usable on its own within any project that adds util-core as a dependency.
You can always use a finagle client to make calls to an HTTP [or other RPC protocol] webservice. It doesn't matter how the service is implemented as along as it uses the protocol correctly. If you are using Java, this link should give you details on how to build a finagle client for an HTTP service: https://github.com/twitter/finagle#Building%20a%20Client%20in%20Java
Here's some sample code to for a more elaborate finagle HTTP client: https://github.com/twitter/finagle/blob/master/finagle-example/src/main/scala/com/twitter/finagle/example/http/HttpClient.scala