Skip to main content

Home/ SoftwareEngineering/ Group items tagged Class<T>

Rss Feed Group items tagged

Filter: All | Bookmarks | Topics Simple Middle
kuni katsuya

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

musingsofaprogrammingaddict.blogspot.ca/...uilder-pattern-using-bean.html

database jpa EntityBeans BuilderPattern BeanValidation

shared by kuni katsuya on 03 Oct 12 - No Cached
  • 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&lt;T&gt;
  • 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&lt;Customer&gt;
  • @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

Fetching Client IP Address and Header information in JBoss AS7 access log « J... - 0 views

middlewaremagic.com/jboss

jbossas7 AccessLog

shared by kuni katsuya on 11 Oct 12 - No Cached
  • Fetching Client IP Address and Header information in JBoss AS7 access log
  • “org.apache.catalina.valves.AccessLogValve”
  • More informations about this Valve can be found in the following link: http://tomcat.apache.org/tomcat-5.5-doc/config/valve.html#Access_Log_Valve
  • ...10 more annotations...
  • Some of the useful patterns
  • %h - Remote host name (or IP address if resolveHosts is false)
  • %a - Remote IP address
  • %u - Remote user that was authenticated (if any), else '-'
  • %r - First line of the request (method and request URI)
  • %s - HTTP status code of the response
  • %b - Bytes sent, excluding HTTP headers, or '-' if zero
  • %S - User session ID
  • %t - Date and time, in Common Log Format
  • %m - Request method (GET, POST, etc.)
  • kuni katsuya on 11 Oct 12
     
    "/subsystem=web/virtual-server=default-host/access-log=configuration:add(pattern="%h %l %u %t "%r" %s %b %{User-Agent}i %{JSESSIONID}c")"
kuni katsuya

Remote call using class as parameter - Google Groups - 0 views

groups.google.com/forum

graniteds remoting DTO ValueObject Method parameter wrapper Java ActionScript3 Class

shared by kuni katsuya on 16 Sep 12 - No Cached
  • public class ClassHolderDTO&lt;T&gt; {&nbsp; &nbsp; private Class&lt;T&gt; classToTransfer;// get/set boilerplate}
  • Resource
  • Class&lt;Resource&gt; entityClass
  • ...18 more annotations...
  • Class as parameter
  • serverside
  • Remote call using class as parameter
  • Does GraniteDS could manage date and TimeZone ?
  • Flash Player (GMT +X) -&gt; IExternizable methods (GMT + X - X = GMT + 0) - &gt; AMF over HTTP (GMT + 0) -&gt; Granite AMF0Deserializer (GMT + 0) -&gt; Granite Converter (GMT + 0 + Y = GMT + Y) -&gt; Java Services (GMT + Y)Java Services (GMT + Y) -&gt; Granite Converter (GMT + Y - Y = GMT + 0) -&gt; Granite AMF0Deserializer (GMT + 0) -&gt; AMF over HTTP (GMT + 0) -&gt; IExternizable methods (GMT + 0 + X = GMT + X) -&gt; Flash Player (GMT + X)
  • We use
  • GMT + 0
  • for AMF for convention
  • define a
  • fixed timezone
  • for your AMF that is over HTTP
  • GMT + X
  • : timezone for your flex client
  • GMT + Y
  • : timezone for your server
  • don't want to modify the default templates
  • override the readExternal / writeExternal methods and do the conversion here.
  • The patch is to use a custom template for generating your as files with a conversion to GMT 0 in the implementations of IExternalizable methods.On the server-side you add a Converter to convert dates GMT 0 to dates GMT + Y.
    • kuni katsuya
      kuni katsuya on 16 Sep 12
       
      see better suggestion below (ie. override instead of replace)
kuni katsuya

5. Exception Handling - Confluence - 0 views

www.graniteds.org/...5.+Exception+Handling

graniteds ExceptionHandling javaee6 Flex ActionScript actionscript3

shared by kuni katsuya on 13 Sep 12 - No Cached
  • Exception Handling
  • 5. Exception Handling
  • server exceptions
  • ...41 more annotations...
  • can be handled on the
  • client-side
  • by defining a
  • fault callback
  • each remote call
  • very tedious
  • possible to define common handlers for particular fault codes on the client-side, and exception converters on the server-side, to convert server exceptions to common fault codes
  • define an
  • ExceptionConverter
  • class
  • Converter
  • ExceptionConverter
  • accepts(Throwable t, Throwable finalException)
  • convert( Throwable t, String detail, Map&lt;String, Object&gt; extendedData)
  • t.getMessage(), detail, t
    • kuni katsuya
      kuni katsuya on 13 Sep 12
       
      * instead of *wrapping* the server-side exception and rethrowing it to the client, ** extract only details relevant to the client (eg. include: human-friendly error message and any helpful parametrized data, exclude: stack traces), ** "wrap" it in a generic ServiceException, which gets "thrown" remotely to the client * client can check ServiceException.getCode() to implement behavior tailored to server-side exception 'type'
  • ENTITY_NOT_FOUND
    • kuni katsuya
      kuni katsuya on 13 Sep 12
       
      ENTITY_NOT_FOUND - 'fault code' understood by client
  • This class will
  • intercept
  • all EntityNotFound exceptions on the server-side, and convert it to a proper ENTITY_NOT_FOUND fault event.
  • exception converter has to be
  • declared on the GDS server config :
  • scan="true" in granite-config.xml
  • META-INF/granite-config.properties
  • in the jar containing the exception converter class
  • granite-config.xml
  • &lt;exception-converters&gt; &lt;exception-converter type="com.package.SomeExceptionConverter"/&gt; &lt;/exception-converters&gt;
  • Flex side
  • Handler
  • Handler
  • IExceptionHandler
    • kuni katsuya
      kuni katsuya on 13 Sep 12
       
      **I**ExceptionHandler??? really?  ;)
  • accepts(emsg:ErrorMessage)
  • handle(context:BaseContext, emsg:ErrorMessage)
  • register it as an exception handler for the
  • Tide context
  • in a static initializer block to be sure it is
  • registered before anything else happens.
  • addExceptionHandler(EntityNotFoundExceptionHandler);
  • ExceptionConverter
  • 5. Exception Handling
  • 5. Exception Handling
  • 5. Exception Handling
kuni katsuya

Stephen Colebourne's blog: Javadoc coding standards - 0 views

blog.joda.org/...javadoc-coding-standards.html

java javadoc BestPractices documentation design communication

shared by kuni katsuya on 13 Dec 12 - No Cached
  • Javadoc coding standards
  • explain some of the rationale for some of my choices
  • this is more about the formatting of Javadoc, than the content of Javadoc
  • ...63 more annotations...
  • Each of the guidelines below consists of a short description of the rule and an explanation
  • Write Javadoc to be read as source code
  • Making Javadoc readable as source code
  • Public and protected
  • All public and protected methods should be fully defined with Javadoc
  • Package and private methods do not have to be, but may
  • benefit from it.
    • kuni katsuya
      kuni katsuya on 13 Dec 12
       
      think of it as internal design documentation when you revisit this code 8 months from now: - based on nothing but your well-chosen ;) package/class/method/variable names, will you recall all of your current design intentions and rationale? likely not - when you hand-off this code to another software engineer, how easy will it be to mostly rtfm? will you have to waste time preparing design/implementation notes specifically for the hand-off? if this is the case because the code is unreadable and not self-guiding and there's not already at least high level design notes in a wiki, you're doing it wrong!
  • If a method is overridden in a subclass, Javadoc should only be present if it says something distinct to the original definition of the method
    • kuni katsuya
      kuni katsuya on 13 Dec 12
       
      ie. don't just copy-paste the javadoc from the superclass. that's mindless and pointless monkey work
  • Use the standard style for the Javadoc comment
  • Do not use '**/' at the end of the Javadoc
  • Use simple HTML tags, not valid XHTML
  • XHTML adds many extra tags that make the Javadoc harder to read as source code
  • Use a single &lt;p&gt; tag between paragraphs
  • Place a single &lt;p&gt; tag on the blank line between paragraphs:
    • kuni katsuya
      kuni katsuya on 13 Dec 12
       
      this at least makes the paragraph breaks wysiwygísh and somewhat easier to read
  • Use a single &lt;li&gt; tag for items in a list
  • place a single &lt;li&gt; tag at the start of the line and no closing tag
  • Define a punchy first sentence
  • it has the responsibility of summing up the method or class to readers scanning the class or package
  • the first sentence should be
  • clear and punchy, and generally short
  • use the third person form at the start
  • Avoid the second person form, such as "Get the foo"
  • Use "this" to refer to an instance of the class
  • When referring to an instance of the class being documented, use "this" to reference it.
  • Aim for short single line sentences
  • Wherever possible, make Javadoc sentences fit on a single line
  • favouring between 80 and 120 characters
  • Use @link and @code wisely
  • @link feature creates a visible hyperlink in generated Javadoc to the target
  • @code feature provides a section of fixed-width font, ideal for references to methods and class names
  • Only use @link on the first reference to a specific class or method
  • Use @code for subsequent references.
  • This avoids excessive hyperlinks cluttering up the Javadoc
  • Never use @link in the first sentence
  • Always use @code in the first sentence if necessary
  • Adding a hyperlink in that first sentence makes the higher level documentation more confusing
  • Do not use @code for null, true or false
  • Adding @code for every occurrence is a burden to both the reader and writer of the Javadoc and adds no real value.
  • Use @param, @return and @throws
  • @param entries should be specified in the same order as the parameters
  • @return should be after the @param entries
  • followed by @throws.
  • Use @param for generics
  • correct approach is an @param tag with the parameter name of &lt;T&gt; where T is the type parameter name.
  • Use one blank line before @param
  • This aids readability in source code.
  • Treat @param and @return as a phrase
  • They should start with a lower case letter, typically using the word "the". They should not end with a dot. This aids readability in source code and when generated.
  • treated as phrases rather than complete sentences
  • Treat @throws as an if clause
  • phrase describing the condition
  • Define null-handling for all parameters and return types
    • kuni katsuya
      kuni katsuya on 13 Dec 12
       
      ideally, if the method in question has any specified/required pre and/or post conditions, they should be noted in the javadoc, not *just* null handling also, there are cleaner ways to design around this type of old school null handling hackage
  • methods should define their null-tolerance in the @param or @return
  • standard forms expressing this
  • "not null"
  • "may be null"
  • "null treated as xxx"
    • kuni katsuya
      kuni katsuya on 13 Dec 12
       
      DO NOT DO THIS this is just bad design
  • "null returns xxx"
    • kuni katsuya
      kuni katsuya on 13 Dec 12
       
      this might also stink of poor design ymmv
  • In general the behaviour of the passed in null should be defined
  • Specifications require implementation notes
  • Avoid @author
  • source control system is in a much better position to record authors
  • This wastes everyone's time and decreases the overall value of the documentation. When you have nothing useful to say, say nothing!
    • kuni katsuya
      kuni katsuya on 13 Dec 12
       
      likewise with javadoc on things like default constructors /**  * Creates an instance of SomeClass  */ public SomeClass() {} is equally useless and unnecessarily clutters up the source code
1 - 5 of 5
Showing 20▼ items per page