- 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
- What would be the proper approach to read a network file in a J2E environment?
- "Open Extended Persistence Context In View" - a new pattern?
- ID generation in a cluster.
- State computation (daily limits) and scalability vs. consistency.
- Is JSF compatible with Bootstrap?
- The JSP / HTML 5 drama: The Return Of JSPs in HTML 5
- "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
- Commercial vs. free tools: gist discussion
- Is "Mixing storage/transfer concerns is an antipattern"? Rafael Chaves, @abstratt
- Broken EJB proxies? Brad Davies, @bradsdavis
-
-
Save AdamBien/8735518ee671d7edb778 to your computer and use it in GitHub Desktop.
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
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.
Make sense?
// example above prints: