Search code examples
jakarta-eeglassfishpayara

What's the difference between glassfish-application.xml and glassfish-web.xml in GlassFish/Payara 4.x?


There're tons of explanation for the difference between Java EE and Web profile for all imaginable pairs of implementations ("What's the difference between Tomcat and GlassFish", "What's the difference between GlassFish and JBoss", etc.) which is pretty clear to me. There're good questions for glassfish-web.xml vs sun-web.xml vs web.xml as well as The difference between web.xml, beans.xml, applicationContext.xml, etc however they all link to the GlassFish 3.x documentation[1].

I'd like to have some definite statements on

  • precedence between glassfish-application.xml and glassfish-web.xml, meaning does one override the other (it could be logical that web overrides application because the classloading order is inverted) or are options picked from both?
  • possible locations where I can expect the files to be picked up. I assume / in the ear for the application and /WEB-INF/ in the war (inside the ear) for the application descriptor
  • Is it possible to specify any values in both files which can be specified in other files, like web.xml or beans.xml and if yes, what's the precedence, then?
  • What's the situation in a war packaged (as opposed to ear packaged) Java EE application?

I assume that there's no difference between Payara and GlassFish because the former is designed to be a drop-in replacement - the fact that documentation is practically not found by google is the same for Payara as for GlassFish 4.x.


[1] which is the major issue with GlassFish - most of the time there's only 3.x documentation available through links in manuals, blog and SO questions and you have to try all the things with the presumption that it might not work because something changed from 3.x to 4.x which results in 2^n complexity for n issues.


Solution

  • precedence between glassfish-application.xml and glassfish-web.xml, meaning does one override the other (it could be logical that web overrides application because the classloading order is inverted) or are options picked from both?

    The glassfish-application.xml is intended for .ear files, while the glassfish-web.xml is intended for .war files. For a .war within an .ear, the glassfish-web.xml would override settings declared within the glassfish-ejb.xml.

    possible locations where I can expect the files to be picked up. I assume / in the ear for the application and /WEB-INF/ in the war (inside the ear) for the application descriptor

    If by this you mean where the files should be located, the glassfish-application.xml should be placed within the META-INF of the .ear alongside the MANIFEST.MF, while the glassfish-web.xml should be placed within the WEB-INF, alongside the beans.xml.

    Is it possible to specify any values in both files which can be specified in other files, like web.xml or beans.xml and if yes, what's the precedence, then?

    Yes, the standard JavaEE deployment descriptors, so web.xml, beans.xml etc are respected, but where there is a server specific deployment descriptor (i.e. glassfish-web.xml) they will be overridden.

    What's the situation in a war packaged (as opposed to ear packaged) Java EE application?

    Within a war-packaged application, you should stick to using the glassfish-web.xml deployment descriptor. This will override values set within the JavaEE web.xml deployment descriptor, but both will be read.

    I assume that there's no difference between Payara and GlassFish because the former is designed to be a drop-in replacement - the fact that documentation is practically not found by google is the same for Payara as for GlassFish 4.x.

    As Payara Server is derived from GlassFish we only document areas which extend or modify the default behaviour. As such, the GlassFish 4 documentation https://javaee.github.io/glassfish/documentation4 can be used for any areas not mentioned within the Payara Server documentation https://docs.payara.fish/. I agree that this does indeed make finding what you are looking for quite a pain, especially as with this instance where the GlassFish Deployment Guide doesn't make it explicitly clear. In fact, a large portion of the GlassFish 5 documentation appears to be unchanged from 3.1.2, so you may not be miles away from a current answer.