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
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, 5 months
update on WildFly NoSQL prototype integration...
by Scott Marlow
Hi,
Below is an update on the WildFly NoSQL integration project. The goal
is for deployed applications to have access to NoSQL databases (via
Hibernate OGM or native APIs). Items 1-4, should be finished in our
first pass, with as much of the others items as we can do as well.
1. connection management will deal with obtaining NoSQL connections for
application use.
- borrow/share Hibernate OGM connection configuration setup code
- authentication integration
- support transport level security
2. CDI programming simplifications will make it easy to inject NoSQL
data into your application classes.
- https://github.com/antoinesd/javaee-nosql is initial idea
3. You will easily get a native NoSQL connection from the specified
NoSQL profile and use the native NOSQL (Cassandra/MongoDB/other) API in
your application.
4. You will also be able to easily use Hibernate OGM with the defined
NoSQL profiles (exactly how is TBD but will be awesome :-).
- Hibernate OGM static module is included.
- need to align with OGM dependencies (e.g. Hibernate ORM + other
dependencies).
- as mentioned above, OGM already has some connection setup code,
which might be good to share for WildFly + standalone NoSQL use.
- once WildFly has a common NoSQLSource (not a DataSource) that OGM
can use, OGM will be enhanced to use it.
5. How best for the WildFly NoSQL subsystem to be optional?
- Is it enough to not run the wildfly/testsuite/nosql tests by default?
- Or do we need to start a separate https://github.com/wildfly/nosql
project for the NoSQL subsystems?
6. transaction enlistment
7. compensating transactions
8. runtime application monitoring
9. How soon can we make an evaluation distribution available for use on
OpenStack/OpenShift?
- Would be great if we could do some load testing with all NoSQL
components.
- Would be great if we could enable others to also test.
10. Are there any problems with our WildFly NoSQL subsystem injecting
MongoDatabase connections via:
@Resource(lookup = "java:jboss/mongodb/test") MongoDatabase db;
- No @Resource support expected for standalone Java, TBD is whether a
runtime library can be used.
- Any problems expected on other EE application servers if this
approach becomes popular?
11. WIP topic branch is at
https://github.com/scottmarlow/wildfly/tree/nosql-dev9. Note that every
once in a while, commits are squashed and pushed to nosql-devN+1.
12. Add proper unit tests
- multi-threaded NoSQL access to show that works at all.
- use NoSQL from different EE components (e.g. JAX-RS).
- other use cases that represent how NoSQL could be used from WildFly.
Feedback/help is welcome!
Thanks,
Scott
8 years, 5 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.
8 years, 5 months
Capabilities and capability-reference not registered in github
by Claudio Miranda
Hi, looking at current wildfly capabilities, I see the following
org.wildfly.batch.configuration
org.wildfly.batch.job.repository
org.wildfly.batch.thread.pool
org.wildfly.clustering.infinispan.cache-container.cache.store.jdbc.data-source
org.wildfly.clustering.infinispan.cache-container.cache.store.remote.outbound-socket-binding
org.wildfly.clustering.protocol.socket-binding
org.wildfly.clustering.singleton.default-policy
org.wildfly.clustering.singleton.policy
org.wildfly.clustering.singleton.singleton-policy.election-policy.socket-binding-preference
org.wildfly.clustering.transport.diagnostics-socket-binding
org.wildfly.data-source
org.wildfly.domain.profile
org.wildfly.domain.server-config
org.wildfly.domain.server-group
org.wildfly.domain.socket-binding-group
org.wildfly.extension.sar-deployment
org.wildfly.extension.undertow.handler
org.wildfly.io.buffer-pool
org.wildfly.io.max-threads
org.wildfly.io.worker
org.wildfly.jsr77
org.wildfly.management.jmx
org.wildfly.management.jmx.remote
org.wildfly.management.native-interface
org.wildfly.network.interface
org.wildfly.network.outbound-socket-binding
org.wildfly.network.socket-binding
org.wildfly.remoting.endpoint
org.wildfly.request-controller
org.wildfly.security
org.wildfly.transactions
org.wildfly.undertow.listener
But they differ from the https://github.com/wildfly/wildfly-capabilities/
Do you plan to update the git repo ?
--
Claudio Miranda
claudio(a)claudius.com.br
http://www.claudius.com.br
8 years, 6 months
JBREM000200 error: XNI0000804: Received an invalid message length of 1195725856
by Marlow, Andrew
Hello everyone,
This is an appeal for help to resolve the error JBREM000200 that I get when a process connects to wildfly to do some JMS work. Details follow:-
I am trying to switch from JBoss-as-7.1.1.Final to Wildfly 9.0.1.Final. My project runs on Microsoft Windows and Red Hat Linux (RHEL 5.11). I am using java jdk 1.8.0_60. The switch to wildfly worked fine on Windows, once I found out what the config file changes were, especially the switch from remote port 4777 to undertow http port 8080. However, on linux the wildfly server get an error as soon as one of my processes connects to it. The wildfly log is not very busy. Wildfly starts with not much logged then I get a one line error report for every connection attempt:
2016-06-29 15:09:09,555 ERROR [org.jboss.remoting.remote.connection] (default I/O-6) JBREM000200: Remote connection failed: java.io.IOException: XNIO000804: Received an invalid message length of 1195725856
The log of the process that connects contains a bit more detail:
Error: NamingException detected during EndPointFactory JMS Server queue initialisation: Failed to connect to any server. Servers tried: [http-remoting://<myIpAddress>:8180 (java.io.EOFException: XNIO000812: Connection closed unexpectedly)] : Failed to connect to any server. Servers tried: [http-remoting://<myIpAddress>:8180 (java.io.EOFException: XNIO000812: Connection closed unexpectedly)] Cause unknown. : Stack trace: javax.naming.CommunicationException: Failed to connect to any server. Servers tried: [http-remoting://<myIpAddress>:8180 (java.io.EOFException: XNIO000812: Connection closed unexpectedly)]
at org.jboss.naming.remote.client.HaRemoteNamingStore.failOverSequence(HaRemoteNamingStore.java:244)
at org.jboss.naming.remote.client.HaRemoteNamingStore.namingStore(HaRemoteNamingStore.java:149)
at org.jboss.naming.remote.client.HaRemoteNamingStore.namingOperation(HaRemoteNamingStore.java:130)
at org.jboss.naming.remote.client.HaRemoteNamingStore.lookup(HaRemoteNamingStore.java:272)
at org.jboss.naming.remote.client.RemoteContext.lookupInternal(RemoteContext.java:104)
at org.jboss.naming.remote.client.RemoteContext.lookup(RemoteContext.java:93)
at org.jboss.naming.remote.client.RemoteContext.lookup(RemoteContext.java:146)
at javax.naming.InitialContext.lookup(InitialContext.java:417)
I am using port 8180 because port 8080 is already taken (jenkins).
I have googled for this causes of this error. I found several hits that suggested various "solutions". I tried them all. None of them worked. Here's what I have tried:
* I ensured that no other process was using 8180. Some wildfly users have been in environments where a rogue process was writing to the undertow port. I used netstat in a loop to monitor any process using 8180. It just showed wildfly listening on it until my app made the connection attempt. Then it showed my app as well. No other apps.
* I tried using the port number offset feature. This used different port numbers but the problem remained.
* xml config, disable section security-realm-name="ApplicationRealm". This made no difference.
* In the interfaces section, interface name="public" replace inet-address value=${jboss.bind.address:0.0.0.0} with value = "<myIpAddressAsADottedQuad>". This did make a difference - I lost connectivity completely. This was fixed by me changing localhost in my remoting URL to the ip address as a dotted quad. Then I got the invalid message length error back.
This seems like a very deep mystery to me. It might force me to abandon using wildfly on linux and say that it is only supported on windows. Any help will be much appreciated.
Regards,
Andrew Marlow.
http://www.andrewpetermarlow.co.uk
_____________
The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.
8 years, 6 months
is <server name=""> supposed to be the same as -Djboss.node.name?
by John Mazzitelli
There is some confusion about setting the WildFly node name (at least in the standalone server case).
<tl;dr>
QUESTION: How does one change the server's cluster node name (say, for the JGroups configuration). I thought both would be equivalent (either setting <server name="a"> or setting -Djboss.node.name=a) but that does not seem to be the case.
</tl;dr>
Suppose I start WildFly via standalone.sh (with its stock out of box standalone.xml) but with the command line option:
-Djboss.node.name=wotgorilla
When I do this, I see the node-name (in the server-environment subsystem) set to "wotgorilla" but the server's name is my normal hostname (in this case "mazztower"):
/core-service=server-environment/:read-attribute(name=node-name)
{
"outcome" => "success",
"result" => "wotgorilla"
}
/:read-attribute(name=name)
{
"outcome" => "success",
"result" => "mazztower"
}
OK, but now suppose I edit standalone.xml - in the top-level root element <server> I add the name attribute:
<server name="foobar">
and I start the server WITHOUT any commmand line options (just "standalone.sh"). I see that BOTH "name" and "node-name" match my new server name:
/core-service=server-environment/:read-attribute(name=node-name)
{
"outcome" => "success",
"result" => "foobar"
}
/:read-attribute(name=name)
{
"outcome" => "success",
"result" => "foobar"
}
QUESTION: Why the discrepency? Is this a bug or expected behavior? How does one change the server's cluster node name (say, for the JGroups configuration). I thought both would be equivalent (either setting <server name="a"> or setting jboss.node.name) but that does not seem to be the case.
Thanks,
John Mazz
8 years, 6 months
Early Access builds of JDK 8u112 b01, JDK 9 b124 are available on java.net
by Rory O'Donnell
Hi Jason/Tomaz,
Early Access b124 <https://jdk9.java.net/download/> for JDK 9 is
available on java.net, summary of changes are listed here
<http://www.java.net/download/java/jdk9/changes/jdk-9+120.html>.
Early Access b123 <https://jdk9.java.net/jigsaw/> (#5178) for JDK 9 with
Project Jigsaw is available on java.net, summary of changes are listed
here
<http://download.java.net/java/jigsaw/archive/123/binaries/jdk-9+123.html>
Early Access b01 <https://jdk8.java.net/download.html> for JDK 8u112 is
available on java.net.
Update to JEP 261 : Module System - email from Mark Reinhold [1]
- The special ALL-DEFAULT module name, which represents the default set
of root modules for use with the -addmods option [2];
- A more thorough explanation of how the built-in class loaders have
changed, how built-in modules are assigned to each loader,
and how these loaders work together to load classes [3]; and
- The reason why Java EE-related modules are no longer resolved by
default [4].
- There are various other minor corrections and clarifications, as can
be seen in the detailed diff [5].
Rgds,Rory
[1]http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-June/008227.html
[2]http://openjdk.java.net/jeps/261#ALL-DEFAULT
[3]http://openjdk.java.net/jeps/261#Class-loaders
[4]http://openjdk.java.net/jeps/261#EE-modules
[5]http://cr.openjdk.java.net/~mr/jigsaw/jeps/updates/261-2016-06-15.html
<http://cr.openjdk.java.net/%7Emr/jigsaw/jeps/updates/261-2016-06-15.html>
--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA, Dublin,Ireland
8 years, 6 months
