1 of 1 people found this helpful
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.
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.
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:
i think you can quite easily modify this example to warn about some strange dependancies.
In general I like your idea
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?
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....
Neat! Yeah I'm convinced that's the way to go. Thanks for that.
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.