You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Christian Vest Hansen <ka...@gmail.com> on 2007/12/03 11:04:27 UTC
configurability of published soap:address location on jaxws endpoints
Hi,
I'm trying to make it possible to configure the published soap:address
location in the jaxws generated WSDLs.
>From a spring point of view, I'm trying to make this:
(beans.xml....)
<jaxws:endpoint id="publishedEndpointUrl"
implementor="#greeter"
address="http://localhost:8080/publishedEndpointUrl"
publishedEndpointUrl="http://cxf.apache.org/GreeterEndpoint"/>
(....)
Do this:
(http://localhost:8080/publishedEndpointUrl?wsdl....)
<wsdl:service name="GreeterService">
<wsdl:port binding="tns:GreeterServiceSoapBinding" name="GreeterPort">
<soap:address location="http://cxf.apache.org/GreeterEndpoint"/>
</wsdl:port>
</wsdl:service>
(....)
Right now, I'm trying to wrap my head around how the WSDL is generated
and how that is connected to the values in the EndpointImpl objects
that the jaxws:endpoint xml generates.
If you have any hints to that end, or other relevant information then
it would be greatly appreciated - I haven't worked with the CXF source
before and the docs on the wiki are still a bit sparse in this regard.
Thanks!
--
Venlig hilsen / Kind regards,
Christian Vest Hansen.
Re: configurability of published soap:address location on jaxws endpoints
Posted by Daniel Kulp <dk...@apache.org>.
On Wednesday 12 December 2007, Christian Vest Hansen wrote:
> Cool,
>
> So this will be in the 2.1 scheduled[1] in three days?
>
> [1]: http://incubator.apache.org/cxf/roadmap.html
Egads. We need to update that page. There isn't anyway 2.1 is going
to be ready in 3 days. We're pretty far from getting the jAX-WS 2.1
tck passing.
This could make it for 2.0.4 since it's a pretty straightforward change.
We really haven't talked about doing a 2.0.4 though. My gut feeling
says it's too late to do one this year due to holidays and vacations and
such. Getting the required IPMC votes could be really tough. I've
put a preliminary date on that page to Jan 15, but I suppose if everyone
thinks one is needed sooner, we could try.
Dan
>
> On 12/12/07, Willem Jiang <ni...@iona.com> wrote:
> > Hi Christian,
> >
> > The testPublishedEndpointUrl can be passed in my workspace.
> > You should check your class path (or use mvn -Psetup.eclipse to
> > create a new workspace) , maybe it is out of date :)
> >
> > FYI I just committed your patch .
> >
> > Thanks,
> >
> > Willem.
> >
> > Christian Vest Hansen wrote:
> > > Hi Willem,
> > >
> > > Ok. I have tried to move (reimplement, really) the test in the
> > > systest module myself, but I can't figure out how to configure it
> > > properly - keep getting a 'no such operation' whenever I request
> > > the wsdl. Oh well... you can probably write the systest better
> > > than I can anyway.
> > >
> > > :-)
> > >
> > > On 12/11/07, Jiang, Ning (Willem) <Ni...@iona.com> wrote:
> > >> Hi Christian,
> > >>
> > >> I just checked the code , the real reason is jaxws front end
> > >> module's pom.xml does not include the http transport module.
> > >> I will move the SpringBeansTest.testPublishedEndpointUrl test
> > >> code to the systest module.
> > >>
> > >> Willem.
> > >>
> > >> -----Original Message-----
> > >> From: Jiang, Ning (Willem) [mailto:Ning.Jiang@iona.com]
> > >> Sent: Tue 12/11/2007 21:29
> > >> To: cxf-dev@incubator.apache.org; cxf-dev@incubator.apache.org
> > >> Subject: RE: configurability of published soap:address location
> > >> on jaxws endpoints
> > >>
> > >>
> > >> Hi Christian,
> > >>
> > >> I will take care it :)
> > >> It likes like you do not set the right bus for the
> > >> JaxWsServerFactoryBean.
> > >>
> > >> Willem.
> > >>
> > >> -----Original Message-----
> > >> From: Christian Vest Hansen [mailto:karmazilla@gmail.com]
> > >> Sent: Tue 12/11/2007 18:38
> > >> To: cxf-dev@incubator.apache.org
> > >> Subject: Re: configurability of published soap:address location
> > >> on jaxws endpoints
> > >>
> > >> I've slept on it and ...
> > >>
> > >>> Even though the test seems to (sometimes) work with the
> > >>> JaxWsServerFactoryBean, I've been unable to prove to myself that
> > >>> a spring-configured jaxws:endpoint works aswell due to #2, so I
> > >>> presume that part dosn't work.
> > >>
> > >> ... is no longer an issue. Turns out the little test project I
> > >> created was borked and included two versions of CXF - no wonder
> > >> it didn't work. Plus, the patch seems to work as expected in this
> > >> test project now that it's dependencies and deployment is fixed.
> > >>
> > >> So this is a good thing, however mvn test still fails with a
> > >> "Could not find destination factory for transport
> > >> http://schemas.xmlsoap.org/soap/http" message, while eclipse lets
> > >> the test pass. I wonder what the difference is.
> > >>
> > >>
> > >> PS.
> > >>
> > >>> I've created a JIRA
> > >>
> > >> ... but forgot the link. Here it is:
> > >> https://issues.apache.org/jira/browse/CXF-1279
> > >>
> > >> On 12/10/07, Christian Vest Hansen <ka...@gmail.com> wrote:
> > >>> I've created a JIRA for this feature and attached a preliminary
> > >>> patch to it that I'de like someone to look at and comment on
> > >>> (I'm sure there are numerous things to point out).
> > >>>
> > >>> The patch has a number of issues that I'm currently stuck on:
> > >>> #1. The SpringBeansTest.testPublishedEndpointUrl runs fine in
> > >>> Eclipse but breaks in mvn test (this also breaks the build).
> > >>> #2. The changes to jaxws.xsd dosn't seem to have any effect
> > >>> outside the confines of JUnit (this breaks war-file deployment).
> > >>> #3. I've had to add the publishedEndpointUrl property to not
> > >>> only EndpointImpl, but also AbstractEndpointFactory, and I
> > >>> wonder if it needs to be added elsewhere.
> > >>>
> > >>> Even though the test seems to (sometimes) work with the
> > >>> JaxWsServerFactoryBean, I've been unable to prove to myself that
> > >>> a spring-configured jaxws:endpoint works aswell due to #2, so I
> > >>> presume that part dosn't work.
> > >>>
> > >>> On 12/5/07, Willem Jiang <ni...@iona.com> wrote:
> > >>>> Jim Ma wrote:
> > >>>>>> Is there a specific reason for using jaxws:properties as
> > >>>>>> oppose to a first class attribute? Because I already
> > >>>>>> implemented the attribute...
> > >>>>>>
> > >>>>>> :p
> > >>>>>
> > >>>>> That's cool . There is no specific reason for that , I just
> > >>>>> think it's the simple way to
> > >>>>> do that .. :)
> > >>>>
> > >>>> I think in this case , you do not need to change the
> > >>>> jaxws.xsd[1] and the EndpointDefinitionParser[2] to consume a
> > >>>> new attribute.
> > >>>>
> > >>>>
> > >>>> [1]https://svn.apache.org/repos/asf/incubator/cxf/trunk/rt/fron
> > >>>>tend/jaxws/src/main/resources/schemas/jaxws.xsd
> > >>>> [2]https://svn.apache.org/repos/asf/incubator/cxf/trunk/rt/fron
> > >>>>tend/jaxws/src/main/java/org/apache/cxf/jaxws/spring/EndpointDef
> > >>>>initionParser.java
> > >>>>
> > >>>>
> > >>>> Willem.
> > >>>
> > >>> --
> > >>> Venlig hilsen / Kind regards,
> > >>> Christian Vest Hansen.
> > >>
> > >> --
> > >> Venlig hilsen / Kind regards,
> > >> Christian Vest Hansen.
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
daniel.kulp@iona.com
http://www.dankulp.com/blog
Re: configurability of published soap:address location on jaxws endpoints
Posted by Christian Vest Hansen <ka...@gmail.com>.
Cool,
So this will be in the 2.1 scheduled[1] in three days?
[1]: http://incubator.apache.org/cxf/roadmap.html
On 12/12/07, Willem Jiang <ni...@iona.com> wrote:
> Hi Christian,
>
> The testPublishedEndpointUrl can be passed in my workspace.
> You should check your class path (or use mvn -Psetup.eclipse to create a
> new workspace) , maybe it is out of date :)
>
> FYI I just committed your patch .
>
> Thanks,
>
> Willem.
>
> Christian Vest Hansen wrote:
> > Hi Willem,
> >
> > Ok. I have tried to move (reimplement, really) the test in the systest
> > module myself, but I can't figure out how to configure it properly -
> > keep getting a 'no such operation' whenever I request the wsdl. Oh
> > well... you can probably write the systest better than I can anyway.
> > :-)
> >
> >
> >
> > On 12/11/07, Jiang, Ning (Willem) <Ni...@iona.com> wrote:
> >
> >> Hi Christian,
> >>
> >> I just checked the code , the real reason is jaxws front end module's pom.xml
> >> does not include the http transport module.
> >> I will move the SpringBeansTest.testPublishedEndpointUrl test code to
> >> the systest module.
> >>
> >> Willem.
> >>
> >> -----Original Message-----
> >> From: Jiang, Ning (Willem) [mailto:Ning.Jiang@iona.com]
> >> Sent: Tue 12/11/2007 21:29
> >> To: cxf-dev@incubator.apache.org; cxf-dev@incubator.apache.org
> >> Subject: RE: configurability of published soap:address location on jaxws endpoints
> >>
> >>
> >> Hi Christian,
> >>
> >> I will take care it :)
> >> It likes like you do not set the right bus for the JaxWsServerFactoryBean.
> >>
> >> Willem.
> >>
> >> -----Original Message-----
> >> From: Christian Vest Hansen [mailto:karmazilla@gmail.com]
> >> Sent: Tue 12/11/2007 18:38
> >> To: cxf-dev@incubator.apache.org
> >> Subject: Re: configurability of published soap:address location on jaxws endpoints
> >>
> >> I've slept on it and ...
> >>
> >>
> >>> Even though the test seems to (sometimes) work with the
> >>> JaxWsServerFactoryBean, I've been unable to prove to myself that a
> >>> spring-configured jaxws:endpoint works aswell due to #2, so I presume
> >>> that part dosn't work.
> >>>
> >> ... is no longer an issue. Turns out the little test project I created
> >> was borked and included two versions of CXF - no wonder it didn't
> >> work. Plus, the patch seems to work as expected in this test project
> >> now that it's dependencies and deployment is fixed.
> >>
> >> So this is a good thing, however mvn test still fails with a "Could
> >> not find destination factory for transport
> >> http://schemas.xmlsoap.org/soap/http" message, while eclipse lets the
> >> test pass. I wonder what the difference is.
> >>
> >>
> >> PS.
> >>
> >>> I've created a JIRA
> >>>
> >> ... but forgot the link. Here it is:
> >> https://issues.apache.org/jira/browse/CXF-1279
> >>
> >>
> >> On 12/10/07, Christian Vest Hansen <ka...@gmail.com> wrote:
> >>
> >>> I've created a JIRA for this feature and attached a preliminary patch
> >>> to it that I'de like someone to look at and comment on (I'm sure there
> >>> are numerous things to point out).
> >>>
> >>> The patch has a number of issues that I'm currently stuck on:
> >>> #1. The SpringBeansTest.testPublishedEndpointUrl runs fine in Eclipse
> >>> but breaks in mvn test (this also breaks the build).
> >>> #2. The changes to jaxws.xsd dosn't seem to have any effect outside
> >>> the confines of JUnit (this breaks war-file deployment).
> >>> #3. I've had to add the publishedEndpointUrl property to not only
> >>> EndpointImpl, but also AbstractEndpointFactory, and I wonder if it
> >>> needs to be added elsewhere.
> >>>
> >>> Even though the test seems to (sometimes) work with the
> >>> JaxWsServerFactoryBean, I've been unable to prove to myself that a
> >>> spring-configured jaxws:endpoint works aswell due to #2, so I presume
> >>> that part dosn't work.
> >>>
> >>> On 12/5/07, Willem Jiang <ni...@iona.com> wrote:
> >>>
> >>>> Jim Ma wrote:
> >>>>
> >>>>>> Is there a specific reason for using jaxws:properties as oppose to a
> >>>>>> first class attribute? Because I already implemented the attribute...
> >>>>>> :p
> >>>>>>
> >>>>>>
> >>>>> That's cool . There is no specific reason for that , I just think
> >>>>> it's the simple way to
> >>>>> do that .. :)
> >>>>>
> >>>>>
> >>>> I think in this case , you do not need to change the jaxws.xsd[1] and the
> >>>> EndpointDefinitionParser[2] to consume a new attribute.
> >>>>
> >>>>
> >>>> [1]https://svn.apache.org/repos/asf/incubator/cxf/trunk/rt/frontend/jaxws/src/main/resources/schemas/jaxws.xsd
> >>>> [2]https://svn.apache.org/repos/asf/incubator/cxf/trunk/rt/frontend/jaxws/src/main/java/org/apache/cxf/jaxws/spring/EndpointDefinitionParser.java
> >>>>
> >>>>
> >>>> Willem.
> >>>>
> >>>>
> >>> --
> >>> Venlig hilsen / Kind regards,
> >>> Christian Vest Hansen.
> >>>
> >>>
> >> --
> >> Venlig hilsen / Kind regards,
> >> Christian Vest Hansen.
> >>
> >>
> >>
> >>
> >
> >
> >
>
--
Venlig hilsen / Kind regards,
Christian Vest Hansen.
Re: configurability of published soap:address location on jaxws endpoints
Posted by Willem Jiang <ni...@iona.com>.
Hi Christian,
The testPublishedEndpointUrl can be passed in my workspace.
You should check your class path (or use mvn -Psetup.eclipse to create a
new workspace) , maybe it is out of date :)
FYI I just committed your patch .
Thanks,
Willem.
Christian Vest Hansen wrote:
> Hi Willem,
>
> Ok. I have tried to move (reimplement, really) the test in the systest
> module myself, but I can't figure out how to configure it properly -
> keep getting a 'no such operation' whenever I request the wsdl. Oh
> well... you can probably write the systest better than I can anyway.
> :-)
>
>
>
> On 12/11/07, Jiang, Ning (Willem) <Ni...@iona.com> wrote:
>
>> Hi Christian,
>>
>> I just checked the code , the real reason is jaxws front end module's pom.xml
>> does not include the http transport module.
>> I will move the SpringBeansTest.testPublishedEndpointUrl test code to
>> the systest module.
>>
>> Willem.
>>
>> -----Original Message-----
>> From: Jiang, Ning (Willem) [mailto:Ning.Jiang@iona.com]
>> Sent: Tue 12/11/2007 21:29
>> To: cxf-dev@incubator.apache.org; cxf-dev@incubator.apache.org
>> Subject: RE: configurability of published soap:address location on jaxws endpoints
>>
>>
>> Hi Christian,
>>
>> I will take care it :)
>> It likes like you do not set the right bus for the JaxWsServerFactoryBean.
>>
>> Willem.
>>
>> -----Original Message-----
>> From: Christian Vest Hansen [mailto:karmazilla@gmail.com]
>> Sent: Tue 12/11/2007 18:38
>> To: cxf-dev@incubator.apache.org
>> Subject: Re: configurability of published soap:address location on jaxws endpoints
>>
>> I've slept on it and ...
>>
>>
>>> Even though the test seems to (sometimes) work with the
>>> JaxWsServerFactoryBean, I've been unable to prove to myself that a
>>> spring-configured jaxws:endpoint works aswell due to #2, so I presume
>>> that part dosn't work.
>>>
>> ... is no longer an issue. Turns out the little test project I created
>> was borked and included two versions of CXF - no wonder it didn't
>> work. Plus, the patch seems to work as expected in this test project
>> now that it's dependencies and deployment is fixed.
>>
>> So this is a good thing, however mvn test still fails with a "Could
>> not find destination factory for transport
>> http://schemas.xmlsoap.org/soap/http" message, while eclipse lets the
>> test pass. I wonder what the difference is.
>>
>>
>> PS.
>>
>>> I've created a JIRA
>>>
>> ... but forgot the link. Here it is:
>> https://issues.apache.org/jira/browse/CXF-1279
>>
>>
>> On 12/10/07, Christian Vest Hansen <ka...@gmail.com> wrote:
>>
>>> I've created a JIRA for this feature and attached a preliminary patch
>>> to it that I'de like someone to look at and comment on (I'm sure there
>>> are numerous things to point out).
>>>
>>> The patch has a number of issues that I'm currently stuck on:
>>> #1. The SpringBeansTest.testPublishedEndpointUrl runs fine in Eclipse
>>> but breaks in mvn test (this also breaks the build).
>>> #2. The changes to jaxws.xsd dosn't seem to have any effect outside
>>> the confines of JUnit (this breaks war-file deployment).
>>> #3. I've had to add the publishedEndpointUrl property to not only
>>> EndpointImpl, but also AbstractEndpointFactory, and I wonder if it
>>> needs to be added elsewhere.
>>>
>>> Even though the test seems to (sometimes) work with the
>>> JaxWsServerFactoryBean, I've been unable to prove to myself that a
>>> spring-configured jaxws:endpoint works aswell due to #2, so I presume
>>> that part dosn't work.
>>>
>>> On 12/5/07, Willem Jiang <ni...@iona.com> wrote:
>>>
>>>> Jim Ma wrote:
>>>>
>>>>>> Is there a specific reason for using jaxws:properties as oppose to a
>>>>>> first class attribute? Because I already implemented the attribute...
>>>>>> :p
>>>>>>
>>>>>>
>>>>> That's cool . There is no specific reason for that , I just think
>>>>> it's the simple way to
>>>>> do that .. :)
>>>>>
>>>>>
>>>> I think in this case , you do not need to change the jaxws.xsd[1] and the
>>>> EndpointDefinitionParser[2] to consume a new attribute.
>>>>
>>>>
>>>> [1]https://svn.apache.org/repos/asf/incubator/cxf/trunk/rt/frontend/jaxws/src/main/resources/schemas/jaxws.xsd
>>>> [2]https://svn.apache.org/repos/asf/incubator/cxf/trunk/rt/frontend/jaxws/src/main/java/org/apache/cxf/jaxws/spring/EndpointDefinitionParser.java
>>>>
>>>>
>>>> Willem.
>>>>
>>>>
>>> --
>>> Venlig hilsen / Kind regards,
>>> Christian Vest Hansen.
>>>
>>>
>> --
>> Venlig hilsen / Kind regards,
>> Christian Vest Hansen.
>>
>>
>>
>>
>
>
>
Re: configurability of published soap:address location on jaxws endpoints
Posted by Christian Vest Hansen <ka...@gmail.com>.
Hi Willem,
Ok. I have tried to move (reimplement, really) the test in the systest
module myself, but I can't figure out how to configure it properly -
keep getting a 'no such operation' whenever I request the wsdl. Oh
well... you can probably write the systest better than I can anyway.
:-)
On 12/11/07, Jiang, Ning (Willem) <Ni...@iona.com> wrote:
>
> Hi Christian,
>
> I just checked the code , the real reason is jaxws front end module's pom.xml
> does not include the http transport module.
> I will move the SpringBeansTest.testPublishedEndpointUrl test code to
> the systest module.
>
> Willem.
>
> -----Original Message-----
> From: Jiang, Ning (Willem) [mailto:Ning.Jiang@iona.com]
> Sent: Tue 12/11/2007 21:29
> To: cxf-dev@incubator.apache.org; cxf-dev@incubator.apache.org
> Subject: RE: configurability of published soap:address location on jaxws endpoints
>
>
> Hi Christian,
>
> I will take care it :)
> It likes like you do not set the right bus for the JaxWsServerFactoryBean.
>
> Willem.
>
> -----Original Message-----
> From: Christian Vest Hansen [mailto:karmazilla@gmail.com]
> Sent: Tue 12/11/2007 18:38
> To: cxf-dev@incubator.apache.org
> Subject: Re: configurability of published soap:address location on jaxws endpoints
>
> I've slept on it and ...
>
> > Even though the test seems to (sometimes) work with the
> > JaxWsServerFactoryBean, I've been unable to prove to myself that a
> > spring-configured jaxws:endpoint works aswell due to #2, so I presume
> > that part dosn't work.
>
> ... is no longer an issue. Turns out the little test project I created
> was borked and included two versions of CXF - no wonder it didn't
> work. Plus, the patch seems to work as expected in this test project
> now that it's dependencies and deployment is fixed.
>
> So this is a good thing, however mvn test still fails with a "Could
> not find destination factory for transport
> http://schemas.xmlsoap.org/soap/http" message, while eclipse lets the
> test pass. I wonder what the difference is.
>
>
> PS.
> > I've created a JIRA
> ... but forgot the link. Here it is:
> https://issues.apache.org/jira/browse/CXF-1279
>
>
> On 12/10/07, Christian Vest Hansen <ka...@gmail.com> wrote:
> > I've created a JIRA for this feature and attached a preliminary patch
> > to it that I'de like someone to look at and comment on (I'm sure there
> > are numerous things to point out).
> >
> > The patch has a number of issues that I'm currently stuck on:
> > #1. The SpringBeansTest.testPublishedEndpointUrl runs fine in Eclipse
> > but breaks in mvn test (this also breaks the build).
> > #2. The changes to jaxws.xsd dosn't seem to have any effect outside
> > the confines of JUnit (this breaks war-file deployment).
> > #3. I've had to add the publishedEndpointUrl property to not only
> > EndpointImpl, but also AbstractEndpointFactory, and I wonder if it
> > needs to be added elsewhere.
> >
> > Even though the test seems to (sometimes) work with the
> > JaxWsServerFactoryBean, I've been unable to prove to myself that a
> > spring-configured jaxws:endpoint works aswell due to #2, so I presume
> > that part dosn't work.
> >
> > On 12/5/07, Willem Jiang <ni...@iona.com> wrote:
> > > Jim Ma wrote:
> > > >
> > > >> Is there a specific reason for using jaxws:properties as oppose to a
> > > >> first class attribute? Because I already implemented the attribute...
> > > >> :p
> > > >>
> > > > That's cool . There is no specific reason for that , I just think
> > > > it's the simple way to
> > > > do that .. :)
> > > >
> > > I think in this case , you do not need to change the jaxws.xsd[1] and the
> > > EndpointDefinitionParser[2] to consume a new attribute.
> > >
> > >
> > > [1]https://svn.apache.org/repos/asf/incubator/cxf/trunk/rt/frontend/jaxws/src/main/resources/schemas/jaxws.xsd
> > > [2]https://svn.apache.org/repos/asf/incubator/cxf/trunk/rt/frontend/jaxws/src/main/java/org/apache/cxf/jaxws/spring/EndpointDefinitionParser.java
> > >
> > >
> > > Willem.
> > >
> >
> >
> > --
> > Venlig hilsen / Kind regards,
> > Christian Vest Hansen.
> >
>
>
> --
> Venlig hilsen / Kind regards,
> Christian Vest Hansen.
>
>
>
--
Venlig hilsen / Kind regards,
Christian Vest Hansen.
RE: configurability of published soap:address location on jaxws endpoints
Posted by "Jiang, Ning (Willem)" <Ni...@iona.com>.
Hi Christian,
I just checked the code , the real reason is jaxws front end module's pom.xml
does not include the http transport module.
I will move the SpringBeansTest.testPublishedEndpointUrl test code to
the systest module.
Willem.
-----Original Message-----
From: Jiang, Ning (Willem) [mailto:Ning.Jiang@iona.com]
Sent: Tue 12/11/2007 21:29
To: cxf-dev@incubator.apache.org; cxf-dev@incubator.apache.org
Subject: RE: configurability of published soap:address location on jaxws endpoints
Hi Christian,
I will take care it :)
It likes like you do not set the right bus for the JaxWsServerFactoryBean.
Willem.
-----Original Message-----
From: Christian Vest Hansen [mailto:karmazilla@gmail.com]
Sent: Tue 12/11/2007 18:38
To: cxf-dev@incubator.apache.org
Subject: Re: configurability of published soap:address location on jaxws endpoints
I've slept on it and ...
> Even though the test seems to (sometimes) work with the
> JaxWsServerFactoryBean, I've been unable to prove to myself that a
> spring-configured jaxws:endpoint works aswell due to #2, so I presume
> that part dosn't work.
... is no longer an issue. Turns out the little test project I created
was borked and included two versions of CXF - no wonder it didn't
work. Plus, the patch seems to work as expected in this test project
now that it's dependencies and deployment is fixed.
So this is a good thing, however mvn test still fails with a "Could
not find destination factory for transport
http://schemas.xmlsoap.org/soap/http" message, while eclipse lets the
test pass. I wonder what the difference is.
PS.
> I've created a JIRA
... but forgot the link. Here it is:
https://issues.apache.org/jira/browse/CXF-1279
On 12/10/07, Christian Vest Hansen <ka...@gmail.com> wrote:
> I've created a JIRA for this feature and attached a preliminary patch
> to it that I'de like someone to look at and comment on (I'm sure there
> are numerous things to point out).
>
> The patch has a number of issues that I'm currently stuck on:
> #1. The SpringBeansTest.testPublishedEndpointUrl runs fine in Eclipse
> but breaks in mvn test (this also breaks the build).
> #2. The changes to jaxws.xsd dosn't seem to have any effect outside
> the confines of JUnit (this breaks war-file deployment).
> #3. I've had to add the publishedEndpointUrl property to not only
> EndpointImpl, but also AbstractEndpointFactory, and I wonder if it
> needs to be added elsewhere.
>
> Even though the test seems to (sometimes) work with the
> JaxWsServerFactoryBean, I've been unable to prove to myself that a
> spring-configured jaxws:endpoint works aswell due to #2, so I presume
> that part dosn't work.
>
> On 12/5/07, Willem Jiang <ni...@iona.com> wrote:
> > Jim Ma wrote:
> > >
> > >> Is there a specific reason for using jaxws:properties as oppose to a
> > >> first class attribute? Because I already implemented the attribute...
> > >> :p
> > >>
> > > That's cool . There is no specific reason for that , I just think
> > > it's the simple way to
> > > do that .. :)
> > >
> > I think in this case , you do not need to change the jaxws.xsd[1] and the
> > EndpointDefinitionParser[2] to consume a new attribute.
> >
> >
> > [1]https://svn.apache.org/repos/asf/incubator/cxf/trunk/rt/frontend/jaxws/src/main/resources/schemas/jaxws.xsd
> > [2]https://svn.apache.org/repos/asf/incubator/cxf/trunk/rt/frontend/jaxws/src/main/java/org/apache/cxf/jaxws/spring/EndpointDefinitionParser.java
> >
> >
> > Willem.
> >
>
>
> --
> Venlig hilsen / Kind regards,
> Christian Vest Hansen.
>
--
Venlig hilsen / Kind regards,
Christian Vest Hansen.
RE: configurability of published soap:address location on jaxws endpoints
Posted by "Jiang, Ning (Willem)" <Ni...@iona.com>.
Hi Christian,
I will take care it :)
It likes like you do not set the right bus for the JaxWsServerFactoryBean.
Willem.
-----Original Message-----
From: Christian Vest Hansen [mailto:karmazilla@gmail.com]
Sent: Tue 12/11/2007 18:38
To: cxf-dev@incubator.apache.org
Subject: Re: configurability of published soap:address location on jaxws endpoints
I've slept on it and ...
> Even though the test seems to (sometimes) work with the
> JaxWsServerFactoryBean, I've been unable to prove to myself that a
> spring-configured jaxws:endpoint works aswell due to #2, so I presume
> that part dosn't work.
... is no longer an issue. Turns out the little test project I created
was borked and included two versions of CXF - no wonder it didn't
work. Plus, the patch seems to work as expected in this test project
now that it's dependencies and deployment is fixed.
So this is a good thing, however mvn test still fails with a "Could
not find destination factory for transport
http://schemas.xmlsoap.org/soap/http" message, while eclipse lets the
test pass. I wonder what the difference is.
PS.
> I've created a JIRA
... but forgot the link. Here it is:
https://issues.apache.org/jira/browse/CXF-1279
On 12/10/07, Christian Vest Hansen <ka...@gmail.com> wrote:
> I've created a JIRA for this feature and attached a preliminary patch
> to it that I'de like someone to look at and comment on (I'm sure there
> are numerous things to point out).
>
> The patch has a number of issues that I'm currently stuck on:
> #1. The SpringBeansTest.testPublishedEndpointUrl runs fine in Eclipse
> but breaks in mvn test (this also breaks the build).
> #2. The changes to jaxws.xsd dosn't seem to have any effect outside
> the confines of JUnit (this breaks war-file deployment).
> #3. I've had to add the publishedEndpointUrl property to not only
> EndpointImpl, but also AbstractEndpointFactory, and I wonder if it
> needs to be added elsewhere.
>
> Even though the test seems to (sometimes) work with the
> JaxWsServerFactoryBean, I've been unable to prove to myself that a
> spring-configured jaxws:endpoint works aswell due to #2, so I presume
> that part dosn't work.
>
> On 12/5/07, Willem Jiang <ni...@iona.com> wrote:
> > Jim Ma wrote:
> > >
> > >> Is there a specific reason for using jaxws:properties as oppose to a
> > >> first class attribute? Because I already implemented the attribute...
> > >> :p
> > >>
> > > That's cool . There is no specific reason for that , I just think
> > > it's the simple way to
> > > do that .. :)
> > >
> > I think in this case , you do not need to change the jaxws.xsd[1] and the
> > EndpointDefinitionParser[2] to consume a new attribute.
> >
> >
> > [1]https://svn.apache.org/repos/asf/incubator/cxf/trunk/rt/frontend/jaxws/src/main/resources/schemas/jaxws.xsd
> > [2]https://svn.apache.org/repos/asf/incubator/cxf/trunk/rt/frontend/jaxws/src/main/java/org/apache/cxf/jaxws/spring/EndpointDefinitionParser.java
> >
> >
> > Willem.
> >
>
>
> --
> Venlig hilsen / Kind regards,
> Christian Vest Hansen.
>
--
Venlig hilsen / Kind regards,
Christian Vest Hansen.
Re: configurability of published soap:address location on jaxws endpoints
Posted by Christian Vest Hansen <ka...@gmail.com>.
I've slept on it and ...
> Even though the test seems to (sometimes) work with the
> JaxWsServerFactoryBean, I've been unable to prove to myself that a
> spring-configured jaxws:endpoint works aswell due to #2, so I presume
> that part dosn't work.
... is no longer an issue. Turns out the little test project I created
was borked and included two versions of CXF - no wonder it didn't
work. Plus, the patch seems to work as expected in this test project
now that it's dependencies and deployment is fixed.
So this is a good thing, however mvn test still fails with a "Could
not find destination factory for transport
http://schemas.xmlsoap.org/soap/http" message, while eclipse lets the
test pass. I wonder what the difference is.
PS.
> I've created a JIRA
... but forgot the link. Here it is:
https://issues.apache.org/jira/browse/CXF-1279
On 12/10/07, Christian Vest Hansen <ka...@gmail.com> wrote:
> I've created a JIRA for this feature and attached a preliminary patch
> to it that I'de like someone to look at and comment on (I'm sure there
> are numerous things to point out).
>
> The patch has a number of issues that I'm currently stuck on:
> #1. The SpringBeansTest.testPublishedEndpointUrl runs fine in Eclipse
> but breaks in mvn test (this also breaks the build).
> #2. The changes to jaxws.xsd dosn't seem to have any effect outside
> the confines of JUnit (this breaks war-file deployment).
> #3. I've had to add the publishedEndpointUrl property to not only
> EndpointImpl, but also AbstractEndpointFactory, and I wonder if it
> needs to be added elsewhere.
>
> Even though the test seems to (sometimes) work with the
> JaxWsServerFactoryBean, I've been unable to prove to myself that a
> spring-configured jaxws:endpoint works aswell due to #2, so I presume
> that part dosn't work.
>
> On 12/5/07, Willem Jiang <ni...@iona.com> wrote:
> > Jim Ma wrote:
> > >
> > >> Is there a specific reason for using jaxws:properties as oppose to a
> > >> first class attribute? Because I already implemented the attribute...
> > >> :p
> > >>
> > > That's cool . There is no specific reason for that , I just think
> > > it's the simple way to
> > > do that .. :)
> > >
> > I think in this case , you do not need to change the jaxws.xsd[1] and the
> > EndpointDefinitionParser[2] to consume a new attribute.
> >
> >
> > [1]https://svn.apache.org/repos/asf/incubator/cxf/trunk/rt/frontend/jaxws/src/main/resources/schemas/jaxws.xsd
> > [2]https://svn.apache.org/repos/asf/incubator/cxf/trunk/rt/frontend/jaxws/src/main/java/org/apache/cxf/jaxws/spring/EndpointDefinitionParser.java
> >
> >
> > Willem.
> >
>
>
> --
> Venlig hilsen / Kind regards,
> Christian Vest Hansen.
>
--
Venlig hilsen / Kind regards,
Christian Vest Hansen.
Re: configurability of published soap:address location on jaxws endpoints
Posted by Christian Vest Hansen <ka...@gmail.com>.
I've created a JIRA for this feature and attached a preliminary patch
to it that I'de like someone to look at and comment on (I'm sure there
are numerous things to point out).
The patch has a number of issues that I'm currently stuck on:
#1. The SpringBeansTest.testPublishedEndpointUrl runs fine in Eclipse
but breaks in mvn test (this also breaks the build).
#2. The changes to jaxws.xsd dosn't seem to have any effect outside
the confines of JUnit (this breaks war-file deployment).
#3. I've had to add the publishedEndpointUrl property to not only
EndpointImpl, but also AbstractEndpointFactory, and I wonder if it
needs to be added elsewhere.
Even though the test seems to (sometimes) work with the
JaxWsServerFactoryBean, I've been unable to prove to myself that a
spring-configured jaxws:endpoint works aswell due to #2, so I presume
that part dosn't work.
On 12/5/07, Willem Jiang <ni...@iona.com> wrote:
> Jim Ma wrote:
> >
> >> Is there a specific reason for using jaxws:properties as oppose to a
> >> first class attribute? Because I already implemented the attribute...
> >> :p
> >>
> > That's cool . There is no specific reason for that , I just think
> > it's the simple way to
> > do that .. :)
> >
> I think in this case , you do not need to change the jaxws.xsd[1] and the
> EndpointDefinitionParser[2] to consume a new attribute.
>
>
> [1]https://svn.apache.org/repos/asf/incubator/cxf/trunk/rt/frontend/jaxws/src/main/resources/schemas/jaxws.xsd
> [2]https://svn.apache.org/repos/asf/incubator/cxf/trunk/rt/frontend/jaxws/src/main/java/org/apache/cxf/jaxws/spring/EndpointDefinitionParser.java
>
>
> Willem.
>
--
Venlig hilsen / Kind regards,
Christian Vest Hansen.
Re: configurability of published soap:address location on jaxws endpoints
Posted by Willem Jiang <ni...@iona.com>.
Jim Ma wrote:
>
>> Is there a specific reason for using jaxws:properties as oppose to a
>> first class attribute? Because I already implemented the attribute...
>> :p
>>
> That's cool . There is no specific reason for that , I just think
> it's the simple way to
> do that .. :)
>
I think in this case , you do not need to change the jaxws.xsd[1] and the
EndpointDefinitionParser[2] to consume a new attribute.
[1]https://svn.apache.org/repos/asf/incubator/cxf/trunk/rt/frontend/jaxws/src/main/resources/schemas/jaxws.xsd
[2]https://svn.apache.org/repos/asf/incubator/cxf/trunk/rt/frontend/jaxws/src/main/java/org/apache/cxf/jaxws/spring/EndpointDefinitionParser.java
Willem.
Re: configurability of published soap:address location on jaxws endpoints
Posted by Jim Ma <em...@iona.com>.
> Is there a specific reason for using jaxws:properties as oppose to a
> first class attribute? Because I already implemented the attribute...
> :p
>
That's cool . There is no specific reason for that , I just think it's
the simple way to
do that .. :)
Re: configurability of published soap:address location on jaxws endpoints
Posted by Christian Vest Hansen <ka...@gmail.com>.
Thank you, Jim.
I was looking at these source files myself trying to figure out how
...?wsdl urls was handled, and it was nice to discover that I seem to
be on the right track.
Is there a specific reason for using jaxws:properties as oppose to a
first class attribute? Because I already implemented the attribute...
:p
On 12/4/07, Jim Ma <em...@iona.com> wrote:
> My idea is this: configure "publishedEndpointUrl" as a jaxws properties :
> <jaxws:endpoint id="publishedEndpointUrl" implementor="#greeter"
> address="http://localhost:8080/publishedEndpointUrl">
> <jaxws:properties>
> <entry key="publishedEndpointUrl"
> value="http://cxf.apache.org/GreeterEndpoint"/>
> </jaxws:properties>
> </jaxws:endpoint>
>
> and store this property in endpointInfo before the EndpointImpl class
> invoks the server.start() [1].
> Then you can rewrite this address in wsdl definition before it is
> written to http response[2] .
> Look at these codes :[1] [2] and [3] for some details.
>
> Regards
> Jim
>
> [1]
> http://svn.apache.org/viewvc/incubator/cxf/trunk/rt/frontend/jaxws/src/main/java/org/apache/cxf/jaxws/EndpointImpl.java
>
> [2]
> http://svn.apache.org/viewvc/incubator/cxf/trunk/rt/core/src/main/java/org/apache/cxf/transport/http/WSDLQueryHandler.java
>
> [3]
> http://svn.apache.org/viewvc/incubator/cxf/trunk/rt/transports/http/src/main/java/org/apache/cxf/transport/servlet/ServletController.java
>
>
>
>
> Christian Vest Hansen wrote:
> > Hi Willem,
> >
> > Troublesome as it may be, I have to try it. I'm scheduled this month
> > to work on this as it is a feature that's pretty high on our wish
> > list, and we might schedule more time if one month is not enough.
> >
> >
> >> I think if we can delegate the WSDL query to a static WSDL resovler
> >> handler , you can define the WSDL service address as what you want.
> >>
> >
> > Can you tell me more about this idea? Where would the good extension
> > points be - what packages & modules to look at.
> >
> >
> > 2007/12/4, Willem Jiang <ni...@iona.com>:
> >
> >> Hi Chirstian,
> >>
> >> I don't think you can do that , since CXFServletControl will use the
> >> endpoint address which get from the endpoint information to find the
> >> right destination, and this endpoint information will be used as the
> >> service address when CXF generate the WSDL for you.
> >>
> >> I think if we can delegate the WSDL query to a static WSDL resovler
> >> handler , you can define the WSDL service address as what you want.
> >>
> >> Willem.
> >>
> >> Christian Vest Hansen wrote:
> >>
> >>> Hi,
> >>>
> >>> I'm trying to make it possible to configure the published soap:address
> >>> location in the jaxws generated WSDLs.
> >>>
> >>> >From a spring point of view, I'm trying to make this:
> >>>
> >>> (beans.xml....)
> >>> <jaxws:endpoint id="publishedEndpointUrl"
> >>> implementor="#greeter"
> >>> address="http://localhost:8080/publishedEndpointUrl"
> >>> publishedEndpointUrl="http://cxf.apache.org/GreeterEndpoint"/>
> >>> (....)
> >>>
> >>> Do this:
> >>>
> >>> (http://localhost:8080/publishedEndpointUrl?wsdl....)
> >>> <wsdl:service name="GreeterService">
> >>> <wsdl:port binding="tns:GreeterServiceSoapBinding" name="GreeterPort">
> >>> <soap:address location="http://cxf.apache.org/GreeterEndpoint"/>
> >>> </wsdl:port>
> >>> </wsdl:service>
> >>> (....)
> >>>
> >>> Right now, I'm trying to wrap my head around how the WSDL is generated
> >>> and how that is connected to the values in the EndpointImpl objects
> >>> that the jaxws:endpoint xml generates.
> >>>
> >>> If you have any hints to that end, or other relevant information then
> >>> it would be greatly appreciated - I haven't worked with the CXF source
> >>> before and the docs on the wiki are still a bit sparse in this regard.
> >>>
> >>> Thanks!
> >>>
> >>>
> >>>
> >
> >
> >
>
--
Venlig hilsen / Kind regards,
Christian Vest Hansen.
Re: configurability of published soap:address location on jaxws endpoints
Posted by Jim Ma <em...@iona.com>.
My idea is this: configure "publishedEndpointUrl" as a jaxws properties :
<jaxws:endpoint id="publishedEndpointUrl" implementor="#greeter"
address="http://localhost:8080/publishedEndpointUrl">
<jaxws:properties>
<entry key="publishedEndpointUrl"
value="http://cxf.apache.org/GreeterEndpoint"/>
</jaxws:properties>
</jaxws:endpoint>
and store this property in endpointInfo before the EndpointImpl class
invoks the server.start() [1].
Then you can rewrite this address in wsdl definition before it is
written to http response[2] .
Look at these codes :[1] [2] and [3] for some details.
Regards
Jim
[1]
http://svn.apache.org/viewvc/incubator/cxf/trunk/rt/frontend/jaxws/src/main/java/org/apache/cxf/jaxws/EndpointImpl.java
[2]
http://svn.apache.org/viewvc/incubator/cxf/trunk/rt/core/src/main/java/org/apache/cxf/transport/http/WSDLQueryHandler.java
[3]
http://svn.apache.org/viewvc/incubator/cxf/trunk/rt/transports/http/src/main/java/org/apache/cxf/transport/servlet/ServletController.java
Christian Vest Hansen wrote:
> Hi Willem,
>
> Troublesome as it may be, I have to try it. I'm scheduled this month
> to work on this as it is a feature that's pretty high on our wish
> list, and we might schedule more time if one month is not enough.
>
>
>> I think if we can delegate the WSDL query to a static WSDL resovler
>> handler , you can define the WSDL service address as what you want.
>>
>
> Can you tell me more about this idea? Where would the good extension
> points be - what packages & modules to look at.
>
>
> 2007/12/4, Willem Jiang <ni...@iona.com>:
>
>> Hi Chirstian,
>>
>> I don't think you can do that , since CXFServletControl will use the
>> endpoint address which get from the endpoint information to find the
>> right destination, and this endpoint information will be used as the
>> service address when CXF generate the WSDL for you.
>>
>> I think if we can delegate the WSDL query to a static WSDL resovler
>> handler , you can define the WSDL service address as what you want.
>>
>> Willem.
>>
>> Christian Vest Hansen wrote:
>>
>>> Hi,
>>>
>>> I'm trying to make it possible to configure the published soap:address
>>> location in the jaxws generated WSDLs.
>>>
>>> >From a spring point of view, I'm trying to make this:
>>>
>>> (beans.xml....)
>>> <jaxws:endpoint id="publishedEndpointUrl"
>>> implementor="#greeter"
>>> address="http://localhost:8080/publishedEndpointUrl"
>>> publishedEndpointUrl="http://cxf.apache.org/GreeterEndpoint"/>
>>> (....)
>>>
>>> Do this:
>>>
>>> (http://localhost:8080/publishedEndpointUrl?wsdl....)
>>> <wsdl:service name="GreeterService">
>>> <wsdl:port binding="tns:GreeterServiceSoapBinding" name="GreeterPort">
>>> <soap:address location="http://cxf.apache.org/GreeterEndpoint"/>
>>> </wsdl:port>
>>> </wsdl:service>
>>> (....)
>>>
>>> Right now, I'm trying to wrap my head around how the WSDL is generated
>>> and how that is connected to the values in the EndpointImpl objects
>>> that the jaxws:endpoint xml generates.
>>>
>>> If you have any hints to that end, or other relevant information then
>>> it would be greatly appreciated - I haven't worked with the CXF source
>>> before and the docs on the wiki are still a bit sparse in this regard.
>>>
>>> Thanks!
>>>
>>>
>>>
>
>
>
Re: configurability of published soap:address location on jaxws
endpoints
Posted by coatsey <de...@gmail.com>.
Christan,
thanks for the reply. Looks like I just had a misconfiguration of my
endpoint that was causing it to not be replaced by the publishedEndpointUrl.
It was just the way I'd read the previous post had me thinking that cxf
didn't handle replacing the endpoint in static wsdl files, so I hadn't
looked for a config problem.
Crisis averted ;)
Cheers,
Mike
Christian Vest Hansen wrote:
>
> I use WSDL-first development in conjuction with this feature.
>
> I write my WSDL with a single static endpoint address - it does mcuh
> matter what it is.
>
> Then I configure it at deployment-time, by having Spring load a
> server-local properties file into a PropertyPlaceholderConfigurer
> bean.
>
> This properties file will have a "host" variable, and I use that
> variable to set my published endpoint url to something like this:
> publishedEndpointUrl="http://${host}/app/services/ImportantService"
>
> For the wsdl location, I just to the one I package in the .war file, like
> this:
> wsdlLocation="classpath:ImportantService.wsdl"
>
> This method works out quite nicely for me, and I haven't experienced a
> time where the publishedEndpointUrl. An issue could be that the code
> only overrides one of the endpoints, and it can be pretty hard to tell
> which, but that is why I only put a single endpoint in my WSDL.
>
> Granted, it defeats the purpose of having multiple endpoints, but for
> me, that's a loss I can live with.
>
> On 3/25/08, coatsey <de...@gmail.com> wrote:
>>
>> Willem,
>> I just found this thread while looking for a way to change the
>> soap:address
>> location published at runtime, and wanted to contribute my thoughts.
>> Unfortunately when using a static wsdl (specified using the wsdlLocation
>> attribute), limiting the location to that contained in the wsdl is a
>> serious
>> limitation in development as it means that you either have to:
>> a) create a different wsdl for each environment you're going to deploy
>> into
>> b) have an incorrect wsdl for all but the final deployed destination.
>> This
>> also assumes that the developer knows hostnames at build-time, and I
>> expect
>> will limit the ability to test.
>>
>> Neither of these options makes me very comfortable. In my mind, the
>> publishedEndpointUrl should be honoured regardless of whether you're
>> using a
>> static wsdl or not so that the definition can be externalised to a
>> deploytime decision.
>>
>> Does this seem reasonable to you? Unfortunately the current code seems
>> to
>> be a showstopper for doing wsdl-first development (I'm more than happy
>> for
>> you to tell me otherwise & provide a workaround though).
>>
>> As our wsdl's have already been defined for these interfaces, it looks
>> like
>> I'll need to try a different WS framework in the mean-time (probably
>> suns
>> jaxws-ri without the spring plugin). It's a real shame though b/c cxf
>> looks
>> great otherwise. Hopefully I'll be back using it soon.
>>
>> Cheers,
>> Mike
>>
>>
>>
>>
>>
>> Willem2 wrote:
>> >
>> > Hi Christian,
>> >
>> > Please see my comments in the mail.
>> > Christian Vest Hansen wrote:
>> >> Hi Willem,
>> >>
>> >> Troublesome as it may be, I have to try it. I'm scheduled this month
>> >> to work on this as it is a feature that's pretty high on our wish
>> >> list, and we might schedule more time if one month is not enough.
>> >>
>> >>
>> > Great, any contribution are welcome here :)
>> >>> I think if we can delegate the WSDL query to a static WSDL resovler
>> >>> handler , you can define the WSDL service address as what you want.
>> >>>
>> >>
>> >> Can you tell me more about this idea? Where would the good extension
>> >> points be - what packages & modules to look at.
>> >>
>> >>
>> > Since CXF WSDLQueryHandler[1] will Generate the WSDL Dynamically,
>> > if your endpoint is generated from a static WSDL, I think you can
>> define
>> > the publishing url as what you
>> > want in the static WSDL and let WSDLQueryHandler return the static
>> WSDL
>> > instead.
>> >
>> >
>> [1]https://svn.apache.org/repos/asf/incubator/cxf/trunk/rt/core/src/main/java/org/apache/cxf/transport/http/WSDLQueryHandler.java
>> >
>> > Willem.
>> >> 2007/12/4, Willem Jiang <ni...@iona.com>:
>> >>
>> >>> Hi Chirstian,
>> >>>
>> >>> I don't think you can do that , since CXFServletControl will use the
>> >>> endpoint address which get from the endpoint information to find the
>> >>> right destination, and this endpoint information will be used as the
>> >>> service address when CXF generate the WSDL for you.
>> >>>
>> >>> I think if we can delegate the WSDL query to a static WSDL resovler
>> >>> handler , you can define the WSDL service address as what you want.
>> >>>
>> >>> Willem.
>> >>>
>> >>> Christian Vest Hansen wrote:
>> >>>
>> >>>> Hi,
>> >>>>
>> >>>> I'm trying to make it possible to configure the published
>> soap:address
>> >>>> location in the jaxws generated WSDLs.
>> >>>>
>> >>>> >From a spring point of view, I'm trying to make this:
>> >>>>
>> >>>> (beans.xml....)
>> >>>> <jaxws:endpoint id="publishedEndpointUrl"
>> >>>> implementor="#greeter"
>> >>>> address="http://localhost:8080/publishedEndpointUrl"
>> >>>> publishedEndpointUrl="http://cxf.apache.org/GreeterEndpoint"/>
>> >>>> (....)
>> >>>>
>> >>>> Do this:
>> >>>>
>> >>>> (http://localhost:8080/publishedEndpointUrl?wsdl....)
>> >>>> <wsdl:service name="GreeterService">
>> >>>> <wsdl:port binding="tns:GreeterServiceSoapBinding"
>> >>>> name="GreeterPort">
>> >>>> <soap:address
>> location="http://cxf.apache.org/GreeterEndpoint"/>
>> >>>> </wsdl:port>
>> >>>> </wsdl:service>
>> >>>> (....)
>> >>>>
>> >>>> Right now, I'm trying to wrap my head around how the WSDL is
>> generated
>> >>>> and how that is connected to the values in the EndpointImpl objects
>> >>>> that the jaxws:endpoint xml generates.
>> >>>>
>> >>>> If you have any hints to that end, or other relevant information
>> then
>> >>>> it would be greatly appreciated - I haven't worked with the CXF
>> source
>> >>>> before and the docs on the wiki are still a bit sparse in this
>> regard.
>> >>>>
>> >>>> Thanks!
>> >>>>
>> >>>>
>> >>>>
>> >>
>> >>
>> >>
>> >
>> >
>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/configurability-of-published-soap%3Aaddress-location-on-jaxws-endpoints-tp14127128p16266846.html
>> Sent from the cxf-dev mailing list archive at Nabble.com.
>>
>>
>
>
> --
> Venlig hilsen / Kind regards,
> Christian Vest Hansen.
>
>
--
View this message in context: http://www.nabble.com/configurability-of-published-soap%3Aaddress-location-on-jaxws-endpoints-tp14127128p16290841.html
Sent from the cxf-dev mailing list archive at Nabble.com.
Re: configurability of published soap:address location on jaxws endpoints
Posted by Christian Vest Hansen <ka...@gmail.com>.
I use WSDL-first development in conjuction with this feature.
I write my WSDL with a single static endpoint address - it does mcuh
matter what it is.
Then I configure it at deployment-time, by having Spring load a
server-local properties file into a PropertyPlaceholderConfigurer
bean.
This properties file will have a "host" variable, and I use that
variable to set my published endpoint url to something like this:
publishedEndpointUrl="http://${host}/app/services/ImportantService"
For the wsdl location, I just to the one I package in the .war file, like this:
wsdlLocation="classpath:ImportantService.wsdl"
This method works out quite nicely for me, and I haven't experienced a
time where the publishedEndpointUrl. An issue could be that the code
only overrides one of the endpoints, and it can be pretty hard to tell
which, but that is why I only put a single endpoint in my WSDL.
Granted, it defeats the purpose of having multiple endpoints, but for
me, that's a loss I can live with.
On 3/25/08, coatsey <de...@gmail.com> wrote:
>
> Willem,
> I just found this thread while looking for a way to change the soap:address
> location published at runtime, and wanted to contribute my thoughts.
> Unfortunately when using a static wsdl (specified using the wsdlLocation
> attribute), limiting the location to that contained in the wsdl is a serious
> limitation in development as it means that you either have to:
> a) create a different wsdl for each environment you're going to deploy into
> b) have an incorrect wsdl for all but the final deployed destination. This
> also assumes that the developer knows hostnames at build-time, and I expect
> will limit the ability to test.
>
> Neither of these options makes me very comfortable. In my mind, the
> publishedEndpointUrl should be honoured regardless of whether you're using a
> static wsdl or not so that the definition can be externalised to a
> deploytime decision.
>
> Does this seem reasonable to you? Unfortunately the current code seems to
> be a showstopper for doing wsdl-first development (I'm more than happy for
> you to tell me otherwise & provide a workaround though).
>
> As our wsdl's have already been defined for these interfaces, it looks like
> I'll need to try a different WS framework in the mean-time (probably suns
> jaxws-ri without the spring plugin). It's a real shame though b/c cxf looks
> great otherwise. Hopefully I'll be back using it soon.
>
> Cheers,
> Mike
>
>
>
>
>
> Willem2 wrote:
> >
> > Hi Christian,
> >
> > Please see my comments in the mail.
> > Christian Vest Hansen wrote:
> >> Hi Willem,
> >>
> >> Troublesome as it may be, I have to try it. I'm scheduled this month
> >> to work on this as it is a feature that's pretty high on our wish
> >> list, and we might schedule more time if one month is not enough.
> >>
> >>
> > Great, any contribution are welcome here :)
> >>> I think if we can delegate the WSDL query to a static WSDL resovler
> >>> handler , you can define the WSDL service address as what you want.
> >>>
> >>
> >> Can you tell me more about this idea? Where would the good extension
> >> points be - what packages & modules to look at.
> >>
> >>
> > Since CXF WSDLQueryHandler[1] will Generate the WSDL Dynamically,
> > if your endpoint is generated from a static WSDL, I think you can define
> > the publishing url as what you
> > want in the static WSDL and let WSDLQueryHandler return the static WSDL
> > instead.
> >
> > [1]https://svn.apache.org/repos/asf/incubator/cxf/trunk/rt/core/src/main/java/org/apache/cxf/transport/http/WSDLQueryHandler.java
> >
> > Willem.
> >> 2007/12/4, Willem Jiang <ni...@iona.com>:
> >>
> >>> Hi Chirstian,
> >>>
> >>> I don't think you can do that , since CXFServletControl will use the
> >>> endpoint address which get from the endpoint information to find the
> >>> right destination, and this endpoint information will be used as the
> >>> service address when CXF generate the WSDL for you.
> >>>
> >>> I think if we can delegate the WSDL query to a static WSDL resovler
> >>> handler , you can define the WSDL service address as what you want.
> >>>
> >>> Willem.
> >>>
> >>> Christian Vest Hansen wrote:
> >>>
> >>>> Hi,
> >>>>
> >>>> I'm trying to make it possible to configure the published soap:address
> >>>> location in the jaxws generated WSDLs.
> >>>>
> >>>> >From a spring point of view, I'm trying to make this:
> >>>>
> >>>> (beans.xml....)
> >>>> <jaxws:endpoint id="publishedEndpointUrl"
> >>>> implementor="#greeter"
> >>>> address="http://localhost:8080/publishedEndpointUrl"
> >>>> publishedEndpointUrl="http://cxf.apache.org/GreeterEndpoint"/>
> >>>> (....)
> >>>>
> >>>> Do this:
> >>>>
> >>>> (http://localhost:8080/publishedEndpointUrl?wsdl....)
> >>>> <wsdl:service name="GreeterService">
> >>>> <wsdl:port binding="tns:GreeterServiceSoapBinding"
> >>>> name="GreeterPort">
> >>>> <soap:address location="http://cxf.apache.org/GreeterEndpoint"/>
> >>>> </wsdl:port>
> >>>> </wsdl:service>
> >>>> (....)
> >>>>
> >>>> Right now, I'm trying to wrap my head around how the WSDL is generated
> >>>> and how that is connected to the values in the EndpointImpl objects
> >>>> that the jaxws:endpoint xml generates.
> >>>>
> >>>> If you have any hints to that end, or other relevant information then
> >>>> it would be greatly appreciated - I haven't worked with the CXF source
> >>>> before and the docs on the wiki are still a bit sparse in this regard.
> >>>>
> >>>> Thanks!
> >>>>
> >>>>
> >>>>
> >>
> >>
> >>
> >
> >
>
>
> --
> View this message in context: http://www.nabble.com/configurability-of-published-soap%3Aaddress-location-on-jaxws-endpoints-tp14127128p16266846.html
> Sent from the cxf-dev mailing list archive at Nabble.com.
>
>
--
Venlig hilsen / Kind regards,
Christian Vest Hansen.
Re: configurability of published soap:address location on jaxws
endpoints
Posted by coatsey <de...@gmail.com>.
Willem,
I just found this thread while looking for a way to change the soap:address
location published at runtime, and wanted to contribute my thoughts.
Unfortunately when using a static wsdl (specified using the wsdlLocation
attribute), limiting the location to that contained in the wsdl is a serious
limitation in development as it means that you either have to:
a) create a different wsdl for each environment you're going to deploy into
b) have an incorrect wsdl for all but the final deployed destination. This
also assumes that the developer knows hostnames at build-time, and I expect
will limit the ability to test.
Neither of these options makes me very comfortable. In my mind, the
publishedEndpointUrl should be honoured regardless of whether you're using a
static wsdl or not so that the definition can be externalised to a
deploytime decision.
Does this seem reasonable to you? Unfortunately the current code seems to
be a showstopper for doing wsdl-first development (I'm more than happy for
you to tell me otherwise & provide a workaround though).
As our wsdl's have already been defined for these interfaces, it looks like
I'll need to try a different WS framework in the mean-time (probably suns
jaxws-ri without the spring plugin). It's a real shame though b/c cxf looks
great otherwise. Hopefully I'll be back using it soon.
Cheers,
Mike
Willem2 wrote:
>
> Hi Christian,
>
> Please see my comments in the mail.
> Christian Vest Hansen wrote:
>> Hi Willem,
>>
>> Troublesome as it may be, I have to try it. I'm scheduled this month
>> to work on this as it is a feature that's pretty high on our wish
>> list, and we might schedule more time if one month is not enough.
>>
>>
> Great, any contribution are welcome here :)
>>> I think if we can delegate the WSDL query to a static WSDL resovler
>>> handler , you can define the WSDL service address as what you want.
>>>
>>
>> Can you tell me more about this idea? Where would the good extension
>> points be - what packages & modules to look at.
>>
>>
> Since CXF WSDLQueryHandler[1] will Generate the WSDL Dynamically,
> if your endpoint is generated from a static WSDL, I think you can define
> the publishing url as what you
> want in the static WSDL and let WSDLQueryHandler return the static WSDL
> instead.
>
> [1]https://svn.apache.org/repos/asf/incubator/cxf/trunk/rt/core/src/main/java/org/apache/cxf/transport/http/WSDLQueryHandler.java
>
> Willem.
>> 2007/12/4, Willem Jiang <ni...@iona.com>:
>>
>>> Hi Chirstian,
>>>
>>> I don't think you can do that , since CXFServletControl will use the
>>> endpoint address which get from the endpoint information to find the
>>> right destination, and this endpoint information will be used as the
>>> service address when CXF generate the WSDL for you.
>>>
>>> I think if we can delegate the WSDL query to a static WSDL resovler
>>> handler , you can define the WSDL service address as what you want.
>>>
>>> Willem.
>>>
>>> Christian Vest Hansen wrote:
>>>
>>>> Hi,
>>>>
>>>> I'm trying to make it possible to configure the published soap:address
>>>> location in the jaxws generated WSDLs.
>>>>
>>>> >From a spring point of view, I'm trying to make this:
>>>>
>>>> (beans.xml....)
>>>> <jaxws:endpoint id="publishedEndpointUrl"
>>>> implementor="#greeter"
>>>> address="http://localhost:8080/publishedEndpointUrl"
>>>> publishedEndpointUrl="http://cxf.apache.org/GreeterEndpoint"/>
>>>> (....)
>>>>
>>>> Do this:
>>>>
>>>> (http://localhost:8080/publishedEndpointUrl?wsdl....)
>>>> <wsdl:service name="GreeterService">
>>>> <wsdl:port binding="tns:GreeterServiceSoapBinding"
>>>> name="GreeterPort">
>>>> <soap:address location="http://cxf.apache.org/GreeterEndpoint"/>
>>>> </wsdl:port>
>>>> </wsdl:service>
>>>> (....)
>>>>
>>>> Right now, I'm trying to wrap my head around how the WSDL is generated
>>>> and how that is connected to the values in the EndpointImpl objects
>>>> that the jaxws:endpoint xml generates.
>>>>
>>>> If you have any hints to that end, or other relevant information then
>>>> it would be greatly appreciated - I haven't worked with the CXF source
>>>> before and the docs on the wiki are still a bit sparse in this regard.
>>>>
>>>> Thanks!
>>>>
>>>>
>>>>
>>
>>
>>
>
>
--
View this message in context: http://www.nabble.com/configurability-of-published-soap%3Aaddress-location-on-jaxws-endpoints-tp14127128p16266846.html
Sent from the cxf-dev mailing list archive at Nabble.com.
Re: configurability of published soap:address location on jaxws endpoints
Posted by Willem Jiang <ni...@iona.com>.
Hi Christian,
Please see my comments in the mail.
Christian Vest Hansen wrote:
> Hi Willem,
>
> Troublesome as it may be, I have to try it. I'm scheduled this month
> to work on this as it is a feature that's pretty high on our wish
> list, and we might schedule more time if one month is not enough.
>
>
Great, any contribution are welcome here :)
>> I think if we can delegate the WSDL query to a static WSDL resovler
>> handler , you can define the WSDL service address as what you want.
>>
>
> Can you tell me more about this idea? Where would the good extension
> points be - what packages & modules to look at.
>
>
Since CXF WSDLQueryHandler[1] will Generate the WSDL Dynamically,
if your endpoint is generated from a static WSDL, I think you can define
the publishing url as what you
want in the static WSDL and let WSDLQueryHandler return the static WSDL
instead.
[1]https://svn.apache.org/repos/asf/incubator/cxf/trunk/rt/core/src/main/java/org/apache/cxf/transport/http/WSDLQueryHandler.java
Willem.
> 2007/12/4, Willem Jiang <ni...@iona.com>:
>
>> Hi Chirstian,
>>
>> I don't think you can do that , since CXFServletControl will use the
>> endpoint address which get from the endpoint information to find the
>> right destination, and this endpoint information will be used as the
>> service address when CXF generate the WSDL for you.
>>
>> I think if we can delegate the WSDL query to a static WSDL resovler
>> handler , you can define the WSDL service address as what you want.
>>
>> Willem.
>>
>> Christian Vest Hansen wrote:
>>
>>> Hi,
>>>
>>> I'm trying to make it possible to configure the published soap:address
>>> location in the jaxws generated WSDLs.
>>>
>>> >From a spring point of view, I'm trying to make this:
>>>
>>> (beans.xml....)
>>> <jaxws:endpoint id="publishedEndpointUrl"
>>> implementor="#greeter"
>>> address="http://localhost:8080/publishedEndpointUrl"
>>> publishedEndpointUrl="http://cxf.apache.org/GreeterEndpoint"/>
>>> (....)
>>>
>>> Do this:
>>>
>>> (http://localhost:8080/publishedEndpointUrl?wsdl....)
>>> <wsdl:service name="GreeterService">
>>> <wsdl:port binding="tns:GreeterServiceSoapBinding" name="GreeterPort">
>>> <soap:address location="http://cxf.apache.org/GreeterEndpoint"/>
>>> </wsdl:port>
>>> </wsdl:service>
>>> (....)
>>>
>>> Right now, I'm trying to wrap my head around how the WSDL is generated
>>> and how that is connected to the values in the EndpointImpl objects
>>> that the jaxws:endpoint xml generates.
>>>
>>> If you have any hints to that end, or other relevant information then
>>> it would be greatly appreciated - I haven't worked with the CXF source
>>> before and the docs on the wiki are still a bit sparse in this regard.
>>>
>>> Thanks!
>>>
>>>
>>>
>
>
>
Re: configurability of published soap:address location on jaxws endpoints
Posted by Christian Vest Hansen <ka...@gmail.com>.
Hi Willem,
Troublesome as it may be, I have to try it. I'm scheduled this month
to work on this as it is a feature that's pretty high on our wish
list, and we might schedule more time if one month is not enough.
> I think if we can delegate the WSDL query to a static WSDL resovler
> handler , you can define the WSDL service address as what you want.
Can you tell me more about this idea? Where would the good extension
points be - what packages & modules to look at.
2007/12/4, Willem Jiang <ni...@iona.com>:
> Hi Chirstian,
>
> I don't think you can do that , since CXFServletControl will use the
> endpoint address which get from the endpoint information to find the
> right destination, and this endpoint information will be used as the
> service address when CXF generate the WSDL for you.
>
> I think if we can delegate the WSDL query to a static WSDL resovler
> handler , you can define the WSDL service address as what you want.
>
> Willem.
>
> Christian Vest Hansen wrote:
> > Hi,
> >
> > I'm trying to make it possible to configure the published soap:address
> > location in the jaxws generated WSDLs.
> >
> > >From a spring point of view, I'm trying to make this:
> >
> > (beans.xml....)
> > <jaxws:endpoint id="publishedEndpointUrl"
> > implementor="#greeter"
> > address="http://localhost:8080/publishedEndpointUrl"
> > publishedEndpointUrl="http://cxf.apache.org/GreeterEndpoint"/>
> > (....)
> >
> > Do this:
> >
> > (http://localhost:8080/publishedEndpointUrl?wsdl....)
> > <wsdl:service name="GreeterService">
> > <wsdl:port binding="tns:GreeterServiceSoapBinding" name="GreeterPort">
> > <soap:address location="http://cxf.apache.org/GreeterEndpoint"/>
> > </wsdl:port>
> > </wsdl:service>
> > (....)
> >
> > Right now, I'm trying to wrap my head around how the WSDL is generated
> > and how that is connected to the values in the EndpointImpl objects
> > that the jaxws:endpoint xml generates.
> >
> > If you have any hints to that end, or other relevant information then
> > it would be greatly appreciated - I haven't worked with the CXF source
> > before and the docs on the wiki are still a bit sparse in this regard.
> >
> > Thanks!
> >
> >
>
--
Venlig hilsen / Kind regards,
Christian Vest Hansen.
Re: configurability of published soap:address location on jaxws endpoints
Posted by Willem Jiang <ni...@iona.com>.
Hi Chirstian,
I don't think you can do that , since CXFServletControl will use the
endpoint address which get from the endpoint information to find the
right destination, and this endpoint information will be used as the
service address when CXF generate the WSDL for you.
I think if we can delegate the WSDL query to a static WSDL resovler
handler , you can define the WSDL service address as what you want.
Willem.
Christian Vest Hansen wrote:
> Hi,
>
> I'm trying to make it possible to configure the published soap:address
> location in the jaxws generated WSDLs.
>
> >From a spring point of view, I'm trying to make this:
>
> (beans.xml....)
> <jaxws:endpoint id="publishedEndpointUrl"
> implementor="#greeter"
> address="http://localhost:8080/publishedEndpointUrl"
> publishedEndpointUrl="http://cxf.apache.org/GreeterEndpoint"/>
> (....)
>
> Do this:
>
> (http://localhost:8080/publishedEndpointUrl?wsdl....)
> <wsdl:service name="GreeterService">
> <wsdl:port binding="tns:GreeterServiceSoapBinding" name="GreeterPort">
> <soap:address location="http://cxf.apache.org/GreeterEndpoint"/>
> </wsdl:port>
> </wsdl:service>
> (....)
>
> Right now, I'm trying to wrap my head around how the WSDL is generated
> and how that is connected to the values in the EndpointImpl objects
> that the jaxws:endpoint xml generates.
>
> If you have any hints to that end, or other relevant information then
> it would be greatly appreciated - I haven't worked with the CXF source
> before and the docs on the wiki are still a bit sparse in this regard.
>
> Thanks!
>
>