Hi Alan,
Thank you for the reply. I already started putting together docker-java.
Seems there is a jackson dependency issue in latest 3.0.0 version. Trying
to figure out how to fix this. Will update as soon as I get this sorted out.

Thank you very much for the advice on change of path. Actually Java API
should be straight forward.

See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.
Exception in thread "main" java.lang.NoSuchMethodError:
com.fasterxml.jackson.databind.ObjectReader.forType(Lcom/fasterxml/jackson/databind/JavaType;)Lcom/fasterxml/jackson/databind/ObjectReader;
    at
com.fasterxml.jackson.jaxrs.base.ProviderBase.readFrom(ProviderBase.java:799)
    at
org.glassfish.jersey.message.internal.ReaderInterceptorExecutor$TerminalReaderInterceptor.invokeReadFrom(ReaderInterceptorExecutor.java:264)
    at
org.glassfish.jersey.message.internal.ReaderInterceptorExecutor$TerminalReaderInterceptor.aroundReadFrom(ReaderInterceptorExecutor.java:234)
    at
org.glassfish.jersey.message.internal.ReaderInterceptorExecutor.proceed(ReaderInterceptorExecutor.java:154)
    at
org.glassfish.jersey.message.internal.MessageBodyFactory.readFrom(MessageBodyFactory.java:1124)
    at
org.glassfish.jersey.message.internal.InboundMessageContext.readEntity(InboundMessageContext.java:851)
    at
org.glassfish.jersey.message.internal.InboundMessageContext.readEntity(InboundMessageContext.java:783)
    at
org.glassfish.jersey.client.ClientResponse.readEntity(ClientResponse.java:326)
    at
org.glassfish.jersey.client.JerseyInvocation.translate(JerseyInvocation.java:786)
    at
org.glassfish.jersey.client.JerseyInvocation.access$500(JerseyInvocation.java:91)
    at
org.glassfish.jersey.client.JerseyInvocation$2.call(JerseyInvocation.java:683)
    at org.glassfish.jersey.internal.Errors.process(Errors.java:315)
    at org.glassfish.jersey.internal.Errors.process(Errors.java:297)
    at org.glassfish.





On Tue, Jun 21, 2016 at 6:08 AM, Alan Williams <[email protected]>
wrote:

> On 18-Jun-16 08:12, Nadeesh Dilanga wrote:
>
>> Hi Alan, Hi Stian,
>> Please refer my latest commit @
>>
>> https://github.com/NadeeshDilanga/incubator-taverna-common-activities/commits/docker/taverna-docker-activity
>>
>> where I have implemented reading a injected configuration. Can you please
>> review this and let me know what I am missing here. But one thing I would
>> like to know is, who is responsible of creating(populating) the
>> DockerContainerConfiguration ?
>>
>
> In the workbench, users are able to change such configurations. That is
> normally done under the File -> Preferences. I think for GSOC it is enough
> to specify what needs to be in the configuration.
>
> We have to allow user to give a docker.conf
>> and from which some one construct the DockerContainerConfiguration and
>> inject it to the activity plugin.
>>
>
> Yes, long term we do. However, for GSOC it is enough to take a
> hand-written docker.conf
>
> Your DockerContainerConfigurationImpl certainly looks to have the correct
> type of information.
>
> Then I went through the taverna-engine repo code base looking for the clue
>> Stian gave, where I have to implement Configurable interface, and use
>> ConfigurationManager. And Configuration manager interface had
>> store/populate methods to override, but I found it bit unclear to figure
>> out how exactly I can use that to my use case/how it works/relation ship
>> between Configurable interface and ConfigurationManager. Do we have any
>> documentation on that ?
>>
>
> I am not sure. Stian and Gale may know.
>
> For SSL issue, I am calling the container as
>> https://192.168.99.100:2376/containers/create  where 192.168.99.100 is my
>> container host. I assume that is the target you meant ?
>>
>
> Yes.
>
> Alan
>
>

Reply via email to