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
7 years, 3 months
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.
7 years, 9 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
7 years, 12 months
Project Jigsaw: The module system was integrated into JDK 9 and is now available for testing in early-access, build 111.
by Rory O'Donnell
Hi Jason/Tomaz,
Project Jigsaw <http://openjdk.java.net/projects/jigsaw/> is an enormous
effort, encompassing six JEPs
<http://openjdk.java.net/projects/jigsaw/#jeps> implemented by dozens of
engineers over many years.
So far we’ve defined a modular structure for the JDK (JEP 200
<http://openjdk.java.net/jeps/200>), reorganized the source code
according to that structure
(JEP 201 <http://openjdk.java.net/jeps/201>), and restructured the JDK
and JRE run-time images to support modules (JEP 220
<http://openjdk.java.net/jeps/220>). The last major component,
the module system itself (JSR 376
<http://openjdk.java.net/projects/jigsaw/spec/> and JEP 261
<http://openjdk.java.net/jeps/261>), was integrated into JDK 9 earlier
this week and is now available for testing
in early-access build 111 - here. <http://jdk9.java.net/download>
More information on Mark Reinhold's blog [1]
Rgds, Rory
Project Jigsaw <http://openjdk.java.net/projects/jigsaw/> is an enormous
effort, encompassing six JEPs
<http://openjdk.java.net/projects/jigsaw/#jeps> implemented by dozens of
engineers over many years. So far we’ve defined a modular structure for
the JDK (JEP 200 <http://openjdk.java.net/jeps/200>), reorganized the
source code according to that structure (JEP 201
<http://openjdk.java.net/jeps/201>), and restructured the JDK and JRE
run-time images to support modules (JEP 220
<http://openjdk.java.net/jeps/220>). The last major component, the
module system itself (JSR 376
<http://openjdk.java.net/projects/jigsaw/spec/> and JEP 261
<http://openjdk.java.net/jeps/261>), was integrated into JDK 9
<http://openjdk.java.net/projects/jdk9> earlier this week and is now
available for testing in early-access build 111
<http://jdk9.java.net/download>.
[1] http://mreinhold.org/blog/jigsaw-module-system
Project Jigsaw <http://openjdk.java.net/projects/jigsaw/> is an enormous
effort, encompassing six JEPs
<http://openjdk.java.net/projects/jigsaw/#jeps> implemented by dozens of
engineers over many years. So far we’ve defined a modular structure for
the JDK (JEP 200 <http://openjdk.java.net/jeps/200>), reorganized the
source code according to that structure (JEP 201
<http://openjdk.java.net/jeps/201>), and restructured the JDK and JRE
run-time images to support modules (JEP 220
<http://openjdk.java.net/jeps/220>). The last major component, the
module system itself (JSR 376
<http://openjdk.java.net/projects/jigsaw/spec/> and JEP 261
<http://openjdk.java.net/jeps/261>), was integrated into JDK 9
<http://openjdk.java.net/projects/jdk9> earlier this week and is now
available for testing in early-access build 111
<http://jdk9.java.net/download>.
Project Jigsaw <http://openjdk.java.net/projects/jigsaw/> is an enormous
effort, encompassing six JEPs
<http://openjdk.java.net/projects/jigsaw/#jeps> implemented by dozens of
engineers over many years. So far we’ve defined a modular structure for
the JDK (JEP 200 <http://openjdk.java.net/jeps/200>), reorganized the
source code according to that structure (JEP 201
<http://openjdk.java.net/jeps/201>), and restructured the JDK and JRE
run-time images to support modules (JEP 220
<http://openjdk.java.net/jeps/220>). The last major component, the
module system itself (JSR 376
<http://openjdk.java.net/projects/jigsaw/spec/> and JEP 261
<http://openjdk.java.net/jeps/261>), was integrated into JDK 9
<http://openjdk.java.net/projects/jdk9> earlier this week and is now
available for testing in early-access build 111
<http://jdk9.java.net/download>.
--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA, Dublin,Ireland
8 years
How to do remote SLSB via http:remoting through mod_cluster?
by sgao
We have multiple wildfly 10 instances running SLSB and web application. We
put a mod_cluster httpd (1.3.1) as a front end load balancer. We use http
protocol instead of AJP.
Web load balancing works well and we can use env.put(Context.PROVIDER_URL,
"http-remoting://node1:8080,http-remoting://node2:8080,http-remoting://node3:8080")
for SLSB remote access.
However, we want to expose only one http port (mod_cluster port) externally
which mean both web access and EJB remote access have to go through the
httpd port. I want to know is it possible to do EJB remote access through
mod_cluster? If yes, how to configure mod_cluster to map http-remoting
request to wildfly? Or mod_cluster only allows web access and we have to
use env.put(Context.PROVIDER_URL,
"http-remoting://node1:8080,http-remoting://node2:8080,http-remoting://node3:8080")
for SLSB remote access?
thanks
--
View this message in context: http://wildfly-development.1055759.n5.nabble.com/How-to-do-remote-SLSB-vi...
Sent from the WildFly Development mailing list archive at Nabble.com.
8 years
server-state / host-state attributes
by Ken Wills
This is an older issue that I looked at last week. The fix is mostly
trivial, but the associated naming wasn't obvious.
https://issues.jboss.org/browse/WFCORE-43
As a result of the discussion, we're leaning towards:
runtime-configuration-state: {STARTING, OK, STOPPING, RELOAD_REQUIRED,
RESTART_REQUIRED}
host-state and server-state will be preserved for compatability, with the
new OK state mapped back to RUNNING.
Thoughts / comments?
Ken
8 years, 1 month
Injecting ManagedExecutorService results in NPE
by Ingo Weiss
Hi,
I was testing injecting the default ManagedExecutorService on WF10 and
it returns a NullPointerException if I don't do a lookup.
These result in a NPE:
@Resource
private ManagedExecutorService executorService;
@Resource(lookup = "java:jboss/ee/concurrency/executor/default")
private ManagedExecutorService executorService;
But this works:
private ManagedExecutorService executorService =
InitialContext.doLookup("java:jboss/ee/concurrency/executor/default");
I didn't change any configurations on WF so far. Ideas?
Cheers
--
Ingo Weiss
8 years, 1 month
