[JBoss JIRA] (WFCORE-1882) Deal with WFCORE-1052 functionality in the HA DC case
by Ken Wills (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1882?page=com.atlassian.jira.plugi... ]
Ken Wills commented on WFCORE-1882:
-----------------------------------
This was completed here: https://github.com/bstansberry/wildfly-core/commit/e496bee63851ed53811fbb...
> Deal with WFCORE-1052 functionality in the HA DC case
> -----------------------------------------------------
>
> Key: WFCORE-1882
> URL: https://issues.jboss.org/browse/WFCORE-1882
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Ken Wills
>
> WFCORE-1052 adds the ability to reload a process to a different config file from what it is currently running. That includes the domain-wide config file if the reloading process is a master HC.
> I don't think we want to support this in a WFCORE-338 scenario, as it amounts to a mechanism to force a different domain-wide config into the domain. I think we should have a more specific, controlled mechanism for that.
> Once WFCORE-1881 is implemented HostProcessReloadHandler can check LocalHostControllerInfo to see if its running in a CDC. Note that this issue may have implications on the design of WFCORE-1881. That is, it may not be the case that if LHCI.isMaster() is true then LHCI.isCandidateDomainController() is true. Perhaps an HC configured in the EAP 7.0 and earlier style could be a master but not a CDC. For such an HC the WFCORE-1052 functionality could be available.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-7645) some typos in Undertows crawler-session-management descriptions
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-7645?page=com.atlassian.jira.plugin.... ]
Stuart Douglas moved JBEAP-7434 to WFLY-7645:
---------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-7645 (was: JBEAP-7434)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Web (Undertow)
(was: Web (Undertow))
Affects Version/s: (was: 7.1.0.DR8)
> some typos in Undertows crawler-session-management descriptions
> ---------------------------------------------------------------
>
> Key: WFLY-7645
> URL: https://issues.jboss.org/browse/WFLY-7645
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Reporter: Stuart Douglas
> Assignee: Stuart Douglas
> Priority: Trivial
>
> Description for {{crawler-session-management}} contains a few typo's:
> {{/subsystem=undertow/servlet-container=default/setting=crawler-session-management:read-resource-description}}
> {quote}
> Configures special session *handing* for crawler bots
> {quote}
> should be {{handling}}
> {quote}
> Regular expression that is used to match the user *agenet* of a crawler
> {quote}
> should be {{agent}}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFCORE-918) Allow embedded server logging to be overridden by properties
by Ken Wills (JIRA)
[ https://issues.jboss.org/browse/WFCORE-918?page=com.atlassian.jira.plugin... ]
Ken Wills commented on WFCORE-918:
----------------------------------
See WFCORE-1187 / WFCORE-1829 for the issues tracking this. Closing this as a duplicate.
> Allow embedded server logging to be overridden by properties
> ------------------------------------------------------------
>
> Key: WFCORE-918
> URL: https://issues.jboss.org/browse/WFCORE-918
> Project: WildFly Core
> Issue Type: Feature Request
> Components: CLI
> Reporter: Ken Wills
> Assignee: Ken Wills
> Fix For: 3.0.0.Beta1
>
>
> For example:
> $ export JBOSS_HOME=/home/kwills/git/wildfly/build/target/wf/
> $ java -jar wildfly-10.0.0.CR1-SNAPSHOT/bin/client/jboss-cli-client.jar -Djboss.server.base.dir=standalone1 -Djboss.server.log.dir=log
> [disconnected /] embed-server --std-out=echo
> This should log to $JBOSS_HOME/standalone1/log
> The properties available to override are:
> jboss.server.base.dir defaults to jbossHome.getAbsolutePath() + File.separator + "standalone" ("domain" for domain servers).
> jboss.server.configuration.dir defaults to "configuration"
> jboss.server.log.dir defaults to log
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFCORE-918) Allow embedded server logging to be overridden by properties
by Ken Wills (JIRA)
[ https://issues.jboss.org/browse/WFCORE-918?page=com.atlassian.jira.plugin... ]
Ken Wills closed WFCORE-918.
----------------------------
Resolution: Duplicate Issue
> Allow embedded server logging to be overridden by properties
> ------------------------------------------------------------
>
> Key: WFCORE-918
> URL: https://issues.jboss.org/browse/WFCORE-918
> Project: WildFly Core
> Issue Type: Feature Request
> Components: CLI
> Reporter: Ken Wills
> Assignee: Ken Wills
> Fix For: 3.0.0.Beta1
>
>
> For example:
> $ export JBOSS_HOME=/home/kwills/git/wildfly/build/target/wf/
> $ java -jar wildfly-10.0.0.CR1-SNAPSHOT/bin/client/jboss-cli-client.jar -Djboss.server.base.dir=standalone1 -Djboss.server.log.dir=log
> [disconnected /] embed-server --std-out=echo
> This should log to $JBOSS_HOME/standalone1/log
> The properties available to override are:
> jboss.server.base.dir defaults to jbossHome.getAbsolutePath() + File.separator + "standalone" ("domain" for domain servers).
> jboss.server.configuration.dir defaults to "configuration"
> jboss.server.log.dir defaults to log
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFCORE-1187) Embedded server start / stop / start with new --jboss-home continues to refer to previous server.log
by Ken Wills (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1187?page=com.atlassian.jira.plugi... ]
Ken Wills commented on WFCORE-1187:
-----------------------------------
Note, this is mostly fixed by WFCORE-1977, however, starting an embedded server does not currently override configured logging properties correctly.
This means that in, for example the manualmode unit tests, standalone servers that are started, then stopped will persist a hardcoded path to a logfile that will then be picked up by the embedded server when starting and logged to.
This should replace any changes that were made (and abandoned by WFCORE-918)
> Embedded server start / stop / start with new --jboss-home continues to refer to previous server.log
> ----------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1187
> URL: https://issues.jboss.org/browse/WFCORE-1187
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Reporter: Ken Wills
> Assignee: Ken Wills
>
> - start-embedded-server --jboss-home=/foo/bar1
> - stop-embedded-server
> - start-embedded-server --jboss-home=/foo/bar2
> -- server.log in /foo/bar1/standalone/logs/server.log is still written to.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFCORE-1880) Extension add operation handling should check that the slave HCs are not running later versions of the subsystem management API
by Ken Wills (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1880?page=com.atlassian.jira.plugi... ]
Ken Wills commented on WFCORE-1880:
-----------------------------------
Note, this is in progress here: https://github.com/bstansberry/wildfly-core/tree/WFCORE-338
> Extension add operation handling should check that the slave HCs are not running later versions of the subsystem management API
> -------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1880
> URL: https://issues.jboss.org/browse/WFCORE-1880
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Ken Wills
>
> Conceptually related to WFCORE-1879, but here the case is a slave that is already registered handling an /extension=foo:add operation sent by the master. It's theoretically possible that the slave might be running an earlier or equal version of all extensions that were configured when it registered, but for this new "foo" extension it has a newer version. If this happens the add operation should fail. The extension cannot be configured while the domain topology is like this.
> Note if the slave is ignoring the extension add op, that is fine.
> It's possible this is already somewhat handled. If an extension is added, for transformation to work properly the slave has to send back management API information that the master can use going forward. It's possible though that even that is not being done, which would be a bug.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFCORE-1881) Add isCandidateDomainController() to LocalHostControllerInfo and use it where possible
by Ken Wills (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1881?page=com.atlassian.jira.plugi... ]
Ken Wills commented on WFCORE-1881:
-----------------------------------
Note, this is in progress here: https://github.com/bstansberry/wildfly-core/tree/WFCORE-338
> Add isCandidateDomainController() to LocalHostControllerInfo and use it where possible
> --------------------------------------------------------------------------------------
>
> Key: WFCORE-1881
> URL: https://issues.jboss.org/browse/WFCORE-1881
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Ken Wills
>
> The WFCORE-338 work is going to add the notion of an HC being configured as a Candidate Domain Controller, which is a separate thing from being "master". There are a number of places where LocalHostControllerInfo.isMaster() is being called to make decisions that with WFCORE-338 should really depend on whether the HC is a CDC, not whether it is master. So, we want LHCI to expose whether the HC is a CDC.
> I think initially we can have isCandidateDomainController() just return the result of isMaster(). We can add a setter to LocalHostControllerInfoImpl later when we actually make the CDC status independently configurable.
> Places that should be updated as part of this task to use isCandidateDomainController() instead of isMaster():
> 1) ProfileCloneHandler
> 2) IgnoredDomainResourceRegistry
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFCORE-1879) Master HC should reject registration attempts by slaves that have any management API version greater than its own
by Ken Wills (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1879?page=com.atlassian.jira.plugi... ]
Ken Wills commented on WFCORE-1879:
-----------------------------------
Note, this is in progress here: https://github.com/bstansberry/wildfly-core/tree/WFCORE-338
> Master HC should reject registration attempts by slaves that have any management API version greater than its own
> -----------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1879
> URL: https://issues.jboss.org/browse/WFCORE-1879
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Ken Wills
>
> (Note: It's possible we already do this, or that somehow we effectively do due to things blowing up if the rule is broken.)
> We have always had a rule that the DC must be running the latest version of the software. If it isn't it can't reliably manage slaves as it cannot know how the slaves will interpret the operations it sends to them, and slaves will assume that the master is sending operations that are tailored to the management API versions it sent when it registered.
> I do not believe the software actually enforces this requirement though. With the more complex use cases that WFCORE-338 will introduce we need to make this more formal.
> When a slave first contacts a master it provides its kernel API version with the HostInfo data it sends over and then later in the registration process it provides the subsystem API versions for all the extensions the master provided. Both of these points provide an opportunity for version comparison.
> When an HC rejects registration by a slave, we have a mechanism for propogating an error code to the slave to help it understand and report the problem (e.g. the remote HC is not master or it is running in admin-only mode.) We should try to expand that mechanism to include this case, rather than failing with a general unspecified error.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-6319) NPE in LocalEjbReceiver.removeClusterNodes during server shutdown
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/WFLY-6319?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz commented on WFLY-6319:
-------------------------------------------
[~mvinkler]
Michal, I checked the latest mysql and postgres runs for the above tests and I don't see the error appearing any longer. Could you confirm if this is still an issue?
By the way, the proposed fix was to apply the logic of VersionOneProtocolChannelReceiver.registryRemoved() to LocalEJBReceiver.registryRemoved(). This probably should be done anyway to keep the two in sync.
> NPE in LocalEjbReceiver.removeClusterNodes during server shutdown
> -----------------------------------------------------------------
>
> Key: WFLY-6319
> URL: https://issues.jboss.org/browse/WFLY-6319
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Reporter: Ladislav Thon
> Assignee: Dmitrii Tikhomirov
>
> In a failover test that passivates sessions to a SQL database (though I think this isn't really relevant much), I've seen a NPE in {{LocalEjbReceiver.removeClusterNodes}}:
> {code}
> 04:09:29,330 WARN [org.jboss.msc.service.fail] (MSC service thread 1-6) MSC000004: Failure during stop of service jboss.ejb3.localEjbReceiver.value: java.lang.NullPointerException
> at org.jboss.as.ejb3.remote.LocalEjbReceiver.removeClusterNodes(LocalEjbReceiver.java:701)
> at org.jboss.as.ejb3.remote.LocalEjbReceiver.disassociate(LocalEjbReceiver.java:681)
> at org.jboss.ejb.client.EJBClientContext.unregisterEJBReceiver(EJBClientContext.java:446)
> at org.jboss.ejb.client.EJBReceiverContext.close(EJBReceiverContext.java:57)
> at org.jboss.as.ejb3.remote.LocalEjbReceiver.stop(LocalEjbReceiver.java:410)
> at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:2056)
> at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:2017)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> This happens during server shutdown, so it probably doesn't affect anything.
> Logs:
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-db-s...
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-db-s...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-2387) CDI injection in entity listeners failing
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-2387?page=com.atlassian.jira.plugin.... ]
Scott Marlow commented on WFLY-2387:
------------------------------------
[WFLY-6941] was merged today, which helps with the progress of this jira. The [https://github.com/scottmarlow/wildfly/commits/WFLY-2387_ORM51_CDI_INJECTION] change uses a Hibernate extension to defer the entity listener registration until AfterDeploymentValidation time. Some persistence providers (e.g. EclipseLink) defer the creation of the entity listener until first use.
[~meetoblivion] Sorry for ignoring your question for too long. You are correct, that the (mine & others) initial assumption is that an entity listener is booted on start up of the persistence unit.
Regarding, your point about @RequestScoped, the JPA 2.1 specification section 3.5.1 does mention "An entity listener is a noncontextual object." and other details about how the persistence provider should create the entity listener.
I agree with your points about how JPA could wait the AfterDeploymentValidation time to get the entity listener. I updated [https://java.net/jira/browse/JPA_SPEC-83?focusedCommentId=392803&page=com...] to reflect that.
> CDI injection in entity listeners failing
> -----------------------------------------
>
> Key: WFLY-2387
> URL: https://issues.jboss.org/browse/WFLY-2387
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, Class Loading, JPA / Hibernate
> Affects Versions: 8.0.0.Beta1
> Reporter: Emond Papegaaij
> Assignee: Scott Marlow
> 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
(v7.2.3#72005)
9 years, 5 months