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?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._______________________________________________On Wed, May 22, 2013 at 3:23 PM, Scott Marlow <smarlow@redhat.com> wrote:
On 05/22/2013 04:04 AM, Nicklas Karlsson wrote:+10 for this idea.
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?)
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.
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.
> Nicklas Karlsson, +358 40 5062266 <tel:%2B358%2040%205062266><mailto:asoldano@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?
>
> --> wildfly-dev@lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>
> Vaakunatie 10 as 7, 20780 Kaarina
>
>
>
> _______________________________________________
> wildfly-dev mailing listwildfly-dev@lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Alessio Soldano
Web Service Lead, JBoss
_______________________________________________
wildfly-dev mailing list
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Nicklas Karlsson, +358 40 5062266
Vaakunatie 10 as 7, 20780 Kaarina
_______________________________________________
wildfly-dev mailing list
wildfly-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Nicklas Karlsson, +358 40 5062266Vaakunatie 10 as 7, 20780 Kaarina
wildfly-dev mailing list
wildfly-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev