May 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-1481) list-add operation doesn't work on login-modules attribute

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1481?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-1481: ------------------------------------------ I looked at the test case and I don't think my word "contrived" was accurate; I think there was just a small mistake in the test in not reading the attribute value in Stage.RUNTIME. https://github.com/wildfly/wildfly-core/pull/1562 fixes that. I think the fix you're trying will have problems with this scenario of working with a runtime-only attribute, but I think the existing code will too. I have some thoughts on how to get it to work, but it will be complex. If you can't find examples of runtime-only list and map attributes it may be ok to get the basic case corrected and file a JIRA for the runtime-only case. The runtime-only case fix will likely build on the simple case fix anyway. Probably by doing some gymnastics to get things to execute in Stage.RUNTIME at the right point. To get an effecdt like your Stage.DOMAIN suggestion, but Stage.RUNTIME instead of Stage.DOMAIN. Quick summary of the trick: 1) Find out before doing any read-attribute whether the attribute is runtime-only. This is done via context.getResourceRegistration().getAttributeAccess(...).getStorageType(). 2) If it's Storage.RUNTIME, then instead of registering the "another step that uses the data in the now-populated response node to do the rest of the manipulation" in Stage.MODEL, you do the following: a) Register a step in Stage.RUNTIME that does nothing except b) Registers also in Stage.RUNTIME "another step that uses the data in the now-populated response node to do the rest of the manipulation". Here's how this works. I'll describe the manipulation of the list of steps below, with this id syntax M## or R## where M is Stage.MODEL, R is Stage.RUNTIME and ## is a sequence number. I. The Storage.CONFIGURATION (i.e. non-runtime-only) attribute case looks like this: 1) Begin operation execution: M0 (the PrepareStepHandler, which figures out which OSH is registered to handle the user's request and adds a step.) 2) M0 executes: M0 M1 (ListAddHandler) 3) M1 executes M0 M1 M2 (the handler for read-attribute) M3 (the handler that takes the M2 result and adds write-attribute) 4) M2 executes (same queue as 3)) 5) M3 executes M0 M1 M2 M3 M4 (the write-attribute step) 6) M4 executes M0 M1 M2 M3 M4 R1 (a step to update the runtime to reflect the write-attribute) II. The Storage.RUNTIME attribute case looks like this: 1) and 2) are the same as above. 3) M1 executes M0 M1 M2 (the handler for read-attribute) R1 (the odd R handler that just adds a step) 4) M2 executes M0 M1 M2 R1 (the odd R handler that just adds a step) R2 (added by M2 to do the read of the runtime in Stage.RUNTIME) 5) R1 executes M0 M1 M2 R1 R2 R3 (the handler that takes the R2 result and adds write-attribute) 6) R2 executes same as 5) 7) R3 executes M0 M1 M2 R1 R2 R3 R4 (the write-attribute step, registered in Stage.RUNTIME) 8) R4 executes M0 M1 M2 R1 R2 R3 R4 So why the "odd" R1? Because R3 has to execute after R2, which means it needs to be registered after R2. The "odd" R1 executes after M2 so it is able to register R3 after R2. The reality is things are even more complex than this. But this illustrates the kind of things that can be done to trigger execution in the right spot. > list-add operation doesn't work on login-modules attribute > ---------------------------------------------------------- > > Key: WFCORE-1481 > URL: https://issues.jboss.org/browse/WFCORE-1481 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 2.1.0.Final > Reporter: Bartosz Spyrko-Śmietanko > Assignee: Tomas Hofman > > Executing list-add operation on login-modules results in the modules being replaced instead of appending new module. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1379) service.bat points user to wrong directory

by Jay Rostosky (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1379?page=com.atlassian.jira.plugi... ] Jay Rostosky commented on WFCORE-1379: -------------------------------------- Still doesn't work, sorry. I grabbed service.bat from GitHub link, replacing original one, then copied service directory to bin. It needs to be in bin. Fails. Then I grabbed *all* the service-related files from GitHub, just to be safe (in case any of the exes had changed) - still fails. See details below. Service installs fine - or appears to... Tried running command prompt as Administrator - no luck. Tried all of: Windows Service Controller UI Windows "sc start" command Our script's "service start" command None work. When attempted via Windows Service Controller UI: The Wildfly service terminated with service-specific error code 1. When attempted via "service start" (even as Administrator): The data area passed to a system call is too small. Failed to start serviceService Wildfly starting... ERROR: Failed to load service Wildfly configuration Event Log: The Wildfly service terminated with service-specific error Incorrect function.. > service.bat points user to wrong directory > ------------------------------------------ > > Key: WFCORE-1379 > URL: https://issues.jboss.org/browse/WFCORE-1379 > Project: WildFly Core > Issue Type: Bug > Components: Scripts > Affects Versions: 2.0.10.Final > Reporter: Nicklas Karlsson > Assignee: Tomaz Cerar > Priority: Trivial > Fix For: 2.2.0.CR1, 3.0.0.Alpha1 > > > Running service.bat from the docs/contrib/scripts/service dir tells user to run the script under bin/service*s* but the binary paths to the services expects bin/service, resulting in service install failure with file not found -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5846) WaitTimeInterceptor should store the start wait time in the context only if the statistics are enabled.

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-5846?page=com.atlassian.jira.plugin.... ] Brian Stansberry reassigned WFLY-5846: -------------------------------------- Fix Version/s: 10.1.0.Final Assignee: Andrej Golovnin Resolution: Done Thanks! > WaitTimeInterceptor should store the start wait time in the context only if the statistics are enabled. > ------------------------------------------------------------------------------------------------------- > > Key: WFLY-5846 > URL: https://issues.jboss.org/browse/WFLY-5846 > Project: WildFly > Issue Type: Enhancement > Components: EJB > Affects Versions: 10.0.0.CR4 > Reporter: Andrej Golovnin > Assignee: Andrej Golovnin > Fix For: 10.1.0.Final > > > Currently the WaitTimeInterceptor always stores the start wait time in the interceptor context. But the ExecutionTimeInterceptor uses this value only if the statistics are enabled on the component. Therefore the WaitTimeInterceptor should be changed to store the start wait time in the context only if statistics are enabled. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-532) Enhance the properties security realm to support reloading.

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-532: ------------------------------------ Summary: Enhance the properties security realm to support reloading. Key: ELY-532 URL: https://issues.jboss.org/browse/ELY-532 Project: WildFly Elytron Issue Type: Enhancement Components: Realms Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.1.0.Beta6 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1481) list-add operation doesn't work on login-modules attribute

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1481?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-1481: ------------------------------------------ Just a quick comment on a couple details before digging in more on the main point you raised: "WriteOSH is doing everything in DOMAIN stage" is not ok. Stage.DOMAIN shouldn't be used by anything outside the specialized OSHs the HostControllers use for rolling changes out to the domain. The test sounds odd, in the "the tested attribute also has WriteOSH defined, which updates the resource model" bit. That sounds contrived; I would expect a runtime-only attribute to only write to the runtime, and never write to the model. But it sounds like changing that to not write to the model would not help the basic problem, which is that Stage.RUNTIME changes are not getting handled. I'll poke a bit. > list-add operation doesn't work on login-modules attribute > ---------------------------------------------------------- > > Key: WFCORE-1481 > URL: https://issues.jboss.org/browse/WFCORE-1481 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 2.1.0.Final > Reporter: Bartosz Spyrko-Śmietanko > Assignee: Tomas Hofman > > Executing list-add operation on login-modules results in the modules being replaced instead of appending new module. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1552) Slaves should report the master's version in the domain model

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1552?page=com.atlassian.jira.plugi... ] Kabir Khan moved JBEAP-4592 to WFCORE-1552: ------------------------------------------- Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-1552 (was: JBEAP-4592) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Domain Management (was: Domain Management) Target Release: (was: 7.backlog.GA) Affects Version/s: 2.2.0.CR2 (was: 7.0.0.GA) > Slaves should report the master's version in the domain model > ------------------------------------------------------------- > > Key: WFCORE-1552 > URL: https://issues.jboss.org/browse/WFCORE-1552 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 2.2.0.CR2 > Reporter: Kabir Khan > Assignee: Kabir Khan > > Setting up the mixed domain tests for an EAP7 slave, I get the following error : > {code} > SimpleMixedDomain700TestCase>SimpleMixedDomainTest.test00002_Versioning:139 expected:<{ > "management-major-version" => 4, > "management-micro-version" => 0, > "management-minor-version" => 1, > "name" => "Unnamed Domain", > "namespaces" => [], > "product-name" => "WildFly Full", > "product-version" => "10.1.0.Final-SNAPSHOT", > "release-codename" => "Kenny", > "release-version" => "2.2.0.CR2", > "schema-locations" => [] > }> but was:<{ > "management-major-version" => 4, > "management-micro-version" => 0, > "management-minor-version" => 1, > "name" => "Unnamed Domain", > "namespaces" => [], > "product-name" => "JBoss EAP", > "product-version" => "7.0.0.GA", > "release-codename" => "Kenny", > "release-version" => "2.1.2.Final-redhat-1", > "schema-locations" => [] > }> > {code} > The 'expected' is the WildFly master values, while the 'actual' are the slave values. product-name, product-version, release-codename and release-version on the slave should be the same as the master values. Once we upgrade to Wildfly Core 3.0.0 we should also check that the management-[major/minor/micro]-version attributes on the slave are the same as the DC's values as well (i.e 5.0.0 rather than 4.0.1) This is similar to WFLY-3228 back in the day. > This is probably caused by the SyncXXX handlers for pushing the domain config as operations (WFCORE-401) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1551) wildfly-init-redhat.sh and jboss-eap-rhel.sh scripts do not work on RHEL 5 OS

by Vlado Pakan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1551?page=com.atlassian.jira.plugi... ] Vlado Pakan closed WFCORE-1551. ------------------------------- Resolution: Done Cloned for wrong project > wildfly-init-redhat.sh and jboss-eap-rhel.sh scripts do not work on RHEL 5 OS > ----------------------------------------------------------------------------- > > Key: WFCORE-1551 > URL: https://issues.jboss.org/browse/WFCORE-1551 > Project: WildFly Core > Issue Type: Bug > Components: Scripts > Affects Versions: 2.2.0.CR2 > Reporter: Vlado Pakan > Assignee: Vlado Pakan > > Wildfly start-up script $JBOSS_HOME/docs/contrib/scripts/init.d/wildfly-init-redhat.sh tries to get successful start timestamp using following command: > grep -o '[0-9]*' $JBOSS_MARKERFILE > This however does not work on RHEL 5 OS, as grep-2.5.1 does not return regular expression result correctly when used with -o option. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1551) wildfly-init-redhat.sh and jboss-eap-rhel.sh scripts do not work on RHEL 5 OS

by Vlado Pakan (JIRA)

Vlado Pakan created WFCORE-1551: ----------------------------------- Summary: wildfly-init-redhat.sh and jboss-eap-rhel.sh scripts do not work on RHEL 5 OS Key: WFCORE-1551 URL: https://issues.jboss.org/browse/WFCORE-1551 Project: WildFly Core Issue Type: Bug Components: Scripts Affects Versions: 2.2.0.CR2 Reporter: Vlado Pakan Assignee: Vlado Pakan Wildfly start-up script $JBOSS_HOME/docs/contrib/scripts/init.d/wildfly-init-redhat.sh tries to get successful start timestamp using following command: grep -o '[0-9]*' $JBOSS_MARKERFILE This however does not work on RHEL 5 OS, as grep-2.5.1 does not return regular expression result correctly when used with -o option. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1550) wildfly-init-redhat.sh script does not work on RHEL 5 OS

by Vlado Pakan (JIRA)

Vlado Pakan created WFCORE-1550: ----------------------------------- Summary: wildfly-init-redhat.sh script does not work on RHEL 5 OS Key: WFCORE-1550 URL: https://issues.jboss.org/browse/WFCORE-1550 Project: WildFly Core Issue Type: Bug Components: Scripts Affects Versions: 2.2.0.CR2 Reporter: Vlado Pakan Assignee: Vlado Pakan Wildfly start-up script $JBOSS_HOME/docs/contrib/scripts/init.d/wildfly-init-redhat.sh tries to get successful start timestamp using following command: grep -o '[0-9]*' $JBOSS_MARKERFILE This however does not work on RHEL 5 OS, as grep-2.5.1 does not return regular expression result correctly when used with -o option. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1481) list-add operation doesn't work on login-modules attribute

by Tomas Hofman (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1481?page=com.atlassian.jira.plugi... ] Tomas Hofman commented on WFCORE-1481: -------------------------------------- I tried Brian's suggestion, and it's working, except that CollectionOperationsTestCase#test[Map/List]OperationsInComposite fails (https://github.com/wildfly/wildfly-core/blob/master/controller/src/test/j...). However, I think the test case doesn't represent real use cases. Reason why it's failing is that: * the tested attribute has Read Operation Step Handler defined, which simulates reading data from runtime, * the tested attribute also has WriteOSH defined, which updates the resource model, and adds another step to update runtime, but this step is added to RUNTIME stage, * so the list-add ops in the composite doesn't see results of previous list-add ops, because runtime is updated at the end of the composite op, not its' individual steps. This problem doesn't happen when: * ReadOSH is not set, because then the value is read from resource's model, which is up to date, * or WriteOSH is doing everything in DOMAIN stage. So I tried to look for actually existing read-write list attributes in Wildfly. The only ones I found either doesn't have ReadOSH, or are using LegacyModulesAttributeReader/Writer. LegacyModulesAttributeWriter is not using RUNTIME stage, so is not affected by this problem. So I think this behaviour is OK..? > list-add operation doesn't work on login-modules attribute > ---------------------------------------------------------- > > Key: WFCORE-1481 > URL: https://issues.jboss.org/browse/WFCORE-1481 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 2.1.0.Final > Reporter: Bartosz Spyrko-Śmietanko > Assignee: Tomas Hofman > > Executing list-add operation on login-modules results in the modules being replaced instead of appending new module. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 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 May 2016