<div dir="ltr">Well, the only "truly correct" way is, like you said, to look at the classloading rules like the AS would see them from the POV of the deployment (including all transitive module dependecies, implicit module additions, spec rules, jboss-deployment-structure overrides etc. <div>
<br></div><div>A quick and dirty way which would probably catch 90% of the issues would be a text file of the format</div><div><br></div><div>ant*:WARN("Surely you don't need build tools in the deployment?")</div>
<div>*spring*:INFO("Please check you have at least version 3.0.3")</div><div>jta:ERROR("Don't do that, it's already provided")</div><div>hibernate*:INFO("Make sure you also configure your application for bundled hibernate")</div>
<div>guava*:INFO("You might also want to consider using the module com.google.guava")</div><div><br></div><div>We could have a local file with the usual suspects but you could also set the subsystem parameter "onlineCheck" that would go to a (predfined?) URL like <a href="http://jboss.org/stuff/wildfly/8/usualsuspects.txt">jboss.org/stuff/wildfly/8/usualsuspects.txt</a> for the list</div>
<div><br></div><div>Thoughts?</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, May 22, 2013 at 4:10 PM, Stephen Coy <span dir="ltr"><<a href="mailto:steve.coy@me.com" target="_blank">steve.coy@me.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>Hi Nicklas,</div><div><br></div>I had been thinking of doing something along similar lines.<div>
<br></div><div>However, I was considering a CLI command related to "deploy" that is able to replicate the class loading environment for each part of a deployment (ear, ejb-jar, war, far, etc) and then check whether or not each class in the deployment is already available in the class loader, subject to the spec's API visibility rules.</div>
<div><br></div><div>That may be a bit over the top though. </div><div><br></div><div>This is also a big +10 from me too, btw. We spend more time on the forums getting people to list their deployment contents when troubleshooting than anything else.</div>
<div><br></div><div>Steve C</div><div><div class="h5"><div><br><div><br></div><div><br><div><div>On 22/05/2013, at 10:34 PM, Nicklas Karlsson <<a href="mailto:nickarls@gmail.com" target="_blank">nickarls@gmail.com</a>> wrote:</div>
<br><blockquote type="cite"><div dir="ltr">An external tool is probably easiest to develop but wouldn't it be hard to know what classes are implicitly added by the deployers (e.g. JPA stuff based on persistence.xml) presence?<div>
For the modules, I guess one could iterate over the module roots, read in the module.xml:S, load thes module and see what's exported and build up a registry to see if there are packages provided both by the deployment and the AS.</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, May 22, 2013 at 3:23 PM, Scott Marlow <span dir="ltr"><<a href="mailto:smarlow@redhat.com" target="_blank">smarlow@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On 05/22/2013 04:04 AM, Nicklas Karlsson wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
That's a good example. I guess the JPA subsystem could check for<br>
incorrectly bundled Hibernate, JSF for incorrectly bundled impl, JAX-RS<br>
probably could use their own. Could they all be extracted to a common<br>
deployment-check-subsystem (or more precisely, should they?)<br>
</blockquote>
<br></div>
+10 for this idea.<br>
<br>
I like both approaches. It would be great to have a deployment *lint* detector of some form. If it is created as a common system, it might be more difficult to reach into the various deployers to diagnose issues.<br>
<br>
For the common approach, it could also be a standalone tool that is built up over time. If it is standalone, a log scanner would be a nice complement so that we could easily identify common runtime problems in addition to deployment time.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
<br>
<br>
On Wed, May 22, 2013 at 10:46 AM, Alessio Soldano <<a href="mailto:asoldano@redhat.com" target="_blank">asoldano@redhat.com</a><br></div><div><div>
<mailto:<a href="mailto:asoldano@redhat.com" target="_blank">asoldano@redhat.com</a>>> wrote:<br>
<br>
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/<u></u>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<br>
aborted.<br>
User will either fix the deployment or disable the webservices subsystem<br>
for it.<br>
<br>
Alessio<br>
<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<br>
source of<br>
> hard-to-debug deployment problems and other non-linear-behavior<br>
is that<br>
> people often try to deploy archives with conflicting dependencies<br>
> (various EE APIs/impls already on the AS, JDBC drivers, maven<br>
plugins,<br>
> you name it).<br>
><br>
> Would it be worthwhile to implement a deployment processor<br>
(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<br>
something<br>
> and people could write their own implementations (that would be<br>
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<br>
contains too<br>
> old version of lib, e.g. Spring)<br>
> * Unused libs (using Tattletale to warn if deployment contains<br>
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<br>
could<br>
> be scanned and the resources indexed or something. Performance<br>
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></div></div>
> Nicklas Karlsson, <a href="tel:%2B358%2040%205062266" value="+358405062266" target="_blank">+358 40 5062266</a> <tel:%2B358%2040%205062266><div><br>
> Vaakunatie 10 as 7, 20780 Kaarina<br>
><br>
><br>
><br>
> ______________________________<u></u>_________________<br>
> wildfly-dev mailing list<br></div>
> <a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.jboss.org</a> <mailto:<a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.<u></u>jboss.org</a>><div>
<br>
> <a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" target="_blank">https://lists.jboss.org/<u></u>mailman/listinfo/wildfly-dev</a><br>
<br>
<br>
--<br>
Alessio Soldano<br>
Web Service Lead, JBoss<br>
______________________________<u></u>_________________<br>
wildfly-dev mailing list<br></div>
<a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.jboss.org</a> <mailto:<a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.<u></u>jboss.org</a>><div>
<br>
<a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" target="_blank">https://lists.jboss.org/<u></u>mailman/listinfo/wildfly-dev</a><br>
<br>
<br>
<br>
<br>
--<br>
Nicklas Karlsson, <a href="tel:%2B358%2040%205062266" value="+358405062266" target="_blank">+358 40 5062266</a><br>
Vaakunatie 10 as 7, 20780 Kaarina<br>
<br>
<br></div><div>
______________________________<u></u>_________________<br>
wildfly-dev mailing list<br>
<a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" target="_blank">https://lists.jboss.org/<u></u>mailman/listinfo/wildfly-dev</a><br>
<br>
</div></blockquote>
<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>Nicklas Karlsson, <a href="tel:%2B358%2040%205062266" value="+358405062266" target="_blank">+358 40 5062266</a><div>Vaakunatie 10 as 7, 20780 Kaarina</div>
</div>
_______________________________________________<br>wildfly-dev mailing list<br><a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">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>
</blockquote></div><br></div></div></div></div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Nicklas Karlsson, +358 40 5062266<div>Vaakunatie 10 as 7, 20780 Kaarina</div>
</div>