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

[Nicklas Karlsson]

Tomaz, did you ever get around to starting on your own implementation you
once mentioned?


On Thu, May 23, 2013 at 1:27 PM, Nicklas Karlsson <nickarls at gmail.com>wrote:

> Embedded AS! ;-)
>
> But yes, that's another good sanity check. I don't know if it's been fixed
> in Weld/AS but at some point you got ambiguous resolves for CDI when you
> had beans.xml in both places in the WAR.
>
>
> On Thu, May 23, 2013 at 12:12 PM, Paul Robinson <paul.robinson at redhat.com>wrote:
>
>> Nicklas,
>>
>> Like others this is something I've wanted for some time. There was some
>> interesting discussion on the following thread. I'll copy my original
>> thoughts here. Apologies in advance to the "JEE Police", I was young and
>> naive ;-)
>>
>> "[jboss-as7-dev] Detecting deployment location errors for xml files
>> using a JEE schema".
>>
>> A common problem I see again and again is when people miss-spell the
>> filenames of XML artefacts that live in the META-INF and WEB-INF
>> directories of a JEE archive. I also see people (myself included)
>> putting these artefacts in the wrong location, For example, putting the
>> beans.xml file in the META-INF of a .war when it belongs in the WEB-INF.
>>
>>
>> Also a student, on a course I teach, tried to deploy AS7 into AS7! That
>> was fun to debug. Would you be able to spot that ;-)
>>
>> Paul.
>>
>>
>> On 22 May 2013, at 08:22, Nicklas Karlsson <nickarls at gmail.com> 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
>> Vaakunatie 10 as 7, 20780 Kaarina
>>  _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>>  --
>> Paul Robinson
>> Web Service Transactions Lead
>> paul.robinson at redhat.com
>>
>> JBoss, a Division of Red Hat
>> Registered in England and Wales under Company Registration No. 03798903
>> Directors: Michael Cunningham (USA), Brendan Lane (Ireland), Matt Parson
>> (USA), Charlie Peters (USA)
>>
>>
>
>
> --
> Nicklas Karlsson, +358 40 5062266
> Vaakunatie 10 as 7, 20780 Kaarina
>



-- 
Nicklas Karlsson, +358 40 5062266
Vaakunatie 10 as 7, 20780 Kaarina
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20130528/9c6f6d48/attachment.html