Petals Distribution

Move from Java 6 to Java 7

Details

  • Type: Task Task
  • Status: Resolved Resolved
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 4.2.3
  • Fix Version/s: 5.0.0-M1
  • Component/s: None
  • Security Level: Public
  • Environment:
    -

Issue Links

Depends

Activity

Ascending order - Click to sort in descending order
Victor NOËL made changes - Mon, 9 Feb 2015 - 15:25:25 +0100
Field Original Value New Value
Assignee Christophe DENEUX [ cdeneux ] Victor NOËL [ vnoel ]
Hide
Permalink
Vincent Zurczak added a comment - Mon, 9 Feb 2015 - 15:40:49 +0100

From an (almost) external point of view, this looks like a good step ahead.
Welcome in the present.

Tests should also be run against OpenJDK 7.

Show
Vincent Zurczak added a comment - Mon, 9 Feb 2015 - 15:40:49 +0100 From an (almost) external point of view, this looks like a good step ahead. Welcome in the present. Tests should also be run against OpenJDK 7.
Hide
Permalink
Christophe DENEUX added a comment - Mon, 9 Feb 2015 - 15:48:03 +0100

What do you want to say with "remove PetalsClassloader needed to load jaxb lib first..." ?

Show
Christophe DENEUX added a comment - Mon, 9 Feb 2015 - 15:48:03 +0100 What do you want to say with "remove PetalsClassloader needed to load jaxb lib first..." ?
Hide
Permalink
Victor NOËL added a comment - Mon, 9 Feb 2015 - 17:01:15 +0100

There is a class org.ow2.petals.launcher.PetalsClassLoader that seems to do things that are not needed anymore such as using a specific classloader to load classes from the microkernel first, than from the jar from the lib and extensions directory.

I'm not sure yet what should remain there or what could simply be part of the normal Java classpath (the one declared on the command-line).
For example I suspect that jars in the lib directory don't need to be loaded in such a special way.
But I also suspect that the way the extensions dependencies are loaded is not very satisfactory: at best it would be better to have one directory per extension and that each extension has its own classloader so that there is no conflict between them.
But all of that are just ideas for now, this should be discussed.

Show
Victor NOËL added a comment - Mon, 9 Feb 2015 - 17:01:15 +0100 There is a class org.ow2.petals.launcher.PetalsClassLoader that seems to do things that are not needed anymore such as using a specific classloader to load classes from the microkernel first, than from the jar from the lib and extensions directory. I'm not sure yet what should remain there or what could simply be part of the normal Java classpath (the one declared on the command-line). For example I suspect that jars in the lib directory don't need to be loaded in such a special way. But I also suspect that the way the extensions dependencies are loaded is not very satisfactory: at best it would be better to have one directory per extension and that each extension has its own classloader so that there is no conflict between them. But all of that are just ideas for now, this should be discussed.
Hide
Permalink
Christophe DENEUX added a comment - Mon, 9 Feb 2015 - 17:10:45 +0100

PetalsClassLoader has been introduced to have the classloaders of JBI components inherited from the system classloader. A JBI component classloader has no dependency on Petals containers library except the JBI API.

Show
Christophe DENEUX added a comment - Mon, 9 Feb 2015 - 17:10:45 +0100 PetalsClassLoader has been introduced to have the classloaders of JBI components inherited from the system classloader. A JBI component classloader has no dependency on Petals containers library except the JBI API.
Hide
Permalink
Victor NOËL added a comment - Mon, 9 Feb 2015 - 17:43:02 +0100 - edited

I'm not talking about org.ow2.petals.microkernel.system.classloader.PetalsClassLoader but about org.ow2.petals.launcher.PetalsClassLoader

Show
Victor NOËL added a comment - Mon, 9 Feb 2015 - 17:43:02 +0100 - edited I'm not talking about org.ow2.petals.microkernel.system.classloader.PetalsClassLoader but about org.ow2.petals.launcher.PetalsClassLoader
Hide
Permalink
Victor NOËL added a comment - Wed, 11 Feb 2015 - 14:45:48 +0100

So in the end, I kept the dependencies to xerces and xalan as we are not sure if they are used as in Java 7 (through the automatic factories) or if their classes are directly referred to.
Since these dependencies does not conflict in term of classpath with Java 7, it should be ok.

We also put back the activation dependency because Java 7 is missing some mimetypes file in its distribution (see: https://bugs.openjdk.java.net/browse/JDK-7096063) and this jar includes them.
An alternative would have been to ship these files directly, but for clarity of the change, we preferred to bring the whole dependency.

The PetalsLauncherClassLoader (previously PetalsClassLoader) was cleaned, and documented to clarify its usefulness.

Show
Victor NOËL added a comment - Wed, 11 Feb 2015 - 14:45:48 +0100 So in the end, I kept the dependencies to xerces and xalan as we are not sure if they are used as in Java 7 (through the automatic factories) or if their classes are directly referred to. Since these dependencies does not conflict in term of classpath with Java 7, it should be ok. We also put back the activation dependency because Java 7 is missing some mimetypes file in its distribution (see: https://bugs.openjdk.java.net/browse/JDK-7096063) and this jar includes them. An alternative would have been to ship these files directly, but for clarity of the change, we preferred to bring the whole dependency. The PetalsLauncherClassLoader (previously PetalsClassLoader) was cleaned, and documented to clarify its usefulness.
Victor NOËL made changes - Tue, 3 Mar 2015 - 10:06:03 +0100
Status New [ 10000 ] Open [ 10002 ]
Priority Blocker [ 1 ]
Victor NOËL made changes - Tue, 3 Mar 2015 - 10:06:06 +0100
Status Open [ 10002 ] In Progress [ 10003 ]
Hide
Permalink
Victor NOËL added a comment - Tue, 3 Mar 2015 - 10:06:34 +0100

Everything should be ok now.

Show
Victor NOËL added a comment - Tue, 3 Mar 2015 - 10:06:34 +0100 Everything should be ok now.
Victor NOËL made changes - Tue, 3 Mar 2015 - 10:06:34 +0100
Status In Progress [ 10003 ] Resolved [ 10004 ]
Fix Version/s VNext [ 10455 ]
Resolution Fixed [ 1 ]
Christophe DENEUX made changes - Tue, 3 Mar 2015 - 10:20:48 +0100
Fix Version/s 4.3.0 [ 10412 ]
Fix Version/s VNext [ 10455 ]
Priority Blocker [ 1 ] Major [ 3 ]
Christophe DENEUX made changes - Wed, 27 May 2015 - 07:55:51 +0200
Link This issue depends on PETALSESBCONT-189 [ PETALSESBCONT-189 ]
Christophe DENEUX made changes - Wed, 27 May 2015 - 07:58:36 +0200
Link This issue blocks PETALSESBCONT-17 [ PETALSESBCONT-17 ]
Christophe DENEUX made changes - Wed, 27 May 2015 - 08:00:53 +0200
Link This issue blocks PETALSBCSOAP-4 [ PETALSBCSOAP-4 ]
Christophe DENEUX made changes - Wed, 27 May 2015 - 15:02:03 +0200
Link This issue depends on PETALSESBCONT-337 [ PETALSESBCONT-337 ]
Christophe DENEUX made changes - Wed, 27 May 2015 - 15:02:04 +0200
Link This issue depends on PETALSESBCLI-119 [ PETALSESBCLI-119 ]
Christophe DENEUX made changes - Fri, 17 Jul 2015 - 16:20:02 +0200
Link This issue blocks PETALSBCSOAP-148 [ PETALSBCSOAP-148 ]
Christophe DENEUX made changes - Tue, 6 Oct 2015 - 11:14:18 +0200
Link This issue blocks PETALSSEJSR-8 [ PETALSSEJSR-8 ]
Christophe DENEUX made changes - Tue, 1 Dec 2015 - 09:35:48 +0100
Link This issue depends on PETALSESBCONT-369 [ PETALSESBCONT-369 ]
Transition Status Change Time Execution Times Last Executer Last Execution Date
New New Open Open
21d 18h 40m
1
Victor NOËL
Tue, 3 Mar 2015 - 10:06:03 +0100
Open Open In Progress In Progress
3s
1
Victor NOËL
Tue, 3 Mar 2015 - 10:06:06 +0100
In Progress In Progress Resolved Resolved
28s
1
Victor NOËL
Tue, 3 Mar 2015 - 10:06:34 +0100



People

Dates

  • Created:
    Mon, 9 Feb 2015 - 15:25:19 +0100
    Updated:
    Tue, 1 Dec 2015 - 09:35:48 +0100
    Resolved:
    Tue, 3 Mar 2015 - 10:06:34 +0100
Atlassian JIRA (v4.1.2#531) | Report a problem | Request a feature | Contact administrators
Powered by a free Atlassian JIRA open source license for Petals ESB. Try JIRA - bug tracking software for your team.