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

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