Thank you for the clarifications, Kathy. Are you saying that the 2.0 draft
of JAX-RPC discourages the use of doc/literal web services in general, or
only their use with DII?
-- Ryan
-----Original Message-----
From: kathy walsh [mailto:Kathleen.Walsh_at_Sun.COM]
Sent: Thursday, November 04, 2004 11:12 AM
To: users_at_jax-rpc.dev.java.net
Subject: Re: Correct client file
Ryan LeCompte wrote:
>Kathy,
>
>I compared your DII cient with mine, and it appears that the "fix" is
>where you modified the generated serializer registry code that was
>copied into the DII client. It looks like you are using the element
>name as opposed to the complex type name as the local part of the Qname
>("data" as opposed to "tData", which is how the serializer registry code is
generated by default):
>
>...
>{
> QName type = new QName("urn:com.test.webservice/types", "data");
> CombinedSerializer serializer = new
>customer_tests.dii_complex_doclit.client.TData_LiteralSerializer(type,
>"", DONT_ENCODE_TYPE);
> registerSerializer(mapping2,
>customer_tests.dii_complex_doclit.client.TData.class, type,
>serializer); }
>
>This appears to fix the problem.
>
Ryan-
Call.invokeOneWay() goes through the same code path as in the static stub
case- You are saying that it blocks? The difference may be in that with dii
with wsdl, JAXRPC-RI actually is building a dataStructure of the wsdl in
memory and attempting to build a dynamic serializer for the given parameter
types. In this case, the parameter type was a complex type which dii has
difficulty with- The fallback is that you need to register custom
serializers, which negates the portability benefit of using dii- This is why
we discourage the use of dii with complex types. In addition, as I mentioned
previously, dii was not intended for use with document(or rpc) literal xml,
at the time the JAXRPC 1.0 specification, use with soap encoding was the
intent.
As for the minimal change in registering the serializers in the client code,
dii creates dynamic serializers a bit differently the static case.
The dii runtime must traverse the data structure created from the wsdl and
use that data structure to create serializers that will correctly serialize
with the appropriate use/style in the wsdl. With use/style doc/lit or
rpc/literal, this is very difficult. The serializers created in memory will
be a bit different that in the static case.
Lastly, If you download the early draft of the JAXRPC 2.0 specification use
of literal is discouraged.
All that said, I agree that the best solution for you is to use static
stubs.
Please let me know if you have more questions, help- Kathy
> Thank you for taking the time to
>investigate this! I've actually decided to use a static stub based
>approach for my doc style web service, since static stubs still support
>one-way operations and do not block (which is what I was hoping to get
>with DII's Call.invokeOneWay). I don't see any advantage at this point
>of using DII over the static stub approach, since the benefits of
>one-way operations are still gained with static stubs, and I have control
over the WSDL definition.
>
>However, I think that through this exercise a couple points should be
noted.
>Firstly, it's a bit clumsy to have to copy/paste the generated
>serializer registry code into the DII client, and even worse to have to
>modify it. It appears as though DII should be enhanced to support this
>(under the covers), since this isn't documented in the tutorials/books that
I've read.
>Furthermore, the generated code can change from one version to another
>of JAX-RPC, so having to rely on this hand-edited generated code is
>probably not a very good long term solution.
>
>Again, thank you for spending time investigating this matter.
>
>Regards,
>-- Ryan
>
>
>-----Original Message-----
>From: kathy walsh [mailto:Kathleen.Walsh_at_Sun.COM]
>Sent: Wednesday, November 03, 2004 8:51 PM
>To: 'Ryan LeCompte'
>Cc: users_at_jax-rpc.dev.java.net
>Subject: Correct client file
>
>Ryan-
>Here is the correct file-
>The serializers are the same-
>
>Verify that it works in your environment and let me know- kathy
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe_at_jax-rpc.dev.java.net
>For additional commands, e-mail: users-help_at_jax-rpc.dev.java.net
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_jax-rpc.dev.java.net
For additional commands, e-mail: users-help_at_jax-rpc.dev.java.net
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_jax-rpc.dev.java.net
For additional commands, e-mail: users-help_at_jax-rpc.dev.java.net