Petals ESB Container

This can be marked as fixed. Further changes to the system classpath can have their own issues in the future.

petals-commons (after being cleaned, now it only includes BytesSource) was added to the system classpath (see PETALSESBCONT-327).

easycommons-util and Saxon-HE were removed from the system classpath (see PETALSDISTRIB-147).

This means for example that the Transformers pool provided by easycommons-util is not available to all classloaders anymore: there will be one per component and one for the kernel (not that PetalsPayloadDumperFileHandler for the logs uses the pool of the kernel container, see PETALSDISTRIB-147 for details).

New problem: petals-log depends on too much things such as easycommons-utils which share pools of transformers for the whole VM, including components.
Even though it saves space, it's not very safe to share all of that, and it creates problem with dependencies to the XSLT transformer used: the component can't use their own transformer (such as xalan or an older version of Saxon).

We should reduce the dependencies used by petals-log as much as possible then, see PETALSDISTRIB-147.

geronimo-jta was added to the system classpath: it is needed if we want to be able to get the TransactionManager from a component that does not share its classloader with the container, see PETALSESBCONT-2 for details.

It's a stable enough API and meant to be part of Java EE so I think it's ok to have it there.

To avoid library version conflicts at component level we must have a minimum number of libraries in the system classloader. When a class was loaded by the system classloader all inherithed classloaders can't load another version of the class even if provided by the component classloader. So, if a component requires another version of slf4j-api or slf4j-jdk14, that will not work. In the past, we have already have this library version conflict problem.

The space saved is not a problem. Petals ESB does not consume a lot of memory.

In the system class loader, just put librairies required by petals bootstrap. If a container library requires another library that is not in the system classloader, put it in the container class loader, even if this library can be used by components. Same for JBI components.

Ok, actually I think it's better not to include them to limit mandatory version of dependencies.

I would like to do that for several reasons:

• first it will save space
• second it is used also by the container so, we might as well share it too
• third, it makes sense that we "select" the slf4j implementation at the last moment, i.e. in the system classloader and the jdk14 implementation depends on slf4j-api…

But we can decide to do differently, what is your opinion in the light of these reasons?

I don't understand why you must add slf4j-api and slf4j-jdk14 at system classloader level. In my mind, it is sufficient to add it in the JBI components that need them to be able to have log traces of embedded libraries

slf4j-api and slf4j-jdk14 must also be added to the system classloader, see PETALSDISTRIB-139 for details. (decision reverted, see next comments)

Apparently needed dependencies in the system classloader are:

• petals-log:
  • java commons logging insist on using the system classloader to find them… (see also PETALSDISTRIB-135)
• petals-common-log:
  • components, container and petals-log use the execution context and its static thread local
  • they also uses the LogData class (this could be taken care of because in the end it's just a map, so we could use that to replace it)
• Most easycommons lib
  • they are dependencies of the previous dependencies
• and petals-jbi obviously

The previous comment is not correct (because the container needs to share the JBI classloader with the components).

A proposed solution is as follow:

• The launcher has its classloader as before, no assumption is made on it, it would be best for it to be reduced as it will still hold some dependencies in memory that won't be reused by the container, maybe it should even not include the container dependencies since they will be loaded directly from the container's classloader.
• When it launches petals, the container sets up (as a hierarchy):
• the JBI classloader containing petals-jbi
• the platform classloader containing petals-commons-log (and/or other things??)
• its classloader
• When a component is created, its classloader is created from:
• the platform classloader if the server properties have isolated as true
• the container classloader if not (but is there any reason to do that??)

Finally, some care must be taken so that there is not security/correctness/performance leaks with statics in the JBI and platform classloader that would let components share some state/influence each other/lock each others. (I'm thinking for example of the jbi descriptor builder, but there can be other things maybe…).

It would maybe make sense, instead of tweaking the launcher classloader, to tweak the components classloader so that its parent is not the system classloader but its parent (the extension classloader, or even maybe the bootstrap classloader).

This would allow to remove complex classloader code from petals launcher and to be sure the component classloader never get unwanted dependencies.