May 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-3860) Improve dependency handling in clustering/infinispan subsystem tests

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-3860?page=com.atlassian.jira.plugin.... ] Jason Greene updated WFLY-3860: ------------------------------- Fix Version/s: 10.0.0.Alpha3 (was: 10.0.0.Alpha2) > Improve dependency handling in clustering/infinispan subsystem tests > -------------------------------------------------------------------- > > Key: WFLY-3860 > URL: https://issues.jboss.org/browse/WFLY-3860 > Project: WildFly > Issue Type: Task > Components: Clustering > Affects Versions: 9.0.0.Alpha1 > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 10.0.0.Alpha3 > > > The subsystem tests in clustering/infinispan are not configured to use a controller operating in --admin-only mode, but they are also not doing all the needed setup to have needed services and resources (core, jmx, jgroups) available for when the services they add are started. > This is fragile, because all sorts of stuff is failing when things are getting launched, but the tests are not noticing that. That's ok right now, but it could lead to missing regressions. > Also, the changes I'm making for WFCORE-102 mean these problems will no longer go unnoticed and the tests will fail. > I plan to: > 1) Shifts tests to using --admin-only in cases where the tests are clearly not testing anything related to runtime execution; i.e. they are just testing model. > 2) For OperationSequencesTestCase and OperationsTestCase, where there is some validation of runtime behavior going on (explicit in some places; in others perhaps expected, perhaps not) I'm going to switch the tests to a more focused config file that: > a) Only uses local caches, to avoid pulling in requirements for jgroups things that are not present. (I see no indication any of the tests are testing anything not present with local caches.) > b) Uses start="LAZY". This means services will get registered, but not started. Not starting avoids detection of various missing dependencies, including a ModuleLoader dependency that I can't figure out how to satisfy. > The tests can't be trying to validate any behavior when services start, because they've never been able to start. So LAZY is fine. Some tests do seem to be looking for problem related to service conflicts as resources are added/removed. These tests are still valid, because service conflicts happen as soon as services are installed, whether or not the services need to start. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3853) Cache PersistenceProviders within the same deployment

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-3853?page=com.atlassian.jira.plugin.... ] Jason Greene updated WFLY-3853: ------------------------------- Fix Version/s: 10.0.0.Alpha3 (was: 10.0.0.Alpha2) > Cache PersistenceProviders within the same deployment > ----------------------------------------------------- > > Key: WFLY-3853 > URL: https://issues.jboss.org/browse/WFLY-3853 > Project: WildFly > Issue Type: Feature Request > Components: JPA / Hibernate > Reporter: Scott Marlow > Assignee: Scott Marlow > Fix For: 10.0.0.Alpha3 > > > See wildfly-dev ml discussion [http://lists.jboss.org/pipermail/wildfly-dev/2014-September/002984.html] about calls to PersistenceProviderResolver.getPersistenceProviders() should return a cached list. The cache should be per deployment. > We can probably reuse our PersistenceProviderResolverImpl.persistenceProviderPerClassLoader map, just need to be careful that addDeploymentSpecificPersistenceProvider() is called early before any calls to getPersistenceProviders(). -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3681) General Schema Sync with EAP

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-3681?page=com.atlassian.jira.plugin.... ] Jason Greene updated WFLY-3681: ------------------------------- Fix Version/s: 10.0.0.Alpha3 (was: 10.0.0.Alpha2) > General Schema Sync with EAP > ---------------------------- > > Key: WFLY-3681 > URL: https://issues.jboss.org/browse/WFLY-3681 > Project: WildFly > Issue Type: Sub-task > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 10.0.0.Alpha3 > > > This may actually be more about pushing some changes to EAP, new schemas are being tracked by individual issues but for the remaining schemas where cosmetic changes have been made or corrections to default values and min/max occurs we need to sync with EAP. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4304) Servlet authentication kicked off when *not* a part of any security-constraint

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-4304?page=com.atlassian.jira.plugin.... ] Jason Greene updated WFLY-4304: ------------------------------- Fix Version/s: 10.0.0.Alpha3 (was: 10.0.0.Alpha2) > Servlet authentication kicked off when *not* a part of any security-constraint > ------------------------------------------------------------------------------ > > Key: WFLY-4304 > URL: https://issues.jboss.org/browse/WFLY-4304 > Project: WildFly > Issue Type: Bug > Affects Versions: 8.2.0.Final > Reporter: Brett Meyer > Assignee: Darran Lofthouse > Fix For: 10.0.0.Alpha3 > > > Artificer runs on Wildfly 8.2 and uses Keycloak for auth. If our WAR contains a servlet that is *not* protected by a security-constraint in web.xml, Wildfly still attempts to authenticate the call (using Wireshark, I see the GET/POST get funneled through the Keycloak realm redirection) if basic auth credentials are in the header. In a keycloak-dev thread this past Dec., [~bill.burke] suggested this was most likely an issue within Wildfly auth itself. > A credentialed call on an un-protected servlet does sound like an edge case. However, this came up possibly due to a secondary symptom: > If I protect the servlet in web.xml, the call's Authorization header is stripped. I'm not currently able to figure out exactly where that's occurring... -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4229) Make http status return while deploying configurable

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-4229?page=com.atlassian.jira.plugin.... ] Jason Greene updated WFLY-4229: ------------------------------- Fix Version/s: 10.0.0.Alpha3 (was: 10.0.0.Alpha2) > Make http status return while deploying configurable > ---------------------------------------------------- > > Key: WFLY-4229 > URL: https://issues.jboss.org/browse/WFLY-4229 > Project: WildFly > Issue Type: Feature Request > Components: Web (Undertow) > Affects Versions: 8.2.0.Final > Reporter: Tomaz Cerar > Assignee: Bartosz Baranowski > Fix For: 9.0.0.CR2, 10.0.0.Alpha3 > > > For deployment behind proxies it would be more than welcome to have server return 503 instead of 404 while application is deploying. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4429) Refactor JCA subsystems

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-4429?page=com.atlassian.jira.plugin.... ] Jason Greene updated WFLY-4429: ------------------------------- Fix Version/s: 10.0.0.Alpha3 (was: 10.0.0.Alpha2) > Refactor JCA subsystems > ----------------------- > > Key: WFLY-4429 > URL: https://issues.jboss.org/browse/WFLY-4429 > Project: WildFly > Issue Type: Task > Components: JCA > Reporter: Jesper Pedersen > Assignee: Stefano Maestri > Priority: Critical > Fix For: 10.0.0.Alpha3 > > > Make use of PASSIVE services, and PersistentResource in :jca:, :datasources: and :resource-adapters: -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4408) WFLY-2160 fix did not include transformation

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-4408?page=com.atlassian.jira.plugin.... ] Jason Greene updated WFLY-4408: ------------------------------- Fix Version/s: 10.0.0.Alpha3 (was: 10.0.0.Alpha2) > WFLY-2160 fix did not include transformation > -------------------------------------------- > > Key: WFLY-4408 > URL: https://issues.jboss.org/browse/WFLY-4408 > Project: WildFly > Issue Type: Bug > Components: JCA > Reporter: Brian Stansberry > Assignee: Stefano Maestri > Fix For: 10.0.0.Alpha3 > > > The WFLY-2160 patch (https://github.com/wildfly/wildfly/pull/6976/files) made the "enabled" attribute support expressions but did not add transformers to reject that setting if a legacy host controller is using the profile. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4379) Always expose <transaction-support> for resource adapters

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-4379?page=com.atlassian.jira.plugin.... ] Jason Greene updated WFLY-4379: ------------------------------- Fix Version/s: 10.0.0.Alpha3 (was: 10.0.0.Alpha2) > Always expose <transaction-support> for resource adapters > --------------------------------------------------------- > > Key: WFLY-4379 > URL: https://issues.jboss.org/browse/WFLY-4379 > Project: WildFly > Issue Type: Task > Components: JCA > Reporter: Jesper Pedersen > Assignee: Stefano Maestri > Priority: Critical > Fix For: 10.0.0.Alpha3 > > > The <transaction-support> setting for resource adapters should always be exposed in the DMR model - e.g. no "undefined". > If the value isn't explicit defined by the deployment, then it will be obtained from the metadata repository of the archive in question. > This also makes it clear that <xa-pool> is used for XATransaction deployments. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4378) Infinispan/JGroups subsystem check for and correct diffs in the default config we ship vs. what we persist

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-4378?page=com.atlassian.jira.plugin.... ] Jason Greene updated WFLY-4378: ------------------------------- Fix Version/s: 10.0.0.Alpha3 (was: 10.0.0.Alpha2) > Infinispan/JGroups subsystem check for and correct diffs in the default config we ship vs. what we persist > ----------------------------------------------------------------------------------------------------------- > > Key: WFLY-4378 > URL: https://issues.jboss.org/browse/WFLY-4378 > Project: WildFly > Issue Type: Task > Components: Clustering > Affects Versions: 9.0.0.Alpha1 > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Fix For: 10.0.0.Alpha3 > > > https://github.com/wildfly/wildfly/pull/7184#issuecomment-75439059 > Brian: > {quote}Semi-tangent: could you guys check for and correct diffs in the default config we ship vs. what we persist? E.g. > 1) Start a new server running standalone-full-ha.xml > 2) Use cli to add a system prop (just to force persistence) > 3) Diff standalone-full-ha.xml vs standalone/configuration/standalone_xml_history/standalone-full-ha.initial.xml > There shouldn't be changes other than the added system prop. Any changes mean either our default configs are wrong or the marshalling is wrong. Both should match xsd. I did this for another reason a couple weeks ago and saw some changes in the clustering subsystems. Perhaps this PR fixes the problem, but I have a feeling I saw something else besides this.{quote} -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4340) use-try-lock exposed for <connection-definition>

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-4340?page=com.atlassian.jira.plugin.... ] Jason Greene updated WFLY-4340: ------------------------------- Fix Version/s: 10.0.0.Alpha3 (was: 10.0.0.Alpha2) > use-try-lock exposed for <connection-definition> > ------------------------------------------------ > > Key: WFLY-4340 > URL: https://issues.jboss.org/browse/WFLY-4340 > Project: WildFly > Issue Type: Bug > Components: JCA > Affects Versions: 8.2.0.Final > Reporter: Jesper Pedersen > Assignee: Stefano Maestri > Fix For: 10.0.0.Alpha3 > > > <connection-definition> DMR: > {noformat} > use-try-lock undefined LONG > {noformat} > which should be removed -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 11 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira May 2015