Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jms-dev] Thoughts on JMS 3.0
  • From: Bruno Dutra <brun_dutra@xxxxxxxxxxx>
  • Date: Tue, 17 Sep 2019 05:01:23 +0000
  • Accept-language: pt-BR, en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kcT/YSU0zChfggFQAaxQxK+q55DFXFBI7wyDD69CynI=; b=DgctIwHQx3EDbK3EJRtutoZWS+z5sAMqMQk3PA5qtx5ntELqhSXRVH+e0UDEefMGR4J8n0p1ng4qlo9RUQeFDOvxHKubmbRUJqBVb48X8wZ4R9f2eqZcuzLCdJ5tBNkyVpgU1pNYfPpyv2w/lRNwgm0FywaiMi15IXQnIrA80qOPsxRXKKCShUxsoWA8A0GkZUUJQZN831bybo5QjhMkqgey5hIZbnya6iscJfB9aoJcoWHop0NCcAkCH2UVDFA1r4Ug+D5k1w4gsRpV2/UDt9Hi76wT7BjXfx16kogN5EkE+IakDYLDvCVl2776Z0+GshUP1CuhOD+ZMHWFp6PLFg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Teye1tRZewvulDHJkhnd6R00wML87mN/QBZ9xcOBdoweDHh5frknaDVacBRX4i2lLU2WL9rK3viXiRxQzUObB4oHG4LkalMUUfWp+WWW+xs2WmuHPR1i+XNUg+sfgk9UV3XaJCgzufnM5i5GRqh8aGJ1s1eqxPL+f7gT7pZtPzuiDgzAlYZyAxNShXHJfdcCV7D4PjDEue7XmpCX/ktAnJhqCbjUODtZVs/cyR3sAzHMRCFR1sMxVGmVPhWTbt471okM2S+XqCd9nZfWQaXMCI+Z20xNZKHHjdy6uISM4Ne+U4iD852cJiseV73qupm35scmXpif76Bi3E07h5AM8Q==
  • Delivered-to: jms-dev@xxxxxxxxxxx
  • List-archive: <https://www.eclipse.org/mailman/private/jms-dev>
  • List-help: <mailto:jms-dev-request@eclipse.org?subject=help>
  • List-subscribe: <https://www.eclipse.org/mailman/listinfo/jms-dev>, <mailto:jms-dev-request@eclipse.org?subject=subscribe>
  • List-unsubscribe: <https://www.eclipse.org/mailman/options/jms-dev>, <mailto:jms-dev-request@eclipse.org?subject=unsubscribe>
  • Thread-index: AQHVazg4RW7DWTgATEaCJcmDm6+bnKcrvAohgAEV9gCAAn+WZg==
  • Thread-topic: [jms-dev] Thoughts on JMS 3.0
Hi, I saw a presentation too and I liked the proposal, I just wonder how the management of threads for multiple queues will be done.

Try making a controller similar to the one proposed in the presentation using JavaEE Concurrency. https://github.com/brunodutr/jms-hello-world/blob/master/src/main/java/br/com/bdutra/controller/PessoaController.java

I would like to participate in the discussion to contribute.

From: jms-dev-bounces@xxxxxxxxxxx <jms-dev-bounces@xxxxxxxxxxx> on behalf of Alexey <onodera@xxxxxxx>
Sent: Sunday, September 15, 2019 11:45:30 AM
To: jms developer discussions <jms-dev@xxxxxxxxxxx>
Subject: Re: [jms-dev] Thoughts on JMS 3.0
 

Hello

 

I agree that the ideas are great and would make a lot of existing boilerplate redundant. There’s just one piece of the puzzle that’s missing: how do you link the new listener to a JMS connection?

 

If you take a look at https://github.com/tomitribe/jms-proposals/blob/master/all-together/src/test/java/org/example/BuildAndNotify.java, it’s just a @MessageConsumer, so there must be a place in the code that creates the correct connection factory and attaches the consumer to the correct connection. This is something that shouldn’t be an implementation detail of a Jakarta EE application server, as I hope to see Jakarta Messaging 100% usable in lightweight applications.

 

Another piece of the same code that I linked to above that bothers me is the creation of the new strongly-typed client. First of all, it should probably be injected into the class instead of the connection factory. And secondly, a lot of JMS code replies to the queue specified in the ReplyTo header, so a non-void listener method could be annotated to indicate the way its return value should be converted to the message to be sent to that queue.

 

Best regards,

Alexey Marin

 

From: ghzooooon@xxxxxxxxx
Sent: Sunday, September 15, 2019 01:10
To: jms developer discussions
Subject: Re: [jms-dev] Thoughts on JMS 3.0

 

Hi everyone,

I really love the ideas on David's presentation, also great work Rüdiger.


Hi all,

I just watched the presentation David gave on Jakarta Messaging 3.0 in the JakartaOne livestream, and I loved it. This is really what JMS needs and it probably just takes the right time for a revolution like this to become a reality.

Back in 2010 I was coding a lot of JMS senders and receivers, so I turned my pain with writing all that boiler plate code into what I termed MessageApi (https://github.com/t1/message-api), which was based roughly on the same ideas as JMS 3.0. I even joined the JMS EG to help promote it into a standard, but it was obviously way too early. It’s wonderful to see something similar to happen now; it seems that some ideas are just destined to become reality!

I haven’t worked with JMS for the last 5 years or so, so there was no progress from my side any more. Maybe you’ll find my old input worth taking a look at.


Kind regards,
Rüdiger
 
_______________________________________________
jms-dev mailing list
jms-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jms-dev

 

Back to the top