I have six Java Scheduler classes, each with a different purpose but all coded in the same way. Only three of these are triggering on my WebSphere Application Server installation.
Interface:
import javax.ejb.Local;
@Local
public interface IScheduledProcessorBean
{
public void doProcessing();
}
Implementations (an example of one that isn't working, but all six are identical except for naming):
@Stateless
@HousekeepingProcessor
public class HousekeepingTimer implements IScheduledProcessorBean
{
public static final String className = "HousekeepingTimer";
@PersistenceContext(unitName = "WOTISEJB")
private EntityManager em;
/**
* Default constructor.
*/
public HousekeepingTimer()
{
// Default Constructor
}
// Try not to clash with the other schedule timer flows.
@Schedule(minute="20", hour="8-20", dayOfWeek="Mon-Fri",
dayOfMonth="*", month="*", year="*", info="HousekeepingTimer", persistent=true)
public void doProcessing()
{
Logger.getGlobal().fine(()->className + " called at: " + new java.util.Date());
try
{
// Specific logic goes here
}
catch (Exception e)
{
Logger.getGlobal().log(Level.SEVERE, "Scheduler failed for Housekeeping", e);
}
}
}
Processor Annotation:
import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;
import javax.inject.Qualifier;
@Qualifier
@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.TYPE, ElementType.METHOD, ElementType.FIELD, ElementType.PARAMETER})
public @interface HousekeepingProcessor {
}
Each of the six timers follow the exact pattern above, however only three of them trigger.
In the WebSphere Application Server 9 Console, under Enterprise Applications -> Application -> EJB JNDI names
, In only see three of the Beans (the three that run successfully), and not all six.
Likewise under Enterprise Applications -> Application -> Binding enterprise Bean with business interface to JNDI names
I only see the three working schedulers.
And, likewise, when installing the application, the "Provide JNDI names for beans" and "Bind EJB Business" steps of the detailed installation path only show those same three beans.
When I look in ejb-jar_merged.xml
in the deployed files, again, only the three working timers are there.
I have tried creating ejb-jar.xml
and deploying it explicitly, and that works - so there's something in Websphere's automatic bean processing that isn't picking it up without a prompt.
Can anyone suggest what might be going on here?
The fact that the EJB is not bound in JNDI indicates WebSphere does not recognize the class as an EJB. Since things work when using an ejb-jar.xml
file, that suggests the EJB class is at least on the classpath for the application.
Here are some additional troubleshooting steps:
1 - Confirm the EJB class is packaged in one of the following locations:
a) in a .jar
file at the root of the .ear
file, b) in a .jar
file in the WEB-INF/lib
directory of a .war
file, c) in the WEB-INF/classes
directory in a .war
file. Only these locations will be scanned for EJB component defining annotations (as required by the EJB specification).
2 - If an application.xml
file is present, ensure the version is >= 5.0. If the EJB is packaged in a .war
file, ensure the web.xml
file version is >= 2.5. (and ejb-jar.xml
>= 3.0)
3 - Confirm the import for the @Stateless
annotation is javax.ejb.Stateless
(and not jakarta.ejb.Stateless
).
4 - Confirm the javax.ejb.Stateless
annotation class is not packaged in the application or included on the application classpath. WebSphere provides the EJB API classes and there could be a conflict if the application also includes a copy.
5 - Look for any warnings in the log that indicate there was a problem accessing annotations for the application. Possibly a message starting with CWMDF
. For example, CWMDF0022W: An attempt to scan class file "{0}" in JAR file "{1}" failed with exception: "{2}"
.
6 - Confirm the ejb-jar.xml
file does not include metadata-complete="true"
. Granted, it sounds like you started without an ejb-jar.xml
file, but WebSphere does support an option during application install to generate an ejb-jar.xml
file and mark it metadata-complete
. Ensure you do not use this option at least for troubleshooting purposes.