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
>