Issue Details (XML | Word | Printable)

Key: GLASSFISH-17826
Type: New Feature New Feature
Status: Resolved Resolved
Resolution: Fixed
Priority: Major Major
Assignee: Hong Zhang
Reporter: vince kraemer
Votes: 0
Watchers: 1
Operations

If you were logged in you would be able to see more operations.
glassfish

provide an asadmin command that outputs the 'effective deployment descriptors'

Created: 24/Nov/11 02:36 AM   Updated: 01/Feb/13 09:14 PM   Resolved: 10/Oct/12 02:23 AM
Component/s: deployment
Affects Version/s: None
Fix Version/s: V3

Time Tracking:
Not Specified

Tags:
Participants: arungupta, Hong Zhang, Tim Quinn, Tom Mueller and vince kraemer


 Description  « Hide

this request is based on the note that alexis sent around.

Interesting and lively discussion on configuration/properties :
[snip]

  • Ops guys don't like Annotations in the class as opposed to DD. Looking for externalizable configuration.

Back in the v2 days, the DD files were written to the generated directory. See http://java.net/jira/browse/GLASSFISH-3844 for some oblique references to the behavior.

With the advent of annotations and web-fragments it is fairly difficult for a 'deployer' to compute the deployment configuration for a non-trivial web-app. The same applies to ejb-jars... but not as critical.



arungupta added a comment - 24/Nov/11 01:32 PM

Now that Java EE 6 allows annotations to spread across multiple files, there is no holistic view of the application in terms of all the components included in the WAR. This is a concern for devops as they do not know what to override using deployment descriptors. Also developers don't get a complete view of the application in terms of Servlets, EJBs, Filters, Listeners etc. The app can still specify some Servlets using web.xml and then web-fragment.xml adds an interesting twist to that scenario.

Just like "effective POM", an effective "web.xml" needs to be generated which can be read from multiple sources: annotations, web.xml, web-fragment.xml. This could be enabled by --keepgenerated flag.


vince kraemer added a comment - 24/Nov/11 04:53 PM

the effective web.xml is especially tricky... since it also gets default-web.xml blended in, too.

We could extend the asadmin deploy command with keepgenerated. It seems like this task is similar to the _listurls (sp??) command that we created for the JavaOne 2011 demo.

By having a separate command I think we will give users more operational flexibility.


vince kraemer added a comment - 25/Nov/11 05:43 PM

just remembered... I think default-web.xml in blended in when the app is started, not at deploy-time.

This means that you can deploy some apps, edit default-web.xml and restart your server and all the apps get the benefit of the new default-web.xml... not just the apps that get redeployed after the change is made in default-web.xml...


Tim Quinn added a comment - 26/Nov/11 01:44 PM

Also remember that a web app's config can be altered using the set-/unset-web-context-param and set-/unset-web-env-entry commands after the app has been deployed.


vince kraemer added a comment - 27/Nov/11 04:23 PM

Hmmm. That is an interesting wrinkle... Should the output of a getEffectiveDeploymentConfiguration command output the dynamic effective or the statically defined effective DDs for a deployed archive.


Tom Mueller added a comment - 28/Nov/11 01:39 PM

Changing to the deployment component.


Hong Zhang added a comment - 10/Oct/12 02:23 AM

Today you could use a system property to force the writing out of the generated descriptors for debug purpose (in the generated/xml directory like in v2), they are just no longer written out by default.

Add this jvm option to domain.xml and restart server before you deploy:
<jvm-options>-Dwriteout.xml=true</jvm-options>


vince kraemer added a comment - 01/Feb/13 09:14 PM

Ummm. I guess that is a work around. It is a bit strange to deploy the app to generate the effective DD so that you can edit that DD so that the app can be deployed using the configuration that you actually want.

If this was a bug, a work-around may be good enough to mark the issue as resolved. Since the request was for a new command, I don't think this is really resolved.