-
1. Re: Change Resource Adapter Defaults
As I understand it, the default ServerURL value is set in the code and cannot be changed via configuration.
I also believe that the code determines which properties are required and which aren't.
I recommend you follow-up with the ActiveMQ community for the functionality you're looking for as code modifications look to be required.
-
2. Re: Change Resource Adapter Defaults
Yea, I was afraid that was going to be the answer, it seemed to be the case. Currently, I am just using a System Property value to set the URL and checking within my app if the Property value is available. This, of course, is not ideal, but it works for now.
Does anyone know why this is the case? Why localhost is so aggressively tied to the Resource Adapter? I realize that the AMQ community will have more insight into this, but I am having trouble getting responses back from them.
I can't think of many cases where localhost makes sense as the value, other than an embedded broker (in which case I would just use Artemis) or local debugging. It just confuses the issue because the server and app both launch correctly and you don't know there is an issue until the app attempts to send a JMS message (at which point the app fails to connect to that server).
Is the Resource Adapter even the right way to go here? To connect to an external AMQ server? It feels like I am using the wrong tools/libraries to accomplish this if the default is expected to be localhost.
-
3. Re: Change Resource Adapter Defaults
Does anyone know why this is the case? Why localhost is so aggressively tied to the Resource Adapter?
In terms of a network host name or address there aren't really any other options since there are no other "known" addresses. If you wanted to have a default URL and it wasn't going to be localhost, what would it be? There's no other obvious choice. Defaulting to "localhost" (or equivalent) is pretty common in situations like this.
It just confuses the issue because the server and app both launch correctly and you don't know there is an issue until the app attempts to send a JMS message (at which point the app fails to connect to that server).
On-demand connectivity which isn't part of the component's life-cycle usually can't fail until it is actually exercised simply because that's the way it's designed. For things like MDBs where a connection is created as part of its life-cycle (i.e. during deployment) this isn't really a problem.
Is the Resource Adapter even the right way to go here? To connect to an external AMQ server? It feels like I am using the wrong tools/libraries to accomplish this if the default is expected to be localhost.
You haven't given a full description of your use-case, but it sounds to me like you're just trying to send messages from an application running in Wildfly to a remote instance of ActiveMQ 5.x. If that's the case then using the resource adapter is the right way to go as it provides you a lot of functionality for free (e.g. connection pooling, automatic transaction enlistment, externalized configuration, etc.). Even if you didn't use the resource adapter you'd still likely have this problem of not knowing the configuration was incorrect until it was exercised.
-
4. Re: Change Resource Adapter Defaults
In terms of a network host name or address there aren't really any other options since there are no other "known" addresses. If you wanted to have a default URL and it wasn't going to be localhost, what would it be? There's no other obvious choice. Defaulting to "localhost" (or equivalent) is pretty common in situations like this.
Sorry about that, I didn't describe what I meant very well. What I mean is that there should be NO default at all since the URL is such a concrete value. Any default seems to be unnecessary/incorrect since a URL is far too specific in regards to its purpose/application.
On-demand connectivity which isn't part of the component's life-cycle usually can't fail until it is actually exercised simply because that's the way it's designed. For things like MDBs where a connection is created as part of its life-cycle (i.e. during deployment) this isn't really a problem.
Again, my fault in communication. I don't mean that Wildfly should be detecting the component's correctness, but that the Resource Adapter itself should do this and be the one to alert Wildfly that it is not configured properly. I think the module should throw an Exception and Wildfly determines to fail startup or not.
I'm fairly new to Wildfly/JBoss (and containers in general, to be frank) so I don't know the full conceptual purpose of modules and/or Resource Adapters, it may very well be expected to just launch and simply fail at runtime, but this is not the functionality I desire. I would like to know for sure that my module was at least attempted to be configured and that no default is being used.
You haven't given a full description of your use-case, but it sounds to me like you're just trying to send messages from an application running in Wildfly to a remote instance of ActiveMQ 5.x. If that's the case then using the resource adapter is the right way to go as it provides you a lot of functionality for free (e.g. connection pooling, automatic transaction enlistment, externalized configuration, etc.). Even if you didn't use the resource adapter you'd still likely have this problem of not knowing the configuration was incorrect until it was exercised.
Yes this is exactly the case. However, in my particular scenario, I need the message to be sent as part of an XA transaction with JDBC inserts.
I originally had the AMQ configuration within the app itself entirely, but the JMSTemplate I was using did not seem to participate with the transaction and therefore I went the route of setting it up through Wildfly (which now it does participate in the transaction correctly).
I didn't have the configuration problem before because I could fail the app startup when I detect that no system property was set for the URL (as long as it is set, I assume it is correct and move on). The difference being that I knew at the moment of deployment that my properties were set and that no default was being utilized. With the problem outlined above, my deployment would have appeared to be a success (which technically it was, lol) but I would have to wait until a call to my endpoint failed at some point in the future to know things are not in the proper state.
Just seems to me that this is either an annoyance to code around or I am ignorant to some configuration paradigm. I would like to know what I'm doing wrong, if anything.
-
5. Re: Change Resource Adapter Defaults
Any default seems to be unnecessary/incorrect since a URL is far too specific in regards to its purpose/application.
I sympathize with what you're saying, but as a developer on a project with a JCA resource adapter which uses default connection parameters (Apache ActiveMQ Artemis) I would also say that there are lots of users on the other side of the issue from you who like having a default. At the end of the day you can't please everybody.
...the Resource Adapter itself should do this and be the one to alert Wildfly that it is not configured properly. I think the module should throw an Exception and Wildfly determines to fail startup or not.
In general the resource adapter won't create a connection until it's told to by something (e.g. the container when it's deploying an MDB, or an application). However, I believe validation logic like what you're talking about could be added to the method which implements javax.resource.spi.ResourceAdapter#start. I'm not aware of any messaging JCA RA that does this (e.g. Artemis, HornetQ, ActiveMQ 5.x, IBM WebSphereMQ).
Just seems to me that this is either an annoyance to code around or I am ignorant to some configuration paradigm. I would like to know what I'm doing wrong, if anything.
I don't think you're doing anything wrong, per se.
-
6. Re: Change Resource Adapter Defaults
Gotcha, that makes a lot of sense and it seems that the general case for which they solve with their RA implementation is not the case that I am pursing (I had originally assumed it was, hence the confusion). In any event, I am already achieving what I want via the app and a system property check, so nothing is lost, if only a little annoying.
Well thanks for at least discussing this with me jbertram, I appreciate the time.
-