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. 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.) < > [email protected] <javascript:>> 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 [email protected] <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/jackson-user/80a3fbd0-41aa-470d-922b-e8d019c0efff%40googlegroups.com >> >> <https://groups.google.com/d/msgid/jackson-user/80a3fbd0-41aa-470d-922b-e8d019c0efff%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jackson-user/90f98719-2e41-4efd-bdd3-ed7d727620cc%40googlegroups.com.
