[wildfly-dev] Accessing system properties in a subsystem

[Tom Jenkinson]

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.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 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20161212/0e7f0f2a/attachment-0001.html