Details
-
Type:
Task
-
Status:
Resolved
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 4.3.0
-
Fix Version/s: 5.0.0
-
Component/s: None
-
Security Level: Public
-
- Environment:
- -
Activity
| Field | Original Value | New Value |
|---|---|---|
| Status | New [ 10000 ] | Open [ 10002 ] |
| Priority | Major [ 3 ] | |
| Assignee | Christophe DENEUX [ cdeneux ] | Victor NOËL [ vnoel ] |
| Summary | Rework the mechanism to load various extensions at startup and add system extensions | Add system extensions |
| Description |
Currently, there is two types of extensions: container extensions (such as the autoloader) and mutable implementations (such as the registry implementation for the container).
We wish to introduce another type of extensions: system extensions that are loaded as part of the system classloader. This will be used for example to add extra logging handlers (that must reside in the system classpath). For this, we rework the directory hierarchy as follows: * lib: contains as before the jars needed by the launcher and the container (including petals-log). ** extensions: contains jars for the container extensions (before it was next to the lib folder and now it is inside it). ** implementations: as before, contains various directories containing various implementations used inside the container. ** system-extensions: contains extra jars that must be loaded within the system classloader. Only the lib and the extensions directories are passed to the container using system properties as they are needed to setup the container classloader. System-extensions is used in the startup script as an extra classpath element (classpath can take a directory and will look for jars inside). Implementations is used internally by the container but is not configurable. This impacts the startup scripts but shouldn't change they way they were used until now. This impacts the zip and deb a bit. |
Currently, there is two types of extensions: container extensions (such as the autoloader) and mutable implementations (such as the registry implementation for the container).
We wish to introduce another type of extensions: system extensions that are loaded as part of the system classloader. This will be used for example to add extra logging handlers (that must reside in the system classpath). For this, the directory hierarchy is as follows: * lib: contains as before the jars needed by the launcher and the container (including petals-log). ** implementations: as before, contains various directories containing various implementations used inside the container. * extensions: contains as before the jars for the container extensions * system-extensions: contains extra jars that must be loaded within the system classloader. Only the lib and the extensions directories are passed to the container using system properties as they are needed to setup the container classloader. System-extensions is used in the startup script as an extra classpath element (classpath can take a directory and will look for jars inside). Implementations is used internally by the container and is not configurable. This impacts the startup scripts but shouldn't change they way they were used until now. This impacts the zip and deb a bit. |
| Status | Open [ 10002 ] | In Progress [ 10003 ] |
| Status | In Progress [ 10003 ] | Resolved [ 10004 ] |
| Fix Version/s | 5.0.0 [ 10413 ] | |
| Resolution | Fixed [ 1 ] |