[JBoss JIRA] (WFLY-2387) CDI injection in entity listeners failing
by Cody Lerum (JIRA)
[ https://issues.jboss.org/browse/WFLY-2387?page=com.atlassian.jira.plugin.... ]
Cody Lerum commented on WFLY-2387:
----------------------------------
Are we going to see this workaround in Wildfly 9 or is going to be held for spec clarification?
> CDI injection in entity listeners failing
> -----------------------------------------
>
> Key: WFLY-2387
> URL: https://issues.jboss.org/browse/WFLY-2387
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: CDI / Weld, Class Loading, JPA / Hibernate
> Affects Versions: 8.0.0.Beta1
> Reporter: Emond Papegaaij
> Assignee: Scott Marlow
> Fix For: 9.0.0.CR1
>
> Attachments: TEST-org.jboss.as.test.integration.ee.injection.support.jpa.EntityListenerInjectionSupportTestCase.xml
>
>
> When trying to use CDI injection in JPA entity listeners, deployment fails with the following exception:
> {code}
> 16:16:37,448 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 15) MSC000001: Failed to start service jboss.persistenceunit."inject-ear.ear#primary": org.jboss.msc.service.StartException in service jboss.persistenceunit."inject-ear.ear#primary": java.lang.IllegalStateException: JBAS016071: Singleton not set for org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl$AggregatedClassLoader@4eeb95dc. This means that you are trying to access a weld deployment with a Thread Context ClassLoader that is not associated with the deployment.
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:169)
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:117)
> at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_25]
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:463) [wildfly-security-manager-1.0.0.Beta3.jar:1.0.0.Beta3]
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:178)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> Caused by: java.lang.IllegalStateException: JBAS016071: Singleton not set for org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl$AggregatedClassLoader@4eeb95dc. This means that you are trying to access a weld deployment with a Thread Context ClassLoader that is not associated with the deployment.
> at org.jboss.as.weld.services.ModuleGroupSingletonProvider$TCCLSingleton.get(ModuleGroupSingletonProvider.java:75)
> at org.jboss.as.weld.services.ModuleGroupSingletonProvider$TCCLSingleton.get(ModuleGroupSingletonProvider.java:128)
> at org.jboss.weld.Container.instance(Container.java:65)
> at org.jboss.weld.manager.BeanManagerImpl.getBeans(BeanManagerImpl.java:563)
> at org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:90)
> at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:358)
> at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:369)
> at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:72)
> at org.jboss.weld.injection.producer.ResourceInjector.inject(ResourceInjector.java:60)
> at org.jboss.weld.injection.producer.DefaultInjector$1.proceed(DefaultInjector.java:66)
> at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48)
> at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:64)
> at org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:90)
> at org.hibernate.jpa.event.internal.jpa.BeanManagerListenerFactory$BeanMetaData.<init>(BeanManagerListenerFactory.java:82)
> at org.hibernate.jpa.event.internal.jpa.BeanManagerListenerFactory$BeanMetaData.<init>(BeanManagerListenerFactory.java:71)
> at org.hibernate.jpa.event.internal.jpa.BeanManagerListenerFactory.buildListener(BeanManagerListenerFactory.java:57)
> at org.hibernate.jpa.event.internal.jpa.LegacyCallbackProcessor.resolveCallbacks(LegacyCallbackProcessor.java:168)
> at org.hibernate.jpa.event.internal.jpa.LegacyCallbackProcessor.processCallbacksForEntity(LegacyCallbackProcessor.java:71)
> at org.hibernate.jpa.event.spi.JpaIntegrator.integrate(JpaIntegrator.java:150)
> at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:310)
> at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1837)
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:854)
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:847)
> at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:396)
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:846)
> at org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:151)
> ... 8 more
> {code}
> I've created a small showcase of the problem: https://github.com/papegaaij/listener-injection
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 2 months
[JBoss JIRA] (WFLY-3711) Topology updates of EJBClient ClusterContexts not being updated correctly after failover
by Richard Achmatowicz (JIRA)
Richard Achmatowicz created WFLY-3711:
-----------------------------------------
Summary: Topology updates of EJBClient ClusterContexts not being updated correctly after failover
Key: WFLY-3711
URL: https://issues.jboss.org/browse/WFLY-3711
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Clustering
Affects Versions: 9.0.0.Beta1
Reporter: Richard Achmatowicz
Assignee: Richard Achmatowicz
ClusterContexts are used by EJBClient to keep track of the current set of nodes in a cluster, so that if an EJBClient invocation fails on one node, it may failover to another node in the same cluster. The ClusterContext is made up of ClusterNodeManagers which are responsible for setting up the connections between the EJBClient and the nodes in the cluster.
Cluster topology updates are sent to registered EJBClients whenever the cluster topology changes (nodes join, nodes leave a cluster). Thse topology updates are processed on the client side by ClusterTopologyUpdateHandler and are used to update the current contents of the associated ClusterContext held on the client.
The current implementation of the handling of topology updates does not correctly handle the addition/removal of ClusterNodeManagers from the cluster context - namely, rather than check whether or not a new ClusterNodeManager really needs to be added, ClusterNodeManagers are added for every node in the received topology update, leading to many unnecessary EJBReceivers and their channels being created.
The logs show that up to 18 cluster node manager instances may be created, have their EJBReceivers registered and channels to the remote node created, when only one node has been added to the cluster.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 2 months
[JBoss JIRA] (WFLY-3699) Missing param-name in a web.xml causes NullPointerException during deployment
by Farah Juma (JIRA)
[ https://issues.jboss.org/browse/WFLY-3699?page=com.atlassian.jira.plugin.... ]
Farah Juma commented on WFLY-3699:
----------------------------------
Thanks for creating a PR, Jay.
> Missing param-name in a web.xml causes NullPointerException during deployment
> ------------------------------------------------------------------------------
>
> Key: WFLY-3699
> URL: https://issues.jboss.org/browse/WFLY-3699
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JSF, Web (Undertow)
> Affects Versions: 9.0.0.Beta1
> Reporter: Jay Kumar SenSharma
> Assignee: Farah Juma
> Attachments: ContextParamNullDemo.war
>
>
> - While deploying a WAR, If the web.xml file is used which has context <param-value> defined, However it has missing <param-name> then it causes NullPointerException as following:
> {code}
> 00:12:09,583 INFO [org.jboss.as.server.deployment] (MSC service thread 1-6) WFLYSRV0027: Starting deployment of "ContextParamNullDemo.war" (runtime-name: "ContextParamNullDemo.war")
> 00:12:09,591 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.deployment.unit."ContextParamNullDemo.war".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.unit."ContextParamNullDemo.war".PARSE: WFLYSRV0153: Failed to process phase PARSE of deployment "ContextParamNullDemo.war"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:163) [wildfly-server-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> Caused by: java.lang.NullPointerException
> at org.jboss.as.jsf.deployment.JSFVersionProcessor.deploy(JSFVersionProcessor.java:91)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156) [wildfly-server-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT]
> ... 5 more
> 00:12:09,598 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "ContextParamNullDemo.war")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"ContextParamNullDemo.war\".PARSE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"ContextParamNullDemo.war\".PARSE: WFLYSRV0153: Failed to process phase PARSE of deployment \"ContextParamNullDemo.war\"
> Caused by: java.lang.NullPointerException"}}
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 2 months
[JBoss JIRA] (WFLY-3710) Break close association of AppclientXml with WildFly-Core
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-3710?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse commented on WFLY-3710:
----------------------------------------
Looks like we also need to go one step further, whilst AppClientXml parses the 'server' element it only supports a subset of it's content. For better or worse the schemas are the document that describes the XML we support - deliberately rejecting configuration that is valid against the schema is not good.
> Break close association of AppclientXml with WildFly-Core
> ---------------------------------------------------------
>
> Key: WFLY-3710
> URL: https://issues.jboss.org/browse/WFLY-3710
> Project: WildFly
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: Application Client, Domain Management
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 9.0.0.Beta1
>
>
> AppClientXml is written on the basis that it is in the same project as the remaining domain management parsers, as an example it is dependent on calling certain version specific vault methods.
> Changes will also be needed to wildfly-core but any access to parsers in wildfly-core should be switched to agreed entry points that will be maintained by compatibility.
> As an example this block: -
> {code}
> if (element == Element.VAULT) {
> switch (namespace) {
> //Less than 1.1 does not end up in this method
> case DOMAIN_1_1:
> case DOMAIN_1_2:
> case DOMAIN_1_3:
> case DOMAIN_1_4:
> case DOMAIN_1_5:
> case DOMAIN_2_0:
> case DOMAIN_2_1: {
> parseVault_1_1(reader, address, namespace, list);
> break;
> }
> default: {
> parseVault_3_0(reader, address, namespace, list);
> }
> }
> {code}
> Should be replaced with a call to parseVault(), the parseVault() method will then be responsible for identifying the correct version.
> Changes should also be made to AppClientXml to make it compatible with multiple major versions in use concurrently for jboss-as-config - otherwise this class is seriously likely to be missed again for all further updates.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 2 months
[JBoss JIRA] (WFCORE-42) Add a ServerXml Parser which extends CommonXml
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-42?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse commented on WFCORE-42:
----------------------------------------
Looks like we also need to go one step further, whilst AppClientXml parses the 'server' element it only supports a subset of it's content. For better or worse the schemas are the document that describes the XML we support - deliberately rejecting configuration that is valid against the schema is not good.
> Add a ServerXml Parser which extends CommonXml
> ----------------------------------------------
>
> Key: WFCORE-42
> URL: https://issues.jboss.org/browse/WFCORE-42
> Project: WildFly Core
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 1.0.0.Alpha4
>
>
> Both StandaloneXml and AppclientXml parse XML starting from the server element.
> This duplication has always been problematic as AppclientXml is completely separate from the remaining domain config parsing, however with the core split this is even worse.
> This change is to introduce a ServerXml that can be the common base for both StandaloneXml and AppclientXml - except in extreme cases it will then be safe to ignore AppclientXml for further schema updates.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 2 months
[JBoss JIRA] (WFCORE-42) Add a ServerXml Parser which extends CommonXml
by Darran Lofthouse (JIRA)
Darran Lofthouse created WFCORE-42:
--------------------------------------
Summary: Add a ServerXml Parser which extends CommonXml
Key: WFCORE-42
URL: https://issues.jboss.org/browse/WFCORE-42
Project: WildFly Core
Issue Type: Task
Security Level: Public (Everyone can see)
Components: Domain Management
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 1.0.0.Alpha4
Both StandaloneXml and AppclientXml parse XML starting from the server element.
This duplication has always been problematic as AppclientXml is completely separate from the remaining domain config parsing, however with the core split this is even worse.
This change is to introduce a ServerXml that can be the common base for both StandaloneXml and AppclientXml - except in extreme cases it will then be safe to ignore AppclientXml for further schema updates.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 2 months
[JBoss JIRA] (WFLY-3149) Windows service on 64 bit systems cannot be stopped
by Otmar Caduff (JIRA)
[ https://issues.jboss.org/browse/WFLY-3149?page=com.atlassian.jira.plugin.... ]
Otmar Caduff commented on WFLY-3149:
------------------------------------
Had the same symptom. In my case, I set JAVA_HOME at the beginning of jboss.cli.bat. Worked afterwards.
Didn't want to set JAVA_HOME env variable, because we're working with different JDKs.
> Windows service on 64 bit systems cannot be stopped
> ---------------------------------------------------
>
> Key: WFLY-3149
> URL: https://issues.jboss.org/browse/WFLY-3149
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Scripts
> Affects Versions: 8.0.0.Final
> Environment: Windows 2008 Server, Windows 7 professional - both 64 bit systems using JDK 1.7.0_09
> Reporter: Mohan Potturi
> Assignee: Mladen Turk
>
> The Windows service cannot be stopped. It says 'stopping' in the windows service user interface window. The only way to stop it is ti actually kill the java process. It works flawlessly on 32 bit systems though.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 2 months