I'm upgrading wildfly-core/threads subsystem to 1.2 for WFLY-1878 (https://issues.jboss.org/browse/WFLY-1878).
This will impact connectors (jca), ejb3 and batch subsystems.
Since ejb3 and jca 3.0 are not released I'm just updating their schemas to use the 1.2 from threads.
I propose also to upgrade batch from 1.0 to 1.1.
What do you think ?
HI, I noticed the input text to filter properties in "Runtime - Server
Status - Environment" is gone from wildfly 8.1 and latest 9 alpha3.
Is there any reason to remove it ?
It was of great help to filter custom properties.
As it is today user must navigate and visually search for the property.
I’m looking to contribute to WildFly in some way. I’d appreciate any assistance getting started or tossing simple bugs my way to assist in learning the project’s architecture.
What I’ve done so far:
- Cloned and pulled down the source from GitHub
- Built via the command line (which worked like a charm)
- Attempted to import the project into Eclipse, but there are a 33k+ build errors due to unresolved dependencies. I’d appreciate assistance configuring Eclipse correctly.
A little bit about me:
- At my day job I develop Java web applications, integrating with other C# and Java apps via SOAP web services and an AQ based ESB. (Unfortunately, we’re locked in to Weblogic through an enterprise buy).
- I’m on a Mac with both Windows and Linux VMs available, and don’t mind working on Mac specific issues.
- I have 10-15 hours a week to help, mostly on nights and weekends.
there have been lots of questions about end results of new build, mostly
all related to missing "jar" files in build distribution.
New build plugin now enables us to produce "slim" distribution of WildFly
which does not include jar files in module directory
but rather user jboss-modules feature to load resources from maven.
This slim/full distribution can be controlled in server-build.xml, which is
config file for build plugin, by *copy-module-artifacts* flag.
By default in current build we have different settings for different
modules / builds
- build - produces slim distribution of whole server, which is used for
- web-build - produces "web" slim distribution
- dist - produces full inflated distribution with all jars in modules
and in wildfly-core, we have
- core-build - which produces inflated distribution, but will be switched
back to slim after MODULES-194 <https://issues.jboss.org/browse/MODULES-194>
So in short, if you need full distribution with all jars or slim distro
doesn't work for you (WFLY-3596 <https://issues.jboss.org/browse/WFLY-3596>)
either use build that you can find in "dist/target" or change config flag
(just don't commit it back)
Also in similar spirit if you need zip/tar.gz distribution, then just run
build with -Drelease
and you will get zip/tar.gz in dist/target
When using current WildFly build from sources I see this message after
startup is complete:
24.07. 21:12:26,131 INFO [org.jboss.as#done] WFLYSRV0025: WildFly
1.0.0.Alpha3 "Kenny" started in 28469ms - Started 374 of 500 services
(179 services are lazy, passive or on-demand)
Two things I suppose to be changed:
1. version is now the version of the underlying core, but version of the
server should also be shown, or not? May be something like "WildFly
9.0.0-Alpha-SNAPSHOT based on WildFly Core 1.0.0.Alpha3" ?
2. the nickname "Kenny" already was used for WildFly 8.x. Time to create
a new one for 9.0.x, or?
I sent below preview to TheCore. But I'd like to give status and get
development feedback from wildfly-dev.
* The current implementation only pulls Keycloak modules into WildFly
Full. WildFly Core only needs Keycloak at compile time.
* You can still use Keycloak with wf-core, but you need to install the
* The current implementation may change a great deal based on Elytron.
I'd like to discuss with someone from that team.
* Thanks to Juca Krohling, who has been preparing integration tests for
* If you follow the setup directions in the preview, you see that the
last step is to unzip some stuff into WildFly. The zip file contains
the Keycloak auth server, a standalone-keycloak.xml file, and an initial
Keycloak database configured for Web Console. I'm wondering if one or
more of these items should ship with WildFly Full? If not, how do we
make it as easy as possible to get Keycloak up and running?
To merge this, we have to wait on two releases. First is a new Keycloak
release, which should be in the next two weeks. After that, I can do a
PR against WildFly Core. After waiting for a WildFly Core release, I
can do a PR against WildFly Full.
The waiting is OK as long as it doesn't drag out too much. I'm hoping
the WildFly Core releases are indeed very frequent.
-------- Original Message --------
Subject: Preview: Keycloak-secured Web Console in WildFly 9
Date: Thu, 24 Jul 2014 15:36:50 -0400
From: Stan Silvert <ssilvert(a)redhat.com>
If you want to see the Web Console secured by Keycloak, follow these
quick and easy instructions. Setup takes about 5 minutes.
Once you are done, you can see
* Web Console using Keycloak login.
* Single Signon between Web Console and Keycloak Admin
* Single Log Out
* Add/Remove Web Console users from Keycloak
* Manage RBAC roles for Web Console users from Keycloak
* Lots of other cool Keycloak features
For WildFly 9 (not 8.2) I propose that we change our policy regarding
support for legacy WildFly configuration documents.
Currently we support being able to parse content from any of our
namespaces (core or subsystem) shipped in a final release going back to
I want to change this to limit support to namespaces shipped in AS 7.2.0
or later and EAP 6.1.0 or later.
This cutoff is consistent with what we are doing with mixed-version
support in managed domains.
The goal of this is to reduce the maintenance burden related to legacy
xml parsers. The goal is *not* to reduce the size of the codebase etc.
So, if this proposal carries, please do not go off and delete old stuff
that works just because you can. But, if you find yourself having to
expend energy maintaining one of these old parsers, the policy change
means just dropping it is a valid alternative.
 Configuration documents meaning standalone/domain/host.xml, not
stuff like deployment descriptors.
Senior Principal Software Engineer
JBoss by Red Hat
I’ve got the chained transformers mostly working in its own tests, but have some issues to iron out when using them for real, which is not picked up by the tests I wrote. Currently I am trying to convert the jmx subsystem, and think I will also do the other ones in wildfly-core (remoting and logging).
Since we have disabled transformer testing against WildFly 8, and AS 7.1.x, there isn’t actually much of a chain to test at the moment. To get better coverage of what I have done in real subsystem scenarios, I would like to temporarily reinstate the test controller for 7.1.x, and to use a system property to enable running of tests against 7.1.x and WildFly 8 unless someone has some strong objections. If people start converting to use chained transformers, since the 7.1.x tests already exist, I think this will be valuable validation of what they are doing.