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

Mon Jun 10 09:35:10 EDT 2013

Hi,

inital code is avalible at github https://github.com/ctomc/wildfly-sdd
for now it only "features" blacklist jar warnings.

I will be talking a bit about this today at JUDCon so if you are here feel
free to ask me anything about it.

--
tomaz

On Wed, May 29, 2013 at 4:24 AM, Nicklas Karlsson <nickarls at gmail.com>wrote:

> Does anyone know if the code is available somewhere on github? No, Tomaz,
> don't you reply - you should be on the beach ;-)
>
>
> On Wed, May 29, 2013 at 10:49 AM, Jaikiran Pai <jpai at redhat.com> wrote:
>
>>  Tomaz is on vacation. He will be at JUDCon in Boston in June and as far
>> as I know this is exactly the topic that he will be talking/demonstrating
>> with a custom subsystem implementation. It's scheduled for June 10th
>> "WildFly extenstions in action"
>> http://www.jboss.org/events/JUDCon/2013/unitedstates/agenda/day2track1.html
>>
>> -Jaikiran
>>
>> On Tuesday 28 May 2013 12:10 PM, Nicklas Karlsson wrote:
>>
>> 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 <%2B358%2040%205062266>
>>>> 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 <%2B358%2040%205062266>
>>> Vaakunatie 10 as 7, 20780 Kaarina
>>>
>>
>>
>>
>>  --
>> Nicklas Karlsson, +358 40 5062266
>> Vaakunatie 10 as 7, 20780 Kaarina
>>
>>
>>  _______________________________________________
>> wildfly-dev mailing listwildfly-dev at lists.jboss.orghttps://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/20130610/8f145f34/attachment-0001.html 