[needusername]

> generics

Please

http://docs.oracle.com/javaee/7/api/javax/jms/ConnectionMeta... http://docs.oracle.com/javaee/7/api/javax/jms/MapMessage.htm...

ever heard of enums?

http://docs.oracle.com/javaee/7/api/javax/jms/DeliveryMode.h... http://docs.oracle.com/javaee/7/api/javax/jms/Session.html#A...

Did you read the the JMS Spec or the Javadoc of JMSException http://docs.oracle.com/javaee/7/api/javax/jms/JMSException.h...? Where does it mentions the relationship between #getLinkedException and #getCause?

> The latest API is perfectly fine indeed and doesn't need wrapping by Spring.

Did you ever actually use JMS in production? If so did you listen on a queue? If so did you use MDBs? 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? If you used a stand alone message broker how did you associate the RAR with the MDB and what did activation specs look like?

> If the Spring guys have suggestions to improve the API even further, why don't they just file an issue on the JMS spec tracker?

Are you aware of the politics behind the JCP? Are you aware of the JSRs that were shot down by WebLogic before they were even created?

> You only have to look at the JIRA of the several specs to see how much things that the community suggested went into Java EE. Go ahead, browse through it. You'd be surprised.

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. It doesn't help that you can't create pull requests for Java EE but you can create pull requests for Spring.

[henk53]

>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.

[needusername]

> 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.

Yes, and the only way of listening to a queue without polling or blocking in Java EE that JMS supports in through an MDB. The way you plug a custom JMS provider into Java EE is through a RAR. The way you connect the RAR to the MDB is undefined because "expert group" can't be bothered.

> Take a look at this article: http://robertpanzer.github.io/blog/2014/inboundra-nointfmdbs....

A very good explanation of what's wrong with JMS. The class to be notified and the configuration is the same file. If this was a host you would have the hostname and port of the message broker in the listener class file.

> Hey, if you have some ideas why not file a JIRA issue?

I personally spoke to the spec lead at JavaOne and he couldn't be bothered.

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

Did you or did you not personally file a single issue?

[henk53]

>The way you connect the RAR to the MDB is undefined because "expert group" can't be bothered.

And which expert group might that be? Java EE, JCA, JMS, EJB? There's no JCA EG at the moment, just a (former) spec lead who's available for maintenance. There's also no EJB EG at the moment.

As with any open source project, it's a matter of pushing if you really want to get some train getting forward. Linux is no different. Try persuading those guys to accept your patch. No easy feat.

Some things are just controversial in any project. I remember the endless debates in the Pidgin project about the stupid size of the text input.

In Java EE there are debates about having resources inside the war. Many are against, I argued for a long time that they should also be inside, and maybe my emails and posts helped since in Java EE 7 almost every resource can be defined in the war.

But if you first asked it, and asked the wrong person (e.g. this Jesper guy from JBoss) you'll get a NO, GO AWAY! If you are immediately turned down by that, nothing ever changes.

There's this other guy in Java EE who keeps bringing up the topic of standardizing logging, who doesn't seem to get very far. Some things are just not accepted, other things are a matter of talking to the right people, finding like minded souls and keep pushing. Again, no different from any other (big) open source project.

In this case, I'm simply not an expert on JCA, so I can't say if you're right or wrong. You did also say that JMS was not even at Java 1.4, which was clearly wrong, so I do take what you say with a grain of salt if you don't mind (no offense, really).

If this is indeed as badly defined as you claim, please, make your voice heard. Create a JIRA issue, tweet about it (cc @Java_ee or @dblevins). I know David has been fighting to improve JCA and make it simpler.

No product is perfect. If Java EE was utterly perfect than we would not have needed Java EE 8. But guess what, Spring is far from perfect either and by the same token if it was there would not have been a need for Spring 4 last year and there would not have been a need for the next version.

>A very good explanation of what's wrong with JMS.

The article is about JCA and EJB, I don't see JMS itself there.

>I personally spoke to the spec lead at JavaOne and he couldn't be bothered.

Which spec lead are you talking about? Nigel from JMS, or someone else?

>Did you or did you not personally file a single issue?

I love it how you conveniently evade the "prove" I provided that clearly shows that many features that ended up in Java EE originated from community proposed issues. Likewise, if you switch over to the implementation trackers you'll find that patches originate from the community. Be it for Mojarra (JSF), Hibernate (JPA), or whatever.

Whether I personally filed issues is almost irrelevant in the face of the examples I provided to you. But if you really want to know; yes, I filed a ton of issues. In fact, I filed a bunch from the very nick (henk53) I'm using here, as well as many in name of the customers I've been working for.

Quite a lot were resolved. Some in a short time, others took ridiculously long, but were eventually resolved. And some were never resolved. Geronimo is the one and only where I just could not get through to. Funny thing is that in theory they are the most open of all parties.

[needusername]

> 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.

Have you ever attended a JCP meeting? The number one topic that pops up again and again for years has been open source (OSI) licensed TCK. The only party blocking that for years has been Oracle.

[henk53]

The matter at hand here was pull requests and the implied notion that those didn't happen in the Java EE universe, which I proved (again) was not true.

Instead of just acknowledging that in whatever way you're just evading the issue (again) and switching to another topic.

But to reply this new topic, TCK has been a thorn in the JCP process indeed. Not every spec has a closed TCK. CDI and Bean Validation have open ones, based on Arquillian, with an open source (OSI) license, and an associated issue tracker where everyone can open issues against it.

Now funny thing here is that CDI is rapidly becoming the underpinning of everything in Java EE. It's the core of Java EE's core.

For some other specs like JSF the TCK is unfortunately closed, but the RI (Mojarra) has such an extensive set of effective TCK tests that I wonder if there's anything at all in the TCK that's not covered by the RI tests.

Still, opening up the TCKs is another battle worth fighting.