[JBoss JIRA] (WFCORE-1260) Capability resolution complaints on admin-only slave HCs not connected to the master
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1260?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1260:
-------------------------------------
Fix Version/s: 3.0.0.Alpha1
> Capability resolution complaints on admin-only slave HCs not connected to the master
> ------------------------------------------------------------------------------------
>
> Key: WFCORE-1260
> URL: https://issues.jboss.org/browse/WFCORE-1260
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.0.5.Final
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 3.0.0.Alpha1
>
>
> If you start a slave HC in admin-only with no master to connect to, boot is fine but then any modifications made to the config result in capability resolution ERROR messages in the host-controller.log
> Starting a slave HC in admin-only with no master to connect to is meant to work, allowing you to use CLI to manipulate the slave's host config:
> {code}
> bin/domain.sh --host-config=host-slave.xml --admin-only -Djboss.domain.master.address=127.0.0.1
> {code}
> The boot is fine:
> {code}
> [Host Controller] 11:06:10,639 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 10.0.0.Final-SNAPSHOT (WildFly Core 2.0.5.Final) (Host Controller) started in 1152ms - Started 41 of 42 services (12 services are lazy, passive or on-demand)
> {code}
> However, subsequent changes made via management tools (e.g. CLI) succeed but result in ERROR logging by the HC:
> {code}
> [domain@127.0.0.1:9999 /] /host=localhost/system-property=foo:add(value=bar)
> {
> "outcome" => "success",
> "result" => undefined,
> "server-groups" => undefined
> }
> {code}
> The HC's log:
> {code}
> [Host Controller] 11:07:37,744 ERROR [org.jboss.as.controller] (management-handler-thread - 4) WFLYCTL0369: Required capabilities are not available:
> [Host Controller] org.wildfly.domain.server-group.other-server-group in context 'server-config'; There are no known registration points which can provide this capability.
> [Host Controller] org.wildfly.domain.server-group.main-server-group in context 'server-config'; There are no known registration points which can provide this capability.
> {code}
> The boot works without logging because of the enhancement Stuart added such that capability reference failures won't fail an admin-only boot, thus letting the user use admin-only to fix the config. But then with subsequent changes, the user gets ERRORs notifying them of the unfixed references.
> But in this case, the references will never be available, so long as there is no connection to a master to provide the domain-wide config.
> This is a general case that needs to be accounted for in the capability resolution logic.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFCORE-1277) Embed-server from CLI launch shows twice prompt string
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1277?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1277:
------------------------------------------
Yesterday using non-embedded CLI I noticed something similar after using CLI to shut down the server:
{code}
[standalone@localhost:9990 /] shutdown
[disconnected /] [disconnected /]
{code}
> Embed-server from CLI launch shows twice prompt string
> ------------------------------------------------------
>
> Key: WFCORE-1277
> URL: https://issues.jboss.org/browse/WFCORE-1277
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 2.0.5.Final
> Reporter: Chao Wang
> Assignee: Chao Wang
> Priority: Minor
>
> {noformat}
> When I launch an embed-server from CLI, it displays twice [standalone@embedded /] [standalone@embedded /] for the first time.
> [wangc@dhcp-128-40 wildfly-10.0.0.Final-SNAPSHOT]$ sh bin/jboss-cli.sh
> You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.
> [disconnected /] embed-server
> [standalone@embedded /] [standalone@embedded /] ls
> core-service launch-type=EMBEDDED product-version=undefined
> deployment management-major-version=4 profile-name=undefined
> deployment-overlay management-micro-version=0 release-codename=Kenny
> extension management-minor-version=0 release-version=2.0.5.Final
> interface name=dhcp-128-40 running-mode=ADMIN_ONLY
> path namespaces=[] schema-locations=[]
> socket-binding-group organization=undefined server-state=running
> subsystem process-type=Server suspend-state=RUNNING
> system-property product-name=undefined uuid=8c4ede2f-8e14-48bf-9eaf-73947e23edcf
> [standalone@embedded /] quit
> {noformat}
> This does not happen in 2.0.4.Final.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (DROOLS-1012) kie-ci-osgi Activator doesn't register the ClassLoaderResolver on the ServiceRegistry
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1012?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration commented on DROOLS-1012:
-------------------------------------------------
Alessandro Lazarotti <alazarot(a)redhat.com> changed the Status of [bug 1293965|https://bugzilla.redhat.com/show_bug.cgi?id=1293965] from MODIFIED to ON_QA
> kie-ci-osgi Activator doesn't register the ClassLoaderResolver on the ServiceRegistry
> -------------------------------------------------------------------------------------
>
> Key: DROOLS-1012
> URL: https://issues.jboss.org/browse/DROOLS-1012
> Project: Drools
> Issue Type: Bug
> Reporter: Mario Fusco
> Assignee: Mario Fusco
> Fix For: 6.4.x
>
> Attachments: brms-fuse-integration-master.tgz
>
>
> kie-ci-osgi Activator doesn't register the ClassLoaderResolver on the ServiceRegistry. This implies that when the KieContainer is created in a OSGi environment it is not able to get an instance of the MavenClassLoaderResolver and then cannot create a ClassLoader including all the transitive dependencies of the kjar to be compiled.
> The attached project reproduces this issue. In order to run it, it's enough to do a mvn clean install of the project and issue the following commands in fuse:
> features:addurl mvn:com.redhat/brms-fuse-integration-features/0.0.1-SNAPSHOT/xml/features
> features:install brms-integration-bundle
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFLY-5484) Calling HttpServletRequest.logout() with single sign-on enabled only works every second time
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-5484?page=com.atlassian.jira.plugin.... ]
Paul Ferraro edited comment on WFLY-5484 at 1/7/16 2:48 PM:
------------------------------------------------------------
This issue seems to be due to a conflict between Undertow's CachedAuthenticatedSessionMechanism and SingleSignOnMechanism. If the CachedAuthenticatedSessionMechanism detects an AuthenticatedSession in the HttpSession, the SingleSignOnMechanism never has the chance to register a security notification listener, thus the SSO is not invalidated on logout, not until the AuthenticatedSession is first removed from the session in a previous request. Reassigning this to [~swd847] as this is an issue with Undertow security, not with clustering SSO management.
was (Author: pferraro):
This issue seems to be due to a conflict between Undertow's CachedAuthenticatedSessionMechanism and SingleSignOnMechanism. If the CachedAuthenticatedSessionMechanism detects an AuthenticatedSession in the HttpSession, the SingleSignOnMechanism never has the chance to register a security notification listener, thus the SSO is not invalidated on logout. Reassigning this to [~swd847] as this is clearly an issue with Undertow security, not with clustering SSO management.
> Calling HttpServletRequest.logout() with single sign-on enabled only works every second time
> --------------------------------------------------------------------------------------------
>
> Key: WFLY-5484
> URL: https://issues.jboss.org/browse/WFLY-5484
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Reporter: Richard Janík
> Assignee: Stuart Douglas
> Priority: Blocker
> Fix For: 10.0.0.CR5
>
> Attachments: reproducer-jbeap-1282.zip
>
>
> See "Steps to Reproduce". Logging out from an application only works every second time, e.g. HttpRequestServlet.logout() has to be called twice in order to have any effect
> This doesn't occur without <single-sign-on/> enabled - logout() has the expected effect. The issue is security related, thus I'm adding our security team members as watchers.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFLY-5484) Calling HttpServletRequest.logout() with single sign-on enabled only works every second time
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-5484?page=com.atlassian.jira.plugin.... ]
Paul Ferraro commented on WFLY-5484:
------------------------------------
This issue seems to be due to a conflict between Undertow's CachedAuthenticatedSessionMechanism and SingleSignOnMechanism. If the CachedAuthenticatedSessionMechanism detects an AuthenticatedSession in the HttpSession, the SingleSignOnMechanism never has the chance to register a security notification listener, thus the SSO is not invalidated on logout. Reassigning this to [~swd847] as this is clearly an issue with Undertow security, not with clustering SSO management.
> Calling HttpServletRequest.logout() with single sign-on enabled only works every second time
> --------------------------------------------------------------------------------------------
>
> Key: WFLY-5484
> URL: https://issues.jboss.org/browse/WFLY-5484
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Web (Undertow)
> Reporter: Richard Janík
> Assignee: Paul Ferraro
> Priority: Blocker
> Fix For: 10.0.0.CR5
>
> Attachments: reproducer-jbeap-1282.zip
>
>
> See "Steps to Reproduce". Logging out from an application only works every second time, e.g. HttpRequestServlet.logout() has to be called twice in order to have any effect
> This doesn't occur without <single-sign-on/> enabled - logout() has the expected effect. The issue is security related, thus I'm adding our security team members as watchers.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFLY-5484) Calling HttpServletRequest.logout() with single sign-on enabled only works every second time
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-5484?page=com.atlassian.jira.plugin.... ]
Paul Ferraro updated WFLY-5484:
-------------------------------
Component/s: (was: Clustering)
> Calling HttpServletRequest.logout() with single sign-on enabled only works every second time
> --------------------------------------------------------------------------------------------
>
> Key: WFLY-5484
> URL: https://issues.jboss.org/browse/WFLY-5484
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Reporter: Richard Janík
> Assignee: Paul Ferraro
> Priority: Blocker
> Fix For: 10.0.0.CR5
>
> Attachments: reproducer-jbeap-1282.zip
>
>
> See "Steps to Reproduce". Logging out from an application only works every second time, e.g. HttpRequestServlet.logout() has to be called twice in order to have any effect
> This doesn't occur without <single-sign-on/> enabled - logout() has the expected effect. The issue is security related, thus I'm adding our security team members as watchers.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFLY-5484) Calling HttpServletRequest.logout() with single sign-on enabled only works every second time
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-5484?page=com.atlassian.jira.plugin.... ]
Paul Ferraro reassigned WFLY-5484:
----------------------------------
Assignee: Stuart Douglas (was: Paul Ferraro)
> Calling HttpServletRequest.logout() with single sign-on enabled only works every second time
> --------------------------------------------------------------------------------------------
>
> Key: WFLY-5484
> URL: https://issues.jboss.org/browse/WFLY-5484
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Reporter: Richard Janík
> Assignee: Stuart Douglas
> Priority: Blocker
> Fix For: 10.0.0.CR5
>
> Attachments: reproducer-jbeap-1282.zip
>
>
> See "Steps to Reproduce". Logging out from an application only works every second time, e.g. HttpRequestServlet.logout() has to be called twice in order to have any effect
> This doesn't occur without <single-sign-on/> enabled - logout() has the expected effect. The issue is security related, thus I'm adding our security team members as watchers.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFLY-5951) pending-puts cache configuration is not started by the JPA subsystem
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-5951?page=com.atlassian.jira.plugin.... ]
Scott Marlow edited comment on WFLY-5951 at 1/7/16 12:53 PM:
-------------------------------------------------------------
sample TRACE output:
{noformat}
2016-01-07 11:12:47,305 TRACE [org.jboss.as.jpa] (MSC service thread 1-1) add second level cache dependencies with properties '{timestamps=timestamps, pending-puts=pending-puts, natural-id=entity, container=hibernate, entity=entity, query=local-query, immutable-entity=immutable-entity, collection=entity}'
2016-01-07 11:12:47,306 TRACE [org.jboss.as.jpa] (MSC service thread 1-1) add second level cache dependency on service 'jboss.infinispan.hibernate.entity.config'
2016-01-07 11:12:47,306 TRACE [org.jboss.as.jpa] (MSC service thread 1-1) add second level cache dependency on service 'jboss.infinispan.hibernate.immutable-entity.config'
2016-01-07 11:12:47,306 TRACE [org.jboss.as.jpa] (MSC service thread 1-1) add second level cache dependency on service 'jboss.infinispan.hibernate.entity.config'
2016-01-07 11:12:47,306 TRACE [org.jboss.as.jpa] (MSC service thread 1-1) add second level cache dependency on service 'jboss.infinispan.hibernate.entity.config'
2016-01-07 11:12:47,307 TRACE [org.jboss.as.jpa] (MSC service thread 1-1) add second level cache dependency on service 'jboss.infinispan.hibernate.pending-puts.config'
2016-01-07 11:12:47,307 TRACE [org.jboss.as.jpa] (MSC service thread 1-1) add second level cache dependency on service 'jboss.infinispan.hibernate.timestamps.config'
2016-01-07 11:12:47,307 TRACE [org.jboss.as.jpa] (MSC service thread 1-1) add second level cache dependency on service 'jboss.infinispan.hibernate.local-query.config'
2016-01-07 11:12:47,307 TRACE [org.jboss.as.jpa] (MSC service thread 1-1) added PersistenceUnitService (phase 2 of 2) for 'service jboss.persistenceunit."jboss-as-hibernate4Test.war#secondary"'. PU is
{noformat}
was (Author: smarlow):
sample TRACE output:
{quote}
2016-01-07 11:12:47,305 TRACE [org.jboss.as.jpa] (MSC service thread 1-1) add second level cache dependencies with properties '{timestamps=timestamps, pending-puts=pending-puts, natural-id=entity, container=hibernate, entity=entity, query=local-query, immutable-entity=immutable-entity, collection=entity}'
2016-01-07 11:12:47,306 TRACE [org.jboss.as.jpa] (MSC service thread 1-1) add second level cache dependency on service 'jboss.infinispan.hibernate.entity.config'
2016-01-07 11:12:47,306 TRACE [org.jboss.as.jpa] (MSC service thread 1-1) add second level cache dependency on service 'jboss.infinispan.hibernate.immutable-entity.config'
2016-01-07 11:12:47,306 TRACE [org.jboss.as.jpa] (MSC service thread 1-1) add second level cache dependency on service 'jboss.infinispan.hibernate.entity.config'
2016-01-07 11:12:47,306 TRACE [org.jboss.as.jpa] (MSC service thread 1-1) add second level cache dependency on service 'jboss.infinispan.hibernate.entity.config'
2016-01-07 11:12:47,307 TRACE [org.jboss.as.jpa] (MSC service thread 1-1) add second level cache dependency on service 'jboss.infinispan.hibernate.pending-puts.config'
2016-01-07 11:12:47,307 TRACE [org.jboss.as.jpa] (MSC service thread 1-1) add second level cache dependency on service 'jboss.infinispan.hibernate.timestamps.config'
2016-01-07 11:12:47,307 TRACE [org.jboss.as.jpa] (MSC service thread 1-1) add second level cache dependency on service 'jboss.infinispan.hibernate.local-query.config'
2016-01-07 11:12:47,307 TRACE [org.jboss.as.jpa] (MSC service thread 1-1) added PersistenceUnitService (phase 2 of 2) for 'service jboss.persistenceunit."jboss-as-hibernate4Test.war#secondary"'. PU is
{quote}
> pending-puts cache configuration is not started by the JPA subsystem
> --------------------------------------------------------------------
>
> Key: WFLY-5951
> URL: https://issues.jboss.org/browse/WFLY-5951
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Reporter: Paul Ferraro
> Assignee: Scott Marlow
> Fix For: 10.0.0.Final
>
>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFLY-5951) pending-puts cache configuration is not started by the JPA subsystem
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-5951?page=com.atlassian.jira.plugin.... ]
Scott Marlow commented on WFLY-5951:
------------------------------------
sample TRACE output:
{quote}
2016-01-07 11:12:47,305 TRACE [org.jboss.as.jpa] (MSC service thread 1-1) add second level cache dependencies with properties '{timestamps=timestamps, pending-puts=pending-puts, natural-id=entity, container=hibernate, entity=entity, query=local-query, immutable-entity=immutable-entity, collection=entity}'
2016-01-07 11:12:47,306 TRACE [org.jboss.as.jpa] (MSC service thread 1-1) add second level cache dependency on service 'jboss.infinispan.hibernate.entity.config'
2016-01-07 11:12:47,306 TRACE [org.jboss.as.jpa] (MSC service thread 1-1) add second level cache dependency on service 'jboss.infinispan.hibernate.immutable-entity.config'
2016-01-07 11:12:47,306 TRACE [org.jboss.as.jpa] (MSC service thread 1-1) add second level cache dependency on service 'jboss.infinispan.hibernate.entity.config'
2016-01-07 11:12:47,306 TRACE [org.jboss.as.jpa] (MSC service thread 1-1) add second level cache dependency on service 'jboss.infinispan.hibernate.entity.config'
2016-01-07 11:12:47,307 TRACE [org.jboss.as.jpa] (MSC service thread 1-1) add second level cache dependency on service 'jboss.infinispan.hibernate.pending-puts.config'
2016-01-07 11:12:47,307 TRACE [org.jboss.as.jpa] (MSC service thread 1-1) add second level cache dependency on service 'jboss.infinispan.hibernate.timestamps.config'
2016-01-07 11:12:47,307 TRACE [org.jboss.as.jpa] (MSC service thread 1-1) add second level cache dependency on service 'jboss.infinispan.hibernate.local-query.config'
2016-01-07 11:12:47,307 TRACE [org.jboss.as.jpa] (MSC service thread 1-1) added PersistenceUnitService (phase 2 of 2) for 'service jboss.persistenceunit."jboss-as-hibernate4Test.war#secondary"'. PU is
{quote}
> pending-puts cache configuration is not started by the JPA subsystem
> --------------------------------------------------------------------
>
> Key: WFLY-5951
> URL: https://issues.jboss.org/browse/WFLY-5951
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Reporter: Paul Ferraro
> Assignee: Scott Marlow
> Fix For: 10.0.0.Final
>
>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months