<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><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><br><div><br></div><div><br><div><div>On 22/05/2013, at 10:34 PM, Nicklas Karlsson <<a href="mailto:nickarls@gmail.com">nickarls@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><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 class="im">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 class="im">
<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 class="h5">
<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 class="im"><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 class="im">
<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 class="im">
<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 class="im">
______________________________<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, +358 40 5062266<div>Vaakunatie 10 as 7, 20780 Kaarina</div>
</div>
_______________________________________________<br>wildfly-dev mailing list<br><a href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a><br>https://lists.jboss.org/mailman/listinfo/wildfly-dev<br></blockquote></div><br></div></div></body></html>