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, 11 months
10.1.0.CR1 is available! Try it out!
by Jason Greene
Some of you may have noticed that 10.1.0.CR1 was released yesterday:
http://wildfly.org/downloads/
Please give it a try and report any major issues. Provided nothing critical comes up, we will release Final next week.
Major new features include:
- Out of the box HTTP/2 support
- TLS cert auto-generation
- Load-balancing profile is now in our default domain.xml config
- Support for clustering node discovery on Azure (jgroups AZURE_PING)
Overall there are 308 issues resolved in this release:
https://issues.jboss.org/secure/ReleaseNote.jspa?version=12329499&styleNa...
Thanks again!
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
8 years, 4 months
Pretty-printing XML validation errors
by Toby Crawley
I've done some work to pretty-print XML validation errors that occur
when parsing (standalone|domain|host).xml, and wanted to get some
feedback on what I have so far to see if:
1) there is interest in seeing this completed
2) the current approach is the best way to integrate with WildFly
3) this same approach could be used to pretty-print issues with other
xml parsed by WildFly (web.xml, jboss-deployment-structure.xml,
etc)
# Background
Inspired by error reporting in the Elm language[1] and improvements in
configuration feedback for Clojure tooling[2], I looked at what it
would take to provide better feedback when parsing XML configuration.
My goals were:
* Give users clear feedback that can be used to correct the
configuration error without the user having to context-switch to
documentation, and, in most cases, enable the user to quickly
identify and understand the issue before looking away from the
validation output, by:
* Showing (instead of telling) where in the XML the error occurred
* Providing richer feedback than the native validation error
provides (detect potential misspellings, provide alternate
locations, etc)
* Showing documentation for the element/attribute where possible
(pulled from the XSD)
* Use what we already produce (XSDs), without having to create
additional context-specific schema.
I've partially implemented a library (vdx)[3] that, given a validation
error, the source document, and the relevant schemas, generates and
prints a friendly error message. I've also made minimal changes to
WildFly to report validation errors to vdx (see below).
# Examples
Below is some examples of the current startup output from WildFly when
a validation error occurs:
## Detecting a misspelled attribute
13:18:03,798 INFO [org.jboss.modules] (main) JBoss Modules version 1.5.2.Final
13:18:03,949 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final
13:18:04,010 INFO [org.jboss.as] (MSC service thread 1-6)
WFLYSRV0049: WildFly Core 2.2.0.CR5-SNAPSHOT "Kenny" starting
13:18:04,751 ERROR [org.jboss.as.controller] (Controller Boot Thread)
====================== Validation Error in standalone.xml ======================
28: <extension module="org.wildfly.extension.request-controller"/>
29: <extension module="org.wildfly.extension.security.manager"/>
30: <extension modue="org.wildfly.extension.undertow"/>
^ 'modue' isn't an allowed attribute for the
'extension' element
31: </extensions>
32: <management>
33: <security-realms>
Did you mean 'module'?
================================================================================
13:18:04,753 ERROR [org.jboss.as.server] (Controller Boot Thread)
WFLYSRV0055: Caught exception during boot:
org.jboss.as.controller.persistence.ConfigurationPersistenceException:
WFLYCTL0085: Failed to parse configuration
at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:175)
at org.jboss.as.server.ServerService.boot(ServerService.java:357)
at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:299)
at java.lang.Thread.run(Thread.java:745)
13:18:04,754 FATAL [org.jboss.as.server] (Controller Boot Thread)
WFLYSRV0056: Server boot has failed in an unrecoverable manner;
exiting. See previous messages for details.
13:18:04,762 INFO [org.jboss.as] (MSC service thread 1-3)
WFLYSRV0050: WildFly Core 2.2.0.CR5-SNAPSHOT "Kenny" stopped in 4ms
## Detecting a misplaced attribute
...
14:32:23,842 ERROR [org.jboss.as.controller] (Controller Boot Thread)
====================== Validation Error in standalone.xml ======================
89: </console-handler>
90: <periodic-rotating-file-handler name="FILE" autoflush="true"
91: category="WARN">
^ 'category' isn't an
allowed attribute for the 'periodic-rotating-file-handler' element
92: <formatter>
93: <named-formatter name="PATTERN"/>
94: </formatter>
'category' is allowed on elements: subsystem > logger, subsystem >
logging-profiles > logging-profile > logger
Did you intend to put it on one of those elements?
================================================================================
...
## Detecting a misplaced element
...
10:54:27,359 ERROR [org.jboss.as.controller] (Controller Boot Thread)
====================== Validation Error in standalone.xml ======================
81: </management>
82: <profile>
83: <extension/>
^ 'extension' isn't an allowed element here
84: <subsystem xmlns="urn:jboss:domain:logging:3.0">
85: <console-handler name="CONSOLE">
86: <level name="INFO"/>
'extension' is allowed in elements: domain > extensions, domain >
host-excludes > host-exclude > excluded-extensions, host > extensions,
host > servers > server > extensions, server > extensions
Did you intend to put it in one of those elements?
================================================================================
...
# Changes to WildFly
To support this, I've made some small changes changes to
wildfly-core[4], but anticipate more before this is complete.
The current changes are:
* Modifications to ParseUtils to wrap the XMLStreamExceptions with
an exception that can convey more context to vdx
* Modifications to XmlConfigurationPersistor to:
* catch the wrapped exception
* see if ${jboss.home.dir}/docs/schema/ is available. If so,
pretty-print the error. If not, throw the wrapped exception
(which is the behavior before my changes).
# Current issues
* Only the first validation issue is reported, but this is
unavoidable, since the subsystem parsers throw on the first error
encountered
* This uses xmlschema-walker from Apache XmlSchema[5], which has a
couple of bugs that will need to be fixed and released (or forked)
* Only errors reported by throwing Exceptions returned by ParseUtils
are pretty-printed. Exceptions that come from within STAX reader
aren't yet handled (for example, a misplaced element in the logging
parser causes reader.handleAny() to be called[6], which triggers an
unwrapped exception)
* vdx itself is far from complete[7] - that work is pending the
outcome of this discussion
# Next steps
As I said above, the first question to answer is: is this an
interesting feature that you would like to see completed? If so, I'm
willing to continue working on this, and would be happy to discuss
here or on JIRA/HipChat as appropriate.
[1]: http://elm-lang.org/blog/compilers-as-assistants
[2]: http://rigsomelight.com/2016/05/17/good-configuration-feedback-is-essenti...
[3]: https://github.com/projectodd/vdx
[4]: https://github.com/tobias/wildfly-core/commit/b4d03897a6ea1b8c786d983da3b...
[5]: https://ws.apache.org/xmlschema/
[6]: https://github.com/wildfly/wildfly-core/blob/2.x/logging/src/main/java/or...
[7]: https://github.com/projectodd/vdx/issues
8 years, 4 months
Specifying order of new JGroups Protocol
by Michael Irwin
I'm adding a JGroup stack protocol using this command:
/subsystem=jgroups/stack=tcp/protocol=JDBC_PING:add()
But, the new protocol is added to the end of the list of protocols. And,
since protocol order matters, how do I add the protocol to the front of the
list? And, I'd prefer to do it without tweaking the XML directly. Any
pointers?
--
Michael Irwin
8 years, 4 months
One Doc to Rule Them All
by James Perkins
I've been reading the WildFly documentation [1] quite a bit lately and
noticing a lot of issues. Sometimes it references WildFly 8 in the WildFly
10 (or 9) documentation. Sometimes it references JBoss AS 7. Links take you
to old documentation, e.g. a WFLY10 doc takes you to a page for WFLY8.
Sometimes documentation is just plain out of date referencing behavior that
has possibly been removed or replaced by something better.
This has happened because we keep copying the documentation over each time
we have a new version. Overall this makes sense as a lot of it doesn't need
to be changed. However it leaves reading the documentation confusing.
Reading documentation for WildFly 10 and seeing WildFly 8 in the text with
a link for AS72 isn't very user friendly as I'm sure we can all agree.
There's a few different ways we could go with this.
Approach 1:
One, probably the easiest, is to use a single confluence project. We'd need
to remove the version numbers from the text, which I think we should do
anyway. Instead of referencing WildFly 10 we just reference it as WildFly.
An issue I can think of with this approach is some how annotating or
referencing that parts of the documentation only work with ${version}. For
example new features would have to be noted they only work with ${version}+.
Approach 2:
Essentially he same as approach 1 only do allow different Confluence
projects for the different Java EE target version. So WIldFly 8, 9 and 10
would all be documented under something like WFLYEE7.
Approach 3
Switch to using something like asciidoc which can use variables and
generate links to the correct content. While this approach is probably
takes the most work up front, it seems like like it would be easier to
maintain between releases.
Any other suggestions are welcome.
[1]: https://docs.jboss.org/author/display/WFLY10/Documentation
--
James R. Perkins
JBoss by Red Hat
8 years, 4 months
Open Logging Discussion
by James Perkins
I haven't put much thought into a solution for this, but I want to put it
out there to start a discussion.
There is a new feature request [1] to provide access logs for EJB's. We
currently have at least 3 different places to configure different types of
logging.
1. The logging subsystem
2. Management access logging
3. Web access logging
All 3 of these reside under different resources and have different
configuration options. Which is really understandable since they are all
quite different in what they are trying to do.
However since we may be adding a forth now I'm thinking we should start to
consider some other options for these. Possibly some kind of centralized
location to configure logging in or something that all log messages pass
through to ensure they're routed correctly (yes I realize this is
essentially a log manager).
As it is now we do have the ability to download logs from a server. Audit
logs, web access logs, process controller logs and host controller logs can
not be downloaded or viewed from the log viewer on the web console. I again
assume user would like access to all log files or some way to view all log
messages.
I'm mainly bringing this up because I'm guessing for things like WildFly
Swarm and OpenShift log files aren't all that useful as the user has no
access to them. Pushing log messages to some kind of log aggregation server
in these cases is often useful in these situations.
At a minimum I do think we need to provide a way to download or view all
log files. In managed domains this is probably useful as well as
environments like docker.
Anyway I'm just looking to plant a seed at this point and see what others
think.
[1]: https://issues.jboss.org/browse/WFLY-6892
--
James R. Perkins
JBoss by Red Hat
8 years, 4 months
Re: [wildfly-dev] Pretty-printing XML validation errors
by Aleksandar Kostadinov
Heiko W.Rupp wrote on 07/27/16 14:57:
> On 21 Jul 2016, at 0:49, Aleksandar Kostadinov wrote:
>>
>> I should have explained better. The config is saved on container. But
>> container being stateless loses changes on restart. At least for
>
> Yeah, that is a bit of an issue. One needs to mount the whole config
> dir to an external volume(*) and then on container creation populate it
> with a default configuration.
> Or externalize the changes of the standard config and apply it each
> time at container start (docker run, not docker start).
OpenShift does support persistent volumes. Thinking about auto-scale I'm
not sure that would help a lot though.
I'm wondering whether domain mode can help - having domain node(s) with
persistent storage configuration for management. Then the worker nodes
would read config from domain.
I suspect though most people would not want to waste resources for
non-worker nodes and would expect to have things working OOB in some
simple manner. Perhaps wildfly may support committing configuration
changes in whatever format to some external system (git, file server,
whatever), then read it from there.
e.g. if wildfly can commit any and all configuration changes to git, an
OpenShift deployment config can trigger redeploy based on the noticed
changes automatically (or user can trigger manually).
btw it would help if Wildfly records only changes from defaults (not all
configuration files). In this way migrating between versions and
changing defaults might work much smoother.
8 years, 4 months
How to work with an optional module dependency
by Martin Kouba
Hi all,
the Weld/CDI team is working on SWARM-568 [1] - to slim the module
dependencies of the Weld subsystem. We will need to modify Weld
subsystem so that some dependencies (EJB, JPA, etc.) are optional. And
this brings additional complexity in the code.
I wonder whether there are any
tips/recommendations/guidelines/examples/etc how to work with an
optional module dependency?
More specifically, what is the best approach to detect a module
availability? In Java SE one would usually take the ClassLoader and try
to load some specific class...
Also what is the safe and reliable way of "handling" the code which
depends on an optional module. It seems a JVM impl may choose to link
everything up front. So I think the only way is to create a separate
class containing all the logic and call this class via reflection.
Thanks a lot,
Martin
[1]
https://issues.jboss.org/browse/SWARM-568
--
Martin Kouba
Software Engineer
Red Hat, Czech Republic
8 years, 4 months
Transactions requirement during the graceful shutdown
by Gytis Trikleris
Hello,
I’m in the process of writing an analysis document for https://issues.jboss.org/browse/EAP7-459 and need your input. Specifically I’m looking for the list of subsystems which might need to create new transactions during the graceful shutdown. Normally new transactions would not be allowed then, but this might stop other subsystems to shutdown properly. If such subsystems exist we’ll need to think of the way how to filter out their requests (e.g. providing SPI for them).
Thanks,
Gytis
8 years, 5 months
