[wildfly-dev] Modular classloader to verify against duplicates and ambiguities?

[Sanne Grinovero]

Very nice!

Don't you think this should be part of WildFly, to check for sanity at
deployment time?

But it looks like you go even further than my proposal, which was to
simply have the modular classloader verify for ambiguities during
class loading. SSD seems to work on a blacklists approach; I guess
there might be some benefits on that like make sure the validation
happens upfront, while classloading is lazy?

I regularly see people in trouble with multiple Hibernate copies,
although if you disable the Hibernate module injection by configuring
Jipijapa it could be a valid choice to bring your own Hibernate
libraries; it would need to be enhanced to understand such options
based on what the container is going to inject (or not). e.g.
Hibernate should be blacklisted if it's being injected, or allowed if
it's not.

One probably needs both: the blacklist approach needs some curating of
the lists, while the classloader approach will always work as last
defence, although later in the game so it might allow an invalid
deploy.. should it still fail hard at that point, when hitting an
inconsistency at runtime but after successful deploy? Probably not,
although I wonder if that's still easily implementable: the behaviour
of the module's classloader would need to switch after deploy.

Thanks,
Sanne

On 8 December 2015 at 16:25, Tomaž Cerar <tomaz.cerar at gmail.com> wrote:
>
> On Tue, Dec 8, 2015 at 5:02 PM, Sanne Grinovero <sanne at hibernate.org> wrote:
>>
>> Personally, I would totally love such an appserver who's going to yell at
>> me:
>> "you bundled two copies of blah, I refuse to deploy that!".
>>
>> Or similarly: "you're bundling Hibernate, but we're giving it to you
>> already as we recognized a JPA app and you didn't disable the embedded
>> module!"
>>
>> "Seriously, one more copy of the JTA API ?"
>
>
>
> I've actually done some initial work on this, but never managed to get code
> to some "stable" phase
> where it could be used for some more than just demo purposes. (it was
> presented at London JBUG last year)
>
> But idea was to do just that, have configurable set of "problematic" bundled
> jars / classes
> that server would than yell at you about.
>
> hence the name silly deployment detector.
> code of it could be found https://github.com/ctomc/wildfly-sdd
>
> With some more effort it could be brought to usable tool to help with messed
> up deployments.
>
> --
> tomaz