Historically the default application name has been the name (without
file type) of the archive. In v3 up until now the DeployCommand
implemented this logic.
Some application types, such as JBI service assemblies, will need to
vary from this. In fact JBI service assemblies were handled as special
cases in v2 autodeployment for just this reason.
I have just checked in a small v3 change set that delegates the
selection of the default application name to the ArchiveHandler for the
relevant archive type. The default implementation in
AbstractArchiveHandler is functionally identical to what has been the
case in v2 and v3. The JBI service assembly archive handler will be
able to override this implementation to return the name of the service
assembly from inside the archive, as the special-case logic for JBI in
the v2 autodeployer does today.
Jerome correctly warns that the logic that determines an archive's
default app name should not rely on APIs provided by the corresponding
container because those APIs might not have been loaded yet. In the JBI
service assembly case the special-case logic in the v2 autodeployer
fetched the descriptor file entry from the archive and used XPath to
navigate to the data of interest. The JBI service assembly archive
handler will probably do the same, thereby avoiding the illegal
dependency Jerome warned about.
- Tim