JBossDeveloper

henk de boer wrote:

 

arjan tijms wrote:

 

My hopes are up that HornetQ introduced something new that does make this possible and I'm eager to find out what that is.

 

Well don't get your hopes up, since HornetQ doesn't have or uses anything like the admin object you showed (I would love to be corrected on this though).

 

The way it seemingly must be done in HornetQ and JBM for that matter is exactly like you mention; fetch the destination out of the JNDI from the remote server and use that. In a way this is a little counter productive if your goal is to prevent each piece of client code creating a new network connection. I'm not sure how intelligent JBoss AS is underneath with automatically caching remote JNDI connections, but I'm afraid this doesn't happen automatically.

 

This leaves you with the choice of either caching the Destination object your self somewhere or just taking the hit and requesting it every time over and over. I'm not sure how thread-safe a destination really is. In JMS connections are thread-safe while sessions, producers and consumers aren't. To the best of my knowledge it's unspecified whether destinations are thread-safe, but I hope someone with more knowledge about this chimes in and gives a better answer.

I don't think this is true. HornetQ doesn't require JNDI to work at all. Both connection factories and destinations can be instantiate on the client side. This is described in the docs and API, and there is an example in the distro that demonstrates this.

Tim Fox wrote:

 

Now, I do know that you can just create destination references on the fly on the client side using HornetQ. By simply using HornetQJMSClient.createXX(), or you can just use session.createQueue()/createTopic() which is part of the standard JMS API. But I don't know if that's the proper/legal *JEE* way of doing things.

I don't know either, which is the reason for me joining this topic and asking

The thing is that you want a reference to a destination that is stored in JNDI on the remote server using some name like /queue/myQueue. But this JNDI name is of course not the 'real name' of the actual destination, but just the place it is stored in JNDI. The Java doc for Destinations says this:

** A <CODE>Destination</CODE> object encapsulates a provider-specific
 * address.
 * The JMS API does not define a standard address syntax. Although a standard
 * address syntax was considered, it was decided that the differences in
 * address semantics between existing message-oriented middleware (MOM)
 * products were too wide to bridge with a single syntax. 

So if you want to re-create the destination reference locally, you'll have to know this 'provider-specific address', right?

I don't think this question is mainly about Java EE. JCA connection pooling is of course, but other then that it's also about using the raw JMS API:

MessageProducer producer = session.createProducer(destination);

As a previous example shows, the resource adapter of Websphere MQ seems to offer a facility that helps the user in creating this destination locally (via org.jboss.resource.deployment.AdminObject).

henk de boer wrote:

 

Tim Fox wrote:

 

Now, I do know that you can just create destination references on the fly on the client side using HornetQ. By simply using HornetQJMSClient.createXX(), or you can just use session.createQueue()/createTopic() which is part of the standard JMS API. But I don't know if that's the proper/legal *JEE* way of doing things.

 

I don't know either, which is the reason for me joining this topic and asking

It's the wrong forum to ask questions about JEE and JCA. We are NOT the experts on that. The JBoss AS, JCA and EJB teams are much better placed to know the answers.

henk de boer wrote:

 

The thing is that you want a reference to a destination that is stored in JNDI on the remote server using some name like /queue/myQueue. But this JNDI name is of course not the 'real name' of the actual destination, but just the place it is stored in JNDI. The Java doc for Destinations says this:

 

** A <CODE>Destination</CODE> object encapsulates a provider-specific
 * address.
 * The JMS API does not define a standard address syntax. Although a standard
 * address syntax was considered, it was decided that the differences in
 * address semantics between existing message-oriented middleware (MOM)
 * products were too wide to bridge with a single syntax. 

 

So if you want to re-create the destination reference locally, you'll have to know this 'provider-specific address', right?

 

I don't think this question is mainly about Java EE. JCA connection pooling is of course, but other then that it's also about using the raw JMS API:

 

All I hear on this thread is JCA, JNDI, EJB. All of these things are part of the *JEE* spec. There's a JNDI forum for JNDI questions too.

henk de boer wrote:

 

 

As a previous example shows, the resource adapter of Websphere MQ seems to offer a facility that helps the user in creating this destination locally (via org.jboss.resource.deployment.AdminObject).

The websphere object is an MBean, that means JMX, yet another part of JEE. So definitely not just JMS.

To summarise, if you want to know about HornetQ or the JMS API, then this is the correct forum. We are experts on that.

if you want to know how JMX, JNDI, EJB, JCA or any other part of JBoss app server works, then there are other forums for that, with people better qualified to answer your questions

henk de boer wrote:

 

 

So if you want to re-create the destination reference locally, you'll have to know this 'provider-specific address', right?

 

No.

All you need is exactly the same information that you would have used in your JNDI lookup. Take a look at the example in the distro.

Tim Fox wrote:

 

So if you want to re-create the destination reference locally, you'll have to know this 'provider-specific address', right?

 

I don't think this question is mainly about Java EE. JCA connection pooling is of course, but other then that it's also about using the raw JMS API:

 

All I hear on this thread is JCA, JNDI, EJB. All of these things are part of the *JEE* spec. There's a JNDI forum for JNDI questions too. [...] The websphere object is an MBean, that means JMX, yet another part of JEE. So definitely not just JMS.

I understand what you mean.

There is a strong separation between different technologies involved, and then there's Java EE which merges all those technologies but it itself also yet another technology. On the one hand there may be some frustration with the developers who get questions in their forum which are outside their domain, but on the other hand there may also be some frustration with the user who does a single high level task (like sending a message), that involves a combination of JCA, JNDI, JMS, Java EE and perhaps EJB and every forum directs the user to ask the question in another forum. The EJB guys say it's a JMS problem, the JNDI guys say it's a JCA problem, etc.

For the record though, I don't think I or the TS have mentioned EJB The MBean itself is indeed JMX technology, but it's not the Websphere object itself. It only helps in creating the object when JBoss AS starts up, but you could do the same in code yourself. Just like your own org.jboss.jms.server.bridge.BridgeService class only functions to help creating the actual object instance of the org.jboss.jms.server.bridge.Bridge class.

I do think we can simplify the problem to just JMS though.

• We have obtained a JMS connection, at that point it doesn't matter anymore that it came from JCA.
• We're not in an EJB
• We want a destination that we only know lives in JNDI, but if we knew the 'provider-specific address', we wouldn't need JNDI.

To end users, it would be very handy if HornetQ offered a simple facility that helped with this, i.e. a POJO (previously MBean), that looked up a requested destination from JNDI, and uses its knowledge of the 'provider-specific address' to recreate it locally.

Tim Fox wrote:

No.

 

All you need is exactly the same information that you would have used in your JNDI lookup. Take a look at the example in the distro.

I'm sorry, I didn't notice this one before writing the previous reply.

So, what you're saying is that basically this 'provider-specifc address' that the JMS doc mentions is in the case of HornetQ simply based on the JNDI name used to store the destination originally. In other words, the JMS spec allows for these two addresses to be completely different, but HornetQ choose to let them be the same by default, right?

If the destination lives under /queue/myQueue, then simply instantiating Destination destination = new JBossDestination("/queue/myQueue") would work.

Okay, I'll do some testing and debugging first and report back after that.

Thanks a lot for your help thus far and sorry for asking questions that may seem obvious

henk de boer wrote:

I do think we can simplify the problem to just JMS though.

 

• We have obtained a JMS connection, at that point it doesn't matter anymore that it came from JCA.
• We're not in an EJB
• We want a destination that we only know lives in JNDI, but if we knew the 'provider-specific address', we wouldn't need JNDI.

 

To end users, it would be very handy if HornetQ offered a simple facility that helped with this, i.e. a POJO (previously MBean), that looked up a requested destination from JNDI, and uses its knowledge of the 'provider-specific address' to recreate it locally.

How is this different from HornetQJMSClient.createQueue()?

Sounds like what you really want here is automatic JNDI lookup caching. If so, this would be a feature for the JBoss JNDI implementation, not HornetQ.

I suggest asking in the JNDI forum, maybe they do this already. Actually I would be surprised if they don't for the EJB use case.

Tim Fox wrote:

How is this different from HornetQJMSClient.createQueue()?

Well, maybe I didn't yet knew about this and didn't fully realize what it could do when you mentioned it earlier

With the help of that it seems it would not be too hard to build something like Adrian's AdminObject that takes a queue name as parameter and binds the Queue created by HornetQJMSClient.createQueue() into the local JNDI. I'll try to give this a shot soon.

Tim Fox wrote:

Sounds like what you really want here is automatic JNDI lookup caching. If so, this would be a 
feature for the JBoss JNDI implementation, not HornetQ.
 
I suggest asking in the JNDI forum, maybe they do this already. Actually I would be surprised if 
they don't for the EJB use case.

You're right, this would be another approach to solve the same problem 'not having to request the destination from JNDI each time'. I'll do some research into this first and then try with the JNDI guys. Thanks!

If I look up examle in HornetQ docs: 7.5 Instantiating JMS resources, then it seems HornetQJMSClient.createQueue does not create simple address wrapper (HornetQQueue) but also do creation of actual queue (managed queue, involve server peer etc).  In 25.1 of manual it says JNDI name is not same as core queue name (/queue/selectorQueue vs jms.queue.selectorQueue).   If we want to make the address wrapper client side, we must still know internal name, not?

No, that method doesn't do anything on the server side.

Anyway, I don't really see what any of this has to do with HornetQ.

As I mentioned earlier, it seems like what you want is some kind of cached JNDI lookup. This would be a feature for the JNDI implementation not HornetQ.

Having said that I would be surprised if the AS doesn't already do this. E.g. with resource-ref which IIRC binds remote JNDI objects into a local (java:) JNDI context.

But it's been many years since I wrote an EJB so I could be wrong. Best to ask the EJB team this one.

Maybe others want to use server to connect to remote hornetQ. 
I just mean Java SE client. I want to create the simple address wrapper. You first said we could use HornetQJMSClient.createQueue for this, but this seems to have 2 problems: 1. It does more than creating simple wrapper only (this is problem for me), and now 2. you say it does nothing server side (this is problem for others).
Now I'm very confused. Maybe just new HornetQQueue("jms.queue.selectorQueue"); is the simple solution everybody is looking for?

I still don't really understand what the problem is, so it's hard for me to provide a solution

Tim Fox wrote:

 

I still don't really understand what the problem is, so it's hard for me to provide a solution

I think the question is simply about re-creating the exact same object locally that you would normally get when you execute the following code:

Destination destination = new InitialContext(remoteEnv).lookup("/queue/myDestination");

It doesn't really matter for this question whether the client is a Java SE one (as in John's case) or a JBoss AS one (Arjan's and mine). As John indicated, the following which I think you suggested first appears to do too much:

Destination destination = HornetQJMSClient.createQueue("myDestination");

The ultimate goal is just doing the following call:

MessageProducer producer = session.createProducer(destination);

Where session is a session created from a connection to a remote HornetQ server and destination is created locally in a cheap and lightweight way, without any JNDI (caching or not), EJB, Java EE, JCA, or whatever involved.