Subsystem Inclusion Policy & Role of Feature Packs & Add-ons
by Jason Greene
Hello Everyone,
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.
Thanks!
[A] https://developer.jboss.org/wiki/LayeredDistributionsAndModulePathOrganiz...
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
8 years
WildFly 11 Model and Schema Version Bumps
by Darran Lofthouse
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
made.
The models bumped so far are: -
- Core Management Model and Schema
- Remoting Subsystem
- Undertow Subsystem
- EJB Subsystem
- Security Subsystem
Regards,
Darran Lofthouse.
8 years, 7 months
Feature pack provisioning
by Marko Strukelj
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?
- marko
8 years, 9 months
Do we support overlay for files in jar of war of ear?
by Lin Gao
Hi,
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
DeploymentOverlayDeploymentUnitProcessor.java[1] and
DeferredDeploymentOverlayDeploymentUnitProcessor.java[2] are classes to
handle the deployment overlay, but in this case, the jar of war of ear does
not get mounted yet, which leads
to DeferredDeploymentOverlayDeploymentUnitProcessor.handleEntryWithFileParent()
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?
[1]
https://github.com/wildfly/wildfly-core/blob/master/server/src/main/java/...
[2]
https://github.com/wildfly/wildfly-core/blob/master/server/src/main/java/...
Best Regards
--
Lin Gao
JBoss Software Engineer
9 years
Internal Server error
by Mester József
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
generate tools.
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.
Log:
33m08:57:20,799 WARN [org.hibernate.engine.jdbc.spi.SqlExceptionHelper]
(default task-3) SQL Error: 0, SQLState: 08S01
[0m[31m08:57:20,800 ERROR
[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
com.joco.nyomtserv2.service.PartnerFacadeREST.findAll():
javax.ejb.EJBException: javax.persistence.PersistenceException:
org.hibernate.exception.JDBCConnectionException: could not extract ResultSet
How can I set the timeout or the autoReconnect?
Thank you.
Joe
9 years, 1 month
Wildfly 10 Release Date
by Bart Van Dosselaer
Hello,
any news on the exact release date of Wildfly 10.0.0.Final?
Thanks,
Bart
9 years, 1 month
Version of Unified EL used in WildFly
by Gunnar Morling
Hi,
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?
Thanks,
--Gunnar
9 years, 1 month
