[JBoss JIRA] (WFLY-8653) Server reload missing in tearDown method of EjbElytronDomainSetup
by Michal Jurc (JIRA)
[ https://issues.jboss.org/browse/WFLY-8653?page=com.atlassian.jira.plugin.... ]
Michal Jurc updated WFLY-8653:
------------------------------
Git Pull Request: https://github.com/wildfly-security-incubator/wildfly/pull/196 (was: https://github.com/wildfly/wildfly/pull/9975)
> Server reload missing in tearDown method of EjbElytronDomainSetup
> -----------------------------------------------------------------
>
> Key: WFLY-8653
> URL: https://issues.jboss.org/browse/WFLY-8653
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Reporter: Michal Jurc
> Assignee: Michal Jurc
>
> Clean up method in {{EjbElytronDomainSetup}} server setup class currently calls management operations on server that require a reload, but the method implicitly states not to reload the server, leaving the server in improperly cleaned up state after test case run, causing multiple tests that use incorrectly cleaned up services to fail with error:
> {code:java|title=EjbElytronDomainSetup.java}@Override
> public void tearDown(final ManagementClient managementClient, final String containerId) {
> System.out.println("tearing down...");
> List<ModelNode> updates = new LinkedList<>();
> updates.add(createRemoveIgnoring(undertowDomainAddress));
> updates.add(createRemoveIgnoring(httpAuthenticationAddress));
> updates.add(Util.getWriteAttributeOperation(ejbRemoteAddress, "connector-ref", "http-remoting-connector"));
> updates.add(createRemoveIgnoring(ejbDomainAddress));
> updates.add(createRemoveIgnoring(remotingConnectorAddress));
> updates.add(createRemoveIgnoring(saslAuthenticationAddress));
> updates.add(createRemoveIgnoring(domainAddress));
> updates.add(createRemoveIgnoring(realmAddress));
> try {
> applyUpdates(managementClient.getControllerClient(), updates, true);
> } catch (Exception e) {
> throw new RuntimeException(e);
> }
> }
> private static ModelNode createRemoveIgnoring(PathAddress address) {
> ModelNode remove = Util.createRemoveOperation(address);
> // Don't rollback when the AS detects the war needs the module
> remove.get(OPERATION_HEADERS, ROLLBACK_ON_RUNTIME_FAILURE).set(false);
> remove.get(OPERATION_HEADERS, ALLOW_RESOURCE_SERVICE_RESTART).set(false);
> return remove;
> }
> protected static void applyUpdates(final ModelControllerClient client, final List<ModelNode> updates, boolean allowFailure) {
> for (ModelNode update : updates) {
> try {
> applyUpdate(client, update, allowFailure);
> } catch (Exception e) {
> throw new RuntimeException(e);
> }
> }
> }{code}
> {code:title=mvn clean test -Dtest=org.jboss.as.test.integration.ejb.security.**.* -Delytron -Dwildfly.tmp.enable.elytron.profile.tests}Running org.jboss.as.test.integration.ejb.security.EJBInWarDefaultSecurityDomainTestCase
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.274 sec - in org.jboss.as.test.integration.ejb.security.EJBInWarDefaultSecurityDomainTestCase
> Running org.jboss.as.test.integration.ejb.security.EJBSecurityTestCase
> Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.374 sec - in org.jboss.as.test.integration.ejb.security.EJBSecurityTestCase
> Running org.jboss.as.test.integration.ejb.security.InherritanceAnnSFSBTestCase
> Tests run: 3, Failures: 0, Errors: 3, Skipped: 0, Time elapsed: 0.396 sec <<< FAILURE! - in org.jboss.as.test.integration.ejb.security.InherritanceAnnSFSBTestCase
> testSingleMethodAnnotationsUser1(org.jboss.as.test.integration.ejb.security.InherritanceAnnSFSBTestCase) Time elapsed: 0.166 sec <<< ERROR!
> javax.naming.CommunicationException: EJBCLIENT000062: Failed to look up "/inherritanceAnnOnlySFSB//InherritanceAnnOnlyCheckSFSB!org.jboss.as.test.integration.ejb.security.authorization.SimpleAuthorizationRemote?stateful" [Root exception is java.lang.IllegalStateException: EJBCLIENT000024: Not able to find EJB matching "StatelessEJBLocator for "/inherritanceAnnOnlySFSB/InherritanceAnnOnlyCheckSFSB", view is interface org.jboss.as.test.integration.ejb.security.authorization.SimpleAuthorizationRemote, affinity is None"]
> at org.jboss.ejb.client.EJBRootContext.lookupNative(EJBRootContext.java:144)
> at org.wildfly.naming.client.AbstractContext.lookup(AbstractContext.java:88)
> at org.wildfly.naming.client.WildFlyRootContext.lookup(WildFlyRootContext.java:149)
> at javax.naming.InitialContext.lookup(InitialContext.java:417)
> at org.jboss.as.test.integration.ejb.security.AnnSBTest.getBean(AnnSBTest.java:94)
> at org.jboss.as.test.integration.ejb.security.AnnSBTest.lambda$testSingleMethodAnnotationsUser1Template$1(AnnSBTest.java:165)
> at org.wildfly.common.context.Contextual.runCallable(Contextual.java:127)
> at org.jboss.as.test.integration.ejb.security.AnnSBTest.testSingleMethodAnnotationsUser1Template(AnnSBTest.java:163)
> at org.jboss.as.test.integration.ejb.security.InherritanceAnnSFSBTestCase.testSingleMethodAnnotationsUser1(InherritanceAnnSFSBTestCase.java:71)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at org.jboss.arquillian.junit.Arquillian$8$1.invoke(Arquillian.java:374)
> at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
> at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> at org.jboss.arquillian.container.test.impl.execution.ClientTestExecuter.execute(ClientTestExecuter.java:53)
> at sun.reflect.GeneratedMethodAccessor14.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142)
> at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createTestContext(ContainerEventController.java:129)
> at sun.reflect.GeneratedMethodAccessor13.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130)
> at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92)
> at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73)
> at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:136)
> at org.jboss.arquillian.junit.Arquillian$8.evaluate(Arquillian.java:367)
> at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:245)
> at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:426)
> at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54)
> at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:259)
> at org.jboss.arquillian.junit.Arquillian$7$1.invoke(Arquillian.java:319)
> at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.execute(ClientBeforeAfterLifecycleEventExecuter.java:99)
> at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.on(ClientBeforeAfterLifecycleEventExecuter.java:72)
> at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142)
> at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createBeforeContext(ContainerEventController.java:124)
> at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130)
> at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92)
> at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73)
> at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
> at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.fireCustomLifecycle(EventTestRunnerAdaptor.java:159)
> at org.jboss.arquillian.junit.Arquillian$7.evaluate(Arquillian.java:312)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:204)
> at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:426)
> at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54)
> at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:218)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:166)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:27)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:108)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:78)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:54)
> at org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:144)
> at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> Caused by: java.lang.IllegalStateException: EJBCLIENT000024: Not able to find EJB matching "StatelessEJBLocator for "/inherritanceAnnOnlySFSB/InherritanceAnnOnlyCheckSFSB", view is interface org.jboss.as.test.integration.ejb.security.authorization.SimpleAuthorizationRemote, affinity is None"
> at org.jboss.ejb.client.EJBClientContext.discoverAffinityNone(EJBClientContext.java:719)
> at org.jboss.ejb.client.EJBClientContext.performLocatedAction(EJBClientContext.java:701)
> at org.jboss.ejb.client.EJBClientContext.createSession(EJBClientContext.java:681)
> at org.jboss.ejb.client.EJBClient.createSession(EJBClient.java:288)
> at org.jboss.ejb.client.EJBRootContext.lookupNative(EJBRootContext.java:142)
> ... 135 more
> Suppressed: org.xnio.http.UpgradeFailedException: Invalid response code 200
> at org.xnio.http.HttpUpgrade$HttpUpgradeState$UpgradeResultListener.handleEvent(HttpUpgrade.java:471)
> at org.xnio.http.HttpUpgrade$HttpUpgradeState$UpgradeResultListener.handleEvent(HttpUpgrade.java:400)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:567)
> at ...asynchronous invocation...(Unknown Source)
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:537)
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:503)
> at org.jboss.remoting3.ConnectionInfo$None.getConnection(ConnectionInfo.java:84)
> at org.jboss.remoting3.ConnectionInfo.getConnection(ConnectionInfo.java:57)
> at org.jboss.remoting3.EndpointImpl.doGetConnection(EndpointImpl.java:458)
> at org.jboss.remoting3.EndpointImpl.getConnectedIdentity(EndpointImpl.java:403)
> at org.jboss.remoting3.UncloseableEndpoint.getConnectedIdentity(UncloseableEndpoint.java:55)
> at org.jboss.remoting3.Endpoint.getConnectedIdentity(Endpoint.java:126)
> at org.jboss.remoting3.Endpoint.getConnectedIdentity(Endpoint.java:139)
> at org.jboss.remoting3.Endpoint.getConnection(Endpoint.java:216)
> at org.jboss.ejb.protocol.remote.RemotingEJBDiscoveryProvider.lambda$discover$0(RemotingEJBDiscoveryProvider.java:103)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.jboss.ejb.protocol.remote.RemotingEJBDiscoveryProvider.discover(RemotingEJBDiscoveryProvider.java:103)
> at org.wildfly.discovery.impl.AggregateDiscoveryProvider.discover(AggregateDiscoveryProvider.java:58)
> at org.wildfly.discovery.ConfiguredProvider.discover(ConfiguredProvider.java:45)
> at org.wildfly.discovery.Discovery.discover(Discovery.java:94)
> at org.jboss.ejb.client.EJBClientContext.discover(EJBClientContext.java:442)
> at org.jboss.ejb.client.EJBClientContext.discoverAffinityNone(EJBClientContext.java:714)
> ... 139 more
> {code}
> If no test with {{EjbElytronDomainSetup}} is ran before these failing tests, they will be successful.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFLY-8654) Improve mod_cluster stop/stop-context(waittime=..) attribute description
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-8654?page=com.atlassian.jira.plugin.... ]
Radoslav Husar moved JBEAP-10584 to WFLY-8654:
----------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-8654 (was: JBEAP-10584)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: mod_cluster
(was: mod_cluster)
Affects Version/s: 11.0.0.Alpha1
(was: 7.1.0.DR16)
> Improve mod_cluster stop/stop-context(waittime=..) attribute description
> ------------------------------------------------------------------------
>
> Key: WFLY-8654
> URL: https://issues.jboss.org/browse/WFLY-8654
> Project: WildFly
> Issue Type: Bug
> Components: mod_cluster
> Affects Versions: 11.0.0.Alpha1
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Priority: Minor
>
> Cli operation description
> {noformat}
> [standalone@localhost:9990 /] /subsystem=modcluster/:read-operation-description(name=stop
> {
> "outcome" => "success",
> "result" => {
> "operation-name" => "stop",
> "description" => "Tell reverse proxies that all contexts on the node can't process requests.",
> "request-properties" => {"waittime" => {
> "type" => INT,
> "description" => "Timeout to wait for all contexts to stop.",
> "expressions-allowed" => false,
> "required" => false,
> "nillable" => true,
> "default" => 10,
> "unit" => "SECONDS"
> }},
> "reply-properties" => {},
> "read-only" => false,
> "runtime-only" => true
> }
> }
> {noformat}
> Documentation
> {noformat}
> Stopping a context with waittime set to 0, meaning no timeout, instructs the balancer to stop routing any request to it immediately, which forces failover to another available context.
> If you set a timeout value using the waittime argument, no new sessions are created on this context, but existing sessions will continue to be directed to this node until they complete or the specified timeout has elapsed. The waittime argument defaults to 10 seconds.
> {noformat}
> There is difference, documentation basically says that till timeout is hit, node is disabled, cli description isn't that specific. Could you elaborate this?
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (LOGMGR-124) Add marker support
by Stephane Gallès (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-124?page=com.atlassian.jira.plugin... ]
Stephane Gallès commented on LOGMGR-124:
----------------------------------------
A filter does not allow to filter *before* the log operation.
In particular with Markers we have {{Logger#isDebugEnabled(Marker marker)}} or {{Logger#isTraceEnabled(Marker marker)}}
> Add marker support
> ------------------
>
> Key: LOGMGR-124
> URL: https://issues.jboss.org/browse/LOGMGR-124
> Project: JBoss Log Manager
> Issue Type: Feature Request
> Components: core
> Affects Versions: 2.0.2.Final
> Reporter: Rob Heine
> Priority: Optional
>
> The logging engine currently (talking about the one included in WF-9) does not support Markers (like in implementations like "logback" and/or "log4j2").
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFLY-4383) Wrong order of elements in appclient.xml
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-4383?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-4383:
-----------------------------------------------
Michael Cada <mcada(a)redhat.com> changed the Status of [bug 1195138|https://bugzilla.redhat.com/show_bug.cgi?id=1195138] from ON_QA to VERIFIED
> Wrong order of elements in appclient.xml
> ------------------------------------------
>
> Key: WFLY-4383
> URL: https://issues.jboss.org/browse/WFLY-4383
> Project: WildFly
> Issue Type: Bug
> Components: Application Client
> Affects Versions: 9.0.0.Alpha1
> Reporter: Panagiotis Sotiropoulos
> Assignee: Panagiotis Sotiropoulos
> Fix For: 9.0.0.Beta1
>
>
> Description of problem:
> File appclient/configuration/appclient.xml has an incorrect order of elements. <core-environment> tag should be before <recovery-environment /> tag. These tags is in <subsystem xmlns="urn:jboss:domain:transactions:1.4"> and schema is in docs/schema/jboss-as-txn_1_4.xsd. This schema defines specific order of elements.
> Version-Release number of selected component (if applicable):
> 6.4.0.ER2
> Validate logs:
> appclient/configuration/appclient.xml:150: element recovery-environment: Schemas validity error : Element '{urn:jboss:domain:transactions:1.4}recovery-environment': This element is not expected. Expected is ( {urn:jboss:domain:transactions:1.4}core-environment ).
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (ELY-1103) Special handling for JBOSS-LOCAL-USER server side authentication
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-1103?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse commented on ELY-1103:
---------------------------------------
Code could have moved on within the last week but the initial reason for running into this issue was: -
In prior releases the mechanism was configured to be quiet on the client side and it would remain quiet, it would not use the supplied CallbackHandler to request an authentication ID so it would not send one, this allowed server side to then fallback and use the default name it is configured with which is '$local'.
In the later Elytron AuthenticationClient code the configuration to make the mechanism quiet is only set if we have no username defined in the configuration and no callback handler is available to request one, the slave process always provides a CBH as we don't know which authentication mechanisms will be offered by the server.
There are still some other areas of local authentication to work through but in the slave host controller process we could actually look into removing the callback handler entirely - i.e. the authentication context and authentication configuration APIs are a set of APIs that allow names and passwords to be specified. (We would need to check the correct precedence) but in theory if the slave HC has a password defined it could obtain the current ACtx and resolve the ACfg and apply the username and password and at the same time disable local auth. If a password is not set then take no action and send no CBH - then you will get quiet local authentication.
Generally the CBH is better suited to environments where we want user interaction e.g. the CLI - but in processes like this that know everything they already know we could move from the CBH and use the ACtx and ACfg directly.
> Special handling for JBOSS-LOCAL-USER server side authentication
> ----------------------------------------------------------------
>
> Key: ELY-1103
> URL: https://issues.jboss.org/browse/ELY-1103
> Project: WildFly Elytron
> Issue Type: Enhancement
> Components: Authentication Server, SASL
> Reporter: David Lloyd
> Fix For: 1.1.0.Beta39
>
>
> If an authentication attempt comes in using the JBOSS-LOCAL-USER mechanism with an authentication name that does not correspond to a real identity, authentication fails. In previous releases, we allowed such authentications to proceed, mapping them to a "special" identity.
> With the Elytron-based authentication client and server, this occurs when a specific authentication principal is explicitly set, and that authentication principal does not correspond to a real identity on the server side. Another way to trigger this problem is to have a custom callback handler which handles NameCallback and explicitly specifies a non-existent name. Note that callback handlers which accept the suggested default name will not have this problem, nor will callback handlers which are explicitly aware of the special {{OptionalNameCallback}}. Configurations which do not specify a user name will not have this problem.
> While logically it is an error condition to specify a user name that does not exist, historically we have allowed such authentications to proceed because of the privileged nature of local invocations. If we decide to continue doing so, we will need to introduce a special hook into the ServerAuthenticationContext's callback handler to detect when the local user mechanism is being used, and attempt to look up the user, and if the user is not found, fall back to the special "$local" user name. Another alternative is to produce an ad-hoc identity, however this would differ in behavior in a few key ways compared to using a fallback identity.
> If we decide to reject this enhancement, then the corresponding application server tests must be updated to specify a real user name or to accept the default name that is suggested.
> Note that if an authorization ID is set in the authentication request, it should be respected and the run-as authorization check should happen as per normal.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (ELY-1104) CS tool, provide way to create empty credential store
by Yeray Borges (JIRA)
[ https://issues.jboss.org/browse/ELY-1104?page=com.atlassian.jira.plugin.s... ]
Yeray Borges moved WFCORE-2480 to ELY-1104:
-------------------------------------------
Project: WildFly Elytron (was: WildFly Core)
Key: ELY-1104 (was: WFCORE-2480)
Component/s: Credential Store
(was: Security)
> CS tool, provide way to create empty credential store
> -----------------------------------------------------
>
> Key: ELY-1104
> URL: https://issues.jboss.org/browse/ELY-1104
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Credential Store
> Reporter: Martin Choma
> Assignee: Yeray Borges
> Labels: credential-store, wildfly-elytron-tool
>
> There is no way to create empty credential store. Curently credential store can be created only with adding alias as well.
> {code}
> java -jar wildfly-elytron-tool.jar credential-store --add myalias --secret supersecretpassword --location="test.store" --uri "cr-store://test?modifiable=true;create=true;keyStoreType=JCEKS" --password mycspassword --salt 12345678 --iteration 230 --summary
> {code}
> I would expect something like
> {code}
> java -jar wildfly-elytron-tool.jar credential-store --create --location="test.store" --uri "cr-store://test?modifiable=true;create=true;keyStoreType=JCEKS" --password mycspassword
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFCORE-2620) Add ability to read computed runtime values of IO subsystem buffer-pool attributes
by Romain Pelisse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2620?page=com.atlassian.jira.plugi... ]
Romain Pelisse commented on WFCORE-2620:
----------------------------------------
[~ctomc] following your comment (and Brian's) on my [PR|https://github.com/wildfly/wildfly-core/pull/2330] for [WFCORE-2620|https://issues.jboss.org/browse/WFCORE-2620], I've looked at you achieved a proper runtime computed value of the workers. AFAIU, you simply used the [MBean|https://github.com/wildfly/wildfly-core/blob/master/io/subsystem/sr...], provided by Xnio(1) to get the proper value. However, there is no value related to buffer in this MBean.
There is an other MBean, java.nio, providing info in the BufferPool(2), however the attributes available there (TotalCapacity and Count) does not provides us with the metrics we need here (buffer-size and buffers-per-slice). AFAIU, the metrics associated to those are computer in the [BufferPoolResourceDefinition class|https://github.com/wildfly/wildfly-core/blob/master/io/subsystem/sr...], and maybe override using the subsystem configuration in [the standalone.xm|https://github.com/wildfly/wildfly-core/blob/master/io/subs...].
My naive approach here - that I want to double check with you, is : Should I create a MBean for the buffer attribute - to mimic the approach of the worker ? If so I assume we'll move the [buffers "default computation"|https://github.com/wildfly/wildfly-core/blob/master/io/subsystem/src/main/java/org/wildfly/extension/io/BufferPoolResourceDefinition.java#L62] into the MBean (right?). Or am I misunderstanding or missing something here ?
Let me know what you think about this (and if my analysis is correct)
MX object names:
* (1) ObjectName: org.xnio:tyep=Xnio.provider="nio,work"="default"
* (2) ObjectName: java.nio:type=BufferPool,name=direct]
> Add ability to read computed runtime values of IO subsystem buffer-pool attributes
> ----------------------------------------------------------------------------------
>
> Key: WFCORE-2620
> URL: https://issues.jboss.org/browse/WFCORE-2620
> Project: WildFly Core
> Issue Type: Enhancement
> Affects Versions: 3.0.0.Beta13
> Reporter: Romain Pelisse
> Assignee: Romain Pelisse
> Original Estimate: 2 days
> Remaining Estimate: 2 days
>
> In IO subsystem there are some attributes which are calculated based on available system resources if not explicitly specified. These attributes are:
> * worker
> ** io-threads
> ** task-max-threads
> * buffer-pool
> ** buffer-size
> ** buffers-per-slice
> ** direct-buffers
> Currently these computed values are not visible for user in the subsystem configuration even with include-runtime=true.
> To show these runtime values would definitely improve UX.
> Worker attributes are covered by EAP7-616 .
> This issue is about buffer-pool attributes.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years