2

I have to migrate a software project from Websphere Application Server v8 (WAS8) to Webphere Liberty Base v17 (WL17) and ran into troubles with the EJB's. E.g. there is the following EJB:

@Stateless
@Local(MyUserServiceLocal.class)
public class MyUserServiceBean implements MyUserServiceLocal {

    @EJB
    private OtherServiceLocal otherServiceLocal;

    @Resource
    private SessionContext context;

    public MyUserServiceBean() {
    }

    public String getUserEmail() {...}

    public String getUserDataId() throws ServiceException {...}
    ...
}

With the corresponding local interface:

@Local
public interface MyUserServiceLocal {

    public String getUserEmail();

    public String getUserDataId() throws ServiceException;
    ...
}

There are a lot more EJB's following a similar implementation scheme.

The project builds fine, all facets in all Eclipse projects are set correctly and maven creates a fresh and deployble EAR file. But when I visit the applications default page the following nested exception is thrown: The MyUserServiceBean bean class for the MyApplication#MyUserServiceEjb.jar#MyUserServiceBean bean does not have a public constructor that does not take parameters.

I currently can not imagine why this exception is thrown by WL17. The feature configuration of my WL looks like this:

<featureManager>
    <feature>appSecurity-2.0</feature>
    <feature>cdi-1.2</feature>
    <feature>distributedMap-1.0</feature>
    <feature>ejbLite-3.2</feature>
    <feature>ejb-3.2</feature>
    <feature>jacc-1.5</feature>
    <feature>jaxrs-2.0</feature>
    <feature>jaxws-2.2</feature>
    <feature>jca-1.7</feature>
    <feature>jdbc-4.1</feature>
    <feature>jndi-1.0</feature>
    <feature>jpa-2.1</feature>
    <feature>jsf-2.2</feature>
    <feature>jsp-2.3</feature>
    <feature>ldapRegistry-3.0</feature>
    <feature>mdb-3.2</feature>
    <feature>servlet-3.1</feature>
    <feature>ssl-1.0</feature>
    <feature>webCache-1.0</feature>
    <feature>wmqJmsClient-2.0</feature>
</featureManager>

I is the same when I do not load the mdb or the ejb feature. Is there any idea how to solve this problem? I have googled a lot and reade half of the internet but didn't get an answer or an idea how to solve this problem.

Joko
  • 600
  • 3
  • 15
  • maybe this can help? https://stackoverflow.com/questions/24868561/bean-does-not-have-a-public-constructor-that-does-not-take-parameters-error-de and https://stackoverflow.com/questions/43904524/was-liberty-ejb-bean-does-not-have-a-public-constructor-that-does-not-take-p – fantaghirocco Sep 12 '17 at 10:47
  • 1
    Thank you for your comment. The referenced SO questions provide three ideas to solve the problem. I tried them all with the following outcome: (1) @PostConstruct -- doesn't work. (2) Injecting members instead of using a default constructor + EJB annotations -- doesn't work. (3) Misconfiguration of Maven plugin -- does not fit to the problem. || I'm sorry, but I still have the same problem, and only with this bean. There are a lot of other beans following the exact same implementation scheme which does not have the problem. – Joko Sep 12 '17 at 13:48

1 Answers1

2

I found the problem of the EJB. One of the interface methods was declared to throw a javax.xml.rpc.ServiceException. I do not understand why this should be a problem, but after removing the throws declaration in the interface and the implementation class WL 17 was able to initialize the bean correctly.

Joko
  • 600
  • 3
  • 15
  • Likely, javax.xml.rpc.ServiceException was not on the classpath, so when the EJB container used reflections to locate the constructor, the JDK returned an error or perhaps null, indicating it did not exist. It seems that the JDK will attempt to fully initialize and resolve the class when reflections is used on it, resulting in this type of error. Ideally, the JDK would have thrown some type of ClassNotFoundException and WebSphere would have at least logged that in FFDC, but I'm guessing the JDK just returned null. – Tracy Sep 19 '17 at 22:02