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&containerType=14&container=2044]
_______________________________________________ jboss-user mailing list [email protected] https://lists.jboss.org/mailman/listinfo/jboss-user
