[JBoss JIRA] (AS7-6225) MessagingSubsystemParser swallows exceptions
by Brian Stansberry (JIRA)
Brian Stansberry created AS7-6225:
-------------------------------------
Summary: MessagingSubsystemParser swallows exceptions
Key: AS7-6225
URL: https://issues.jboss.org/browse/AS7-6225
Project: Application Server 7
Issue Type: Bug
Components: Domain Management, JMS
Affects Versions: 7.1.3.Final (EAP)
Reporter: Brian Stansberry
Assignee: Jeff Mesnil
In numerous places, MessagingSubsystemParser calls ParseUtils.missingRequired but does not throw the returned exception.
I'll attach a patch showing all the places where Intellij reported this. I'd just send a pull request, but when I run with this patch, the messaging module testsuite has failures and I don't have time today to investigate.
--
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
[JBoss JIRA] (AS7-6068) jar file system is broken again (regression)
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/AS7-6068?page=com.atlassian.jira.plugin.s... ]
Stuart Douglas edited comment on AS7-6068 at 12/19/12 8:38 PM:
---------------------------------------------------------------
There is a flag in jboss-deployment-structure.xml that allows you to change the code base from a vfs:// URL to the physical URL, via the use-physical-code-source attribute. For bouncycastle bundled in a war the code would look something like:
{code}
<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.1">
<deployment>
<resources>
<resource-root path="WEB-INF/lib/bouncycastle.jar" use-physical-code-source="true"/>
</resources>
</deployment>
</jboss-deployment-structure>
{code}
Does this resolve the problem?
was (Author: swd847):
There is a flag in jboss-deployment-structure.xml that allows you to change the code base from a vfs:// URL to the physical URL, via the use-physical-code-source attribute. For bouncycastle bundled in a war the code would look something like:
[code]
<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.1">
<deployment>
<resources>
<resource-root path="WEB-INF/lib/bouncycastle.jar" use-physical-code-source="true"/>
</resources>
</deployment>
</jboss-deployment-structure>
[code]
Does this resolve the problem?
> jar file system is broken again (regression)
> --------------------------------------------
>
> Key: AS7-6068
> URL: https://issues.jboss.org/browse/AS7-6068
> Project: Application Server 7
> Issue Type: Bug
> Affects Versions: 7.1.1.Final
> Reporter: Alvin Thompson
> Assignee: JBoss SET
> Priority: Critical
>
> Similar to issue JBAS-7882, you cannot bundle a security provider in a WAR/EAR, because JBOSS's jar file system becomes confused when there are JARs nested in other JARs/WARs/EARs, which is pretty much always.
> This was supposedly fixed in previous versions, but it's back in 7.
--
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
[JBoss JIRA] (AS7-6068) jar file system is broken again (regression)
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/AS7-6068?page=com.atlassian.jira.plugin.s... ]
Stuart Douglas commented on AS7-6068:
-------------------------------------
There is a flag in jboss-deployment-structure.xml that allows you to change the code base from a vfs:// URL to the physical URL, via the use-physical-code-source attribute. For bouncycastle bundled in a war the code would look something like:
[code]
<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.1">
<deployment>
<resources>
<resource-root path="WEB-INF/lib/bouncycastle.jar" use-physical-code-source="true"/>
</resources>
</deployment>
</jboss-deployment-structure>
[code]
Does this resolve the problem?
> jar file system is broken again (regression)
> --------------------------------------------
>
> Key: AS7-6068
> URL: https://issues.jboss.org/browse/AS7-6068
> Project: Application Server 7
> Issue Type: Bug
> Affects Versions: 7.1.1.Final
> Reporter: Alvin Thompson
> Assignee: JBoss SET
> Priority: Critical
>
> Similar to issue JBAS-7882, you cannot bundle a security provider in a WAR/EAR, because JBOSS's jar file system becomes confused when there are JARs nested in other JARs/WARs/EARs, which is pretty much always.
> This was supposedly fixed in previous versions, but it's back in 7.
--
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
[JBoss JIRA] (AS7-6224) Ensure AttributeDefinition does string-to-expression conversion before calling correctValue
by Brian Stansberry (JIRA)
Brian Stansberry created AS7-6224:
-------------------------------------
Summary: Ensure AttributeDefinition does string-to-expression conversion before calling correctValue
Key: AS7-6224
URL: https://issues.jboss.org/browse/AS7-6224
Project: Application Server 7
Issue Type: Sub-task
Components: Domain Management
Affects Versions: 7.1.3.Final (EAP)
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: 7.2.0.Alpha1
AttributeDefinition.validateAndSet() is calling correctValue() before checking whether a ModelType.STRING node is actually an expression and converting it. The result is the corrector may end up correcting (and breaking) a param it shouldn't.
--
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
[JBoss JIRA] (AS7-5489) Resource injection fails for bound JNDI References
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/AS7-5489?page=com.atlassian.jira.plugin.s... ]
Stuart Douglas resolved AS7-5489.
---------------------------------
Resolution: Done
As far as I can see I think this is already done.
I think I left it open because I wanted to investigate something further, but I can't remember exactly what it was, and looking at the code it should not be a problem as far as I can see.
> Resource injection fails for bound JNDI References
> --------------------------------------------------
>
> Key: AS7-5489
> URL: https://issues.jboss.org/browse/AS7-5489
> Project: Application Server 7
> Issue Type: Bug
> Components: CDI / Weld, EJB
> Environment: Current AS7 master (5da40038a409abdb0492b7198b5073379223fb08)
> AS 7.1.3.Beta1
> Reporter: Jozef Hartinger
> Assignee: Stuart Douglas
>
> AS7 seems to be inconsistent when a Reference (e.g. ModularReference) is bound to JNDI.
> Since https://github.com/jbossas/jboss-as/commit/2b0130ca72fd4bbcb9339fe55dc3e8...
> the BeanManager is injected using ModularReference.
> When a JNDI lookup is done for "java:comp/BeanManager", my understanding is that NamingContext (https://github.com/jbossas/jboss-as/blob/master/naming/src/main/java/org/...) takes care of turning the ModularReference instance into a BeanManager instance and everything works as expected.
> However, when instead of a lookup a resource injection is performed on a session bean such as:
> {code:JAVA}
> @Stateful
> @SessionScoped
> public class HelloBean implements IHelloBean, Serializable {
> @Resource(mappedName = "java:comp/BeanManager")
> private BeanManager beanManager;
> @Remove
> public void remove() {
> }
> }
> {code}
> I am getting the following exception at runtime which indicates the ModularReference is not turned into BeanManager instance for injection into the field of the session bean.
> {code}
> 15:25:45,359 ERROR [org.jboss.arquillian.protocol.jmx.JMXTestRunner] (pool-3-thread-1) Failed: org.jboss.weld.tests.enterprise.EnterpriseBeanTest.testPassivationOfEjbs: org.jboss.weld.exceptions.CreationException: WELD-000079 Could not find the EJB in JNDI: class org.jboss.weld.tests.enterprise.IHelloBean$587032701$Proxy$_$$_Weld$Proxy$
> at org.jboss.weld.bean.SessionBean.create(SessionBean.java:306) [weld-core-1.1.9.Final.jar:2012-08-06 19:12]
> at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:103) [weld-core-1.1.9.Final.jar:2012-08-06 19:12]
> at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:90) [weld-core-1.1.9.Final.jar:2012-08-06 19:12]
> at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:104) [weld-core-1.1.9.Final.jar:2012-08-06 19:12]
> at org.jboss.weld.proxies.IHelloBean$587032701$Proxy$_$$_WeldClientProxy.sayHello(IHelloBean$587032701$Proxy$_$$_WeldClientProxy.java) [weld-core-1.1.9.Final.jar:]
> at org.jboss.weld.tests.enterprise.HelloAction.executeRequest(HelloAction.java:32) [2d05798d-e3ce-4ca8-b593-84a523961362.jar:]
> at org.jboss.weld.tests.enterprise.EnterpriseBeanTest.testPassivationOfEjbs(EnterpriseBeanTest.java:113) [2d05798d-e3ce-4ca8-b593-84a523961362.jar:]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.6.0_31]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [rt.jar:1.6.0_31]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [rt.jar:1.6.0_31]
> at java.lang.reflect.Method.invoke(Method.java:597) [rt.jar:1.6.0_31]
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44) [arquillian-service:]
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) [arquillian-service:]
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41) [arquillian-service:]
> at org.jboss.arquillian.junit.Arquillian$6$1.invoke(Arquillian.java:270) [arquillian-service:]
> at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60) [arquillian-service:]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.6.0_31]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [rt.jar:1.6.0_31]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [rt.jar:1.6.0_31]
> at java.lang.reflect.Method.invoke(Method.java:597) [rt.jar:1.6.0_31]
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) [arquillian-service:]
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) [arquillian-service:]
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) [arquillian-service:]
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135) [arquillian-service:]
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115) [arquillian-service:]
> at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) [arquillian-service:]
> at org.jboss.arquillian.container.test.impl.execution.ContainerTestExecuter.execute(ContainerTestExecuter.java:38) [arquillian-service:]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.6.0_31]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [rt.jar:1.6.0_31]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [rt.jar:1.6.0_31]
> at java.lang.reflect.Method.invoke(Method.java:597) [rt.jar:1.6.0_31]
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) [arquillian-service:]
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) [arquillian-service:]
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) [arquillian-service:]
> at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:89) [arquillian-service:]
> at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source) [:1.6.0_31]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [rt.jar:1.6.0_31]
> at java.lang.reflect.Method.invoke(Method.java:597) [rt.jar:1.6.0_31]
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) [arquillian-service:]
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) [arquillian-service:]
> at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:75) [arquillian-service:]
> at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source) [:1.6.0_31]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [rt.jar:1.6.0_31]
> at java.lang.reflect.Method.invoke(Method.java:597) [rt.jar:1.6.0_31]
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) [arquillian-service:]
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) [arquillian-service:]
> at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60) [arquillian-service:]
> at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) [:1.6.0_31]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [rt.jar:1.6.0_31]
> at java.lang.reflect.Method.invoke(Method.java:597) [rt.jar:1.6.0_31]
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) [arquillian-service:]
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) [arquillian-service:]
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135) [arquillian-service:]
> at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:111) [arquillian-service:]
> at org.jboss.arquillian.junit.Arquillian$6.evaluate(Arquillian.java:263) [arquillian-service:]
> at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:226) [arquillian-service:]
> at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314) [arquillian-service:]
> at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46) [arquillian-service:]
> at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:240) [arquillian-service:]
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76) [arquillian-service:]
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) [arquillian-service:]
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193) [arquillian-service:]
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52) [arquillian-service:]
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191) [arquillian-service:]
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42) [arquillian-service:]
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184) [arquillian-service:]
> at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:185) [arquillian-service:]
> at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314) [arquillian-service:]
> at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46) [arquillian-service:]
> at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:199) [arquillian-service:]
> at org.junit.runners.ParentRunner.run(ParentRunner.java:236) [arquillian-service:]
> at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:147) [arquillian-service:]
> at org.junit.runner.JUnitCore.run(JUnitCore.java:157) [arquillian-service:]
> at org.junit.runner.JUnitCore.run(JUnitCore.java:136) [arquillian-service:]
> at org.jboss.arquillian.junit.container.JUnitTestRunner.execute(JUnitTestRunner.java:65) [arquillian-service:]
> at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethodInternal(JMXTestRunner.java:128) [arquillian-service:]
> at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethod(JMXTestRunner.java:107) [arquillian-service:]
> at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.runTestMethod(ArquillianService.java:214) [arquillian-service:]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.6.0_31]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [rt.jar:1.6.0_31]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [rt.jar:1.6.0_31]
> at java.lang.reflect.Method.invoke(Method.java:597) [rt.jar:1.6.0_31]
> at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:93) [rt.jar:1.6.0_31]
> at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:27) [rt.jar:1.6.0_31]
> at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:208) [rt.jar:1.6.0_31]
> at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:120) [rt.jar:1.6.0_31]
> at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:262) [rt.jar:1.6.0_31]
> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:836) [rt.jar:1.6.0_31]
> at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:761) [rt.jar:1.6.0_31]
> at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.invoke(PluggableMBeanServerImpl.java:502)
> at org.jboss.as.jmx.PluggableMBeanServerImpl.invoke(PluggableMBeanServerImpl.java:246)
> at org.jboss.remotingjmx.protocol.v1.ServerProxy$InvokeHandler.handle(ServerProxy.java:1034)
> at org.jboss.remotingjmx.protocol.v1.ServerProxy$MessageReciever$1.run(ServerProxy.java:215)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_31]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_31]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_31]
> Caused by: java.lang.IllegalStateException: JBAS011048: Failed to construct component instance
> at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:163) [jboss-as-ee-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.constructComponentInstance(StatefulSessionComponent.java:145) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.constructComponentInstance(StatefulSessionComponent.java:76) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:85) [jboss-as-ee-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createInstance(StatefulSessionComponent.java:135) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createInstance(StatefulSessionComponent.java:76) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.as.ejb3.cache.TransactionAwareObjectFactory.createInstance(TransactionAwareObjectFactory.java:53) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.as.ejb3.cache.impl.backing.NonPassivatingBackingCacheImpl.create(NonPassivatingBackingCacheImpl.java:106) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.as.ejb3.cache.impl.backing.NonPassivatingBackingCacheImpl.create(NonPassivatingBackingCacheImpl.java:57) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.as.ejb3.cache.spi.impl.AbstractCache.create(AbstractCache.java:53) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.as.ejb3.cache.impl.SimpleCache.create(SimpleCache.java:69) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.as.ejb3.cache.impl.SimpleCache.create(SimpleCache.java:40) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createSession(StatefulSessionComponent.java:241) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.as.weld.ejb.StatefulSessionObjectReferenceImpl.<init>(StatefulSessionObjectReferenceImpl.java:72) [jboss-as-weld-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.as.weld.services.bootstrap.WeldEjbServices.resolveEjb(WeldEjbServices.java:60) [jboss-as-weld-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.weld.bean.SessionBean.createReference(SessionBean.java:411) [weld-core-1.1.9.Final.jar:2012-08-06 19:12]
> at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.<init>(EnterpriseBeanProxyMethodHandler.java:69) [weld-core-1.1.9.Final.jar:2012-08-06 19:12]
> at org.jboss.weld.bean.SessionBean.create(SessionBean.java:296) [weld-core-1.1.9.Final.jar:2012-08-06 19:12]
> ... 95 more
> Caused by: java.lang.IllegalArgumentException: Can not set javax.enterprise.inject.spi.BeanManager field org.jboss.weld.tests.enterprise.HelloBean.beanManager to org.jboss.as.naming.context.ModularReference
> at sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:146) [rt.jar:1.6.0_31]
> at sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:150) [rt.jar:1.6.0_31]
> at sun.reflect.UnsafeObjectFieldAccessorImpl.set(UnsafeObjectFieldAccessorImpl.java:63) [rt.jar:1.6.0_31]
> at java.lang.reflect.Field.set(Field.java:657) [rt.jar:1.6.0_31]
> at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:111) [jboss-as-ee-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.as.ee.component.ManagedReferenceInterceptorFactory$ManagedReferenceInterceptor.processInvocation(ManagedReferenceInterceptorFactory.java:95) [jboss-as-ee-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) [jboss-as-ee-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.as.jpa.interceptor.SFSBPreCreateInterceptor.processInvocation(SFSBPreCreateInterceptor.java:47)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45) [jboss-as-ee-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:161) [jboss-as-ee-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> ... 112 more
> {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
[JBoss JIRA] (AS7-5217) Add test coverage for OSGi subsystem bootstrap scenarios
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/AS7-5217?page=com.atlassian.jira.plugin.s... ]
Thomas Diesler reassigned AS7-5217:
-----------------------------------
Assignee: Thomas Diesler
> Add test coverage for OSGi subsystem bootstrap scenarios
> ---------------------------------------------------------
>
> Key: AS7-5217
> URL: https://issues.jboss.org/browse/AS7-5217
> Project: Application Server 7
> Issue Type: Task
> Components: OSGi
> Reporter: Thomas Diesler
> Assignee: Thomas Diesler
> Fix For: 7.2.0.CR1
>
>
> Currently we don't test OSGi subsystem activation with persistent bundles. In the InitialDeploymentTracker there is a TODO that should get investigated/fixed
> {code}
> protected boolean trackService(ServiceController<? extends Object> controller) {
> // [TODO] currently we track all persistet deployments.
> // If one fails it would mean that the OSGi framwork does not bootstrap
> return deploymentPhaseServices.contains(controller.getName());
> }
> {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
[JBoss JIRA] (AS7-6223) org.jboss.as.protocol.ProtocolChannelClient needs to support client socket bind address config
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/AS7-6223?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry updated AS7-6223:
----------------------------------
Fix Version/s: 7.2.0.Alpha1
Component/s: Domain Management
Added "Domain Management" component as this affects any management client that uses the native interface.
> org.jboss.as.protocol.ProtocolChannelClient needs to support client socket bind address config
> ----------------------------------------------------------------------------------------------
>
> Key: AS7-6223
> URL: https://issues.jboss.org/browse/AS7-6223
> Project: Application Server 7
> Issue Type: Feature Request
> Components: CLI, Domain Management
> Affects Versions: 7.1.0.Final
> Reporter: William DeCoste
> Assignee: William DeCoste
> Fix For: 7.2.0.Alpha1
>
>
> OpenShift requires that the client socket bind address be set to the OPENSHIFT_INTENRAL_IP loopback. ProtocolChannelClient currently does not support config for the bind address. connect(..) should be calling
> return endpoint.connect("remote", bindAddress, destAddress, builder.getMap(), actualHandler, sslContext);
> instead of
>
> return endpoint.connect(uri, builder.getMap(), actualHandler, sslContext);
> and expose bindAddress config
--
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
[JBoss JIRA] (AS7-6222) JCA workmanager "name" attribute should not support expressions
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/AS7-6222?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry updated AS7-6222:
----------------------------------
Summary: JCA workmanager "name" attribute should not support expressions (was: JCA workmanager and bootstrap-context "name" attributes should not support expressions)
Edited title to remove bootstrap-context, which does not have this problem.
> JCA workmanager "name" attribute should not support expressions
> ---------------------------------------------------------------
>
> Key: AS7-6222
> URL: https://issues.jboss.org/browse/AS7-6222
> Project: Application Server 7
> Issue Type: Sub-task
> Components: Domain Management, JCA
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 7.2.0.Alpha1
>
>
> These "name" attributes represent part of the address of a resource. Resource address elements cannot support expressions, because their value needs to be resolvable
> 1) before all system property values are known
> 2) on the master host controller, which may have different resolution sources from other HCs or the servers.
--
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