taverna-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nadeesh Dilanga <nadeesh...@gmail.com>
Subject Re: Finalize Docker Invoke JSON format
Date Thu, 23 Jun 2016 06:17:16 GMT
Hi,
With the help of maven dependency tree, was able to rule out all possible
places that packs in old jacksons. And since you mentioned about 2.7.4, I
only added following and was able to get rid of above error. So that means
docker-java can work with 2.7.4. I am in the process of doing code changes
accordingly to implement docker-java utility instead of docker-http.

And I was able to complete the implementation for basic Docker
1. Inspect an Image
2. Create a container from a given image.

And was able to successfully execute these from docker-jave utility I
implemented. I verified the api invocation outputs with raw docker commands
and it was a success.

Now I am creating a full pledged DockerContainerConfiguration  bean with
all supporting params. Will send a pull request as soon as I completes it.

One question, docker container config, that we expect to read as a JSON,
but we need certain params to setup docker client to invoke docker remote
api. Ex: remote host;port, cert path, if we have a special registry, its
url, username/password etc. Shall I accept these as Activity Config
params(the map I get in executeAsync()) ? Or any suggestions for that ?

<dependency>
        <groupId>com.fasterxml.jackson.jaxrs</groupId>
        <artifactId>jackson-jaxrs-json-provider</artifactId>
        <version>2.7.4</version>
</dependency>



On Wed, Jun 22, 2016 at 1:06 PM, Stian Soiland-Reyes <stain@apache.org>
wrote:

> It might be tricky to upgrade to Jackson 3 as we use Jackson 2.7.4 in
> Taverna Language (the Activity's Configuration) - and so this is sadly
> part of our API and we would need to see what could break moving to
> Jackson 3.  What is their breaking changes since they are bumping the
> major version?
>
> (Perhaps we should instead use a neutral JSON API like
> javax.json.JsonObject ?
> http://docs.oracle.com/javaee/7/api/javax/json/JsonObject.html  --
> Apache Johnzon is one implementation)
>
>
>
> On 22 June 2016 at 05:57, Nadeesh Dilanga <nadeesh092@gmail.com> wrote:
> > 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 <alaninmcr@googlemail.com
> >
> > 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
> >>
> >>
>
>
>
> --
> Stian Soiland-Reyes
> Apache Taverna (incubating), Apache Commons
> http://orcid.org/0000-0001-9842-9718
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message