Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Payara not showing modules for versioned application PAYARA-670 #702

Closed
ratcashdev opened this issue Mar 14, 2016 · 7 comments
Closed

Payara not showing modules for versioned application PAYARA-670 #702

ratcashdev opened this issue Mar 14, 2016 · 7 comments
Labels
Status: Accepted Confirmed defect or accepted improvement to implement, issue has been escalated to Platform Dev

Comments

@ratcashdev
Copy link
Contributor

Mostly related to #455 and slightly #445.
Glassfish is not able to list the deployed modules when using versioned applications.
See the attached screenshots:
versioneddeployment
expected:
expected

I was wondering, if this is not a simple path mistake? Note the different between the colon in the application's name, and the ~ (tilde) that is used in the app's path on the filesystem.

@smillidge smillidge changed the title Payara not showing modules for versioned application Payara not showing modules for versioned application PAYARA-670 Mar 16, 2016
@OndroMih OndroMih added Status: Accepted Confirmed defect or accepted improvement to implement, issue has been escalated to Platform Dev c:PossibleBug labels Apr 11, 2016
@ratcashdev
Copy link
Contributor Author

#461 seems to be duplicate (and sorry, i forgot about that one). I do think we've got more relevant information here, than there. As #461 also deals with lost requests, I suggest to focus on the lost request as part of #461 and with components/monitoring as part of this issue.

@ratcashdev
Copy link
Contributor Author

Couple of findings:

  1. The component listing seems to be just a GUI problem, because the REST management services work find. E.g. GET http://localhost:4848/management/domain/applications/application/versionedSampleApp:1/list-sub-components works just fine and I get the necessary components.
  2. ex.getLocalizedMessage() is many times returning simply "null" which makes the debug so much more difficult. Wonder why did they chose this option instead of the ex.getMessage().
  3. The json response from the REST resource includes the following: "commandLog": [ "list-sub-components --modulename versionedSampleApp:1" ]
    whereas the correct command-line is:
    asadmin list-sub-components --appname="versionedSampleApp:1" versionedSampleApp i.e. without the ":1" version suffix, and without --modulename (the latter being not even understood by the cli)
  4. ApplicationHandlers.getSubComponents() is subject to NPEs if the application has no contextRoot (disabled app after restart). i will open a separate issue for this.

This hints to the fact that the GUI is not propely stripping the version from the app-name when used as module-name.

However, it also seems that for different REST endpoints, the expected style of the module-name is varying.
Examples:

  • AppUtil.getSnifferListOfModule(), that is /applications/application/{appName}/module/{moduleName} expects the appName and the moduleName both with the version included.
  • ApplicationHandlers.getSubComponents(), that is /applications/application/{appName}/get-context-root.xml?modulename={moduleName} expects the appname with version and the moduleName w/o version
  • ApplicationHandlers.getSubComponentDetail(), that is /applications/application/{appName}/list-sub-components?appname={appName}&id={moduleName} expects the appname with version and the moduleName w/o version

@ratcashdev
Copy link
Contributor Author

For now, I can see two different approaches to fix this:

  1. Fix the REST clients. Currently identified 2 files, ApplicationHandlers and MonitoringHandlers.java. However, it's clear there will be more, somewhere in .inc files the usage of which is beyond me, unfortunately.
  2. Fix the REST resources so that they properly strip off the version suffix from the moduleName where needed. This may be a simpler approach with less hunting.

@ratcashdev
Copy link
Contributor Author

One more possibility is to ensure that the contents of the HandlerContext is properly set up (that is, moduleNames won't contain version suffixes), but given the various expectations of the REST services, that may not be such a good idea, after all.

@ratcashdev
Copy link
Contributor Author

It seems also some of the REST responses contain invalid moduleNames. Specific case:
management/domain/applications/application/{appName}:1/module
returns the following:

{
...
    "extraProperties": {
       ...
        "childResources": {
            "{appName}:1": "http://localhost:4848/management/domain/applications/application/{appName}:1/module/{moduleName}:1"
        }
    }
}

@ratcashdev
Copy link
Contributor Author

The linked pull request is basically approach No2: "Fix the REST resources so that they properly strip off the version suffix from the moduleName where needed."

@smillidge
Copy link
Contributor

Thanks for all the work and analysis

smillidge pushed a commit that referenced this issue Apr 23, 2016
…updates) when looking up the app's modules. (#746)

Dirty hack to solve issue #702, and partly also #461 (note: only the GUI issue, when components were listed).
arieki pushed a commit to arieki/Payara that referenced this issue Dec 16, 2022
FISH-5809 (Enterprise) Add `jdk.internal.reflect` packages to OSGi BootDelegation
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Status: Accepted Confirmed defect or accepted improvement to implement, issue has been escalated to Platform Dev
Projects
None yet
Development

No branches or pull requests

3 participants