Skip to main content

Home/ SoftwareEngineering/ Contents contributed and discussions participated by kuni katsuya

Contents contributed and discussions participated by kuni katsuya

kuni katsuya

HttpServletRequest (Java EE 6 ) - 0 views

  •  
    "getSession(boolean create)"
kuni katsuya

Session Management | Apache Shiro - 0 views

  • available in any application,
  • regardless of container.
  • even if you deploy your application in a Servlet or EJB container, there are still compelling reasons to use Shiro's Session support instead of the container's
  • ...40 more annotations...
  • Easy Custom Session Storage
  • POJO/J2SE based (IoC friendly)
  • Container-Independent Clustering!
  • Heterogeneous Client Access
  • Event Listeners
  • listen to lifecycle events during a session's lifetime
  • Host Address Retention
  • retain the IP address or host name of the host from where the session was initiated
  • Inactivity/Expiration Support
  • can be prolonged via a touch() method to keep them 'alive' if desired
  • Transparent Web Use
  • can use Shiro sessions in existing web applications and you
  • don't need to change any of your existing web cod
  • Can be used for SSO
  • easily stored in any data source
  • can be
  • 'shared'
  • across applications if needed
  • 'poor man's SSO'
  • simple sign-on experience since the shared session can retain authentication state
  • interface-based and implemented with POJOs
  • allows you to easily configure all session components with any JavaBeans-compatible configuration format, like JSON, YAML
  • easily extend
  • customize session management functionality
  • session data can be easily stored in any number of data sources
  • easily clustered using any of the readily-available networked caching products
  • no matter what container you deploy to, your sessions will be clustered the same way
  • No need for container-specific configuration!
  • Shiro sessions can be 'shared' across various client technologies
  • listen for these events and react to them for custom application behavior
  • SecurityUtils.getSubject()
  • currentUser.getSession()
  • If the Subject already has a Session, the boolean argument is ignored and the Session is returned immediately
  • If the Subject does not yet have a Session and the create boolean argument is true,
  • a new session will be created
  • and returned.
  • If the Subject does not yet have a Session and the create boolean argument is false, a new session will not be created and null is returned.
  • Suject.getSession(boolean create)
  • method functions the same way as the
  • HttpServletRequest.getSession(boolean create) method:
    • kuni katsuya
kuni katsuya

WYTIWYR : What You Test Is What You Run « Antonio's Blog - 0 views

  •  
    " Don't mock types you don't own TDD: Only mock types you own Test Smell: Everything is mocked Testing Anti-Patterns: How to Fail With 100% Test Coverage TDD: Only mock types you own Test Smell: Everything is mocked Arquillian"
kuni katsuya

Implementing the Builder Pattern using the Bean Validation API - Musings of a Programmi... - 0 views

  • invariants
  • customer's last name must not be null
  • must be between 3 and 80 characters long
  • ...23 more annotations...
  • @Size(min = 3, max = 80)
  • @NotNull
  • LastName
  • inner class Builder is in charge of creating Customer instances
  • mandatory fields – either primitive (e.g. id) or annotated with @NotNull (e.g. lastName) – are part of the builder's constructor
  • all optional fields setter methods on the builder are provided
  • newly created Customer instance is validated using the Validator#validate() method
  • impossible to retrieve an invalid Customer instance
  • extract the validation routine into a base class:
  • abstract class AbstractBuilder<T>
  • T build() throws ConstraintViolationException
  • protected abstract T buildInternal();
  • private static Validator validator
  • Concrete builder classes have to
  • extend AbstractBuilder
  • must implement the buildInternal() method:
  • Builder extends AbstractBuilder<Customer>
  • @Override protected Customer buildInternal()
  • Implementing the Builder Pattern using the Bean Validation API
  • variation of the Builder design pattern for instantiating objects with multiple optional attributes.
  • this pattern frees you from providing multiple constructors with the different optional attributes as parameters (hard to maintain and hard to read for clients)
  • or providing setter methods for the optional attributes
  • (require objects to be mutable, can leave objects in inconsistent state)
kuni katsuya

A proper way for JPA entities instantiation « Paul Szulc's Blog - 0 views

  • A proper way for JPA entities instantiation
  • creating the entities I would like to focus in this post
  • JPA2.0 entities
  • ...31 more annotations...
  • UserService
  • UserDao
  • FacebookWS
  • User u
  • UserService uses UserDAO and FacebookWS
  • but don’t know how those dependencies are instantiated
  • And you shouldn’t really care, all that is important is that UserService depends on dao and webservice object.
  • BDD template given-when-then) tests are easy to read
  • @Entity
  • public class User
  • calling new User(“someName”,”somePassowrd”, “someOtherName”, “someOtherPassword”) becomes hardly readable and maintainable
  • code duplication
  • Maintaining this code would turn into a nightmare in no time
  • running the code above will throw an exception by the JPA provider,
  • since not-nullable password field was never set.
  • Joshua Blooch gives fine example of builder pattern.
  • Instead of making the desired object directly, the client calls a constructor (or static factory) with all of the required parameters and gets a builder object. Then the client calls setter-like methods on the builder object to set each optional parameter of interest. Finally, the client calls a parameterless build method to generate the object, which is immutable. The builder is a static member class of the class it builds.
  • Coffee
  • public static class Builder
  • Builder(CoffeeType type, int cupSize)
  • Builder withMilk()
  • Coffee build()
  • Coffee(this)
  • private Coffee(Builder builder)
  • Coffee coffee = new Coffee.Builder(CoffeeType.Expresso, 3).withMilk().build();2}
  • especially if most of those parameters are optional.
  • For all entity attributes I create private fields
  • those that are obligatory become parameters for the public constructor
  • parameter-less constructor, I create one, but I give him
  • protected access level
  • protected
« First ‹ Previous 421 - 440 of 1268 Next › Last »
Showing 20 items per page