8:57 a.m.
The quick summary of this email: the Hawkular Wildfly Monitor Agent will not be able to
run on WildFly 9 in its current state. It must be refactored due to changes that were made
in the WildFly 9 subsystem extension API.
Details:
After staring at this for a while, I found that our currently WildFly8 code layout of the
subsystem extensions in the agent needs to change for this to run in WF9 - I don't
think I used this approach in the bus or nest subsystem extensions so nothing needs to
change there.
The design pattern here is to use PersistentResourceDefinition subclasses for our the
subsystem resource definitions (called the Definition classes). In here you define static
members for all attributes and operations as well as an INSTANCE object of the definition
itself, among other things.
The problem is, that same Definition class needs to grab (and thus create) an instance of
the AddStepHandler within the Definition class' constructor. And THAT AddStepHandler
needs to refer back to the Definition object for the attributes. Today, it does so in the
populateModel() overloaded method, which isn't a problem. However, we needed to access
a parent class' data field (this.attributes) to set our attributes in that
populateModel() method. Unfortunately, that parent class in WF9 has changed that
this.attributes data field to final. So we can't do that anymore. Instead, it appears
the only way to set the attributes now is to pass them in via the AddStepHandler
class' constructor (calling the superclass's "super(Collection<?>
attributes")).
But this introduces an ugly circular dependency in the Definition and AddStepHandler
constructors - it bombs with an NPE.
So this means in order for us to move the agent to WF9, I would need to refactor the
subsystem definition classes - I would probably have to extract out all of the
attribute/operation definitions into some independent class that can be shared between the
*Definition and *Add classes to avoid this constructor-circularity dependency. It probably
won't be hard to do this, just a hour or two hopefully. But as it is now, it can't
run on WF9.
9:08 a.m.
Here's what the error looks like:
https://travis-ci.org/hawkular/hawkular-agent/builds/63771085
And here's the changes that would need to be made for it to compile with WildFly 9 but
introduces the circular constructor problem (this is just to workaround that issue with
this.attributes changed to "final"):
https://github.com/hawkular/hawkular-agent/commit/84fbfb3354f2eba4524fd4f...
As the comment says, I tried passing Array.asList(XYZDefinition.ATTRIBUTES) in the
constructor, as well as what you see here (XYZDefinition.INSTANCE.getAttributes()) but
both have this circular problem and breaks.
----- Original Message -----
The quick summary of this email: the Hawkular Wildfly Monitor Agent
will not
be able to run on WildFly 9 in its current state. It must be refactored due
to changes that were made in the WildFly 9 subsystem extension API.
Details:
After staring at this for a while, I found that our currently WildFly8 code
layout of the subsystem extensions in the agent needs to change for this to
run in WF9 - I don't think I used this approach in the bus or nest subsystem
extensions so nothing needs to change there.
The design pattern here is to use PersistentResourceDefinition subclasses for
our the subsystem resource definitions (called the Definition classes). In
here you define static members for all attributes and operations as well as
an INSTANCE object of the definition itself, among other things.
The problem is, that same Definition class needs to grab (and thus create) an
instance of the AddStepHandler within the Definition class' constructor. And
THAT AddStepHandler needs to refer back to the Definition object for the
attributes. Today, it does so in the populateModel() overloaded method,
which isn't a problem. However, we needed to access a parent class' data
field (this.attributes) to set our attributes in that populateModel()
method. Unfortunately, that parent class in WF9 has changed that
this.attributes data field to final. So we can't do that anymore. Instead,
it appears the only way to set the attributes now is to pass them in via the
AddStepHandler class' constructor (calling the superclass's
"super(Collection<?> attributes")).
But this introduces an ugly circular dependency in the Definition and
AddStepHandler constructors - it bombs with an NPE.
So this means in order for us to move the agent to WF9, I would need to
refactor the subsystem definition classes - I would probably have to extract
out all of the attribute/operation definitions into some independent class
that can be shared between the *Definition and *Add classes to avoid this
constructor-circularity dependency. It probably won't be hard to do this,
just a hour or two hopefully. But as it is now, it can't run on WF9.
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
5:30 a.m.
Would that still work with WF 8?
Yes, it should.
----- Original Message -----
> On 23 May 2015, at 16:08, John Mazzitelli wrote:
>
> > And here's the changes that would need to be made for it to compile
> > with WildFly 9 but introduces the circular constructor problem (this
>
Would that still work with WF 8?
>
_______________________________________________
> hawkular-dev mailing list
> hawkular-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
3392
days inactive
3395
days old
3 comments
2 participants
participants (2)
-
Heiko W.Rupp -
John Mazzitelli