[GLASSFISH-574] Web Service Endpoint Specification Needs Improvement Created: 13/Apr/06  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: web_services
Affects Version/s: 9.0pe
Fix Version/s: not determined

Type: Improvement Priority: Critical
Reporter: khookguy Assignee: mikeg
Resolution: Unresolved Votes: 3
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 574

 Description   

See also this related issue: 482

The specification of web service endpoint in Glassfish needs to be rationalized
and professionalized. First of all, the default endpoint URL assigned to a web
service varies depending on whether you deploy it as an EJB endpoint or a
serlvet endpoint. There should be no difference. The default URL for a WAR
deployment is:

http://<hostname[:port]>/<web module>/<simple name of the Service Class>

Whereas, when using a EJB-JAR, it is:

http://<hostname[:port]>/<simple name of the Service Class> + "Service"/<simple
name of the Service Class>

In the WAR case, the module name is part of the URL, and in the EJB-JAR case, it
is not. I believe that the default behavior in both cases should look like the
EJB-JAR case. The file name of the web module should be irrelevant to deployment.

Secondly, the hostname selected by GlassFish is something of a mystery and is
outside the deployer's control. See this thread fron the SDN forum:
http://forum.java.sun.com/thread.jspa?threadID=725485&tstart=0

There needs to be a mechanism by which the deployer can specify the hostname
that gets used in the WSDL (other then providing the entire WSDL file). This is
a real showstopper problem if you need to publish a WSDL that works outside a
firewall and GlassFish is using an internal hostname that can't be resolved on
the WWW.

Thirdly, there needs to be a better way to specify a custom context-root for the
EJB-JAR deployment scenario. When deploying a WAR, you can use the asadmin
deploy command with the --contextroot flag. However, this isn't applicable in
the EJB-JAR case. For the EJB-JAR, it seems that the only way to do it is to
provide a sun-ejb-jar.xml deployment descriptor with an endpoint-address-uri set
to the context-root desired. In this case, I think that the --context-root flag
should also work for the EJB-JAR case, and the value provided by the deployer
should be inserted into the internally generated sun-ejb-jar.xml by GlassFish at
deploy time.



 Comments   
Comment by khookguy [ 14/Apr/06 ]

Correction:

The default URL for a WAR deployment is:

http://<hostname[:port]>/<web module>/<simple name of the Service Class>
+ "Service"

Comment by tomo_ikeda [ 17/Apr/06 ]

About first point, I don't think that Web Module is irrelevant.
End Point Address should include the Web Module name.
Because, if there are two or more Service Implementation Beans with the same
name in different Web Modules, End Point Addresses conflict.
For EJB model, module name may be irrelevant.
But as long as we conform to the servlet specification of Java EE, the Web
Module name should be a part of the http URL address.
The most important thing is to avoid name collisions.
So, I think that the default End Point Address should be :
http://<hostname[:port]>/<Web Module name>/<fully qualified name of the Service
Class>
FYI, default Service Class name is Service Implementation Bean name + "Service".

Comment by khookguy [ 18/Apr/06 ]

Regarding module name, I agree that it is fine as the default context-root for
avoiding name collisions. However, I believe that there needs to be a
consistent means (across servlet and EJB endpoints) that allows the deployer to
specify a context-root. For many Web Services applications, it is desirable to
be able to specify the endpoint address of the service to have a URL that
conforms to naming standards (or is just easy to read) that have nothing to do
with the fact that it is deployed on a Java EE 5 container.

Comment by vijaysr [ 13/Mar/07 ]

Reassigning to Mike

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-482] Service Endpoint Address and Classes for Web Service Methods overlapping Created: 27/Mar/06  Updated: 15/Oct/12

Status: Open
Project: glassfish
Component/s: web_services
Affects Version/s: 9.0pe
Fix Version/s: not determined

Type: Improvement Priority: Minor
Reporter: tomo_ikeda Assignee: mikeg
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 482

 Description   

Hello!
My name is Tomohiro Ikeda.
I'm using GlassFish for Web Service in the web container (not in the EJB
container).
It is very useful and very easy for development and I will continue to use it.
But I found two problems in it.

First problem occurs in case that there are two (or more) Service Implementation
Beans that have the same name in different packages.
For example as below.
<a web module>
`-- WEB-INF
`-- classes

– pack01
`-- Class01 (Service Implementation Bean : pack01.Class01)
`-- pack02
`-- Class01 (Service Implementation Bean : pack02.Class01)
If these Service Implementation Beans have default WebService Annotation
(without "serviceName" value), their Service Endpoint Addresses overlap.
Because default name of the Service Class is simple name of the Service
Implementation Bean + "Service" and Endpoint Address is "http://<hostname[:port]
>/<web module>/<simple name of the Service Class>".
Therefore, the WSDL files generated automatically by the container overlap, and
one is overwritten with the other.
In this case, one Web Service is not available although it is present in Admin
Console page of GlassFish.
And Web Service name in Admin Console is sometime simple name of Service
Implementation Bean and sometime FQDN of one.
Of cource, we can avoid this problem by indicating serviceName in WebService
Annotation such as "pack01.Class01", but I think that it should work without
serviceName value.
Default value of serviceName is decided in JSR-181 and we can not change it, but
I think that Service Endpoint Address should include package information of the
Service Class.
Does it violate any specification ?

Second problem occurs in case that two (or more) Service Implementation Beans in
the same package have method with the same name.
For example as below.
<a web module>
`-- WEB-INF
`-- classes
`-- pack01

– Class01 (Service Implementation Bean : pack01.Class01)
`-- method01(.., ..)
`-- Class02 (Service Implementation Bean : pack01.Class02)
`-- method01()
Classes genarated automatically by the container for the Web Service Methods
overlap, and one is overwritten with the other.
In this case, cryptic exception occurs in the client side at the run time though
source files are successfully compiled.
And we cannot aboid this problem.
A method is unique in a class or interface, and I think that generated classes
for Web Service Methods should include information of the name of Service
Implementation Bean.
Does it violate any specification too?

These problems occur in the server side, and the developers in the client side
cannot know what happened and why does not it work.
If these problems are insoluble, I think that the container should reject
deployment with appropriate messages.

I hope you will take good care of this. Thank you.



 Comments   
Comment by vijaysr [ 27/Mar/06 ]

reassigning ownership

Comment by vijaysr [ 27/Mar/06 ]

started

Comment by vijaysr [ 27/Mar/06 ]

I am changing this as an enhancement to be implemented later. As of now for the
first case, user can use the serviceName attribute. For the second case, user
can use wsgen with customization and package these generated classes as part of
the WAR being deployed.

Comment by vijaysr [ 13/Mar/07 ]

reassigning to mike

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





Generated at Sat May 30 05:02:08 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.