<div dir="ltr">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?)</div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, May 22, 2013 at 10:46 AM, Alessio Soldano <span dir="ltr"><<a href="mailto:asoldano@redhat.com" target="_blank">asoldano@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Just FYI, the webservices subsystem has something related to this topic,<br>
see <a href="https://issues.jboss.org/browse/WFLY-451" target="_blank">https://issues.jboss.org/browse/WFLY-451</a> . Basically deployments<br>
containing WS endpoints are scanned by the webservices susbsystem to<br>
detect Apache CXF libraries (which should not be included in the<br>
deployment, being them already available on the server). If they're<br>
found, a verbose/explanatory warning is printed and the deployment aborted.<br>
User will either fix the deployment or disable the webservices subsystem<br>
for it.<br>
<br>
Alessio<br>
<div><div class="h5"><br>
On 05/22/2013 09:22 AM, Nicklas Karlsson wrote:<br>
> (I know there has been some discussion on the topic (old community<br>
> AS7-dev postings, IRC-chat with Tomaz Cerar etc)<br>
><br>
> Hanging around the forums, I've noticed that a frequent source of<br>
> hard-to-debug deployment problems and other non-linear-behavior is that<br>
> people often try to deploy archives with conflicting dependencies<br>
> (various EE APIs/impls already on the AS, JDBC drivers, maven plugins,<br>
> you name it).<br>
><br>
> Would it be worthwhile to implement a deployment processor (disabled<br>
> by default) that would act as a helpful bouncer for the deployment<br>
> archive? We could have a simple isSane(Archive) interface or something<br>
> and people could write their own implementations (that would be picked<br>
> up through the java services system or listed explicitly in some<br>
> module?). Default implementation that come to mind is<br>
><br>
> * Blacklisted packages (using Tattletale to warn users if they are<br>
> bundling e.g. EE impls/APIs)<br>
> * Version limiter (using Tattletale to warn if deployment contains too<br>
> old version of lib, e.g. Spring)<br>
> * Unused libs (using Tattletale to warn if deployment contains unused jars)<br>
> * Server provided libs (using Tattletale and JBoss Modules) to show<br>
> which dependencies could be handled by a server module dependency)<br>
><br>
> I'm not sure JBoss Modules contains any "directory" for<br>
> which-modules-provides functionality but I guess the module root could<br>
> be scanned and the resources indexed or something. Performance would not<br>
> be an issue because it's still going to be faster that a user playing<br>
> around with dependencies for days.<br>
><br>
> Thoughts?<br>
><br>
> --<br>
> Nicklas Karlsson, <a href="tel:%2B358%2040%205062266" value="+358405062266">+358 40 5062266</a><br>
> Vaakunatie 10 as 7, 20780 Kaarina<br>
><br>
><br>
><br>
</div></div>> _______________________________________________<br>
> wildfly-dev mailing list<br>
> <a href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a><br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
--<br>
Alessio Soldano<br>
Web Service Lead, JBoss<br>
_______________________________________________<br>
wildfly-dev mailing list<br>
<a href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a><br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br>Nicklas Karlsson, +358 40 5062266<div>Vaakunatie 10 as 7, 20780 Kaarina</div>
</div>