Nico Rossi

Greenhorn
+ Follow
since Jun 12, 2011
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
(keep public parts private until JForum day)
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt
Moderation Tools

Recent posts by Nico Rossi

Hi, I found the answers on this specification (JSR-109):

http://jcp.org/aboutJava/communityprocess/mrel/jsr109/index3.html

It describes how Jax-WS works on JavaEE:


4.1 Client Programming model (page 18)

a client must assume that the methods of a Web service have no state that is persistent across multiple Web service method invocations. A client can treat the Web service implementation as stateless.

The client has no control over the life cycle of the Web service implementation on the server. A client does not create or destroy instances of a Web service, which is referred to as a Port. The client only accesses the Port. The life cycle of the Ports, or instances of a Web service implementation, are managed by the run-time that hosts the Web service. A Port has no identity. This means that a client cannot compare a Port to other Ports to see if they are the same or identical, nor can a client access a specific Port instance.


5.3.2.4.2 Web container programming model for JAX-WS (page 42)

A Service Implementation must be a stateless object. A Service Implementation Bean must not save client specific state across method calls either within the bean instance’s data members or external to the instance. A container may use any bean instance to service a request.


5.3.4 Service Implementation Bean Life Cycle (page 43)

Before a request can be serviced, the container must instantiate a Service Implementation Bean and ready it for method requests.
A container may pool method ready instances of a Service Implementation Bean and dispatch a method request on any instance in a method ready state.



Moreover, the specification states that JavaEE must not use the Endpoint class to publish a webservice:


5.3.3 Publishing Endpoints – javax.xml.ws.Endpoint (page 43)

JAX-WS provides functionality for creating and publishing Web Service endpoints dynamically using javax.xml.ws.Endpoint API. The use of this functionality is considered non-portable in a managed environment. It is required that both the Servlet and the EJB container disallow the publishing of the Endpoint dynamically, by not granting the publishEndpoint security permission.

4 years ago

Hi all,
I'm studying Jax-WS specification in general and its implementation on Glassfish 3.1.2. I built a simple standard example where a jax-ws soap based web service is called from a jsp page by using the artifacts generated through wsimport (the webservice and the jsp page are both deployed on Glassfish in the same EAR but in 2 different wars).

Everything works as expected but I have a question: looking at the application log, it seems that Glassfish creates a new instance of the webservice each time it is called. I would like to know where Java offically defines how a web container should manage webservice instances and if developers can customize this behavior.

I read jax-ws 2.1 specification here
Jax WS 2.1 Spec

but I found only a clue when speaking about how to publish a webservice using the Endpoint class by hand (section 5.2.2 "Publishing", page 69):


An endpoint consists of an object that acts as the Web service implementation (called here implementor) plus some configuration information...

An Endpoint will be typically invoked to serve concurrent requests, so its implementor should be written so as to support multiple threads. The synchronized keyword may be used as usual to control access to critical sections of code. For finer control over the threads used to dispatch incoming requests, an application can directly set the executor to be used...


This note is present even in Jax-WS 2.2 specification (used by Glassfish 3).

Actually, if I build a webservice using only JavaSE 7 (which includes Jax-WS 2.2), this description is true because there is only one instance of the webservice. Is there any reason why JavaEE doesn't follow this policy?

Thanks a lot for your help,

Nico
4 years ago
Hi Tim, ok Jsf applies its mechanisms to make dataTables easy to use, I see.
There is only one thing that I don't manage to understand: why they are not request parameters exactly? When I spoke about request parameters I always wanted to refer to these 6 key/value pairs

myForm:tablePersone:0:in1 Mario
myForm:tablePersone:0:in2 Rossi
myForm:tablePersone:1:in1 Enrico
myForm:tablePersone:1:in2 Verdi
myForm:tablePersone:2:in1 Gino
myForm:tablePersone:2:in2 Gialli

They are inside an html form and are added to the body of an http post when the form is submitted. I think this makes them request parameters.

Thanks,
Nico
4 years ago
JSF
Hi Tim, thanks a lot for the complete explanation on how jsf build its views.
Just a last question on request parameters handling: when I said "the request parameters of the table" I meant the request parameters generated by the presence of input fields inside the html table rendered from an h:dataTable.

This is what the http post contains when I "submit the previous table" (from tab "net" of Firefox):

myForm:tablePersone:0:in1 Mario
myForm:tablePersone:0:in2 Rossi
myForm:tablePersone:1:in1 Enrico
myForm:tablePersone:1:in2 Verdi
myForm:tablePersone:2:in1 Gino
myForm:tablePersone:2:in2 Gialli


I added some ids to the previous table but the structure is exactly the same:

myform is the id of the h:form
in1 is the id of the first inputText in the table (STATO)
in2 is the id of the second inputText in the table (CODICE)

I think that jsf has to store these values somewhere during the apply request values phase and the presence of an index in the name of the 6 parameters seems to "remember" to jsf how many rows are in the table.
Is it possible to know what happens to these 6 request parameters or I'm too paranoid considering that the main purpose of a mvc framework is to forget about http posts (as your last sentence said).

Thanks again
4 years ago
JSF
Hi Tim, could you tell me how a <h:dataTable> is added to the jsf view exactly and what happens to the request parameters of the table during the apply request values phase? Thanks a lot
4 years ago
JSF
Hi all, I have a question on how JSF 1.2 manages DataTable exactly. Consider this table (suppose that tableList.persone has 3 items):



I read that jsf iterates over the items of the list during the render response phase, in fact, "item" is not available when jsf builds the view.
Does it means that jsf does not duplicate the content of the table for each item in the list when creating the tree component?
In the table above, each row has 2 inputText. If jsf does not create a couple of inputText objects for each row, how jsf handles all the 6 request parameters when the form is submitted (in particular during the apply request values phase).

Thanks a lot,
Nico
4 years ago
JSF
Hi, I found this note on the book when speaking about how to generate the wsdl with wsgen:

"In the current Metro release, the Endpoint publisher automatically generates the wsgen artifacts if the programmer does not..... In time this convenient feature of the Metro release will make its way into core Java so that the wsgen step in document-style services can be avoided."

I think this is what happens with current versions of Jax-WS.
4 years ago
Hi all, I'm studying how to build and publish Jax-WS web services using only javaSE 6 or later. The book I'm reading says that, for document-style ws, you need to call the wsgen utility before publishing the ws in order to create the java classes that act as wrappers for the data in the request and response messages. However, I tried to publish the ws without calling wsgen and everything seems to work fine: Endpoint.publish publishes the ws instance and the request and response messages are wrapped as expected (I'm using SoapUI to test the WS).

The version of my jdk is 1.7 and the jax-ws version is 2.2.4. The book speaks about jax-ws 2.1. Is it possible that jax-ws 2.2 automatically calls wsgen or cretaes the wrappers on the fly?

Thanks a lot for your help.

Nico
5 years ago
I downloaded jax-ws 2.0 specification and it disproves what the book I'm reading says:

"An endpoint consists of an object that acts as the Web service implementation (called here implementor) plus some configuration information ... An Endpoint will be typically invoked to serve concurrent requests, so its implementor should be written so as to support multiple threads. The synchronized keyword may be used as usual to control access to critical sections of code. For finer control over the threads used to dispatch incoming requests, an application can directly set the executor to be used"

(http://jcp.org/aboutJava/communityprocess/final/jsr224/index.html, section 5.2.2 "Publishing", page 67)

The book speaks about jax-ws 2.1 but I didn't manage to download that version of the specification. Anyway, jax-ws 2.2 specification (current version) confirms the concurrent nature of the Endpoint class (it contains the same sentences as above).

I don't know what the author of the book means exactly.
5 years ago
Hi all,
I'm starting studying java web services with JAX WS. The first chapter of the book I'm reading shows how to build and publish a simple jax ws web service using only java SE. In particular, the web service is published through the Endpoint class. After publishing the web service, the author specifies that

"Out of the box, the Endpoint publisher handles one client request at a time ... if the processing of a given request should hang, then all other client requests are effectively blocked. An example at the end of this chapter shows how Endpoint can handle requests concurrently so that one hung request does not block the others."

To see this, I tried to send two requests to a web service with 2 threads. Here is the code:



If I start MyClient class, the thread called "miao" sends its request and then goes to sleep. However, the thread called "bau" does not wait for the previous request and its request is immediately satisfied.

I get the same result if I call the WS with SoapUI using 2 different request instances.

Am I missing something? Can java threads be used to simulate multiple requests?

Thanks a lot for your help,
Nico
5 years ago

Hi Tim, thanks a lot, everything is clear now. The Force is very strong in you. If you plan to visit Italy, let me know.

Bye.
5 years ago
JSF
Hi Tim, thanks a lot for your help. Just a quick clarification about the second point:

"...the JSF pages are not converted into servlets as far as the overall processing is concerned..."

means that
jsf pages are not converted into servlets at all
or that
jsf pages are translated into servlets at the end of jsf lifecycle

I'm sorry but I'm still learning English.
Thanks again,
Nico
5 years ago
JSF
Hi all, I would like to ask 2 questions on JSF 1.2 lifecycle:

1) All the requests for jsf resources are managed by the FacesServlet whose service method starts the lifecycle for the requested resource. So, for each request:

  • the web container creates a new thread to serve the request
  • the thread calls the service method of the FacesServlet which starts jsf lifecycle
  • the whole lifecylce takes place into the thread

  • Is this correct?

    2) JSF pages are translated into servlet at a certain point of the lifecycle or not? Talking about the Render Response Phase, the JavaEE 5 tutorial says: "During this phase, the JavaServer Faces implementation delegates authority for rendering the page to the JSP container if the application is using JSP pages ..... the components will render themselves as the JSP container traverses the tags in the page."

    Does it mean that the response is constructed one tag at a time while the jsp container traverses the whole view without the need to translate the page into a servlet and call the resulting jsp_service method (as for standard jsp pages)?

    Thanks a lot for your help,

    Nico
    5 years ago
    JSF
    Hi Leo, thanks for your advise but I don't think that the problem is the
    non-execution of the 'Update Model Values' and 'Invoke Apllication' phases
    after an uncorrect submit of the form. Let me explain: if the user submits
    the form without filling the inputText, validation fails and JSF jumps to
    the Render Response phase displaying the values introduced by the user
    (correct or not). That's correct and that's what happens. Now, if the user
    changes the value of the first selectOneMenu, RichFaces submits the form
    again thanks to the a4j:support tag but, in this case, JSF lifecycle is
    completely executed because the attribute 'ajaxSingle = true' tells JSF
    to ignore all the other input fields of the form (including the required
    input text). As a consequence, the actionListener attached to the first
    selectOneMenu is called during the Invoke Application Phase forcing the
    values of the second and third selectOneMenu to null. However, JSF keeps
    displaying the values introduced before the failure of the validation phase
    (even if the properties of the backing bean contain 'null').
    What it is strange to me is that JSF stops calling the get methods of the
    second and the third selectOneMenu during the Render Response phase after
    Validation phase fails.
    6 years ago
    JSF
    Hi all,
    I would like to ask some help in understanding a particular behaviour that JSF shows when Validation Phase
    fails.
    I'm using:

    - Tomcat 7.0.2
    - JSF 1.2_12
    - RichFaces 3.3.3

    Problem description.
    I wrote a form with 4 input fields: an inputText and 3 selectOneMenu. The inputText is required
    while the selectOneMenus don't require any validation. Attached to the first selectOneMenu (row 32),
    is an a4j:support tag so that, whenever the change event is fired, the list of items of the second
    and the third selectOneMenu (row 44 and 58) are correctly filled. In particular, after loading
    the two lists of items, the method forces the value of the second and the third selectOneMenu
    to null. This mechanism seems to work fine until I submit the form without filling the input
    text: as expected, JSF validation fails but when I change the value of the first selectOneMenu,
    the page keeps displaying the values specified before JSF validation failed for the second and the
    third selectOneMenu (note that the actionListener is still called and the values of the second and
    the third selectOneMenu are still forced to null).

    Since I'm using a simple PhaseListener, I noticed the following:
    before JSF validation fails, every time I change the value of the first selectOneMenu, JSF life
    cycle always calls the get method for the second and the third selectOneMenu during the Render
    Response Phase. In this way, JSF is able to "see" that those values have been set to null during
    the Invoke Application Phase.
    After validation fails, JSF stops calling those getters when I change the value of the first
    selectOneMenu.

    I hope my explanation was clear enough, thaks a lot for your help.

    Regards,
    Nico






    6 years ago
    JSF