init-param vs context-param

see http://javahash.com/difference-between-servlet-init-and-context-parameter/ for background. Gist:
context-param variables are global and accessible through the ServletContext. init-param variables are configured per servlet.

E.g. the org.springframework.web.servlet.DispatcherServlet can be explicitely set to use a particular application context file via init-param, i.e. setting the contextConfigLocation variable (which overrides the default <servlet-name>-context.xml)

Conversely, to register a Spring Security application context, Spring can make use of a contextConfigLocation global context-param variable which it reads via a listener: org.springframework.web.context.ContextLoaderListener -- which is also a handy way to bootstrap a Spring application on Tomcat startup. Note that the Spring Security bootstrap mechanism also relies on adding a filter: org.springframework.web.filter.DelegatingFilterProxy.

Select Statement Transactions and Isolation Levels

http://docs.oracle.com/javadb/10.5.3.0/devguide/cdevconcepts15366.html

Shows how isolation levels are pertinent to reads, i.e. select statement transactions overlapping update statement transactions.

Jettison vs Jackson CXF JSON Providers

[org.apache.cxf.jaxrs.provider.json.JSONProvider] is Jettison based and supports only JAXB annotated beans. You should use Jackson provider to process POJOs without JAXB annotations

http://cxf.apache.org/docs/jax-rs-data-bindings.html

Gradle Tasks Example Execution

The following is a build.gradle which is what's executed when you run gradle <tasks>

task a << {  //double left angle brackets are the same as "doLast" or  more technically the "leftShift" operator
 println "in a"
}
  task b {
 println "in b"
}
  task (c, type: Copy) {
 from('c:/tmp/from/')
 into('c:/tmp/to')  
}
  c << {
 println "in c" //this ("in c") does not print below during the configuration phase for the same reason a doesn't: the print statement is in an action closure (added via leftShift op) unlike the print statements in b,d, and f whose print statements are executed as part of the configuration phase. Moreover, the "in c" is not printed in the execution phase. Why? because Gradle considers it doesn't have any work to do (hence the "UP-TO-DATE") output. If there was a file in c:/tmp/from/ then "in c" would be printed so I guess Gradle determines "didWork" property from the Copy type and ignores the leftShift appended print task here.
}
  task (d, type: Copy) {
 println "in d"
}
task e {
 doLast {
  println "in e"
 }
}
task f {
 println "in f"
 doLast {
  taskname -> println "in $taskname doLast" //note groovy (pun intended) use of lambdas.
 }
}
task g(dependsOn: c) << {
 println "c did work: " + c.getState().getDidWork();
 println "c.destinationDir: " + c.destinationDir
}
task h(dependsOn: b) << {
 println "b did work: " + b.getState().getDidWork();
}
task i(dependsOn: a) << {
 println "a did work: " + a.getState().getDidWork();
}
gradle.taskGraph.whenReady {taskGraph ->
    println "c is set to execute: " + taskGraph.hasTask(c)
}
println "the end of configuration phase"

executed:

>gradle a b c d e f g h i
in b
in d
in f
the end of configuration phase
c is set to execute: true
:a
in a
:b UP-TO-DATE
:c UP-TO-DATE
:d UP-TO-DATE
:e
in e
:f
in task ':f' doLast  // note the output from a, e, and f but none from c for reasons stated above.
:g
c did work: false
c.destinationDir: C:\tmp\to
:h
b did work: false
:i
a did work: true

BUILD SUCCESSFUL

Total time: 3.222 secs

ref: https://discuss.gradle.org/t/how-to-understand-task-creation-syntax/4478
see also: https://docs.gradle.org/current/userguide/build_lifecycle.html

12/16/2015

Learned
-about using joda time's DateTime to parse a UTC date.
-about using Apache Commons XMLConfiguration to drive strategy
-about one pattern for using strategies in a Java Spring Application:
in beans file add:
    <bean id="byWhichMeansStrategyFactory" class="com.awgtek.byWhichMeansStrategyFactory" factory-method="createStrategy">
<constructor-arg index="0"  ref="myXmlConfig" />
<constructor-arg index="1" type="java.lang.String">
  <value>this_means</value>
</constructor-arg>
    </bean>
   
    <bean id="MyImpl" class="com.awgtek.DoesSomethingImpl">
        <constructor-arg index="0" ref="byWhichMeansStrategyFactory" />
    </bean>

The createStrategy method would instantiate the correct strategy class basd on the "this_means" value. The injected strategy would then be used to e.g. pick a consultant either through "cheapness" defined by some parameters in the strategy or skill, etc. see http://blog.lowendahl.net/design-patterns/strategy-pattern/

-about using Guava, e.g. to import static com.google.common.base.Preconditions.checkNotNull to do checkNotNull statements where needed.

Camel vs Spring Integration (SI)

Camel uses producer templates to access routes.

SI uses gateways to access channels.

Modular JavaScript Articles

http://adripofjavascript.com/blog/drips/variable-and-function-hoisting

http://www.adequatelygood.com/JavaScript-Module-Pattern-In-Depth.html

http://addyosmani.com/writing-modular-js/