[
https://issues.apache.org/jira/browse/ARTEMIS-4716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17838280#comment-17838280
]
Justin Bertram edited comment on ARTEMIS-4716 at 4/17/24 4:36 PM:
------------------------------------------------------------------
bq. There is no such thing as "Jakarta SE", only "Jakarta EE".
There may be no such thing as _Jakarta SE_ per se, but the most common
JMS/Jakarta Messaging use-case is in a Java SE context (i.e. not in an EE
container). This use-case involves basic clients sending and receiving messages
and includes frameworks like Spring. Clients still use Jakarta classes in this
Java SE context. The {{artemis-jakarta-client}} (which is based on the
{{artemis-jms-client}}) is provided to users for this purpose. The presence of
_jakarta_ in the name of the package does *not* equate to _EE_. Classes in the
{{jakarta}} namespace (and the {{javax}} namespace before it) have always been
viable in a Java SE context.
bq. Your package being named "jakarta" is where all my expectations come from...
I'm not 100% clear on what your expectations were, but as this conversation
continues it seems perhaps your expectations were misplaced.
bq. And a library author should value convenience, don't you think?
In general, I agree. Convenience should be valued. However, as with all things
it must be balanced with other priorities, some of which may actually compete
directly with convenience, but I digress.
bq. In any event, CDI or JNDI, I'm not picky, as long as there are clear
instructions stating the preferred way to use the library.
>From an implementer's perspective I'm not sure there is a clear preference.
>I'd say use whichever best fits your use-case.
bq. I don't think I can quite use WildFly as a template to integrate
"artemis-jakarta-client" in my application, can I?
You can't use it as a _template_ per se, but it's worth noting how WildFly
manages the integration. Most of the "hundreds and hundreds of lines" of code
you saw deals with configuring and managing the embedded broker. That's not
particularly relevant to your use-case. The main things it does to help EE
applications directly are (1) deploying the ActiveMQ Artemis JCA RA (which
enables MDB use-cases and provides connection pooling and XA support for any
messaging client running in the container) and (2) binding connection factories
into JNDI (which mainly enable connectivity from remote messaging clients).
There are some more nuances in there, but those are the main two things that
would impact someone in your situation. These are the kinds of things you'd
want to configure on _any_ application server with regards to messaging
integration.
bq. What I meant is, does any project using a Jakarta EE implementation (one
that doesn't already come with ActiveMQ, obviously) ever used
"artemis-jakarta-client" with dependency injection (or even at all)?
I can't say for sure that anybody has ever used {{artemis-jakarta-client}} _as
such_ to integrate ActiveMQ Artemis with a Jakarta EE container. Typically
folks would use the ActiveMQ Artemis JCA RA for that (which includes
{{artemis-jakarta-client}}) as it's the standard path for integration like
this. That said, there are containers that don't require a specific JCA RA for
messaging integration since not all JMS implementations provide a JCA RA.
bq. You presume it is possible, but how do you know? You must have tested it at
some point, right?
I've deployed the ActiveMQ Artemis JCA RA to various application servers in the
(long ago) past.
bq. I don't know why you see this as beyond the scope of Artemis'
documentation...
The EE space is big and even the messaging subset of the EE space is big. This
space is already covered by the relevant specifications, tutorials & docs from
Sun/Oracle, and docs from particular application servers. All this stuff is
beyond the scope of the ActiveMQ Artemis documentation just like all the
nuances of the JMS/Jakarta Messaging API are.
bq. ...it is definitely useful to know how to use the "artemis-jakarta-client"
package.
I think this may be where the real confusion is. As noted previously, the
_jakarta_ in {{artemis-jakarta-client}} does *not* equate to _EE_.
bq. Without even one usage example, it makes using the package very hard.
The {{artemis-jakarta-client}} can be used anywhere the {{artemis-jms-client}}
is used and we have [_lots_ of
examples|https://github.com/apache/activemq-artemis-examples] for that. We
don't have EE examples because that's beyond the scope of our documentation.
The EE docs from Oracle combined with those from your application server should
suffice for that. If they don't then I suggest you take that up with your
application server vendor/community.
bq. ...maybe is just the name of the package which is wrong...
I don't think the name of the package is wrong. The naming simply reflects the
namespace of the implementation. Using _jakarta_ doesn't mean _EE_ now just
like _javax_ didn't mean _EE_ in the past.
bq. ...none of my expectations hold because it isn't really meant to be an
integration of Artemis with Jakarta (EE).
I think this is essentially correct.
was (Author: jbertram):
bq. There is no such thing as "Jakarta SE", only "Jakarta EE".
There may be no such thing as _Jakarta SE_ per se, but the most common
JMS/Jakarta Messaging use-case is in a Java SE context (i.e. not in an EE
container). This use-case involves basic clients sending an receiving messages
and includes frameworks like Spring. Clients still use Jakarta classes in this
Java SE context. The {{artemis-jakarta-client}} (which is based on the
{{artemis-jms-client}}) is provided to users for this purpose. The presence of
_jakarta_ in the name of the package does *not* equate to _EE_. Classes in the
{{jakarta}} namespace (and the {{javax}} namespace before it) have always been
viable in a Java SE context.
bq. Your package being named "jakarta" is where all my expectations come from...
I'm not 100% clear on what your expectations were, but as this conversation
continues it seems perhaps your expectations were misplaced.
bq. And a library author should value convenience, don't you think?
In general, I agree. Convenience should be valued. However, as with all things
it must be balanced with other priorities, some of which may actually compete
directly with convenience, but I digress.
bq. In any event, CDI or JNDI, I'm not picky, as long as there are clear
instructions stating the preferred way to use the library.
>From an implementer's perspective I'm not sure there is a clear preference.
>I'd say use whichever best fits your use-case.
bq. I don't think I can quite use WildFly as a template to integrate
"artemis-jakarta-client" in my application, can I?
You can't use it as a _template_ per se, but it's worth noting how WildFly
manages the integration. Most of the "hundreds and hundreds of lines" of code
you saw deals with configuring and managing the embedded broker. That's not
particularly relevant to your use-case. The main things it does to help EE
applications directly are (1) deploying the ActiveMQ Artemis JCA RA (which
enables MDB use-cases and provides connection pooling and XA support for any
messaging client running in the container) and (2) binding connection factories
into JNDI (which mainly enable connectivity from remote messaging clients).
There are some more nuances in there, but those are the main two things that
would impact someone in your situation. These are the kinds of things you'd
want to configure on _any_ application server with regards to messaging
integration.
bq. What I meant is, does any project using a Jakarta EE implementation (one
that doesn't already come with ActiveMQ, obviously) ever used
"artemis-jakarta-client" with dependency injection (or even at all)?
I can't say for sure that anybody has ever used {{artemis-jakarta-client}} _as
such_ to integrate ActiveMQ Artemis with a Jakarta EE container. Typically
folks would use the ActiveMQ Artemis JCA RA for that (which includes
{{artemis-jakarta-client}}) as it's the standard path for integration like
this. That said, there are containers that don't require a specific JCA RA for
messaging integration since not all JMS implementations provide a JCA RA.
bq. You presume it is possible, but how do you know? You must have tested it at
some point, right?
I've deployed the ActiveMQ Artemis JCA RA to various application servers in the
(long ago) past.
bq. I don't know why you see this as beyond the scope of Artemis'
documentation...
The EE space is big and even the messaging subset of the EE space is big. This
space is already covered by the relevant specifications, tutorials & docs from
Sun/Oracle, and docs from particular application servers. All this stuff is
beyond the scope of the ActiveMQ Artemis documentation just like all the
nuances of the JMS/Jakarta Messaging API are.
bq. ...it is definitely useful to know how to use the "artemis-jakarta-client"
package.
I think this may be where the real confusion is. As noted previously, the
_jakarta_ in {{artemis-jakarta-client}} does *not* equate to _EE_.
bq. Without even one usage example, it makes using the package very hard.
The {{artemis-jakarta-client}} can be used anywhere the {{artemis-jms-client}}
is used and we have [_lots_ of
examples|https://github.com/apache/activemq-artemis-examples] for that. We
don't have EE examples because that's beyond the scope of our documentation.
The EE docs from Oracle combined with those from your application server should
suffice for that. If they don't then I suggest you take that up with your
application server vendor/community.
bq. ...maybe is just the name of the package which is wrong...
I don't think the name of the package is wrong. The naming simply reflects the
namespace of the implementation. Using _jakarta_ doesn't mean _EE_ now just
like _javax_ didn't mean _EE_ in the past.
bq. ...none of my expectations hold because it isn't really meant to be an
integration of Artemis with Jakarta (EE).
I think this is essentially correct.
> Improve Jakarta Messaging / JMS documentation
> ---------------------------------------------
>
> Key: ARTEMIS-4716
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4716
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: JMS
> Affects Versions: 2.33.0
> Reporter: Daniel Martin
> Priority: Minor
>
> I'm struggling to understand [these
> instructions|https://activemq.apache.org/components/artemis/documentation/latest/using-jms.html]
> to use Artemis in the context of Jakarta Messaging which perhaps could be
> updated / simplified / improved.
> At the moment, I'm depending on {{artemis-jakarta-client}} and manually
> instantiating {{ActiveMQConnectionFactory}}. While investigating a memory
> leak that may come from my usage of ActiveMQ, I wanted to simplify this part
> and rely on dependency injection instead. However, I don't begin to
> understand how to do such thing.
> My expectation was to be able to use the {{@Inject}} annotation to get a
> reference to a {{ConnectionFactory}}, {{JMSContext}}, or similar and to be
> able to provide configuration such as broker address and credentials
> _somewhere_ as to end up with a reference to a {{Connection}} which is
> ultimately what I need. Is this possible? What's the recommended way? Is
> there any (working) reference examples?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
