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

Paul Robinson paul.robinson at redhat.com
Thu May 23 05:58:41 EDT 2013


I'm guessing something convoluted, that boiled down to:

cp -r jboss-as-7.1.3 ./jboss-as-7.1.3/standalone/deployments

It produced a large log file ;-)

On 23 May 2013, at 10:55, Jaikiran Pai <jpai at redhat.com> wrote:

> On Thursday 23 May 2013 02:42 PM, Paul Robinson wrote:
>> ...
>> 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.
> 
> How did he try doing that?
> 
> -Jaikiran
>> 
>> 
>> 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)
>> 
>> 
>>  
>>  _______________________________________________
>> 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)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20130523/39861fdd/attachment.html 


More information about the wildfly-dev mailing list