Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #31365 > unrolled thread
| Started by | John <xsli2@yahoo.com> |
|---|---|
| First post | 2015-03-25 12:27 -0700 |
| Last post | 2015-03-27 18:58 -0400 |
| Articles | 9 — 2 participants |
Back to article view | Back to comp.lang.java.programmer
using two different versions of JAR files John <xsli2@yahoo.com> - 2015-03-25 12:27 -0700
Re: using two different versions of JAR files John <xsli2@yahoo.com> - 2015-03-25 13:24 -0700
Re: using two different versions of JAR files Jeff Higgins <jeff@invalid.invalid> - 2015-03-25 19:30 -0400
Re: using two different versions of JAR files John <xsli2@yahoo.com> - 2015-03-26 06:18 -0700
Re: using two different versions of JAR files Jeff Higgins <jeff@invalid.invalid> - 2015-03-26 19:05 -0400
Re: using two different versions of JAR files Jeff Higgins <jeff@invalid.invalid> - 2015-03-26 19:53 -0400
Re: using two different versions of JAR files Jeff Higgins <jeff@invalid.invalid> - 2015-03-26 20:00 -0400
Re: using two different versions of JAR files John <xsli2@yahoo.com> - 2015-03-27 13:41 -0700
Re: using two different versions of JAR files Jeff Higgins <jeff@invalid.invalid> - 2015-03-27 18:58 -0400
| From | John <xsli2@yahoo.com> |
|---|---|
| Date | 2015-03-25 12:27 -0700 |
| Subject | using two different versions of JAR files |
| Message-ID | <06d02c2a-6d23-47a9-bcb2-7bd710c9c385@googlegroups.com> |
Hi: Our JAVA programs are running as plugins inside a framework from a company called "ABC". They use a JAR suppose called "xyz-1.0.3.jar". Our JAVA programs need to use newer version, xyz-1.0.5.jar, because we found some bug inside xyz-1.0.3.jar The company "ABC" won't upgrade their JARS. In our code, when loading com.opq.rst.Hello.class, how can we make sure it is not loaded from xyz-1.0.3.jar and it is loaded from xyz-1.0.9.jar? Thank you very much.
[toc] | [next] | [standalone]
| From | John <xsli2@yahoo.com> |
|---|---|
| Date | 2015-03-25 13:24 -0700 |
| Message-ID | <8eb033b5-47e0-424f-ac87-10abeac44fc6@googlegroups.com> |
| In reply to | #31365 |
Sorry. I did some reading and have some insights: In normal situation, parent classloader is delegated first. If not found, then the local classloader. However, in Java Severlet container, the order has been reversed. The benefit of reversing can be shown in this classical example: The new container is always shipped out with many JARs, let's say one of them is log4j JAR. The users' programs very likely also uses log4j JAR. The two JARs probably is the same version. Classloader delegates to local first so that users programs get their log4j first. So, I guess I need to ask the company "ABC" about the classloader order. I was told different application container follow different orders.
[toc] | [prev] | [next] | [standalone]
| From | Jeff Higgins <jeff@invalid.invalid> |
|---|---|
| Date | 2015-03-25 19:30 -0400 |
| Message-ID | <mevgep$ss3$1@dont-email.me> |
| In reply to | #31365 |
On 03/25/2015 03:27 PM, John wrote: > Hi: > > Our JAVA programs are running as plugins inside a framework from a company called "ABC". They use a JAR suppose called "xyz-1.0.3.jar". > > Our JAVA programs need to use newer version, xyz-1.0.5.jar, because we found some bug inside xyz-1.0.3.jar > > The company "ABC" won't upgrade their JARS. > > In our code, when loading com.opq.rst.Hello.class, how can we make sure it is not loaded from xyz-1.0.3.jar and it is loaded from xyz-1.0.9.jar? > > Thank you very much. > <https://docs.oracle.com/javase/8/docs/technotes/guides/versioning/spec/versioning2.html>
[toc] | [prev] | [next] | [standalone]
| From | John <xsli2@yahoo.com> |
|---|---|
| Date | 2015-03-26 06:18 -0700 |
| Message-ID | <1ca55065-50ad-41c9-ad2b-435f6ae491df@googlegroups.com> |
| In reply to | #31368 |
On Wednesday, March 25, 2015 at 7:31:33 PM UTC-4, Jeff Higgins wrote: > On 03/25/2015 03:27 PM, John wrote: > > Hi: > > > > Our JAVA programs are running as plugins inside a framework from a company called "ABC". They use a JAR suppose called "xyz-1.0.3.jar". > > > > Our JAVA programs need to use newer version, xyz-1.0.5.jar, because we found some bug inside xyz-1.0.3.jar > > > > The company "ABC" won't upgrade their JARS. > > > > In our code, when loading com.opq.rst.Hello.class, how can we make sure it is not loaded from xyz-1.0.3.jar and it is loaded from xyz-1.0.9.jar? > > > > Thank you very much. > > > <https://docs.oracle.com/javase/8/docs/technotes/guides/versioning/spec/versioning2.html> I have scanned through the document. I don't get any hints.
[toc] | [prev] | [next] | [standalone]
| From | Jeff Higgins <jeff@invalid.invalid> |
|---|---|
| Date | 2015-03-26 19:05 -0400 |
| Message-ID | <mf23di$l3e$1@dont-email.me> |
| In reply to | #31373 |
On 03/26/2015 09:18 AM, John wrote: > On Wednesday, March 25, 2015 at 7:31:33 PM UTC-4, Jeff Higgins wrote: >> On 03/25/2015 03:27 PM, John wrote: >>> Hi: >>> >>> Our JAVA programs are running as plugins inside a framework from a company called "ABC". They use a JAR suppose called "xyz-1.0.3.jar". >>> >>> Our JAVA programs need to use newer version, xyz-1.0.5.jar, because we found some bug inside xyz-1.0.3.jar >>> >>> The company "ABC" won't upgrade their JARS. >>> >>> In our code, when loading com.opq.rst.Hello.class, how can we make sure it is not loaded from xyz-1.0.3.jar and it is loaded from xyz-1.0.9.jar? >>> >>> Thank you very much. >>> >> <https://docs.oracle.com/javase/8/docs/technotes/guides/versioning/spec/versioning2.html> > > I have scanned through the document. I don't get any hints. > Huh. Did you get as far as: <https://docs.oracle.com/javase/8/docs/technotes/guides/versioning/spec/versioning2.html#wp90779> The crux of your problem seems to be your assertion: "The company "ABC" won't upgrade their JARS." Too bad.
[toc] | [prev] | [next] | [standalone]
| From | Jeff Higgins <jeff@invalid.invalid> |
|---|---|
| Date | 2015-03-26 19:53 -0400 |
| Message-ID | <mf2674$uov$1@dont-email.me> |
| In reply to | #31385 |
On 03/26/2015 07:05 PM, Jeff Higgins wrote: > On 03/26/2015 09:18 AM, John wrote: >> On Wednesday, March 25, 2015 at 7:31:33 PM UTC-4, Jeff Higgins wrote: >>> On 03/25/2015 03:27 PM, John wrote: >>>> Hi: >>>> >>>> Our JAVA programs are running as plugins inside a framework from a >>>> company called "ABC". They use a JAR suppose called "xyz-1.0.3.jar". >>>> >>>> Our JAVA programs need to use newer version, xyz-1.0.5.jar, because >>>> we found some bug inside xyz-1.0.3.jar >>>> >>>> The company "ABC" won't upgrade their JARS. >>>> >>>> In our code, when loading com.opq.rst.Hello.class, how can we make >>>> sure it is not loaded from xyz-1.0.3.jar and it is loaded from >>>> xyz-1.0.9.jar? In your code test for the presence of the bug. If found you are using the buggy jar. >>>> >>>> Thank you very much. >>>> >>> <https://docs.oracle.com/javase/8/docs/technotes/guides/versioning/spec/versioning2.html> >>> >> >> I have scanned through the document. I don't get any hints. >> > Huh. Did you get as far as: > <https://docs.oracle.com/javase/8/docs/technotes/guides/versioning/spec/versioning2.html#wp90779> > > The crux of your problem seems to be your assertion: > "The company "ABC" won't upgrade their JARS." > Too bad. >
[toc] | [prev] | [next] | [standalone]
| From | Jeff Higgins <jeff@invalid.invalid> |
|---|---|
| Date | 2015-03-26 20:00 -0400 |
| Message-ID | <mf26kk$hh$1@dont-email.me> |
| In reply to | #31386 |
On 03/26/2015 07:53 PM, Jeff Higgins wrote: > On 03/26/2015 07:05 PM, Jeff Higgins wrote: >> On 03/26/2015 09:18 AM, John wrote: >>> On Wednesday, March 25, 2015 at 7:31:33 PM UTC-4, Jeff Higgins wrote: >>>> On 03/25/2015 03:27 PM, John wrote: >>>>> Hi: >>>>> >>>>> Our JAVA programs are running as plugins inside a framework from a >>>>> company called "ABC". They use a JAR suppose called "xyz-1.0.3.jar". >>>>> >>>>> Our JAVA programs need to use newer version, xyz-1.0.5.jar, because >>>>> we found some bug inside xyz-1.0.3.jar >>>>> >>>>> The company "ABC" won't upgrade their JARS. >>>>> >>>>> In our code, when loading com.opq.rst.Hello.class, how can we make >>>>> sure it is not loaded from xyz-1.0.3.jar and it is loaded from >>>>> xyz-1.0.9.jar? > > In your code test for the presence of the bug. > If found you are using the buggy jar. > >>>>> >>>>> Thank you very much. >>>>> >>>> <https://docs.oracle.com/javase/8/docs/technotes/guides/versioning/spec/versioning2.html> >>>> >>>> >>> >>> I have scanned through the document. I don't get any hints. >>> >> Huh. Did you get as far as: >> <https://docs.oracle.com/javase/8/docs/technotes/guides/versioning/spec/versioning2.html#wp90779> >> >> >> The crux of your problem seems to be your assertion: >> "The company "ABC" won't upgrade their JARS." >> Too bad. >> > Well, it seems your entire upstream needs to get busy in support of their downstream customers (you).
[toc] | [prev] | [next] | [standalone]
| From | John <xsli2@yahoo.com> |
|---|---|
| Date | 2015-03-27 13:41 -0700 |
| Message-ID | <2b132a2c-1421-41b6-b95b-02697b69dcf6@googlegroups.com> |
| In reply to | #31387 |
On Thursday, March 26, 2015 at 8:02:29 PM UTC-4, Jeff Higgins wrote: > On 03/26/2015 07:53 PM, Jeff Higgins wrote: > > On 03/26/2015 07:05 PM, Jeff Higgins wrote: > >> On 03/26/2015 09:18 AM, John wrote: > >>> On Wednesday, March 25, 2015 at 7:31:33 PM UTC-4, Jeff Higgins wrote: > >>>> On 03/25/2015 03:27 PM, John wrote: > >>>>> Hi: > >>>>> > >>>>> Our JAVA programs are running as plugins inside a framework from a > >>>>> company called "ABC". They use a JAR suppose called "xyz-1.0.3.jar". > >>>>> > >>>>> Our JAVA programs need to use newer version, xyz-1.0.5.jar, because > >>>>> we found some bug inside xyz-1.0.3.jar > >>>>> > >>>>> The company "ABC" won't upgrade their JARS. > >>>>> > >>>>> In our code, when loading com.opq.rst.Hello.class, how can we make > >>>>> sure it is not loaded from xyz-1.0.3.jar and it is loaded from > >>>>> xyz-1.0.9.jar? > > > > In your code test for the presence of the bug. > > If found you are using the buggy jar. > > > >>>>> > >>>>> Thank you very much. > >>>>> > >>>> <https://docs.oracle.com/javase/8/docs/technotes/guides/versioning/spec/versioning2.html> > >>>> > >>>> > >>> > >>> I have scanned through the document. I don't get any hints. > >>> > >> Huh. Did you get as far as: > >> <https://docs.oracle.com/javase/8/docs/technotes/guides/versioning/spec/versioning2.html#wp90779> > >> > >> > >> The crux of your problem seems to be your assertion: > >> "The company "ABC" won't upgrade their JARS." > >> Too bad. > >> > > > Well, it seems your entire upstream needs to get busy > in support of their downstream customers (you). I think my scenario is not rare. The company ships out their framework with certain version of 3rh party library files(JARS). Regardless they are buggy or not, the users of the framework should not be tied to use the same version of the library if the same library is needed by the users, correct? My original question is that I want to user NEWER version of JAR. Can I? I think this is classloader question. TomCat comes with certain version log4j.jar. The user's program also uses log4j.jar, suppose. The user should not need to care which version this TomCat release is using, because the classloader order in TomCat has been reversed: classloader searches locally first for the specific class, if not found, then delegates to the parent. In contrast, in normal situation, it is delegated to the parent first, if not found, search locally.
[toc] | [prev] | [next] | [standalone]
| From | Jeff Higgins <jeff@invalid.invalid> |
|---|---|
| Date | 2015-03-27 18:58 -0400 |
| Message-ID | <mf4nc0$pv8$1@dont-email.me> |
| In reply to | #31390 |
On 03/27/2015 04:41 PM, John wrote: > On Thursday, March 26, 2015 at 8:02:29 PM UTC-4, Jeff Higgins wrote: >> On 03/26/2015 07:53 PM, Jeff Higgins wrote: >>> On 03/26/2015 07:05 PM, Jeff Higgins wrote: >>>> On 03/26/2015 09:18 AM, John wrote: >>>>> On Wednesday, March 25, 2015 at 7:31:33 PM UTC-4, Jeff Higgins wrote: >>>>>> On 03/25/2015 03:27 PM, John wrote: >>>>>>> Hi: >>>>>>> >>>>>>> Our JAVA programs are running as plugins inside a framework from a >>>>>>> company called "ABC". They use a JAR suppose called "xyz-1.0.3.jar". >>>>>>> >>>>>>> Our JAVA programs need to use newer version, xyz-1.0.5.jar, because >>>>>>> we found some bug inside xyz-1.0.3.jar >>>>>>> >>>>>>> The company "ABC" won't upgrade their JARS. >>>>>>> >>>>>>> In our code, when loading com.opq.rst.Hello.class, how can we make >>>>>>> sure it is not loaded from xyz-1.0.3.jar and it is loaded from >>>>>>> xyz-1.0.9.jar? >>> >>> In your code test for the presence of the bug. >>> If found you are using the buggy jar. >>> >>>>>>> >>>>>>> Thank you very much. >>>>>>> >>>>>> <https://docs.oracle.com/javase/8/docs/technotes/guides/versioning/spec/versioning2.html> >>>>>> >>>>>> >>>>> >>>>> I have scanned through the document. I don't get any hints. >>>>> >>>> Huh. Did you get as far as: >>>> <https://docs.oracle.com/javase/8/docs/technotes/guides/versioning/spec/versioning2.html#wp90779> >>>> >>>> >>>> The crux of your problem seems to be your assertion: >>>> "The company "ABC" won't upgrade their JARS." >>>> Too bad. >>>> >>> >> Well, it seems your entire upstream needs to get busy >> in support of their downstream customers (you). > > I think my scenario is not rare. The company ships out their framework with certain version of 3rh party library files(JARS). Regardless they are buggy or not, the users of the framework should not be tied to use the same version of the library if the same library is needed by the users, correct? > My original question is that I want to user NEWER version of JAR. Can I? I think this is classloader question. > TomCat comes with certain version log4j.jar. The user's program also uses log4j.jar, suppose. The user should not need to care which version this TomCat release is using, because the classloader order in TomCat has been reversed: classloader searches locally first for the specific class, if not found, then delegates to the parent. > > In contrast, in normal situation, it is delegated to the parent first, if not found, search locally. > I will still say that attempting to get your framework vendor to upgrade to a newer library version will be your best bet. Classloader solutions will be tricky at best, then fragile, to broken.
[toc] | [prev] | [standalone]
Back to top | Article view | comp.lang.java.programmer
csiph-web