Some java @Schedule not triggering in Websphere, and some are

huangapple go评论56阅读模式
英文:

Some java @Schedule not triggering in Websphere, and some are

问题

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?

英文:

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?

答案1

得分: 1

以下是要翻译的内容:

看起来六个调度程序类中的三个在WebSphere应用服务器中没有触发。这很可能是由于EJB JNDI名称未正确绑定到调度程序类的问题。

以下是一些用于排除此问题的步骤:

  1. 确认所有六个调度程序类都包含在部署单元中(例如.ear文件)。
  2. 检查所有六个调度程序类上是否存在@Stateless注释。
  3. 验证没有类路径或包级别的问题,防止在部署过程中检测到调度程序类。
  4. 确保如果适用,Maven依赖项在项目的pom.xml文件中正确配置。
  5. 确保所有调度程序类都具有默认构造函数。
英文:

It looks like the three out of six Scheduler classes are not triggering in WebSphere Application Server. This is likely due to a problem with the EJB JNDI names not being bound correctly to the Scheduler classes.

Here are a few steps to troubleshoot this issue:

  1. Confirm that all six Scheduler classes are included in the
    deployment unit (e.g. .ear file).
  2. Check that the @Stateless annotation is present on all six Scheduler
    classes.
  3. Verify that there are no classpath or package level issues that
    prevent the Scheduler classes from being detected during deployment.
  4. Make sure that the Maven dependencies, if applicable, are properly
    configured in the project's pom.xml file.
  5. Ensure that all Scheduler classes have a default constructor.

答案2

得分: 1

以下是已翻译的内容:

"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."

英文:

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.

huangapple
  • 本文由 发表于 2023年2月6日 17:37:24
  • 转载请务必保留本文链接:https://go.coder-hub.com/75359554.html
匿名

发表评论

匿名网友

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

确定