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

[Nicklas Karlsson]

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?)


On Wed, May 22, 2013 at 10:46 AM, Alessio Soldano <asoldano at redhat.com>wrote:

> Just FYI, the webservices subsystem has something related to this topic,
> see 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
> > Vaakunatie 10 as 7, 20780 Kaarina
> >
> >
> >
> > _______________________________________________
> > wildfly-dev mailing list
> > wildfly-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
> --
> Alessio Soldano
> Web Service Lead, JBoss
> _______________________________________________
> wildfly-dev mailing list
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20130522/1411448f/attachment.html