Forward from an internal mailing to the list so we can keep track and
inform others that possibly also come across this.
Vineet Reynolds (@VineetReynolds) originally wrote this email. So
credit goes to him ;)
Thanks,
M
----snipp
We've encountered a bug with the list-sub-components admin command
(issued through the REST API in this case), of GlassFish. I've
provided a background for this issue, and the observations of the
buggy behavior:
We have an application, that uses Arquillian in it's integration
tests. Arquillian uses the GlassFish RESTful administration interface
for all communication with the GlassFish container. After deploying
the application, Arquillian issues a list-sub-components command (of
format "
http://host:port/management/domain/applications/application/list-sub-components?id={application}&type=servlets"
where {application} is the deployment name), to determine the list of
web-modules in the application. The value of the "type" property is
set to "servlets", in order to obtain the set of Web Modules only in a
EAR deployment, and the list of servlets in a WAR deployment. The
"moduleInfo" properties returned in the response are eventually used
to obtain metadata about the deployment, most importantly the context
root of the web modules.
The problem lies with the response returned by GlassFish for the
above mentioned REST request, only for this application (so far). The
expected behavior of returning a filter set of properties is observed
with most applications, but in this case, GlassFish returns a
moduleInfo property containing metadata about an EJB module, instead
of the Web Module. The application is deployed as an EAR, containing
two modules - an EJB module and a Web Module.
My debugging has led me so far:
1. The 'getAppLevelComponents' method of the
'ListSubComponentsCommand' class returns a Map with the module name
and the type of the module. When the request specifies a type of
"servlets", the returned Map will contain only WebModules (and no EJB
modules).
2. The 'getSubModulesForEar' method of the 'ListSubComponentsCommand'
class returns subModuleInfos - a List of modules (with some metadata)
of an application. The basis for this List is however a Set of
ModuleDescriptors, so the order of the elements in the List depends on
the order in which the Set is iterated through.
3. When the childParts are added to the ActionReport in the execute
method of the 'ListSubComponentsCommand' class, moduleInfo elements
are added to the childParts from the subModuleInfos list (from pt 2).
The subModuleInfos list being ordered, it is quite possible to add the
moduleInfo element of a different module, to the childPart. This is
precisely what happens in the case of this application - the EJB
moduleInfo element is added instead of the Web moduleInfo element.
--- snapp