Coding mystery!

Example daily rolling file appender Log4j2 configuration using YAML

2015-10-15T06:50:00.001-07:00

Log4j 2 can be configured using XML, JSON and YAML files. Despite YAML being the most readable format of all these, there are not many documentation available on configuring log4j2 using YAML.

The following is an example configuration, if you're interested in using YAML.

Configuration:
  status: warn

  Properties:
    Property:
      name: logPath
      value: /app/logs

  Appenders:
    Console:
      name: Console
      target: SYSTEM_OUT
      ThresholdFilter:
        level: info
      PatternLayout:
        Pattern: '%d{yyyy-MM-dd HH:mm:ss.SSS} [%t] [%-5level] %c{1} - %msg%n'
    RollingFile:
      name: File
      fileName: ${logPath}/app.log
      filePattern: ${logPath}/app-%d{yy-MM-dd}.log.gz
      PatternLayout:
        Pattern: '%d{yyyy-MM-dd HH:mm:ss.SSS} [%t] [%-5level] %c{1} - %msg%n'
      TimeBasedTriggeringPolicy:
        interval: 1
        modulate: true  Loggers:
    Root:
      level: info
      AppenderRef:
        - ref: Console
        - ref: File
    Logger:
      name: com.mylogger
      level: info

Preventing IntelliJ/Eclipse from formatting a block of code

2015-04-24T23:11:00.000-07:00

IntelliJ has extensively configurable code style settings, which can be adopted for pretty much for any project team. However, once in a while we need to have explicit control of formatting for a few lines of code to make them more readable.

For instance, the following code snippet for configuring Spring Security is better formatted manually (taken from Spring boot documentation).

    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http
            .authorizeRequests()
                .antMatchers("/", "/home").permitAll()
                .anyRequest().authenticated()
                .and()
            .formLogin()
                .loginPage("/login")
                .permitAll()
                .and()
            .logout()
                .permitAll();
    }

However, when we invoke "Reformat code" in IntelliJ, it'll align all the chained calls at the same indentation line.

This can be prevented by using formatter marker feature of IntelliJ. For this, first we need to enable this feature in IntelliJ. Go to Settings -> Editor -> Code Style. Select "Enable formatter markers in comments" check box.

Once that is done, the block of code not to be formatted by IntelliJ has to be surrounded by "@formatter:off" & "@formatter:on" text as comments. The above code after this will look as below:

    @Override
    protected void configure(HttpSecurity http) throws Exception {
        // @formatter:off
        http
            .authorizeRequests()
                .antMatchers("/", "/home").permitAll()
                .anyRequest().authenticated()
                .and()
            .formLogin()
                .loginPage("/login")
                .permitAll()
                .and()
            .logout()
                .permitAll();
        // @formatter:on
    }

All code outside this block will still be formatted the usual way.

A few things to keep in mind:
* All developers in the team should have this feature turned on. Otherwise, IntelliJ used by a second developer will mess up the formatting.
* If you use Eclipse IDE, apparently the same can be configured in Eclipse too: http://archive.eclipse.org/eclipse/downloads/drops/R-3.6-201006080911/eclipse-news-part2.html#JavaFormatter

Credit: Found this tip via http://myshittycode.com/2014/08/19/intellij-selectively-disable-line-wrap/.

Adding a whole directory tree to a Crucible review

2013-01-17T21:19:00.000-08:00

Crucible is an excellent tool for code reviews. Ideally code reviews should be done periodically after completing each feature. This is supported nicely by Crucible. All you've to do is select the commits to be reviewed.

However, quite often we need to add all the files in a branch in entirety to a review. This could be because that is the first review & a lot of changes have been committed before the code is in a shape to review. Or an expert from outside the team wants to review the code. Crucible doesn't support any straight forward way to add complete tree hierarchy to a review. The easiest solution to this is to write a EyeQL query & add all the revisions. The query I normally use is

select revisions from dir your/directory where is head and not deleted on branch your_branch

For instance, it could be

select revisions from dir trunk where is head and not deleted on branch trunk

Should all arguments be marked as final in Java?

2012-03-29T06:12:00.001-07:00

Once in a while, someone suggests me to define all method arguments as final in Java. As per this suggestion, the code

public void foo(int bar, MyObject baz) {  
    // do something  
 }

should be changed to

public void foo(final int bar, final MyObject baz) {  
    // do something  
 }

I hear many reasons in favor of this.

Methods that don't modify input arguments are more reliable. This translates to more maintainable & easily testable methods.

Java always passes by value (refer this for details). Hence, if a different value is assigned to the argument variable in the called method body, the variable in the caller method will still point to the same old value/object. If an argument is not defined as final, a different object/value can be assigned. However, this will not affect the caller in anyway.

In addition to that, even if a variable is defined as final, the fields of that object can still be modified. So, the question of a method modifying the input arguments can't be prevented by defining the argument as final. Hence, this will not make a method more reliable.

A method can be made reliable by making the arguments immutable. Defining the arguments final has nothing to do with that.

Changing the value of argument will make the code harder to read.

Actually, I believe multiple assignments to any variable, not just arguments, can make the code difficult to read. Still, I do that very often for assigning a default value, if an argument or a variable, retrieved from another method, is null. Otherwise, I've to define a new variable for the same purpose and copy the argument value conditionally to the new variable. This doesn't appeal to me very much. Of course, I very rarely change the argument/variable in other cases. If the argument is multiple assignments, then the suggestion should be to define all local variables as final. However, we'll need static code analyzers to warn if a developer didn't declare a variable as final. I believe writing a new rule for checking multiple assignments by static code analyzers shouldn't be very difficult. Then why to clutter the code with no advantage?

PMD rule set mandates this

PMD rule set categorized this under Java optimization. Actually, Java compiler will remove the final keyword for argument & local variables. Hence, there is no way JVM can optimize a final variable access.

In interface definition, final keyword is used to specify the variable is not changed

This is a very good idea; only problem is it is broken. As explained earlier, Java doesn't make the argument immutable on declaring it as final. So, it is up to the developers to make sure they don't change the fields of the arguments.

If an argument, whose value is changed in a method, has to be accessed from an anonymous inner class, will you define that argument final? Then you're breaking this convention. Or will you define another final local variable for that purpose? Ugh... Ugly.

Conclusion: IMO, there is no advantage in defining all arguments as final. To me, it looks like adding syntactic noise to an already very noisy language. Please stop doing that.

Lazy loading of properties using Hibernate/JPA

2011-02-26T13:09:00.000-08:00

If a persisted object has heavy properties like Blobs, we may want to load them only when needed. This can be achieved in many ways in hibernate.

Use projection in criteria query or HQL to fetch only the required columns. (http://docs.jboss.org/hibernate/core/3.3/reference/en/html/querycriteria.html#querycriteria-projection & http://docs.jboss.org/hibernate/core/3.3/reference/en/html/queryhql.html#queryhql-select)
Pros: Very easy to implement. Different code can fetch different set of fields.
Cons: Values will be returned as Object[], not as our persistent object.
Use lazy loading of properties. This requires instrumenting the byte codes during build time. (More info @http://docs.jboss.org/hibernate/core/3.5/reference/en/html/performance.html#performance-fetching-lazyproperties)
Pros: Most natural solution from OOP point of view.
Cons: Change in building procedure.
Trick hibernate to think your class is instrumented & implement your own lazy loading. More info @http://justonjava.blogspot.com/2010/09/lazy-one-to-one-and-one-to-many.html
Pros: Build procedure doesn't have to change. Still we're dealing with objects.
Cons: Using internals of a third-party library has its own disadvantages like future incompatibilities, vendor lock-in.
Use runtime byte code instrumentation by defining hibernate.ejb.use_class_enhancer to true. (Refer http://justonjava.blogspot.com/2010/09/lazy-one-to-one-and-one-to-many.html)
Extract the blob property as an independent entity & refer to that using one-to-many from PrimitiveRequest (More info @http://community.jboss.org/wiki/Someexplanationsonlazyloadingone-to-one)
Define a new entity class, which is mapped to the same table & has only relevant properties defined.
Pros: Different pieces of code can fetch different objects. Each object can have its own domain logic.
Cons: Could be confusing. No single object may have all the required domain logic. Possibility of code duplication related to domain logic.

Iteration demo guidelines

2010-07-23T20:50:00.000-07:00

Iteration demos are really important in many of the agile methodologies like Scrum & XP. This post is an introduction, in my understanding, on what to demo & how to demo features during iteration demos. I'm writing this to communicate the best practices I want my team to follow. There may be a few things that won't be applicable to other teams depending upon who their customer is.

What is iteration demo

Iteration demo is meant for

Demonstrating requirements that were implemented in that iteration
Getting feedback from customer on how to improve that behavior
Giving enough information to testers so that they can write test spec for that feature & test it in next iteration
Giving high level idea on how further developments related to a functionality will shape up & discuss that with customer

Iteration demo is NOT meant for

Testing the newly implemented feature
Demonstrating/explaining technical level task (task of a story) to customer. For instance, performance improvement activities like caching implementation, index creation, etc. Demos should be on features/requirements that end user/customer can see/experience.
Code review sessions & scrutinizing if a developer has done what he/she claims to have done
Development demos. For instance, a major refactoring or a new utility that could be useful to other developers can be demoed in a developers only meeting. This will avoid wasting time of non-developers like customer & testers.
Design discussions. Though this can be brought up, it has to be followed up in a seperate meeting.

What to show in iteration demos

Iteration demos should concentrate on things customer will see/experience. Only if no customer facing interfaces are available to demonstrate a feature, other means can be used. The following are the standard interfaces used in demos.

GUI
Web services (preferably using SoapUI)
Logging
Database (used as the last choice)

Note: If the product is exposing API for some developers to use (say a library), code utilizing that API can be used. Client code or test cases should not be used if the product is going to be used by non-developers.

Best practices

Only features/requirements that were completed end-to-end should be Demonstrated. Otherwise, it'll be more of a technical demo.
Demonstrate only the features that were already checked-in to version control. This will avoid confusion to customer & testers if that feature is available & can be tested with that iteration build or not.
Preferably all developers should demonstrate features using a single installation of iteration build. Demonstrating using developer builds should be avoided. This will ensure that uncommitted check-ins are not used. This way developer can continue with the next activity without worrying about breaking the feature temporarily in his/her working copy.

GMail aliases

2005-06-27T03:07:00.000-07:00

Gmail offers users a feature similar to account aliases. Messages sent to 'username+alias@gmail.com.' are delivered to 'username@gmail.com.' For example, messages sent to 'GoogleAmy+notes@gmail.com' are delivered to 'GoogleAmy@gmail.com.'

You can set up filters to automatically direct these messages to 'Trash,' apply a label or star, skip the inbox, or forward to another email account.

Taken from
GMail Help center
(via Kiruba comments section)

Introduction

2005-06-27T03:04:00.000-07:00

I'm basically a Java/J2EE guy with considerable persistence/database exposure. Currently working in a DSL project following XP development methodology. So, chances are more that my posting will also revolve around these areas.

I'm creating this blog to share interesting technical stuff that I come across over net or at my work with everybody.

Hope I'll do enough reading to keep this blog alive!