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
>