this is not new to those of you who attended my talk on the F2F 2016 in
Brno. Let me explain the idea here again for all others who did not have
a chance to be there.
Srcdeps  is a tool to build Maven dependencies from their sources.
With srcdeps, wildfly-core can depend on a specific commit of, e.g.,
where aabbccd is the git commit id to build when any undertow artifact
is requested during the build of wildfly-core.
 describes in detail, how it works.
The main advantage of srcdeps is that changes in components can be
integrated and tested in wildfly-core immediately after they are
committed to a public component branch. There is no need to wait for the
Here in the WildFly family of projects, it is often the case that
something needs to be fixed in a component, but the verification (using
bug reproducer, or integration test) is possible only at the level of
wildfly or wildfly-core. Engineers typically work with snapshots
locally, but when their changes need to get shared (CI, reviews) in a
reproducible manner, snapshots cannot be used anymore.
In such situations a source dependency come in handy: it is very easy to
share and it is as reproducible as a Maven build from a specific commit
can be. All CIs and reviewers can work with it, because all source
dependency compilation is done under the hood by Maven.
Developers working on changes that span over multiple interdependent git
repos can thus get feedback (i-tests, reviews) quickly without waiting
for releases of components.
Srcdeps emerged in the Hawkular family of projects to solve exactly this
kind of situation and is in use there since around October 2015.
When I said there is no need to wait for releases of components, I did
not mean that we can get rid of component releases altogether. Clearly,
we cannot, because i.a. for any tooling uninformed about how srcdeps
work, those source dependencies would simply be non-resolvable from
public Maven repositories. So, before releasing the dependent component
(such as wildfly-core) all its dependencies need to be released. To
enforce this, srcdeps is by default configured to make the release fail,
as long as there are source dependencies.
I have sent a PR introducing srcdeps to wildfly-core:
To get a feeling how it works, checkout the branch, switch to e.g.
(that happens to be the commit id of the 1.4.8.Final tag)
and build wildfly-core as usual with "mvn clean install". You'll see in
the build log that undertow is being cloned to ~/.m2/srcdeps/io/undertow
and that it is built there. After the build, check that the
version of Undertow got installed to your local Maven repo (usually
Are there any questions or comments?
P.S.: I will be talking about srcdeps on Saturday 2017-01-28 at 14:30 at
We're currently working on the next major version of HAL . HAL.next will
include all features of the current management console plus many new features
such as macro recording, topology overview, better keyboard support and
PatternFly  compliance. See  for more details.
We're making good progress and have migrated all of the configuration and
half of the runtime screens to HAL.next. What's missing is the support for
patching and the remaining runtime UI. Our goal is to ship HAL.next with
WildFly asap. If you don't want to wait, I encourage you to try out HAL.next
today  and give us feedback!
I'd like to use this post to give you the chance to participate in the
future of the management console. We already have some basic ideas what
we would like to add to HAL.next, but we also want you to give us additional
As most of you will know both HAL and HAL.next are implemented in GWT.
For the current version there's a way to write extensions as GWT modules .
This is based on the concept of having compile time extensions provided as
maven dependencies. While this gives you full access to the HAL API, it's
often hard to get started for none GWT developers.
New features in GWT 2.8 like JsInterop  make it very easy to export parts
The current management console has some limited monitoring capabilities.
We could improve and enhance these capabilities if this is something which
you want to have out of the box. However we don't want to turn HAL into
another monitoring tool. There are plenty of other tools and frameworks
which focus on monitoring.
# Macro Recording
We've built basic support to record macros in HAL.next. Behind the scenes the
DMR operations are collected and made available for replay. We could extend
this feature to be more dynamic if requested (variables, iterations, el al).
# What else?
It's your turn! What else do you want to see in HAL.next?
recently I decided, that Weld 3 (CDI 2.0, currently nearing Final at high speed) should be running on WildFly 11.
Up until now, we had the integration based on 10.1.0.Final but for several reasons we want to move to 11.
There were some changes and I figured out most of them but I am lost when it comes to security.
I know Elytron was added but I don't know a damn thing about it - could anyone lend a hand here, please?
The code is now located at this branch and the very last commit shows the integration done.
Vast majority is just taken from previous integration with 10.1.0.Final (branch 10.1.0.Final-weld3).
The part I am concerned about is weld/subsystem/src/main/java/org/jboss/as/weld/services/bootstrap/WeldSecurityServices.java 
'getPrincipal' method was earlier adapted to Elytron, and I am thinking the other methods should perhaps be adjusted as well?
But then again, I have no idea how to do that with Elytron... a penny for your thoughts?
I am just checking how wildfly controller handle dynamic resources because
issue (WFCORE-2691) where every recursive :read-resource (even with
include-runtime=false) asks parent resource for list of all dynamic
For example query:
will cause "server" resource (child of messaging-activemq) is asked for list
of all "core-address" (call *getChildren("core-address")*), even trough
they are not
displayed as part of operation result - only blank placeholder is printed:
*"core-address" => undefined,*
This is problem especially in case of new Elytron resources which allow to
user identities using AS model - every :read-resource on root or every AS
currently causes iterating over all users/identities available in all
Is this design problem?
Is there some reason why should wildfly controller ask for all resource
even when they are ignored and not printed?
What do you think about it? How should be resources with dynamic children
Could you please help me with start contributing.
I want to contribute in WildFly project, but couldnot find any information
about ICLA/CCLA. Is it necessary to fill CLA form for starting contributing
Best Regards, Anton Churaev
Currently we store passwords for core management in various attributes.
With Elytron we can use a Credential Store to store those attributes values using a CredentialReference, which led to .
Investigating we have found the following attributes :
* SSLServerIdentityResourceDefinition.KEYSTORE_PASSWORD KEY_PASSWORD
* LocalAuthenticationResourceDefinition.DEFAULT_USER ALLOWED_USERS
Did we miss attributes that could be alternative of CredentialReference ?
KEYSTORE_PASSWORD KEY_PASSWORD (in SSLServerIdentityResourceDefinition and TruststoreAuthenticationResourceDefinition) are using the
attribute definitions of KeystoreAttributes.
We could introduce the alternatives in those definition but that would impact SyslogAuditLogProtocolResourceDefinition.TlsKeyStore.
It's really a pain when you are developing a multifaceted change to the
application server and it hangs. Sometimes, if you're lucky, you can
stick jconsole on there and figure out at least a general idea of what
is going on, or reproduce the problem by running a test, a test class,
or a test module in isolation with debugging turned on. Sometimes
you're not so lucky, or sometimes the hang happens in the manualmode
test suite where you have to attach a debugger 9,000 times only to find
out that the hang doesn't happen when you do that.
I think we should introduce a new build profile which activates the
remote debugging port, but with suspend=n. This would allow entire full
test suite runs to be done while allowing debugger to be attached for
exploratory surgery in the event that something goes wrong. While it's
possible that having debugging activated might actually prevent the hang
you care about, at least there's a chance that something can be done.
If you review a PR and it’s good, please use the Git Hub review feature to say so instead of just leaving a comment. That makes the fact that someone has approved it visible at a glance in the PR queue which is nice and saves opening the issue and scrolling through comments, CI run reports etc.
When you look at the files of the PR, e.g. , in the top right there is the green “Review Changes” button. Click it, select Approve, add a comment if you like, and hit Submit.
Manager, Senior Principal Software Engineer
JBoss by Red Hat
as you may have noticed, Maven 3.5.0 has been released recently.
While having a colored console output is nice `mvn clean install
-DskipTests` works, are there any issues/reasons known already why Maven
3.5.0 should not be used for building WildFly & Co.?
Going through the relnotes  I found two potential sources of issues:
(1) Replaced Eclipse Aether with Maven Resolver - this will perhaps
change the resolution in some cases.
(2) Removed the artifact handler for ejb3 - do we use ejb3 packaging in
our code at all?