[JBoss JIRA] (JBWS-3648) WS-Policy code-first improvements and tooling
by Alessio Soldano (JIRA)
[ https://issues.jboss.org/browse/JBWS-3648?page=com.atlassian.jira.plugin.... ]
Alessio Soldano commented on JBWS-3648:
---------------------------------------
Nice suggestion: https://community.jboss.org/message/827438
> WS-Policy code-first improvements and tooling
> ---------------------------------------------
>
> Key: JBWS-3648
> URL: https://issues.jboss.org/browse/JBWS-3648
> Project: JBoss Web Services
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: jbossws-cxf, productivity
> Reporter: Alessio Soldano
> Assignee: Alessio Soldano
> Fix For: jbossws-cxf-4.2
>
>
> I'd like to see some kind of ws-policy oriented tooling in JBossWS. Ideally we should provide some mechanisms for basic code-first development; currently stuff like ws-security configuration through policies is actually contract based: the user is expected to either provide a wsdl with proper policies or to use policy attachment, which is basically the same, writing the actual policy assertion is required.
> An idea could be to have a group of pre-defined policy assertions' sets for known scenarios (for ws-security those could be based e.g. on the Oasis WS-Security Policy Examples [1]). Each set would be composed of 'placement points' with a policy to be attached at each of those points. We'd then possibly have a custom CXF FactoryBeanListener to be registered in the FactoryBeanListenerManager; the new listener would perform something similar to what the PolicyAnnotationListener does (based on the @Policies/@Policy in the code), that is attaching policies to the proper attach points. An additional step would be to support merging (effective policy through Neethi?) multiple sets at the same time (say, you want e.g. a specific ws-security set plus a ws-rm set).
> With such thing, we could provide the initial sets and let users pick the sets they want for a given endpoint (perhaps through a custom annotation, or possibly better specifying the sets' names within a property in a selected Endpoint Config).
> The initial policy sets could be stored as xml files in one of the jbossws-cxf jars and we could provide a mechanism for reading additional ones from the current classpath (to let users add additional ones).
> Finally, this would open up to further tooling improvements; e.g. 1) wsprovide could be enhanced to process the @EndpointConfig annotation, get the policy sets and produce a ws-policy enabled wsdl, 2) we could even provide an 'educational' gui tool showing assertions enabled/disabled depending on the selected sets, etc.
> [1] http://docs.oasis-open.org/ws-sx/security-policy/examples/ws-sp-usecases-...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 9 months
[JBoss JIRA] (JBWS-3660) intermittent failure in ResourceResolverDeploymentAspect
by Jim Ma (JIRA)
Jim Ma created JBWS-3660:
----------------------------
Summary: intermittent failure in ResourceResolverDeploymentAspect
Key: JBWS-3660
URL: https://issues.jboss.org/browse/JBWS-3660
Project: JBoss Web Services
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: jbossws-cxf
Affects Versions: jbossws-cxf-4.1.3
Reporter: Jim Ma
Assignee: Jim Ma
Fix For: jbossws-cxf-4.2
After EndpointLifeCyle is moved and executed in EndpointService.start() and EndpointService.stop(). The ResouceResolverDeploymentAspect.stop() will try to remove attachment from endpoint before EndpointService set it to Stopped or EndpointService.uninstall() is not called when stopServices is false.
14:36:55,337 ERROR [stderr] (default task-19) org.jboss.wsf.spi.deployment.WSFDeploymentException: java.lang.IllegalStateException: JBWS022105: Cannot modify endpoint in state STARTED: jboss.ws:context=ep-publish-test,endpoint=pattern
14:36:55,337 ERROR [stderr] (default task-19) at org.jboss.wsf.spi.deployment.WSFDeploymentException.rethrow(WSFDeploymentException.java:52)
14:36:55,337 ERROR [stderr] (default task-19) at org.jboss.ws.common.deployment.DeploymentAspectManagerImpl.failsafeStop(DeploymentAspectManagerImpl.java:184)
14:36:55,337 ERROR [stderr] (default task-19) at org.jboss.ws.common.deployment.DeploymentAspectManagerImpl.undeploy(DeploymentAspectManagerImpl.java:169)
14:36:55,338 ERROR [stderr] (default task-19) at org.jboss.as.webservices.publish.EndpointPublisherImpl.destroy(EndpointPublisherImpl.java:218)
14:36:55,338 ERROR [stderr] (default task-19) at org.jboss.test.ws.publish.EndpointPublishServlet.doGet(EndpointPublishServlet.java:117)
14:36:55,338 ERROR [stderr] (default task-19) at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
14:36:55,338 ERROR [stderr] (default task-19) at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
14:36:55,338 ERROR [stderr] (default task-19) at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87)
14:36:55,338 ERROR [stderr] (default task-19) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130)
14:36:55,339 ERROR [stderr] (default task-19) at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:138)
14:36:55,339 ERROR [stderr] (default task-19) at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56)
14:36:55,339 ERROR [stderr] (default task-19) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
14:36:55,339 ERROR [stderr] (default task-19) at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85)
14:36:55,339 ERROR [stderr] (default task-19) at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:56)
14:36:55,340 ERROR [stderr] (default task-19) at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
14:36:55,340 ERROR [stderr] (default task-19) at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
14:36:55,340 ERROR [stderr] (default task-19) at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:115)
14:36:55,340 ERROR [stderr] (default task-19) at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52)
14:36:55,340 ERROR [stderr] (default task-19) at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45)
14:36:55,341 ERROR [stderr] (default task-19) at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65)
14:36:55,341 ERROR [stderr] (default task-19) at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70)
14:36:55,341 ERROR [stderr] (default task-19) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
14:36:55,341 ERROR [stderr] (default task-19) at org.wildfly.extension.undertow.security.SecurityContextCreationHandler.handleRequest(SecurityContextCreationHandler.java:54)
14:36:55,341 ERROR [stderr] (default task-19) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
14:36:55,342 ERROR [stderr] (default task-19) at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:131)
14:36:55,342 ERROR [stderr] (default task-19) at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:118)
14:36:55,342 ERROR [stderr] (default task-19) at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:47)
14:36:55,342 ERROR [stderr] (default task-19) at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:94)
14:36:55,342 ERROR [stderr] (default task-19) at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36)
14:36:55,342 ERROR [stderr] (default task-19) at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:629)
14:36:55,343 ERROR [stderr] (default task-19) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
14:36:55,343 ERROR [stderr] (default task-19) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
14:36:55,343 ERROR [stderr] (default task-19) at java.lang.Thread.run(Thread.java:722)
14:36:55,343 ERROR [stderr] (default task-19) Caused by: java.lang.IllegalStateException: JBWS022105: Cannot modify endpoint in state STARTED: jboss.ws:context=ep-publish-test,endpoint=pattern
14:36:55,343 ERROR [stderr] (default task-19) at org.jboss.ws.common.deployment.AbstractDefaultEndpoint.assertEndpointSetterAccess(AbstractDefaultEndpoint.java:255)
14:36:55,344 ERROR [stderr] (default task-19) at org.jboss.ws.common.deployment.AbstractDefaultEndpoint.removeAttachment(AbstractDefaultEndpoint.java:235)
14:36:55,344 ERROR [stderr] (default task-19) at org.jboss.wsf.stack.cxf.deployment.aspect.ResourceResolverDeploymentAspect.stop(ResourceResolverDeploymentAspect.java:62)
14:36:55,344 ERROR [stderr] (default task-19) at org.jboss.ws.common.deployment.DeploymentAspectManagerImpl.failsafeStop(DeploymentAspectManagerImpl.java:180)
14:36:55,344 ERROR [stderr] (default task-19) ... 31 more
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 9 months
[JBoss JIRA] (JBWS-3601) SOAPFaultException cannot render SOAP 1.2 Fault Subcode in CXF
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBWS-3601?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on JBWS-3601:
-----------------------------------------------
Emmanuel Hugonnet <ehugonne(a)redhat.com> changed the Status of [bug 913411|https://bugzilla.redhat.com/show_bug.cgi?id=913411] from MODIFIED to NEW
> SOAPFaultException cannot render SOAP 1.2 Fault Subcode in CXF
> --------------------------------------------------------------
>
> Key: JBWS-3601
> URL: https://issues.jboss.org/browse/JBWS-3601
> Project: JBoss Web Services
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: jbossws-cxf
> Affects Versions: jbossws-cxf-4.0.2
> Environment: JBoss Enterprise Application Platform 6
> Reporter: Tadayoshi Sato
> Assignee: Alessio Soldano
> Labels: cxf
> Fix For: jbossws-cxf-4.2
>
>
> Backport https://issues.apache.org/jira/browse/CXF-4790, which is the root cause. The code below doesn't render {{<soapenv:Subcode>}}.
> {code}
> import javax.xml.soap.SOAPConstants;
> import javax.xml.soap.SOAPFactory;
> import javax.xml.soap.SOAPFault;
> import javax.xml.ws.soap.SOAPFaultException;
> ...
> SOAPFactory factory = SOAPFactory.newInstance(SOAPConstants.SOAP_1_2_PROTOCOL);
> SOAPFault fault = factory.createFault("Operator not found", new QName(SOAPConstants.URI_NS_SOAP_1_2_ENVELOPE, "Receiver"));
> fault.appendFaultSubcode(new QName("...", "OperatorNotFound"));
> ...
> throw new SOAPFaultException(fault);
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 9 months
[JBoss JIRA] (JBWS-3601) SOAPFaultException cannot render SOAP 1.2 Fault Subcode in CXF
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBWS-3601?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on JBWS-3601:
-----------------------------------------------
Emmanuel Hugonnet <ehugonne(a)redhat.com> made a comment on [bug 913411|https://bugzilla.redhat.com/show_bug.cgi?id=913411]
Looks like this is not enough with EJB exposed as webservices.
> SOAPFaultException cannot render SOAP 1.2 Fault Subcode in CXF
> --------------------------------------------------------------
>
> Key: JBWS-3601
> URL: https://issues.jboss.org/browse/JBWS-3601
> Project: JBoss Web Services
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: jbossws-cxf
> Affects Versions: jbossws-cxf-4.0.2
> Environment: JBoss Enterprise Application Platform 6
> Reporter: Tadayoshi Sato
> Assignee: Alessio Soldano
> Labels: cxf
> Fix For: jbossws-cxf-4.2
>
>
> Backport https://issues.apache.org/jira/browse/CXF-4790, which is the root cause. The code below doesn't render {{<soapenv:Subcode>}}.
> {code}
> import javax.xml.soap.SOAPConstants;
> import javax.xml.soap.SOAPFactory;
> import javax.xml.soap.SOAPFault;
> import javax.xml.ws.soap.SOAPFaultException;
> ...
> SOAPFactory factory = SOAPFactory.newInstance(SOAPConstants.SOAP_1_2_PROTOCOL);
> SOAPFault fault = factory.createFault("Operator not found", new QName(SOAPConstants.URI_NS_SOAP_1_2_ENVELOPE, "Receiver"));
> fault.appendFaultSubcode(new QName("...", "OperatorNotFound"));
> ...
> throw new SOAPFaultException(fault);
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 9 months
[JBoss JIRA] (JBWS-3659) XTS services start endpoint with error JBWS022103: Cannot start endpoint in state STARTED
by Alessio Soldano (JIRA)
[ https://issues.jboss.org/browse/JBWS-3659?page=com.atlassian.jira.plugin.... ]
Alessio Soldano updated JBWS-3659:
----------------------------------
Fix Version/s: jbossws-cxf-4.2
> XTS services start endpoint with error JBWS022103: Cannot start endpoint in state STARTED
> -----------------------------------------------------------------------------------------
>
> Key: JBWS-3659
> URL: https://issues.jboss.org/browse/JBWS-3659
> Project: JBoss Web Services
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: jbossws-integration
> Reporter: Amos Feng
> Fix For: jbossws-cxf-4.2
>
>
> It looks like an issue in EndpointPublisherImpl.java
> {code}
> public List<Endpoint> publish(ServiceTarget target, WSEndpointDeploymentUnit unit) throws Exception {
> ...
> // [JBWS-3441] hack - fallback JAXWS invocation handler for dynamically generated deployments
> for (Endpoint ep : dep.getService().getEndpoints()) {
> synchronized(ep) {
> ep.setState(EndpointState.STOPPED);
> ep.setInvocationHandler(new InvocationHandlerJAXWS());
> ep.setState(EndpointState.STARTED);
> }
> }
> ...
> }
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 9 months
[JBoss JIRA] (JBWS-3659) XTS services start endpoint with error JBWS022103: Cannot start endpoint in state STARTED
by Alessio Soldano (JIRA)
[ https://issues.jboss.org/browse/JBWS-3659?page=com.atlassian.jira.plugin.... ]
Alessio Soldano updated JBWS-3659:
----------------------------------
Assignee: Jim Ma
> XTS services start endpoint with error JBWS022103: Cannot start endpoint in state STARTED
> -----------------------------------------------------------------------------------------
>
> Key: JBWS-3659
> URL: https://issues.jboss.org/browse/JBWS-3659
> Project: JBoss Web Services
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: jbossws-integration
> Reporter: Amos Feng
> Assignee: Jim Ma
> Fix For: jbossws-cxf-4.2
>
>
> It looks like an issue in EndpointPublisherImpl.java
> {code}
> public List<Endpoint> publish(ServiceTarget target, WSEndpointDeploymentUnit unit) throws Exception {
> ...
> // [JBWS-3441] hack - fallback JAXWS invocation handler for dynamically generated deployments
> for (Endpoint ep : dep.getService().getEndpoints()) {
> synchronized(ep) {
> ep.setState(EndpointState.STOPPED);
> ep.setInvocationHandler(new InvocationHandlerJAXWS());
> ep.setState(EndpointState.STARTED);
> }
> }
> ...
> }
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 9 months
[JBoss JIRA] (JBWS-3659) XTS services start endpoint with error JBWS022103: Cannot start endpoint in state STARTED
by Amos Feng (JIRA)
[ https://issues.jboss.org/browse/JBWS-3659?page=com.atlassian.jira.plugin.... ]
Amos Feng updated JBWS-3659:
----------------------------
Description:
It looks like an issue in EndpointPublisherImpl.java
{code}
public List<Endpoint> publish(ServiceTarget target, WSEndpointDeploymentUnit unit) throws Exception {
...
// [JBWS-3441] hack - fallback JAXWS invocation handler for dynamically generated deployments
for (Endpoint ep : dep.getService().getEndpoints()) {
synchronized(ep) {
ep.setState(EndpointState.STOPPED);
ep.setInvocationHandler(new InvocationHandlerJAXWS());
ep.setState(EndpointState.STARTED);
}
}
...
}
{code}
> XTS services start endpoint with error JBWS022103: Cannot start endpoint in state STARTED
> -----------------------------------------------------------------------------------------
>
> Key: JBWS-3659
> URL: https://issues.jboss.org/browse/JBWS-3659
> Project: JBoss Web Services
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: jbossws-integration
> Reporter: Amos Feng
>
> It looks like an issue in EndpointPublisherImpl.java
> {code}
> public List<Endpoint> publish(ServiceTarget target, WSEndpointDeploymentUnit unit) throws Exception {
> ...
> // [JBWS-3441] hack - fallback JAXWS invocation handler for dynamically generated deployments
> for (Endpoint ep : dep.getService().getEndpoints()) {
> synchronized(ep) {
> ep.setState(EndpointState.STOPPED);
> ep.setInvocationHandler(new InvocationHandlerJAXWS());
> ep.setState(EndpointState.STARTED);
> }
> }
> ...
> }
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 9 months