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
*JDK 9 Early Access* build 170 is available at the new location : -
A summary of all the changes in this build are listed here
Changes which were introduced since the last availability email that may
be of interest :
* b168 - JDK-8175814: Update default HttpClient protocol version and
optional request version
o related to JEP 110 : HTTP/2 Client.
* b169 - JDK-8178380 : Module system implementation refresh (5/2017)
o changes in command line options
* b170 - JDK-8177153 : LambdaMetafactory has default
o release note: JDK-8180035
*New Proposal - Mark Reinhold has asked for comments on the jigsaw-dev
mailing list *
* Proposal: Allow illegal reflective access by default in JDK 9
In short, the existing "big kill switch" of the `--permit-illegal-access`
option  will become the default behavior of the JDK 9 run-time system,
though without as many warnings. The current behavior of JDK 9, in which
illegal reflective-access operations from code on the class path are not
permitted, will become the default in a future release. Nothing will
change at compile time.
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland
When JIRA was being screwy on Friday I used the time to investigate an idea
I have had for a while about improving our boot time performance. According
to Yourkit the majority of our time is spent in class loading. It seems
very unlikely that we will be able to reduce the number of classes we load
on boot (or at the very least it would be a massive amount of work) so I
investigated a different approach.
I modified ModuleClassLoader to spit out the name and module of every class
that is loaded at boot time, and stored this in a properties file. I then
created a simple Service that starts immediately that uses two threads to
eagerly load every class on this list (I used two threads because that
seemed to work well on my laptop, I think Runtime.availableProcessors()/4
is probably the best amount, but that assumption would need to be tested on
The idea behind this is that we know the classes will be used at some
point, and we generally do not fully utilise all CPU's during boot, so we
can use the unused CPU to pre load these classes so they are ready when
they are actually required.
Using this approach I saw the boot time for standalone.xml drop from ~2.9s
to ~2.3s on my laptop. The (super hacky) code I used to perform this test
I think these initial results are encouraging, and it is a big enough gain
that I think it is worth investigating further.
Firstly it would be great if I could get others to try it out and see if
they see similar gains to boot time, it may be that the gain is very system
Secondly if we do decide to do this there are two approach that we can use
that I can see:
1) A hard coded list of class names that we generate before a release
(basically what the hack already does), this is simplest, but does add a
little bit of additional work to the release process (although if it is
missed it would be no big deal, as ClassNotFoundException's would be
suppressed, and if a few classes are missing the performance impact is
negligible as long as the majority of the list is correct).
2) Generate the list dynamically on first boot, and store it in the temp
directory. This would require the addition of a hook into JBoss Modules to
generate the list, but is the approach I would prefer (as first boot is
always a bit slower anyway).
I'm trying to provision a server with the
wildfly-server-provisioning-maven-plugin. The server needs some modules
defined in the core-feature-pack excluded, so I put up excludes in the
dependency management of the pom. However all modules seem to be
included regardless of the projects dependency management.
Is server provisioning ignoring dependency management? If so, I think it
is a bug.
If not, then how should it be done?
We have a number of PRs working there way through the queues now with
the latest component upgrades / backports from ladybird to upstream but
from this point on all pull requests should be sent directly upstream
instead of going via the ladybird branches.
We still have some PRs against the incubator which we will continue to
merge and port over so those don't need to be resubmitted.
We will keep the ladybird branches up to date with upstream in case we
need to use them again but for the last week or so the PRs coming
through have required less coordination so we should be able to handle
I have a stupid question and two not-so-stupid questions.
1. I think I know the answer but I really just need confirmation.
Suppose I have this defined in standalone.xml:
<driver name="h2" module="com.h2database.h2">
Notice it defines the XA datasource class.
I can share this with both a non-XA <data-source> and a XA <xa-data-source>, correct? So this is OK:
That's the stupid question.
2. Here a second question - what is the purpose of both "driver-xa-datasource-class-name" and "xa-datasource-class". The weird thing is the XML in standalone.xml uses "xa-datasource-class" but that seems to be the value of the attribute "driver-xa-datasource-class-name" - what is this xa-datasource-class ATTRIBUTE?
The docs are not clear here: https://wildscribe.github.io/Wildfly/10.0.0.Final/subsystem/datasources/j...
where it says:
* driver-xa-datasource-class-name The fully qualified class name of the javax.sql.XADataSource implementation module-slot The slot of the module from which the driver was loaded, if it was loaded from the module path profile Domain Profile in which driver is defined. Null in case of standalone server
* xa-datasource-class XA datasource class
3. Third question - what is this "jdbc-compliant" attribute used for? The docs don't indicate what it would actually be used for:
* jdbc-compliant - Whether or not the driver is JDBC compliant
If I am defining a JDBC driver, wouldn't you think it is JDBC compliant? :-)
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?