Recently there has been some confusion about how subsystems should be distributed, and whether or not they should be part of the WildFly repository.
There are three primary use-cases for distributing a subsystem.
#1 - Inclusion in an official WildFly distribution
#2 - A user installable "add-on distribution" which can be dropped on top of a WildFly Distribution (see [A])
#3 - A separate, independant, customized distribution, with a differing identity. Possibly build but not required as a layer (see [A])
If you are after #1, then the subsystem source code (defined as the portion of code which integrates with the server using the subsystem facilities) MUST be included in the WildFly repo. This is because subsystems heavily impact the stability of the server and our compliance with our strict management compatibility policy, and additionally it allows for us to keep all included subsystems up to date with core infrastructure changes such as capabilities and requirements, and the upcoming elytron security integration. Under this approach, a feature-pack is unlikely to be used, as it would likely just be part of the full feature-pack. It could very well be that we would introduce a different more expansive feature-pack in the future defining a larger distribution foot-print, however, there are currently no plans to do so.
If you are after #2, then you do not want a feature-pack, as feature-packs are just for building custom server distributions. If your use-case is #2 you are by definition not a custom server distribution, but rather a set of modules built the normal maven way.
If you are after #3, then you likely wish to use the feature-pack mechanism to make it easy to produce your custom distribution. This facility would allow you to keep your source repository limited to just the new subsystems you introduce, and pull the rest of the server bits via a maven dep. It is important, that you change the identity of the server (see [A]), such that patches for the official WildFly server are not accidentally installed.
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
Some time ago, John Mazzitelli wrote a blog on how to get a local
ModelControllerClient from within a servlet.
Is there an easier way to do it these days?
I need to read the attributes under /deployment=mydeployment.war/. Is
there an easier way to do that from the WAR than using a
Just a FYI,
In preparation for WildFly 11 I already have bumped the schema versions
and model for numerous parts of WildFly - if you plan to work on any
WildFly 11 changes that would also require a bump of any of these let me
know and I can point you to a branch where the changes have already been
The models bumped so far are: -
- Core Management Model and Schema
- Remoting Subsystem
- Undertow Subsystem
- EJB Subsystem
- Security Subsystem
Currently wildfly-server-provisioning-maven-plugin always generates a full Wildfly distribution. For Keycloak project we have three different cases of provisioning, and it would be great to be able to cover it with a common wildfly provided tool:
1) full server distribution
2) overlay distribution (unzip into existing OOTB Wildfly distribution - your problem if you use unsupported Wildfly version)
3) provision into existing Wildfly server detecting version mismatches, and configuring existing and additional subsystems for Keycloak to run properly.
First one is what’s currently supported, and what we use.
Second one is what we currently hack up by extracting modules directory from (1) - it would support this use case better if wildfly-server-provisioning-maven-plugin could generate 'modules only' for example.
The third one requires a CLI installer tool. I’m not aware that currently there is something for that, and we are loath to develop one from scratch.
Is it realistic to expect 2) and 3) in not so distant future?
I am working on https://issues.jboss.org/browse/WFCORE-761 for a while,
and I am stuck in the case of overlaying files in jar of war of ear.
I want to know that do we support overlay for files in jar of war of
ear? like: xx.ear/yy.war/zz.jar/META-INF/config.properties
DeferredDeploymentOverlayDeploymentUnitProcessor.java are classes to
handle the deployment overlay, but in this case, the jar of war of ear does
not get mounted yet, which leads
method is called, which just prints the error message.
The way to fix it maybe mount the jar(VFS.mountZip) beforehand, but it
is specific to the case of ear/war/jar, and these 2 classes are more
generic(they are in wildfly-core, no ee nor undertow extension), so where
this can be fixed?
JBoss Software Engineer
Hello and Merry Christmas
I have a maven web application, which contains only REST services. This
is a very basic application. The whole app created with Netbeans auto
I have a Debian Wheezy server and when I deploy my war everything is
good, but some hours later REST service is not respond, and I only got
Internal Server Error.
I had to disable my application , after I have to disable Datasource, re
enable datasource, and after that re deploy my program.
33m08:57:20,799 WARN [org.hibernate.engine.jdbc.spi.SqlExceptionHelper]
(default task-3) SQL Error: 0, SQLState: 08S01
[org.hibernate.engine.jdbc.spi.SqlExceptionHelper] (default task-3) The
last packet successfully received from the server was 58,901,043
milliseconds ago. The last packet sent successfully to the server was
58,901,043 milliseconds ago. is longer than the server configured value
of 'wait_timeout'. You should consider either expiring and/or testing
connection validity before use in your application, increasing the
server configured values for client timeouts, or using the Connector/J
connection property 'autoReconnect=true' to avoid this problem.
[0m[31m08:57:20,805 ERROR [org.jboss.as.ejb3.invocation] (default
task-3) JBAS014134: EJB Invocation failed on component PartnerFacadeREST
for method public java.util.List
org.hibernate.exception.JDBCConnectionException: could not extract ResultSet
How can I set the timeout or the autoReconnect?
WildFly seems to use an adapted version of the Unified EL RI which has
the version "3.0.1-b08-jbossorg-1".
Does anyone know what modifications have been made in comparison to
the upstream version and where the repo of this modified version is?