[
https://issues.apache.org/jira/browse/OPENEJB-1330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thorsten Wärtel updated OPENEJB-1330:
-------------------------------------
Attachment: testcase-injection.zip
With the latest 4.0.0-beta-2-SNAPSHOT, I seem to have narrowed it down to three
cases: two of them working as intended and one that still gets a
NameAlreadyBoundException but which seems to be largely my own fault.
I'm attaching a test project I derived from the
[testcase-injection|http://svn.apache.org/repos/asf/openejb/trunk/openejb/examples/testcase-injection]
example project. This project will still fail with a NameAlreadyBoundException
in the module-b test. The project structure is as follows:
One aggregator POM over two modules named "module-a" and "module-b", each of
which contains the original test case from the example project. Module-a's POM
includes generation of an attached test-jar. Module-b has a test-scope
dependency on module-a so that it can access module-a's EJBs (this is my
real-world scenario) and it also has a test-scope dependency on module-a's
test-jar (so I could derive from or re-use any test classes from module-a; in
the example, the dependency alone raises the exception, so I don't actually use
anything from the test-jar).
In both module-a and module-b, I included a
src/test/resources/META-INF/application-client.xml, each with a unique id set
in the document element. Now, for module-b's test there's three cases:
1a) application-client.xml present, test classes annotated with @LocalClient,
test case using EJBContainer.createEjbContainer() to set up OpenEJB:
Test fails with NameAlreadyBoundException, because there are two local client
classes with the same qualified name visible on the classpath (one from
module-a's test-jar, one from module-b's target/test-classes). It seems that
the application-client id is not taken into account when local clients are
bound, just the qualified name. This is where it get my fault, because I could
have noticed this earlier and I really don't need classes with the same
qualified name in my real-world projects. If I rename one test class or its
package, everything works fine in this case.
1b) application-client.xml not present, no matter if test classes are annotated
with @LocalClient or not, test case using EJBContainer.createEjbContainer() to
set up OpenEJB:
Everything works fine! I don't know if anything like this was possible in
OpenEJB 3.x, but this is exactly what I was looking for for EJB-testing in my
real-world projects. Since there is no application-client.xml anymore, this
case is not affected by the bug reported here.
2) application-client.xml present, test cases annotated with @LocalClient
(won't work otherwise), test case using new InitialContext() with
LocalInitialContextFactory to set up OpenEJB
This was my OpenEJB 3.x approach and like 1a) it will only fail with
NameAlreadyBoundException, if there are duplicate @LocalClient-annotated
classes on the classpath. Note that the actual test case will fail with
"javax.naming.NamingException: Unable to find injection meta-data for
org.superbiz.testinjection.MoviesTest. Ensure that class was annotated with
@org.apache.openejb.api.LocalClient and was successfully discovered and
deployed. See http://openejb.apache.org/3.0/local-client-injection.html";, but
the NameAlreadyBoundException is logged to the console.
I also tested the working case 2) (without duplicate classes) with OpenEJB
Versions 4.0.0-beta-1 (also working) and 3.1.4 (not working,
javax.naming.NameAlreadyBoundException:
ParsedName\{path=openejb/client/test-classes/comp/env, component=env\}). I
think this bug can be considered fixed in OpenEJB 4, which would be fine by me,
I don't need a backport to 3.x
Thanks a lot and keep up the good work!
> providing id in application-client.xml has no effect on local client module
> name
> --------------------------------------------------------------------------------
>
> Key: OPENEJB-1330
> URL: https://issues.apache.org/jira/browse/OPENEJB-1330
> Project: OpenEJB
> Issue Type: Bug
> Components: configuration
> Affects Versions: 3.1.2, 3.1.4, 4.0-beta-1
> Reporter: Thorsten Wärtel
> Attachments: AppInfoBuilder.java.patch, testcase-injection.zip
>
>
> Some weeks ago, a problem with duplicate local client module names was posted
> on the openejb-users mailing list:
> http://openejb.979440.n4.nabble.com/OpenEJB-localclient-module-name-td2238205.html
> I am having the same problem in the following scenario:
> - multi-module project
> - module-a tests do local client injection, so there is an
> application-client.xml present in module-a/target/test-classes/META-INF
> - module-a builds an attached test-jar
> - module-b has a dependency on module-a's test-jar
> - module-b also does local client injection
> If I run tests in this project from command line, everything works fine in
> module-b: LocalClients from module-a are deployed with a local client module
> name of "module-a-1.0.0-SNAPSHOT-tests" and LocalClients from module-b use
> module name "test-classes".
> However, if I run tests in eclipse (using m2eclipse 0.10.2), a
> NameAlreadyBoundException is raised because LocalClients from module-a are
> already bound using alocal client module name of "test-classes", so
> module-b's LocalClients try to bind under the same name.
> The first reply on the mailing list hints that using a unique id attribute in
> application-client.xml would prevent this, but unfortunately this does not
> work in 3.1.2 (and current 3.1.3-SNAPSHOT).
> Doing some debugging, I found out that the id attribute is correctly set into
> class ApplicationClient when reading application-client.xml and also
> correctly passed on to class ClientModule. But I think there might be an
> error in AppInfoBuilder.getClientModuleId(ClientModule), where a module id is
> determined from ClientModule.getJarLocation() instead
> ClientModule.getModuleId(). The moduleId is already set to jarLocation in
> ClientModule, if no explicit id is provided. Changing getClientModuleId() to
> use getModuleId() did the trick for me, application-client.xml ids are now
> used as local client module names and there is no NameAlreadyBoundException
> raised anymore.
> I will attach a patch containing the change I made.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
