[JBoss JIRA] (AS7-6001) Unable to lookup remote JNDI EJBs
by John Ament (JIRA)
John Ament created AS7-6001:
-------------------------------
Summary: Unable to lookup remote JNDI EJBs
Key: AS7-6001
URL: https://issues.jboss.org/browse/AS7-6001
Project: Application Server 7
Issue Type: Bug
Components: Remoting
Affects Versions: 7.1.1.Final
Reporter: John Ament
Assignee: David Lloyd
Based on the following arquillian test case:
@RunWith(Arquillian.class)
@RunAsClient
public class RemoteDatabaseIntegratorTest {
@Deployment(testable=false)
public static JavaArchive createTestArchive() {
return ShrinkWrap.create(JavaArchive.class,"myejb.jar")
.addClasses(RemoteDatabaseIntegrator.class,RemoteDatabaseIntegratorImpl.class);
}
@ArquillianResource
private Context context;
private static final String JNDI_LOC = "java:module/RemoteDatabaseIntegratorImpl";
private static final String[] JNDI_LOCS = {
//"java:global/myejb/RemoteDatabaseIntegratorImpl!com.tad.arquillian.chp5.remoteejb.RemoteDatabaseIntegrator",
//"java:app/myejb/RemoteDatabaseIntegratorImpl!com.tad.arquillian.chp5.remoteejb.RemoteDatabaseIntegrator",
"java:module/RemoteDatabaseIntegratorImpl!com.tad.arquillian.chp5.remoteejb.RemoteDatabaseIntegrator",
"java:jboss/exported/myejb/RemoteDatabaseIntegratorImpl!com.tad.arquillian.chp5.remoteejb.RemoteDatabaseIntegrator",
//"java:global/myejb/RemoteDatabaseIntegratorImpl",
//"java:app/myejb/RemoteDatabaseIntegratorImpl",
"java:module/RemoteDatabaseIntegratorImpl"
};
@Test
public void testDbServiceInjectionFailure() throws Exception{
//Thread.sleep(1000000);
//context.addToEnvironment(Context.INITIAL_CONTEXT_FACTORY, "org.jboss.as.naming.InitialContextFactory");
Hashtable<String,String> env = new Hashtable<String,String>();
//env.put(Context.INITIAL_CONTEXT_FACTORY, "org.jboss.naming.remote.client.InitialContextFactory");
env.put(Context.INITIAL_CONTEXT_FACTORY, "org.jboss.as.naming.InitialContextFactory");
env.put(Context.PROVIDER_URL, "remote://127.0.0.1:4447");
//env.put(Context.SECURITY_PRINCIPAL, "anon");
//env.put(Context.SECURITY_CREDENTIALS, "anon123");
Context context = new InitialContext(env);
for(String JNDI_LOC : JNDI_LOCS) {
try{
RemoteDatabaseIntegrator dbIntegrator = (RemoteDatabaseIntegrator)context.lookup(JNDI_LOC);
dbIntegrator.runQuery("select 1");
} catch (Exception e) {
System.out.println("Failed to lookup by "+JNDI_LOC);
e.printStackTrace();
}
}
}
}
I can see the JNDI locations populated, but cannot be retrieved, based on the following error:
20:19:02,743 INFO [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-7) JNDI bindings for session bean named RemoteDatabaseIntegratorImpl in deployment unit deployment "myejb.jar" are as follows:
java:global/myejb/RemoteDatabaseIntegratorImpl!com.tad.arquillian.chp5.remoteejb.RemoteDatabaseIntegrator
java:app/myejb/RemoteDatabaseIntegratorImpl!com.tad.arquillian.chp5.remoteejb.RemoteDatabaseIntegrator
java:module/RemoteDatabaseIntegratorImpl!com.tad.arquillian.chp5.remoteejb.RemoteDatabaseIntegrator
java:jboss/exported/myejb/RemoteDatabaseIntegratorImpl!com.tad.arquillian.chp5.remoteejb.RemoteDatabaseIntegrator
java:global/myejb/RemoteDatabaseIntegratorImpl
java:app/myejb/RemoteDatabaseIntegratorImpl
java:module/RemoteDatabaseIntegratorImpl
20:19:02,912 INFO [org.jboss.as.server] (management-handler-thread - 2) JBAS018559: Deployed "myejb.jar"
Failed to lookup by java:module/RemoteDatabaseIntegratorImpl!com.tad.arquillian.chp5.remoteejb.RemoteDatabaseIntegrator
javax.naming.NameNotFoundException: java:module/RemoteDatabaseIntegratorImpl!com.tad.arquillian.chp5.remoteejb.RemoteDatabaseIntegrator
at org.jboss.as.naming.InitialContext.lookup(InitialContext.java:117)
at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:214)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.tad.arquillian.chp5.ejb.RemoteDatabaseIntegratorTest.testDbServiceInjectionFailure(RemoteDatabaseIntegratorTest.java:62)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
at org.jboss.arquillian.junit.Arquillian$6$1.invoke(Arquillian.java:270)
at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115)
at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
at org.jboss.arquillian.container.test.impl.execution.ClientTestExecuter.execute(ClientTestExecuter.java:53)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 11 months
[JBoss JIRA] (AS7-6005) The weld-core module should not be loaded by default when beans.xml is found
by Ron Šmeral (JIRA)
Ron Šmeral created AS7-6005:
-------------------------------
Summary: The weld-core module should not be loaded by default when beans.xml is found
Key: AS7-6005
URL: https://issues.jboss.org/browse/AS7-6005
Project: Application Server 7
Issue Type: Enhancement
Components: CDI / Weld, Class Loading
Reporter: Ron Šmeral
Assignee: Stuart Douglas
Priority: Optional
AS7 automatically loads the {{weld-core}} module with any deployment which contains the {{beans.xml}} marker file. This doesn't seem like best practice. Only the APIs should be exposed by default.
>From {{weld/src/main/java/org/jboss/as/weld/deployment/processors/WeldDependencyProcessor.java}}:
{code:java}
addDependency(moduleSpecification, moduleLoader, JAVAX_PERSISTENCE_API_ID);
addDependency(moduleSpecification, moduleLoader, JAVAEE_API_ID);
addDependency(moduleSpecification, moduleLoader, JAVASSIST_ID);
addDependency(moduleSpecification, moduleLoader, WELD_CORE_ID);
addDependency(moduleSpecification, moduleLoader, WELD_API_ID);
addDependency(moduleSpecification, moduleLoader, WELD_SPI_ID);
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 11 months
[JBoss JIRA] (AS7-6012) AS7 violating alternate client view of EJB 3.1 spec
by John Ament (JIRA)
John Ament created AS7-6012:
-------------------------------
Summary: AS7 violating alternate client view of EJB 3.1 spec
Key: AS7-6012
URL: https://issues.jboss.org/browse/AS7-6012
Project: Application Server 7
Issue Type: Bug
Components: EJB
Reporter: John Ament
Assignee: jaikiran pai
Section 4.4.2.2 of the EJB 3.1 spec states that the following JNDI locations should be populated for "other client views," which includes remote. AS7 is using a highly custom pattern for this view. This is shown when trying to run the following test case in Arquillian:
@Remote
public interface RemoteDatabaseIntegrator {
public void runQuery(String query) throws SQLException;
}
@Remote(RemoteDatabaseIntegrator.class)
@Stateless(name="RemoteDatabaseIntegrator")
public class RemoteDatabaseIntegratorImpl implements RemoteDatabaseIntegrator {
@Resource(name="jdbc/AppDS")
private DataSource ds;
private Connection conn;
@PostConstruct
public void init() throws SQLException {
this.conn = ds.getConnection();
}
@PreDestroy
public void cleanup() throws SQLException {
this.conn.close();
}
public void runQuery(String query) throws SQLException {
this.conn.createStatement().execute(query);
}
}
@RunWith(Arquillian.class)
@RunAsClient
public class RemoteDatabaseIntegratorTest {
@Deployment(testable=false)
public static JavaArchive createTestArchive() {
return ShrinkWrap.create(JavaArchive.class,"test.jar")
.addClasses(RemoteDatabaseIntegrator.class,RemoteDatabaseIntegratorImpl.class);
}
private static final String JNDI_LOC = "?";
@Test
public void testDbServiceInjectionFailure() throws Exception{
Context context = createAS7Context();
RemoteDatabaseIntegrator dbIntegrator = (RemoteDatabaseIntegrator)context.lookup(JNDI_LOC);
dbIntegrator.runQuery("select 1");
}
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 11 months
[JBoss JIRA] (AS7-6020) Update slf4j-api dependency for module
by Bernd Eckenfels (JIRA)
Bernd Eckenfels created AS7-6020:
------------------------------------
Summary: Update slf4j-api dependency for module
Key: AS7-6020
URL: https://issues.jboss.org/browse/AS7-6020
Project: Application Server 7
Issue Type: Feature Request
Components: Build System, Logging
Affects Versions: 7.1.1.Final, 7.2.0.CR1
Reporter: Bernd Eckenfels
Assignee: Paul Gier
The org.slf4j-api artifact shipped with 7.1.1-final is at level 1.6.1 and I noticed that it is not upgraded with 7.2. There are newer 1.6.x versions but also the option to switch to 1.7.x which features vararg.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 11 months
[JBoss JIRA] (AS7-6018) NillableOrExpressionParameterValidator fails when undefining a nillable attribute
by Stefan Guilhen (JIRA)
Stefan Guilhen created AS7-6018:
-----------------------------------
Summary: NillableOrExpressionParameterValidator fails when undefining a nillable attribute
Key: AS7-6018
URL: https://issues.jboss.org/browse/AS7-6018
Project: Application Server 7
Issue Type: Bug
Affects Versions: 7.1.3.Final (EAP)
Reporter: Stefan Guilhen
Assignee: Stefan Guilhen
Fix For: 7.2.0.Alpha1, 7.1.4.Final (EAP)
Undefining a nillable attribute via CLI results in a validation error:
[standalone@localhost:9999 /] /subsystem=security/security-domain=other:undefine-attribute(name=cache-type)
{
"outcome" => "failed",
"failure-description" => "JBAS014746: value may not be null",
"rolled-back" => true
}
This is caused by the validateResolvedParameter method in the NillableOrExpressionParameterValidator. The method incorrectly qualifies the value as an expression when its undefined:
if (!value.isDefined()) {
if (!allowExpression) {
throw MESSAGES.nullNotAllowed(parameterName);
}
} else {
delegate.validateResolvedParameter(parameterName, value);
}
It should check the value type instead, just like validateParameter does.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 11 months
[JBoss JIRA] (AS7-6008) Logging transformers do not work
by Kabir Khan (JIRA)
Kabir Khan created AS7-6008:
-------------------------------
Summary: Logging transformers do not work
Key: AS7-6008
URL: https://issues.jboss.org/browse/AS7-6008
Project: Application Server 7
Issue Type: Bug
Reporter: Kabir Khan
Assignee: James Perkins
Trying to debug an issue in logging transformers when an old slave is connected to master's DC I noticed that SubsystemParsing11TestCase contains the transformers test. As mentioned in AS7-6007 this test was disabled and the parser does not work. It makes more sense to parse the latest xml and test transformation there, as I attempted to do in https://github.com/kabir/jboss-as/tree/logging-transformers-for-james. However, there are still some issues with the transformers there which needs to be fixed. The current stumbling block is:
{code}
[~/sourcecontrol/jboss-as7/git/jboss-as]
$more logging/target/surefire-reports/org.jboss.as.logging.LoggingSubsystemTestCase.txt
-------------------------------------------------------------------------------
Test set: org.jboss.as.logging.LoggingSubsystemTestCase
-------------------------------------------------------------------------------
Tests run: 2, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.816 sec <<< FAILURE!
testTransformers_1_1(org.jboss.as.logging.LoggingSubsystemTestCase) Time elapsed: 0.309 sec <<< ERROR!
java.lang.IllegalArgumentException: JBAS014880: No operation entry called 'add' registered at '[
("subsystem" => "logging"),
("logging-profile" => "test-profile"),
("console-handler" => "CONSOLE")
]'
at org.jboss.as.controller.operations.validation.OperationValidator.throwOrWarnAboutDescriptorProblem(OperationValidator.java:552)
at org.jboss.as.controller.operations.validation.OperationValidator.validateOperation(OperationValidator.java:123)
at org.jboss.as.controller.operations.validation.OperationValidator.validateOperations(OperationValidator.java:95)
at org.jboss.as.model.test.ModelTestModelControllerService.boot(ModelTestModelControllerService.java:136)
at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:217)
at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:185)
at java.lang.Thread.run(Thread.java:680)
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 11 months