[
https://issues.apache.org/jira/browse/CXF-5863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14055902#comment-14055902
]
Andrew commented on CXF-5863:
-----------------------------
Having had a bit of a look around, it seems that Camel can handle this for,
e.g., interceptors in Camel CXF, but it does things rather differently. Have a
look at
{{[org.apache.camel.component.cxf.blueprint.EndpointDefinitionParser|https://github.com/apache/camel/blob/e7563a7611667fb9b449d8a7f8c3fa7e3a0524bd/components/camel-cxf/src/main/java/org/apache/camel/component/cxf/blueprint/EndpointDefinitionParser.java]}},
for example, which can take configuration like:
{code:xml}
<!-- CXF (SOAP Web Service) end point. dataFormat is PAYLOAD -->
<camelcxf:cxfEndpoint id="id_1" address="http://..."; wsdlURL="/wsdl.wsdl">
<camelcxf:properties>
<entry key="dataFormat" value="PAYLOAD" />
.
.
.
</camelcxf:properties>
<camelcxf:inInterceptors>
<ref component-id="basicAuthInterceptor" />
</camelcxf:inInterceptors>
</camelcxf:cxfEndpoint>
<bean id="basicAuthInterceptor" class="..." />
{code}
But that would definitely mean a complete rewrite of the CXF/Jetty Blueprint
Namespace Handler.
Another option might be to directly access the current {{BlueprintContainer}}
via the {{Bundle}} and {{BundleContext}}, and, assuming the call
{{engine.getHandlers()}} returns a {{List}} of {{Ref}}s or something, grab the
bean straight out of the container, but that's a pretty nasty hack.
> JettyHTTPServerEngineFactoryHolder does not support Handlers
> ------------------------------------------------------------
>
> Key: CXF-5863
> URL: https://issues.apache.org/jira/browse/CXF-5863
> Project: CXF
> Issue Type: Bug
> Components: Transports
> Affects Versions: 2.7.10, 3.0.0
> Environment: Apache SMX 5.0.0
> Apache Camel 2.12.3
> Java 1.7.0_25
> Reporter: Andrew
> Assignee: Willem Jiang
> Priority: Minor
> Labels: blueprint, jetty
>
> I've been trying to add basic authentication to my CXF Web Service (using
> Apache Camel 2.12.3 and SMX 5.0.0), and I had hoped that I would be able to
> use the {{http://cxf.apache.org/transports/http-jetty/configuration}}
> namespace to configure it, with the following in my blueprint file:
> {code:xml}
> <httpj:engine-factory bus="cxf">
> <httpj:engine port="${fromCxfEndpointUri.port}">
> <httpj:handlers>
> <!-- BASIC AUTHENTICATION configuration -->
> <ref bean="securityHandler"/>
> </httpj:handlers>
> </httpj:engine>
> </httpj:engine-factory>
> <bean id="securityHandler"
> class="org.eclipse.jetty.security.ConstraintSecurityHandler">
> .
> .
> .
> </bean>
> {code}
> But as it turns out, that's not possible - I was unable to get it to
> recognise the handler - nothing I could do would make SMX recognise that
> element (I had tried with an invalid bean id, in the hope that it would raise
> an error, but it never did). In addition to {{<ref
> bean="securityHandler"/>}}, I also tried {{<ref
> component-id="securityHandler"/>}}, but to no avail.
> After hunting around for some time, I eventually found the following in
> {{org.apache.cxf.transport.http_jetty.blueprint.JettyHTTPServerEngineFactoryHolder}}:
> {code:java}
> if (engine.isContinuationsEnabled() != null) {
> eng.setContinuationsEnabled(engine.isContinuationsEnabled());
> }
> // eng.setHandlers(engine.getHandlers());
> if (engine.getHost() != null && !StringUtils.isEmpty(engine.getHost())) {
> eng.setHost(engine.getHost());
> }
> {code}
> Note, particularly, the line {{// eng.setHandlers(engine.getHandlers());}}
> (line 119) - it never actually adds the handlers.
> Now, I don't imagine the solution is as simple as just uncommenting that
> line, but it would be really nice if we could have one of the following:
> # Handler support implemented
> # An exception to be thrown if handlers are detected, saying they're not
> supported
> # A warning / error message logged if handlers are detected, saying they're
> not supported.
> It's a bit frustrating, as _everything else_ seemed to work, so I was a bit
> perplexed as to why this one thing didn't. Unfortunately, I don't have the
> time (or the knowledge, frankly) to fix this myself.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
