[wildfly-dev] SDDS (Silly Deployment Detector Subsystem)
Brian Stansberry
brian.stansberry at redhat.com
Wed May 29 10:22:08 EDT 2013
I don't see it in his repo.
On 5/29/13 3:24 AM, Nicklas Karlsson 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
> <mailto: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 <mailto: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 <mailto: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 <mailto: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
>>> <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
>>
>> --
>> Paul Robinson
>> Web Service Transactions Lead
>> paul.robinson at redhat.com <mailto: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 <tel:%2B358%2040%205062266>
>> Vaakunatie 10 as 7, 20780 Kaarina
>>
>>
>>
>>
>> --
>> 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
>
>
>
>
> --
> 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
>
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
More information about the wildfly-dev
mailing list