10:24 a.m.
On 9/17/15 5:02 AM, Darran Lofthouse wrote:
Has this code been already written or not? I was told the other day
that this code was almost complete but now it is back to a design
discussion. I have also been told that this is not urgent for WildFly 10.
If this is still being designed and is not critical for WildFly 10 can I
please ask that this is stopped and we pick this up later - this
directly conflicts with changes I have already made to integrate Elytron.
In general my opinion is that instead of spending any effort on
redesigning the current interfaces we should put the effort into the
design of a new subsystem to contain these interfaces and that should
start from the beginning where we can remodel the relationship between
the two interface types.
That is fine; we should stop. This work was driven by
https://issues.jboss.org/browse/WFCORE-949 /
https://issues.jboss.org/browse/JBEAP-980 neither of which are scheduled
for WF 10. WFCORE-949 isn't truly a regression, as doing a similar thing
in EAP 6 by removing the native interface will also fail. But still, if
we could have fixed 949 for WF 10 by adding a no-brainer child resource
I would have liked to do so.
But it's clear that the design of that child resource is not a
no-brainer, so we should stop.
Regards,
Darran Lofthouse.
On 16/09/15 18:33, Emmanuel Hugonnet wrote:
> Hi,
> This is for management interfaces only.
> We need a capability to cover the fact that some management interfaces may provides
jboss-remoting endpoints to be used by JMX.
> The native-interface provides this capability at the resource level, so this is nice
and straightforward.
> Currently making an http-interface http-upgrade-enabled is done through the well
named 'http-upgrade-enabled' attribute.
> But because of the use of an attribute we have no nice standard way to register the
capability.
> One way to do that would be to use a child resource,
"http-upgrade-support=on" to define the fact that this http-interface supports
upgrade.
> We could then move the code and services associated with this support to the
addHandler and removeHandler.
> To keep backward compatibility :
> - for the add / remove of current resource :
> it is easy to add a new step to add the new resource on the http-interface
addHandler, and do the same for removal.
> - for the beloved http-upgrade-enabled attribute which is writeable but
doesn't really do anything until the interface is restarted.
> Of course it could get deprecated but we would still have a writeable attribute that
represents a duplicate state of the child resource.
> We may want to use the write-attribute handler on this attribute to call the resource
ops without impacting the services, just changing the
> model.
>
> What do you think ?
>
>
>
>
> _______________________________________________
> 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
Senior Principal Software Engineer
JBoss by Red Hat