[wildfly-dev] SDDS (Silly Deployment Detector Subsystem)
Scott Marlow
smarlow at redhat.com
Wed May 22 08:54:27 EDT 2013
I think that you have an *itch* in mind and should give it a go either
way. If you start it as an internal tool, it could be switched to
external later if that makes sense.
The important thing is to start building this tool up on github, so that
others can use it and contribute to it also!
On 05/22/2013 08:34 AM, Nicklas Karlsson 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.
Really depends on how you want to determine the dependencies (based on
what the deployers actually do versus *dependency rules* described in a
file/code).
>
>
> On Wed, May 22, 2013 at 3:23 PM, Scott Marlow <smarlow at redhat.com
> <mailto: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>
> <mailto: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
> <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> <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>
> <mailto:wildfly-dev at lists.__jboss.org
> <mailto:wildfly-dev at lists.jboss.org>>
>
> > https://lists.jboss.org/__mailman/listinfo/wildfly-dev
> <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>
> <mailto:wildfly-dev at lists.__jboss.org
> <mailto:wildfly-dev at lists.jboss.org>>
>
> https://lists.jboss.org/__mailman/listinfo/wildfly-dev
> <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
>
>
>
>
> --
> 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
> <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
>
>
>
>
>
> --
> Nicklas Karlsson, +358 40 5062266
> Vaakunatie 10 as 7, 20780 Kaarina
More information about the wildfly-dev
mailing list