I have been looking into it further and at the very least the comparison of
type is wrong. The code says
if (type.isInstance(pair.getClass()) ||
type.getName().equals(pair.getClassName()))
{
but should be
if (type.isAssignableFrom(Class.forName(pair.getClassName()))) {
Pair's getClass() method will always return javax.naming.NameClassPair. The
getClassName() method will give the name back but unless you are looking up
exactly that class name, it will fail. It will not pick up derived classes
making it useless. Checking "isAssignableFrom" is the only solution here.
And as I pointed out in my first email, this will only fix the case when
the name is not in a sub context.
I will see if i can conjure up a patch real quick.
*Robert Simmons Jr. MSc. - Lead Java Architect @ EA*
*Author of: Hardcore Java (2003) and Maintainable Java (2012)*
*LinkedIn: **http://www.linkedin.com/pub/robert-simmons/40/852/a39
<http://www.linkedin.com/pub/robert-simmons/40/852/a39>*
On Fri, Feb 21, 2014 at 5:55 PM, kraythe . <[email protected]> wrote:
> And incidentally it also fails to find derived type. I put in
> JTATransactionManager which is an implementation of the
> PlatformTransactionManager type and the lookup of
> PlatformTransactionManager fails. The camel implementation of the JNDI
> registry needs some work it seems. Anyone have any idea how I could plug in
> another JNDI implementation ?
>
> *Robert Simmons Jr. MSc. - Lead Java Architect @ EA*
> *Author of: Hardcore Java (2003) and Maintainable Java (2012)*
> *LinkedIn: **http://www.linkedin.com/pub/robert-simmons/40/852/a39
> <http://www.linkedin.com/pub/robert-simmons/40/852/a39>*
>
>
> On Fri, Feb 21, 2014 at 5:44 PM, kraythe . <[email protected]> wrote:
>
>> I was debugging an issue in a test case where I use Atomikos for JTA
>> transaction management support and the app uses the JNDIRegistry. When the
>> registry imll from camel is used and the lookupByType is called, it invokes
>> the following code:
>>
>> public <T> Map<String, T> findByTypeWithName(Class<T> type) {
>> Map<String, T> answer = new LinkedHashMap<String, T>();
>> try {
>> NamingEnumeration<NameClassPair> list = getContext().list("");
>> while (list.hasMore()) {
>> NameClassPair pair = list.next();
>> if (type.isInstance(pair.getClass()) ||
>> type.getName().equals(pair.getClassName())) {
>> Object instance = context.lookup(pair.getName());
>> answer.put(pair.getName(), type.cast(instance));
>> }
>> }
>> } catch (NamingException e) {
>> // ignore
>> }
>>
>> return answer;
>> }
>>
>> Now I know for sure my transaction manager is registered at
>> "java:app/jta/txnManager" and so when I got an empty set result to this, I
>> debugged into it and examined it.
>>
>> The code above assumes that the list is only one layer deep and thus if
>> the name is not found at that level it doesn't exist. When in fact this
>> code should be recursive. When It finds an object of type JNDIContext, it
>> should recurse and add all results from the recursive call.
>>
>> public <T> Map<String, T> findByTypeWithName(Class<T> type) {
>> Map<String, T> answer = new LinkedHashMap<String, T>();
>> try {
>> NamingEnumeration<NameClassPair> list = getContext().list("");
>> while (list.hasMore()) {
>> NameClassPair pair = list.next();
>> if (type.isInstance(pair.getClass()) ||
>> type.getName().equals(pair.getClassName())) {
>> Object instance = context.lookup(pair.getName());
>> answer.put(pair.getName(), type.cast(instance));
>> * } else if (pair.getClass().equals(JndiContext.class)) {*
>> *
>>
>> answer.putAll((JndiContext)context.lookup(pair.getName()).lookupByType(type);*
>> * }*
>> }
>> } catch (NamingException e) {
>> // ignore
>> }
>>
>> return answer;
>> }
>>
>> The problem is camel's implementation of JNDI Context also doesn't
>> implement lookupByType() so that would have to be done as well. Sorry for
>> coding without an IDE.
>>
>> So am I crazy here or is this a real issue?
>>
>> *Robert Simmons Jr. MSc. - Lead Java Architect @ EA*
>> *Author of: Hardcore Java (2003) and Maintainable Java (2012)*
>> *LinkedIn: **http://www.linkedin.com/pub/robert-simmons/40/852/a39
>> <http://www.linkedin.com/pub/robert-simmons/40/852/a39>*
>>
>
>