JAR blacklist for deployment

[ndipiazza]

Countless times that I've seen, a JBoss system JAR somehow gets accidentally deployed to the EAR/WAR file that we are trying to launch on JBoss.

Instead of giving a warning or an error stating that your web app contained this system jar on accident, it will instead lead you down several different misleading scenarios trying to fix the issue: Class Not Found errors are very common because of the conflicting objects in the class loader, but you also sometimes get a wonderfully nested exception causing you to waste a lot of time before only realizing... oops! doh. duh! there's jboss-ee.jar.

This especially happens when a new developer takes over some old project. While attempting to resurrect the build process for an older application, it's actually pretty common to accidentally deploy a system jar or two. While getting the maven dependencies back working, it's common to forget to set a scope to "provided." Or Eclipse when you include JBoss as a user library, you may forget to tell Eclipse not to write custom libraries to the deployment.

We should create a blacklist of JAR MANIFEST.MF files that will at very least generate something like:

[WARN] YOU HAVE A BLACKLISTED JAR IN YOUR DEPLOYMENT /path/to/blah.jar. YOU ARE LIKELY AN IDIOT. ARE YOU SURE YOU WANT TO BE AN IDIOT?

What do you guys think? If you like it I'll generate a new feature request and a Pull Request.

[nickarls]

It shouldn't be that hard to modify  https://docs.jboss.org/author/display/AS71/Extending+JBoss+AS+7 into a subsystem that scans for offending libraries based on some list, one would think.

[ndipiazza]

A subsystem is a nice way to go.

Is there an API that JBoss provides for the subsystem code to trigger events for "onAppDeployed" for example? And then an API to scan the classpath for a module at deploy-time?

Now that deployments are based on the JBoss Modules project, I'm lost as to how to add a validator during the deployment cycle.

[ctomc]

Hi,

take a look at subsystem example https://github.com/jbossas/archetypes/tree/master/jboss-as-subsystem-example

what you are interested in is deployment unit processor

example is here:

https://github.com/jbossas/archetypes/blob/master/jboss-as-subsystem-example/src/main/java/com/acme/corp/tracker/deployment/SubsystemDeploymentProcessor.java

i think you can quite easily modify this example to warn about some strange dependancies.

In general I like your idea

--

tomaz

[ndipiazza]

First of all, thanks for the feedback. I'm glad you think it's a good idea.

So as a follow up: what do you I'm looking for your opinions on the best strategy for coming up with the best default list of blacklisted JARs. In other words, JARs that are NEVER ok to have in your deployment.

I need to:

a) how to check to see if a JAR has been blacklisted.

b) getting a list of blacklisted JARs

My ideas for (a):

• Collect store a SHA1 checksum for all blacklisted JARs and store in text file conf/blacklist.properties. Load the checksum list as a dictionary during server startup. Validate SHA1 checksum for JARs deployed to verify none match a blacklisted JAR from the dictionary.
• Instead of storing a SHA1 checksum for the whole JAR, just blacklist a JAR when it matches one or more MANIFEST.MF entries. (Wildcards might be useful here too)

      E.g. If Specification-Title: JBoss and Specification-Version: 4*

----> This is the one I'm leaning towards.

• Instead of blacklisting JARs, blacklist certain Classes that if found in any JAR within your deployment will cause the warning. 

My ideas for (b):

List of all JBoss system JARs:

From AS7+: Blacklist some or all JARs from modules\org\jboss

For AS4-6: Blacklist all JARs in client/jboss*.jar, server/default/lib/jboss*.jar, and server/all/lib/jboss*.jar

That is a good default list for now.

Any ideas on this? 

[nickarls]

I actually has a monologue on the topic on the irc channel on dec 18 ;-)

[20:37:27] <nickarls> wonder if it would be difficult to take the example subsystem from "Extending JBoss AS 7" and make it a pluggable "Deployment sanity checker"? You could e.g. throw in a "hibernate" check module which would warn if you have bundled hibernate jars accidently etc...

[20:46:24] <nickarls> obsolete configuration files check, zipped war in exploded ear check, too-old-spring-version check etc. of course, the general deployers could be improved but these would be pluggable (and could be more verbose)

Like I said, it would be nice if the architechture would be pluggable and the JAR check would be one component

You might want to check what options JBoss Modules has for querying the module repository. Does it have a "what provides"-function for a class or can you list all jars in the module an match against regexp-patterns etc....

[ndipiazza]

Neat! Yeah I'm convinced that's the way to go. Thanks for that.

[nickarls]

As for the interface, perhaps something like

public interface DeploymentValidator

{

    public void validateDeployment(DeploymentUnit deploymentUnit) throws DeploymentUnitProcessingException;

}

might do. Or then DeploymentPhaseContext as parameter.

I'm not sure what would be the best way in JBoss Modules to add validation implementation JARs without having to list them explicitly in some module.xml. Perhaps the standard ServiceLoader mechanism is applicable.