| Re: [cu-dev] JNDI search in ContextServiceDefinitionBean |
|
Petr, Thanks for spotting that, it is clearly looking up the wrong JNDI name. My initial reaction was how can that possibly be passing when I run the TCK with Open Liberty? After investigating, it turns out that it isn’t passing. Instead, it isn’t running that code at all because it’s unreachable. I recall that when reviewing the new EJB tests earlier this year, I had spotted a couple of occurrences of dead code that the developer had copied over from the servlet tests for use as a starting point/reference for writing some similar
EJB tests. The dead code that I spotted at that time was removed. However, it looks like this is some additional dead code from that point which went unnoticed until now. Just for fun, I added some code to enable it locally and was happy to confirm that Open Liberty does indeed fail when trying to run with that incorrect JNDI name, javax.naming.NameNotFoundException: java:comp/concurrent/ContextB While we could opt to try to make this into a new working test (which would require more than just correcting the JNDI name because assertions would also need to match the different configuration within the EJB), I don’t see any point in
that given that there is already other coverage in both EJBs and servlets. Let’s just remove it. From: cu-dev <cu-dev-bounces@xxxxxxxxxxx> on behalf of Petr Aubrecht <aubrecht@xxxxxxxxxxxx> Hello, I would like to ask you for help -- ContextServiceDefinitionBean class defines ContextB with this name: @ContextServiceDefinition(name = "java:module/concurrent/ContextB",... But it looks up in this way: InitialContext.doLookup("java:comp/concurrent/ContextB");
Shouldn't the names match? Or is the module/comp mismatch intentional? We tried to fix it (using java:module for both) and this tests works: https://github.com/aubi/concurrency-api/pull/1/commits/fd0c15a35c29d14683e1d6369f27a6b470cc193f Thank you Petr |