Class loading issue across versions

Poster	Content
tab nk4um Moderator Posts: 485	<div>Yep that is a good way to go. Not only will you avoid classloader issues but you''ll also avoid permgen issues if a 3rd party library is only loaded up once and then shared by placing it in it''s own module.<br/><br/>Let me know if you want more help with this one.<br/><br/>Cheers,<br/>Tony</div> 2009-12-21T10:43:15.000ZDecember 21, 2009 10:43 Yep that is a good way to go. Not only will you avoid classloader issues but you''ll also avoid permgen issues if a 3rd party library is only loaded up once and then shared by placing it in it''s own module. Let me know if you want more help with this one. Cheers, Tony
gary.sole nk4um User Posts: 74	<div>Hi Tony,<br/><br/>Thanks for the reply. I agree that maybe our problem is that we have shared 3rd party libraries in a module we call mod-app-core. All of our modules import this base module that includes all or Transreptors and common Accessors.<br/><br/>We have found that we have to share our 3rd party libraries by importing a common module because otherwise we run out of PERM gen space.<br/><br/>We could do this though by moving the libraries to their own lib module that modules import and keep mod app core for the common features, transreptors and importing of NK libraries.<br/><br/>Gary</div> 2009-12-18T18:22:56.000ZDecember 18, 2009 18:22Class loading issue across versions Hi Tony, Thanks for the reply. I agree that maybe our problem is that we have shared 3rd party libraries in a module we call mod-app-core. All of our modules import this base module that includes all or Transreptors and common Accessors. We have found that we have to share our 3rd party libraries by importing a common module because otherwise we run out of PERM gen space. We could do this though by moving the libraries to their own lib module that modules import and keep mod app core for the common features, transreptors and importing of NK libraries. Gary
tab nk4um Moderator Posts: 485	<div>Hi Gary,<br/><br/>what you are encountering, I think, is a fundamental limit of Java classloader rather than a problem with NetKernel''s versioning. I''m not exactly sure on the exports from each of the modules you describe but it sound like you need to keep the classes more isolated. If it is possible to not expose the libraries classes outside the module that would help. Try and keep it just to representation interfaces. It might help if we can work together to create a tight example of what you are talking about and then we can work it though and get to the specifics and a good solution for you.<br/><br/>Cheers,<br/>Tony</div> 2009-12-18T17:59:08.000ZDecember 18, 2009 17:59 Hi Gary, what you are encountering, I think, is a fundamental limit of Java classloader rather than a problem with NetKernel''s versioning. I''m not exactly sure on the exports from each of the modules you describe but it sound like you need to keep the classes more isolated. If it is possible to not expose the libraries classes outside the module that would help. Try and keep it just to representation interfaces. It might help if we can work together to create a tight example of what you are talking about and then we can work it though and get to the specifics and a good solution for you. Cheers, Tony
gary.sole nk4um User Posts: 74	<div>We have run into the following problem.<br/>Module A imports Module B and Module C v1<br/>Module B also imports Module C v1<br/>The above works.<br/>However, if Module A imports Module B and Module C v2 while Module B imports Module C v1 we have a problem.<br/>Module C has a third party library that is used by Module A and B.<br/><br/>A call in Module A using the third party library from Module C is needing to use a Class that is exported by Module B. The third party library gets a ClassDefNotFoundException in the second case, but works find when Module A and B import the same version of Module C.<br/>At this point in time, we can solve the problem by not creating a v2 of Module C as the changes have been minor enough. It only breaks our versioning strategy - which is not the end of the world.<br/><br/>However, I am concerned that in the future we may have a legitimate reason to not share the same version and thus want to bring up this issue now before it bites us later.<br/><br/>Is there any solution?<br/>Does NK 4 support versioning better?<br/><br/>Gary</div> 2009-12-18T16:02:57.000ZDecember 18, 2009 16:02Class loading issue across versions We have run into the following problem. Module A imports Module B and Module C v1 Module B also imports Module C v1 The above works. However, if Module A imports Module B and Module C v2 while Module B imports Module C v1 we have a problem. Module C has a third party library that is used by Module A and B. A call in Module A using the third party library from Module C is needing to use a Class that is exported by Module B. The third party library gets a ClassDefNotFoundException in the second case, but works find when Module A and B import the same version of Module C. At this point in time, we can solve the problem by not creating a v2 of Module C as the changes have been minor enough. It only breaks our versioning strategy - which is not the end of the world. However, I am concerned that in the future we may have a legitimate reason to not share the same version and thus want to bring up this issue now before it bites us later. Is there any solution? Does NK 4 support versioning better? Gary

tab

nk4um Moderator

Posts: 485

December 21, 2009 10:43

Yep that is a good way to go. Not only will you avoid classloader issues but you''ll also avoid permgen issues if a 3rd party library is only loaded up once and then shared by placing it in it''s own module.

Let me know if you want more help with this one.

Cheers,
Tony

gary.sole

nk4um User

Posts: 74

December 18, 2009 18:22Class loading issue across versions

Hi Tony,

Thanks for the reply. I agree that maybe our problem is that we have shared 3rd party libraries in a module we call mod-app-core. All of our modules import this base module that includes all or Transreptors and common Accessors.

We have found that we have to share our 3rd party libraries by importing a common module because otherwise we run out of PERM gen space.

We could do this though by moving the libraries to their own lib module that modules import and keep mod app core for the common features, transreptors and importing of NK libraries.

Gary

tab

nk4um Moderator

Posts: 485

December 18, 2009 17:59

Hi Gary,

what you are encountering, I think, is a fundamental limit of Java classloader rather than a problem with NetKernel''s versioning. I''m not exactly sure on the exports from each of the modules you describe but it sound like you need to keep the classes more isolated. If it is possible to not expose the libraries classes outside the module that would help. Try and keep it just to representation interfaces. It might help if we can work together to create a tight example of what you are talking about and then we can work it though and get to the specifics and a good solution for you.

Cheers,
Tony

gary.sole

nk4um User

Posts: 74

<div>We have run into the following problem. Module A imports Module B and Module C v1 Module B also imports Module C v1 The above works. However, if Module A imports Module B and Module C v2 while Module B imports Module C v1 we have a problem. Module C has a third party library that is used by Module A and B. A call in Module A using the third party library from Module C is needing to use a Class that is exported by Module B.  The third party library gets a ClassDefNotFoundException in the second case, but works find when Module A and B import the same version of Module C. At this point in time, we can solve the problem by not creating a v2 of Module C as the changes have been minor enough.  It only breaks our versioning strategy - which is not the end of the world. However, I am concerned that in the future we may have a legitimate reason to not share the same version and thus want to bring up this issue now before it bites us later. Is there any solution? Does NK 4 support versioning better? Gary</div>

December 18, 2009 16:02Class loading issue across versions

We have run into the following problem.
Module A imports Module B and Module C v1
Module B also imports Module C v1
The above works.
However, if Module A imports Module B and Module C v2 while Module B imports Module C v1 we have a problem.
Module C has a third party library that is used by Module A and B.

A call in Module A using the third party library from Module C is needing to use a Class that is exported by Module B. The third party library gets a ClassDefNotFoundException in the second case, but works find when Module A and B import the same version of Module C.
At this point in time, we can solve the problem by not creating a v2 of Module C as the changes have been minor enough. It only breaks our versioning strategy - which is not the end of the world.

However, I am concerned that in the future we may have a legitimate reason to not share the same version and thus want to bring up this issue now before it bites us later.

Is there any solution?
Does NK 4 support versioning better?

Gary