-
Notifications
You must be signed in to change notification settings - Fork 49
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RMQObjectFactory does not work with Wildfly object-factory JNDI binding #21
Labels
Milestone
Comments
@remibantos sure, thank you. Holy cow, there are still widely used APIs that use Hashtables and not maps? TIL. |
I would say that javax.naming.ObjectFactory has not evolved very much since a very long time :) |
remibantos
pushed a commit
to remibantos/rabbitmq-jms-client
that referenced
this issue
May 29, 2017
…properties from environment HashTable parameter of getObjectInstance method, allowing for example to instantiate client objects on Wildfly with JNDI bindings object-factory configuration
remibantos
pushed a commit
to remibantos/rabbitmq-jms-client
that referenced
this issue
May 29, 2017
…properties from environment HashTable parameter of getObjectInstance method, allowing for example to instantiate client objects on Wildfly with JNDI bindings object-factory configuration
remibantos
pushed a commit
to remibantos/rabbitmq-jms-client
that referenced
this issue
May 29, 2017
remibantos
pushed a commit
to remibantos/rabbitmq-jms-client
that referenced
this issue
May 29, 2017
…llowing PR review
remibantos
added a commit
to remibantos/rabbitmq-jms-client
that referenced
this issue
May 29, 2017
…it test methods when NamingException expectation not met
acogoluegnes
added a commit
to rabbitmq/rabbitmq-website
that referenced
this issue
May 30, 2017
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The RMQObjectFactory class does not work with Wildfly object-factory JNDI binding configuration, documented here
This is because the getObjectInstance() Object first argument is handled as a javax.naming.Reference instance whereas a java.lang.String object is actually provided to this method by Wildfly when using the object-factory binding configuration.
Thus, the following NamingException is always thrown by this code bellow:
From what I understand from javax.naming.ObjectFactory javadoc, there is not requirement to deal with this parameter as a javax.naming.Reference instance only.
So in order to make the RMQObjectFactory work with Wildfly object-factory, we could add the possibility to provide all required properties via the Hashtable environment third argument of getObjectInstance() method.
Note that I'm going to propose a PR for that.
The text was updated successfully, but these errors were encountered: