Hi, Bill
>The spec may be overstating things here, or you may be misinterpreting
>them. The intent was not to prevent deployment tools from being to
>specify the name at deployment time, overriding the default or app-specified
>name. I would expect the --name argument to specify the application name.
>
>Let me reword the spec to make it clear that deployment tools are allowed
>to do this.
>
>
>
Thanks for the clarification. I will make the changes to not
differentiate application registration name and EE 6 application name.
For a related part of the spec:
=====================
The deployment tool must ensure that the application name is unique in
the application server instance. If the name is not unique, the
deployment tool may automatically choose a unique name or allow the
Deployer to choose a unique name, but must not fail the deployment. This
ensures that existing applications continue to be deployable.
====================
For the cases where the user does not specify --name, we will reassign
another (unique) name to the application.
But for the case where user explicitly specifies a --name option and the
name is in conflict with another name, what should be the expected
behavior?
I think we should still fail the deployment. If user specifies a name
explicitly, most likely they will depend on this name and it's not good
to just reassign a different name behind the scene. The error message of
the failed deployment would say something like "Application with name
XXX is already registered. Please pick a different name if this is a new
deployment. And please specify the force option if this is a
redeployment of the same application". I think this behavior is spec
compatible as this "allow the Deployer to choose a unique name". And
this behavior is more compatible with the behavior we currently have
(fail the deployment and ask user to use force option to redeploy
application). Please let me know what you think.
Thanks,
- Hong
>Hong Zhang wrote on 10/1/09 1:40 PM:
>
>
>>Hi, Ludo
>>
>>
>>>> I am not sure about the expected behavior on JWS part, Tim should
>>>>be able to the clarify it. What you saw with the global jndi name is
>>>>the expected behavior.
>>>>
>>>> There are two names involved here, the EE6 spec defined application
>>>>name and the glassfish specific application registration name:
>>>> a) The EE6 application name is the value of the application-name
>>>>element defined in application.xml. When this element is not present
>>>>in the application.xml, the default is derived from the path.
>>>>
>>>>
>>>Are you sure the EE 6 spec mentions this default from the path?
>>>
>>>
>>In EE 8.1.1:
>>
>> All Java EE modules have a name. The name can be explicitly set in
>>the
>> deployment descriptor for the module. If not set, the name of the
>>module is the
>> pathname of the module in the ear file with any filename extension
>>(.jar, .war, .rar)
>> removed, but with any directory names included. The name of a module
>>must be
>> unique within an application. If and only if the name is not unique
>>(e.g., because
>> two names are identical after removing different filename extensions) the
>> deployment tool may choose new unique names for any of the conflicting
>> modules; module names that do not conflict must not be changed. The
>>algorithm
>> for choosing unique names in such a case is product specific.
>>Applications that
>> depend on the names of their modules must ensure that their module
>>names are
>> unique.
>> For example, an application with this structure:
>> myapp.ear
>> inventory.jar
>> ui.war
>> has a default application name of "myapp", and defines two modules
>>with default names "inventory" and "ui".
>> An application with this structure:
>> bigapp.ear
>> ejbs
>> inventory.jar
>> accounts.jar
>> ui
>> store.war
>> admin.war
>> has a default application name of "bigapp", and defines four modules
>>with default names "ejbs/inventory", "ejbs/accounts", "ui/store", and
>>"ui/admin".
>>
>>
>>
>>>It is not the complete path, there, only the last part of the path
>>>that may be duplicated (in our case for NB), but all complete paths
>>>are different...
>>>/app1/gfdeploy
>>>/app2/gfdeploy
>>>etc are all different applications...
>>>Seem a GF bug imo.
>>>
>>>
>>In case of duplicates (which the above will be as the spec says path
>>name and not full path), a unique (product specific) name will be
>>assigned. This is actually the part I am working on right now (changes
>>will be soon checked in). In the scheme I implemented, it appends "_1",
>>"_2" etc to the original applicaition name until a unique name is found.
>>
>>- Hong
>>
>>
>>>
>>>
>>>>This is what's used in the global jndi name. And in your case, the
>>>>gfdeploy.
>>>> b) The glassfish impl specific application registration name will
>>>>also take consideration of the --name option which has the highest
>>>>precedence. When the --name option is not specified, we set it to the
>>>>EE6 application name. This in your case, the "Examples".
>>>>
>>>> Hope this clarifies things a bit.
>>>>
>>>>- Hong
>>>>
>>>>
>>>>>I am investigating
>>>>>http://www.netbeans.org/issues/show_bug.cgi?id=173440.
>>>>>
>>>>>The server integration for v3 uses directory deployment to help
>>>>>speed up development...
>>>>>
>>>>>The IDE creates a deployment directory called gfdeploy.
>>>>>
>>>>>It then does the equivalent of 'asadmin deploy --name <app name>
>>>>>gfdeploy'
>>>>>
>>>>>This deploys the app and in just about every place that we have
>>>>>looked at to date, the word <app name> is used when referring to the
>>>>>app... except the global jndi name [and JWS support]
>>>>>
>>>>>I double checked the situation, by running the deploy with asadmin
>>>>>against v3 b66 (2009-09-28)
>>>>>
>>>>>here is the result...
>>>>>
>>>>>bash-3.2$ date
>>>>>Thu Oct 1 10:52:42 PDT 2009
>>>>>bash-3.2$ /export/home/vkraemer/glassfishv3/glassfish/bin/asadmin
>>>>>deploy --name Examples /tmp/Examples/dist/gfdeploy
>>>>>
>>>>>Command deploy executed successfully.
>>>>>bash-3.2$ /export/home/vkraemer/glassfishv3/glassfish/bin/asadmin
>>>>>get '*.Examples.*'
>>>>>applications.application.Examples.availability-enabled=false
>>>>>applications.application.Examples.directory-deployed=true
>>>>>applications.application.Examples.enabled=true
>>>>>applications.application.Examples.location=file:/tmp/Examples/dist/gfdeploy/
>>>>>
>>>>>applications.application.Examples.name=Examples
>>>>>applications.application.Examples.object-type=user
>>>>>applications.application.Examples.engine.ear.sniffer=ear
>>>>>applications.application.Examples.module.Examples-app-client.jar.name=Examples-app-client.jar
>>>>>
>>>>>applications.application.Examples.module.Examples-app-client.jar.engine.appclient.sniffer=appclient
>>>>>
>>>>>applications.application.Examples.module.Examples-ejb.jar.name=Examples-ejb.jar
>>>>>
>>>>>applications.application.Examples.module.Examples-ejb.jar.engine.ejb.sniffer=ejb
>>>>>
>>>>>applications.application.Examples.module.Examples-ejb.jar.engine.security.sniffer=security
>>>>>
>>>>>applications.application.Examples.property.default-EE6-app-name=gfdeploy
>>>>>
>>>>>applications.application.Examples.property.isComposite=true
>>>>>applications.application.Examples.property.org.glassfish.ejb.container.application_unique_id=82209641347678208
>>>>>
>>>>>servers.server.server.application-ref.Examples.disable-timeout-in-minutes=30
>>>>>
>>>>>servers.server.server.application-ref.Examples.enabled=true
>>>>>servers.server.server.application-ref.Examples.lb-enabled=false
>>>>>servers.server.server.application-ref.Examples.ref=Examples
>>>>>servers.server.server.application-ref.Examples.virtual-servers=server
>>>>>
>>>>>Command get executed successfully.
>>>>>
>>>>>And here is the relevant log entries...
>>>>>
>>>>>[#|2009-10-01T10:52:59.160-0700|INFO|glassfish|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=31;_ThreadName=Thread-2;|Portable
>>>>>JNDI names for EJB HelloWorldBean :
>>>>>[java:global/gfdeploy/Examples-ejb/HelloWorldBean,
>>>>>java:global/gfdeploy/Examples-ejb/HelloWorldBean!com.sun.suned.sl355.examples.ejb.session.HelloWorldRemote]|#]
>>>>>
>>>>>
>>>>>[#|2009-10-01T10:52:59.160-0700|INFO|glassfish|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=31;_ThreadName=Thread-2;|Glassfish-specific
>>>>>(Non-portable) JNDI names for EJB HelloWorldBean :
>>>>>[com.sun.suned.sl355.examples.ejb.session.HelloWorldRemote,
>>>>>com.sun.suned.sl355.examples.ejb.session.HelloWorldRemote#com.sun.suned.sl355.examples.ejb.session.HelloWorldRemote]|#]
>>>>>
>>>>>
>>>>>[#|2009-10-01T10:52:59.301-0700|INFO|glassfish|javax.enterprise.system.container.appclient.org.glassfish.appclient.server.core|_ThreadID=31;_ThreadName=Thread-2;|ACDEPL103:
>>>>>Java Web Start services started for the app client
>>>>>Examples/Examples-app-client.jar (contextRoot:
>>>>>/gfdeploy/Examples-app-client)|#]
>>>>>
>>>>>[#|2009-10-01T10:52:59.347-0700|INFO|glassfish|javax.enterprise.system.tools.admin.org.glassfish.server|_ThreadID=31;_ThreadName=Thread-2;|Deployment
>>>>>of Examples done is 4,313 ms|#]
>>>>>
>>>>>It looks like there may be a similar issue with the Java Web Start
>>>>>support.
>>>>>
>>>>>I also checked what happens when the user uses directory deployment
>>>>>for an EJB jar. In this case the directory has the name jar... but
>>>>>the global JNDI name appears to use the value from --name....
>>>>>
>>>>>vbk
>>>>>
>>>>>
>>>>>
>>>>>---------------------------------------------------------------------
>>>>>To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>>>For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>>
>>>>>
>>>>>
>>>>---------------------------------------------------------------------
>>>>To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>>For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>
>>>>
>>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>
>>>
>>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>>
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>
>
>