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

[Sanne Grinovero]

On 8 December 2015 at 16:11, David M. Lloyd <david.lloyd at redhat.com> wrote:
> Right now we have a policy where deployment classes are searched first
> unless the container also provides that package, in which case the
> deployment package is silently dropped.  We could enhance that to
> outright reject, however that won't catch cases where we have an API
> available that does something but it is not added to the deployment for
> whatever reason (missing descriptor, subsystem not configured, etc.).
> But it might do for part of the problem anyways...

Right, I would love that. The main thing really is to prevent
duplicates and ambiguities, and prevent most cases which bring to
complex issues like "LinkageError" exceptions. So the case in which a
class is resolvable from 2+ places, or cases in which one things a
specific library version is being used but actually another is being
loaded.. those errors are subtle as they might go unnoticed.

As you say we can't do much about people who simply forget a needed
dependency or misconfiguration causing a "0 resolvable places"
situation, but also that's much simpler for people to figure out as
you'll get a familiar ClassNotFound exception or something around
those lines.

>
> The other part (logging what dependencies were added) I think would also
> be a worthy (but separate) enhancement.

+1

>
> On 12/08/2015 10:02 AM, Sanne Grinovero wrote:
>> As an app developer I remember that some years ago I fell in love with
>> JBoss Tattletale [1], as I would use it on my projects regularly to
>> verify that I wasn't screwing up my deployed dependencies.. something
>> which was quite common as a naive developer using Maven..
>>
>> Nowadays I'm loving WildFly's modules system as it would allow me to
>> break down complex applications further (if I still were to develop
>> apps on it), or as a Hibernate / Search / Infinispan developer allows
>> us to package things in a much nicer way, exposing a minimal API
>> surface to end users.
>>
>> Then we have deployers such as the JPA subsystem which "automagically"
>> add dependencies to apps at runtime, and while I like the fact that I
>> don't have to add specific module-related descriptor files to my app
>> and trust that the app server *might* do the right thing in most
>> cases, I'm actually not very happy with the transparency of this
>> system as I believe most application developers would need an
>> exhaustive list of what's being added - and such details are all too
>> fleeting in our different versions.
>>
>> I think it would be a great feature if the modular classloader
>> wouldn't just have a well-defined order to find class definitions, but
>> could go beyond that by actually verify that for a given class name
>> there are no ambiguous resolutions, within each module (and each
>> application).
>>
>> 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 ?"
>>
>> Please?
>>
>> Thanks,
>> Sanne
>>
>> 1 - http://tattletale.jboss.org/
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
> --
> - DML
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev