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

[David M. Lloyd]

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...

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

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