Errors when using jackson_databind, jackson_core and jackson_databind version 2.10.2 because of module_info.class

[Ron Karim (Oracle Corp.)]

As we are upgrading jackson modules to version 2.10.2, we are using jackson_core, jackson_databind and jackson_annotations (all versions 2.10.2),

Each of these jars have a module_info.class that seems to be different in each jar. Hence we cannot use these 3 jars in our systems.

Should we be using the same 2.10.2 version for jackson_core and ja kson_annotations too ? Along with the jackson_databind 2.10.2 ?

Or is there another resolution to dealiing with the module_info.class in each of these jars ?

Appreciate your help.

[Ron Karim (Oracle Corp.)]

The module_info.class is different in all three jackson jars we need to use (all version 2.10.2):

jackson_annotations.jar  - module_info.class (size:190)

jackson_core.jar              module_info.class (size:698)

jackson_databind            module_info.class (size 1496)

As all 3 jars are needed at our company in the same source repository, we are getting errors about this class with the same name but different for each of the jars.

Looking forward to a recommendation for us to upgrade to jackson_databind 2.10.2 due to security issues with our previous versinos.

Thanks,

Ron

On Tuesday, January 28, 2020 at 11:03:53 AM UTC-8, Ron Karim (Oracle Corp.) wrote:

As we are upgrading jackson modules to version 2.10.2, we are using jackson_core, jackson_databind and jackson_annotations (all versions 2.10.2),

Each of these jars have a module_info.class that seems to be different in each jar. Hence we cannot use these 3 jars in our systems.

Should we be using the same 2.10.2 version for jackson_core and jackson_annotations too ? Along with the jackson_databind 2.10.2 ?

Or is there another resolution to dealing with the module_info.class in each of these jars ?

Appreciate your help.

[Ron Karim (Oracle Corp.)]

Basically Dependencies rejected for these 3 jars with the module_info.class (as it is different in all 3 jars).

Is there a version 2.10.2  available with support for multi-release-jars ?

On Tuesday, January 28, 2020 at 11:03:53 AM UTC-8, Ron Karim (Oracle Corp.) wrote:

[Tatu Saloranta]

On Tue, Jan 28, 2020 at 11:36 AM Ron Karim (Oracle Corp.) <ron....@gmail.com> wrote:

Basically Dependencies rejected for these 3 jars with the module_info.class (as it is different in all 3 jars).

Is there a version 2.10.2  available with support for multi-release-jars ?

No. Module-info classes should only be used by JDK 9 and above; Java 8 and below should just ignore these classes.

What specifically is your issue? On which platform / tools?

-+ Tatu +-

 

On Tuesday, January 28, 2020 at 11:03:53 AM UTC-8, Ron Karim (Oracle Corp.) wrote:

As we are upgrading jackson modules to version 2.10.2, we are using jackson_core, jackson_databind and jackson_annotations (all versions 2.10.2),

Each of these jars have a module_info.class that seems to be different in each jar. Hence we cannot use these 3 jars in our systems.

Should we be using the same 2.10.2 version for jackson_core and ja kson_annotations too ? Along with the jackson_databind 2.10.2 ?

Or is there another resolution to dealiing with the module_info.class in each of these jars ?

Appreciate your help.

--
You received this message because you are subscribed to the Google Groups "jackson-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jackson-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jackson-user/c73577d8-f4e0-4983-9314-81631827eeb9%40googlegroups.com.

[Ron Karim (Oracle Corp.)]

On Tuesday, January 28, 2020 at 11:03:53 AM UTC-8, Ron Karim (Oracle Corp.) wrote:

[Ron Karim (Oracle Corp.)]

In our corporate builds in Oracle that use jackson, we need to support JDK 7 and JDK 8 as the current user-base/customers are still on JDK 7 and JDK 8 based systems.

Is there a way of ignoring the JDK 9 module_info.class from these jars ? We are not allowed to modify the jars, but the 3 jars need to be in the same repository as a single jackson patch.

On Tuesday, January 28, 2020 at 2:14:07 PM UTC-8, Tatu Saloranta wrote:

On Tue, Jan 28, 2020 at 11:36 AM Ron Karim (Oracle Corp.) <ron....@gmail.com> wrote:

Basically Dependencies rejected for these 3 jars with the module_info.class (as it is different in all 3 jars).

Is there a version 2.10.2  available with support for multi-release-jars ?

No. Module-info classes should only be used by JDK 9 and above; Java 8 and below should just ignore these classes.

What specifically is your issue? On which platform / tools?

-+ Tatu +-

 

On Tuesday, January 28, 2020 at 11:03:53 AM UTC-8, Ron Karim (Oracle Corp.) wrote:

As we are upgrading jackson modules to version 2.10.2, we are using jackson_core, jackson_databind and jackson_annotations (all versions 2.10.2),

Each of these jars have a module_info.class that seems to be different in each jar. Hence we cannot use these 3 jars in our systems.

Should we be using the same 2.10.2 version for jackson_core and ja kson_annotations too ? Along with the jackson_databind 2.10.2 ?

Or is there another resolution to dealiing with the module_info.class in each of these jars ?

Appreciate your help.

--
You received this message because you are subscribed to the Google Groups "jackson-user" group.

To unsubscribe from this group and stop receiving emails from it, send an email to jackso...@googlegroups.com.

[Tatu Saloranta]

On Tue, Jan 28, 2020 at 2:24 PM Ron Karim (Oracle Corp.) <ron....@gmail.com> wrote:

In our corporate builds in Oracle that use jackson, we need to support JDK 7 and JDK 8 as the current user-base/customers are still on JDK 7 and JDK 8 based systems.

Is there a way of ignoring the JDK 9 module_info.class from these jars ? We are not allowed to modify the jars, but the 3 jars need to be in the same repository as a single jackson patch.

I am not sure I follow: how exactly would these classes be referenced by JVM (or more likely, some tooling)? They are not referenced by any classes you load, nor automatically by JVM (as far as I know), so their existence should not matter.

I have not observed issues with JDK 8 (I develop on Java 8, all runtimes likewise). JDK 7 I don't know since I no longer have access to such JDKs.

As importantly, no one reported any problems during pre-release time for 2.10 release despite my requesting feedback... so I am literally unaware of actual concrete problems with inclusion of module-info class files.

Given all this I am not yet convinced there is an issue to solve.

But perhaps Java folks at Oracle can help you with problems you have?

-+ Tatu +-

 

On Tuesday, January 28, 2020 at 2:14:07 PM UTC-8, Tatu Saloranta wrote:

On Tue, Jan 28, 2020 at 11:36 AM Ron Karim (Oracle Corp.) <ron....@gmail.com> wrote:

Basically Dependencies rejected for these 3 jars with the module_info.class (as it is different in all 3 jars).

Is there a version 2.10.2  available with support for multi-release-jars ?

No. Module-info classes should only be used by JDK 9 and above; Java 8 and below should just ignore these classes.

What specifically is your issue? On which platform / tools?

-+ Tatu +-

 

On Tuesday, January 28, 2020 at 11:03:53 AM UTC-8, Ron Karim (Oracle Corp.) wrote:

As we are upgrading jackson modules to version 2.10.2, we are using jackson_core, jackson_databind and jackson_annotations (all versions 2.10.2),

Each of these jars have a module_info.class that seems to be different in each jar. Hence we cannot use these 3 jars in our systems.

Should we be using the same 2.10.2 version for jackson_core and ja kson_annotations too ? Along with the jackson_databind 2.10.2 ?

Or is there another resolution to dealiing with the module_info.class in each of these jars ?

Appreciate your help.

--
You received this message because you are subscribed to the Google Groups "jackson-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jackso...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jackson-user/c73577d8-f4e0-4983-9314-81631827eeb9%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "jackson-user" group.

To unsubscribe from this group and stop receiving emails from it, send an email to jackson-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jackson-user/01eacd95-7ca3-4125-8205-0f9bbe4d16e8%40googlegroups.com.

[Ron Karim (Oracle Corp.)]

As per this JDK 8 bug (unresolved), jars with the module_info.class (JDK9 ) will not build with JDK 8:

https://bugs.openjdk.java.net/browse/JDK-8206896

[Guido Medina]

If you are building some fat jar with all the jars and having an issue because "module-info.class" is on the same package for different jars and is a different class,

I would add some rule to your build tool to just ignore that class name which is well known as class name for module information, it is safe to completely ignore it for JDK 8 and below.

I don't think there is something that can be done on the Jackson side, module info is pretty standard and needed to support JDK 9+

Here is some example of the same problem and how to solve it for Maven for example: https://github.com/javaee/jaxb-v2/commit/2961be74799e0d123f198cbe29fcd0dc4e8bcf63

To unsubscribe from this group and stop receiving emails from it, send an email to jackson-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jackson-user/01eacd95-7ca3-4125-8205-0f9bbe4d16e8%40googlegroups.com.

[Ron Karim (Oracle Corp.)]

Thanks for the quick response, the module_info.class is stored in a common location when we create a patch for cutomers with all 3 jars in the same "jackson-updated-security patch", here is an example error from our system:

ERROR: Different size module-info.class duplicated in archives: fnd/java/3rdparty/stdalone/jackson_annotations.zip (120.0.12020000.7), fnd/java/3rdparty/stdalone/jackson_databind.zip (120.0.12020000.7), fnd/java/3rdparty/stdalone/jackson_core.zip (120.0.12020000.7) java/3rdparty/stdalone/jackson_core.zip

One option that we re thinking is maybe create 3 separate patches, but that will cause an error when the patches are applied in the same customer location.

On Tuesday, January 28, 2020 at 11:03:53 AM UTC-8, Ron Karim (Oracle Corp.) wrote:

[Tatu Saloranta]

On Tue, Jan 28, 2020 at 2:31 PM Ron Karim (Oracle Corp.) <ron....@gmail.com> wrote:

As per this JDK 8 bug (unresolved), jars with the module_info.class (JDK9 ) will not build with JDK 8:

https://bugs.openjdk.java.net/browse/JDK-8206896

Jackson does not compile `module-info.java` with javac, but uses Moditect plug-in for this reason (see https://github.com/moditect/moditect).

And like someone already suggested, if you are bundling Jackson jars with something else it is best to ignore module-info.class: I think a few other files often need to be dropped on Android builds.

I am interested in hearing more details about problem cases as I realize that just because I haven't yet heard of issues does not mean there are none. But I want to give some context on perceived usage, users, so that issues can be isolated and prevalence correctly estimated.

Challenge here is that there is value in providing module descriptors: and I have heard that use of multi-release jars has its own potential problems from tooling perspective.

-+ Tatu +- 

 

On Tuesday, January 28, 2020 at 2:24:17 PM UTC-8, Ron Karim (Oracle Corp.) wrote:

In our corporate builds in Oracle that use jackson, we need to support JDK 7 and JDK 8 as the current user-base/customers are still on JDK 7 and JDK 8 based systems.

Is there a way of ignoring the JDK 9 module_info.class from these jars ? We are not allowed to modify the jars, but the 3 jars need to be in the same repository as a single jackson patch.

On Tuesday, January 28, 2020 at 2:14:07 PM UTC-8, Tatu Saloranta wrote:

On Tue, Jan 28, 2020 at 11:36 AM Ron Karim (Oracle Corp.) <ron....@gmail.com> wrote:

Basically Dependencies rejected for these 3 jars with the module_info.class (as it is different in all 3 jars).

Is there a version 2.10.2  available with support for multi-release-jars ?

No. Module-info classes should only be used by JDK 9 and above; Java 8 and below should just ignore these classes.

What specifically is your issue? On which platform / tools?

-+ Tatu +-

 

On Tuesday, January 28, 2020 at 11:03:53 AM UTC-8, Ron Karim (Oracle Corp.) wrote:

As we are upgrading jackson modules to version 2.10.2, we are using jackson_core, jackson_databind and jackson_annotations (all versions 2.10.2),

Each of these jars have a module_info.class that seems to be different in each jar. Hence we cannot use these 3 jars in our systems.

Should we be using the same 2.10.2 version for jackson_core and ja kson_annotations too ? Along with the jackson_databind 2.10.2 ?

Or is there another resolution to dealiing with the module_info.class in each of these jars ?

Appreciate your help.

--
You received this message because you are subscribed to the Google Groups "jackson-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jackso...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jackson-user/c73577d8-f4e0-4983-9314-81631827eeb9%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "jackson-user" group.

To unsubscribe from this group and stop receiving emails from it, send an email to jackson-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jackson-user/9395c3da-3bd8-429c-9207-8494957ead32%40googlegroups.com.

[Tatu Saloranta]

On Tue, Jan 28, 2020 at 2:39 PM Ron Karim (Oracle Corp.) <ron....@gmail.com> wrote:

Thanks for the quick response, the module_info.class is stored in a common location when we create a patch for cutomers with all 3 jars in the same "jackson-updated-security patch", here is an example error from our system:

ERROR: Different size module-info.class duplicated in archives: fnd/java/3rdparty/stdalone/jackson_annotations.zip (120.0.12020000.7), fnd/java/3rdparty/stdalone/jackson_databind.zip (120.0.12020000.7), fnd/java/3rdparty/stdalone/jackson_core.zip (120.0.12020000.7) java/3rdparty/stdalone/jackson_core.zip

One option that we re thinking is maybe create 3 separate patches, but that will cause an error when the patches are applied in the same customer location.

That sounds like something where filtering out of these class descriptors would probably make sense. There are other artifacts that I have heard can cause issues with packaging -- META-INF/LICENSE, for example, is exists in all jars.

I am guessing that tools in question predate Java 9, but there hopefully is some setting to specify file(s) to ignore?

Otherwise, pre-processing jars to drop module-info.class would serve the same purpose.

This class obviously has no value on Java 7/8 platform.

-+ Tatu +-

 

On Tuesday, January 28, 2020 at 11:03:53 AM UTC-8, Ron Karim (Oracle Corp.) wrote:

As we are upgrading jackson modules to version 2.10.2, we are using jackson_core, jackson_databind and jackson_annotations (all versions 2.10.2),

Each of these jars have a module_info.class that seems to be different in each jar. Hence we cannot use these 3 jars in our systems.

Should we be using the same 2.10.2 version for jackson_core and ja kson_annotations too ? Along with the jackson_databind 2.10.2 ?

Or is there another resolution to dealiing with the module_info.class in each of these jars ?

Appreciate your help.

--
You received this message because you are subscribed to the Google Groups "jackson-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jackson-user...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jackson-user/80a3fbd0-41aa-470d-922b-e8d019c0efff%40googlegroups.com.

[Ron Karim (Oracle Corp.)]

Thanks for the quick response. For a large enterprise organization like ours, modifying central builds and making changes to them require all sorts of complexities, which we may have to bite the bullet and do. But the fact that we are getting security issues every few months is getting a lot of attention from our release areas as well.

Since we need this particular set of jars (jackson_databin, jackson_core, jackson_annotations) for a JDK 7 Runtime environment (all components in this massive behemoth are still using JDK 7 and will be for quite sometime), couple of questions as we prepare a case for uptake of jackson 2.10.2 :

- What version of the JDK are used to build these jars, (if a JDK 9 compiler is used, then we won't be able to use them in a JDK 7 runtime environment, correct ?)

- If these libraries were tested for a Java 7 runtime, how did you build those particular libraries that were tested for the JDK 7 runtime ?

Thanks for all the advice and guidance.

To unsubscribe from this group and stop receiving emails from it, send an email to jackso...@googlegroups.com.

[Tatu Saloranta]

On Wed, Jan 29, 2020 at 10:45 AM Ron Karim (Oracle Corp.) <ron....@gmail.com> wrote:

Thanks for the quick response. For a large enterprise organization like ours, modifying central builds and making changes to them require all sorts of complexities, which we may have to bite the bullet and do. But the fact that we are getting security issues every few months is getting a lot of attention from our release areas as well.

Since we need this particular set of jars (jackson_databin, jackson_core, jackson_annotations) for a JDK 7 Runtime environment (all components in this massive behemoth are still using JDK 7 and will be for quite sometime), couple of questions as we prepare a case for uptake of jackson 2.10.2 :

- What version of the JDK are used to build these jars, (if a JDK 9 compiler is used, then we won't be able to use them in a JDK 7 runtime environment, correct ?)

JDK 8 used, since at this point it this almost impossible to publish anything to Sonatype OSS repository with JDK 7 or earlier (I do not remember exact timeline when this changed; I used JDK 7 for releases until that point -- but I think this was in late 2018 or so).

JDK 9 or later will not be used for building Jackson 2.x.

(getting JDK 7 itself is getting challenging, and CI systems like Travis seem to have dropped supported too)

Maven builds specify Java source and target versions of 1.7 (for JDK 7), with exception of `jackson-annotations` and `jackson-core` that have target of 1.6 (for JDK 6). So resulting bytecode should still be compatible with earlier JVMs.

module-info.class is included starting with Jackson 2.10.

- If these libraries were tested for a Java 7 runtime, how did you build those particular libraries that were tested for the JDK 7 runtime ?

No full or automated testing is done on JDK 7 any more. Effort is made to avoid using any JDK classes or methods past JDK 7, but this is not very robust as JDK 8 needs to be used for build process itself.

We rely on user community to report issues with JDK 7 (or, for streaming/jackson-core, for JDK 6), not having resources to do testing with it.

 

Thanks for all the advice and guidance.

I hope this helps.

-+ Tatu +-

 

On Tuesday, January 28, 2020 at 8:18:01 PM UTC-8, Tatu Saloranta wrote:

On Tue, Jan 28, 2020 at 2:39 PM Ron Karim (Oracle Corp.) <ron....@gmail.com> wrote:

Thanks for the quick response, the module_info.class is stored in a common location when we create a patch for cutomers with all 3 jars in the same "jackson-updated-security patch", here is an example error from our system:

ERROR: Different size module-info.class duplicated in archives: fnd/java/3rdparty/stdalone/jackson_annotations.zip (120.0.12020000.7), fnd/java/3rdparty/stdalone/jackson_databind.zip (120.0.12020000.7), fnd/java/3rdparty/stdalone/jackson_core.zip (120.0.12020000.7) java/3rdparty/stdalone/jackson_core.zip

One option that we re thinking is maybe create 3 separate patches, but that will cause an error when the patches are applied in the same customer location.

That sounds like something where filtering out of these class descriptors would probably make sense. There are other artifacts that I have heard can cause issues with packaging -- META-INF/LICENSE, for example, is exists in all jars.

I am guessing that tools in question predate Java 9, but there hopefully is some setting to specify file(s) to ignore?

Otherwise, pre-processing jars to drop module-info.class would serve the same purpose.

This class obviously has no value on Java 7/8 platform.

-+ Tatu +-

 

On Tuesday, January 28, 2020 at 11:03:53 AM UTC-8, Ron Karim (Oracle Corp.) wrote:

As we are upgrading jackson modules to version 2.10.2, we are using jackson_core, jackson_databind and jackson_annotations (all versions 2.10.2),

Each of these jars have a module_info.class that seems to be different in each jar. Hence we cannot use these 3 jars in our systems.

Should we be using the same 2.10.2 version for jackson_core and ja kson_annotations too ? Along with the jackson_databind 2.10.2 ?

Or is there another resolution to dealiing with the module_info.class in each of these jars ?

Appreciate your help.

--
You received this message because you are subscribed to the Google Groups "jackson-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jackso...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jackson-user/80a3fbd0-41aa-470d-922b-e8d019c0efff%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "jackson-user" group.

To unsubscribe from this group and stop receiving emails from it, send an email to jackson-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jackson-user/90f98719-2e41-4efd-bdd3-ed7d727620cc%40googlegroups.com.

[Xeno Amess]

I don't know if I shall say this. 

but jigsaw sucks.

module sucks.

and module_info sucks.

Tatu Saloranta <tsalo...@gmail.com> 于 2020年1月30日 周四 上午6:11写道：

To view this discussion on the web visit https://groups.google.com/d/msgid/jackson-user/CAGrxA27pzuJKfJz6zvxLP3G8RyuxavkyT7h4L1YvS%2B0HHdhhKQ%40mail.gmail.com.

[Xeno Amess]

oh btw

https://github.com/JOML-CI/JOML/blob/master/pom.xml 

That author build multiple jars using different profiles in maven.

That sounds crazy but he maintains his project to work on jdk 3-12 and android, for several years.

I hope this be helpful. 

 

Xeno Amess <xeno...@gmail.com> 于2020年1月30日周四 上午6:37写道：

[Ron Karim (Oracle Corp.)]

Our organization needs to use these jars "as-is", due to legal obligations (modifying or rebuilding them at our site may extend the liability or support of these external libraries to customers, etc..among others). The overall system that deal with Java dictates that libraries use packages explicitly with no duplicate classes.

Since it never was an issue, make files and other build systems simply spit these jars out as "non-standard and inadmissible".

Even if we modify one area of the build, down the line, some other build system or a patch-application system utilizing this component will break.

Although, not every product uses it, the Build and release in this environment deals with 243 Enterprise-capacity software systems all part of a single Suite of Products (in Java).

But, that is the only option we have at this time with these Jackson Jars and have started looking into that route. That just delays our uptake of these external libraries. Appreciate all the suggestions.

To view this discussion on the web visit https://groups.google.com/d/msgid/jackson-user/90f98719-2e41-4efd-bdd3-ed7d727620cc%40googlegroups.com.

[Tatu Saloranta]

On Fri, Jan 31, 2020 at 11:36 AM Ron Karim (Oracle Corp.)
<ron....@gmail.com> wrote:
>
> Our organization needs to use these jars "as-is", due to legal obligations (modifying or rebuilding them at our site may extend the liability or support of these external libraries to customers, etc..among others). The overall system that deal with Java dictates that libraries use packages explicitly with no duplicate classes.
> Since it never was an issue, make files and other build systems simply spit these jars out as "non-standard and inadmissible".
> Even if we modify one area of the build, down the line, some other build system or a patch-application system utilizing this component will break.
> Although, not every product uses it, the Build and release in this environment deals with 243 Enterprise-capacity software systems all part of a single Suite of Products (in Java).
> But, that is the only option we have at this time with these Jackson Jars and have started looking into that route. That just delays our uptake of these external libraries. Appreciate all the suggestions.

This is a good example why it would be really good to get early
feedback on release candidate versions: changes can still be made, and
in some cases inclusion could be deferred -- although with inclusion
of module-info, only by some amount.

In this specific case, for example, if it was known there are actual
problems, I might have considered that 2.10.0 would not yet include
module-info just because the important security aspects of 2.10 are
worth getting out. And module-info could have followed in 2.11 which
is due out soon now.

But since module-info is included and probably used by many already
(for those running on JDK 11 and later it can be very useful in
trimming down full deployables), it really can not be removed from
2.10 patch versions.

The idea of using different "flavors" of Jars (with Maven...
classifier? or was it qualifier?), this is something we have
considered for certain things, but at the end of the day complexity in
build system, for users and so on really is something that does not
seem worth the hassle. Handling releases, development across 2 dozen
different projects is heavy enough burden as is.
So it is unlikely we'd go that route here or in general.
And finally, use of multi-release jars would be likely to cause as
many issues as it might solve (based on commentary I have seen),
regarding pre-java9 platforms. I am not even sure if module-info could
live under sub-directories.

If module-info is completely unacceptable, Jackson versions up to
2.9.x will not include it, so that may still be an option. Security
aspects wrt CVE notices (... but not really _security problems_
actually) can be tricky as we still need to file CVEs for all
theoretical problems.
But at the same time we will keep on releasing micro-patches
addressing those: 2.9.x branch will live as long as necessary.

I hope this further clarifies the situation,

-+ Tatu +-

> To unsubscribe from this group and stop receiving emails from it, send an email to jackson-user...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/jackson-user/094d430e-1c9f-47ed-8a18-5f3c13a31c48%40googlegroups.com.