[JBoss JIRA] (ARQ-867) Arquillian should warn if javax.inject.* annotations used w/o beans.xml
by Craig Ringer (JIRA)
Craig Ringer created ARQ-867:
--------------------------------
Summary: Arquillian should warn if javax.inject.* annotations used w/o beans.xml
Key: ARQ-867
URL: https://issues.jboss.org/browse/ARQ-867
Project: Arquillian
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Affects Versions: 1.0.0.Final
Environment: JBoss AS 7.1.1.Final
java version "1.7.0_01"
Java(TM) SE Runtime Environment (build 1.7.0_01-b08)
Java HotSpot(TM) 64-Bit Server VM (build 21.1-b02, mixed mode)
Linux ayaki.localdomain 3.3.0-4.fc16.x86_64 #1 SMP Tue Mar 20 18:05:40 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
Reporter: Craig Ringer
Because Arquillian requires the use of ShrinkWrap and individual selection of parts of the project to be tested, it's easy to leave beans.xml out and have CDI injection (javax.inject.Inject, etc) fail silently. A log message is emitted in the server logs about the BeanManager not being found, but there's no other indication of the problem until the tests fail with NPEs in injected fields. Missing/unsatisfied/duplicate dependencies are not caught and resolved, so if the injected fields aren't used directly a test may appear to pass when it's really just not testing the CDI stuff you thought you were testing.
This issue is particularly easy to stumble on because different archive types require beans.xml to appear in different locations, and ShrinkWrap doesn't have any API for automatically placing beans.xml in the correct archive specific location. (See https://issues.jboss.org/browse/SHRINKWRAP-396).
It'd be a usability enhancement to Arquillian if it'd detect the case where javax.inject.Inject annotations were used but CDI was not present, and emit an explicit warning in the logs and test output.
(Personally I think the CDI spec allowing containers to silently ignore javax.inject.Inject when no CDI implementation is present was a mistake - they should be required to emit a warning at minimum. So much pain would be saved for newbies.)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (ARQ-866) Allow catalina.base to be configured separately from catalina.home in the Tomcat managed adapters
by Dan Allen (JIRA)
Dan Allen created ARQ-866:
-----------------------------
Summary: Allow catalina.base to be configured separately from catalina.home in the Tomcat managed adapters
Key: ARQ-866
URL: https://issues.jboss.org/browse/ARQ-866
Project: Arquillian
Issue Type: Enhancement
Security Level: Public (Everyone can see)
Components: Tomcat Containers
Affects Versions: tomcat_1.0.0.CR3
Reporter: Dan Allen
The Tomcat managed container adapter assumes that catalina.base is the same as catalina.home.
{code}
String absolutePath = new File(CATALINA_HOME).getAbsolutePath();
...
cmd.add("-Dcatalina.base=" + absolutePath);
cmd.add("-Dcatalina.home=" + absolutePath);
{code}
However, this is not necessary true. For instance, when using Tomcat from Eclipse, the catalina.base (which includes the configuration files) is managed inside the Eclipse workspace. This allows the developer to modify Tomcat settings without affecting the system installation.
The fix for this problem is to add a configuration property named "catalinaBase" and honor if it's set when building the startup script.
This affects all the Tomcat managed containers (5, 6 and 7).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months