Re: [wildfly-dev] Accessing system properties in a subsystem

Thanks for the input/ This is the point I do not think the property has been set by: "MSC service thread 1-3@2595" prio=5 tid=0x14 nid=NA runnable java.lang.Thread.State: RUNNABLE at com.arjuna.ats.arjuna.common.RecoveryEnvironmentBean. getExpiryScannerClassNames(RecoveryEnvironmentBean.java:336) - locked <0x1bb6> (a com.arjuna.ats.arjuna.common. RecoveryEnvironmentBean) at sun.reflect.NativeMethodAccessorImpl.invoke0( NativeMethodAccessorImpl.java:-1) 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 com.arjuna.common.internal.util.propertyservice.BeanPopulator. handleGroupProperty(BeanPopulator.java:263) at com.arjuna.common.internal.util.propertyservice.BeanPopulator. configureFromProperties(BeanPopulator.java:170) at com.arjuna.common.internal.util.propertyservice.BeanPopulator. getNamedInstance(BeanPopulator.java:87) at com.arjuna.common.internal.util.propertyservice.BeanPopulator. getDefaultInstance(BeanPopulator.java:53) at com.arjuna.ats.arjuna.common.recoveryPropertyManager. getRecoveryEnvironmentBean(recoveryPropertyManager.java:34) at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start( ArjunaRecoveryManagerService.java:96) - locked <0x1bd2> (a org.jboss.as.txn.service. ArjunaRecoveryManagerService) at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService( ServiceControllerImpl.java:1963) at org.jboss.msc.service.ServiceControllerImpl$StartTask.run( ServiceControllerImpl.java:1896) at java.util.concurrent.ThreadPoolExecutor.runWorker( ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run( ThreadPoolExecutor.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@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@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(a)redhat.com&gt; 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(a)redhat.com&gt; 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(a)jboss.com&gt; 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(a)redhat.com&gt; > 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@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@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(a)lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev > >> > >> > >> _______________________________________________ > >> wildfly-dev mailing list > >> wildfly-dev(a)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(a)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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev