If you haven’t already, please send in a PR updating your component to Final status, as we hope to release 9 Final this month.
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
there ware some discussions on how we should improve handling complex types
of attribute bit better in CLI.
For most part that was about Map & List types.
After some discussions with few of you I came up with plan / ideas what all
options are there for us to improve on.
you can see current state of proposed enhancements at
In short, I propose to add set of map-* and list-* global operations and
improve :read-attribute & :write-attribute
with EL like syntax for reading / updating map, list and generic complex
Let me know what you think about it, especially Console & CLI folks.
The reason this is coming up now is I am working on adding references to
Elytron services from the interfaces, also I know there is plenty of
demand for additional configuration options on these.
So the question is should the management interface definitions be a part
of a subsystem of their own or should they remain a top level?
My vote would be make them a part of a subsystem, my main justifications
- They are going to be dependent on capabilities supplied by other
- We already have non-optimal code in there to access subsystem
supplied services so can clean this up.
- In standalone mode they should not be strictly necessary, it should
be possible to remove all remote administration for standalone.
Even in the case of a slave host controller, if that host controller
pulls it's Elytron definition from the master it could also pull it's
management interface definitions from master.
If no one is actively working on WFLY-1192, I’ll give it a go. Not sure how quickly I’ll be able to turn it around. Sources appear to be under wildly-core. Let me know if you’d like to me to work on this.
Quick warning for anyone developing using Java 8 but on projects still
dependent on Java 7.
Normally this is fine, as an engineer you make sure you don't use any
new language features or call new APIs and generally it all works.
With Java 8 there is one addition gotcha, Java 8 adds support for
default method implementations on interfaces, to add to this some
pre-existing methods have now been replaced with default
implementations. The side effect being it is easy to miss that you have
a method missing from a class and it will not be picked up till it is
compiled on Java 7.
e.g. On java.util.Iterator the remove method is now default so classes
that implement this interface no longer need to implement that method
unless they really are providing an implementation of that method.
I am migrating my application from JBoss 6 to Wildfly 8. MDB in my
application uses "jms-ra.rar" as resource adapter and the rar archive is
present in *server/deploy *directory of JBoss 6.
Can anyone help me about the default resource adapter in Wildfly that can
be used. There is a module *org.hornetq.ra* I observed and please anyone
explain about how to use the default resource adapter in Wildfly.
Many thanks in advance.
The JBoss EJB Client project at GitHub  has undergone a couple of
administrative changes in anticipation of WildFly 10 development.
The 'master' branch, which was previously versioned at 2.1.x, is now for
3.x development. The 2.x development branch has been moved to the '2.x'
branch. Development of the 1.0.x series is still in the existing 1.0
branch and will remain there, as will the 2.0 branch for 2.0.x development.
The 3.x code is presently reasonably stable but it does rely on a
snapshot of JBoss Remoting 5.x at the moment.
The JIRA project  has been updated with a 3.0.0.Beta1 release.