6th Airhacks Q & A

6thAirhacksQ&A.md

1. What do you think about play framework as compared to JavaEE ? I often heard that JavaEE is heavyweight in development and therefore internet-startups uses other framework stacks like play, rails, meteor etc
2. What would be the proper approach to read a network file in a J2E environment?
3. "Open Extended Persistence Context In View" - a new pattern?
4. ID generation in a cluster.
5. State computation (daily limits) and scalability vs. consistency.
6. Is JSF compatible with Bootstrap?
7. The JSP / HTML 5 drama: The Return Of JSPs in HTML 5
8. "How are you going to structure your application if application is going to be really huge. Are you still going to keep it in one big war?" blog comment by Thomas
9. Commercial vs. free tools: gist discussion
10. Is "Mixing storage/transfer concerns is an antipattern"? Rafael Chaves, @abstratt
11. Broken EJB proxies? Brad Davies, @bradsdavis

Hi Adam,

I also have a question which needs to be discussed in every project again:
What is the best approach to calculate unique IDs in a cluster. Database sequences are the easiest and common option, but something like a clustered Singleton would be also nice. I think Clustered Singletons were introduced by JBoss, but were not a part of JavaEE spec. What's your recommendation?

Hi Adam,
In some financial application we need to check limit of customer like day limit in which system check whether customer crossed his daily limit or not in terms of number of transactions/day , total amount per/day . Limit may be weekly, monthly or In some application there may be situation where we have to check limit within 2 year.
We have 2 solutions for this problem

1. Calculate limit every time when user initiate transaction .This is slow process if we have to check limit for years.Here we can use cache[ JPA Second level ] to speed up.
2. Make a limit table along with limit columns like daily_no_of_txn,weekly_total_amount and so on . When transaction is completed update the counter of related column.This approached is much faster when validating limit since we just need one select statement.

So in your view which approach is good and why ? How java EE 7 make it simple ?

Hi Adam,
Good developer always use good diagnostic tools in order to fix bugs more easily, but most of them are with price tag. What free diagnostic tools will you recommend, for the following areas:

• Hot redeployment (JRebel is best, but licence)
• Sql query generation from JPA/Hibernate or some other ORM with some statistics like objects created in memory, display the areas from where data are fetch (1 level, 2 level cache) etc.
  Thanks

@GjorgjiJosifov Everyone loves free, esp. a manager, but if an organization is professional they shouldn't balk at purchasing tools that will help their employees deliver higher quality code faster then the available free tools. You wouldn't expect the car mechanics at your car dealer to buy their own tools would you? Great example is Intellij IDEA. It costs a couple of hundred bucks (drop in the bucket compared to ones salary and other expenses an organization has) and its so much better then a free alternative like Eclipse its easy to make a ROI case for it. And FWIW I don't work for a tools company :) Cheers.

Currently in EJB 3.1, the EJB Delegate / Proxy layer is only hit through the client view of the EJB. This means, once you have transversed the proxy and are in the bean, all local calls to the bean do not execute through the proxy. The result is that even though you have put settings on the method level, they are ignored by internal calls. I say this is bad form, because it ignores what could be very important context about how you intend the functionality to work. It also means that in order to get these examples to work properly, you either have to hack around the issue, or break the methods out into their own beans, which in itself could lead to other problems like circular dependency, etc.

I think the issue is that the EJB proxy layer simply passes through all calls to the delegate. But, I think it would have been better if the proxy would have overridden the methods of the delegate, and then applied appropriate semantics upon method execution (such as checking TX scope or Sync / Async behavior).

An example of the issue:

@LocalBean
public class ExampleBean {
  @TransactionAttribute(value = TransactionAttributeType.NEVER)
  public void exampleNoTX() {
     //example
  }
  @TransactionAttribute(value = TransactionAttributeType.REQUIRED)
  public void exampleRequired() {
    //should but does not throw an exception in an EJB context
    exampleNoTx();
  }

  public void exampleSync() {
     //should be non blocking within an EJB context, but is not.
     exampleAsync();
  }

  @Asynchronous
  public void exampleAsync() {
     Thread.sleep(10000);
  }
}

Functionally, I think this is how the proxy should work in an EJB context. In this case, the fact that sayHello() was called from talk() still executes the functionality of ExampleBean.sayHello, but when you are leveraging the proxy bean, because the methods are overridden, the semantics of the EJB method could be checked within the proxy, and applied before calling the super (EJB Bean) method functionality.

package com.bradsdavis;

public class ExampleBean {
    public void sayHello() {
        System.out.println("Hello Brad!");
    }
    public void talk() {
        sayHello();
    }   
}

package com.bradsdavis;

public class ProxyExampleBean extends ExampleBean {
    @Override
    public void sayHello() {
        System.out.println("Applying EJB method level symantics of sayHello...");
        super.sayHello();
    }

    @Override
    public void talk() {
        System.out.println("Applying EJB method level symantics of talk...");
        super.talk();
    }
}

package com.bradsdavis;

public class Main {
    public static void main(String[] args) {
        ExampleBean ex = new ProxyExampleBean();
        ex.talk();
    }
}

Make sense?

// example above prints:

Applying EJB method level symantics of talk...
Applying EJB method level symantics of sayHello...
Hello Brad!

Hi Adam,

My opinion on 1.:

All those "rapid" prototyping frameworks fits well in the agile world ... until the Technical Debt raises in unexpected highs and then the project fails while trying to clear this debt within these frameworks.

What aspect do one like to achieve when using those frameworks? They FAKE the customer! They show the customer a set of fancy features in a rapid way and forget completely how the whole system will behave/perform/secure/scale/integrate in production and legacy enterprise environments.

We all are very "rapid" in outdating some technologies, that becoming more and more mature.

But it's all about answering the question: "Do we REALLY know/posses these supposed-to-be-outdated technologies? (Or do we just follow a hype and parroting fashion, because this is easier than reading a JSR spec?)"

So - Are we REALLY deep experts in Java EE, that we can suppose, Java EE is outdated against <replace this with the next hyping framework's name>?

How many productive scenarios are there in the web, where those hyping frameworks fit still well - even when requirements changes, stakeholders tending to do common enterprise architecting or the numbers of users/requests increases dramatically?

Let us all stop fiddling around with the next hype - let us become specialists in plain and mature Java EE technology! It's all there! OOTB!

But yes: to apply it, you have to read the specs!

(...and then: don't let us use java.io.File access in Session Beans anymore, even if it works in some Application Servers (for now)!)

So long...
Robert