ejb-3.0

问题 The scenario You have developed a webapp using EJBs version 3. The system is deployed, delivered and is used by the customer. If you would have to rewrite the system from scratch, would you use EJBs again? Yes : Don't answer this question, answer this one instead. No : Provide the top reason for not using EJBs again, based on your personal experience. Let the answer contain just one reason. This will let other readers vote up the number one reason to stay away from EJB 3. 回答1: The project did

问题 I have a large non-Java EE, JSF-based web app project. Our system is layered (in the source code sense): there's a data model package, building on that is the DAO package. We are using Hibernate's XML configuration mapping exclusively in the DAO package. We really don't want to muddle the data model with annotations, but aren't wedded to Hibernate specifically (except that the mapping is quite complex). I'm strongly considering making a move towards Java EE and building our DAO objects as

问题 I used EJB3/JPA when persisting my entities and I am happy on how it is able to manage my DB related task. My only concern is on the exception handling. My sample code when saving entity always comes in this flavor. Most of the tutorials that I read on the net comes in this flavor also with no regards to exception handling. @Stateless public class StudentFacade{ @PersistenceContext(unitName = "MyDBPU") private EntityManager em; public void save(Student student) { em.persist(student); } } But

问题 I am using Java EE 5 , EJB 3.0 , Jboss AS 4.3.2 . I have simplest Stateful bean @Local public interface IStateBean { } @Stateful public class StateBean implements IStateBean { private static int number = 0; @PostConstruct void init() { number++; System.out.println("@PostConstruct: " + number); } @PreDestroy void destroy() { number--; System.out.println("@PreDestroy: " + number); } } I do lookup in servlet for this bean public class MyServlet extends HttpServlet { @Override public void doGet

问题 When a (transactional) method of an EJB calls another (transactional) method of another EJB, and an exception is thrown in the second, but catched in the first one, it seems that the transaction is automatically rolled back when the second one returns, even if the first one catches it, is this true? how can I avoid it? The scenario is the following one: @Stateless class ClassA { @EJB ClassB objectB; methodA() { try { objectB.methodB(); } catch(Exception e) { //Here the transaction started in

问题 Which one is better among following(EJB 3 JPA) //Query a). getEntityManager().createQuery ("select o from User o"); //Named Query where findAllUser is defined at Entity level b). getEntityManager().createNamedQuery ("User.findAllUser");** //Native Query c). getEntityManager().createNativeQuery ("SELECT * FROM TBLMUSER "); Please explain me which approach is better in which case?. 回答1: createQuery() It should be used for dynamic query creation. //Example dynamic query StringBuilder builder =

问题 I'm having a problem with the following setup: A Java application send email msg to a JMS queue, then an MDB listening to the queue get the email msg with the onMessage method, it open a connection on the Gmail SMTP, send the email to the SMTP and close the connection. Doing this on all message in the JMS queue. It is working great when I have up to 5 messages in the queue at the same time. All messages are picked-up in the same time by 5 different instances of the MDB, so I have 5 concurrent

问题 Enviornment- wildfly-9.0.2.Final, EJB 3.0 Following error occurred while trying to connect Test.java class(deployed as module at wildfly-9.0.2.Final@machine-A) to EJB whilch is deployed on jboss at machine-B(291.861.301.732). 17:02:46,666 ERROR [stderr] (default task-1) javax.naming.NamingException: WFLYNAM0027: Failed instantiate InitialContextFactory org.jboss.naming.remote.client.InitialContextFactory from classloader ModuleClassLoader for Module "deployment.test.ear.test.war:main" from

问题 I have a question related with possible performance issue while using @EJB annotation. Imagine following scenario public class MyBean1 implements MyBean1Remote{ @EJB private MyBean2Remote myBean2; @EJB private MyBean2Remote myBean3; ... @EJB private MyBean20Remote myBean20; } There is a bean with many dependencies to other beans. According to EJB spec if I would like to inject MyBean1Remote to some other bean, container would have to take all required dependencies from its pool inject it into

问题 Is there any situation where it's better to use JNDI than to inject a stateless session bean using the @EJB annotation? We're using JSF 1.2 with Sun Application Server 9.0_01. Our team is debating which approach is better when using SLSBs in a Managed Bean. I've read the following questions, but was wondering if there was a situation where lookup is preferred. EJB3 - obtaining bean via injection vs lookup - what are the differences, implications, gotchas? @EJB injection vs lookup -