[wildfly-dev] SDDS (Silly Deployment Detector Subsystem)

Wed May 22 09:10:29 EDT 2013

Hi Nicklas,

I had been thinking of doing something along similar lines.

However, I was considering a CLI command related to "deploy" that is able to replicate the class loading environment for each part of a deployment (ear, ejb-jar, war, far, etc) and then check whether or not each class in the deployment is already available in the class loader, subject to the spec's API visibility rules.

That may be a bit over the top though. 

This is also a big +10 from me too, btw. We spend more time on the forums getting people to list their deployment contents when troubleshooting than anything else.

Steve C

On 22/05/2013, at 10:34 PM, Nicklas Karlsson <nickarls at gmail.com> wrote:

> An external tool is probably easiest to develop but wouldn't it be hard to know what classes are implicitly added by the deployers (e.g. JPA stuff based on persistence.xml) presence?
> For the modules, I guess one could iterate over the module roots, read in the module.xml:S, load thes module and see what's exported and build up a registry to see if there are packages provided both by the deployment and the AS.
> 
> 
> On Wed, May 22, 2013 at 3:23 PM, Scott Marlow <smarlow at redhat.com> wrote:
> On 05/22/2013 04:04 AM, Nicklas Karlsson wrote:
> That's a good example. I guess the JPA subsystem could check for
> incorrectly bundled Hibernate, JSF for incorrectly bundled impl, JAX-RS
> probably could use their own. Could they all be extracted to a common
> deployment-check-subsystem (or more precisely, should they?)
> 
> +10 for this idea.
> 
> I like both approaches.  It would be great to have a deployment *lint* detector of some form.  If it is created as a common system, it might be more difficult to reach into the various deployers to diagnose issues.
> 
> For the common approach, it could also be a standalone tool that is built up over time.  If it is standalone, a log scanner would be a nice complement so that we could easily identify common runtime problems in addition to deployment time.
> 
> 
> 
> On Wed, May 22, 2013 at 10:46 AM, Alessio Soldano <asoldano at redhat.com
> <mailto:asoldano at redhat.com>> wrote:
> 
>     Just FYI, the webservices subsystem has something related to this topic,
>     see https://issues.jboss.org/browse/WFLY-451 . Basically deployments
>     containing WS endpoints are scanned by the webservices susbsystem to
>     detect Apache CXF libraries (which should not be included in the
>     deployment, being them already available on the server). If they're
>     found, a verbose/explanatory warning is printed and the deployment
>     aborted.
>     User will either fix the deployment or disable the webservices subsystem
>     for it.
> 
>     Alessio
> 
>     On 05/22/2013 09:22 AM, Nicklas Karlsson wrote:
>      > (I know there has been some discussion on the topic (old community
>      > AS7-dev postings, IRC-chat with Tomaz Cerar etc)
>      >
>      >      Hanging around the forums, I've noticed that a frequent
>     source of
>      > hard-to-debug deployment problems and other non-linear-behavior
>     is that
>      > people often try to deploy archives with conflicting dependencies
>      > (various EE APIs/impls already on the AS, JDBC drivers, maven
>     plugins,
>      > you name it).
>      >
>      >     Would it be worthwhile to implement a deployment processor
>     (disabled
>      > by default) that would act as a helpful bouncer for the deployment
>      > archive? We could have a simple isSane(Archive) interface or
>     something
>      > and people could write their own implementations (that would be
>     picked
>      > up through the java services system or listed explicitly in some
>      > module?). Default implementation that come to mind is
>      >
>      > * Blacklisted packages (using Tattletale to warn users if they are
>      > bundling e.g. EE impls/APIs)
>      > * Version limiter (using Tattletale to warn if deployment
>     contains too
>      > old version of lib, e.g. Spring)
>      > * Unused libs (using Tattletale to warn if deployment contains
>     unused jars)
>      > * Server provided libs (using Tattletale and JBoss Modules) to show
>      > which dependencies could be handled by a server module dependency)
>      >
>      > I'm not sure JBoss Modules contains any "directory" for
>      > which-modules-provides functionality but I guess the module root
>     could
>      > be scanned and the resources indexed or something. Performance
>     would not
>      > be an issue because it's still going to be faster that a user playing
>      > around with dependencies for days.
>      >
>      > Thoughts?
>      >
>      > --
>      > Nicklas Karlsson, +358 40 5062266 <tel:%2B358%2040%205062266>
> 
>      > Vaakunatie 10 as 7, 20780 Kaarina
>      >
>      >
>      >
>      > _______________________________________________
>      > wildfly-dev mailing list
>      > wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
> 
>      > https://lists.jboss.org/mailman/listinfo/wildfly-dev
> 
> 
>     --
>     Alessio Soldano
>     Web Service Lead, JBoss
>     _______________________________________________
>     wildfly-dev mailing list
>     wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
> 
>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
> 
> 
> 
> 
> --
> Nicklas Karlsson, +358 40 5062266
> Vaakunatie 10 as 7, 20780 Kaarina
> 
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> 
> 
> 
> 
> 
> -- 
> Nicklas Karlsson, +358 40 5062266
> Vaakunatie 10 as 7, 20780 Kaarina
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20130522/ff67ffa4/attachment-0001.html 