Coder Social home page Coder Social logo

cf-java-client's Introduction

Cloud Foundry Java Client

Maven Central

Artifact Javadocs
cloudfoundry-client javadoc
cloudfoundry-client-reactor javadoc
cloudfoundry-operations javadoc
cloudfoundry-util javadoc

The cf-java-client project is a Java language binding for interacting with a Cloud Foundry instance. The project is broken up into a number of components that expose different levels of abstraction depending on need.

  • cloudfoundry-client – Interfaces, request, and response objects mapping to the Cloud Foundry REST APIs. This project has no implementation and therefore cannot connect to a Cloud Foundry instance on its own.
  • cloudfoundry-client-reactor – The default implementation of the cloudfoundry-client project. This implementation is based on Reactor Netty HttpClient.
  • cloudfoundry-operations – An API and implementation that corresponds to the Cloud Foundry CLI operations. This project builds on the cloudfoundry-client and therefore has a single implementation.

Versions

The Cloud Foundry Java Client has two active versions. The 5.x line is compatible with Spring Boot 2.4.x - 2.6.x just to manage its dependencies, while the 4.x line uses Spring Boot 2.3.x.

Dependencies

Most projects will need two dependencies; the Operations API and an implementation of the Client API. For Maven, the dependencies would be defined like this:

<dependencies>
    <dependency>
        <groupId>org.cloudfoundry</groupId>
        <artifactId>cloudfoundry-client-reactor</artifactId>
        <version>latest.RELEASE</version>
    </dependency>
    <dependency>
        <groupId>org.cloudfoundry</groupId>
        <artifactId>cloudfoundry-operations</artifactId>
        <version>latest.RELEASE</version>
    </dependency>
    ...
</dependencies>

Snapshot artifacts can be found in the Spring snapshot repository:

<repositories>
    <repository>
        <id>spring-snapshots</id>
        <name>Spring Snapshots</name>
        <url>https://repo.spring.io/snapshot</url>
        <snapshots>
            <enabled>true</enabled>
        </snapshots>
    </repository>
    ...
</repositories>

For Gradle, the dependencies would be defined like this:

dependencies {
    compile 'org.cloudfoundry:cloudfoundry-client-reactor:<latest>.RELEASE'
    compile 'org.cloudfoundry:cloudfoundry-operations:<latest>.RELEASE'
    ...
}

Snapshot artifacts can be found in the Spring snapshot repository:

repositories {
    maven { url 'https://repo.spring.io/snapshot' }
    ...
}

Usage

Both the cloudfoundry-operations and cloudfoundry-client projects follow a "Reactive" design pattern and expose their responses with Project Reactor Monoss and Fluxs.

CloudFoundryClient, DopplerClient, UaaClient Builders

The lowest-level building blocks of the API are ConnectionContext and TokenProvider. These types are intended to be shared between instances of the clients, and come with out of the box implementations. To instantiate them, you configure them with builders:

DefaultConnectionContext.builder()
    .apiHost(apiHost)
    .build();

PasswordGrantTokenProvider.builder()
    .password(password)
    .username(username)
    .build();

In Spring-based applications, you'll want to encapsulate them in bean definitions:

@Bean
DefaultConnectionContext connectionContext(@Value("${cf.apiHost}") String apiHost) {
    return DefaultConnectionContext.builder()
        .apiHost(apiHost)
        .build();
}

@Bean
PasswordGrantTokenProvider tokenProvider(@Value("${cf.username}") String username,
                                         @Value("${cf.password}") String password) {
    return PasswordGrantTokenProvider.builder()
        .password(password)
        .username(username)
        .build();
}

CloudFoundryClient, DopplerClient, and UaaClient are only interfaces. Each has a Reactor-based implementation. To instantiate them, you configure them with builders:

ReactorCloudFoundryClient.builder()
    .connectionContext(connectionContext)
    .tokenProvider(tokenProvider)
    .build();

ReactorDopplerClient.builder()
    .connectionContext(connectionContext)
    .tokenProvider(tokenProvider)
    .build();

ReactorUaaClient.builder()
    .connectionContext(connectionContext)
    .tokenProvider(tokenProvider)
    .build();

In Spring-based applications, you'll want to encapsulate them in bean definitions:

@Bean
ReactorCloudFoundryClient cloudFoundryClient(ConnectionContext connectionContext, TokenProvider tokenProvider) {
    return ReactorCloudFoundryClient.builder()
        .connectionContext(connectionContext)
        .tokenProvider(tokenProvider)
        .build();
}

@Bean
ReactorDopplerClient dopplerClient(ConnectionContext connectionContext, TokenProvider tokenProvider) {
    return ReactorDopplerClient.builder()
        .connectionContext(connectionContext)
        .tokenProvider(tokenProvider)
        .build();
}

@Bean
ReactorUaaClient uaaClient(ConnectionContext connectionContext, TokenProvider tokenProvider) {
    return ReactorUaaClient.builder()
        .connectionContext(connectionContext)
        .tokenProvider(tokenProvider)
        .build();
}

CloudFoundryOperations Builder

The CloudFoundryClient, DopplerClient, and UaaClients provide direct access to the raw REST APIs. This level of abstraction provides the most detailed and powerful access to the Cloud Foundry instance, but also requires users to perform quite a lot of orchestration on their own. Most users will instead want to work at the CloudFoundryOperations layer. Once again this is only an interface and the default implementation of this is the DefaultCloudFoundryOperations. To instantiate one, you configure it with a builder:

NOTE: The DefaultCloudfoundryOperations type does not require all clients in order to run. Since not all operations touch all kinds of clients, you can selectively configure the minimum needed. If a client is missing, the first invocation of a method that requires that client will return an error.

DefaultCloudFoundryOperations.builder()
    .cloudFoundryClient(cloudFoundryClient)
    .dopplerClient(dopplerClient)
    .uaaClient(uaaClient)
    .organization("example-organization")
    .space("example-space")
    .build();

In Spring-based applications, you'll want to encapsulate this in a bean definition as well:

@Bean
DefaultCloudFoundryOperations cloudFoundryOperations(CloudFoundryClient cloudFoundryClient,
                                                     DopplerClient dopplerClient,
                                                     UaaClient uaaClient,
                                                     @Value("${cf.organization}") String organization,
                                                     @Value("${cf.space}") String space) {
    return DefaultCloudFoundryOperations.builder()
            .cloudFoundryClient(cloudFoundryClient)
            .dopplerClient(dopplerClient)
            .uaaClient(uaaClient)
            .organization(organization)
            .space(space)
            .build();
}

CloudFoundryOperations APIs

Once you've got a reference to the CloudFoundryOperations, it's time to start making calls to the Cloud Foundry instance. One of the simplest possible operations is list all of the organizations the user is a member of. The following example does three things:

  1. Requests a list of all organizations
  2. Extracts the name of each organization
  3. Prints the name of each organization to System.out
cloudFoundryOperations.organizations()
    .list()
    .map(OrganizationSummary::getName)
    .subscribe(System.out::println);

To relate the example to the description above the following happens:

  1. .list() – Lists the Cloud Foundry organizations as a Flux of elements of type Organization.
  2. .map(...) – Maps each organization to its name (type String). This example uses a method reference; the equivalent lambda would look like organizationSummary -> organizationSummary.getName().
  3. subscribe... – The terminal operation that receives each name in the Flux. Again, this example uses a method reference and the equivalent lambda would look like name -> System.out.println(name).

CloudFoundryClient APIs

As mentioned earlier, the cloudfoundry-operations implementation builds upon the cloudfoundry-client API. That implementation takes advantage of the same reactive style in the lower-level API. The implementation of the Organizations.list() method (which was demonstrated above) looks like the following (roughly):

cloudFoundryClient.organizations()
    .list(ListOrganizationsRequest.builder()
        .page(1)
        .build())
    .flatMapIterable(ListOrganizationsResponse::getResources)
    .map(resource -> OrganizationSummary.builder()
        .id(resource.getMetadata().getId())
        .name(resource.getEntity().getName())
        .build());

The above example is more complicated:

  1. .list(...) – Retrieves the first page of Cloud Foundry organizations.
  2. .flatMapIterable(...) – Substitutes the original Mono with a Flux of the Resources returned by the requested page.
  3. .map(...) – Maps the Resource to an OrganizationSummary type.

Troubleshooting

If you are having issues with the cf-java-client in your applications...

First, read this article on debugging reactive applications and watch this Spring Tips Video also on debugging reactive apps.

Beyond that, it is helpful to capture the following information:

  1. The version of cf-java-client you are using
  2. If you are using Spring Boot & if so, the version
  3. A description of the problem behavior.
  4. A list of things, if any, you have recently changed in your project (even if seemingly unrelated)
  5. If you are getting failures with an operation or client request, capture the request and response information.
    • You may capture basic request and response information by setting the log level for cloudfoundry-client to DEBUG. For example with Spring Boot, set logging.level.cloudfoundry-client=debug.
    • You may perform a wire capture by setting the log level for cloudfoundry-client.wire to TRACE. For example with Spring Boot, set logging.level.cloudfoundry-client.wire=trace.

If you open a Github issue with a request for help, please include as much of the information above as possible and do not forget to sanitize any request/response data posted.

Development

The project depends on Java 8. To build from source and install to your local Maven cache, run the following:

$ git submodule update --init --recursive
$ ./mvnw clean install

It also depends on Immutables and won't compile in IDEs like Eclipse or IntelliJ unless you also have an enabled annotation processor. See this guide for instructions on how to configure your IDE.

To run the integration tests, run the following:

$ ./mvnw -Pintegration-test clean test

To run a specific integration test, run the following replacing with -Dtest=org.cloudfoundry.TestClass#test-method (#test-method is optional):

./mvnw -Pintegration-test clean test -Dtest=org.cloudfoundry.client.v3.ServiceBrokersTest#update

To run tests & enable HTTP trace output, execute:

CLIENT_LOGGING_LEVEL=trace ./mvnw -Pintegration-test clean test

IMPORTANT Integration tests require admin access and should be run against an empty Cloud Foundry instance. The integration tests are destructive, affecting nearly everything on an instance given the chance.

The integration tests require a running instance of Cloud Foundry to test against. To configure the integration tests with the appropriate connection information use the following environment variables:

Name Description
TEST_ADMIN_CLIENTID Client ID for a client with permissions for a Client Credentials grant
TEST_ADMIN_CLIENTSECRET Client secret for a client with permissions for a Client Credentials grant
TEST_ADMIN_PASSWORD Password for a user with admin permissions
TEST_ADMIN_USERNAME Username for a user with admin permissions
TEST_APIHOST The host of a Cloud Foundry instance. Typically something like api.local.pcfdev.io.
TEST_PROXY_HOST (Optional) The host of a proxy to route all requests through
TEST_PROXY_PASSWORD (Optional) The password for a proxy to route all requests through
TEST_PROXY_PORT (Optional) The port of a proxy to route all requests through. Defaults to 8080.
TEST_PROXY_USERNAME (Optional) The username for a proxy to route all requests through
TEST_SKIPSSLVALIDATION (Optional) Whether to skip SSL validation when connecting to the Cloud Foundry instance. Defaults to false.

If you do not have access to a CloudFoundry instance with admin access, you can run one locally using bosh-deployment & cf-deployment and Virtualbox.

For instructions installing Bosh in VirtualBox using bosh-deployment, see the Install Section to install Bosh.

With Bosh installed, follow the deployment guide to get CF installed. You can skip to step 4, since you're installing into VirtualBox. Be sure to read the entire document before you begin, however pay specific attention to this section which has specific instructions for running locally.

Lastly before running the tests, it is strongly recommended that you take a snapshot of the VMs in the environment. This allows for the quick rollback of the environment should the tests break something (they don't generally, integration tests should clean up after themselves).

Contributing

Pull requests and Issues are welcome.

License

This project is released under version 2.0 of the Apache License.

cf-java-client's People

Contributors

abhishek7-sap avatar alighm avatar anthonydahanne avatar arghya88 avatar dsyer avatar enchobelezirev avatar gberche-orange avatar gfriedrich avatar ghillert avatar glyn avatar ivanborislavovdimitrov avatar jtuchscherer avatar lokeshn avatar loxal avatar mheath avatar nebhale avatar nictas avatar o-orand avatar pacphi avatar pivotal-david-osullivan avatar radito3 avatar radoslav-tomov avatar ramnivas avatar s-bortolussi avatar schulzh avatar scottfrederick avatar skuppa avatar theghost5800 avatar twoseat avatar youngm avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

cf-java-client's Issues

Spring 3 and HTTP components version mismatch

This is a question more than an issue.

I'm working on a project that uses this library and something that depends on HTTPCore 4.3. This causes the typical classpath hell issues for the code that assumes 4.3 because cloudfoundry-client-lib brings in Spring 3 which uses an older HTTPCore version.

I see that spring-web in Spring 4 depends on HTTPCore 4.3. Are there any plans to move to Spring 4? I've found a workaround for now, mostly being curious.

Creating Organization/Space?

I searched for a method to create an organization and space in CF, but did not find one. Is it possible to do that from the Java client?

Thanks,

Christoph

Proxy support appears to be missing

I am using maven behind a proxy and maven can download dependencies and other things okay.

However, when I try to cf:push I get connection outs which are usually from attempting to use HTTP in my network without a configured proxy.

The proxy is configured in my maven settings.xml and I am using maven 2.2.1.

Out-of-date license file of cloudfoundry-client-lib

The license file located at [1] is a little out of date. Basically, the file currently has the below content:

SECTION 2: Apache License, V2.0

cloudfoundry-client-lib-0.8.1
cloudfoundry-client-lib-0.8.2
commons-cli-1.2
commons-cli-1.2.0
commons-io-2.1
commons-io-2.1.0

Obviously the more recent versions of the client-lib is missing. It should be updated to something like below, together with more detailed corresponding license content.

SECTION 2: Apache License, V2.0

cloudfoundry-client-lib-0.8.1
cloudfoundry-client-lib-0.8.2
cloudfoundry-client-lib-0.8.3
cloudfoundry-client-lib-0.8.4
cloudfoundry-client-lib-0.8.5
commons-cli-1.2
commons-cli-1.2.0
commons-io-2.1
commons-io-2.1.0

[1] https://github.com/cloudfoundry/vcap-java-client/blob/master/LICENSE

Support streaming of staging logs.

The getStagingLogs() method is intended to be called repeatedly, returning immediately with all available staging log content, until it returns null (indicating that staging is complete and no more logs are available).

Instead, the method currently blocks until all staging output is available, and returns all staging output at once.

The method should be fixed to work as intended, so clients can provide the appearance of streaming output of staging logs.

CloudApplication.getServices() returns null for each service name

It appears that CloudApplication.getServices() doesn't work against the latest Cloud Controller. For each service bound to my application I get an entry in getServices() but the name is null.

client.getApplications().get(0).getServices().get(0) == null;

Digging into the code the problem appears to be in CloudEntityResourceMapper.mapApplicationResource():154

getEntityAttribute(binding, "service_instance", Map.class);

returns null.

Looking through the binding value I don't see the service name anywhere in there. We may need to retrieve the service name using another api call?

push should let CC set the memory default instead of hard coding 512m

When pushing an application with the maven or gradle plugins, if no memory value is specified then the maven plugin currently sets a default value of "512M":

https://github.com/cloudfoundry/cf-java-client/blob/master/cloudfoundry-maven-plugin/src/main/java/org/cloudfoundry/maven/AbstractApplicationAwareCloudFoundryMojo.java#L313

Now that the cloud controller can maintain a default value the maven plugin should honor that setting which is what gcf does today:

https://github.com/cloudfoundry/cloud_controller_ng/blob/master/config/cloud_controller.yml#L27

Thanks,
Mike

Add support for events endpoint

The /v2/spaces/:guid/events CC REST endpoint provides useful information to list events related to an app such as start/stop by HM, or cause of an app stop/crash:

 {
      "metadata": {
        "guid": "85edc0bd-6898-4d83-8be7-5b127ef49fff",
        "url": "/v2/events/85edc0bd-6898-4d83-8be7-5b127ef49fff",
        "created_at": "2013-09-03 10:08:29 +0000",
        "updated_at": null
      },
      "entity": {
        "type": "app.crash",
        "actor": "3d1ea022-ab7c-4f92-9a03-67ebd70f3d4f",
        "actor_type": "app",
        "actee": "3d1ea022-ab7c-4f92-9a03-67ebd70f3d4f",
        "actee_type": "app",
        "timestamp": "2013-09-03 10:08:29 +0000",
        "metadata": {
          "instance": "7ac29c442b4cdf80fb8125e2148b4ff2",
          "index": 0,
          "exit_status": 255,
          "exit_description": "out of memory",
          "reason": "CRASHED"
        },
        "space_guid": "2e5aee21-45fe-4032-a4d5-72e09035e170",
        "space_url": "/v2/spaces/2e5aee21-45fe-4032-a4d5-72e09035e170"
      }
    },

Note that the /v2/apps/:guid/events is also exposed, but returned nothing when I tested it on api.run.pivotal.io

I'm proposing to add support for events into the vcap_java_client with a new domain.ApplicationEvent class returned by the following new methods:

  • List<ApplicationEvent> CloudFoundryOperations.getEvents(int eventOffset, int maxEvents, long starttimestemps, long endtimestamp)
  • and a shorter version List<ApplicationEvent> CloudFoundryOperations.getEvents()

The event endpoint is documented into https://github.com/cloudfoundry/cloud_controller_ng/blob/b8b8397922ed632ec59a0d4502a5a3f290afe02b/spec/controllers/core/app_events_controller_spec.rb

Anyone planning such contrib already or has suggestions for different API ?

Support the stream way to read the remote file

Hi,
Now the cf client supports the methods to read the remote files and returns the whole contents as String, it works in most scenario, while not for binary file and big files. Wonder whether we could add the following methods ?
public InputStream openFile(String appName, int instanceIndex, String filePath, int startPosition, int endPosition)
public InputStream openFile(String appName, int instanceIndex, String filePath, int startPosition) ;
public InputStream openFile(String appName, int instanceIndex, String filePath) ;
Thoughts ?

Add `health_check_timeout` to app push options

A health_check_timeout parameter is now supported in the app create REST API. The cloudfoundry-client-lib createApplication() methods should accept this parameter (possibly as a new field in the Staging object).

support for multi-module projects

at the moment the plugin doesnt support multi-module projects. Once the plugin gets invoked for one of the .war's submodules it fails and aborts the build

Deploying applications can give: java.lang.OutOfMemoryError: Java heap space

Here is a sample stack trace:

Caused by: java.lang.OutOfMemoryError: Java heap space
        at java.util.Arrays.copyOf(Arrays.java:2786)
        at java.io.ByteArrayOutputStream.write(ByteArrayOutputStream.java:94)
        at org.springframework.util.FileCopyUtils.copy(FileCopyUtils.java:113)
        at org.cloudfoundry.client.lib.util.UploadApplicationPayloadHttpMessageConverter.write(UploadApplicationPayloadHttpMessageConverter.java:67)
        at org.cloudfoundry.client.lib.util.UploadApplicationPayloadHttpMessageConverter.write(UploadApplicationPayloadHttpMessageConverter.java:39)
        at org.springframework.http.converter.FormHttpMessageConverter.writePart(FormHttpMessageConverter.java:306)
        at org.springframework.http.converter.FormHttpMessageConverter.writeParts(FormHttpMessageConverter.java:270)
        at org.springframework.http.converter.FormHttpMessageConverter.writeMultipart(FormHttpMessageConverter.java:260)
        at org.springframework.http.converter.FormHttpMessageConverter.write(FormHttpMessageConverter.java:200)
        at org.springframework.http.converter.FormHttpMessageConverter.write(FormHttpMessageConverter.java:1)
        at org.springframework.web.client.RestTemplate$HttpEntityRequestCallback.doWithRequest(RestTemplate.java:588)
        at org.springframework.web.client.RestTemplate.doExecute(RestTemplate.java:436)
        at org.cloudfoundry.client.lib.rest.LoggingRestTemplate.doExecute(LoggingRestTemplate.java:54)
        at org.springframework.web.client.RestTemplate.execute(RestTemplate.java:401)
        at org.springframework.web.client.RestTemplate.postForLocation(RestTemplate.java:257)
        at org.cloudfoundry.client.lib.rest.CloudControllerClientV1.uploadApplication(CloudControllerClientV1.java:319)
        at org.cloudfoundry.client.lib.rest.CloudControllerClientV1.doUploadApplicationZipFile(CloudControllerClientV1.java:531)
        at org.cloudfoundry.client.lib.rest.CloudControllerClientV1.uploadApplication(CloudControllerClientV1.java:301)

Seems the culprit is that

https://github.com/cloudfoundry/vcap-java-client/blob/master/cloudfoundry-client-lib/src/main/java/org/cloudfoundry/client/lib/util/UploadApplicationPayloadHttpMessageConverter.java#L67

is being handed a ByteArrayOutputStream rather than chunking the payload.

Given that the client can be used embedded within other applications, and also that it is legitimate to deploy an application that is larger than the deploying machines available memory, it is not a valid solution to mandate increasing memory. Deploying applications should be chunked or at the very least use a modified BAOS that spills over to disk past a certain size.

proxy settings ignored in gradle build

I have a problem using the gradle plugin in a proxy environment -- using version 1.0.1 of the cf plugin.

Things I've tried so far:

  1. Set global gradle proxies as described in section 20.2 http://www.gradle.org/docs/current/userguide/build_environment.html
  2. Setting the proxy directly as java system properties for a gradle build ./gradlew cf-login -Dhttp.proxyHost=xxx -Dhttp.proxyPort=yyyy -Dhttps.proxyHost=xxx -Dhttps.proxyPort=yyy
  3. Setting bash variables for the proxy settings export https_proxy=xxx:yyy

so far, nothing had any effect.

I was working with the public CF installation at https://api.run.pivotal.io using gradle 1.8.

cloudfoundry-client-lib depends on old jackson1 version 1.6.2

Is there a reason to stick to jackson 1.6.2 ? Would a PR upgrading to jackson 1.9.13 (current version spring depends) or jackson 2.3.1 likely to be accepted ?

More details below:

cloudfoundry-client-lib depends on

                optional("org.codehaus.jackson:jackson-mapper-asl:1.4.2")
                optional("com.fasterxml.jackson.core:jackson-databind:2.0.1")

Some other java components in the cloudfoundry java community rely on more up_to-date jackson implementations:

Latest spring itself depends on https://github.com/spring-projects/spring-framework/blob/master/build.gradle#L22

   ext.jackson1Version = "1.9.13"
   ext.jackson2Version = "2.3.1"

This makes it hard for customers that need to interact both with java-nats and cf-java-client as the jackson1 dependency conflicts or fail at runtime:

I'm currently getting the following runtime exception (still diagnosing which version bump broke it)

com.fasterxml.jackson.databind.JsonMappingException: Can not construct instance of org.springframework.security.oauth2.common.OAuth2AccessToken, problem: abstract types either need to be mapped to concrete types, have custom deserializer, or be instantiated with additional type information
 at [Source: org.apache.http.conn.EofSensorInputStream@774ad8b2; line: 1, column: 1]
        at com.fasterxml.jackson.databind.JsonMappingException.from(JsonMappingException.java:164) ~[jackson-databind-2.2.2.jar:2.2.2]
        at com.fasterxml.jackson.databind.DeserializationContext.instantiationException(DeserializationContext.java:600) ~[jackson-databind-2.2.2.jar:2.2.2]
        at com.fasterxml.jackson.databind.deser.AbstractDeserializer.deserialize(AbstractDeserializer.java:114) ~[jackson-databind-2.2.2.jar:2.2.2]
        at com.fasterxml.jackson.databind.ObjectMapper._readMapAndClose(ObjectMapper.java:2888) ~[jackson-databind-2.2.2.jar:2.2.2]
        at com.fasterxml.jackson.databind.ObjectMapper.readValue(ObjectMapper.java:2094) ~[jackson-databind-2.2.2.jar:2.2.2]
        at org.springframework.http.converter.json.MappingJackson2HttpMessageConverter.readInternal(MappingJackson2HttpMessageConverter.java:123) ~[spring-web-3.1.3.RELEASE.jar:3.1.3.RELEASE]
Wrapped by: org.springframework.http.converter.HttpMessageNotReadableException: Could not read JSON: Can not construct instance of org.springframework.security.oauth2.common.OAuth2AccessToken, problem: abstract types either need to be mapped to concrete types, have custom deserializer, or be instantiated with additional type information
 at [Source: org.apache.http.conn.EofSensorInputStream@774ad8b2; line: 1, column: 1]; nested exception is com.fasterxml.jackson.databind.JsonMappingException: Can not construct instance of org.springframework.security.oauth2.common.OAuth2AccessToken, problem: abstract types either need to be mapped to concrete types, have custom deserializer, or be instantiated with additional type information
 at [Source: org.apache.http.conn.EofSensorInputStream@774ad8b2; line: 1, column: 1]
        at org.springframework.http.converter.json.MappingJackson2HttpMessageConverter.readInternal(MappingJackson2HttpMessageConverter.java:126) ~[spring-web-3.1.3.RELEASE.jar:3.1.3.RELEASE]
        at org.springframework.http.converter.AbstractHttpMessageConverter.read(AbstractHttpMessageConverter.java:153) ~[spring-web-3.1.3.RELEASE.jar:3.1.3.RELEASE]
        at org.springframework.web.client.HttpMessageConverterExtractor.extractData(HttpMessageConverterExtractor.java:81) ~[spring-web-3.1.3.RELEASE.jar:3.1.3.RELEASE]
        at org.springframework.web.client.RestTemplate.doExecute(RestTemplate.java:454) ~[spring-web-3.1.3.RELEASE.jar:3.1.3.RELEASE]
        at org.springframework.web.client.RestTemplate.execute(RestTemplate.java:417) ~[spring-web-3.1.3.RELEASE.jar:3.1.3.RELEASE]
        at org.springframework.security.oauth2.client.token.OAuth2AccessTokenSupport.retrieveToken(OAuth2AccessTokenSupport.java:102) ~[spring-security-oauth2-1.0.0.RELEASE.jar:na]
        at org.springframework.security.oauth2.client.token.grant.password.ResourceOwnerPasswordAccessTokenProvider.obtainAccessToken(ResourceOwnerPasswordAccessTokenProvider.java:47) ~[spring-security-oauth2-1.0.0.RELEASE.jar:na]
        at org.cloudfoundry.client.lib.oauth2.OauthClient.getToken(OauthClient.java:67) ~[cloudfoundry-client-lib-0.8.7-orange-oauth-fix.jar:na]

Any suggestion for short-term fix ?

Cannot deploy app with more than 2G of RAM using maven plugin

Currently with the maven plugin you cannot deploy an application using more than 2G. the Maven plugin should update to follow the same convention of CF which, I believe, allows for free form memory settings. The code involved appears to be:

https://github.com/cloudfoundry/cf-java-client/blob/master/cloudfoundry-client-lib/src/main/java/org/cloudfoundry/client/lib/rest/CloudControllerClientImpl.java#L239

https://github.com/cloudfoundry/cf-java-client/blob/master/cloudfoundry-maven-plugin/src/main/java/org/cloudfoundry/maven/AbstractPush.java#L179

Here is the error I get:

 [ERROR] Failed to execute goal org.cloudfoundry:cf-maven-plugin:1.0.1:push-only (push-cf) on project MLU-Services-alm: An exception was caught while executing Mojo. Memory must be one of the following values: 64, 128, 256, 512, 1024, 2048 -> [Help 1]
 org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.cloudfoundry:cf-maven-plugin:1.0.1:push-only (push-cf) on project MLU-Services-alm: An exception was caught while executing Mojo.
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
    at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319)
    at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
    at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
    at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
    at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:601)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
 Caused by: org.apache.maven.plugin.MojoExecutionException: An exception was caught while executing Mojo.
    at org.cloudfoundry.maven.AbstractCloudFoundryMojo.execute(AbstractCloudFoundryMojo.java:235)
    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
    ... 19 more
 Caused by: java.lang.IllegalStateException: Memory must be one of the following values: 64, 128, 256, 512, 1024, 2048
    at org.cloudfoundry.maven.AbstractPush.validateMemoryChoice(AbstractPush.java:203)
    at org.cloudfoundry.maven.AbstractPush.validateMemoryChoice(AbstractPush.java:182)
    at org.cloudfoundry.maven.AbstractPush.doExecute(AbstractPush.java:62)
    at org.cloudfoundry.maven.AbstractCloudFoundryMojo.execute(AbstractCloudFoundryMojo.java:233)
    ... 21 more

Cloudfoundry-maven-plugin: Provide better error messages when incorrect Url parameters are used

Currently we provide the following error message when an incorrect url parameter is used. This needs to be refined, providing better guidance to the user on how to fix the issue, e.g. incl. the value of the used Url parameter in the error message.

Sep 26, 2011 10:14:26 AM org.springframework.web.client.RestTemplate handleResponseError
WARNING: GET request for "http://api.cloudfoundry.com/apps/hello-java2" resulted in 404 (Not Found); invoking error handler
Sep 26, 2011 10:14:26 AM org.springframework.web.client.RestTemplate handleResponseError
WARNING: POST request for "http://api.cloudfoundry.com/apps" resulted in 403 (Forbidden); invoking error handler
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 3.864s
[INFO] Finished at: Mon Sep 26 10:14:26 EDT 2011
[INFO] Final Memory: 7M/81M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.cloudfoundry:cf-maven-plugin:1.0.0.BUILD-SNAPSHOT:push (default-cli) on project hello-java2: Error while creating application 'hello-java2'. Error message: '403 Forbidden'. Description: 'External URIs are not enabled for this account' -> [Help 1]
[ERROR] 

app uploaded as a directory from Windows fails to start

The archive file that gets created in /var/vcap/shared/droplets, when unzipped, has backslashes in the file names. These are valid file name characters on Linux so the directory structure of the application is lost. It works using vmc instead of the java client.

[Gradle] Rename all tasks to use camelCase

Tasks in the Gradle plugin are named with the form cf-task-name. This makes it difficult to use the task names in Groovy expressions since the - characters are taken as part of an expression (i.e. a "minus" sign) instead of part of a variable name.

It is more typical to use the form cfTaskName in Gradle tasks. Please comment on this issue if you have concerns about this backward-incompatible change.

Feature request: service broker registration

It would be convenient to have a way to do what

cf create-service-broker

does this client. Brokers may want to register themselves with CC e.g. on start.

Happy to work on a pull request but not sure how to run integration tests yet.

setCloudSpace method needed in CloudFoundryClient api

We are using vcap-java-client 0.8.5 to connect to CF NG(V2) and find the current api is a little bit inconvenient.

As we know, to use vcap-java-client, we have to provide CloudSpace instance to the constructor of CloudFoundryClient. Otherwise, it will not work when creating applications.
However, we tried to create CloudSpace object and related Organization Object and put it into constructor of CloudFoundryClient, but it doesn't work. So as a workaround, we are using the following invocation sequence:

CloudFoundryClient client = new CloudFoundryClient(credentials, endpoint, httpProxy, null); //create a client without CloudSpace
client.login(); //login
client.getSpaces(); //get spaces from cf
for (CloudSpace space : spaces) .....//find the space using a loop through spaces
client = new CloudFoundryClient(credentials, endpoint, httpProxy, space);
//create a client again with space
client.login(); //login again.

It is a little awkward since we need to create two cloudfoundry client and login twice. Is it possible to add a method like setCloudSpace in class CloudFoundryClient so that we don't need to go through the sequence to finally get a usable client? Also, it may be better if a method like getSpace(Stirng spaceName) is provided in the class as well.

If there is already an alternative way to do that, please suggest it to me.
Thanks a lot.

Is service version manatory for creating services of service broker v2 api?

Hello,
We are using java client to create a service whose service broker is implemented in broker api v2. We find that there is nowhere to set the version of service to the catalog of v2 api. However, it is still a must parameter for creating a service in java client. Please check the code below in class CloudControllerClientImpl.

It seems method createService requires version should not be null but findPlanForService can deal with null version situation.
Could you please tell me whether version should still be mandatory? If so, how can we set service version in service broker v2 api implementation?
Thanks for your help.

public void createService(CloudService service) {
Assert.notNull(sessionSpace, "Unable to create service without specifying space to use");
Assert.notNull(service, "Service must not be null");
Assert.notNull(service.getName(), "Service name must not be null");
Assert.notNull(service.getLabel(), "Service label must not be null");
Assert.notNull(service.getVersion(), "Service version must not be null");
Assert.notNull(service.getPlan(), "Service plan must not be null");

            CloudServicePlan cloudServicePlan = findPlanForService(service);

            HashMap<String, Object> serviceRequest = new HashMap<String, Object>();
            serviceRequest.put("space_guid", sessionSpace.getMeta().getGuid());
            serviceRequest.put("name", service.getName());
            serviceRequest.put("service_plan_guid", cloudServicePlan.getMeta().getGuid());
            getRestTemplate().postForObject(getUrl("/v2/service_instances"), serviceRequest, String.class);
    }

    private CloudServicePlan findPlanForService(CloudService service) {
            List<CloudServiceOffering> offerings = getServiceOfferings(service.getLabel());
            for (CloudServiceOffering offering : offerings) {
                    if (service.getVersion() != null || service.getVersion().equals(offering.getVersion())) {
                            for (CloudServicePlan plan : offering.getCloudServicePlans()) {
                                    if (service.getPlan() != null && service.getPlan().equals(plan.getName())) {
                                            return plan;
                                    }
                            }
                    }
            }
            throw new IllegalArgumentException("Service plan " + service.getPlan() + " not found");
    }

Inconsistent data returned from CloudFoundryOperations.getServices() compared to CloudFoundryOperations.getService("my-service")

Iterating through the results of a call to client.getServices() returns data that looks like:

Service
    label: elephantsql
    name: springmvc-hibernate-db
    plan: turtle
    provider: elephantsql
    version: n/a
Service
    label: rediscloud
    name: springmvc-hibernate-redis
    plan: 20mb
    provider: garantiadata
    version: n/a

Whereas retrieving a single service directly, client.getService("springmvc-hibernate-db") , results in null values.

Service
    label: null
    name: springmvc-hibernate-db
    plan: null
    provider: null
    version: null

I'm seeing this in cloudfoundry-client-lib version 0.8.6.

Cannot set the disk_quota

We can have manifest with disk size when deploying application but it is not possible when we use API.

applications:
- path: dist.zip
  instances: 1
  memory: 3G
  name: testapp
  disk: 3G
  domain: testdomain.com
  command: bin/start.sh

Can we add the feature or is it hidden somewhere?

Thanks,
-Sridharan

Parameter 'organization' causes NPE

I was trying to do a gradle cf-login with an organisation provided. The organisation was created by an other account and I was only invited to this org. When I remove the organisation parameter, everything works as expected.

Here is the Stacktrace:

Caused by: java.lang.NullPointerException
    at org.cloudfoundry.client.lib.rest.CloudControllerClientImpl.<init>(CloudControllerClientImpl.java:175)
    at org.cloudfoundry.client.lib.rest.CloudControllerClientFactory.newCloudController(CloudControllerClientFactory.java:77)
    at org.cloudfoundry.client.lib.CloudFoundryClient.<init>(CloudFoundryClient.java:106)
    at org.cloudfoundry.client.lib.CloudFoundryClient.<init>(CloudFoundryClient.java:78)
    at org.cloudfoundry.gradle.tasks.AbstractCloudFoundryTask.createClientWithUsernamePassword(AbstractCloudFoundryTask.groovy:102)
    at org.cloudfoundry.gradle.tasks.LoginCloudFoundryTask.login(LoginCloudFoundryTask.groovy:42)
    at org.gradle.util.JavaMethod.invoke(JavaMethod.java:62)
    at org.gradle.api.internal.project.taskfactory.AnnotationProcessingTaskFactory$StandardTaskAction.doExecute(AnnotationProcessingTaskFactory.java:219)
    at org.gradle.api.internal.project.taskfactory.AnnotationProcessingTaskFactory$StandardTaskAction.execute(AnnotationProcessingTaskFactory.java:212)
    at org.gradle.api.internal.project.taskfactory.AnnotationProcessingTaskFactory$StandardTaskAction.execute(AnnotationProcessingTaskFactory.java:201)
    at org.gradle.api.internal.AbstractTask$TaskActionWrapper.execute(AbstractTask.java:527)
    at org.gradle.api.internal.AbstractTask$TaskActionWrapper.execute(AbstractTask.java:510)
    at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeAction(ExecuteActionsTaskExecuter.java:80)
    at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:61)
    ... 52 more

Staging.getBuildpackUrl() and Staging.getCommand() return the string "null" instead of null

This is a small thing but not what I would expect.

This is what happens if you specify neither a command nor buildpack.

        CloudApplication app = client.getApplication("my-app");
        assert app.getStaging().getBuildpackUrl().equals("null");
        assert app.getStaging().getCommand().equals("null");```

I would expect

    CloudApplication app = client.getApplication("my-app");
    assert app.getStaging().getBuildpackUrl() == null;
    assert app.getStaging().getCommand() == null;

CloudFoundryClient.getCloudInfo() throws an exception when targeting v2

When using cloudfoundry-client-lib and targeting a CF v2 environment, the CloudFoundryClient.getCloudInfo() throws an exception every time.

Apr 24, 2013 2:41:19 PM org.springframework.web.client.RestTemplate handleResponseError
WARNING: GET request for "http://api.a1.cf-app.com/v2/runtimes" resulted in 404 (Not Found); invoking error handler
Exception in thread "main" org.cloudfoundry.client.lib.CloudFoundryException: 404 Not Found (Unknown request)
    at org.cloudfoundry.client.lib.rest.AbstractCloudControllerClient$ErrorHandler.handleError(AbstractCloudControllerClient.java:357)
    at org.springframework.web.client.RestTemplate.handleResponseError(RestTemplate.java:486)
    at org.springframework.web.client.RestTemplate.doExecute(RestTemplate.java:443)
    at org.cloudfoundry.client.lib.rest.LoggingRestTemplate.doExecute(LoggingRestTemplate.java:54)
    at org.springframework.web.client.RestTemplate.execute(RestTemplate.java:401)
    at org.springframework.web.client.RestTemplate.getForObject(RestTemplate.java:199)
    at org.cloudfoundry.client.lib.rest.CloudControllerClientV2.getAllResources(CloudControllerClientV2.java:436)
    at org.cloudfoundry.client.lib.rest.CloudControllerClientV2.getInfoForRuntimes(CloudControllerClientV2.java:1104)
    at org.cloudfoundry.client.lib.rest.CloudControllerClientV2.getInfo(CloudControllerClientV2.java:145)
    at org.cloudfoundry.client.lib.CloudFoundryClient.getCloudInfo(CloudFoundryClient.java:101)
    at org.cloudfoundry.sample.JavaSample.main(JavaSample.java:24)

This is caused by the fact that getCloudInfo() attempts to show runtimes and frameworks info, but these REST endpionts (/v2/runtimes and /v2/frameworks) do not exists.

CF ungracious failure on CF-PUSH when Target Resources Exhausted

While testing version 1.0.2 of the CF gradle plugin, my anynines.com target only allows a maximum of resources. i did not see that i had exceeded their limit and tried a CF-PUSH to that target. The gradle plugin failed with http response code 400 because of it and forced a java dump in my joblog thus killing my gradle script. Do we have a way to programatically see the exit code for the CF plugin after the completion of a CF task ?

can send you a full trace log by email if you need it but here is the relevant extracts:

18:12:04.031 [DEBUG] [org.gradle.api.Task] REQUEST: POST https://api.de.a9s.eu/v2/apps
18:12:04.031 [DEBUG] [org.gradle.api.Task] RESPONSE: 400 ERROR 400 Bad Request
18:12:04.046 [DEBUG] [org.gradle.api.internal.tasks.execution.ExecuteAtMostOnceTaskExecuter] Finished executing task ':asciidoctor-project:cf-push'

18:12:04.718 [ERROR] [org.gradle.BuildExceptionReporter] Caused by: org.cloudfoundry.client.lib.CloudFoundryException: 400 Bad Request (You have exceeded your organization's memory
limit. Please login to your account and upgrade. If you are trying to scale down and you are receiving this error, you can either delete an app or contact support.)
18:12:04.734 [ERROR] [org.gradle.BuildExceptionReporter] at org.cloudfoundry.client.lib.rest.CloudControllerResponseErrorHandler.getException(CloudControllerResponseErrorHand
ler.java:69)

Environment variable casting issue

When environment variable LDAP_INT_ENABLED = true contains Boolean value then casting Boolean to String fails.

java.lang.ClassCastException: java.lang.Boolean cannot be cast to java.lang.String
       at org.cloudfoundry.client.lib.domain.CloudApplication.setEnv(CloudApplication.java:205)

NullPointerException occurred when try to use java client to login to a cloudfoundry V2(NG)

I have tried to use java client 0.8.3/0.8.4/0.8.5 to login to a cloudfoundry V2, but got the following exception.
It seems when java client try to obtain access token, the response doesn't contains a "Location" header, which lead to a NullPointerException when extracting data from response in method ImplicitAccessTokenProvider.ImplicitResponseExtractor.extractData.
Please help me with this issue.

Exception in thread "main" java.lang.NullPointerException
at org.cloudfoundry.client.lib.rest.LoggingRestTemplate$1.extractData(LoggingRestTemplate.java:66)
at org.springframework.web.client.RestTemplate.doExecute(RestTemplate.java:491)
at org.cloudfoundry.client.lib.rest.LoggingRestTemplate.doExecute(LoggingRestTemplate.java:54)
at org.springframework.web.client.RestTemplate.execute(RestTemplate.java:454)
at org.springframework.security.oauth2.client.token.OAuth2AccessTokenSupport.retrieveToken(OAuth2AccessTokenSupport.java:92)
at org.springframework.security.oauth2.client.token.grant.implicit.ImplicitAccessTokenProvider.obtainAccessToken(ImplicitAccessTokenProvider.java:61)
at org.cloudfoundry.client.lib.oauth2.OauthClient.getToken(OauthClient.java:72)
at org.cloudfoundry.client.lib.rest.CloudControllerClientV2.login(CloudControllerClientV2.java:179)
at org.cloudfoundry.client.lib.CloudFoundryClient.login(CloudFoundryClient.java:135)

maven plugin doc still uses version 1.0.0

I struggled with getting the plugin to work because I was using version 1.0.0 as described in the README.md file.
I eventually found a post which said a bug related to my problem was fixed with version 1.0.1.
Please update README.md to reflect latest working plugin version.

Feature Request: [Gradle/Maven plugin] Allow directory upload

At least in the gradle plugin you can only specify files for being uploaded. It would be great if this restriction could be dropped out to support the upload of directories.

Use case: This would allow uploading an directory that uses the nginx buildpack (https://github.com/cloudfoundry-community/nginx-buildpack.git) with the gradle plugin (cf-deploy). You could do a zero-downtime-deployment with this task for different application types and make these plugins a 'full-featured' alternative to the CLI.

cf-java-client doesn't support uris without a host

Currently with the Ruby CF command line it is possible to provide a value for a domain and "none" for the host. Which will deploy the application to a url the value of just the domain.

This is not possible with the maven plugin currently. The cf-java-client appears to require a "host" when parsing the uris. When CF itself doesn't appear to require this.

We need this because several applications have custom none wildcard urls that they wish to map to.

The problematic code appears to be here:

https://github.com/cloudfoundry/cf-java-client/blob/master/cloudfoundry-client-lib/src/main/java/org/cloudfoundry/client/lib/rest/CloudControllerClientImpl.java#L958

The error I get when trying to set the uri to a domain is:

[ERROR] Failed to execute goal org.cloudfoundry:cf-maven-plugin:1.0.1:push-only (push-cf) on project some-project: An exception was caught while executing Mojo. Invalid URI https://somedomain.com -- host not specified for domain somedomain.com -> [Help 1]
 org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.cloudfoundry:cf-maven-plugin:1.0.1:push-only (push-cf) on project some-project: An exception was caught while executing Mojo.
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
    at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319)
    at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
    at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
    at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
    at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:601)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
 Caused by: org.apache.maven.plugin.MojoExecutionException: An exception was caught while executing Mojo.
    at org.cloudfoundry.maven.AbstractCloudFoundryMojo.execute(AbstractCloudFoundryMojo.java:235)
    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
    ... 19 more
 Caused by: java.lang.IllegalArgumentException: Invalid URI https://somedomain.com -- host not specified for domain /somedomain.com
    at org.cloudfoundry.client.lib.rest.CloudControllerClientImpl.extractUriInfo(CloudControllerClientImpl.java:933)
    at org.cloudfoundry.client.lib.rest.CloudControllerClientImpl.addUris(CloudControllerClientImpl.java:898)
    at org.cloudfoundry.client.lib.rest.CloudControllerClientImpl.updateApplicationUris(CloudControllerClientImpl.java:1228)
    at org.cloudfoundry.client.lib.CloudFoundryClient.updateApplicationUris(CloudFoundryClient.java:250)
    at org.cloudfoundry.maven.AbstractPush.createApplication(AbstractPush.java:153)
    at org.cloudfoundry.maven.AbstractPush.doExecute(AbstractPush.java:82)
    at org.cloudfoundry.maven.AbstractCloudFoundryMojo.execute(AbstractCloudFoundryMojo.java:233)
    ... 21 more

mvn clean install inside of cloudfoundry-client-lib failed the build

The default profile that excludes the CloudFoundryClientTest.java is not activated by default. Guess it is due to other profile was activated.

mvn help:active-profiles
The following profiles are active:

  • mac-toolsjar-profile (source: pom)

mvn clean install -Ddefault will work.

Uknown configuration element "services"

I am trying to deploy application using "mvn cf:push" with configuration (from example in README):

org.cloudfoundry cf-maven-plugin 1.0.0.M2 standalone bin/demo target/appassembler XXXX XXXX XXXX rabbitmq123 rabbitmq

But getting maven error:

[ERROR] Failed to execute goal org.cloudfoundry:cf-maven-plugin:1.0.0.M2:push (default-cli) on project twitter2rabbit: U
nable to parse configuration of mojo org.cloudfoundry:cf-maven-plugin:1.0.0.M2:push: When configuring a basic element th
e configuration cannot contain any child elements. Configuration element 'services'. -> [Help 1]

I see no configuration element "services" here - https://github.com/cloudfoundry/vcap-java-client/blob/master/cloudfoundry-maven-plugin/src/main/java/org/cloudfoundry/maven/common/SystemProperties.java - probably this is the reason of error?

Works fine without specifying "services" xml element.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.