November 2015 - esb-issues - Jboss List Archives

by Mark Little (JIRA)

[ https://issues.jboss.org/browse/JBESB-765?page=com.atlassian.jira.plugin.... ] Mark Little closed JBESB-765. ----------------------------- Resolution: Out of Date > AMQP support > ------------ > > Key: JBESB-765 > URL: https://issues.jboss.org/browse/JBESB-765 > Project: JBoss ESB > Issue Type: Feature Request > Components: Transports > Reporter: Mark Little > Assignee: Mark Little > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBESB-655) Add CORBA support

by Mark Little (JIRA)

[ https://issues.jboss.org/browse/JBESB-655?page=com.atlassian.jira.plugin.... ] Mark Little closed JBESB-655. ----------------------------- Resolution: Out of Date > Add CORBA support > ----------------- > > Key: JBESB-655 > URL: https://issues.jboss.org/browse/JBESB-655 > Project: JBoss ESB > Issue Type: Feature Request > Components: Transports > Affects Versions: 4.2 Milestone Release 2 > Reporter: Mark Little > Assignee: Mark Little > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBESB-740) Allow for different message types on the same bus

by Mark Little (JIRA)

[ https://issues.jboss.org/browse/JBESB-740?page=com.atlassian.jira.plugin.... ] Mark Little closed JBESB-740. ----------------------------- Resolution: Out of Date > Allow for different message types on the same bus > ------------------------------------------------- > > Key: JBESB-740 > URL: https://issues.jboss.org/browse/JBESB-740 > Project: JBoss ESB > Issue Type: Feature Request > Components: Rosetta > Affects Versions: 4.2 Milestone Release 3 > Reporter: Mark Little > Assignee: Mark Little > > It was always the aim to support different message formats (e.g., not just Java serializable!) We do that, but unfortunately none of the senders/receivers use anything other than the default message format (serializable). So it's not possible to send multiple types over the same ESB deploymend. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBESB-804) Remove base64 encoding from DBMessageStoreImpl

by Mark Little (JIRA)

[ https://issues.jboss.org/browse/JBESB-804?page=com.atlassian.jira.plugin.... ] Mark Little closed JBESB-804. ----------------------------- Resolution: Done > Remove base64 encoding from DBMessageStoreImpl > ---------------------------------------------- > > Key: JBESB-804 > URL: https://issues.jboss.org/browse/JBESB-804 > Project: JBoss ESB > Issue Type: Task > Components: Message Store > Affects Versions: 4.2 Milestone Release 3 > Reporter: Mark Little > Assignee: Mark Little > Priority: Trivial > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBESB-916) CBR with protocol translation

by Mark Little (JIRA)

[ https://issues.jboss.org/browse/JBESB-916?page=com.atlassian.jira.plugin.... ] Mark Little closed JBESB-916. ----------------------------- Resolution: Done > CBR with protocol translation > ----------------------------- > > Key: JBESB-916 > URL: https://issues.jboss.org/browse/JBESB-916 > Project: JBoss ESB > Issue Type: Feature Request > Components: Content Based Routing > Affects Versions: 4.2 Milestone Release 3 > Reporter: Mark Little > Assignee: Mark Little > Priority: Optional > > More of a reminder to me to check: can the CBR be used to do opaque transport bridging, e.g., a JMS comes in but an HTTP goes out. Plus, bi-directional so bridged requests have corresponding bridged responses. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBESB-852) Retransmission for fail-over is a property of the transport requirement (or service contract)

by Mark Little (JIRA)

[ https://issues.jboss.org/browse/JBESB-852?page=com.atlassian.jira.plugin.... ] Mark Little closed JBESB-852. ----------------------------- Resolution: Out of Date > Retransmission for fail-over is a property of the transport requirement (or service contract) > --------------------------------------------------------------------------------------------- > > Key: JBESB-852 > URL: https://issues.jboss.org/browse/JBESB-852 > Project: JBoss ESB > Issue Type: Feature Request > Components: Transports > Affects Versions: 4.2 Milestone Release 3 > Reporter: Mark Little > Assignee: Mark Little > > What we have now is great and fine with our current purposes. (Hence settin this to a 5.0). > But we should not be reusing the general MessageStore for this either, since that is intended for audit trail purposes and may have specific security requirements places on it by the deployer. The need for a retransmission/redeliver store may not be needed at all by some transports, e.g., WS-RX, because it's built in to the implementation. But it may be for others (e.g., HTTP). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBESB-802) ServiceInvoker should hide EPRs

by Mark Little (JIRA)

[ https://issues.jboss.org/browse/JBESB-802?page=com.atlassian.jira.plugin.... ] Mark Little closed JBESB-802. ----------------------------- Resolution: Out of Date > ServiceInvoker should hide EPRs > ------------------------------- > > Key: JBESB-802 > URL: https://issues.jboss.org/browse/JBESB-802 > Project: JBoss ESB > Issue Type: Feature Request > Components: Rosetta > Affects Versions: 4.2 Milestone Release 3 > Reporter: Mark Little > Assignee: Mark Little > > EPRs were never intended to be used by the majority of developers. They are the "physical" address of individual services. The "logical" name is the service name, that might map down to one or more EPRs. But most of the time developers would be using the logical name. At least that was the approach in the original pre-Rosetta days. By the time you get down to working with EPRs and headers (Call) you're really working at the lowest level and talking about a specific Message going to a specific service instance. > The higher level abstraction should be working only in terms of the message payload (Body, Attachments, etc.) and service names. FaultTo, To, ReplyTo etc. would be abstracted to service names by the API. The implementation would hide the mapping of service name to specific EPRs when necessary to ultimately deliver a message. > Shouldn't ServiceInvoker work in the same way? On the one hand it seems to be one SI instance per client per service (you create the instance and pass in the servicename [equivalent of defining To]). However, because the deliverSync and deliverAsync work in terms of Messages, it's then entirely possible for that information to be ignored by the user, i.e., you can use any SI instance to deliver a message to any service as long as you define the To field correctly. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBESB-946) Security implications of changing ReplyTo, FaultTo etc.

by Mark Little (JIRA)

[ https://issues.jboss.org/browse/JBESB-946?page=com.atlassian.jira.plugin.... ] Mark Little closed JBESB-946. ----------------------------- Resolution: Out of Date > Security implications of changing ReplyTo, FaultTo etc. > ------------------------------------------------------- > > Key: JBESB-946 > URL: https://issues.jboss.org/browse/JBESB-946 > Project: JBoss ESB > Issue Type: Feature Request > Components: Security > Affects Versions: 4.2 Milestone Release 3 > Reporter: Mark Little > Assignee: Mark Little > > We need to consider the security implications of allowing senders of responses to change the incoming header data structure. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBESB-1013) Retained results Action

by Mark Little (JIRA)

[ https://issues.jboss.org/browse/JBESB-1013?page=com.atlassian.jira.plugin... ] Mark Little closed JBESB-1013. ------------------------------ Resolution: Out of Date > Retained results Action > ----------------------- > > Key: JBESB-1013 > URL: https://issues.jboss.org/browse/JBESB-1013 > Project: JBoss ESB > Issue Type: Feature Request > Components: Rosetta > Affects Versions: 4.2 > Reporter: Mark Little > Assignee: Mark Little > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBESB-654) JBI integration

by Mark Little (JIRA)

[ https://issues.jboss.org/browse/JBESB-654?page=com.atlassian.jira.plugin.... ] Mark Little closed JBESB-654. ----------------------------- Resolution: Out of Date > JBI integration > --------------- > > Key: JBESB-654 > URL: https://issues.jboss.org/browse/JBESB-654 > Project: JBoss ESB > Issue Type: Feature Request > Components: JBI > Affects Versions: 4.2 Milestone Release 2 > Reporter: Mark Little > Assignee: Mark Little > > Can we support JBI integration as a first step to JBI compliance? Have something that allows the ESB to receive messages over JBossESB transports and then deliver them as JBI messages to other components. Plus, support sending JBI messages out over JBossESB transports. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 5 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

esb-issues November 2015