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:[EMAIL PROTECTED] Sent: 05 April 2007
01:30
To: [email protected]
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
