Bean ID's (in this case, constructed from the names) are assigned to the BeanDefinition at parse time. However, properties are not expanded until bean creation time. That's why the properties cannot be used for ids/names.
What I don't know is if something like: <http:conduit name="foo"…./> <alias name="foo" alias="http://${server}:${port}/.*"/> would work to alias that conduit definition. I'm not sure when/how the alias names are processed. Your best bet may be to create a wrapper org.apache.cxf.configuration.Configurer that would grab the original configurer, forward all non-HTTPConduit things into it, but for HTTPConduits, reset the name or similar to whatever is appropriate to match the config. A bit tricky. Dan On Jan 31, 2013, at 11:13 AM, Ivan.Latysh <[email protected]> wrote: > Aki Yoshida-3 wrote >> the name attribute of the conduit corresponds to its bean ID. So you >> can't use parameters in there like in your example. >> >> if you know at the configuration time which addresses will be called, >> can you just define a set of pattern matched conduits to switch the >> setting? > > Unfortunately not, the app is shipped to the client, and client configure it > in a single place. So I do not know the name or the port until app is > deployed. > > I wonder, how comes that config parameter got into the bean name ? > > Cause ... bean can have multiple names and what if I have a comma in my path > ? > > Why not to have a regular parameter that avoid all that confusion and > limitations ? > > > > -- > View this message in context: > http://cxf.547215.n5.nabble.com/cxf-http-conduit-with-parameterizable-name-tp5722488p5722559.html > Sent from the cxf-user mailing list archive at Nabble.com. -- Daniel Kulp [email protected] - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
