Alessio Soldano [https://community.jboss.org/people/asoldano] created the discussion
"Re: Metro in JBoss 7 HowTo" To view the discussion, visit: https://community.jboss.org/message/757622#757622 -------------------------------------------------------------- Hi Mike, I'll comment later on the classpath / client topic. > Mike P wrote: > > Lastly, it's interesting that, possibly, as is, right now, Metro can not do > WS-Trust with a CXF server. Unless that tagged on /mex url becomes > automagically available. > My thinking on that one, is that *if* the wsdl advertises the (extra?) > metadata, that CXF then goes ahead and makes avaibable this mystery /mex > service (that apparently does GETs and POSTs and whatnots), and that Metro > "ought to" not make assumptions about mex being available when the wsdl > doesn't list it (which might be considered a bug in Metro - which should be > reported - or at least feedback ought to be requested on this issue - I can > post a report about my findings, since I've already spend time banging my > head into this...). > *Maybe* there could a flag somewhere that makes CXF make available mex even > though wsdl doesn't advertise it - just so that clients like Metro that > require this (wrongfully), don't end up failing. > *Or*, have CXF add mex always. I don't know when mex should be added - > perhaps only with this WS-Trust stuff? Or perhaps for other ws security > features. Not needed for simple unsecure ws calls I would think (will have to > verify that). I did a bit of additional investigation on this topic today. Basically, Apache CXF is able to reply to WS-MEX requests sent to "/mex". The problem is with properly configuring the STS endpoint on JBoss AS. You need to have the JBoss Web layer deal with HTTP messages to the /mex subpath, for instance by having a web.xml descriptor as follows (please note the wildcard in the url pattern): <web-app ...> <servlet> <servlet-name>TestSecurityTokenService</servlet-name> <servlet-class>org.jboss.test.ws.jaxws.samples.wsse.policy.trust.SampleSTS</servlet-class> </servlet> <servlet-mapping> <servlet-name>TestSecurityTokenService</servlet-name> <url-pattern>/SecurityTokenService/*</url-pattern> </servlet-mapping> </web-app> Besides that, I unfortunately found a bug in the jbossws-cxf SubjectCreatingInterceptor which basically block any WS-MEX call, see https://issues.jboss.org/browse/JBWS-3543 https://issues.jboss.org/browse/JBWS-3543 . It's fixed on jbossws-cxf trunk and will be in next release. This said, there're many complaints on the net regarding Metro default behaviour wrt WS-MetadataExchange and STS endpoints; btw Glen Mazza also created a WSIT / Metro improvement ticket at http://java.net/jira/browse/WSIT-1586 http://java.net/jira/browse/WSIT-1586 long time ago (for a better configurability of Metro), but that's not been worked yet. -------------------------------------------------------------- Reply to this message by going to Community [https://community.jboss.org/message/757622#757622] 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
