stupid noobie question - trying to deploy ear

[end-user]

I have a stupid question.  I'm trying to deploy a refactored ear that I've probably messed up.  I have a bunch of ejbs that depend on a main jar with most of the functionality.  In order to decouple, the main jar has the interfaces and the beans implement them (because the main jar also uses the - I have to break cyclic dependencies).  My problem is when I go to deploy, all the ejbs fail with this underlying error:

`Caused by: java.lang.NoClassDefFoundError: Failed to link package/ejb/session/CheckManager/CheckManagerBean (Module "deployment.project-ear-1.0.0-SNAPSHOT.ear.package-CheckManagerEJB-1.0.0-SNAPSHOT.jar" from Service Module Loader): package/CheckManager/ICheckManager`

I'm not really sure what's going on.  Is the ejb.jar trying to load and not finding the interface in the main.jar?  Or the other way around?  Does this scream anything obvious to anyone?

[ilya_mart]

Probably your main.jar was not packed into ear. Please check. Please show your sources and pom.xml that builds ear.

[jewellgm]

What does your application.xml look like?  Are you declaring main.jar as an ejb module?  Are you trying to force a specific order of deployment?

[end-user]

I'm letting maven-ear-plugin generate the application.xml; yes, I told it to initializeInOrder.  It has my war first, and then the ejbs.  However, main.jar is not listed as it's not actually an ejb, however, it is included in the ear with other dependencies.

[jewellgm]

Can you provide the following things:

• More of the error message.  There may be something above or below what you provided that would help to narrow things down
• The structure of your ear file -- where jar files are contained (in the root directly, lib directory, etc.)
• The contents of application.xml file

Without seeing these things, it's largely a guessing game.

[end-user]

So, this story has advanced a bunch.  Essentially, I was finding it impossible to break the cyclic dependencies without lots more refactoring.  Since those dependencies largely only matter at compile time, I dumped the classes back into one large application jar file.  I've been trying to rely on an ejb declaration file (ejb-jar.xml) instead.  I believe I also got past specifying the naming factory (I need org.wildfly.naming.client.WildFlyInitialContextFactory).  Now, I'm thinking that I need to tell the container what to load by putting all the ejb names into a jboss.xml deployment descriptor?  Am I on the right track?  I'm guessing that this would work by wildfly reading the deployment descriptor and loading these classes?  Would they be found under the ejb3 subsystem if it's successful?

[jewellgm]

Using a deployment descriptor file is an option.  However, the file jboss.xml is retired, and was replaced by jboss-ejb3.xml or ejb-jar.xml.  Depending on your application, though, you may be able to simply add annotations to your EJBs.  Session beans and MDBs can often be configured completely through annotations such as @Stateless, @Local, @MessageDriven, etc.  Entity beans will require a persistence.xml, with at least an entity manager defined, but is also largely configurable through annotations.  As long as your jar is deployed as an EJB module in application.xml, the annotations are often sufficient. 

[end-user]

Ok, well bear in mind I'm trying to migrate a large, very old, application that I don't really understand.  I added that jar in the application.xml under module -> ejb and now wildfly is attempting to load it (yay!).  However, each ejb is failing because wildfly is expecting a Validator, ValidatorFactory, InstanceName and InAppClientContainer.  Is there an aspect I'm missing?

[end-user]

After combing through my log, I'm wondering if this is my issue:

2018-10-12 08:14:46 INFO  [org.jboss.as.ejb3.deployment] (MSC service thread 1-3) WFLYEJB0473: JNDI bindings for session bean named 'ApplicationManager' in deployment unit 'subdeployment "myejbjar-1.0.0-SNAPSHOT.jar" of deployment "myapp-ear-1.0.0-SNAPSHOT.ear"' are as follows:

    java:global/myapp-ear-1.0.0-SNAPSHOT/myejbjar-1.0.0-SNAPSHOT/ApplicationManager!com.package.ApplicationManagerLocal

    java:app/myejbjar-1.0.0-SNAPSHOT/ApplicationManager!com.package.ApplicationManagerLocal

    java:module/ApplicationManager!com.package.ApplicationManagerLocal

    ejb:myapp-ear-1.0.0-SNAPSHOT/myejbjar-1.0.0-SNAPSHOT/ApplicationManager!com.package.ApplicationManagerLocal

    java:global/myapp-ear-1.0.0-SNAPSHOT/myejbjar-1.0.0-SNAPSHOT/ApplicationManager

    java:app/myejbjar-1.0.0-SNAPSHOT/ApplicationManager

    java:module/ApplicationManager

...

2018-10-12 08:14:47 DEBUG [org.jboss.as.ee] (MSC service thread 1-8) Configuring component class: com.package.ApplicationManagerBean named ApplicationManager

...

    Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYEJB0405: No EJB found with interface of type 'com.package.ApplicationManagerLocalHome' and name 'ApplicationManager' for binding java:comp/env/ApplicationManager

At the top, it's found a bean descriptor and is going to deploy it.  The ejb-jar lists only local & local-home references (no remote).  Later, after loading all the descriptors, wildfly states it's going to configure (initialize?) the class.  However, it fails because it says there's no ejb with the LocalHome interface bound to the java:comp/env/name?

my bean description in ejb-jar for this is

<session>

    <ejb-name>ApplicationManager</ejb-name>

    <ejb-class>com.package.ApplicationManagerBean</ejb-class>

    <session-type>Stateless</session-type>

    <transaction-type>Container</transaction-type>

    <ejb-local-ref>

        <ejb-ref-name>ApplicationManager</ejb-ref-name>

        <ejb-ref-type>Session</ejb-ref-type>

        <local-home>

            com.package.ApplicationManagerLocalHome

        </local-home>

        <local>com.package.ApplicationManagerLocal</local>

        <ejb-link>ApplicationManager</ejb-link>

    </ejb-local-ref>

</session>

and, yes, ApplicationManagerBean implements both ApplicationManagerLocal and ApplicationManagerLocalHome

Am I understanding this correctly?  If so, what am I missing?