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