StardogException - needs a boundary value

Moved from the mailing list: Portions of relevant emails included for context, with initials to distinguish who said what.


BT:
I just updated to 4.2.2 and am running into some issues with code that previously worked.
I saw that this was a previous issue that was solved by changing HTTPClient to 4.4.x. I did this
and rebuilt my project, but I'm still getting "Needs a boundary value".

The AdminConnection (admin) is fine, my project is actually failing when making a Connection from admin. Here's the code:

    File file = new File(path);
    Connection conn = null;

    // Load file and then delete it
    try {
        FileWriter fw = new FileWriter(file);
        BufferedWriter bw = new BufferedWriter(fw);
        bw.write(inputFile);
        bw.close();
        fw.close();

        conn = admin.memory(graphTitle).create(file.toPath()).connect();
        file.delete();

    } catch (StardogException|IOException e) {

        file.delete();
        throw e;
    }

    return conn;

ZW:
Looks like the actual error is probably coming from netty having a problem decoding multipart form data. I'd double check to make sure you actually reverted the HTTPClient version then you might want to check other dependencies starting with netty.

Hope this helps.

Since you just upgraded you might want to grab the latest 4.2.3 while you're at it.


BT:
Thanks for getting back to me. I upgraded to 4.2.3 and made sure the old HTTPClient files were deleted from my system. While I was at it, I also deleted the old Stardog files and recompiled.

I wasn't using Netty previously so I put the following in my dependencies to see if it helped:

compile "io.netty:netty-all:4.1.8.Final"
compile "org.jboss.netty:netty:3.2.10.Final"

Still getting the same error, though. Is there another dependency I might be missing that's required for 4.x that wasn't used in earlier versions?


ZW:
If you're not using netty you definitely don't want to put it in there. Stardog uses netty and I was just pointing out that the stack trace was throwing a StardogException but the underlying problem was probably coming from netty which Stardog uses. I didn't know what your dependencies are so I was just suggesting that it was something you might want to look at it if it was in there. Just deleting HTTPClient isn't going to help if it's being pulled in as a transitive dependency. It appears as though you're using gradle. To check your dependencies try running one of the following and exclude any dependencies that are causing problems Learning the Basics


HO:
We've had this issue, and discovered that we were getting in newer versions of HttpClient through our Elasticsearch dependency in the pom.

Search in your dependency tree to see if you can find other HttpClients, and then exclude them.

Previous discussion: Redirecting to Google Groups


BT:
It looks like all the transient dependencies for HTTPClient are 4.4.1, which is the version I reverted back to. Nothing is bringing in a newer version. Should I still exclude it?

I've been looking around trying to figure it out and I'm at a loss. I ran a dependencyInsight for httpclient and it's all 4.4.1. Netty is all the same version as well. I'm still getting the "needs a boundary value" error after trying a variety of different things. I'm not quite sure what else to check.


HO:
Just found out that this happens if you are running stardog 4.2.2 and using the java libraries for 4.2.3.


BT:
I'm running 4.2.3 and using the libraries for 4.2.3 - I got a different error when I forgot to change them.

Thanks Stephen!

Zach previously asked that I share my build.gradle so I’m posting it here.

buildscript {
repositories {
    mavenCentral()
    maven {
  		url "https://plugins.gradle.org/m2/"
	}
}
dependencies {
    classpath("org.springframework.boot:spring-boot-gradle-plugin:1.4.2.RELEASE")
    classpath("org.sonarsource.scanner.gradle:sonarqube-gradle-plugin:2.2.1")
    }
}

apply plugin: "org.springframework.boot"
apply plugin: 'java'
apply plugin: 'eclipse'
apply plugin: 'org.sonarqube'
apply plugin: 'war'

war {
baseName = 'OntoGraph'
version = '2.3'
}

jar {
    baseName = 'OntoGraph'
}

sonarqube {
    properties {
        property "sonar.host.url", "http://sonar.ninepts.local"
    }
}

repositories {
jcenter()
maven {
	url "http://maven.stardog.com"
    }
    mavenCentral()
    mavenLocal()
}

version =  '2.3.2'
sourceCompatibility = 1.8
targetCompatibility = 1.8

configurations {
// Spring Boot includes Logback and Slf4j, so exclude from other package
    all*.exclude module : "slf4j-jdk14"
}

ext {	
aspectjVersion = "1.8.9"
commonsIoVersion = "2.5"
commonsLangVersion = "3.5"
groovyVersion = "2.4.7"
httpClientVersion = "4.4.1"
    httpCoreVersion = "4.4.1"
lombokVersion = "1.16.10"
orgJsonVersion = "20160810"
quartzSchedulerVersion = "2.2.3"
springBootVersion = "1.4.2.RELEASE"
springSecurityVersion = "4.0.2.RELEASE"
springVersion = "4.3.4.RELEASE"
springCloudVersion = "1.0.2.RELEASE"
stardogVersion = "4.2.3"
    stardogSpringVerison = "4.2.1"
}

dependencies {
compile "commons-io:commons-io:$commonsIoVersion"
compile "com.complexible.stardog:client-http:$stardogVersion"
compile "com.complexible.stardog:client-snarl:$stardogVersion"
compile "com.complexible.stardog:server:$stardogVersion"
compile "com.complexible.stardog:stardog-spring:$stardogSpringVersion"
compile "org.apache.commons:commons-lang3:$commonsLangVersion"
compile "org.apache.httpcomponents:httpcore:$httpCoreVersion"
compile "org.apache.httpcomponents:httpclient:$httpClientVersion"
compile "org.aspectj:aspectjweaver:$aspectjVersion"
compile "org.codehaus.groovy:groovy-all:$groovyVersion"
compile "org.json:json:$orgJsonVersion"
compile "org.projectlombok:lombok:$lombokVersion"
compile "org.quartz-scheduler:quartz:$quartzSchedulerVersion@jar"
compile "org.springframework:spring-context:$springVersion"
compile "org.springframework:spring-context-support:$springVersion"
compile "org.springframework.boot:spring-boot-starter-aop:$springBootVersion"
compile "org.springframework.boot:spring-boot-starter-web:$springBootVersion"
compile "org.springframework.cloud:spring-cloud-aws-context:${springCloudVersion}"
compile "org.apache.commons:commons-collections4:4.0"

providedRuntime "org.springframework.boot:spring-boot-starter-tomcat"
testCompile 'junit:junit:4.12'
}

task wrapper(type: Wrapper) {
    gradleVersion = '3.2.1'
}

I'm not positive but I think I know what the problem is. Try changing your dependencies to include the stardog provided poms and additionally only the dependencies you need for your application. The Stardog dependencies are described here Home | Stardog Documentation Latest

I would also pay close attention to your Spring dependencies. Sorry I don't have time to go into more detail but let me know if you're still having problems and I'll take a closer look but hopefully this gets you going.

No worries, thanks for checking out the code. I really appreciate you taking the time to help out with this. I took out everything that I didn’t need for the project and this is what I’m left with:

dependencies {
    compile "com.complexible.stardog:client-http:${stardogVersion}@pom"
    compile "com.complexible.stardog:client-snarl:${stardogVersion}@pom"
    compile "com.complexible.stardog:server:${stardogVersion}@pom"
    compile "com.complexible.stardog:stardog-spring:$stardogSpringVersion"
    compile "org.projectlombok:lombok:$lombokVersion"
    compile "org.springframework.boot:spring-boot-starter-aop:$springBootVersion"
    compile "org.springframework.boot:spring-boot-starter-web:$springBootVersion"
    
    providedRuntime "org.springframework.boot:spring-boot-starter-tomcat"
    testCompile 'junit:junit:4.12'
}

Even with this minimal build, I’m getting the error. I looked at what spring-boot was pulling in, and nothing looks like it should be causing any issues.

You might want to try looking at just the runtime dependencies

$> gradle dependencies --configuration runtime

I’m guessing that springboot is messing with HttpClient

So, interestingly, httpClient 4.5.2 is being pulled in when I checked the runtime dependencies. But it’s being brought in by com.complexible.stardog:client-http:4.2.3. See below. I omitted other dependencies for clarity, but I can post the full log as well. This seems strange to me, if it’s httpClient 4.5.2 causing the issue.

+--- com.complexible.stardog:client-http:4.2.3
|    +--- com.complexible.stardog.watchdog.http:stardog-watchdog-protocols-http-client:4.2.3
|    |    +--- com.complexible.stardog.watchdog:stardog-watchdog-api:4.2.3
|    |    |    +--- com.complexible.stardog:stardog-api:4.2.3
|    |    |    |    +--- com.complexible.stardog.protocols.spec:stardog-protocols-spec-client:4.2.3
|    |    |    |    |    +--- com.complexible.stardog.protocols.spec:stardog-protocols-spec-shared:4.2.3
|    |    |    |    |    |    +--- com.complexible.stardog.core:stardog-core-shared:4.2.3
|    |    |    |    |    |    |    +--- com.complexible.stardog.utils:stardog-utils-rdf:4.2.3
|    |    |    |    |    |    |    |    +--- org.apache.httpcomponents:httpclient-osgi:4.4
|    |    |    |    |    |    |    |    |    +--- org.apache.httpcomponents:httpclient:4.4 -> 4.5.2
|    |    |    |    |    |    |    |    |    |    +--- org.apache.httpcomponents:httpcore:4.4.4 -> 4.4.5
|    |    |    |    |    |    |    |    |    |    +--- commons-logging:commons-logging:1.2
|    |    |    |    |    |    |    |    |    |    \--- commons-codec:commons-codec:1.9 -> 1.10
|    |    |    |    |    |    |    |    |    +--- commons-codec:commons-codec:1.9 -> 1.10
|    |    |    |    |    |    |    |    |    +--- org.apache.httpcomponents:httpmime:4.4 -> 4.5.2
|    |    |    |    |    |    |    |    |    |    \--- org.apache.httpcomponents:httpclient:4.5.2 (*)
|    |    |    |    |    |    |    |    |    +--- org.apache.httpcomponents:httpclient-cache:4.4
|    |    |    |    |    |    |    |    |    |    +--- org.apache.httpcomponents:httpclient:4.4 -> 4.5.2 (*)
|    |    |    |    |    |    |    |    |    |    \--- commons-logging:commons-logging:1.2
|    |    |    |    |    |    |    |    |    \--- org.apache.httpcomponents:fluent-hc:4.4
|    |    |    |    |    |    |    |    |         +--- org.apache.httpcomponents:httpclient:4.4 -> 4.5.2 (*)
|    |    |    |    |    |    |    |    |         \--- commons-logging:commons-logging:1.2

Edit -
Even when I exclude module ‘httpclient’ from that and bring in 4.4.1, it still fails. There doesn’t seem to be any conflicting dependencies with springboot (see below)

+--- org.springframework.boot:spring-boot-starter-aop:1.4.2.RELEASE
|    +--- org.springframework.boot:spring-boot-starter:1.4.2.RELEASE
|    |    +--- org.springframework.boot:spring-boot:1.4.2.RELEASE
|    |    |    +--- org.springframework:spring-core:4.3.4.RELEASE (*)
|    |    |    \--- org.springframework:spring-context:4.3.4.RELEASE (*)
|    |    +--- org.springframework.boot:spring-boot-autoconfigure:1.4.2.RELEASE
|    |    |    \--- org.springframework.boot:spring-boot:1.4.2.RELEASE (*)
|    |    +--- org.springframework.boot:spring-boot-starter-logging:1.4.2.RELEASE
|    |    |    +--- ch.qos.logback:logback-classic:1.1.7
|    |    |    |    +--- ch.qos.logback:logback-core:1.1.7
|    |    |    |    \--- org.slf4j:slf4j-api:1.7.20 -> 1.7.21
|    |    |    +--- org.slf4j:jcl-over-slf4j:1.7.21
|    |    |    |    \--- org.slf4j:slf4j-api:1.7.21
|    |    |    +--- org.slf4j:jul-to-slf4j:1.7.21
|    |    |    |    \--- org.slf4j:slf4j-api:1.7.21
|    |    |    \--- org.slf4j:log4j-over-slf4j:1.7.21
|    |    |         \--- org.slf4j:slf4j-api:1.7.21
|    |    +--- org.springframework:spring-core:4.3.4.RELEASE (*)
|    |    \--- org.yaml:snakeyaml:1.17
|    +--- org.springframework:spring-aop:4.3.4.RELEASE (*)
|    \--- org.aspectj:aspectjweaver:1.8.9
+--- org.springframework.boot:spring-boot-starter-web:1.4.2.RELEASE
|    +--- org.springframework.boot:spring-boot-starter:1.4.2.RELEASE (*)
|    +--- org.springframework.boot:spring-boot-starter-tomcat:1.4.2.RELEASE
|    |    +--- org.apache.tomcat.embed:tomcat-embed-core:8.5.6
|    |    +--- org.apache.tomcat.embed:tomcat-embed-el:8.5.6
|    |    \--- org.apache.tomcat.embed:tomcat-embed-websocket:8.5.6
|    |         \--- org.apache.tomcat.embed:tomcat-embed-core:8.5.6
|    +--- org.hibernate:hibernate-validator:5.2.4.Final
|    |    +--- javax.validation:validation-api:1.1.0.Final
|    |    +--- org.jboss.logging:jboss-logging:3.2.1.Final -> 3.3.0.Final
|    |    \--- com.fasterxml:classmate:1.1.0 -> 1.3.3
|    +--- com.fasterxml.jackson.core:jackson-databind:2.8.4 (*)
|    +--- org.springframework:spring-web:4.3.4.RELEASE
|    |    +--- org.springframework:spring-aop:4.3.4.RELEASE (*)
|    |    +--- org.springframework:spring-beans:4.3.4.RELEASE (*)
|    |    +--- org.springframework:spring-context:4.3.4.RELEASE (*)
|    |    \--- org.springframework:spring-core:4.3.4.RELEASE (*)
|    \--- org.springframework:spring-webmvc:4.3.4.RELEASE
|         +--- org.springframework:spring-aop:4.3.4.RELEASE (*)
|         +--- org.springframework:spring-beans:4.3.4.RELEASE (*)
|         +--- org.springframework:spring-context:4.3.4.RELEASE (*)
|         +--- org.springframework:spring-core:4.3.4.RELEASE (*)
|         +--- org.springframework:spring-expression:4.3.4.RELEASE (*)
|         \--- org.springframework:spring-web:4.3.4.RELEASE (*)
\--- org.springframework.boot:spring-boot-starter-tomcat: -> 1.4.2.RELEASE (*)

Stardog is requesting HttpClient 4.4 but gradle is resolving it based on some other dependency to 4.5.2. the arrow (->) gives the requested artifact and the resolved artifact. “you requested x.1 but someone else needed x.2 so that’s what you’re getting. x.1 -> x.2”. There should be something else in there that’s causing that to happen.

Hi again - it seems that it was httpmime that was causing the problem. I just excluded httpmime from everything and brought in httpclient 4.4.1, and it was able to create the database.

Thanks so much for your help with this

1 Like