skip to main |
skip to sidebar
HelpEclipse IDE Navigation- Alt-right-/Alt-left - last history location
- Alt-Sh-Q Java Menu
- P Package Explorer
- Alt-Sh-X Run Menu
- T Run As Unit Test
- F12 - Active Editor
- Ctl-F6 List of editors
- Sh-Ctl-F6 Go backwards in the list
- Ctl-E List of open editors, then regex search
- Alt-F # Will bring up the File Menu and then choose the file by number.
Java Perspective Navigation
- F3 Open Declaration
- F4 Type Hierarchy
- Clt-F3 Open Structure of active File
Searching/ReplacingEditor Movement/Navigation- Ctl-Home - Top of document
- Ctl-End - Bottom of document
- Ctl-right/left - Go to next word
- Sh-Ctl-down/up - Go to next method
- Clt-q last edit location
- Alt-up/down Move line up/down
- Clt-L - Go to line
- Alt-left/right navigate in the editor history
Deleting/Cutting/Copying- Clt-D Delete line
- Sh-Ctl up/down copy line up/down
Selecting- Ctl-a - select all
- Sh-left/right - Select with movement
- Sh-Ctl-left/right - Select Word
- Sh-End - End of Line
- Sh-Home - Beginning of Line
- Alt-Sh-Up/Down/left/right - select/de-select Enclosing element
JavaDoc- F2 - show tool tips in line
- Sh-F2 - Show in Browser, must have javadoc path set in project, else nothing will happen
- Alt-Sh-Q J Show JavaDoc View
Per standard EJB design patterns, a SSB should never have any business logic in its methods, all business logic should be delegated to a POJO provider. A POJO provider can be injected using Spring's AbstractStatelessSessionBean. Here is example code:
[import org.spring.*
public class BusinessSSB extends AbstractStatelessSessionBean implements BusinessInterface {
private BusinessInterface provider;
public void businessMethodOne() {
provider.businessMethod1();
}
// other business methods here...
protected void onEjbCreate() throws CreateException {
provider = (BusinessInterface) createProvider("BusinessProvider");
}
protected Object createProvider(String componentName) {
Object o = getBeanFactory().getBean(componentName);
return o;
}
}
Good to know when someone says we need to use SSB's for performance reasons.
--------------------------------------
From the book "J2EE without EJB" . This blog has a good summary.
http://forum.springframework.org/archive/index.php/t-23787.html
From the above post:
Rod Johnson 04-07-2006, 05:35 AM
I'm just wondering if there might be a performance benefit with the instance pooling provided with a stateless ejb implementation, vs. having a singleton object. Any insight there?
Ok, I can't resist.
The benchmarks published in J2EE without EJB were the result of prolonged load testing against the leading commercial and open source app servers, on production-quality hardware. The results showed that
- Singleton with Spring-managed transactions dramatically outperformed local or co-located remote EJBs in the open source application server (by 1.5 to 3x, even when many calls resulted in database hits), and consistently (but marginally) outperformed SLSBs in the commercial application server.
- Average response time was distinctly better with the Spring-managed singleton
- The spread in response times was much narrower in the Spring-managed singleton approach (good).
Pooling is greatly overrated for SLSBs. It is actually a flaw in the EJB spec (all versions) that pooling is effectively required, even for local EJBs, when thread pooling can be performed by the web container. Most stateless objects are naturally threadsafe. Thus they gain nothing from pooling.
There is no way in which a pool can outperform a shared instance if there is no need for synchronization on the shared instance.
