Animation of height of LinearLayout container with ValueAnimator

Had some issues with animation in Android a couple of years ago and I posted the solution to StackOverflow. I thought I might post it here as well :)

Looking at chitgoks blog post I found that I shouldn’t use view.invalidate() to have the layout redrawn. I should use view.requestLayout().

Thus the code becomes something like this:

I just wanted to add a note on how to get the height of the LinearLayout as well to make the animation dynamic. To get the height all the views need to be drawn first. Therfor we have to listen for an event that tells us that the drawing is done. This can be done from the onResume() method like this (note that in my xml I have declared the container to wrap_content for height and it is also visible, since I want to hide it from the start I do that efter measuring it):

Crypto fundamentals


One-Time Pad

  • Start with random sequence of letters
  • Write message without spaces and punctuation
  • Add numbers mod 26

  • Unbreakable if truly random

  • Different keys may give different resulting messages


  • Toss of coin generates 1 bit of entropy
  • Toss coing 8 times -> 8 bits of entropy -> 8 bits of storage to record outcome
  • Using OTP in takes log2(26) = 4.7 bits of information to record one letter
  • In OTP with 1000 letters we get 4700 bits of entropy
  • If truly random and only used once we get maximun entropy
  • Entropy does not increase witout adding more randomness


  • Much weaker then OTP (though still hard to break!)
  • Used interconnecting rotors applied in order
  • Rotors rotated with each keystroke (central rotor stepped twice to prevent consecutive patterns)
  • Also used a plug board to be able to swap letters in a fourth mapping
  • Same machine could be used to encrypt and decrypt but this prevented an output letter from ever being the same as the input


  • One mapping represents multiple different offsets

  • Entropy of 26 letters in OTP: 4.7*26 = 122.2

  • Entropy of 26 letters in Enigma rotor: 4.7 bits (internal wiring is constant)

  • Usage of reflector for decryption reduces entropy from log(26) to log(25) = 4.6 bits

  • Usage of double stepping central rotor also decreased entropy from 262626=17576 to 262526=16900

  • Same initial rotor settings used for a full day
  • No repeated initial rotor settings in a month
  • Key was encrypted twice in message and prepended (generated pattern)
  • Same message sent twice with different encryption (play cipher texts agains each other)
  • Plugboard configuration did not change during day so it was possible to combine intercepts to guess configuration

Diffie-Hellman key exchange

  • Whitfield Diffie and Martin Hellman (assisted by Raplh Merkle)
  • Key agreement and generation can be done over an untrusted channel

  • 2048 bit is smallest prime considered secure (616 digits)

  • Number of water molecules on earth (46 digits)

  • Very vulnerable to MitM since a MitM can send different values to Alice and Bob


  • Entropy is critical
  • Scrambling does not increase entropy
  • OTP can be proven secure but are hard to use
  • Patterns can be exploited
  • Weakest link is the human operator


  • Comes in 3 flavours to create a crypto system
    • Symmetric – Encrypts and decrypts
    • Asymmetric – Encrypts and decrypts
    • Hash Functions – Verifies authenticity
  • Relationship between key and ciphertext is called Confusion
    • Small change in key -> large change in ciphertext
    • XOR not sufficient; one-to-one
    • Key schedule gives us a large change
  • Relationship between message and ciphertext is called Diffusion
    • Diffuse the information so that small change in message -> large change in ciphertext
    • Hides patterns within message


  • Uses same key to encrypt and decrypt

Block ciphers

  • Block ciphers used to make it possible to use shorter key then message
  • Typical block size is 16 bytes
  • Operates in rounds where part of key (Round Key) is applied on block with some other operations
  • After some number of rounds, we end up with cipher text
Round Key
  • Derived from key using a key schedule
  • Key Schedule is an algorithm that can Shift, XOR, Multiply and perform other operations on original key
Electronic Code Book (ECB)
  • Encrypt blocks induvidually
  • Easy to crack since we get a lot of patterns and repeated information
Cipher Block Chaining (CBC)
  • XOR’s next adjacent block with previous block
  • First block is XOR’d with an Initialization Vector (IV) same size as block
  • Diffuses information
  • Makes it possible to encrypt message of arbitrary length when having fixed length key

Data Encryption Standard (DES)

  • Key length 64 bits using 8 bits for parity check -> 56 bit key
  • Has theoritical issues but key length is also much to short
  • Used in 3DES where DES runs 3 times with 3 different keys -> key length 168 bits

Advanced Encryption Standard

  • Uses Rijndael as encryption algorithm
  • 128, 192 or 256 bit keys
  • Block size 16 bytes organize din 4×4 matrix


  1. Uses key expansion to confuse the key and create a round key
    • Shift orignal key then;
    • XOR then;
    • Multiply
  2. XOR block with Round Key
  3. Substitution using S-Box
    • Essentially a lookup table with 256 entries where each byte is substituted
  4. Shift rows
    • Move top to bottom
  5. Mix columns to further confuse the key
    • Rotate the bytes in each row with a different number
    • First row is not rotated
    • Second row with one byte
    • Third row with two bytes
    • Fourth row with three bytes

Cryptanalysis – Why is Enigma weaker then AES?

  • Engima

    • 47.1 bits in plugboard
    • 14.1 bits in rotors
    • Total: 61.2 bits
    • No memory -> No diffusion
    • Predictable key exchanges -> little confusion
  • DES

    • 56 bits of entropy
    • CBC and IV -> Good diffusion
    • Rounds -> Good confusion
  • AES

    • 128-256 bits of entropy
    • CBC and IV -> Good diffusion
    • Rounds -> Good confusion


  • English text has about 0.6 – 1.3 bits of information per character
  • Compressed ASCII can be compressed to about 40% (although theoretical limit is 7.5 to 16%!)
  • Squeezes out redundancy and preserves information

Encryption vs Compression

  • Encryption masks patterns and adds information
  • Compression after encryption os not effective
  • Compression uses redundancy and removes compression
  • Compress before encrypting -> More diffusion

Error Correction

  • Operation
    • Checksums
    • Discover errors
    • Correct errors
  • Combined with encryption
    • Adds redundancy
    • Makes ciphertext easier to crack
  • Only error check at time of transmission, not encryption!
    • Does not weaken encryption but still protects the message


  1. Compress
  2. Encrypt
  3. Transmit and correct


  • Diffie-Hellman first example of asymetric algorithm
  • Needs proof of identity (public key)

  • Find numbers to use for exponents using RSA

Elliptic Curve Cryptography (ECC)

  • A non-vertical line intersecting 2 points will also intersect a third
  • No line intersects at more than 3 points
  • The curve is symmetrical
  • Basic operation

  • Easy to find An if A0, A1 and n are given

  • Very difficult to find n if A0, A1, An are given

  • Example function: y^2 = x^3 + 3x + 5 mod p where x and y are integers and p is prime

    • Private key: n
    • Public key: An
  • Can use shorter keys then RSA (163-359 bits)

Hash functions

  • One way functions that can digest a message
  • Encrypt message digest with private key -> signed message
  • Receipient computes same hash and decrypts signature to verify

CRC 32

  • Produces a 32-bit hash based on Cyclic Redundancy Check
  • Uses a 33 bit polynomial and stores 32 bits of it
  • Easily reversible since intended for error detection, not suitable for signatures
  • A MitM can reverse the algorithm and replace the original message with an evil message with same hash

Cryptographically Strong Hash Functions

  • Uses bit shifts, modulus addition and XOR in rounds to diffuse message
  • Makes it difficult to reverse the process
  • Very popular but very weak
  • No longer suitable for use
  • 160-bit hash
  • Invented by NSA
  • Also has severe weaknesses
  • No longer recommended after 2010
  • Invented by NSA
  • Contains many different
    • SHA-256
    • SHA-512
  • 2012 NIST competition
  • Collection of functions
  • Based on Keccak algorithm
  • 224-512 bit hash
  • Has much larger internal state

Birthday Attack

  • Probability that two share a birthday in the same room: 1 – everybody has unique birthday
  • 1 person enters room -> 365/365 likelihood for unique birthday
  • 2 person enters room -> 364/365 likelihood for unique birthday
  • 3 person enters room -> 363/365 likelihood for unique birthday
  • 20 person enters room -> 346/365 likelihood for unique birthday 94.7%
  • Probability that all above happend and all were unique: 365/365 * 364/365 * … -> 58.9% for 20 people
  • 23 people -> greater then 50% probability that two have same birthday
  • MitM does not try to match a specific document that is to be signed
  • MitM tries to have signer sign one of MitM documents
  • MitM tries to find hash collisions

  • Protocols demand that we never sign someone else’s document

  • Always append randomness


  • We sign public keys to proove identity
  • Can be done by individuals in a Web Of Trust
  • Can be done by authorities in a Chain Of Trust


  • Asymmetric crypto
    • RSA
    • Elliptic Curve
  • Symmertic crypto
    • DES
    • AES
  • Hash Functions
    • MD5
    • SHA 1, 2 and 3
  • Combine algorithms to provide confidentiality and authenticity
    • Encrypt message with symmetric key
    • Encrypt symmetric key with public key
    • Compute digest with hash
    • Encrypt digest with private key


  • Java Cryptography Extensions (JCE)
  • KeyGenerator generates SecretKey
  • KeyPairGenerator generates Private/Public Key pair
  • SecureRandom is a PRNG and IvParameterSpec for IV’s in block ciphers
  • Cipher and Signature classes perform crypto operations
  • CipherInputStream and CipherOutputStream hooks into the Java stream model
  • JCE uses maximum AES key size 128 bits
  • Unlimited JCEPolicy extra policy files that allow 256 bits
  • Bouncy Castle can be used as well if default JCE is not enough

Symmetric Java API’s

Asymmetric Java API’s


  • Defined by X.509 standard
  • Contains a subject, validity, public key and signature from CA
  • Subject is a Distinguished Name; hierarchy of information
    • Country (C)
    • State (ST)
    • Locality (L)
    • Organization (O)
    • Organizational Unit (OU)
    • Common Name (CN) (i.e. domain name on a site)
  • Uses Chain Of Trust
    • Certificate signed by intermediate CA
    • Intermediate CA signed by Root CA
    • Root CA pre-installed in browser and is self-signed
  • Used in different Public Key Cryptography Standards (PKCS)


  • Cryptographic Message Syntax
  • Certificates

PKCS #10

  • Certification Requeste

PKCS #12

  • Personal Information Exchange Syntax
  • Private keys

Common File Formats



  • Certificate uses a Subject (Distinguished Name)
  • Certificate has a validity and public key
  • Certificate is signed by issuer
  • OpenSSL has multiple commands for working with different types of PKCS formats
    • genrsa
    • req
    • x509
    • pkcs12

Authentication and Authorization

  • Passwords are problemtic

    • Reused
    • Dictionary words
    • Not enough entropy
    • Phishing
  • Offline password attacks on leaked databases

    • Dictionary attacks
    • Rainbow tables
    • Same hash on different users
  • Using salted hashes makes it harder to attack

  • Password Based Key Derivation Functions (PBKDF) can be used

Computing Password Entropy

  • H = L * log2 * N
  • Common substitutions (0=o, 1=l, 1=i, etc)
    • Log2 of (size of sustitution dictionary * number of characters)
  • Dictionary words
    • Log2 of (size of dictionary * number of words)
  • Capitalization
    • Mostly caps or mostly lower?
    • 1 bit for each different capital not at the beginning of the word
  • Remaining characters
    • Log2 of (size of alphabet * number of characters)

PBKDF (Password Based Key Derivation Functions)

  • Intended for deriving a symmetric key and IV from a password
    • Used in openssl when encrypting RSA key with AES-256
    • Can be used to generate a salted hash
  • Slow down an offline attack
  • Uses Key Stretching


  1. Divide password into blocks
  2. Hash each block
  3. Hash the output of 2 again and xor with previous hash
  4. Repeat n times for each block (n > 10000 preferred)
  5. Append results

  • Might want to use different algorithms so we store the algorithm in the DB
  • Also good for future migration


  • Remove responsibility of identity from applications
  • Separate authentication from authorization
  • Based on trust between multiple parties
  • Identity proved once and authorization granted through different “tickets”


  • Identity Provider (IP) performs Authentication in centralized identity management
  • Secure Token Service (STS) performs Authorization in single repository of roles and responsibilities
  • Relying Party (RP) consumes STS token and takes action based on token claims and can focus on business logic
  • Both IP and STS are providing services so they are usually called IP-STS and RP-STS


  • Both authentication and authorization
  • Used in many OSs including Windows, OS X and some Linux distros
  • User receieves a Ticket Granting Ticket from Identity Provider (IP)
  1. User asks IP for token
  2. IP sends token (TGT) encrypted with symmetric key generated from users password (PBKDF)
  3. User can decrypt the TGT if he knows the password
  4. TGT used to request access from other services that perform authorization

WS-Trust and WS-Federation

  • Protocols for Web Services
  • Defines a protocol and XML schemas for SOAP web services to exchange security tokens
  • Active federation – client machine provides proof of identity
    • Client produces a Proof Key (often asymmetric)
    • Client signs a message to prove ownership of the key pair
  • Passive federation – browser redirects exchange tokens through cookies
    • Password based authentication
    • Bearer token signed by STS and encrypted for a specific RP
Secure Assertion Markup Language (SAML)
  • XML-based
  • Provides authentication and authorization claims (assertions)
  • Assertions signed by STS
  • Enveloped signature with reference to its assertion, usually by ID
  • STS signs the Assertion and Signature

XML Signature Wrapping Attack
  • Signature not always enveloped in the assertion, can appear anywhere
  • Certain SAML implementations vulnerable to exchange of elements
  • Signature has signed the “valid” token and the assertion has been added to another part of the document
  • Implementations might validate one assertion and then use another


  • Used in social applications and mash-ups
  • Delegates access to services
  • Only provides authorization
  • Allows Agents (clients) to perform actions on behalf of User (like 3rd party Web Service)
  • The Agent (Client) is authorized, not the User
  • Relies on signed token request and share symmetric client secret
  1. Client registers with OAuth Service Provider and receives a Client Key and Client Secret
  2. User wants Client to act on his behalf so Client requests a Request Token from Service Provider
  3. Client signs the request with the Client Secret
    • Secret is XORd with one constant and then prepended to the message
    • Result is hashed and key is XORd with a different constant and prepended to result
    • Result is hashed again so that the resulting hash is based on message and client secret
  4. Service Provider performs the same operation using the stored Client Key and generates a One Time Token
  5. One Time Token is sent to the Client
  6. Client redirects the User to the Service Provider passing along the One Time Token
  7. User grants Client access (authorization) to the Service Provider
  8. Service Provider redirects User to Client with a Bearer Token
  9. Client can use Bearer Token to get information from Service Provider on User behalf
Mobile and Desktop Apps
  • No backend, uses API calls from Client
  • Client secret embedded in mobile app
  • Apps can be decompiled to find secrets
  • Very problematic since a User may loose control of the access granted to an Agent

OpenID Connect

  • Originally user owned the identity provider
  • Now it is available through Facebook, Twitter, Google etc
  • Built on top of OAuth although OpenID is about Authentication rather then Authorization
  • Usually Authorization comes after authentication
  • OAuth is not authorizing User however, only authorizing an Agent to act on the User behalf
  1. User wants to access an Agent
  2. User is bounced to Service Provider
  3. User authenticates and creates an Access Token for the Agent
  4. Agent checks with Service Provider if user is authenticated


  • Passwords is most commong and should be hashed, salted and re-hash (bcrypt, scrypt ftw)
  • Tokes are signed to prove vercity of claims and assure trust relationships
  • Weak crypto is sometimes used with Bearer Tokens and unprotected Client Secrets
  • Crypto is great but must be used correctly!

Case studies

  • Some examples of incorrect usage of crypto


  • Social network
  • Reviewed by Gibson Research
  • Reverse Engineered API and published API
  • Snapchat did not act on notification
  • Bad use of crypto

Snap encryption

  • Used AES ECB (weak)
  • Changed to CBC later
  • Still used same symmetric key
  • Key available in Android and IOS apps
  • Find Friends API allowed user lookup by phone number with no rate limiting
  • Symmetric key should have been unique for each user
  • Users should also have unique Public Keypair to exchange symmetric key
  • Snaps should have been signed by the user who took it so receiver could reject invalid snaps (prevent DoS and spam)


  • Reviewed by Adam Langley
  • Goto fail allowed any signed certificate to be used although invalid
  • OpenSSL requires private key for signature so it could not be used to generate a key
  • Trivial to create one anyway using code
  • Should have had better code review


  • OpenSSL library mistake
  • Heartbeat supposed to send back whatever the client sent the server
  • Pointer p with a TLS Heartbeat record could be used to overflow since the client provided the length of the buffer
  • Client could claim to send 64k of data although specifying much less like a few bytes
  • Server would send back 64k of memory that happen to sit next to the bytes from the client
  • Leaves no trace
  • Keys, certificates and other sensitive data could leak
  • Should have had better code review


  • Reviewed by Brian Krebs
  • Attackers installed malware on Point of Sales systems
  • Pin pad gathered pin and credit card data and sent it to PoS
  • PoS intercepted the data and dumped it to a share
  • Attackers remote connected to get the file every now and then
  • Not a crypto attack, needed access to PoS
  • Track Data is unencrypted, chip with encrypted data would have helped
  • PIN number sent to chip causes a unique CVV (iCVV) is created that is used to process payment
  • PIN would then never have been sent to PoS
  • Some Chip and Pin systems have static iCVV numbers though, which opens up for replay attack
  • Dynamic Chip and Pin is much better but Pin Pad could also intercept the data if Pin Pad is infected
  • Pin Pad could then be MitM and steal pin or present different amount for transaction
  • Smartphone could be used to get rid of middle hand hardware


  • Knew about differential crypto analysis without telling the world
  • Dual Elliptic Curve PRNG has constants P, Q and Phi are defined in the specification being suspicious of a back door
    • If exponent e is known such thta Q^e=P it is possible to determine the internal state of the machine
    • Would make it possible to predict new keys
    • Could be that there is no issue, but understanding the full system is important
  • Peer review is critical
  • Simplicity is critical
  • Don’t trust math provided by 3rd party

Lessons learned

  • Avoid static symmetric keys
  • Keep private keys private
  • Use asymmetric crypto to establish trust
  • Dont write crypto code on your own
  • Audit all crypto code
  • Question crypto provided by 3rd party
    • Understand the source
    • Understand the implementation

Jersey Async REST



  • Jersey 1 uses com.sun.jersey
  • Jersey 2 uses org.glassfish.jersey.*
  • Make sure you know which version you are using


  • Jersey does not require servlet framework
  • Grizzly HTTP container can be used
  • Grizzly is a framework using Java NIO API
  • Divided into Core Framework and HTTP Services

HTTP vs. Servlet Containers

  • Servlet Container uses War file with web.xml file and source
  • HTTP Container uses a Main classto launch rest of source and deploys in Jar
  • Lots of other containers can be used (jetty, jdk, simple http, tomcat)

Generating starter project

  • Use Maven archetype

  • Generates Plain Old Resource (

  • Generates with resource config elements


  • Scans for components using packages() and files()
  • Register custom JAX-RS componenets with register()
  • Get and set application properties

Simple example

Testing with JerseyTest

  • Leverages existing jersey components
  • JerseyTest provide both Container and Client
  • Tests use the client to invoke API’s deployed in container
  • Important methods:
    • configure()
    • configureClient()
    • target()
    • enable()

Configuring Container and Client

Invoking an endpoint

Example tests

Test properties

  • It is possible to configure features and properties when running tests

Dependency injection and POST support

  • Using the @Context annotation
  • Many different Classes available for injection

  • Using HK2 to add to @Context and inject our own objects

  • Requires a Binder registered with ResourceConfig

Async requests

  • @ManagedAsync and @Suspended are commonly used annotations

  • Grizzly Threads receives request -> Passes on to Jersey Async Threads

  • Databases (or other Applications) may provide their own async interfaces

  • Application Threads can be combined with Jersey Async Threads

  • AsyncResponse can be used in many different ways

  • Guava can be used in DAO to give it an asynchronous interface

  • URI invoked -> Resource method -> DAO method | ListenableFuture.onSuccess(stuff) <-|

  • Collections and Concurrent hashmaps may cause issues using the built-in Moxy JSON support

  • Good thing we can use Jackson instead!


  • Jackson can process data (json, xml etc.)
  • Register in resource config
  • Watch out for format changes on dates, enums, properties etc.
  • Has many annotations and configs for changing behaviour and formats

  • Jackson can store arbitrary elements that are submitted using annotations

  • Adding XML support

  • Prioritize json over xml

  • Other XML annotations


  • Converts Java type to Stream
  • Can be used to format json and xml differently
  • Uses isWrtieable to determine which MBW to use

Bean Validation, Exceptions and Conditional GET

  • Beans can be validated with Annotations
  • Hibernate Validator is used in Jersey
  • Setup in pom.xml and can be configured in resource config
  • Possible to write custom ValidationConfig class

  • Validate using @Valid and @NotNull annotations

  • Possible to map Exceptions to Responses

  • Use EntityTags to support “If-None-Match” and conditional GETs

  • Use ResponseBuilder to build() response to client

  • ResponseBuild can set any header (cache, cookie, encoding, links, last modified etc.)

PATCH support

  • Extend Jerseys supported HTTP verbs with PATCH
  • Can be used through a custom annotation
  • Needs a custom client connector like Grizzly’s

  • Can be extended by supporting the If-Match header

  • Uses evaluatePreconditions as conditional GETs

  • The caller supply an entity tag which must match the servers

  • If not, it’s assumed the servers tag has changed

Filters in Jersey

  • Supports JAX-RS filters
  • Can modify requests and responses
  • Pre-Matching Request Filter
    • Applied to incoming request before method is selected
  • Post-Matching Request Filter
    • Applied after Resource method is selected but before execution
  • Response Filter
    • Applied after Resource method
  • Filters need modification to use async functionality, runs in Grizzly Thread by default
  • Can use Name Binding to control usage of filters

Filters vs Interceptors

  • Filters
    • Modify headers, entity and other request/response params
    • Executed regardless of wheter there is an entity to read/write
    • Can abort a request and prevent resource method from executing
  • Interceptor

    • Primarily to manipulate the entity
    • Can change properties to affect choice of Message Body Reader/Writer
    • Only executed if there is an entity to read/write
  • Execution Order

    1. Pre-Match filters
    2. Post-Match filters
    3. Reader Interceptor
    4. Response Filter
    5. Writer Interceptor
  • Jersey Filters

    • Logging
    • JAX-RS to Spring Request attribute bridge
    • CSRF protection

    • HTTP method overrides

    • URI-based content negotiation

Custom filters

  • Possible to write custom request/response filters
  • Can use annotations to decide which type of request filter
  • Implements a filter method

  • Use name binding to choose when filter is applied

    1. Define a name binding annotation

    2. Associate annotation with filter or interceptor

    3. Use annotation to flag a resource method (or application)

Java Servlets and Faces Fundamentals

JavaEE Servlets and Faces


  • Java Applet designed to run on a server
  • Extend capabilities of server
  • Java counter part to PHP,
  • Request/Response model
  • Implements Java Servlet API (javax.servlet)


  • GenericServlet
  • HttpServlet


  • 3 phases
    1. Initialize: init()
    2. Send request to servlet: service()
    3. Remove: destroy()


  • Defines user interface
  • Has pre-built tags


  1. Create web page
  2. Associate page with components via tags
  3. Associate components with server side data through managed beans
  4. Create web deployment descriptor


  • 2 main phases

    1. Execute: Translates user input and executes code on the input
      • Build or refresh application view
      • Apply parameters of request
      • Recalculate components
      • Run the code
    2. Render: Translate machine output and renders it to human readable form
      • Generate new UI
  • 6 phases

    1. Restore view
      • When a request for a JSF page is made
      • Builds view and sets up event handlers
      • Put view in faces context index
      • If initial request, go straight to 6.
    2. Apply request values
      • Called on postback
      • Components extract values from request
      • Events that are queued can be broadcast and executed by listeners
    3. Process validations
      • Validates values for components
    4. Update model values
      • Stores local component values to server side components
    5. Invoke application
      • Application level events like submit form and navigate to other page
      • Can go to Complete face or Render response depending on target
    6. Render response
    7. Complete

Managed bean

  • Java object that represents a resource in the JVM
  • Bound to a:
    • Component value to validate some data
    • Component instance to handle events for that component (like page navigation)
    • Converter instance
    • Listener instance
    • Validator instance

Component rendering

  • javax.faces.component.UIComponent
    • Command
    • Form
    • Output
    • SelectOne
  • Behavioral interface
    • ActionSource2
    • StateHolder
    • ValueHolder

Web context

  • Normally one context per application
  • Can also be distributed (1 context per vm)
  • Basic parts
    • Init parameters
      • Specific values to be passed to certains components when application is run
        • Font type
        • Encoding
        • Data
      • Stored in web.xml
    • Associated resources and object value attributes
      • Stored in web context
      • Data and attributes available to all servlets
      • Basically a global storage
    • Functions dealing with logging data
      • Log error messages
      • Store and analyze user traffic data
      • Monitor latency

Client state

  • Requests are not independent
  • Need client state in application (session)


  • Represented by HttpSession object
  • Can store object-value attributes
  • Can listen to binding and activation events for the HttpSession
  • Session uses timeout for expiry
  • Calling a service method resets the TTL counter for the session

JavaEE Fundamentals

Java EE

Difference to SE

  • EE extends SE
  • EE tiers include web, client, business and information tiers with separate tools


  • Web Components
    • JSP/Servlets/EL/JSF/JavaBeans
  • Web Services
    • JAX-WS, JAX-RS
  • Data Access
    • JDBC, JPA (persistance api), JTA (transaction api)
  • Persistent Entities and Java Beans

HTTP Servlet

  • Allows client to interact with server
  • Similar to applet but run by server
  • Generally tightly focused in purpose
  • All servlets have the same methods available
    • init()
    • service()
  • Base class is GenericServlet extended by HttpServlet
  • Can execute Java code and generate HTML

JSP Overview

What is it?

  • A web page
  • A servlet
  • A view
  • Allows for more then just HTML


  • Include: can include files for use in the page
  • Page: gives ability to control things on page, import, sessions, ignores
  • Tag: allows for the use of tags to control libraries of code


  • Use <% %> to wrap code blocks
  • Allows Java execution in JSP file
  • May need additional imports
  • May require use of declarations


  • Use <%! %> to wrap declarations
  • Instantiate objects/variables/methods for use in scriptlets


  • Use <%= %> to wrap an expression
  • Renders object info to screen
    • Fill in forms
    • Render dynamic content

Expression language

  • Expressions to get managed information
  • Communicate well with objects
  • Chaining to get to properties
  • Use ${} to interact with EL

Tag libraries

  • Can be included for use in the page, pre-defined or custom
  • Accessed via the prefix assigned and valid methods from the library
    <%@ taglibname prefix="variable" uri="..." %>

JSP Actions

  • Standard
    • jsp:include
    • jsp:forward
    • jsp:useBean
    • jsp:getProperty
    • jsp:setProperty
  • Other
    • Core library actions on included in standard actions

Implicit objects


  • JSP allows for programming on the View
  • Interaction with the Controller
  • Other ways to navigate
  • Render dynamic content
  • Lots of tools already in place

Actions, JavaBeans and Expression Langage (EL)

Standard Actions

  • Available on JSP pages
  • Syntax is tag/markup language format
  • Most common
    • include – imports resources
    • forward – forwards the request
    • useBean – work with objects get/create
    • setProperty – set the bean object properties
    • getProperty – get the bean object properties
  • Other
    • element – xml
    • attribtue – xml
    • body – xml
    • text – template text for JSP page
    • plugin – embedded objects

Java Beans

  • Serializable class, used as Model
  • Contains a default no argument constructor
  • All properties use get/set/is methods
  • Other properties named in camelCase
  • Not the same thing as an Enterprise Java Bean
    • EJB is more persistance focused on services

Expression Language

  • Expressions give direct access to objects/beans
  • Access to every scope through implicit objects
    • sessionScope
    • pageContext
    • applicationScope
    • header
    • initParam
    • param
    • requestScope
    • cookie
  • Simple and powerful
  • Expressions are wrapped with ${}


  • Actions provide tag-like syntax for common operations
  • Beans is the specification we use to build models
  • EL is used to access the Bean data

Tag Libraries

  • Not included by default
  • Included as directive on JSP page
  • Core tags used for program/flow control on the page without having to use Java
  • Tags reference with prefix “c”

Custom tags

  • Declared with:

    • mlns, xmlns, xsi:schemalocation, version


    • The namespace/package
    • Must match or wont work
    • Link/location is irreleveant
    • Can be a simple identifier [i.e myTags]


Body content

  • Tag-dependent: Embedded commands handled by tag library
  • Empty: No body
  • Scriptless: String literals, EL expressions or tags only. No scriptlets.



  • Create class that extends SimpleTagSupport (tag-class)
  • Implement the doTag() method for execution
  • Must have public mutators for any attributes on the tag

EL Functions

  • Define in TLD file
  • Map to Java class that performs the function
  • Must also define which method to run with its return type and parameter


  • Passed in chains
  • Can be used to parse request and response data for specified paths
  • Filter can for example validate a user before the filter chain can complete
  • If auth filter fails, the filter can redirect to login rather then continue the chain
  • Some older filters have to be defined in web.xml


  • Can intercept data and inspect parameters for validation or authentication
  • Can also modify parameters (uppercase, lowercase, validate)
  • Uses a filter on the request
  • Applied in a filter as the request/response goes through the chain

HTTP Server authentication and authorization (Tomcat)


  • Copy config file for backup
  • Remove all comments
  • Add roles

  • Add users


  • Copy config file for backup
  • Remove all comments (except realm info and ssl port)
  • Comment out
  • Add Realm for memory


Security constraint




  • Configure webserver with keystore
  • Configure web.xml

Spring JPA Hibernate Fundamentals


  • Interface for a specific ORM implementation
  • Actually just a specification thought of as an Object Relational Mapping tool
  • CRUD for Java objects and a relational database
  • Uses JPQL (Java Persistence Query Language)
  • Heavy focus on POJO and its mapping to the database
  • Many providers: EclipseLink (TopLink), DataNucleus, ObjectDB, OpenJPA, Versant, Hibernate
  • Using JPA to talk to ORM makes transitioning easy


  • Controller <-> Service <-> Repository <-> DB
  • Controllers handle requests
  • Service handles business logic
  • Repository saves data to db through EntityManager


  • ORM (sql)
  • OGM (nosql)
  • Search
  • Validation

Configuring JPA

  • Add ContextLoaderListener to web.xml to load jpaContext.xml


  • Add namespaces beancs, xsi, tx, context
  • Add context annotation config and scanner that points to package with classes
  • Add persistance annotation bean post processor to inject persistence context into entity manager factory
  • Create local entity manager factory
    • persistence unit
    • data source
    • vendor adapter
    • turn on to show sql
    • map to jpa property map to set dialect and sql formatting
  • Create transaction manager and enable tx annotations for the transaction manager
  • Create datasource with user, password, url and driver class name

jpaPropertyMap properties
  • hibernate.dialect (MySQLInnoDB)
  • hibernate.format_sql (formats output)
  • (creates database for us automatically)
    • create
    • create-drop
    • update
    • validate
    • none

Entity and Business Objects

  • Is a POJO with @Entity annotation and @Id

  • Good for storing data and maps to the database

  • Business objects can join several entities and be presented to user

Java Persistence Query Language (JPQL)

  • This is not SQL
  • Centered around objects, take care of naming!

JPA Annotations

  • xml and hbm files can also be used to bind objects
  • use @PersistenceContext to get the entityManagerFactory and inject it into code

Fetch types

  • Lazy queries when property is called

    • Can throw LaxyInitializationExeption which is very common when session is clsed
    • OpenEntityManagerInViewFilter can be used to prevent sesion being closed to early

  • Eager queries when object is created


  • Selects the fields we are actually interested in
  • Great way to present objects to UI
  • Objects are added using JPQL-syntax
  • Projection objects can be Jpa Entities
  • Need a constructor for the projection
  • Can join entities into a non-entity (requires getters and setters)


  • Cleaner than adhoc JPQL
  • Not required but focuses on the domain and is stored in domain objects
  • Has named parameters

Spring Data JPA

  • In JPA Persist and Merge (Create and Update) are different methods that return different objects
  • Framework to eliminate boiler plate code in the DAO layer

  • Spring JPA wraps JPA by replacing the Repository Tier to eliminate boiler plate code

  • Can be extended for more complex functionality
  • No support for named queries



  • Uses Spring Data JPA jar (contains incompatable jar with Spring AOP)
  • Spring JPA uses the interfaces to perform the functionality so we don’t need implementation classes
  • Interfaces extend JpaRepository<T, T(id)> and uses @Repository

Java Enterprise Beans Fundamentals

JavaEE Essentials – Enterprise Beans


Session Bean

  • Series of methos encapsulated in a bean
  • Stores only local data
  • Used to execute main bulk of program
  • Associated with single client session
  • Can execute a single or series of transactions
  • State is managed by the EJB container


  • Runs i a client bean session
  • Associated with a client state


  • Any client can invoke the methods
  • Can keep state that lasts for the duration of the invocation


  • Once per application
  • Keeps state for duration of application execution
  • Bean equivalent of global variables
  • Perform startup and cleanup tasks

Entity Bean

  • Associated with a data set not a session
  • Esentially permanent
  • Uniquely identified by a primary key
  • Don’t necessarily require a client

Message Bean

  • Receives JMS messages asynchronously and acts upon them
  • Does not have a client interface
  • Can only respond to single client message
  • Used to handle special events

Programming on a Server

  • Watch out for latency and rw conflicts


  • Limited communication speed
  • Reduce through workflow balancing

Concurrent access

  • Mutliple requests to shared resources

Session & Entity Objects (Coarse Grained)

  • Interfaces with blocks of data
  • Deals with more complex data

Session objects

  • Created within a specific client session
  • Lasts as long as the client
  • Keeps Conversational State (a connection with one or more clients)
  • Coarse grained

Entity objects

  • Persistent across multiple clients and instantiations
  • Keeps state with a primary key that identifies the bean
  • Client uses key to reconnect to bean if it exists
  • If bean is not available, it can be recreated with the persistent data
  • Coarse grained

Client vs Server side

  • Main difference is program output
    • Server produces data for client
    • Client presents data to user
  • Beans primarily for server programs


  • Work with databases
  • Display pages
  • Validate and handle user input
  • Authentication, verification and monitoring


  • Interface with server
  • Generate dynamic web pages
  • Taking in user input
  • Work with local storage
  • Send/receive requests with server

Bean lifecycle

Stateless Session Bean

Uncreated -> setSessionContext -> Active -> ejbRemove -> Destroyed

Stateful Session Bean

Uncreated -> setSessionContext -> Active -> ejbPassivate -> Passive
ejbCreate ejbActivate <- Passive -> ejbRemove -> Destroyed

Entity Bean

Uncreated -> setEntity -> Pool -> ejbActivate -> Active
Pool <——————— remove

Message Bean

Uncreated -> setSessionContext -> Active -> ejbRemove -> Destroyed
-> onMessage -> OnMessage
Active <—————–


  • Most beans don’t use concurrency since they are only accessible by one client at a time
  • Multiple clients -> multiple beans
  • Databases must also handle paralellism
  • Singleton Session Beans must take parallelism into consideration to handle multiple clients
    • Use @Lock(Write) at methods to protect from writing and writing
    • Use @Lock(Read) at methods to protect from duplicate reading
    • Use @AccessTimeout(value=100) to control timeout for concurrent access
    • Use @ConcurrencyManagement(Bean) for bean control
      • “volatile, synchronized” and other mechanisms can also be used

Exclusive Read Exclusive Write (EREW)

  • One CPU can access a memory location at a given time
  • Other CPU’s will be locked out
  • Safe but slow

Concurrent Read Exclusive Write (CREW)

  • Allows multiple reads
  • Only 1 can write
  • Faster the EREW

Concurrent Read Concurrent Write (CRCW)

  • No restrictions on reading and writing
  • No locking algorithm
  • Very fast but requires careful programming

Maximising performance

  • Minimize computations
  • Minimize length of non-parallizable sections
  • Minimize overhead cpu<->cpu communication
  • Find paralellism possibilities, refactor
  • Load balance to keep processors working at all times
  • Minimize communication overhead



  • Simple
  • Based on user roles and access methods
  • Uses access levels
  • Can map users to more general roles with lots of users
  • On class: @DeclareRoles(values = {“admin,guest”})
  • On method: @RolesAllowed(value = {“admin”}) (@Deny @Allow)


  • Harder
  • More powerful and easy to make mistakes
  • Methods:
    • Invoked in method
    • SessionContext.getCallerPrinciple()
    • SessionContext.isUserInRole()

Asynchronous methods

  • Apply to method or entire class
  • Methods return void or Future result type
  • Use: @Asynchronous annotation
  • Use: AsyncResult to cast result


  • Failures are ok, clients can re-send
  • Much more efficient to allow occasional failures
  • Sometimes necessary to NOT fail or fail in SPECIFIC way
  • Multiple steps trated as single unit of work
  • Use: @TransactionAttribute to mark methods for transactional behaviour
    • required
    • requiresNew
    • mandatory
    • supports
    • notSupported
    • never

Spring Fundamentals

Spring overview

  • Framework to reduce complexity around EJB
  • Allows enterprise development without Application Server
  • POJO based and Interface driven
  • Lightweight and unobtrusive compared to older J2EE methodoligies
  • Uses AOP and Proxies to remove Cross-Cutting Concerns
  • Increases Scalability, Testabiliy and Maintainability
  • Puts focus on the Business
  • Can be seen as a glorified HashMap
  • Can be used as a Registry

Project setup

  • Add libraries to build path
  • Define mappings in applicationContext.xml
  • ApplicationContext can be instantiated in main() using ClassPathXmlApplicationContext()

XML Configuration


  • Can be defined in applicationContext
  • Needs ID or Name
    • Id has to be valid xml identifier
    • Name can contain special chars
  • Default no-args constructor
    • Setter injection uses properties on beans
    • Construction injection uses constructor-arg element
  • Regular class with getters and setters


  • Spring wires beans together instead of mapping in xml
  • Can be wired by:
    • Type: bean of property type must be unique in the container
    • Name: wire by property name
    • Constructor: same as type but for constructors
    • None
  • Can be configured in xml or class


  • Uses component scanner from the context namespace

  • 3 main types of annotations (stereotype annotations)

    • @Service and @Repository extend @Component but do not add features
    • @Component used for components/beans, any POJO
    • @Service, service tier where business logic is contained
    • @Repository, data access tier (dao’s)
  • Can perform Autowiring on member variables, constructor and setters


  • Light weight dependency injection specification for Java
  • Simple annotations
  • Spring offers more features

Java Configuration

  • No need to configure with xml, we can use Java annotations
  • Not all spring releases are fully supported
  • @Configuration annotation replace applicationContext at class level
  • Methods used in conjunction with @Bean are used to get instances of beans

  • No applicationContext.xml needed, we use an app config class instead

  • Beans can be fetched from the context

Setter injection

  • Setter injection is as simple as a method call (mystery of injection goes away)
  • Call the setter

Cosntructor injection

  • Same as setter injection but uses constructor instead
  • Requires constructor in implementation class (CustomerServiceImpl here)


  • Add @ComponentScan annotation on the app config class

  • Just like xml configuration we mark what we want with @AutoWired (byName uses bean name byType uses instance type)

  • Possible to mix configurations with injection and autowired


  • Classes and instances can have different scope
  • Defines with @Scope in java or xml bean attribtue
  • Singleton is default
  • Prototype gives new instance for each request from bean
  • Web scopes (Request, Session, GlobalSession)covered in Spring MVC

Property files

  • Good to keep environmental information out of app
  • Context Namespace has utilities to help load files

XML configuration

Java configuration

  • Use @PropertySource(“”) annotation in AppConfig
  • To use in POJO, bean configuration is needed

  • Much cleaner in xml

Spring MVC fundamentals

Spring MVC

Other framworks

  • Struts
  • Tapestry
  • Wicket
  • GWT
  • JSF
  • Seam
  • Stripes

What is Spring MVC

  • General Web (JSP/REST/Headless/Remoting) framework
  • POJO based and interface driven
  • Based on Dispatcher Servlet / Front Controller pattern


  • DispatcherServlet – Entry point for the application
  • Controller – Command pattern object that handles request and routes to a view
  • RequestMapping – URL and Request Type that method is tied to (GET/PUT/POST…)
  • ViewResolver – Used to locate JSP pages or whatever view we are using
  • Servlet-config – Configuration per DispatcherServlet

Spring MVC Configuration

  • Configure web.xml
  • Configure servlet-config.xml
  • Add Controller
    • Controllers are annotation based using @Controller
    • Controller path is set using annotations @RequestMapping
  • Add View
    • Put views under WEB-INF/jsp/*.jsp and redirect using InternalResourceViewResolver




Controller (@Controller)

  • Routes requests
  • Builds response
  • Handles exceptions
  • Recommended to put request mapping on methods

Service (@Service)

  • Handles actions of a system
  • Service contains business logic
  • Ensures the business object is in valid state
  • Transactions begin here
  • Often same method as Repository but different focus (set default etc.)

Repository (@Repository)

  • Repository accesses data through database
  • Usually mapped 1-1 with db-tables
  • Focuses on persisting and interacting with database (CRUD)

Request/Response lifecycle

  1. Incoming request -> Front Controller -> Delegate Request -> Controller -> Handle Request -> Backend
  2. Backend -> Create Model -> Controller -> Delegate Rendering (Model) -> Front Controller -> Model -> View Template -> Front Controller -> Return Response

Passing params

  • Request[‘params’] -> Controller[‘model’] -> Response
  • Model used for both get/post to database
  • Use @ModelAttribute to send data or retrieve data to/from Controller
  • Use with GET/POST on POJOs


  • Convention to place views in /WEB-INF/jsp/ directory
  • Allows us to completely control all routing, can make site more secure
  • View Resolver uses string returned from controller method
  • Controller can build model and return to View Resolver
  • Many different resolvers for different templating tools and return types
  • Possible to create static view resource mapping to publish images, pdf’s etc.

Tag Libraries

  • Two libs in Spring MVC
  • Can bind to objects from model
  • Can connect to css
  • Can escape data
  • Spring ex.
    • bind
    • escapeBody
    • hasBindErrors
    • htmlEscapt
    • message
    • nestedPath
    • theme
    • transform
    • url
    • eval
  • Spring Form ex.
    • checkbox(es)
    • errors
    • form
    • hidden
    • input
    • label
    • option
    • password
    • select


  • Registered and part of request lifecycle
  • Have ability to pre/post handle web requests before and after controller
  • Callback methods used to override or change values
  • Commonly used for locale changing


  • Constraint validation
    • Expecting data like “firstname”, “password” must not be null and contain some specific data
  • Business logic validation
    • Rather constraints on what values are handled
    • Should be handled i service tier, not controller
  • Form tags have an error class for displaying errors

  • Validator interface

    • ValidationUtils helper class used with simple form controller
    • Implements Validator Interface
    • Requires lots of hands on coding for validation
    • Binds to a BindingResult
    • Can be used in Service tier to do things outside of spring
    • Can use SimpleFormController
    • Limited use and not annotation supported
  • JSR 303 validation

    • Java standard for validation
    • Integrates well with Spring for validation and reporting errors
    • Annotation based and can use custom validation rules
    • Reference implementation is the Hibernate Validator (not same as Hibernate ORM!)
    • POJO based

Application request types

  • Can set up to handle json and xml etc.
  • Configure in servlet xml

  • Dispatcher Servlet needs to be configured to allow different request types

Dynamic localization of JSR 303 validation messages with wildcards

Lets say you have a class like this

And you want to localize the messages in a file, you might do something like this:

Now you have hardcoded the values in multiple places, imagine if you have multiple properties files for different languages, you would define the values everywhere!

Instead you can do this:

And this:

Now, why are we using {2} and {1}?

The attributes are ordered alphabetically! From the board:

For the first option, Spring-managed field error arguments include the actual constraint annotation attributes in alphabetical order now. So for @Size(min=1,max=5), it’ll include the field name as {0} , the max value as {1} , and the min value as {2}

Has caught me many times.