JavaOne Day Three

Day three ... here's my notes from todays sessions that I attended, more good stuff.

GWT and jMaki: Expending the GWT Universe

  • Why use jMaki
    • Hide compexity of JS / CSS
    • portable library
    • standarized event / data model: JSON
    • easy integration of 3rd party tech
    • encourage re-usable JS tech
    • integrates with existing applications
  • jMaki widgets: component.htm, component.css, component.js
  • Hello World widget
  • jMaki events: pub /sub mechanism, declarative events, programmtic events
  • jMaki Application Recipe
  • Demo: (sumltron)
  • jMaki-store on has all the demo code
  • What is GWT
    • Framework for building Ajax apps
    • open source (Apache 2.0)
    • targeted at Java Lang users
    • java src is compiled to browsers compliant JS code
  • Why use GWT
    • brower issues
    • integrated client - server debugging
    • tool of your choice
    • no need to learn another language
    • hides complexity of JS
  • GWT model
    • generate skelaton app
    • set layout
    • add container or components
  • Component configuration
  • Adding a widget
  • Demo: NetBeans with GWT plug-in
  • Marry the best of both worlds
  • jMaki Charting for GWT

Advanced Web Application Security

  • Speakers: Jeremiah Grossman, Whitehat Security; Joe Walker, Sitepen
  • Learn how to keep the bad guys out of your website
  • Web Hacking today
    • Past two years, web sites are lot less secure than we thought
    • over 90% of websites have serious security issues
  • The Attackers, being more organized, not just hacking for fun
    • Who is the target: you, company, others
    • Who is the attacker: troublemakers, theives
    • Who is the victim: data, users, partners
  • Cross Site Request Forgery
    • Cross-Domain Rules: browsers job to enforce cookie usage
    • How to abuse a cookie without reading it
    • sends request to
    • all you need is iframe src to bad url, or img or script
    • cant use XMLHttpRequest because cross-domain rules not allowed
    • are write-only
    • GET and POST can be forged
    • Reffer checking is not a complete fix
    • Not just cookies that get stolen
  • Demo: CSRF:
  • How to protect yourself
    • Force users to logout
    • check referrer headers
    • include authen toketn with every request, cookie is not enough
    • security tokens in GET requests are not a great idea
    • POST means forms with hidden fields: OWASP servlet filter
    • Double-submit cookie pattern (Ajax requests only), read in JS and submit in the body
  • JavaScript hijacking
    • using "script" auto evals the returned script
    • might be able to setup the env to get information from the script
    • JS lets you redefine anything, Object, Getters and Setters, reading data from a script service
    • use JSON properly; wrap data with { ... } anr wrap keys in ''
    • use unpredictable URLs or other authen
    • deny GET requests
  • Cross Site Scripting
    • allow content that could contain scripts from someone untrusted into pages from your domain
    • 3 types:
      1. reflected script embedded in the request is 'relfected' in the response
      2. stored: input is stored and played back in alter page
      3. DOM: script injected into document
    • scenario: let the user enter their name
    • make user input safe
      • need to filter lots of things
      • could put scripts in css files
      • browsers try to understand anything
      • flash, svg, .htc XML
    • web developers get lazy ... browsers make it look good, they get lazier
  • Demo: XSS
  • How to fix XSS
    • filter input by white-listing input characters, "a-z, A-Z",etc
    • filter outputs for display environment
      • well formed HTML
      • validate as HTML and throw away
      • take extra care over attributes
    • use AntiSamy
    • hacking RSS Readers
    • RSS feeds -- aggregator generally change the domain -- browser
    • Hacking RSS and Atom Feed Implementations
    • restrict input as much as possible, whenever possible
    • ensure output encoding is correct
  • Combination attacks
    • small holes multiple
    • web worms
      • grow faster than email worms
      • XHR/Flash/Quicktime
      • users can attack their 'friends' with scripts
  • Demo: web worm

Using DTrace with Java apps: bridging the observability

  • How to use dtrace in java
  • Introduction to DTrace
    • available in Jan 2005
    • dynamic instrumentation of the whole software system - top to bottom
    • use in production; safe, zero disabled overhead, minimal enabled overhead
    • powerful interpreted language
    • Probes: place of interest in the system where we can make observations
    • Aggregations: patterns are more interesting than individual datum, look for trends
    • jstack() Action: prints mix mode stack trace
    • Demo: dtrace
  • DVM provider
    • project to add DTrace support
    • download shared libs
    • lots of new probes, alloc, methods, time spent
    • Demo:
  • hotspot provider
    • Dtrace in JDK 6 "out of the box"
    • implements all dvm probes plus extensions
    • JNI method probes: entry/return points
    • certain probes are expensive, some off by default
    • Demo: space invader game
  • Visualization and project DAVE
    • Dtrace Advanced Visualization Environment
    • uses D script and method probes
  • JSDT
    • Java Env Statically Defined Tracing
    • Java SE 7
    • com.sun.tracing.\*;
    • @ProviderName() @ProbeName()
    • public interace MyProvder implements Provider {}

JSF 2.0: Insight and Opinion

  • Where is JSF today:
    • latest 1.2 maint release 1
    • Glassfish v2
    • Apache MyFaces 1.2.2 / Tomcat 6.0
    • Component Libraries
    • JSF is everywhere
    • Every app server, except Geronimo, use Sun impl
    • What should be in Java EE 6 Web Profile ... JSF 2.0 and Web Beans (the web profile debate)
  • Where are we going:
    • JSF 1.0, 1.1 planted the seed; lots of opinions, tool support limited
    • JSF 1.2, mostly planting, some harvesting; fixed JSP, little easier, more opinions
    • How we listened; mostly harvesting, tool vendors are building on JSF
    • Keep current on web trends; Rails (focus on CRUD), Rich Internet Apps
    • JSF still lives in the "Desktop" space: ServerSide UI Framework
    • Top Five Goals
      • Components easier to deploy
      • Ajax support
      • Page Description Lang
      • Reduce config burden
      • Compat between component libs with vendors
    • Other Goals
      • state mgmt redo
      • bookmark urls (evetything is now a PORT)
      • zero deploy
      • tree traversal
      • scopes
      • better error reporting
  • What are we doing:
    • Easier to develop components: repackage as a single config, support locales, versions.
    • Facelets now core part of JSF
    • Template based Renderers and events from JSFTemplating
    • Should new components be added, maybe a component compat kit
    • Partial Tree Traversal
    • Partial PAge Update
  • Demo

Design Patterns Reconsidered

  • What is a Design Pattern: describe a problem that occurs over and over again. Don't do the same thing twice
  • Gang Of Four, Design Patterns
  • Creation, Structural, Behavioral
  • Patterns Backlash:
    • copy/paste, design by template, cookbook, stops people from thinking
    • Aren't patterns, workaround to lang missing features
    • Overuse; do a pattern just because it's there
  • Practical Patterns: a vocabulary, expose real issues, compare design choices
  • Singleton:
    • there can be only one
    • hard to know what they are really doing
    • hidden coupling
    • testing issues
    • Just one? it's a lie
    • possible memory leak
    • dependancy issues
    • Use interface and implementation
    • Control by configuration not by pattern
  • Template Method:
    • Pluggable Algorithm
    • usually abstracted methods
    • fighting over your inheritance
    • poorly documents intent to framework user
    • hard to maintain and evolve
    • use composition, context classes to expose state
    • Can closures help?
    • prefer composition to inheritance; easier to maintain, understand
  • Proxy
  • Vistor
    • operations over a composite heirarchy
    • tree / node example
    • one generic method which takes a "visitor"
    • define new visitors as needed
    • "The Expresion Problem"
      • add new cases to a data type
      • add new functions over data type
      • don't recompile when adding
      • don't lose static type safety
    • Where does navigation code live:
      • In node: limited to one navigaton strategy
      • In navigation node:
    • Common visitor types
      • Collector
      • Finder
      • Event:
      • Transform: modify the tree
      • Validation: verify structure
    • Problem: need to return a value, option: use Generics
    • Exception handling, store it in the visitor, generics
    • Can closures help
    • Learned: expression problem hard to solve. ngenerics add precision
  • Principles:
    • use interfaces and dependency injection
    • favor compostion over inheritance
    • leverage static typing and generics


Post a Comment:
Comments are closed for this entry.

Scott Fehrman


« July 2016

No bookmarks in folder


No bookmarks in folder

Ref. Material

No bookmarks in folder