Jenkins jobs and subversion access via certificate and batch related stuff

Jenkins is a very nice solution to a number needs outside of automated builds.  Use as a general batch solution is feasible at smaller scales.  This has further improved recently with the credentials plugin.  This makes it pretty easy to setup jobs which use certificates to access subversion instead of requiring a specific persons credentials which require a much more regular change.  Of course, this works best when an organization has the infrastructure to securely manage certificates.

[2014/05/20] Works!  It seems easiest to setup 2 separate Apache Virtual servers though; one with Basic Auth and the other with Certificate auth.  

Related to general batch processing, the Elastic Axis plugin is a great solution.  This is a perfect fit for when you have load balanced servers implementing an application and you need to run a job on any one but only one of them.  You can take an application node offline and Jenkins/Elastic Axis will happily pick an available node out of the remaining configured nodes.

My wish list for Jenkins includes a few enhancements which would improve some things to a large extent - this mainly revolves around new/improved support for high availability, multiple masters with fail-over and a clear/clean clustering solution.  A database backed job store might be a big plus depending on how the previously mentioned features were implemented.  I would love to be able to easily integrate Jenkins into our DR environment but as it stands it is a more manual integration.

Java security manager policy mechanism and non-trivial applications

We have a "pest" bothering us and to deal with the issue we decided to implement multiple security mechanisms.  The mechanism I am currently working on revolves around the age old Java security manager policy.  This really should be done at initial design/implementation if it is done at all.  A multitude of open source libraries isn't making this easy.  Not complaining mind you - just wishing that security was part of the initial requirements for all open source libraries.  Unfortunately, there are some pretty popular libraries which are somewhat troublesome and securing them is a bit disconcerting.  I can't comment on what libraries I am referencing out of security concerns and respect for my employer.  I will say that this is making my recommendation for complete removal of the libraries much easier to justify.

The general process to getting the security manager working with an existing application is:
* start application server with security manager enabled
* access application while monitoring logs
* when a failure occurs; update the policy file based on data in the log, clear logs and start this process over again

The app server logging is pretty good; it almost always contains 'denied' in the message and many times the remainder of the content can be cut/pasted nearly as is into the policy file.  There are times that debugging isn't easy; as when there are problems with components which start up early and/or eat exceptions instead of logging.

I would not bother trying to debug the security manager polices by setting

   -Djava.security.debug=all

that just generates way too much useless data.  I think that

   -Djava.security.debug=policy,access

is a better setting which gives a good amount of data to help in resolving failures and understanding what the application is accessing.