feat: first draft of JMS Binding Objects #193
Conversation
adamretter
requested review from
KhudaDad414,
derberg,
fmvilas,
dalelane,
smoya,
char0n and
asyncapi-bot-eve
as code owners
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
There was a problem hiding this comment.
Welcome to AsyncAPI. Thanks a lot for creating your first pull request. Please check out our contributors guide useful for opening a pull request.
Keep in mind there are also other channels you can use to interact with AsyncAPI community. For more details check out this issue.
adamretter
changed the title
adamretter
changed the title
|
It would be great to see this PR merged. We are using AsyncAPI together with JMS in a major project right now. |
|
@rwalpole good to hear, whould you mind joining the review of proposed initial jms binding spec? |
adamretter
force-pushed
the
jms-bindings
branch
from
ec186b5
to
dbc31fd
Compare
|
@derberg @KhudaDad414 @rwalpole I hope I have addressed all of the review comments that you had. Thanks for the feedback :-) I think it is now ready for a second round of review... |
|
LGTM but from the perspective of bindings repo maintainer, not @KhudaDad414 please have another look on JSON Schemas @rwalpole anything else from your side @MichaelDavisSolace I think you use JMS at Solace afaik...at least I think you asked about JMS binding one time. Would you have time to look at this PR? @rcarrascosps you created #87 so maybe you want to join review? @fmvilas anything from your side? @adamretter Let's give these folks a week for reply. In the meantime can you clarify if you can become a maintainer of this specific binding? just like we have others in https:/asyncapi/bindings/blob/master/CODEOWNERS |
@derberg This work was done on behalf of one of my clients; so I can maintain it only for as long as they are asking me to do so. |
There was a problem hiding this comment.
I think this helps clarify that the server binding could be from a JMS Provider and that the resulting AsyncAPI doc might include more than one binding. Moving forward it might be useful to solve the JMS Provider flag in a more generic way by adding that into the provider binding or protocol binding (in the case of something like AMQP).
|
Any updates on this please? |
|
@derberg any updates on this please? |
|
@adamretter sorry, was out on holidays. I see that @rcoppen have a 👍🏼 and @SrfHead is ready to be codeowner here, so please go ahead and update in the PR the |
adamretter
dismissed stale reviews from KhudaDad414, rcoppen, derberg, and dalelane
via
b55f2a9
|
@derberg Thanks. I hope you had a nice holiday? I have now committed the |
|
@KhudaDad414 please approve again. No changes to the binding, @adamretter was just adding |
|
@jonaslagoni we are letting in a new binding. Anything we should remember to do because of coming 3.0? get schemas in |
Nothing tbh, you just have the same question as I gave the other codeowners @adamretter @rcoppen @SrfHead: #182 (comment) You can find a lot of information about the changes here: #182 (comment) Also happy to help out, and feel free to join our spec 3.0 meetings if you have questions you want answered live 🙂 |
|
/rtm |
|
@adamretter @rcoppen @SrfHead as per @jonaslagoni comment. In short, this binding that was just merged is for AsyncAPI 2.x and you need to make sure it will still be working fine with 3.x. So look on linked materials and any changes need to be done against also, in 3.0 we remove json schemas from this repo, to have them better integrated with current tooling, we move them to https:/asyncapi/spec-json-schemas. So please open up a followup PR to get your bindings in https:/asyncapi/spec-json-schemas/tree/next-major-spec/bindings + make sure they are referenced in respective |
Closes PACT-921
Resolves asyncapi/spec#919
This is a first draft of a set of JMS Binding Objects. There is a lot of variance between JMS Providers in terms of features and capabilities, however these bindings should work with all providers as they stay within the JMS API.
More features could of course be added in future if desirable!