occur. Any ideas of what I might be doing wrong?
On Monday, 12 November 2012 11:53:35 UTC, Leander wrote:
> Small update, the tests work with mvn clean test but fail when i try mvn
> install.
> On Mon, Nov 12, 2012 at 11:10 AM, Leander Bessa Beernaert <
> leande...@gmail.com> wrote:
>> I've been sidetracked for a while, but now i'm back to resolving this
>> issue.
>> There is another problem i'm currently facing. I've forked JClouds on
>> GitHub so that I can later push these changes back to it. However, I can
>> seem to compile it or install it.
>> It hangs at this error:
>> Tests run: 753, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 55.663
>> sec <<< FAILURE!
>> testEventBusIsSingleton(org.jclouds.events.config.EventBusModuleTest)
>> Time elapsed: 0.001 sec <<< FAILURE!
>> java.lang.AssertionError: expected [true] but found [false]
>> at org.testng.Assert.fail(Assert.java:94)
>> at org.testng.Assert.failNotEquals(Assert.java:494)
>> at org.testng.Assert.assertTrue(Assert.java:42)
>> at org.testng.Assert.assertTrue(Assert.java:52)
>> at
>> org.jclouds.events.config.EventBusModuleTest.testEventBusIsSingleton(EventB usModuleTest.java:77)
>> Also, since i'm a bit inexperienced with Maven, how can tell a test
>> project to use my version of JClouds instead of the stable one I'm
>> currently using?
>> Regards,
>> Leander
>> On Thu, Oct 18, 2012 at 12:51 PM, Richard Downer <
>> richard.dow...@cloudsoftcorp.com> wrote:
>>> Hi,
>>> I think that something for @ExceptionParser is what you need. Create a
>>> class that implements Function<Exception, Object> (my guess is
>>> that org.jclouds.openstack.nova.v2_0.functions is the right package for it
>>> to belong), and change the @ExceptionParser annotation to refer to your new
>>> class.
>>> Richard.
>>> On 18 October 2012 11:46, Leander Bessa Beernaert <leande...@gmail.com>wrote:
>>>> Thanks, for the info. It turned out to be surprisingly easy :D.
>>>> However, I'm trying to get around something. This OpenStack command may
>>>> not be supported on certain hypervisors. How can i make it so that it
>>>> gracefully handle the http error 500. I currently have the following in
>>>> ServerAsyncApi.java:
>>>> @GET
>>>> @Path("/servers/{id}/diagnostics")
>>>> @Consumes(MediaType.APPLICATION_JSON)
>>>> @ExceptionParser(MapHttp4xxCodesToExceptions.class)
>>>> ListenableFuture<String> getDiagnostics(@PathParam("id") String id);
>>>> Since it isn't supported on my current OpenStack Install, it produces
>>>> the error 500 and the output below is slightly different . Is this expected?
>>>> [i/o thread 0] ERROR
>>>> org.jclouds.http.handlers.BackoffLimitedRetryHandler - Cannot retry after
>>>> server error, command has exceeded retry limit 5:
>>>> [method=ServerAsyncApi.getDiagnostics, request=GET
>>>> http://10.0.107.2:8774/v2/4ebf76425efa4d01bc54a182185444a6/servers/52...]
>>>> org.jclouds.http.HttpResponseException: command: GET
>>>> http://10.0.107.2:8774/v2/4ebf76425efa4d01bc54a182185444a6/servers/52... failed with response: HTTP/1.1 500 Internal Server Error; content:
>>>> [{"computeFault": {"message": "The server has either erred or is incapable
>>>> of performing the requested operation.", "code": 500}}]
>>>> at
>>>> org.jclouds.openstack.nova.v2_0.handlers.NovaErrorHandler.handleError(
>>>> NovaErrorHandler.java:48)
>>>> at org.jclouds.http.handlers.DelegatingErrorHandler.handleError(
>>>> DelegatingErrorHandler.java:71)
>>>> at
>>>> org.jclouds.http.internal.BaseHttpCommandExecutorService$HttpResponseCallab le.shouldContinue(
>>>> BaseHttpCommandExecutorService.java:197)
>>>> at
>>>> org.jclouds.http.internal.BaseHttpCommandExecutorService$HttpResponseCallab le.call(
>>>> BaseHttpCommandExecutorService.java:167)
>>>> at
>>>> org.jclouds.http.internal.BaseHttpCommandExecutorService$HttpResponseCallab le.call(
>>>> BaseHttpCommandExecutorService.java:135)
>>>> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>>>> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>>>> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(
>>>> ThreadPoolExecutor.java:886)
>>>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(
>>>> ThreadPoolExecutor.java:908)
>>>> at java.lang.Thread.run(Thread.java:680)
>>>> at org.jclouds.concurrent.config.DescribingExecutorService.submit(
>>>> DescribingExecutorService.java:89)
>>>> at org.jclouds.http.internal.BaseHttpCommandExecutorService.submit(
>>>> BaseHttpCommandExecutorService.java:132)
>>>> at org.jclouds.http.TransformingHttpCommandExecutorServiceImpl.submit(
>>>> TransformingHttpCommandExecutorServiceImpl.java:54)
>>>> at org.jclouds.http.TransformingHttpCommandImpl.execute(
>>>> TransformingHttpCommandImpl.java:73)
>>>> at
>>>> org.jclouds.rest.internal.AsyncRestClientProxy.createListenableFutureForHtt pRequestMappedToMethodAndArgs(
>>>> AsyncRestClientProxy.java:255)
>>>> at org.jclouds.rest.internal.AsyncRestClientProxy.invoke(
>>>> AsyncRestClientProxy.java:149)
>>>> at $Proxy81.getDiagnostics(Unknown Source)
>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>> at sun.reflect.NativeMethodAccessorImpl.invoke(
>>>> NativeMethodAccessorImpl.java:39)
>>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(
>>>> DelegatingMethodAccessorImpl.java:25)
>>>> at java.lang.reflect.Method.invoke(Method.java:597)
>>>> at org.jclouds.concurrent.internal.SyncProxy.invoke(SyncProxy.java:170)
>>>> at $Proxy82.getDiagnostics(Unknown Source)
>>>> at gsd.JCloudsOpenStack.listImages(JCloudsOpenStack.java:72)
>>>> at gsd.JCloudsOpenStack.main(JCloudsOpenStack.java:34)
>>>> at org.jclouds.concurrent.config.DescribingExecutorService.submit(
>>>> DescribingExecutorService.java:89)
>>>> at org.jclouds.http.internal.BaseHttpCommandExecutorService.submit(
>>>> BaseHttpCommandExecutorService.java:132)
>>>> at org.jclouds.http.TransformingHttpCommandExecutorServiceImpl.submit(
>>>> TransformingHttpCommandExecutorServiceImpl.java:54)
>>>> at org.jclouds.http.TransformingHttpCommandImpl.execute(
>>>> TransformingHttpCommandImpl.java:73)
>>>> at
>>>> org.jclouds.rest.internal.AsyncRestClientProxy.createListenableFutureForHtt pRequestMappedToMethodAndArgs(
>>>> AsyncRestClientProxy.java:255)
>>>> at org.jclouds.rest.internal.AsyncRestClientProxy.invoke(
>>>> AsyncRestClientProxy.java:149)
>>>> at $Proxy81.getDiagnostics(Unknown Source)
>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>> at sun.reflect.NativeMethodAccessorImpl.invoke(
>>>> NativeMethodAccessorImpl.java:39)
>>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(
>>>> DelegatingMethodAccessorImpl.java:25)
>>>> at java.lang.reflect.Method.invoke(Method.java:597)
>>>> at org.jclouds.concurrent.internal.SyncProxy.invoke(SyncProxy.java:170)
>>>> at $Proxy82.getDiagnostics(Unknown Source)
>>>> at gsd.JCloudsOpenStack.listImages(JCloudsOpenStack.java:72)
>>>> at gsd.JCloudsOpenStack.main(JCloudsOpenStack.java:34)
>>>> On Thu, Oct 18, 2012 at 11:06 AM, Richard Downer <
>>>> richard.dow...@cloudsoftcorp.com> wrote:
>>>>> (Replying just to jclouds-dev)
>>>>> On 18 October 2012 10:45, Leander Bessa Beernaert <leande...@gmail.com
>>>>> > wrote:
>>>>>> I've found the ServerAPI file
>>>>>> under ./jclouds/apis/openstack-nova/src/main/java/org/jclouds/openstack/nova/v2_0 /features/ServerApi.java.
>>>>>> Any pointers on how to compile changes using the eclipse setup and using
>>>>>> JClouds REST API?
>>>>> Firstly, there's actually two files you need to change -
>>>>> ServerApi.java and ServerAsyncApi.java. These files are very similar - both
>>>>> should define the same set of methods with the same parameters. The method
>>>>> return types differ slightly in that every return type in the AsyncApi is
>>>>> wrapped with a ListenableFuture<T>. So if the Api class defines a method
>>>>> returning Server, the equivalent method in AsyncApi will return
>>>>> ListenableFuture<Server>; void maps to ListenableFuture<Void>.
>>>>> (Implementation detail: at runtime jclouds creates a proxy for the
>>>>> synchronous Api class. The proxy will, for every method, simply call the
>>>>> equivalent AsyncApi method, and then immediately wait on the completion of
>>>>> the ListenableFuture.)
>>>>> The AsyncApi class also contains lots of annotations - these are
>>>>> crucial as jclouds uses these to determine how to form the request and
>>>>> handle the response. Within a single cloud API these are generally very
>>>>> similar so you can probably copy-and-paste annotations from a similar
>>>>> method (say, get server details) and then modify the annotations for the
>>>>> operation you are working on.
>>>>> In answer to your actual question: everybody's workflow is slightly
>>>>> different and I don't use Eclipse so can't tell you the best way to use
>>>>> that. However what will probably work is if you build from the command line
>>>>> using "mvn clean install" in the apis/openstack-nova folder. This will
>>>>> build the code and install it in your local maven repository. You can then
>>>>> build your application with maven and it will use the jclouds version in
>>>>> your local repository that you have just built.
>>>>> Cheers
>>>>> Richard.
>>>>> --
>>>>> Richard Downer • Lead Engineer • Cloudsoft Corporation •
>>>>> http://www.cloudsoftcorp.com
>>>>> Skype richardcloudsoft • Twitter @FrontierTown
>>> --
>>> Richard Downer • Lead Engineer • Cloudsoft Corporation •
>>> http://www.cloudsoftcorp.com
>>> Skype richardcloudsoft • Twitter @FrontierTown
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "jclouds-dev" group.
>>> To post to this group, send email to jclouds-dev@googlegroups.com.
>>> To unsubscribe from this group, send email to
>>> jclouds-dev+unsubscribe@googlegroups.com.
>>> For more options, visit this group at
>>> http://groups.google.com/group/jclouds-dev?hl=en.