search

eclipse-ee4j / glassfish

Eclipse GlassFish
https://eclipse-ee4j.github.io/glassfish/
387 stars 144 forks source link

GlassFish enforces change in EAR #7084

Closed glassfishrobot closed 4 years ago

glassfishrobot commented 15 years ago

In modern administration, people are used to deal with the separation of binary packages and configuration: Binary packages contain the software and configuration scripts and defaults, while the actual configuration is kept outside in a separate store. For example, on Windows, deployers are running a .msi or setup.exe file which puts the binaries in the right locations and set up a default configuration in the Windows Registry or Active Directory. AFTER that, the administrator can change these configuration settings according to the local needs AT ANY LATER TIME. Moreover most software products are able to get informed asynchronously by the Windows Registry about such changes and apply the new configuration almost immediately, without the need of a manual application restart. This separation of actual configuration and prepackaged binary is a big benefit. The application assembler just needs to provide defaults and the package will stay untouched. All local configuration is provided by the administrator or deployer in the registry, so these persons do not need to know anything about the interior of the package.

Mapped to the Java EE world, there is a similar idea. The EAR is nothing else but the package, containing the binaries (JARs, WARs, etc.), installation script and default configuration (application.xml, ejb-jar.xml, web.xml).

Unfortunately, GlassFish is not able to deploy such a "vanilla" package. It needs a lot of sun-*.xml files already at deployment time to be found INSIDE of the EAR! So the administrator or deployer need to know about the interor of the EAR, and must be able to modify the XML and EAR files. This is very bad, since a lot of those people have no real knowledge of Java EE or GlassFish in particular. Also, modifying a package before deploying it is not very smart.

JSR 88 (Java EE Deployment API) did solve this issue by declaring that the installation program can ask for open questions at the vendor's driver, so all what is found in sun-*.xml doesn't need to get packed into that files but the deployment tool can ask the user in an interactive way. Unfortunately JSR 88 support never got broad attention.

Also later changes after deployment often need a change in sun-*.xml, so a redeployment has to be done. This also is bad since it again imposes good knowledge about the structure of that XML file which least administrators actually have.

JSR 77 (Java EE Management API) tries to solved that by allowing some kind of independent management tool to query the server for any properties (including those found in sun-.xml), so the administrator can use a nice GUI to easily change settings by mouse click, without manual redeployment. Unfortunately JSR 77 does not cover all content of sun-.xml, so this is not possible right now.

To match Windows' ease of deployment and management that administrators are used these days, GlassFish should change it's way of deployment and management in this direction:

glassfishrobot commented 6 years ago
glassfishrobot commented 13 years ago

@glassfishrobot Commented mkarg said: It's a pity that Oracle does not find the time in the past years to even comment in any way this proposal. Seems Oracle has no real interest in ISV's view on GF?

glassfishrobot commented 13 years ago

@glassfishrobot Commented @vbkumarjayanti said: Mark,

Any reason this bug was categorized as a security bug ?. I am reassigning the bug to configuration and assigning it to our director so he may take notice of this and reassign as appropriate.

glassfishrobot commented 13 years ago

@glassfishrobot Commented kumara said: asadmin deploy command has an option to allow "not packaging" sun-* configuration files with the application archive. Please see http://download.oracle.com/docs/cd/E19879-01/821-0184/ablig/index.html

At this stage, GlassFish does not have a tool to create "deployment plan" from interactive user input. It will be "nice-to-have", however it is not on the roadmap as of now (which is driven by Java EE platform requirements).

On the section about not requiring "redeployment" after making configuration changes, another good requirement that we would like to get to some time but it is not on the roadmap.

Thank you for taking time to file an excellent enhancement request.

glassfishrobot commented 13 years ago

@glassfishrobot Commented mkarg said: You're welcome. But the actual problem is: Will Oracle ever have enough resources to actually implement ideas like this, or will there always be a next EE spec version that binds all people?

glassfishrobot commented 13 years ago

@glassfishrobot Commented kumara said: "Ever" is too long a timeframe to say anything about definitely. For the time being though, you are right, the focus is on the next Java EE spec.

glassfishrobot commented 13 years ago

@glassfishrobot Commented mkarg said: Reminds me of the German car industry. "When will you supply electric cars?" - "We have to concentrate on other things currently". Telling this since years. So let's just frankly say: If I do not implement it on my own, there will always be a "next spec" which prevents Oracle from implementing external ideas. Good to know for my next blog entry.

glassfishrobot commented 15 years ago

@glassfishrobot Commented Was assigned to kumara

glassfishrobot commented 7 years ago

@glassfishrobot Commented This issue was imported from java.net JIRA GLASSFISH-7084

glassfishrobot commented 15 years ago

@glassfishrobot Commented Reported by mkarg

github-actions[bot] commented 4 years ago

This issue has been marked as inactive and old and will be closed in 7 days if there is no further activity. If you want the issue to remain open please add a comment