[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