ejb-3.1

I'm trying to use the Timer Service in EJB 3.1 in my app. @Stateless @LocalBean public class StatelessTimerSessionBean { @Schedule(minute = "*", second = "0", dayOfMonth = "*", month = "*", year = "*", hour = "9-17", dayOfWeek = "Mon-Fri") public void myTimer() { System.out.println("Timer event: " + new Date()); } } ".. set the EJB Timer Service’s Timer DataSource setting to a valid JDBC resource.." from EJB Timer Service I cannot figure out how to configure the Timer Datasource correctly? The error I get when deploying is: SEVERE: Exception while invoking class org.glassfish.ejb.startup

I'm currently learning the new Java EE 6 component models and am confused with the latest dependency injection mechanism. So here are my questions: 1) What is the difference between @Inject and @EJB 2) If I have a simple POJO that contains another POJOs (which one of them is the DAO code), what would be the better choice: @Inject or @EJB? Can I mix @Inject and @EJB? An example would be: ClassA implements InterfaceA and has an instance of ClassA_Adaptor ClassA_Adaptor implements InterfaceAB and has an instance of ClassB ClassB implements InterfaceB and has an instance of ClassB_Adaptor and an

I'm currently creating an EJB3 Data Access Class to handle all database operations in my Java EE 6-application. Now, since Java EE 6 provides the new ApplicationScoped annotation, I wonder what state my EJB should have, or if it should be stateless. Would it be better to let the DAO be a @Stateless Session Bean, or an @ApplicationScoped Bean? What about @Singleton ? What are the differences between these options related to a DAO? EDIT: I'm using Glassfish 3.0.1 with the full Java EE 6 platform Whould it be better to let the DAO be a @Stateless Session Bean, or an @ApplicationScoped Bean? What

I am trying to inject EJB into Spring (3.1.2) service (both in different WARs) Both are very simple (methods removed to simplify example): EJB: @Remote public interface MyBean { } @Singleton public class MyBeanImpl implements MyBean{ } Service: @Service public class MyServiceImpl implements MyService{ } At first sight thing is very simple, but I tried: @EJB(lookup = "java:global/ejbApp/MyBeanImpl!com.my.MyBean") private MyBean myBean; and it didin't work. Then I also tried: @EJB(mappedName = "java:global/ejbApp/MyBeanImpl!com.my.MyBean") private MyBean myBean; And @Resource(mappedName = "java

I have a method annotated with @Schedule that is called by the container once in a while. @Schedule(second = "*/5", minute = "*", hour = "*", persistent = false) public void myTimerMethod() throws Exception { ... } Problem is on certain conditions i want to this method to throw an exception to cause the ongoing transaction to rollback. But if I do this more than two times the timer will be expunged and not called any more! INFO: EJB5119:Expunging timer ['68@@1359143163781@@server@@domain1' 'TimedObject = MyBean' 'Application = My-War' 'BEING_DELIVERED' 'PERIODIC' 'Container ID =

Is it possible to inject a request-scoped CDI bean into a Stateless session bean? I had asked a related question and thought the specific CDI @RequestScoped into @Stateless question merited its own post. Passing state between EJB methods / @RequestScoped and @Stateless I also asked a similar question about JMS @MessageDriven beans - basically want to know the same about @Stateless. @RequestScoped CDI injection into @MessageDriven bean You can absolutely do what you mention and use @RequestScoped beans in an @Stateless session bean and an @MessageDriven bean. This is a core part of the CDI spec

I want to write a back-ground job (EJB 3.1), which executes every minute. For this I use the following annotation: @Schedule(minute = "*/1", hour = "*") which is working fine. However, sometimes the job may take more than one minute. In this case, the timer is still fired, causing threading-issues. Is it somehow possible, to terminate the scheduler if the current execution is not completed? Arjan Tijms If only 1 timer may ever be active at the same time, there are a couple of solutions. First of all the @Timer should probably be present on an @Singleton . In a Singleton methods are by default