You know, I had thought of this case as I was working on the changes -
the trailing slash for directories - but forgot to account for it.
I will address it Friday U.S. time and check in the fix.
Thanks for catching this.
- Tim
Pramod Gopinath wrote:
> Hi Tim
> There is a bug in the code when one tries to do a directory
> deployment. I am trying to do a directory deployment of a ROR
> application and in this case the method
> AbstractArchiveHandler.getDefaultApplicationName() returns a name of
> value "".
>
>
> I am trying to do a directory deployment of a ROR application. The
> command that I have used is :
> ~/work_related/gf_v3_install/01312008/glassfish/bin/asadmin deploy
> --upload=false
> /Users/pramodgopinath/work_related/jruby_for_V3/samples/hello
>
> This is what I have got by debugging the command :
> DeployCommand.execute() has the path set correctly to
> "/Users/pramodgopinath/work_related/jruby_for_V3/samples/hello"
>
> Then there is call to archive = archiveFactory.openArchive(file);
> which enters
> ./common/common-util/src/main/java/com/sun/enterprise/deploy/shared/ArchiveFactory.openArchive()
> which calls prepareArchiveURI().
> The method call path.toURI(). This is where the URI is getting
> generated as
> "/Users/pramodgopinath/work_related/jruby_for_V3/samples/hello/"
>
> This causes the code in
> ./common/common-util/src/main/java/com/sun/enterprise/deploy/shared/AbstractArchiveHandler.getDefaultApplicationName()
> to be executed. The culprit is the code :
>
> / name = path.substring(path.lastIndexOf('/') + 1);
> if (name.lastIndexOf(".")!=-1) {
> name = name.substring(0, name.lastIndexOf("."));
> }/
>
> which in this case would return a value of "".
>
> Thanks
> Pramod Gopinath
>
>
>
>
>
>
> Tim Quinn wrote:
>> 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
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>