topic Re: Calling a Locator in java processor - java.lang.NoSuchFieldError: DATE_PATTERNS in ArcGIS GeoEvent Server Questions

Calling a Locator in java processor - java.lang.NoSuchFieldError: DATE_PATTERNS

RobUdink1 — Fri, 14 Feb 2014 13:25:34 GMT

Hi

I'm building a custom java processor calling a Locator service for geocoding, following the example given in
http://resources.arcgis.com/en/help/runtime-java/concepts/index.html#//01qv00000016000000

Using the following java code:
    Locator locator = new Locator(DEFUALT_LOCATOR_URL, credentials);
    LocatorFindParameters parameters = new LocatorFindParameters(ADDRESS);
    parameters.setMaxLocations(10); // number of results to return
    List<LocatorGeocodeResult> results = locator.find(parameters);

To get it compiling en running, a dependency for HTTP client needs to be added to the POM,
the one also used in the ARCGIS 10.1.1 Runtime
   <dependency>
      <groupId>org.apache.httpcomponents</groupId>
      <artifactId>httpclient</artifactId>
      <version>4.2</version>
   </dependency>

However on calling the Locator find method the following exceptions is raised:
java.lang.NoSuchFieldError: DATE_PATTERNS
at com.esri.core.internal.io.handler.e.<init>(Unknown Source)
at com.esri.core.internal.io.handler.g.newInstance(Unknown Source)
at org.apache.http.cookie.CookieSpecRegistry.getCookieSpec(CookieSpecRegistry.java:110)
....
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:1035)
at com.esri.core.internal.io.handler.l.a(Unknown Source)
at com.esri.core.internal.io.handler.l.a(Unknown Source)
at com.esri.core.internal.tasks.a.c.c.a(Unknown Source)
at com.esri.core.tasks.ags.geocode.Locator.find(Unknown Source)

Locally on my development PC, I can resolve this exception by using an older httpclient version:
   <dependency>
      <groupId>org.apache.httpcomponents</groupId>
      <artifactId>httpclient</artifactId>
      <version>4.0</version>
   </dependency>

However on the target the exception still shows up in the karaf log en the GeoEvent processor effectively stops working.

Any hint on how to get this solved, or properly call a Locator within a java processor?

Thanks
Rob Udink

Re: Calling a Locator in java processor - java.lang.NoSuchFieldError: DATE_PATTERNS

JavierDelgadillo — Tue, 18 Feb 2014 16:51:58 GMT

Rob,

GEP 10.2.1 ships with httpclient 4.2. If you need an older version, you'll need to drop it's jar files into GEP's deploy folder. This may become an iterative process as the older jar files may also require other jar files that aren't available with GEP 10.2.1--so you may have to drop its dependencies into the the deploy folder as well.

To summarize:
1) Build your processor using the 4.0 dependencies in your pom.xml file.
2) Drop your custom jar along with httpclient 4.0 (and dependencies) into GEP's deploy folder.

Hopefully this works, if it doesn't there are ways of build jar files that contain all of their dependencies you can use.

-Javier

Re: Calling a Locator in java processor - java.lang.NoSuchFieldError: DATE_PATTERNS

ChrisTallman — Wed, 12 Mar 2014 20:07:32 GMT

Rob,

Were you able to get this processor working? If so would it be something you would be willing to share?

Chris

Re: Calling a Locator in java processor - java.lang.NoSuchFieldError: DATE_PATTERNS

RobUdink1 — Thu, 20 Mar 2014 13:36:14 GMT

Hi all,

As suggested, I've tried:
> 1) Build your processor using the 4.0 dependencies in your pom.xml file.
> 2) Drop your custom jar along with httpclient 4.0 (and dependencies) into GEP's deploy folder.
however without success. I get the same error as before.
I think this comes from because my custom code calls the ARCGIS 10.1.1 Runtime provided with the GeoEvent processor and from there its own HTTP (4.2) stack is called.

The next step as I understand is to include the whole ARCGIS Runtime in a single jar of the custom component. I've not tried this (yet).

Best regards
Rob

Re: Calling a Locator in java processor - java.lang.NoSuchFieldError: DATE_PATTERNS

JavierDelgadillo — Fri, 21 Mar 2014 16:46:31 GMT

Rob, Chris:

What we've found works well in cases where merely dropping jar files in the deploy folder doesn't work is to create a jar file that bundles all of your dependencies with it. To accomplish this, you'll need to give the maven-bundle-plugin an instruction to bundle the dependencies you need into the the jar file it generates.

This is what you'll do:
Make sure your pom.xml file packaging type is set to bundle:
[INDENT]<project>
...
<packaging>bundle</packaging>
...
</project>
[/INDENT]
Add your dependencies as you normally would:
[INDENT]<dependencies>
...
<dependency>
    <groupId>org.apache.httpcomponents</groupId>
    <artifactId>httpclient</artifactId>
    <version>4.0.1</version>
</dependency>
...
</dependencies>
[/INDENT]
Now, further down in your pom.xml file, you'll have a section that calls the maven-bundle-plugin. In there, you'll need to add a line to get the dependency embedded based on the artifactId in your dependency.
[INDENT]
<build>
...
<plugins>
...
<plugin>
     <groupId>org.apache.felix</groupId>
     <artifactId>maven-bundle-plugin</artifactId>
     <extensions>true</extensions>
     <configuration>
       <instructions>
...
          <Embed-Dependency>httpclient;scope=compile|runtime;inline=true</Embed-Dependency>
...
       </instructions>
     </configuration>
</plugin>
...
</plugins>
...
</build>
[/INDENT]
The Embed-Dependency command takes a comma-separated list of dependencies keyed by artifactId's in your dependencies that you'd like to include with your jar. We've used this in other places to solve this problem of including different versions of dependencies successfully on other projects.

You can find more documentation on using the Embed-Dependency plugin here.

Hope this helps.

-Javier