[#PETALSDISTRIB-109] Move from Java 6 to Java 7 - Petals Link JIRA

Details

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

Description:
Hide
Compile with JDK (Oracle) 7
Run tests and integration tests with Java 7 (oracle and openjdk maybe?), and with java 8 also if possible

Remove all dependencies to libraries already included in Java 7 (u76 for now):

jaxp 1.5

stax 1.2

jaxb 2.2.4

jax-ws 2.2.4

xerces 2.7.1

xalan 2.7.1

Clean old code to handle bugs fixed in Java 7:

close is now available on URLClassLoader: http://bugs.java.com/bugdatabase/view_bug.do?bug_id=5041014

remove PetalsClassloader needed to load jaxb lib first...

use try-with-resources statement instead of ugly and bad closing: http://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.html

...
Show
Compile with JDK (Oracle) 7 Run tests and integration tests with Java 7 (oracle and openjdk maybe?), and with java 8 also if possible Remove all dependencies to libraries already included in Java 7 (u76 for now):

jaxp 1.5

stax 1.2

jaxb 2.2.4

jax-ws 2.2.4

xerces 2.7.1

xalan 2.7.1

Clean old code to handle bugs fixed in Java 7:

close is now available on URLClassLoader: http://bugs.java.com/bugdatabase/view_bug.do?bug_id=5041014

remove PetalsClassloader needed to load jaxb lib first...

use try-with-resources statement instead of ugly and bad closing: http://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.html

...

Environment:

-

Issue Links

Depends

This issue depends on:
~~PETALSESBCONT-189~~ PetalsClassLoader includes a tricky method to unlock JAR file of classloader
~~PETALSESBCONT-337~~ Petals ESB container requires a Java Runtime Environment head less
~~PETALSESBCLI-119~~ Petals ESB CLI requires a Java Runtime Environment head less
~~PETALSESBCONT-369~~ Reduce the acceptor core size of NIO transporter when no request incomes

This issue blocks:
~~PETALSESBCONT-17~~ "Too many open files" after several component or SA installations/uninstallations
~~PETALSSEJSR-8~~ All the resources are not properly released
~~PETALSBCSOAP-4~~ All resource are not properly closed
~~PETALSBCSOAP-148~~ Upgrade Jetty to the version 9.2.x

Activity

Descending order - Click to sort in ascending order

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.

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.

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

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: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 - 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

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.

People

Assignee:

Victor NOËL

Reporter:

Victor NOËL
Watchers:

0

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

Petals Distribution

Move from Java 6 to Java 7

Details

Issue Links

Activity

People

Dates