You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Fred Dushin <fr...@dushin.net> on 2007/04/05 02:29:56 UTC
http-(conduit|destination) cfg
The CXF https sample has bean configurations of the form:
<bean name="{http://foo.bar/context}SomePort.http-conduit" ...>
<bean name="{http://foo.bar/context}SomePort.http-destination" ...>
I'm trying to get a grip on the name parameter here, and its semantics.
I understand and fully appreciate the idea that this lets you do
configuration on a per-endpoint basis, but I think I might be missing
something about what an endpoint is, in WSDL. I was always under the
impression that an endpoint is more or less a pair of QNames -- a
service qname and a port (q)name. Isn't that right?
The config above seems to either ignore the service, or it chooses a
default, somehow.
E.g., what would happen if your services section was something like:
<wsdl:service name="ServiceA">
<wsdl:port binding="tns:SomeBinding" name="PortA">
<soap:address location="..."/>
</wsdl:port>
</wsdl:service>
<wsdl:service name="ServiceB">
<wsdl:port binding="tns:SomeBinding" name="PortA"> <!-- not
a typo -->
<soap:address location="..."/>
</wsdl:port>
</wsdl:service>
I.e., 2 distinct services have the same port name. Is this
prohibited in WSDL? If not, is there an alternate syntax for
conduits and destinations that allows you to specify the service in
which a port is defined?
Again, apologies for the naive questions. If you'd prefer, you can
tell me to go RTFS.
-Fred
Re: http-(conduit|destination) cfg
Posted by Polar Humenn <ph...@iona.com>.
Andrea Smyth wrote:
> Glynn, Eoghan wrote:
>
>> Back in the day, I'm pretty sure that the port-specific config had
>> *both* the service and the port names encoded in the bean ID.
>> The syntax was something like
>> {http://foo.bar/context}SomeService/SomePort.whatever
>>
>> I'm not sure though if its still possible to specify the service name in
>> this way, and if not what the motivation was for changing this.
>>
>>
> Can't remember either, one reason may have been the readability of
> bean file (the long bean names are far from ideal) trading the
> flexibility of being able to configure conduits on a per endpoint
> basis for shorter names and only being able to configure conduits on
> a per port name basis.
Isn't this approach sort of like trying to bomb "200 Main St." without
naming the Country, City, etc? Bad things might happen, no?
I know, it's all about the "context". But in the general case, in order
to get config to work, you'd be naming Ports redundantly with the
service name in order to delineate them. Furthermore, as a client
devouring the WSDL, I don't think you really have the ability to
redefine the WSDL dynamically so you can make it fit your config file.
There seem to be quite logical delineation points for uniquely (as best
one can) naming a conduit/destination, and that's.
1. Namespace URI
2. Service Name
3, Port Name
I think eliminating (2) from the name is going to cause trouble down the
line, as has already been found out.
Cheers,
-Polar
> It's easy enough to change though: in HTTPConduit.getBeanName(),
> prefix the current bean name with
> endpointInfo.getServiceInfo().getName().toString() + "." + ...
> Same in AbstractHTTPDestination.
> Existing bean files (samples, tests ...) need to be updated.
>
> Andrea.
>
>> /Eoghan
>>
>>
>>
>>> -----Original Message-----
>>> From: Fred Dushin [mailto:fred@dushin.net] Sent: 05 April 2007 01:30
>>> To: cxf-user@incubator.apache.org
>>> Subject: http-(conduit|destination) cfg
>>>
>>>
>>> The CXF https sample has bean configurations of the form:
>>>
>>> <bean name="{http://foo.bar/context}SomePort.http-conduit" ...>
>>> <bean name="{http://foo.bar/context}SomePort.http-destination" ...>
>>>
>>> I'm trying to get a grip on the name parameter here, and its semantics.
>>>
>>> I understand and fully appreciate the idea that this lets you do
>>> configuration on a per-endpoint basis, but I think I might be
>>> missing something about what an endpoint is, in WSDL. I was always
>>> under the impression that an endpoint is more or less a pair of
>>> QNames -- a service qname and a port (q)name. Isn't that right?
>>>
>>> The config above seems to either ignore the service, or it chooses a
>>> default, somehow.
>>>
>>> E.g., what would happen if your services section was something like:
>>>
>>> <wsdl:service name="ServiceA">
>>> <wsdl:port binding="tns:SomeBinding" name="PortA">
>>> <soap:address location="..."/>
>>> </wsdl:port>
>>> </wsdl:service>
>>>
>>> <wsdl:service name="ServiceB">
>>> <wsdl:port binding="tns:SomeBinding" name="PortA"> <!-- not
>>> a typo -->
>>> <soap:address location="..."/>
>>> </wsdl:port>
>>> </wsdl:service>
>>>
>>> I.e., 2 distinct services have the same port name. Is this
>>> prohibited in WSDL? If not, is there an alternate syntax for
>>> conduits and destinations that allows you to specify the service in
>>> which a port is defined?
>>>
>>> Again, apologies for the naive questions. If you'd prefer, you can
>>> tell me to go RTFS.
>>>
>>> -Fred
>>>
>>>
>
RE: http-(conduit|destination) cfg
Posted by "Glynn, Eoghan" <eo...@iona.com>.
> -----Original Message-----
> From: Polar Humenn [mailto:phumenn@iona.com]
> Sent: 10 April 2007 15:50
> To: cxf-user@incubator.apache.org
> Subject: Re: http-(conduit|destination) cfg
>
>
> Without much investigation, I suspect the problem probably
> rests with the implementation of the List type, which ever
> one Spring is using.
The Spring injection into java.util.List is fine as far as I can see.
A quick scan of the PhaseInterceptor code suggests the the reversal
occurs in the insertInterceptor() method. See my earlier mail for more
detail on this and a suggested fix.
> I've seen list implementations where the add() operation,
> true to LISP form, actually adds the item to the beginning of
> the list.
java.util.List.add() is required to be an append. In any case, I don't
think the prob is in the List impl per se.
> So, if Spring is chugging down the list in order
> the list actually comes out backwards.
>
> I'm all for getting the Spring to configure the interceptors
> completely, if at all, phase, Before, After. sure. However,
> still must be some good documentation on what is happening,
> especially when the implementation of the interceptors may
> say something else (which overrides what?) and what is
> happening *should* intuitively follow the config file.
Agreed on good docco, everything configurable, and clear precedence
rules.
Now all we need is a volunteer to pick up some of the work :)
Cheers,
Eoghan
> In any case, for now, it's good enough to say that *if* the
> interceptors are in the same phase and they don't have any or
> the same before/after constraints, that they appear in the
> order they are listed (from top to bottom, left to right) in
> the config file.
>
> We just have to ensure the order, regardless of the List
> implementation being used.
>
> Otherwise, we can stop the use of generic Spring beans, and
> make a type schema for the Bus, Endpoint, etc.
>
> Cheers,
> -Polar
>
>
>
> Glynn, Eoghan wrote:
> >
> >
> >
> >> -----Original Message-----
> >> From: Fred Dushin [mailto:fred@dushin.net]
> >> Sent: 10 April 2007 13:44
> >> To: cxf-user@incubator.apache.org
> >> Subject: Re: http-(conduit|destination) cfg
> >>
> >> Hm. I don't see it that way.
> >>
> >> Each list is really "chunked" into phases, no?
> >>
> >
> >
> > Well, not really, at least the way its currently implemented.
> >
> > The phase separation only occurs when a full interceptor chain is
> > being assembled from the constituent sub-lists. This is done afresh
> > for each invocation.
> >
> > So the ordering of each sub-list only says something about the
> > ordering of contained interceptors of *the same phase*.
> >
> > To fall-back on some half-remembered math terminology, there's a
> > *partial order* defined over the list, not a *total order*.
> >
> >
> >
> >> So what does
> >> it mean to specify an ordering declaratively, when the declared
> >> ordering is not what will actually be realized at runtime?
> >>
> >
> >
> > My understanding is that the partial order defined
> declaratively (or
> > programmatically in the injected lists are subsequently
> manipulated by
> > the application) is like a fallback position ... this is
> the order of
> > interceptors of the same phase if not overridden by the
> > getBefore/After().
> >
> > However, I see where you're going with the "this may not be
> the most
> > user-friendly thing in the world" thought.
> >
> > One useful improvement might be to allow the getBefore/After
> > constraints to be specified declaratively also.
> >
> > So for example it may be confusing if the ordering implied by:
> >
> > <bean id="phaseA_interceptor1" class="phaseA.Interceptor1"/>
> > <bean id="phaseA_interceptor2" class="phaseA.Interceptor2"/>
> > <bean id="cxf" class="org.apache.cxf.bus.CXFBusImpl">
> > <property name="inInterceptors">
> > <list>
> > <ref bean="phaseA_interceptor1"/>
> > <ref bean="phaseA_interceptor2"/>
> > </list>
> > </property>
> > </bean>
> >
> > is then overridden programmatically by
> phaseA.Interceptor2.getAfter()
> > returning "phaseA.Interceptor1", thereby reversing the ordering
> > implied by the config.
> >
> > Obviously clearer if the getAfter() constraint could be
> specified in
> > config also, e.g.:
> >
> > <bean id="phaseA_interceptor2" class="phaseA.Interceptor2">
> > <after>
> > <set>
> > <ref bean="phaseA_interceptor1"/>
> > <set>
> > </after>
> > </bean>
> >
> >
> >
> >> It's misleading at best -- an outright lie, at worst.
> >>
> >
> >
> > Maybe we just need to be clearer about the *partial*
> ordering aspect,
> > so that nothing is inferred ordering-wise from something like:
> >
> > <bean id="phaseA_interceptor" class="phaseA.Interceptor"/>
> > <bean id="phaseB_interceptor" class="phaseB.Interceptor"/>
> > <bean id="cxf" class="org.apache.cxf.bus.CXFBusImpl">
> > <property name="inInterceptors">
> > <list>
> > <ref bean="phaseA_interceptor"/>
> > <ref bean="phaseB_interceptor"/>
> > </list>
> > </property>
> > </bean>
> >
> > i.e. it's only the relative ordering of phases A and B that
> important
> > here.
> >
> > But again, it might be clearer if the phase could also be specified
> > declaratively, so a human reader of the config wouldn't
> have to look
> > up the code to see what's passed to setPhase(). Something like:
> >
> > <bean id="MyInterceptor" class="impl.MyInterceptor">
> > <phase>A</phase>
> > </bean>
> >
> >
> >
> >> Not sure I suggested a change to a programmatic API,
> unless that was
> >> a logical consequence of something I said elsewhere.
> >>
> >
> >
> > Somewhere on the thread it was suggested we replace List with some
> > unordered Collection type, by Polar probably. But yeah,
> cool, so we're
> > agreed the API stays the same.
> >
> >
> >
> >> Was just suggesting that we change/deprecate the name of a config
> >> varaible, and to put it on a long finger, at that.
> >>
> >
> >
> > Deprecating the config variable would be a bit awkward as several
> > demos and system tests depend on it to engage functionality
> like WS-RM
> > and WS-A. But definitely +1 to a clearer explanation of the
> subtlety
> > in the docco. And the above config enhancements might be useful if
> > someone wants to pick them up (I don't have the bandwidth).
> >
> > Cheers,
> > Eoghan
> >
> >
> >> -Fred
> >>
> >> On Apr 10, 2007, at 6:41 AM, Glynn, Eoghan wrote:
> >>
> >>
> >>> It's a bit more subtle that, I think. The individual
> >>>
> >> interceptor lists
> >>
> >>> associated with each interceptor provider are indeed
> ordered, so the
> >>> list type is appropriate [IMO].
> >>>
> >>
>
>
Re: http-(conduit|destination) cfg
Posted by Polar Humenn <ph...@iona.com>.
Without much investigation, I suspect the problem probably rests with
the implementation of the List type, which ever one Spring is using.
I've seen list implementations where the add() operation, true to LISP
form, actually adds the item to the beginning of the list. So, if Spring
is chugging down the list in order the list actually comes out backwards.
I'm all for getting the Spring to configure the interceptors completely,
if at all, phase, Before, After. sure. However, still must be some good
documentation on what is happening, especially when the implementation
of the interceptors may say something else (which overrides what?) and
what is happening *should* intuitively follow the config file.
In any case, for now, it's good enough to say that *if* the interceptors
are in the same phase and they don't have any or the same before/after
constraints, that they appear in the order they are listed (from top to
bottom, left to right) in the config file.
We just have to ensure the order, regardless of the List implementation
being used.
Otherwise, we can stop the use of generic Spring beans, and make a type
schema for the Bus, Endpoint, etc.
Cheers,
-Polar
Glynn, Eoghan wrote:
>
>
>
>> -----Original Message-----
>> From: Fred Dushin [mailto:fred@dushin.net]
>> Sent: 10 April 2007 13:44
>> To: cxf-user@incubator.apache.org
>> Subject: Re: http-(conduit|destination) cfg
>>
>> Hm. I don't see it that way.
>>
>> Each list is really "chunked" into phases, no?
>>
>
>
> Well, not really, at least the way its currently implemented.
>
> The phase separation only occurs when a full interceptor chain is being
> assembled from the constituent sub-lists. This is done afresh for each
> invocation.
>
> So the ordering of each sub-list only says something about the ordering
> of contained interceptors of *the same phase*.
>
> To fall-back on some half-remembered math terminology, there's a
> *partial order* defined over the list, not a *total order*.
>
>
>
>> So what does
>> it mean to specify an ordering declaratively, when the
>> declared ordering is not what will actually be realized at runtime?
>>
>
>
> My understanding is that the partial order defined declaratively (or
> programmatically in the injected lists are subsequently manipulated by
> the application) is like a fallback position ... this is the order of
> interceptors of the same phase if not overridden by the
> getBefore/After().
>
> However, I see where you're going with the "this may not be the most
> user-friendly thing in the world" thought.
>
> One useful improvement might be to allow the getBefore/After constraints
> to be specified declaratively also.
>
> So for example it may be confusing if the ordering implied by:
>
> <bean id="phaseA_interceptor1" class="phaseA.Interceptor1"/>
> <bean id="phaseA_interceptor2" class="phaseA.Interceptor2"/>
> <bean id="cxf" class="org.apache.cxf.bus.CXFBusImpl">
> <property name="inInterceptors">
> <list>
> <ref bean="phaseA_interceptor1"/>
> <ref bean="phaseA_interceptor2"/>
> </list>
> </property>
> </bean>
>
> is then overridden programmatically by phaseA.Interceptor2.getAfter()
> returning "phaseA.Interceptor1", thereby reversing the ordering implied
> by the config.
>
> Obviously clearer if the getAfter() constraint could be specified in
> config also, e.g.:
>
> <bean id="phaseA_interceptor2" class="phaseA.Interceptor2">
> <after>
> <set>
> <ref bean="phaseA_interceptor1"/>
> <set>
> </after>
> </bean>
>
>
>
>> It's misleading at best -- an outright lie, at worst.
>>
>
>
> Maybe we just need to be clearer about the *partial* ordering aspect, so
> that nothing is inferred ordering-wise from something like:
>
> <bean id="phaseA_interceptor" class="phaseA.Interceptor"/>
> <bean id="phaseB_interceptor" class="phaseB.Interceptor"/>
> <bean id="cxf" class="org.apache.cxf.bus.CXFBusImpl">
> <property name="inInterceptors">
> <list>
> <ref bean="phaseA_interceptor"/>
> <ref bean="phaseB_interceptor"/>
> </list>
> </property>
> </bean>
>
> i.e. it's only the relative ordering of phases A and B that important
> here.
>
> But again, it might be clearer if the phase could also be specified
> declaratively, so a human reader of the config wouldn't have to look up
> the code to see what's passed to setPhase(). Something like:
>
> <bean id="MyInterceptor" class="impl.MyInterceptor">
> <phase>A</phase>
> </bean>
>
>
>
>> Not sure I suggested a change to a programmatic API, unless
>> that was a logical consequence of something I said elsewhere.
>>
>
>
> Somewhere on the thread it was suggested we replace List with some
> unordered Collection type, by Polar probably. But yeah, cool, so we're
> agreed the API stays the same.
>
>
>
>> Was just suggesting that we change/deprecate the name of a
>> config varaible, and to put it on a long finger, at that.
>>
>
>
> Deprecating the config variable would be a bit awkward as several demos
> and system tests depend on it to engage functionality like WS-RM and
> WS-A. But definitely +1 to a clearer explanation of the subtlety in the
> docco. And the above config enhancements might be useful if someone
> wants to pick them up (I don't have the bandwidth).
>
> Cheers,
> Eoghan
>
>
>> -Fred
>>
>> On Apr 10, 2007, at 6:41 AM, Glynn, Eoghan wrote:
>>
>>
>>> It's a bit more subtle that, I think. The individual
>>>
>> interceptor lists
>>
>>> associated with each interceptor provider are indeed ordered, so the
>>> list type is appropriate [IMO].
>>>
>>
RE: http-(conduit|destination) cfg
Posted by "Glynn, Eoghan" <eo...@iona.com>.
> -----Original Message-----
> From: Fred Dushin [mailto:fred@dushin.net]
> Sent: 10 April 2007 13:44
> To: cxf-user@incubator.apache.org
> Subject: Re: http-(conduit|destination) cfg
>
> Hm. I don't see it that way.
>
> Each list is really "chunked" into phases, no?
Well, not really, at least the way its currently implemented.
The phase separation only occurs when a full interceptor chain is being
assembled from the constituent sub-lists. This is done afresh for each
invocation.
So the ordering of each sub-list only says something about the ordering
of contained interceptors of *the same phase*.
To fall-back on some half-remembered math terminology, there's a
*partial order* defined over the list, not a *total order*.
> So what does
> it mean to specify an ordering declaratively, when the
> declared ordering is not what will actually be realized at runtime?
My understanding is that the partial order defined declaratively (or
programmatically in the injected lists are subsequently manipulated by
the application) is like a fallback position ... this is the order of
interceptors of the same phase if not overridden by the
getBefore/After().
However, I see where you're going with the "this may not be the most
user-friendly thing in the world" thought.
One useful improvement might be to allow the getBefore/After constraints
to be specified declaratively also.
So for example it may be confusing if the ordering implied by:
<bean id="phaseA_interceptor1" class="phaseA.Interceptor1"/>
<bean id="phaseA_interceptor2" class="phaseA.Interceptor2"/>
<bean id="cxf" class="org.apache.cxf.bus.CXFBusImpl">
<property name="inInterceptors">
<list>
<ref bean="phaseA_interceptor1"/>
<ref bean="phaseA_interceptor2"/>
</list>
</property>
</bean>
is then overridden programmatically by phaseA.Interceptor2.getAfter()
returning "phaseA.Interceptor1", thereby reversing the ordering implied
by the config.
Obviously clearer if the getAfter() constraint could be specified in
config also, e.g.:
<bean id="phaseA_interceptor2" class="phaseA.Interceptor2">
<after>
<set>
<ref bean="phaseA_interceptor1"/>
<set>
</after>
</bean>
> It's misleading at best -- an outright lie, at worst.
Maybe we just need to be clearer about the *partial* ordering aspect, so
that nothing is inferred ordering-wise from something like:
<bean id="phaseA_interceptor" class="phaseA.Interceptor"/>
<bean id="phaseB_interceptor" class="phaseB.Interceptor"/>
<bean id="cxf" class="org.apache.cxf.bus.CXFBusImpl">
<property name="inInterceptors">
<list>
<ref bean="phaseA_interceptor"/>
<ref bean="phaseB_interceptor"/>
</list>
</property>
</bean>
i.e. it's only the relative ordering of phases A and B that important
here.
But again, it might be clearer if the phase could also be specified
declaratively, so a human reader of the config wouldn't have to look up
the code to see what's passed to setPhase(). Something like:
<bean id="MyInterceptor" class="impl.MyInterceptor">
<phase>A</phase>
</bean>
> Not sure I suggested a change to a programmatic API, unless
> that was a logical consequence of something I said elsewhere.
Somewhere on the thread it was suggested we replace List with some
unordered Collection type, by Polar probably. But yeah, cool, so we're
agreed the API stays the same.
> Was just suggesting that we change/deprecate the name of a
> config varaible, and to put it on a long finger, at that.
Deprecating the config variable would be a bit awkward as several demos
and system tests depend on it to engage functionality like WS-RM and
WS-A. But definitely +1 to a clearer explanation of the subtlety in the
docco. And the above config enhancements might be useful if someone
wants to pick them up (I don't have the bandwidth).
Cheers,
Eoghan
> -Fred
>
> On Apr 10, 2007, at 6:41 AM, Glynn, Eoghan wrote:
>
> > It's a bit more subtle that, I think. The individual
> interceptor lists
> > associated with each interceptor provider are indeed ordered, so the
> > list type is appropriate [IMO].
>
>
Re: http-(conduit|destination) cfg
Posted by Fred Dushin <fr...@dushin.net>.
Hm. I don't see it that way.
Each list is really "chunked" into phases, no? So what does it mean
to specify an ordering declaratively, when the declared ordering is
not what will actually be realized at runtime?
It's misleading at best -- an outright lie, at worst.
Not sure I suggested a change to a programmatic API, unless that was
a logical consequence of something I said elsewhere. Was just
suggesting that we change/deprecate the name of a config varaible,
and to put it on a long finger, at that.
-Fred
On Apr 10, 2007, at 6:41 AM, Glynn, Eoghan wrote:
> It's a bit more subtle that, I think. The individual interceptor lists
> associated with each interceptor provider are indeed ordered, so the
> list type is appropriate [IMO].
RE: http-(conduit|destination) cfg
Posted by "Glynn, Eoghan" <eo...@iona.com>.
> -----Original Message-----
> From: Fred Dushin [mailto:fred@dushin.net]
> Sent: 09 April 2007 16:35
> To: cxf-user@incubator.apache.org
> Subject: Re: http-(conduit|destination) cfg
>
> I agree. List connotes order, and if the things are not
> ordered, it's misleading to name them such.
It's a bit more subtle that, I think. The individual interceptor lists
associated with each interceptor provider are indeed ordered, so the
list type is appropriate [IMO].
The point is that this ordering is not necessarily maintained in the
full interceptor chain that results from merging the partial lists. This
is due to (a) phase separation, (b) getBefore/getAfter() constraints,
and (c) some questionable logic in PhaseInterceptorChain that I
mentioned in my previous post on this thread.
So rather than making disruptive mods to the InterceptorProvider API, I
think we just need to emphasize (a) & (b) in docco, and "fix" (c) which
is a fairly trivial change.
/Eoghan
> In light of other pressures, I suggest we file a Jira and
> schedule it, accordingly. Certainly not the end of the
> world, if it's not gotten to immediately.
>
> -Fred
>
> On Apr 9, 2007, at 10:09 AM, Polar Humenn wrote:
>
> > TypeO (sometimes I think my mailer leaves out words!) I meant
> > "Collection *instead* of List". Sorry.
>
>
Re: http-(conduit|destination) cfg
Posted by Fred Dushin <fr...@dushin.net>.
I agree. List connotes order, and if the things are not ordered,
it's misleading to name them such.
In light of other pressures, I suggest we file a Jira and schedule
it, accordingly. Certainly not the end of the world, if it's not
gotten to immediately.
-Fred
On Apr 9, 2007, at 10:09 AM, Polar Humenn wrote:
> TypeO (sometimes I think my mailer leaves out words!)
> I meant "Collection *instead* of List". Sorry.
Re: http-(conduit|destination) cfg
Posted by Polar Humenn <ph...@iona.com>.
Polar Humenn wrote:
> Is saying "it's undefined" really good enough for things that are
> "intuitive"? I mean, saying "division by zero" is undefined because
> there is some formal reason for doing so.
>
> I can see your point that if the order of specified interceptors are
> governed by their internal Before/After settings that the config file
> would conflict with the ordering of the "list". So, if the "config"
> doesn't really define the order of the interceptors and it is desired
> that be the case, then perhaps we should be using a construct that
> does *not* imply an ordering such as Collection of List?
>
TypeO (sometimes I think my mailer leaves out words!)
I meant "Collection *instead* of List". Sorry.
> Cheers,
> -Polar
>
> Dan Diephouse wrote:
>> On 4/5/07, Polar Humenn <ph...@iona.com> wrote:
>>
>>> And furthermore, I was surprised (by trial and error, mind you) that if
>>> you list two interceptors in a SpringBus bean interceptor property,
>>> that
>>> they get installed in the reverse order than the order listed!
>>>
>>>
>> Ordering for interceptors is not currently defined unless you set the
>> before/after properties on your interceptor.
>> Regards,
>> - Dan
>>
>
RE: http-(conduit|destination) cfg
Posted by "Glynn, Eoghan" <eo...@iona.com>.
> -----Original Message-----
> From: Polar Humenn [mailto:phumenn@iona.com]
> Sent: 09 April 2007 14:54
> To: cxf-user@incubator.apache.org
> Subject: Re: http-(conduit|destination) cfg
>
> Is saying "it's undefined" really good enough for things that
> are "intuitive"? I mean, saying "division by zero" is
> undefined because there is some formal reason for doing so.
>
> I can see your point that if the order of specified
> interceptors are governed by their internal Before/After
> settings that the config file would conflict with the
> ordering of the "list". So, if the "config"
> doesn't really define the order of the interceptors and it is
> desired that be the case, then perhaps we should be using a
> construct that does
> *not* imply an ordering such as Collection of List?
The behavior I've seen is that for two configured interceptors, the
order they appear in the list injected into the InterceptorProvider (the
Bus impl in your case) is actually the *same* as order in which the
interceptors are enumerated in the config file. I don't know if this is
*guaranteed* though, as the underlying schema type is an xsd:sequence
with unbounded maxOccurs. Dunno if this schema type actually implies an
ordering.
Note that the ordering-connoting List type is actually only directly
associated with the programmatic representation of the individual
interceptor chains, not with the schema type in config (although of
course the one is injected into the other).
Also note that the individual (ordered) interceptor lists maintained by
the various interceptor providers (Bus, Binding, Endpoint, Service,
Client) need to be merged into a single chain. In addition, the chain is
separated into phases and the getBefore/After ordering constraints
honoured.
So the initial orderings of the individual "partial" interceptor lists
does not necessarily reflect the order of the full chain constructed
from these lists, i.e. the order in which the interceptors are
traversed. This is the crux of the issue.
On an aside, I noticed slightly some slightly questionable logic in
PhaseInterceptorChain.insertInterceptor(). If two interceptors are being
inserted into the *same* phase, with *no* intra-interceptor ordering
asserted (i.e. empty getBefore/After()) then the first interceptor is
appended to the sub-list for that phase, whereas the second is inserted
in position zero i.e. is *prepended* to the sub-list. This probably
explains the ordering reversal you observed. And it would be easy to
fix.
If you're worried about it, just add something like:
if (before.size() == 0 && after.size() == 0) {
intercs.add(interc);
return;
}
just before the for loop in PhaseInterceptorChain.insertInterceptor().
And of course validate with a full test run, just in case some other
code is implicitly dependent on the current behavior.
/Eoghan
> Cheers,
> -Polar
>
> Dan Diephouse wrote:
> > On 4/5/07, Polar Humenn <ph...@iona.com> wrote:
> >
> >> And furthermore, I was surprised (by trial and error, mind
> you) that
> >> if you list two interceptors in a SpringBus bean interceptor
> >> property, that they get installed in the reverse order
> than the order listed!
> >>
> >>
> > Ordering for interceptors is not currently defined unless
> you set the
> > before/after properties on your interceptor.
> > Regards,
> > - Dan
> >
>
>
Re: http-(conduit|destination) cfg
Posted by Polar Humenn <ph...@iona.com>.
Is saying "it's undefined" really good enough for things that are
"intuitive"? I mean, saying "division by zero" is undefined because
there is some formal reason for doing so.
I can see your point that if the order of specified interceptors are
governed by their internal Before/After settings that the config file
would conflict with the ordering of the "list". So, if the "config"
doesn't really define the order of the interceptors and it is desired
that be the case, then perhaps we should be using a construct that does
*not* imply an ordering such as Collection of List?
Cheers,
-Polar
Dan Diephouse wrote:
> On 4/5/07, Polar Humenn <ph...@iona.com> wrote:
>
>> And furthermore, I was surprised (by trial and error, mind you) that if
>> you list two interceptors in a SpringBus bean interceptor property, that
>> they get installed in the reverse order than the order listed!
>>
>>
> Ordering for interceptors is not currently defined unless you set the
> before/after properties on your interceptor.
> Regards,
> - Dan
>
Re: http-(conduit|destination) cfg
Posted by Dan Diephouse <da...@envoisolutions.com>.
On 4/5/07, Polar Humenn <ph...@iona.com> wrote:
> And furthermore, I was surprised (by trial and error, mind you) that if
> you list two interceptors in a SpringBus bean interceptor property, that
> they get installed in the reverse order than the order listed!
>
>
Ordering for interceptors is not currently defined unless you set the
before/after properties on your interceptor.
Regards,
- Dan
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
Re: http-(conduit|destination) cfg
Posted by Polar Humenn <ph...@iona.com>.
There has to be more documentation and specification than that for this
stuff.
For instance, if you have two <bean/> definition with the same id in
whatever xml files that seem to get parsed, do you know which definition
wins out? Now add "matching" into the mix.
And furthermore, I was surprised (by trial and error, mind you) that if
you list two interceptors in a SpringBus bean interceptor property, that
they get installed in the reverse order than the order listed!
Cheers,
-Polar
Fred Dushin wrote:
> That's why I say "regular expressions".
>
> There is not a much better understood class of expressions than REs,
> their grammars being among the class of grammars that are equivalent,
> in an important mathematical sense, to finite state machines.[1]
> Haven't looked at Sun's implementation, but I would not at all be
> surprised to see them compile down to FSAs to do acceptance.
>
> -Fred
>
> [1] http://portal.acm.org/citation.cfm?coll=GUIDE&dl=GUIDE&id=48032
>
> On Apr 5, 2007, at 11:46 AM, Polar Humenn wrote:
>
>> Then we better have some specific semantics about which "match" is
>> selected, so it's predictable by thinking about apriori, and not
>> discovery by subsequent testing.
>
Re: http-(conduit|destination) cfg
Posted by Fred Dushin <fr...@dushin.net>.
That's why I say "regular expressions".
There is not a much better understood class of expressions than REs,
their grammars being among the class of grammars that are equivalent,
in an important mathematical sense, to finite state machines.[1]
Haven't looked at Sun's implementation, but I would not at all be
surprised to see them compile down to FSAs to do acceptance.
-Fred
[1] http://portal.acm.org/citation.cfm?coll=GUIDE&dl=GUIDE&id=48032
On Apr 5, 2007, at 11:46 AM, Polar Humenn wrote:
> Then we better have some specific semantics about which "match" is
> selected, so it's predictable by thinking about apriori, and not
> discovery by subsequent testing.
Re: http-(conduit|destination) cfg
Posted by Polar Humenn <ph...@iona.com>.
Andrea Smyth wrote:
> Andrea Smyth wrote:
>
>> Glynn, Eoghan wrote:
>>
>>> Back in the day, I'm pretty sure that the port-specific config had
>>> *both* the service and the port names encoded in the bean ID.
>>> The syntax was something like
>>> {http://foo.bar/context}SomeService/SomePort.whatever
>>>
>>> I'm not sure though if its still possible to specify the service
>>> name in
>>> this way, and if not what the motivation was for changing this.
>>>
>>>
>> Can't remember either, one reason may have been the readability of
>> bean file (the long bean names are far from ideal) trading the
>> flexibility of being able to configure conduits on a per endpoint
>> basis for shorter names and only being able to configure conduits on
>> a per port name basis.
>> It's easy enough to change though: in HTTPConduit.getBeanName(),
>> prefix the current bean name with
>> endpointInfo.getServiceInfo().getName().toString() + "." + ...
>> Same in AbstractHTTPDestination.
>> Existing bean files (samples, tests ...) need to be updated.
>>
>> Andrea.
>
> Having said that the we can alleviate the pain of these long bean
> names by re-introducing some form of wildcarding (Objectweb Celtix
> supported it), in which the bean definition with the name that best
> matches that of the object you want to configure is used for injection.
> I'll see if I get a change to do this.
Then we better have some specific semantics about which "match" is
selected, so it's predictable by thinking about apriori, and not
discovery by subsequent testing.
Cheers,
-Polar
>
> Andrea.
>
>>
>>> /Eoghan
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: Fred Dushin [mailto:fred@dushin.net] Sent: 05 April 2007 01:30
>>>> To: cxf-user@incubator.apache.org
>>>> Subject: http-(conduit|destination) cfg
>>>>
>>>>
>>>> The CXF https sample has bean configurations of the form:
>>>>
>>>> <bean name="{http://foo.bar/context}SomePort.http-conduit" ...>
>>>> <bean name="{http://foo.bar/context}SomePort.http-destination" ...>
>>>>
>>>> I'm trying to get a grip on the name parameter here, and its
>>>> semantics.
>>>>
>>>> I understand and fully appreciate the idea that this lets you do
>>>> configuration on a per-endpoint basis, but I think I might be
>>>> missing something about what an endpoint is, in WSDL. I was always
>>>> under the impression that an endpoint is more or less a pair of
>>>> QNames -- a service qname and a port (q)name. Isn't that right?
>>>>
>>>> The config above seems to either ignore the service, or it chooses
>>>> a default, somehow.
>>>>
>>>> E.g., what would happen if your services section was something like:
>>>>
>>>> <wsdl:service name="ServiceA">
>>>> <wsdl:port binding="tns:SomeBinding" name="PortA">
>>>> <soap:address location="..."/>
>>>> </wsdl:port>
>>>> </wsdl:service>
>>>>
>>>> <wsdl:service name="ServiceB">
>>>> <wsdl:port binding="tns:SomeBinding" name="PortA"> <!-- not
>>>> a typo -->
>>>> <soap:address location="..."/>
>>>> </wsdl:port>
>>>> </wsdl:service>
>>>>
>>>> I.e., 2 distinct services have the same port name. Is this
>>>> prohibited in WSDL? If not, is there an alternate syntax for
>>>> conduits and destinations that allows you to specify the service in
>>>> which a port is defined?
>>>>
>>>> Again, apologies for the naive questions. If you'd prefer, you can
>>>> tell me to go RTFS.
>>>>
>>>> -Fred
>>>>
>>>>
>>>
>>
>
Re: http-(conduit|destination) cfg
Posted by Fred Dushin <fr...@dushin.net>.
Wildcarding would be *very* nice, particularly for the SSL config.
It would be very convenient, in a container with a lot of services,
to include swaths of services with the stroke of a regular
expression. Seeing as the JDK supports regular expressions, and they
are so powerful and pervasive, it would be a shame to not use them.
From past experience (I won't go into details), I would recommend a
special syntax, if regular expressions are supported, to tell the
consumer that the bean name is or contains regular expressions.
Something along the lines of "regex{.*MyService.*}". That way, you
won't by default treat the name as a regular expression, which could
get pretty confusing.
0.02 euro,
-Fred
On Apr 5, 2007, at 3:00 AM, Andrea Smyth wrote:
> Andrea Smyth wrote:
>
>> Glynn, Eoghan wrote:
>>
>>> Back in the day, I'm pretty sure that the port-specific config had
>>> *both* the service and the port names encoded in the bean ID.
>>> The syntax was something like
>>> {http://foo.bar/context}SomeService/SomePort.whatever
>>>
>>> I'm not sure though if its still possible to specify the service
>>> name in
>>> this way, and if not what the motivation was for changing this.
>>>
>> Can't remember either, one reason may have been the readability of
>> bean file (the long bean names are far from ideal) trading the
>> flexibility of being able to configure conduits on a per endpoint
>> basis for shorter names and only being able to configure conduits
>> on a per port name basis.
>> It's easy enough to change though: in HTTPConduit.getBeanName(),
>> prefix the current bean name with
>> endpointInfo.getServiceInfo().getName().toString() + "." + ...
>> Same in AbstractHTTPDestination.
>> Existing bean files (samples, tests ...) need to be updated.
>>
>> Andrea.
>
> Having said that the we can alleviate the pain of these long bean
> names by re-introducing some form of wildcarding (Objectweb Celtix
> supported it), in which the bean definition with the name that best
> matches that of the object you want to configure is used for
> injection.
> I'll see if I get a change to do this.
>
> Andrea.
>
>>
>>> /Eoghan
>>>
>>>
>>>> -----Original Message-----
>>>> From: Fred Dushin [mailto:fred@dushin.net] Sent: 05 April 2007
>>>> 01:30
>>>> To: cxf-user@incubator.apache.org
>>>> Subject: http-(conduit|destination) cfg
>>>>
>>>>
>>>> The CXF https sample has bean configurations of the form:
>>>>
>>>> <bean name="{http://foo.bar/context}SomePort.http-conduit" ...>
>>>> <bean name="{http://foo.bar/context}SomePort.http-destination" ...>
>>>>
>>>> I'm trying to get a grip on the name parameter here, and its
>>>> semantics.
>>>>
>>>> I understand and fully appreciate the idea that this lets you do
>>>> configuration on a per-endpoint basis, but I think I might be
>>>> missing something about what an endpoint is, in WSDL. I was
>>>> always under the impression that an endpoint is more or less a
>>>> pair of QNames -- a service qname and a port (q)name. Isn't
>>>> that right?
>>>>
>>>> The config above seems to either ignore the service, or it
>>>> chooses a default, somehow.
>>>>
>>>> E.g., what would happen if your services section was something
>>>> like:
>>>>
>>>> <wsdl:service name="ServiceA">
>>>> <wsdl:port binding="tns:SomeBinding" name="PortA">
>>>> <soap:address location="..."/>
>>>> </wsdl:port>
>>>> </wsdl:service>
>>>>
>>>> <wsdl:service name="ServiceB">
>>>> <wsdl:port binding="tns:SomeBinding" name="PortA"> <!--
>>>> not a typo -->
>>>> <soap:address location="..."/>
>>>> </wsdl:port>
>>>> </wsdl:service>
>>>>
>>>> I.e., 2 distinct services have the same port name. Is this
>>>> prohibited in WSDL? If not, is there an alternate syntax for
>>>> conduits and destinations that allows you to specify the service
>>>> in which a port is defined?
>>>>
>>>> Again, apologies for the naive questions. If you'd prefer, you
>>>> can tell me to go RTFS.
>>>>
>>>> -Fred
>>>>
>>>>
>>>
>>
>
>
RE: http-(conduit|destination) cfg
Posted by "Glynn, Eoghan" <eo...@iona.com>.
> -----Original Message-----
> From: Andrea Smyth [mailto:andrea.smyth@iona.com]
> Sent: 05 April 2007 08:01
> To: cxf-user@incubator.apache.org
> Subject: Re: http-(conduit|destination) cfg
>
> Andrea Smyth wrote:
>
> > Glynn, Eoghan wrote:
> >
> >> Back in the day, I'm pretty sure that the port-specific config had
> >> *both* the service and the port names encoded in the bean ID.
> >> The syntax was something like
> >> {http://foo.bar/context}SomeService/SomePort.whatever
> >>
> >> I'm not sure though if its still possible to specify the
> service name
> >> in this way, and if not what the motivation was for changing this.
> >>
> >>
> > Can't remember either, one reason may have been the readability of
> > bean file (the long bean names are far from ideal) trading the
> > flexibility of being able to configure conduits on a per endpoint
> > basis for shorter names and only being able to configure
> conduits on a
> > per port name basis.
> > It's easy enough to change though: in HTTPConduit.getBeanName(),
> > prefix the current bean name with
> > endpointInfo.getServiceInfo().getName().toString() + "." + ...
> > Same in AbstractHTTPDestination.
> > Existing bean files (samples, tests ...) need to be updated.
> >
> > Andrea.
>
> Having said that the we can alleviate the pain of these long
> bean names by re-introducing some form of wildcarding
> (Objectweb Celtix supported it), in which the bean definition
> with the name that best matches that of the object you want
> to configure is used for injection.
> I'll see if I get a change to do this.
Yeah, some form of wildcarding would rock.
Especially if a "*" for the service name could be inferred if the bean
ID was in the "port-only" form, i.e. no "MyService/" preceding the port
name.
That way all existing configs out in the wild would continue to work.
Cheers,
Eoghan
> Andrea.
>
> >
> >> /Eoghan
> >>
> >>
> >>
> >>> -----Original Message-----
> >>> From: Fred Dushin [mailto:fred@dushin.net] Sent: 05 April
> 2007 01:30
> >>> To: cxf-user@incubator.apache.org
> >>> Subject: http-(conduit|destination) cfg
> >>>
> >>>
> >>> The CXF https sample has bean configurations of the form:
> >>>
> >>> <bean name="{http://foo.bar/context}SomePort.http-conduit" ...>
> >>> <bean
> name="{http://foo.bar/context}SomePort.http-destination" ...>
> >>>
> >>> I'm trying to get a grip on the name parameter here, and
> its semantics.
> >>>
> >>> I understand and fully appreciate the idea that this lets you do
> >>> configuration on a per-endpoint basis, but I think I might be
> >>> missing something about what an endpoint is, in WSDL. I
> was always
> >>> under the impression that an endpoint is more or less a pair of
> >>> QNames -- a service qname and a port (q)name. Isn't that right?
> >>>
> >>> The config above seems to either ignore the service, or
> it chooses a
> >>> default, somehow.
> >>>
> >>> E.g., what would happen if your services section was
> something like:
> >>>
> >>> <wsdl:service name="ServiceA">
> >>> <wsdl:port binding="tns:SomeBinding" name="PortA">
> >>> <soap:address location="..."/>
> >>> </wsdl:port>
> >>> </wsdl:service>
> >>>
> >>> <wsdl:service name="ServiceB">
> >>> <wsdl:port binding="tns:SomeBinding"
> name="PortA"> <!-- not
> >>> a typo -->
> >>> <soap:address location="..."/>
> >>> </wsdl:port>
> >>> </wsdl:service>
> >>>
> >>> I.e., 2 distinct services have the same port name. Is this
> >>> prohibited in WSDL? If not, is there an alternate syntax for
> >>> conduits and destinations that allows you to specify the
> service in
> >>> which a port is defined?
> >>>
> >>> Again, apologies for the naive questions. If you'd
> prefer, you can
> >>> tell me to go RTFS.
> >>>
> >>> -Fred
> >>>
> >>>
> >>
> >
>
>
Re: http-(conduit|destination) cfg
Posted by Andrea Smyth <an...@iona.com>.
Andrea Smyth wrote:
> Glynn, Eoghan wrote:
>
>> Back in the day, I'm pretty sure that the port-specific config had
>> *both* the service and the port names encoded in the bean ID.
>> The syntax was something like
>> {http://foo.bar/context}SomeService/SomePort.whatever
>>
>> I'm not sure though if its still possible to specify the service name in
>> this way, and if not what the motivation was for changing this.
>>
>>
> Can't remember either, one reason may have been the readability of
> bean file (the long bean names are far from ideal) trading the
> flexibility of being able to configure conduits on a per endpoint
> basis for shorter names and only being able to configure conduits on
> a per port name basis.
> It's easy enough to change though: in HTTPConduit.getBeanName(),
> prefix the current bean name with
> endpointInfo.getServiceInfo().getName().toString() + "." + ...
> Same in AbstractHTTPDestination.
> Existing bean files (samples, tests ...) need to be updated.
>
> Andrea.
Having said that the we can alleviate the pain of these long bean names
by re-introducing some form of wildcarding (Objectweb Celtix supported
it), in which the bean definition with the name that best matches that
of the object you want to configure is used for injection.
I'll see if I get a change to do this.
Andrea.
>
>> /Eoghan
>>
>>
>>
>>> -----Original Message-----
>>> From: Fred Dushin [mailto:fred@dushin.net] Sent: 05 April 2007 01:30
>>> To: cxf-user@incubator.apache.org
>>> Subject: http-(conduit|destination) cfg
>>>
>>>
>>> The CXF https sample has bean configurations of the form:
>>>
>>> <bean name="{http://foo.bar/context}SomePort.http-conduit" ...>
>>> <bean name="{http://foo.bar/context}SomePort.http-destination" ...>
>>>
>>> I'm trying to get a grip on the name parameter here, and its semantics.
>>>
>>> I understand and fully appreciate the idea that this lets you do
>>> configuration on a per-endpoint basis, but I think I might be
>>> missing something about what an endpoint is, in WSDL. I was always
>>> under the impression that an endpoint is more or less a pair of
>>> QNames -- a service qname and a port (q)name. Isn't that right?
>>>
>>> The config above seems to either ignore the service, or it chooses a
>>> default, somehow.
>>>
>>> E.g., what would happen if your services section was something like:
>>>
>>> <wsdl:service name="ServiceA">
>>> <wsdl:port binding="tns:SomeBinding" name="PortA">
>>> <soap:address location="..."/>
>>> </wsdl:port>
>>> </wsdl:service>
>>>
>>> <wsdl:service name="ServiceB">
>>> <wsdl:port binding="tns:SomeBinding" name="PortA"> <!-- not
>>> a typo -->
>>> <soap:address location="..."/>
>>> </wsdl:port>
>>> </wsdl:service>
>>>
>>> I.e., 2 distinct services have the same port name. Is this
>>> prohibited in WSDL? If not, is there an alternate syntax for
>>> conduits and destinations that allows you to specify the service in
>>> which a port is defined?
>>>
>>> Again, apologies for the naive questions. If you'd prefer, you can
>>> tell me to go RTFS.
>>>
>>> -Fred
>>>
>>>
>>
>
Re: http-(conduit|destination) cfg
Posted by Andrea Smyth <an...@iona.com>.
Glynn, Eoghan wrote:
>Back in the day, I'm pretty sure that the port-specific config had
>*both* the service and the port names encoded in the bean ID.
>
>The syntax was something like
>{http://foo.bar/context}SomeService/SomePort.whatever
>
>I'm not sure though if its still possible to specify the service name in
>this way, and if not what the motivation was for changing this.
>
>
Can't remember either, one reason may have been the readability of bean
file (the long bean names are far from ideal) trading the flexibility of
being able to configure conduits on a per endpoint basis for shorter
names and only being able to configure conduits on a per port name basis.
It's easy enough to change though: in HTTPConduit.getBeanName(), prefix
the current bean name with
endpointInfo.getServiceInfo().getName().toString() + "." + ...
Same in AbstractHTTPDestination.
Existing bean files (samples, tests ...) need to be updated.
Andrea.
>/Eoghan
>
>
>
>>-----Original Message-----
>>From: Fred Dushin [mailto:fred@dushin.net]
>>Sent: 05 April 2007 01:30
>>To: cxf-user@incubator.apache.org
>>Subject: http-(conduit|destination) cfg
>>
>>
>>The CXF https sample has bean configurations of the form:
>>
>><bean name="{http://foo.bar/context}SomePort.http-conduit"
>>...> <bean
>>name="{http://foo.bar/context}SomePort.http-destination" ...>
>>
>>I'm trying to get a grip on the name parameter here, and its
>>semantics.
>>
>>I understand and fully appreciate the idea that this lets you
>>do configuration on a per-endpoint basis, but I think I might
>>be missing something about what an endpoint is, in WSDL. I
>>was always under the impression that an endpoint is more or
>>less a pair of QNames -- a service qname and a port (q)name.
>>Isn't that right?
>>
>>The config above seems to either ignore the service, or it
>>chooses a default, somehow.
>>
>>E.g., what would happen if your services section was something like:
>>
>> <wsdl:service name="ServiceA">
>> <wsdl:port binding="tns:SomeBinding" name="PortA">
>> <soap:address location="..."/>
>> </wsdl:port>
>> </wsdl:service>
>>
>> <wsdl:service name="ServiceB">
>> <wsdl:port binding="tns:SomeBinding" name="PortA">
>><!-- not a typo -->
>> <soap:address location="..."/>
>> </wsdl:port>
>> </wsdl:service>
>>
>>I.e., 2 distinct services have the same port name. Is this
>>prohibited in WSDL? If not, is there an alternate syntax for
>>conduits and destinations that allows you to specify the
>>service in which a port is defined?
>>
>>Again, apologies for the naive questions. If you'd prefer,
>>you can tell me to go RTFS.
>>
>>-Fred
>>
>>
>>
Re: http-(conduit|destination) cfg
Posted by Fred Dushin <fr...@dushin.net>.
Great -- thanks, Eoghan. I can try to dig a little into the code and
see if that syntax is supported.
On Apr 4, 2007, at 9:34 PM, Glynn, Eoghan wrote:
>
>
> Back in the day, I'm pretty sure that the port-specific config had
> *both* the service and the port names encoded in the bean ID.
>
> The syntax was something like
> {http://foo.bar/context}SomeService/SomePort.whatever
>
> I'm not sure though if its still possible to specify the service
> name in
> this way, and if not what the motivation was for changing this.
>
> /Eoghan
>
>> -----Original Message-----
>> From: Fred Dushin [mailto:fred@dushin.net]
>> Sent: 05 April 2007 01:30
>> To: cxf-user@incubator.apache.org
>> Subject: http-(conduit|destination) cfg
>>
>>
>> The CXF https sample has bean configurations of the form:
>>
>> <bean name="{http://foo.bar/context}SomePort.http-conduit"
>> ...> <bean
>> name="{http://foo.bar/context}SomePort.http-destination" ...>
>>
>> I'm trying to get a grip on the name parameter here, and its
>> semantics.
>>
>> I understand and fully appreciate the idea that this lets you
>> do configuration on a per-endpoint basis, but I think I might
>> be missing something about what an endpoint is, in WSDL. I
>> was always under the impression that an endpoint is more or
>> less a pair of QNames -- a service qname and a port (q)name.
>> Isn't that right?
>>
>> The config above seems to either ignore the service, or it
>> chooses a default, somehow.
>>
>> E.g., what would happen if your services section was something like:
>>
>> <wsdl:service name="ServiceA">
>> <wsdl:port binding="tns:SomeBinding" name="PortA">
>> <soap:address location="..."/>
>> </wsdl:port>
>> </wsdl:service>
>>
>> <wsdl:service name="ServiceB">
>> <wsdl:port binding="tns:SomeBinding" name="PortA">
>> <!-- not a typo -->
>> <soap:address location="..."/>
>> </wsdl:port>
>> </wsdl:service>
>>
>> I.e., 2 distinct services have the same port name. Is this
>> prohibited in WSDL? If not, is there an alternate syntax for
>> conduits and destinations that allows you to specify the
>> service in which a port is defined?
>>
>> Again, apologies for the naive questions. If you'd prefer,
>> you can tell me to go RTFS.
>>
>> -Fred
>>
>
RE: http-(conduit|destination) cfg
Posted by "Glynn, Eoghan" <eo...@iona.com>.
Back in the day, I'm pretty sure that the port-specific config had
*both* the service and the port names encoded in the bean ID.
The syntax was something like
{http://foo.bar/context}SomeService/SomePort.whatever
I'm not sure though if its still possible to specify the service name in
this way, and if not what the motivation was for changing this.
/Eoghan
> -----Original Message-----
> From: Fred Dushin [mailto:fred@dushin.net]
> Sent: 05 April 2007 01:30
> To: cxf-user@incubator.apache.org
> Subject: http-(conduit|destination) cfg
>
>
> The CXF https sample has bean configurations of the form:
>
> <bean name="{http://foo.bar/context}SomePort.http-conduit"
> ...> <bean
> name="{http://foo.bar/context}SomePort.http-destination" ...>
>
> I'm trying to get a grip on the name parameter here, and its
> semantics.
>
> I understand and fully appreciate the idea that this lets you
> do configuration on a per-endpoint basis, but I think I might
> be missing something about what an endpoint is, in WSDL. I
> was always under the impression that an endpoint is more or
> less a pair of QNames -- a service qname and a port (q)name.
> Isn't that right?
>
> The config above seems to either ignore the service, or it
> chooses a default, somehow.
>
> E.g., what would happen if your services section was something like:
>
> <wsdl:service name="ServiceA">
> <wsdl:port binding="tns:SomeBinding" name="PortA">
> <soap:address location="..."/>
> </wsdl:port>
> </wsdl:service>
>
> <wsdl:service name="ServiceB">
> <wsdl:port binding="tns:SomeBinding" name="PortA">
> <!-- not a typo -->
> <soap:address location="..."/>
> </wsdl:port>
> </wsdl:service>
>
> I.e., 2 distinct services have the same port name. Is this
> prohibited in WSDL? If not, is there an alternate syntax for
> conduits and destinations that allows you to specify the
> service in which a port is defined?
>
> Again, apologies for the naive questions. If you'd prefer,
> you can tell me to go RTFS.
>
> -Fred
>