[JBoss JIRA] Created: (JBESB-1992) EBWS Security needs rework and unification
by Jiri Pechanec (JIRA)
EBWS Security needs rework and unification
------------------------------------------
Key: JBESB-1992
URL: https://jira.jboss.org/jira/browse/JBESB-1992
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Rosetta, Security, Web Services
Affects Versions: 4.4
Reporter: Jiri Pechanec
There is now security implementation at two levels
- specifying webservice="security" attribute enables JBossWS security handler
- specifying security elemnt enables WSSecuritySoapExtractor
The WSSecuritySoapExtractor operates at XML/DOM level which means that is completely independent on JBossWS security handler.
Please consider unifying the configuration and JBossWS facility use.
Morever check the WSSecurityInfoExtractor if there is also a way to use JBossWS functions instead of Smooks parsing.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 9 months
[JBoss JIRA] Created: (JBESB-2273) Extend BusinessRulesProcessor action to support entry-point
by Burr Sutter (JIRA)
Extend BusinessRulesProcessor action to support entry-point
-----------------------------------------------------------
Key: JBESB-2273
URL: https://jira.jboss.org/jira/browse/JBESB-2273
Project: JBoss ESB
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Affects Versions: 4.4 CP1
Reporter: Burr Sutter
BusinessRulesProcessor allows for a "stateful" rules session as of ESB 4.4, however, it doesn't allow subsequent inbound messages to inject those messages into the already existing stateful rules session via the entry-point API.
<action
class="org.jboss.soa.esb.actions.BusinessRulesProcessor"
name="OrderDiscountBasedOnCustomerHistory">
<property name="ruleSet"
value="OrderDiscountOnMultipleOrders.drl" />
<property name="ruleReload" value="false" />
<property name="stateful" value="true" />
<property name="object-paths">
<object-path esb="body.TheOrderHeader" />
<object-path esb="body.TheCustomer" />
</property>
</action>
We might extend this like so:
<object-path esb="body.TheOrderHeader" entry-point="OrderStream" />
<object-path esb="body.TheCustomer" entry-point="CustomerStream" />
The date time stamp should be based on message DOB but perhaps overrideable here as well.
The use of entry-points would also mean that the Rules session is "self cleaning" as it automatically garbage collects stale facts.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 9 months
[JBoss JIRA] Created: (JBESB-3021) SOAPProxies on different services shares configuration
by Jiri Pechanec (JIRA)
SOAPProxies on different services shares configuration
------------------------------------------------------
Key: JBESB-3021
URL: https://jira.jboss.org/jira/browse/JBESB-3021
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Web Services
Affects Versions: 4.7
Environment: ER4
Reporter: Jiri Pechanec
Priority: Critical
Attachments: soapproxy-breaker.zip
If a jboss-esb.xml file contains definition of two services and each uses SOAPProxy, then the configuration is shared between them.
Check the attached example
1) Remove Proxy-breaker service from the config file, deploy and do ant runtest. The execution is performed correctly and target service is invoked.
2) Enable Proxy-breaker service but disable <http-client-property name="protocol-socket-factory"... in it, deploy and do ant run test. Although you are invoking the first service the invocation will fail due to strict SSL setting.
3) Enable Proxy-breaker service and enable <http-client-property name="protocol-socket-factory"... in it, deploy and do ant run test. The execution is performed correctly and target service is invoked.
It proves that SOAPProxy settings on Proxy-breaker service DIRECTLY infulennces SOAPProxy settings of Proxy service.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 10 months
[JBoss JIRA] Created: (JBESB-2903) Backwards incompatibility with HttpResponse
by Lukáš Petrovický (JIRA)
Backwards incompatibility with HttpResponse
-------------------------------------------
Key: JBESB-2903
URL: https://jira.jboss.org/jira/browse/JBESB-2903
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Rosetta
Reporter: Lukáš Petrovický
Fix For: 4.7
In SOA-P 5.0 ER1 (which leverages ESB 4.7 trunk), we found the following backwards-incompatible change while compiling one of our tests (based on the http_2way_ssl QS):
[javac] /home/lpetrovi/Work/QE/tests/quickstarts/https_2way_ssl/src/org/jboss/soa/esb/samples/https/client/HttpResponsePrinter.java:35: incompatible types
[javac] found : java.util.List<org.jboss.soa.esb.http.HttpHeader>
[javac] required: java.util.List<org.jboss.soa.esb.actions.routing.http.HttpHeader>
[javac] List<HttpHeader> headers = httpResponse.getHeaders();
[javac] ^
[javac] Note: /home/lpetrovi/Work/QE/tests/quickstarts/https_2way_ssl/src/org/jboss/soa/esb/samples/https/client/HttpResponsePrinter.java uses or overrides a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
As you can see, the getHeaders() method now returns a different type than it used to. In my opinion, breaking backwards compatibility would be OK when switching to a new major version of ESB, but this is not the case.
I also noticed that the QS in question has been updated in the ESB to reflect this change, so I expect the view of the ESB team is that this is not a valid bug.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 10 months
[JBoss JIRA] Created: (JBESB-2913) Only one JMS endpoint accessible when more available
by Lukáš Petrovický (JIRA)
Only one JMS endpoint accessible when more available
----------------------------------------------------
Key: JBESB-2913
URL: https://jira.jboss.org/jira/browse/JBESB-2913
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Web Services
Affects Versions: 4.7
Reporter: Lukáš Petrovický
Using enhanced webservice_consumer1 QS (to be attached soon), we deploy an ESB service with two different JMS listeners:
<jms-provider name="JBossMQ" connection-factory="ConnectionFactory">
...
<jms-bus busid="quickstartEsbChannel">
<jms-message-filter dest-type="QUEUE" dest-name="queue/quickstart_webservice_consumer1_esb" />
</jms-bus>
<jms-bus busid="quickstartEsbChannel2">
<jms-message-filter dest-type="QUEUE" dest-name="queue/quickstart_webservice_consumer1_esb2" />
</jms-bus>
</jms-provider>
...
<listeners>
<jms-listener name="JMS-ESBListener" busidref="quickstartEsbChannel"/>
<jms-listener name="JMS-ESBListener2" busidref="quickstartEsbChannel2"/>
...
</listeners>
Using JBoss ESB Service list (http://localhost:8080/contract/), we can see the service correctly with two endpoints (jms:localhost:1099#queue/quickstart_webservice_consumer1_esb, jms:localhost:1099#queue/quickstart_webservice_consumer1_esb2). However, both these endpoints share the same WSDL and that only contains a port for the first listener:
...
<service name="HelloWorldWSService">
<port binding="tns:HelloWorldBinding" name="HelloWorldPort">
<soap:address location="jms:/#queue/quickstart_webservice_consumer1_esb"/>
</port>
</service>
...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 10 months