How to call separately deployed ejb3 on wildlfy

Question

As long as my EJB is deployed inside the war of the app using it everything works fine, I only have to @Inject it, no xml, and no local or remote interfaces. The webapp is a Vaadin 7.5.6 app using vaadin-cdi.

When deploying the ejb as a separate jar, the web-app calling it fails with "Forbidden". I've annotated it with

@SecurityDomain("other")
@RolesAllowed({ "guest" })

However, still "Forbidden". Probably some config is needed in the webapp as well. All examples I've found so far mentions jndi-lookup, ejb-jar.xml, web.xml, jboss-ejb.xml, ejb interfaces and whatnot. Is it even possible to have the ejb deployed separately and accessible, while avoiding all this extra config? I'd like to break up my app so that I don't have to deploy everything each time I make changes to the gui, but if I have to revert to "old school" ejb config I'm not sure there is a point.

Using Wildfly 9.0.2, Java 8 and Maven.

Edit:

EJB : The Hello World EJB lives in a maven sub-project, it has jar-packaging. It has no xml-configuration and no local or remote interface. There is no usage of maven-ejb-plugin. The implementation looks like this:

import javax.ejb.Stateless;

@Stateless
public class ReceptionService {
    public String welcome() {
        return "Hello, Developer! No XML, No Configuration, and it works!";
    }
}

There is also a number of real-world session beans that use JPA inside methods that look like this (below) so there might be some persistence and transaction issues popping up as well here, but not until the simple hello-world case is working. The hello-world-webapp does not include any of these EJBs, just the simple hello-world-EJB.

@Stateless
@TransactionManagement(value = TransactionManagementType.CONTAINER)
public class DealerSession {

    private Logger logger = LoggerFactory.getLogger(DealerSession.class);

    @PersistenceContext(unitName = "MyUnit")
    protected EntityManager em;

    @TransactionAttribute(REQUIRED)
    public Long create(DealerUpdate update) {
        notNull(update, "update"); // and so on ....

The persistence unit is defined in the EJB project, and it connects to an datasource in Wildfly. In the real-world-beans transactions are rolled back on failure.

WAR : This is a Vaadin 7 webapp. It simply looks like this:

@CDIUI("")
@Theme("valo")
public class WelcomePage extends UI {

    @Inject
    ReceptionService service;

    @Override
    protected void init(VaadinRequest request) {
        setSizeFull();
        String message = service.welcome();
        Label label = new Label("this is the message: " + message);
        setContent(new HorizontalLayout(label));
    } ....

The EJB jar-file is referenced in the dependencies. So it is included, and everything works as if the EJB bean was just a .class-file in the war. This is very convenient, because there is almost no configuration involved. But as the real-world-project here grows, I'd like to split up the deployment, so that I do not have to deploy all EJBs as part of the war each time the gui is updated, because it slows down the development cycle.

The war project depends on vaadin-cdi 1.0.3 and vaadin-bom 7.5.6, and of course the jar with the EJB (which has jar and not ejb packaging). Also vaadin-maven-plugin, maven-resource-plugin and maven-war-plugin is used.

Both projects also use wildly-plugin 1.0.2.Final. and depend on java javaee-api 7.0.

NOW, my naïve attempt so far has been to change packaging of the EJB jar to "ejb", add maven-ejb-plugin, specify scope provided in the dependency in the pom file of the war-project, and deploy war and jar separately. So far there are no error-messages or warning, both are deployed. But access to the ejb is "Forbidden", there is an error message in the gui saying that, strangely not in the wildfly console. I've tried to add @SecurityDomain and @RolesAllowed annotations to the EJB (see above), but stuff has to be configured on the webapp as well. If it is so that CDI only will inject the EJB as a pojo anyway, or I have to add Local and/or Remote interfaces, perform JNDI-lookups, add lots of stuff to xml configuration files and so on, I can manage that, because there are sample apps and documentation for that, but also everything gets a lot more complicated, and I want to avoid that.

Answer 1

First of all your EJBs are not not injected as such, even if they are deployed with your WAR. This is because you don't declare interfaces. In this case you will at least have to annotate them with @LocalBean which declares the no-interface-view for the bean.

When you outsource the EJBs into a jar, CDI is not able to inject the bean isntances that would be produced by EJB (the proxies) but injects pojo instances instead. To avoid this you could create a producer field or method for each EJB in your WAR. Injecting the bean with CDI then calls the producer. This producer would have to do a specific JNDI lookup (java:global/...) to get the EJB bean instance.

Then, when deploying to wildfly, you will have to add a dependency from the WAR to the JAR since both deployments have separate class loaders and can't see each other. The dependency connects both class loaders so that the one of the WAR is able to load classes of the JAR.

You will only have to activate CDI for the WAR not the JAR in this case since the EJB instances are retrieved by explicit JNDI lookups.

Answer 2

The answer I have approved for my question might be the right one if you absolutely need to use cdi-injection. I never came as far as I got it working, though.

Instead I decided to try use the @EJB annotation, instead of @Inject. When I deploy my ejb (in a separate jar from my web-app, that lives in a war-file) Wildfly registers jndi-names and reports this in the console. One of the names is "java:global/template-service-1.0.0-SNAPSHOT/ReceptionService". Note the "global" scope.

The @EJB annotation has a parameter called mappedName. Injecting and using the ejb like this did the trick:

@EJB(mappedName = "java:global/template-service-1.0.0-SNAPSHOT/ReceptionService")
ReceptionService service;

@Override
protected void init(VaadinRequest request) {
    UI.getCurrent().setLocale(new Locale("nb","no"));
    setSizeFull();
    String message = service.welcome();
    Label label = new Label("message: " + message);
    setContent(new HorizontalLayout(label));
}

It is also still needed to register module dependency, so that the client class loader can see the service. I do it in the webapp pom.xml using the war-plugin:

         <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-war-plugin</artifactId>
            <configuration>
                <archive>
                    <manifestEntries>
                        <Dependencies>deployment.template-service-1.0.0-SNAPSHOT.jar</Dependencies>
                    </manifestEntries>
                </archive>
            </configuration>
        </plugin>

This way I am able to deploy my ejbs separately, and I can then deploy my war-file as a "thin" deployment. My real-world project has a bunch of ejbs and jpa-stuff which slows down the develops-compile-deploy cycle when I work on the gut-stuff, with this setup I can save quite some time when fiddling with the gui.

The EJB looks like this, no ejb-jar.xml.

@Stateless
public class ReceptionService {
    public String welcome() {
        return "Hello, Developer! No XML, No Configuration, and it works!!!";
    }
}

The no-xml-part in the message would only be true if you added the module dependency to your manifest manually, and not using war-plugin :o)

Edit: to include dependencies in the ejb jar one can use one-jar plugin or similar.