10:53 a.m.
Alessio Soldano [https://community.jboss.org/people/asoldano] created the discussion
"Re: WS-Security without Spring, without WS-Policy and without the CXF
annotations?"
To view the discussion, visit: https://community.jboss.org/message/751283#751283
--------------------------------------------------------------
Matt Wringe wrote:
I know (and mentioned) those configuration options in my original post :) As
mentioned:
1) we can't use ws-policy since its against the wsrp spec
2) adding annotations to add in interceptors means that our purely jax java service
classes now have to become dependent on cxf (which doesn't make a lot of sense since
have to support non-cxf based web services, and we also want an admin to be able to
enable/disable the interceptors themselves).
Quite frankly, I see and understand the
need for avoiding implementation specific api in endpoints (you might want to deploy the
same archive on another vendor container), but as hinted before that's probably simply
not doable (especially without WS-Policy support) with WS-Security. The reason basically
being that there's no JCP spec covering ws-security configuration, so you'll
always need to use an implementation specific configuration approach.
If the real need is actually with the admin wanting to enable/disable the cxf interceptor
without touching the code, you can go the spring descriptor way, after having added spring
libraries to the app server.
3) we don't want to have to bring in spring just to configure the
web service. And this doesn't appear to the preferred method of configuring jbossws
(but it is the preferred way to configure cxf).
You don't want to bring in
spring because it's just for configuration *or* you're simply somehow confused by
the fact jbossas/jbossws does not ship with / install spring by default? If it's a
matter of willing to avoid spring for ws configuration only, I see what you mean (as a
matter of fact jbossws has moved in this direction, hence is not forcing the spring
approach and encouraging the ws-policy based approach), but when you have many other
contraints like "wsrp does not support policies", "I don't want to use
cxf api", ... you need to come to a compromise and use what is left ;-)
If it's a matter of you being confused on "what the preferred method is",
keep in mind that JBossWS suggest using the policy approach, but allows different methods
if you can't go that way. Apache CXF in general simply has multiple configuration
mechanisms and I can say that there's not an actual preference for the spring one as
of today, they're really all at the same level.
The problem is how to configure the server. Using JBossWS Native
stack I could just use the pre and post handlers to add in proper soap handlers for
ws-security, this was simple and straight forward and configurable from an admin
perspective. The ws-security setup could be handled outside of the service configuration
(add in the options in the web.xml file to specify the endpoint config name and config
file). It would be perfect if we could add in interceptors also in this manner, but this
option doesn't seem to exist (which is strange since in cxf interceptors are the
preferred method).
The client / endpoint pre-defined configurations can be used to
add JAXWS handlers. WS-Security was implemented using handlers in native stack. However
it's not implemented using jaxws handlers on cxf and we can't (and do not want to)
change that.
Any mechanism for allowing configuring a generic interceptor through descriptor would
basically imply re-inventing the spring configuration approach (a jaxws handler definition
is covered by jsr224/jsr109 specs instead).. so again, either the user go the spring way
if he really wants to have fine grain control on the interceptor beans or he stay with the
suggested configuration mechanism (policy engine + properties through @EndpointConfig)
*or* direct cxf api/annotation usage.
Its strange that CXF is the preferred web service stack in JBossAS,
and the preferred way to configure CXF is using Spring configuration files, but JBossAS
doesn't ship or include Spring. So we can't properly configure web services the
way they were meant to be configured.
Again, 1) it's not *the* way they're
meant to be configured, just *one* of the possible ways 2) you *can* still configure the
ws endpoints that way if you want, simply install Spring first (either using the jbossws
build or manually copying the spring jars into modules/org/springframework/spring/main and
creating a valid module.xml descriptor for the new module).
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/751283#751283]
Start a new discussion in JBoss Web Services at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&...]