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

ssilvert at redhat.com ssilvert at redhat.com
Wed May 22 10:20:18 EDT 2013


+11

I like this idea a lot, and especially like the name!


On 5/22/2013 8:54 AM, Scott Marlow wrote:
> 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
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev



More information about the wildfly-dev mailing list