There's DeployUtils.extractModuleIdFromArchive(File) which will give you the ModuleID (if there's a Geronimo deployment plan in the archive), but you still have to get to the TargetModuleID. If you plan to support anything other than Geronimo then I think you need to loop through getAvailableModules(), but if you plan to support Geronimo only, I think you could just create a TargetModuleIDImpl directly (with the Target from getTargets and the ModuleID or archive name).
Right now the deploy tool uses these to handle redeploy even if no module ID is specified on the command line. Aaron On 11/10/05, Sachin Patel <[EMAIL PROTECTED]> wrote: > Aaron, > > Is there a way I can exploit this when invoking redeploy's through the > DeploymentManager? Is there some utility method that can return me back > a TargetModuleID for a given archive? I currently have to traverse > through all the TargetModuleID's returned from > getDeploymentManager().getAvailableModule()'s to find a matching > configID, and was wondering if there might be an easier way. > > > Aaron Mulder (JIRA) wrote: > > [ http://issues.apache.org/jira/browse/GERONIMO-1120?page=all ] > > > > Aaron Mulder resolved GERONIMO-1120: > > ------------------------------------ > > > > Resolution: Fixed > > Assign To: Aaron Mulder > > > > Revision 332215 > > > > > >> Auto-detect config ID for a deployable archive > >> ---------------------------------------------- > >> > >> Key: GERONIMO-1120 > >> URL: http://issues.apache.org/jira/browse/GERONIMO-1120 > >> Project: Geronimo > >> Type: Improvement > >> Components: deployment > >> Versions: 1.0-M3 > >> Reporter: Aaron Mulder > >> Assignee: Aaron Mulder > >> Fix For: 1.0 > >> > > > > > >> Given an application/module/service archive, or an archive and a plan, we > >> need a routine to pull out what the configuration name will be for it. In > >> other words, we need to peek into the deployment plan and look for the > >> configId attribute, the catch being that we don't know up front what the > >> name of the plan file is if it's embedded in the JAR. > >> This is necessary to be able to redeploy without explicitly naming the > >> configuration to replace, which is necessary to do redeploy operations in > >> a hot deploy directory. > >> It seems like it'd be easy to write a bit of code to do this by hardcoding > >> the locations of all known deployment types, but it would be a little more > >> elegant if the deployers coughed up the required information and it could > >> be handled on a more pluggable basis. > >> > > > > > >
