October 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-347) Rework all realm implementations that use credential names

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-347?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse reassigned ELY-347: ------------------------------------ Assignee: Darran Lofthouse > Rework all realm implementations that use credential names > ---------------------------------------------------------- > > Key: ELY-347 > URL: https://issues.jboss.org/browse/ELY-347 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Realms > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.1.0.Beta2 > > > A number of the realm implementations are making use of credential names - for the ones that are not automatic we need to ensure they are configurable instead as within Elytron we no longer need a set of standard names. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ELY-344) Review how clients use ModifiableRealmIdentity / ModifiableRealm

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-344?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-344: --------------------------------- Fix Version/s: 1.1.0.Beta3 (was: 1.1.0.Beta2) > Review how clients use ModifiableRealmIdentity / ModifiableRealm > ---------------------------------------------------------------- > > Key: ELY-344 > URL: https://issues.jboss.org/browse/ELY-344 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Realms > Reporter: Darran Lofthouse > Fix For: 1.1.0.Beta3 > > > This may be something we address in the subsystem but just raising here so we don't forget. > Once we have a working set up with a realm which can be modified it seems unreasonable to expect the administrator to know exactly which credential types and names to use. > This may need to be a few milestones away once we have the bulk integrated so the relationships are clear. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-30) Support automatic log file compression in FileHandler (for compressing all files in real time) and PeriodicRotatingFileHandler (for compressing upon rotation)

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-30?page=com.atlassian.jira.plugin.... ] James Perkins reassigned LOGMGR-30: ----------------------------------- Assignee: James Perkins > Support automatic log file compression in FileHandler (for compressing all files in real time) and PeriodicRotatingFileHandler (for compressing upon rotation) > -------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: LOGMGR-30 > URL: https://issues.jboss.org/browse/LOGMGR-30 > Project: JBoss Log Manager > Issue Type: Feature Request > Reporter: Aleksander Adamowski > Assignee: James Perkins > Fix For: 2.1.0.Beta1 > > > This is a follow up to JBAS-6917. > It would be nice to have an automatic compression of log files similar to the one implemented in Log4j extras: > http://logging.apache.org/log4j/companions/extras/apidocs/org/apache/log4... > "TimeBasedRollingPolicy supports automatic file compression. This feature is enabled if the value of the FileNamePattern option ends with .gz or .zip." > In JBoss Logging, I suppose this could be implemented on 2 levels: > 1) In the FileHandler (http://anonsvn.jboss.org/repos/common/jboss-logmanager/trunk/src/main/jav...) so that, with proper configuration, each log file is compressed in real time, and it exists only in compressed form from the moment of its creation. > 2) In the PeriodicRotatingFileHandler (http://anonsvn.jboss.org/repos/common/jboss-logmanager/trunk/src/main/jav...) so that with proper configuration, archival log files can be compressed the moment they are rotated (e.g. server.log.2010-05-06.gz is created instead of server.log.2010-05-06), but the current log file should be plain text. > In PeriodicRotatingFileHandler, the implementation must take into account that compression of rotated log files may take considerable time and should be performed in the background - the handler should be able to process log records at any time, particularly during rotation, without losing any. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ELY-353) Add NameRewriters to map from mechanism credential name to the name presented to the realm

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-353: ------------------------------------ Summary: Add NameRewriters to map from mechanism credential name to the name presented to the realm Key: ELY-353 URL: https://issues.jboss.org/browse/ELY-353 Project: WildFly Elytron Issue Type: Enhancement Components: API / SPI Reporter: Darran Lofthouse Fix For: 1.1.0.Beta3 Names may not be consistent across realm implementations so a level of mapping may be required. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ELY-352) Release WildFly Elytron 1.1.0.Beta1

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-352?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse resolved ELY-352. ---------------------------------- Resolution: Done > Release WildFly Elytron 1.1.0.Beta1 > ----------------------------------- > > Key: ELY-352 > URL: https://issues.jboss.org/browse/ELY-352 > Project: WildFly Elytron > Issue Type: Release > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.1.0.Beta1 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5601) Failure to add a datasource with a name that was previously used

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFLY-5601?page=com.atlassian.jira.plugin.... ] James Perkins closed WFLY-5601. ------------------------------- Resolution: Rejected Using the {{reload}} operation executes and returns immediately. This could result in the {{add}} operation executing before the reload is complete. That would result in some odd behavior in this case indicating a duplicate capability reference. Just for completeness of the description. Here's what Brian said about the {{reload}} operation. {quote} you also get a response to the reload op earlier than you might intuitively expect basically it has to tell you it succeeded before it starts shutting down all the services otherwise you likely won't ever get a response because the service to send you a response has stopped {quote} With CLI there is a {{reload}} command that does block and handle the reconnect for the {{ModelControllerClient}}. > Failure to add a datasource with a name that was previously used > ---------------------------------------------------------------- > > Key: WFLY-5601 > URL: https://issues.jboss.org/browse/WFLY-5601 > Project: WildFly > Issue Type: Bug > Components: Domain Management > Reporter: Heiko Braun > Assignee: James Perkins > Priority: Blocker > Fix For: 10.0.0.Final > > > Steps to re-create: create DS, remove it, reload and then add again (using the same name for the DS) > This leads to: > {noformat} > java.lang.IllegalStateException: WFLYCTL0363: Capability 'org.wildfly.data-source.swarm-integration-test' is already registered in context 'global'. > at org.jboss.as.controller.CapabilityRegistry.registerCapability(CapabilityRegistry.java:146) > at org.jboss.as.controller.OperationContextImpl.registerCapability(OperationContextImpl.java:1422) > at org.jboss.as.controller.OperationContextImpl.registerCapability(OperationContextImpl.java:1414) > at org.jboss.as.controller.AbstractAddStepHandler.recordCapabilitiesAndRequirements(AbstractAddStepHandler.java:274) > at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:146) > at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:890) > at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:659) > at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370) > at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1336) > at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392) > at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:217) > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1059) RestartParentResourceAdd/RemoveHandler should handle capability registration

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1059?page=com.atlassian.jira.plugi... ] Brian Stansberry reassigned WFCORE-1059: ---------------------------------------- Fix Version/s: 3.0.0.Alpha1 Assignee: Tomaz Cerar (was: Brian Stansberry) > RestartParentResourceAdd/RemoveHandler should handle capability registration > ---------------------------------------------------------------------------- > > Key: WFCORE-1059 > URL: https://issues.jboss.org/browse/WFCORE-1059 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Affects Versions: 2.0.0.CR6 > Reporter: Paul Ferraro > Assignee: Tomaz Cerar > Fix For: 3.0.0.Alpha1 > > > RestartParentResourceAddHandler and RestartParentResourceRemoveHandler do not extend the respective AbstractAddStepHandler and AbstractRemoveStepHandler base classes, and thus does not handle capability [un]registration. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5601) Failure to add a datasource with a name that was previously used

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFLY-5601?page=com.atlassian.jira.plugin.... ] James Perkins reassigned WFLY-5601: ----------------------------------- Assignee: James Perkins (was: Brian Stansberry) > Failure to add a datasource with a name that was previously used > ---------------------------------------------------------------- > > Key: WFLY-5601 > URL: https://issues.jboss.org/browse/WFLY-5601 > Project: WildFly > Issue Type: Bug > Components: Domain Management > Reporter: Heiko Braun > Assignee: James Perkins > Priority: Blocker > Fix For: 10.0.0.Final > > > Steps to re-create: create DS, remove it, reload and then add again (using the same name for the DS) > This leads to: > {noformat} > java.lang.IllegalStateException: WFLYCTL0363: Capability 'org.wildfly.data-source.swarm-integration-test' is already registered in context 'global'. > at org.jboss.as.controller.CapabilityRegistry.registerCapability(CapabilityRegistry.java:146) > at org.jboss.as.controller.OperationContextImpl.registerCapability(OperationContextImpl.java:1422) > at org.jboss.as.controller.OperationContextImpl.registerCapability(OperationContextImpl.java:1414) > at org.jboss.as.controller.AbstractAddStepHandler.recordCapabilitiesAndRequirements(AbstractAddStepHandler.java:274) > at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:146) > at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:890) > at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:659) > at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370) > at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1336) > at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392) > at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:217) > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5601) Failure to add a datasource with a name that was previously used

by Heiko Braun (JIRA)

Heiko Braun created WFLY-5601: --------------------------------- Summary: Failure to add a datasource with a name that was previously used Key: WFLY-5601 URL: https://issues.jboss.org/browse/WFLY-5601 Project: WildFly Issue Type: Bug Components: Domain Management Reporter: Heiko Braun Assignee: Brian Stansberry Priority: Blocker Fix For: 10.0.0.Final Steps to re-create: create DS, remove it, reload and then add again (using the same name for the DS) This leads to: {noformat} java.lang.IllegalStateException: WFLYCTL0363: Capability 'org.wildfly.data-source.swarm-integration-test' is already registered in context 'global'. at org.jboss.as.controller.CapabilityRegistry.registerCapability(CapabilityRegistry.java:146) at org.jboss.as.controller.OperationContextImpl.registerCapability(OperationContextImpl.java:1422) at org.jboss.as.controller.OperationContextImpl.registerCapability(OperationContextImpl.java:1414) at org.jboss.as.controller.AbstractAddStepHandler.recordCapabilitiesAndRequirements(AbstractAddStepHandler.java:274) at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:146) at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:890) at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:659) at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370) at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1336) at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392) at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:217) {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5600) List of nodes taken from org.wildfly.clustering.group.Group is different across nodes

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-5600?page=com.atlassian.jira.plugin.... ] Paul Ferraro closed WFLY-5600. ------------------------------ Fix Version/s: 10.0.0.Alpha3 Resolution: Out of Date This issue was addressed by: https://github.com/wildfly/wildfly/commit/bc19803a2fcd5b02caad187a0353ab5... > List of nodes taken from org.wildfly.clustering.group.Group is different across nodes > ------------------------------------------------------------------------------------- > > Key: WFLY-5600 > URL: https://issues.jboss.org/browse/WFLY-5600 > Project: WildFly > Issue Type: Bug > Components: Clustering, EE, EJB > Affects Versions: 9.0.1.Final > Environment: Windows 7 64 bit, JDK 1.8_20 64bit > Reporter: Piotr Nowicki > Assignee: Paul Ferraro > Labels: channel, cluster, jgroups > Fix For: 10.0.0.Alpha3 > > > I have a cluster of 2 nodes with a WAR application deployed using web-console and exposing EJB remote business interface with following content: > {code}@Stateless > @Remote > public class ServiceImplementation implements Service { > @Resource( lookup = "java:jboss/clustering/group/ejb" ) > private Group channelGroup; > @Override > public void printNodeList() { > for( Node node : channelGroup.getNodes()) { > System.out.println( "node = " + node ); > } > } > } > {code} > I invoke this EJB from a standalone client multiple times (to make sure that method calls will reach both nodes.) > The result is different on both nodes: > * On master node the result is *correct* = two nodes' names are printed out , > * On second node the result is *incorrect* = *no nodes' names are printed out*. > This was working fine in WFLY 8.2.0.Final. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira October 2015