Glassfish 4.1: war inside ear does not expose webservices

Question

I am currently working on upgrading an application from Java7 running on Glassfish 3.1.2.2, to Java8 running on Glassfish 4.1. The application is packaged as an ear-file, containing an ejb-jar, and a war. The war in turn contains some webservices.

In Glassfish 3.1.2.2, deploying the ear will lead to the war exposing a number of webservices. But, when I deploy the ear in Glassfish 4.1, no webservice are exposed. When listing the components for the ear in Glassfish, the war does not list webservices (only web) in 4.1 (but does in 3.1.2.2).

I have tried deploying the war-file as a standalone application, and when doing this the webservices becomes available.

Does anyone know if there is a known bug with regards to deploying webservices through an ear-file with Glassfish 4.1?

When it comes to changes, I have upgraded some dependencies, but as far as I know there is nothing that should affect this.

My application.xml:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE application PUBLIC
    "-//Sun Microsystems, Inc.//DTD J2EE Application 1.3//EN"
    "http://java.sun.com/dtd/application_1_3.dtd">
<application>
  <display-name>myApplication-ear</display-name>
  <description>myApplication</description>
  <module>
    <ejb>myApplication-ejb-5.2-SNAPSHOT.jar</ejb>
  </module>
  <module>
    <web>
      <web-uri>myApplication-war-5.2-SNAPSHOT.war</web-uri>
      <context-root>/myApplication-war</context-root>
    </web>
  </module>
</application>

I actually have this exact same problem in Glassfish 3.1.2. I only have a single class in my war and a single war in my ear. Deploying as an ear yields inconsistent results. Sometimes it works and sometimes not. Deploying as a war seems to be the only way it works consistently correct. — Rob Benton, Dec 15 '15 at 13:46
Think there might be a bug (race condition maybe) when initializing the ear. Restarting glassfish will make the webservice deploy in some cases (so no need for a redeploy when it happens..) But good to know that I'm not the only one with the problem, might create a bug with glassfish then.. The project I'm working on is quite a mess, so wasn't sure if it was the project's fault.. — Tobb, Dec 15 '15 at 14:35

score 1 · Accepted Answer · answered Feb 24 '16 at 07:58

The problem was an old dependency:

  <dependency>
    <groupId>com.sun.xml.ws</groupId>
    <artifactId>jaxws-rt</artifactId>
    <version>2.2.7</version>
  </dependency>

I removed it because it is already included in rt.jar in the java installation. Somehow Glassfish didn't handle this at all, the webservices simply didn't work and no traces of error in the server.log

score 0 · Answer 2 · answered May 08 '15 at 10:20

0

Can this be your scenario (?): EJB module deployment may fail when an EJB that is exposed as a web service, and which has a handler, is initialized before an EJB on which it has dependencies. This is caused by the way the EJB container initializes and loads EJB web services, the workaround is to rename the EJBs so that the EJB exposed as a web service is initialized after the EJB on which it has dependencies.

answered May 08 '15 at 10:20

I'm not sure I understand 100%, but you might be onto something. One thing I noticed (and then forgot) when deploying the war as a standalone was that I recieved error messages that did not occur when deploying the ear (something with Hibernate, so should have failed for both ear and war). It seems that errors from submodules are not propagated when deploying an ear. Deploying the ejb-module standalone seemed to be a bit more tricky, but I might try that and see if any errors pop up. – Tobb May 08 '15 at 10:28
Let's rephrase the above scenario: the EJB WebService may fail because its dependencies were not loaded. EJB initialization usually happens in alphabetical order. Can you rename the EJBs so that the EJB exposed as a web service is initialized after the EJB on which it has dependencies and try deploy the ear again ? – May 08 '15 at 10:35
The EJBs are not exposed as webservices. There are separate modules, the one with EJB is for communication with a Swing-client, the war contains standard `@Webservice`-annotated classes. I will try to deploy the ejb-jar as a standalone and resolve any errors to see if it helps. It might be that initialization of the ejb fails, which in turn leads to the war not being properly initialized (I find it strange that the server log is all sunshine though..) – Tobb May 08 '15 at 10:38

Glassfish 4.1: war inside ear does not expose webservices

2 Answers2