Develop Reference

Disabling injection of Spring Scheduler

I have some scheduled jobs in my project with #Schedule annotation, but don't want to inject all of them. Do you know how to skip injection of some jobs, or how can I do it in another way?

You could configure the scheduled tasks in a property file. That way, you could add a boolean flag that you inject into any class containing the scheduled task. Then you could check inside your code if the task is enabled and should be executed.
There is detailed code over in question How to conditionally enable or disable scheduled jobs in Spring?.
If you want to decide if a #Scheduled task should be detected and registered at a ScheduledAnnotationBeanPostProcessor, you might want to look into the SchedulingConfigurer:
[It allows] registering scheduled tasks in a programmatic fashion as opposed to
the declarative approach of using the #Scheduled annotation

Controlling timed execution in Spring-based Pojo in Java EE

I'd like to have a Spring-managed bean schedule execution of itself (or some other bean, simple factoring) if certain conditions are met (i.e. checking successul startup etc.)
I'd also like to be able to see and control the timer from within the application, which will be running on a Java EE 5-compliant container.
Not sure how best to do this - I know about the dangers of doing thread management myself in an EE environment.

You could have a base class that is a wrapper to schedule background tasks (could be e.g. an Executor or TimerTask) and be parameterized by the timing intervals or even the task to schedule and you could derive more specific classes specialized on certain tasks.
These you would configure/instantiate via Spring configuration and of course your app could modify these via the properties of the classes/beans.
Concerning thread management, I also had concerns regarding threads since JavaEE specs (I believe specifically EJB specs) disallow it but this perhaps depends on the container. For example in Tomcat which of course is not a fully EE container, I never had issue with my own threads.
You don't mention which container you are interested in.
Also (friends here can correct if I am wrong) my understanding is that threads are disallowed e.g. in EJB containers etc if you access various resources handled by the container threads.
So if you only want to do some e.g. sanity checks (checking succesful startup) and similar, I don't think that this would be an issue. But this is MHO. I am not sure to be honest

ExecutorService vs Asynchronous annotation

I have a list of EJBs, each one may run for more than 1 minute. I would like to run them in loop asynchronously, and then after a timeout of 10 seconds check for results using Future output.
As I understand, both ExecutorService and #Asynchronous annotation on method can give me this functionality.
When should I use Asynchronous annotations, and when it's better to use ExecutorService?
thank you

from my point I'd stick to the EJB features and as a consequence I would use the #Asynchronous annotation which seems to be very well suited for your needs... ExecutorService is made for the Java SE world and I won't suggest you to use it directly inside a Java EE 6 server.

Who is calling the EJBs? If it's a servlet, then you might consider asynchronous servlet support.
Asynchronous EJBs are more useful than creating your own threads (via a ThreadPoolExecutor) because the container will establish thread contexts on the asynchronous thread: context class loader, java: namespaces, security, etc. Your application server might also have additional qualities of service (e.g., monitoring, timeouts, etc.) for threads that it manages.

Spring Scheduling: #Scheduled vs Quartz

I'm reading the Spring 3.0 docs regarding scheduling. I'm leaning towards Spring's JobDetailBean for Quartz. However, the #Scheduled annotation has captured my eye. It appears this is another way of scheduling task using the Spring Framework. Based on the docs, Spring provides three way of scheduling:
#Scheduled
Via Quartz
Via JDK Timer
I have no interest in the JDK Timer. Why should I choose #Scheduled over Quartz? (When I mention Quartz I mean using Spring's bean wrapper for Quartz).
Let's say my use case is complex enough that I will be communicating to a third-party web service to import and export data at specified intervals.

Quartz is an order of magnitude more complex than Spring's built in scheduler, including support for persistent, transactional and distributed jobs. It's a bit of a pig, though, even with Spring's API support.
If all you need to is to execute methods on a bean every X seconds, or on a cron schedule, then #Scheduled (or the various options in Spring's <task> config schema) is probably enough

I have to state my own experience regarding use of #Scheduled versus Quartz as scheduling implementation in a Spring application.
Scheduling jobs had the following requirements:
End users should have the ability to save and schedule (define execution time) their own tasks
Scheduled jobs during server downtime should not get omitted from jobs queue
Hence, we have to try and use Quartz implementation (version 2.2.3) in order to support persistence of jobs in a database. Some basic conclusions are the following:
Integration with a Spring 4 MVC application is not difficult at all using quartz.properties file.
We had the ability to choose a second database for storing the jobs from the main database.
Jobs scheduled during server downtime begin running as long as server comes up.
As a bonus we managed to maintain in main database some useful (and more user-oriented) information about user defined scheduled jobs using custom JobListener and TriggerListener.
Quartz is a very helpful library in applications with more complex scheduling requirements.

According to Quartz Documentation
We can use some more and complex feature that it doesn't exist in #Scheduler.
for example:
in Quartz we can placing a scheduler in stand-by mode with
scheduler.standby(); and re schedule it with scheduler.start();.
shutting down a scheduler before execution of job or after that with
scheduler.shutdown(true); and scheduler.shutdown(false);
storing a job for later use and when you need the job you can
triggered it.
JobDetail job1 =newJob(MyJobClass.class).
withIdentity("job1","group1").
storeDurably().
build();
Add the new job to the scheduler, instructing it to "replace" the
existing job with the given name and group (if any).
JobDetail job1 = newJob(MyJobClass.class).
withIdentity("job1", "group1").
build();

In Spring you could schedule task by using FixedRate,FixedDelay and cron. But most of the scheduled job requires dynamic handling of execution time. So in this scenario it is better to use Quartz as it provide the option to store scheduled jobs in DBJobstore as well as RAMJobstore.

java ejb3 #PostConstruct

I am experimenting with EJB3 on JBoss, developing a stateless bean. Basically once the module has been deployed I need to perform some actions related to load application settings.
To do this I've annotated a method as #PostConstruct, which as far as I know from the API instructs the container to invoke it once the bean has been deployed and before get in service. (correct?)
Now, I am confused, because from the log on that method looks like is not simply called after has been deployed but before each exposed method is called.
I only need to call that method once, not every time it receives a call. What would be the best approach?
Thanks in advance
Alessandro Ilardo

A stateless bean should be just that - stateless. Meaning that in use, you should neither be able to tell or to care if the bean was pulled from a pool or constructed on demand for your request. I'm hard-put to envision how a PostConstruct could apply to a stateless environment, since I always use that function to finish building a bean's state.
Apparently, JBoss is either forgoing the pooling of stateless beans and constructing them fresh each time, or, if it is using pooling, treating them like they were reconstructed each time (since they shouldn't be carrying state information). I'm actually a little surprised that it invokes the PostConstruct at all.

First of all PostConstruct is called before first method will be invoked on the bean. If no method will be invoked no post construct ever be called.
Secondly you can execute inverse actions in PreDestory method to remove side effects.
Anyway which kind of action you have to perform?

It is up to the app server to manage the lifecycle of EJBs. It may decide to construct, initialise and tear down beans whenever it sees fit. It may be that each call to your stateless bean is on a fresh instance of the your bean class, although that does seem like an off thing to do.
Is the app server calling the #PostConstruct method multiple times on the same object instance, or on a different instance each time? Try sticking log statements inside the constructor and the #PostConstruct method.

How many SLSB do you have in your pool? Depending on the container the #PostConstruct may not be called until the first client accesses it (not sure about JBoss) so this may be why it looks like it is on every access. It would be interesting to see if it stopped calling your post-construct method after calling your method the number of times equalling your pool size.
If you are performing some expensive actions in your post-construct method then maybe do these in a SFSB at startup and "inject" that SFSB into your SLSB in the post-construct.

PostConstruct gets called before the client runs a biz method. This means that if the bean isn't pooled the container will instantiate the bean, do injection, call the #PostConstruct method, then allow the biz method to run.
In the case of a pooled be then the #PostConstruct method will be run every time the bean is pulled from the pool. With Stateless beans this will be between every method call. With Stateful beans this will be after client lookup or injection.
If you need to run something on application deployment your options will depend on the version of Java EE you have.
For Java EE 6 you can use #Startup on a #Singleton EJB which contains a #PostConstruct method.
For Java EE 5 and previous you'll have to use a ServletContextListener in a web archive. You can have the ServletContextListener call an EJB if you want.
However what might be a more important question is where do you want to load these application settings to? If you are dealing with a non-clustered single JVM configuration then you probably going to want to load them into a Singleton of some type. In Java EE 5- you'll have to implement the singleton design pattern yourself or in EE 6 use the #Singleton EJB type.