Costin Manolache wrote:
- the specification still recommends hiding the implementation classes
(hence the hierarchy - is that the one proven to not matter ?)
Not matter + alternative implementations.
Hiding the implementation could be done at classloader / config level if
really needed.
Possibly.
- the "classes" folders allow patching (which of course may not be that
useful)
Did we ever did such a patch in the last 5 years ? How would it interact
with
package sealing ? etc.
Yes, quite a few such patches were released. It is also useful to
provide a user with a quick fix.
- I have no justification for the "shared" folder, except being able to
share a JAR (aka, save memory and create leaking potential) without
having it be exposed to the container implementation
If those justifications are good enough, then the "common" and "server"
folders should remain.
I think the main 'justification' for the current structure was hiding the
jaxp
parser that the server used ( old crimson, different versions of xerces, etc
).
No, I remember it was really for hiding container classes.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
