Mailing-List: contact issues-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cxf.apache.org
Date: Tue, 17 May 2011 09:49:47 +0000 (UTC)
From: "Albert Ruiz (JIRA)" <jira@apache.org>
To: issues@cxf.apache.org
Message-ID: 
 <1401446799.18624.1305625787417.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1664997800.15526.1305561467666.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (CXF-3523) Ability to force java2wsdl approach
 for javaws:client even if wsdlLocation is set (via populateFromClass
 property or, at least, custom jaxws:serviceFactory) when using spring
 integration
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/CXF-3523?page=3Dcom.atlassian.j=
ira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D130346=
57#comment-13034657 ]=20

Albert Ruiz commented on CXF-3523:
----------------------------------

I think yesterday I was a little ofuscated by ServiceContractResolverRegist=
ry (until I found the workaround to server endpoints setting populateFromCl=
ass=3Dtrue although wsdlLocation being set because of ServiceContractResolv=
er on client endpoints on same context).=20

Now that I have thought it over again, I see that on client side it has no =
sense to do java2wsdl if ServiceContractResolver is present; wsdlLocation i=
s not the actual location of the server endpoint, just the wsdl. So if I'm =
using a ServiceContractResolverRegistry on client endpoints (no matter my o=
nly reason is to know the server address), the reasonable thing is to proce=
ss this wsdl completely and don't build service model from java.

=C2=BFis this argumentation correct? (Sorry for the lost time :( ).

Right now, my conclusion is that the issue is another one (althought there'=
s a workaround as i said). There's the need to be able to configure Service=
ContractResolverRegistry to only work with client endpoints and not server =
ones (not in all cases, just the ability to configure it). Otherwise, a dea=
d end can be reached when using java2wsdl for server endpoints:
   1.- A ServiceContractResolverRegistry is configured for client endpoints=
 to get wsdl location.
   2.- There are server endpoints on same application context.
   3.- This same ServiceContractResolverRegistry will be used during initia=
lization of server endpoints on same application context. This initilializa=
tion will fail if the registry already has the wsdl location statically for=
 these endpoints (other client endpoints for other applications may need th=
is wsdl location), because ServiceContractResolver will set wsdlLocation an=
d service model building from wsdl will be triggered. This building will fa=
il, since wsdl doesn't exist yet! (it's what server endpoint should be init=
ializing at this moment!).
  As I said, the workaround for me is to set a custom serviceFactory with p=
opulateFromClass=3Dtrue. But this is not really what should be done, since =
I think no ServiceContractResolver at all should be used for server endpoin=
ts in this case (I only want it for client endpoints).

=C2=BFis this correct? =C2=BFdo i close this issue and open a new one?

> Ability to force java2wsdl approach for javaws:client even if wsdlLocatio=
n is set (via populateFromClass property or, at least, custom jaxws:service=
Factory) when using spring integration
> -------------------------------------------------------------------------=
---------------------------------------------------------------------------=
--------------------------------------
>
>                 Key: CXF-3523
>                 URL: https://issues.apache.org/jira/browse/CXF-3523
>             Project: CXF
>          Issue Type: Improvement
>          Components: Configuration
>    Affects Versions: 2.2.12, 2.4, 2.3.4
>            Reporter: Albert Ruiz
>            Priority: Minor
>
> To put into context: There's "no way" (i think there's one using some spr=
ing 'tricks') of using java2wsdl with client endpoints along with ServiceCo=
ntractResolver functionality (to access an UDDI registry, for example). Whe=
n using ServiceContractResolver, the wsdlLocation property gets updated, an=
d this property is later used to determine the approach to use when initial=
izing the service model. The same occurs with server endpoints but, at leas=
t, a custom jaxws:serviceFactory can be configured with populateFromClass s=
et to true (this flag is checked when deciding how to initialize the model)=
.
> =C2=BFIs there a reason for jaxws:client not having the ability to pass a=
 custom serviceFactory like server does? If there's a good reason for that =
(it seems to me that maybe this is done voluntarily) =C2=BFcouldn't a popul=
ateFromClass property be added to jaxws:client and jaxws:server to handle t=
his when instantiating the default serviceFactory?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira