>Please

Please? You're stating that JMS is not even at Java SE 1.4, then I give you simple prove that it's at Java SE 7, and your response is "please"?

>Did you ever actually use JMS in production?

Yes, rather intensively.

>If so did you use MDBs?

Yes

>If so did you use whatever happened to be the default JMS implementation of the server or did you use a stand alone message broker?

The default implementation, with a JMS bridge. This is a rather powerful setup. The application posts and listens to what are local queues using the default provider. The bridge then transports these to the remote destination.

>how did you associate the RAR with the MDB and what did activation specs look like

Since I didn't use a standalone provider, I didn't go that route. But I DO know that you've changed specs here and are barking against the wrong tree. A RAR is JCA and MDB is EJB, we were talking about JMS here.

While I don't have much experience with JCA, I also do know that things have been simplified a while ago. Take a look at this article: http://robertpanzer.github.io/blog/2014/inboundra-nointfmdbs...

Or read some of David Blevins posts about this topic.

JCA and particular the activation config annotation is rather ugly, I'll agree to that. It's a direct translation of the old XML version and there's room for simplification here. Hey, if you have some ideas why not file a JIRA issue?

>As I said, I take it you never actually tried to do that yourself. I did it for the issues listed above and more and absolutely nothing happened.

Do you have a link to the issues you filed? I'm rather curious now.

When I look at the JIRAs of the Java EE specs I see a lot of issues that were filed by community users and were indeed implemented.

JSF is most well known here. Take a look at: https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC

Check what has been implemented in JSF 2 and check that with the issues that were filed. This one makes that rather easy: http://jdevelopment.nl/jsf-22 Now see who filed a lot of those issues. See?

If we look at JMS and I grab this issue, then it's a community member and the issue got included in Java EE: https://java.net/jira/browse/JMS_SPEC-63

Now just grab whatever other spec, say JPA, and look at another feature that was introduced a while back: https://java.net/jira/browse/JPA_SPEC-26

What do you know, AGAIN a community member. You can go on and on. MANY issues that actually ended up in Java EE were proposed by community members.

> It doesn't help that you can't create pull requests for Java EE

Oh? So what is this: https://github.com/spericas/ozark/pulls?q=is%3Apr+is%3Aclose...

And not every implementation is on Github, but many RI implementations take the equivalent of pull requests; patches attached to issues. Boils down to the exact same thing.

Yes, I too would like that every implementation and specifically the RI ones were all on Github, but there are many great other open source projects that aren't on Github either and this doesn't make them any less open source or free. In fact, I just called my old friend RMS (we go way back) and according to him there's nothing in OSI that requires projects to be on Github.