[wildfly-dev] Accessing system properties in a subsystem

Kabir Khan kabir.khan at jboss.com
Mon Dec 12 13:10:29 EST 2016


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




More information about the wildfly-dev mailing list