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 <[email protected]> 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 <[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 >> >> -- Stian Soiland-Reyes Apache Taverna (incubating), Apache Commons http://orcid.org/0000-0001-9842-9718
