[wildfly-dev] Accessing system properties in a subsystem

Tom Jenkinson tom.jenkinson at redhat.com
Tue Dec 13 06:55:59 EST 2016 

Yeah, moving the lookup to the area you mentioned worked - thanks again!

On 13 December 2016 at 10:54, Tom Jenkinson <tom.jenkinson at redhat.com>
wrote:

> Thanks, I will take a look. Did this change recently? If not I am at a
> loss why it is starting to fail an existing test.
>
> On 12 December 2016 at 21:33, Brian Stansberry <
> brian.stansberry at redhat.com> wrote:
>
>>
>> > On Dec 12, 2016, at 3:21 PM, Brian Stansberry <
>> brian.stansberry at redhat.com> wrote:
>> >
>> > This is the problem: the TransactionExtension initialize method of
>> touching classes that result in doing static initialization stuff that
>> reads the system props at that point, which is too early:
>> >
>>
>> s/of touching/is touching/g
>>
>> A likely fix is to just not store a ref to coordinatorEnvironmentBean in
>> TransactionSubsystemRootResourceDefinition$StatisticsEnabledHandler.
>> Just find it and use it in applyUpdateToRuntime/revertUpdateToRuntime
>> neither of which will get called before system properties are set. They
>> don’t get called at all if the user doesn’t do a write-attribute op to
>> change that attribute.
>>
>> > "ServerService Thread Pool -- 21 at 3635" prio=5 tid=0x30 nid=NA runnable
>> >  java.lang.Thread.State: RUNNABLE
>> >         at com.arjuna.common.util.propertyservice.PropertiesFactory.ini
>> tPropertiesFactory(PropertiesFactory.java:53)
>> >         - locked <0x1389> (a java.lang.Class)
>> >         at com.arjuna.common.util.propertyservice.PropertiesFactory.get
>> DefaultProperties(PropertiesFactory.java:36)
>> >         at com.arjuna.common.internal.util.propertyservice.BeanPopulato
>> r.getNamedInstance(BeanPopulator.java:86)
>> >         at com.arjuna.common.internal.util.propertyservice.BeanPopulato
>> r.getDefaultInstance(BeanPopulator.java:53)
>> >         at com.arjuna.ats.arjuna.common.arjPropertyManager.getCoordinat
>> orEnvironmentBean(arjPropertyManager.java:51)
>> >         at org.jboss.as.txn.subsystem.TransactionSubsystemRootResourceD
>> efinition$StatisticsEnabledHandler.<init>(TransactionSubsyst
>> emRootResourceDefinition.java:518)
>> >         at org.jboss.as.txn.subsystem.TransactionSubsystemRootResourceD
>> efinition.registerAttributes(TransactionSubsystemRootResourc
>> eDefinition.java:314)
>> >         at org.jboss.as.controller.registry.NodeSubregistry.registerChi
>> ld(NodeSubregistry.java:104)
>> >         at org.jboss.as.controller.registry.ConcreteResourceRegistratio
>> n.registerSubModel(ConcreteResourceRegistration.java:225)
>> >         at org.jboss.as.controller.extension.ExtensionRegistry$Subsyste
>> mRegistrationImpl.registerSubsystemModel(ExtensionRegistry.java:706)
>> >         at org.jboss.as.txn.subsystem.TransactionExtension.initialize(T
>> ransactionExtension.java:104)
>> >         at org.jboss.as.controller.extension.ExtensionAddHandler.initia
>> lizeExtension(ExtensionAddHandler.java:131)
>> >         at org.jboss.as.controller.extension.ExtensionAddHandler.initia
>> lizeExtension(ExtensionAddHandler.java:104)
>> >         at org.jboss.as.controller.extension.ParallelExtensionAddHandle
>> r$ExtensionInitializeTask.call(ParallelExtensionAddHandler.java:144)
>> >         at org.jboss.as.controller.extension.ParallelExtensionAddHandle
>> r$ExtensionInitializeTask.call(ParallelExtensionAddHandler.java:127)
>> >         at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>> >         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPool
>> Executor.java:1142)
>> >         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo
>> lExecutor.java:617)
>> >         at java.lang.Thread.run(Thread.java:745)
>> >         at org.jboss.threads.JBossThread.run(JBossThread.java:320)
>> >
>> >
>> >> On Dec 12, 2016, at 2:50 PM, Tom Jenkinson <tom.jenkinson at redhat.com>
>> wrote:
>> >>
>> >> Thanks for the input/
>> >>
>> >> This is the point I do not think the property has been set by:
>> >>
>> >> "MSC service thread 1-3 at 2595" prio=5 tid=0x14 nid=NA runnable
>> >>  java.lang.Thread.State: RUNNABLE
>> >>        at com.arjuna.ats.arjuna.common.RecoveryEnvironmentBean.getExpi
>> ryScannerClassNames(RecoveryEnvironmentBean.java:336)
>> >>        - locked <0x1bb6> (a com.arjuna.ats.arjuna.common.R
>> ecoveryEnvironmentBean)
>> >>        at sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAcc
>> essorImpl.java:-1)
>> >>        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce
>> ssorImpl.java:62)
>> >>        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe
>> thodAccessorImpl.java:43)
>> >>        at java.lang.reflect.Method.invoke(Method.java:498)
>> >>        at com.arjuna.common.internal.util.propertyservice.BeanPopulato
>> r.handleGroupProperty(BeanPopulator.java:263)
>> >>        at com.arjuna.common.internal.util.propertyservice.BeanPopulato
>> r.configureFromProperties(BeanPopulator.java:170)
>> >>        at com.arjuna.common.internal.util.propertyservice.BeanPopulato
>> r.getNamedInstance(BeanPopulator.java:87)
>> >>        at com.arjuna.common.internal.util.propertyservice.BeanPopulato
>> r.getDefaultInstance(BeanPopulator.java:53)
>> >>        at com.arjuna.ats.arjuna.common.recoveryPropertyManager.getReco
>> veryEnvironmentBean(recoveryPropertyManager.java:34)
>> >>        at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(
>> ArjunaRecoveryManagerService.java:96)
>> >>        - locked <0x1bd2> (a org.jboss.as.txn.service.Arjun
>> aRecoveryManagerService)
>> >>        at org.jboss.msc.service.ServiceControllerImpl$StartTask.
>> startService(ServiceControllerImpl.java:1963)
>> >>        at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(Se
>> rviceControllerImpl.java:1896)
>> >>        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPool
>> Executor.java:1142)
>> >>        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo
>> lExecutor.java:617)
>> >>        at java.lang.Thread.run(Thread.java:745)
>> >>
>> >> (that is output from the debugger)
>> >>
>> >> Once releasing that thread and letting the container continue startup
>> I see this execute:
>> >> 2016-12-12 20:46:49,731 TRACE [org.jboss.as.controller.management-operation]
>> (Controller Boot Thread) Final response for step handler
>> org.jboss.as.server.operations.SystemPropertyAddHandler at 5c7e7735
>> handling add in address [("system-property" =>
>> "RecoveryEnvironmentBean.expiryScannerClassNames")] is {"outcome" =>
>> "success"}
>> >> 2016-12-12 20:46:49,787 TRACE [org.jboss.as.controller.management-operation]
>> (Controller Boot Thread) Final response for step handler
>> org.jboss.as.controller.ValidateModelStepHandler at f15c8f7 handling
>> internal-model-validation in address [("system-property" =>
>> "RecoveryEnvironmentBean.expiryScannerClassNames")] is {"outcome" =>
>> "success"}
>> >>
>> >> I believe this is different to previous behaviour as I have had a
>> defect raised against TX: https://issues.jboss.org/browse/JBEAP-7820.
>> It's possible that there is a regression in Narayana (somehow) if nothing
>> changed in this area in the core itself.
>> >>
>> >> Thanks for your input,
>> >> Tom
>> >>
>> >>
>> >>
>> >>
>> >> On 12 December 2016 at 20:15, Brian Stansberry <
>> brian.stansberry at redhat.com> wrote:
>> >> This works fine for me. Adding that xml snippet to standalone.xml
>> after the <extensions> element I see the property being set during boot
>> before any processing of subsystem operations begins.
>> >>
>> >>> On Dec 12, 2016, at 1:55 PM, Brian Stansberry <
>> brian.stansberry at redhat.com> wrote:
>> >>>
>> >>> I don’t see anything in the organization of boot ops that would have
>> changed the ordering, and the add op for that system property should be
>> executing prior to the subsystem ops. I’ll see if I can reproduce.
>> >>>
>> >>>> On Dec 12, 2016, at 12:10 PM, Kabir Khan <kabir.khan at jboss.com>
>> wrote:
>> >>>>
>> >>>> Where are you trying to use the system property from? They should
>> only be attempted resolved during the RUNTIME stage, not MODEL.
>> >>>>> On 12 Dec 2016, at 18:00, Tom Jenkinson <tom.jenkinson at redhat.com>
>> wrote:
>> >>>>>
>> >>>>> Hi,
>> >>>>>
>> >>>>> I have a subsystem that configures itself from system properties.
>> >>>>>
>> >>>>> For example:
>> >>>>> <system-properties>
>> >>>>> <property name="RecoveryEnvironmentBean.expiryScannerClassNames"
>> value="com.arjuna.ats.internal.arjuna.recovery.ExpiredTransactionStatusManagerScanner
>> com.arjuna.ats.internal.arjuna.recovery.AtomicActionExpiryScanner"/>
>> >>>>> </system-properties>
>> >>>>>
>> >>>>> In earlier revisions of WFLY this worked fine. However I am now
>> seeing that the system property is not set until after my subsystem has
>> started. I can tell this as I have breakpoints on where I process the
>> property. I can see "MSC service thread 1-4" attempting to process the
>> property (which is not set). I do later see messages that suggest the
>> system property is set but at that the later point:
>> >>>>>
>> >>>>> 2016-12-12 17:57:48,042 TRACE [org.jboss.as.controller.management-operation]
>> (Controller Boot Thread) Final response for step handler
>> org.jboss.as.server.operations.SystemPropertyAddHandler at 784c8c5f
>> handling add in address [("system-property" =>
>> "RecoveryEnvironmentBean.expiryScannerClassNames")] is {"outcome" =>
>> "success"}
>> >>>>> 2016-12-12 17:57:48,093 TRACE [org.jboss.as.controller.management-operation]
>> (Controller Boot Thread) Final response for step handler
>> org.jboss.as.controller.ValidateModelStepHandler at 87b4493 handling
>> internal-model-validation in address [("system-property" =>
>> "RecoveryEnvironmentBean.expiryScannerClassNames")] is {"outcome" =>
>> "success"}
>> >>>>>
>> >>>>> Does my subsystem need to depend on something to get the old
>> behaviour of being started after system properties are processed?
>> >>>>>
>> >>>>> My subsystem is the transaction one and the service is the recovery
>> manager.
>> >>>>>
>> >>>>> Thanks!
>> >>>>> Tom
>> >>>>> _______________________________________________
>> >>>>> wildfly-dev mailing list
>> >>>>> wildfly-dev at lists.jboss.org
>> >>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> >>>>
>> >>>>
>> >>>> _______________________________________________
>> >>>> wildfly-dev mailing list
>> >>>> wildfly-dev at lists.jboss.org
>> >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> >>>
>> >>> --
>> >>> Brian Stansberry
>> >>> Manager, Senior Principal Software Engineer
>> >>> JBoss by Red Hat
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>> wildfly-dev mailing list
>> >>> wildfly-dev at lists.jboss.org
>> >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> >>
>> >> --
>> >> Brian Stansberry
>> >> Manager, Senior Principal Software Engineer
>> >> JBoss by Red Hat
>> >>
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> wildfly-dev mailing list
>> >> wildfly-dev at lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> >>
>> >
>> > --
>> > Brian Stansberry
>> > Manager, Senior Principal Software Engineer
>> > JBoss by Red Hat
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > wildfly-dev mailing list
>> > wildfly-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>> --
>> Brian Stansberry
>> Manager, Senior Principal Software Engineer
>> JBoss by Red Hat
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20161213/7f8276d6/attachment-0001.html

More information about the wildfly-dev mailing list