Daniel Kulp wrote > 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.
I do not understand why the pattern should be in the bean name at the first place. Daniel Kulp wrote > 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. >From what I see aliases are not processed either. Daniel Kulp wrote > 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. I had a look at it, it is not feasible as changes are too invasive. Creation of the ConfigurerImpl is hard coded ... I believe this issue has to be tackled on the architecture level. I have created https://issues.apache.org/jira/browse/CXF-4811 with my thoughts about it. -- View this message in context: http://cxf.547215.n5.nabble.com/cxf-http-conduit-with-parameterizable-name-tp5722488p5722763.html Sent from the cxf-user mailing list archive at Nabble.com.
