Is there a single maven BOM artifact I can use to get/build the entire wildfly ee server?
by Eric B
I'm trying to debug some code, and I am often hitting classes in
Wildfly/Undertow/etc in my stack that I don't have the source code for.
I'd love to be able to add a dependency in my pom.xml so that Eclipse will
automatically d/l the sources from maven central for me and add them to my
debugger. I'm looking for an artifact that I'd be able to list something
like:
<dependency>
<artifactId>wildfly</artifactId>
<groupId>org.wildfly</groupId>
<version>10.1.0</version>
<scope>provided</scope>
<type>pom</type>
</dependency>
That would then download all the sources for me, and I'd be in business.
Is there something like this BOM available for wildfly?
Thanks,
Eric
6 years, 8 months
WildFly 12 Plans, EE8, and Move to Quarterly Iterative Releases
by Jason Greene
Hello Everyone,
Release Model Changes
————————————————————-
In order to bring new capabilities to the community quicker, we plan to move to a more iterative time-boxed approach, starting with WildFly 12 (and continuing with 13, 14, etc). By time-boxed, I mean the each release aims to have a fixed and reliable delivery window that approximates a calendar quarter. Since these time-frames are fixed, it’s important that any given feature or improvement not hold up a release. To facilitate this we need to make major changes to our development process. Currently development for any enhancement is merged in chunks, as it progresses from inception to completion. This means to have something worthy of release, we must either block for its completion or roll it back. The latter is often difficult, since at any given moment there are many features under active development, and their respective implementations can become co-dependent. Additionally, its common for component dependencies to start off as Alphas and/or Betas, and we end up needing to wait for those components to hit Final before we can cut the release.
The solution to this problem is to rely more on topic branches, and only merge fully completed work to master. By fully complete, I mean all PRs on master should be fully developed, tested, and documented[1]. Additionally any updated dependencies must only be against Final/GA components.
This has a number of advantages:
A. Master becomes always stable, always releasable. So at any given moment we can decided to cut a release[1]
B. Nightly builds become way more usable, and a great feedback channel (a release starts to have less importance)
C. If a feature takes longer than expected, no big deal, it will be picked up in the next cycle[2]
D. Should anything cause a major regression, not caught in testing it will be easier to revert, since the history will be cleaner
Since in-progress work will need to be based on topic branches, custom jobs on ci.wildfly.org will need to be relied upon instead of the automated CI that happens when you submit a PR (although that’s still important and still staying). Additionally if two changes/improvements are interrelated, then they will need to either share a topic branch, or find a way to construct the work independently (potentially adding and removing a temporary construct until both are merged).
[1] To make it easier to associate documentation with the PR, we are looking to move to an asciidoc based solution instead of confluence like we utilize today.
[2] While this is generally the case, there are some activities we can’t avoid before releasing, such as ensuring a TCK run has completed.
[3] An important aspect of C is that iterations have a short enough cycle, such that the pressure to make a particular iteration is low enough to avoid the urge to try and cram something in, and potentially compromise quality (e.g. no docs etc).
Java EE8
————————
As part of adopting this model, we aim to deliver Java EE8 in incremental chunks. Adding support for specs individually in batches. As an example for WildFly 12, I propose we target Servlet 4, JSON-B, and CDI. Due to unfortunate restrictions in EE certification, we will need to have a separate configuration profile or property to enable these additional APIs until we complete full EE8 certification.
Proposed WildFly 12 Goals [Target Release Date = Feb 28, 2018]
————————————————————————
+ Adopt new release model
+ Java 9 improvements
+ Servlet 4
+ JSON-B (incorporating Yasoon)
+ CDI 2
+ JSF 2.3
+ Metaspace usage improvements
+ early/initial changes to accommodate the new provisioning effort (easy slimming, updates, etc)
Proposed WildFly 13 Goals (Very Tentative) [May 2018]
———————————————————————————-
+ New EE Security Spec
+ Adoption of provisioning
+ JPA 2.2
+ JAX-RS 2.1
+ BV 2.0
+ Agroal inclusion
Just to highlight that with this new model, that these goals I am proposing are not something we would block on, any given item might be deferred to the next release if it’s not quite ready. Let me know if you have any additional major items you are planning to contribute towards 12.
Thanks!
-Jason
6 years, 10 months
JBoss MSC Plans
by Richard Opalka
Hi everyone,
I would like to outline a brief JBoss MSC Plans for Year 2018.
Goals defined below address both:
* Cloud First Effort
- Reduce WildFly memory footprint
- Speed up WildFly boot time
* Potential Migration to MSC 2
MSC Library Goals:
* SHORT TERM GOALS (MSC 1.2.x, 1.3.x)
[1] simplify MSC state machine - deprecate useless MSC internal states
(e.g. REMOVED, WONT_START, WAITING, REMOVING, STOPPING maybe others)
[2] deprecate API exposing MSC internals
(e.g. replace ServiceListener with LifecycleListener)
[3] deprecate MSC Values, Injections & Injectors and provide alternative
API
(alternative API should have same minimalistic memory requirements
like MSC 2)
* LONG TERM GOALS (MSC 1.4.x)
[4] remove deprecated APIs and all deprecated stuff
WildFly MSC Integration Goals:
+ SHORT TERM GOALS (WildFly 12)
* replace ServiceListeners with LifecycleListeners (LifecycleListeners
don't expose MSC internals)
* eliminate MSC optional dependencies from WildFLy Core
* eliminate MSC Values, Injections & Injectors and migrate to
alternative API
* WildFly Management Layer should not expose MSC APIs as its public API
(complicates potential migration to MSC2 and breaks encapsulation)
+ LONG TERM GOALS (WildFly versions targeting next major EAP)
* eliminate MSC optional dependencies from WildFly (probably via
Capabilities)
(MSC Optional Dependencies have been fixed recently but there's still
performance issue
- in worst case scenario if service A has N optional dependencies
it may happen service A is restarted N times before it is stabilized
in UP state)
Feedback and comments more than welcome!
--
Rio
6 years, 10 months
WildFly provisioned "thin" giving confusing errors on incorrect global Maven settings
by Sanne Grinovero
TLDR: provisioning works fine, booting the server works not.
Hi all,
with all Hibernate ORM contributors now forced to run WildFly
"provisioned in thin format" for integration tests, several people
have been reporting cryptic errors such as:
Failed to resolve artifact 'xerces:xercesImpl:2.11.0.SP5'
(position: END_TAG seen ...resources>\n <artifact
name="xerces:xercesImpl:2.11.0.SP5"/>... @26:56)
The common pattern seems to be an exception reported as "Caused by:
org.jboss.modules.xml.XmlPullParserException".
Turns out the problem is that they didn't have the JBoss Nexus
repository activated.
The provisioning tool is running with the JBoss repository being
enabled - as I hardcoded this as a default - so the dependencies are
actually copied into the local cache, but Maven (Aether) is keeping
track of these being sourced from the JBoss Nexus, so these
dependencies are unresolvable when a subsequent process is started
without having the JBoss Nexus repository enabled.
This could be caused by not having activated some Maven profile, or
simply because the user doesn't mention the JBoss Nexus at all in his
Maven global settings file, or has no global file at all.
There's a number of open JIRAs and StackOverflow questions related,
people are a bit lost and it seems a widespread problem [1].
I'm looking for two things:
A# Could the exception be made clearer? It seems to suggest the XML
is malformed, or perhaps the download corrupted, the local Maven cache
needing to be nuked.
B# Is there a way to boot WildFly with custom Maven configuration
settings? I would want to avoid having all contributors to have to
figure out they have to adjust their global Maven settings.
I guess in an ideal world we'd also want to avoid needing any
dependency which isn't available in Maven Central, but that seems an
harder, long term goal.
For the time being I'll be changing our builds to use the provisioning
but avoiding the "thin" format; I'm a bit sad about that as it was
very convenient, so I'm looking forward for better suggestions :)
Thanks,
Sanne
1 - https://stackoverflow.com/questions/41826619/wildfly-swarm-deployment-iss...
6 years, 11 months
JDK 10 Early Access b40 & JDK 8u172 Early Access b02 are available on jdk.java.net
by Rory O'Donnell
Hi Jason/Tomaz,
Happy New Year!
*OpenJDK builds - *JDK 10 Early Access build 40 is available at
http://jdk.java.net/10/
* These early-access, open-source builds are provided under the GNU
General Public License, version 2, with the Classpath Exception
<http://openjdk.java.net/legal/gplv2+ce.html>.
* Summary of changes :-
https://download.java.net/java/jdk10/archive/40/jdk-10+40.html
*JDK 10 will enter Rampdown Phase Two on Thursday the 18th of January,
2018. *
* More details , see Mark Reinhold's email to jdk-dev mailing list [1]
* The Rampdown Phase Two process will be similar to that of JDK 9 [2].
* JDK 10 Schedule, Status & Features are available [3]
*JDK **8u172 Early-Access build 03*is available at :-
http://jdk.java.net/8/
* Summary of Changes here :-
https://download.java.net/java/jdk8u172/changes/jdk8u172-b02.html
<http://openjdk.java.net/projects/jdk8u/releases/8u162.html>
Regards,
Rory
[1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-January/000416.html
[2] http://openjdk.java.net/projects/jdk/10/rdp-2
[3] http://openjdk.java.net/projects/jdk/10/
--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA, Dublin,Ireland
6 years, 11 months
WF 11.0.0-Final: IJ020009: Invalid connection definition with class-name: com.scort.ctg.cics.eci.jca.EciConnectionFactory
by Francis ANDRE
Hello
Adding the ra.xml joined to WildFly-11.0-Final, ironjacamar emits the
error message: IJ020009: Invalid connection definition with class-name:
com.scort.ctg.cics.eci.jca.EciConnectionFactory (see the log joined
lines 330/350)
The IronJacamar 1.4.6.Final emits this IJ020009 message in the class
org.jboss.jca.deployers.common.AbstractResourceAdapterDeployer.findConnectionDefinitions()
at line 502
for (ConnectionDefinition cd : defs)
{
if (cd.getClassName() == null)
{
log.connectionDefinitionNull();
}
else
{
if (clz.equals(cd.getClassName()))
{
if (result == null)
result = new HashSet<ConnectionDefinition>();
result.add(cd);
}
else
{
if
(!verifyManagedConnectionFactory(cd.getClassName(), cl))
log.connectionDefinitionInvalid(cd.getClassName()); // << line 502
}
}
}
but com.scort.ctg.cics.eci.jca.EciConnectionFactory is not a
ManagedConecctionFactory, it is a ConnectionFactory. So what is wrong
with this ra.xml?
--
Francis ANDRE
R&D Metrixware
------------------------------
METRIXWARE
18-22, Rue d'Arras
(Batiment B12)
92000 Nanterre, France
Téléphone : 01.55.69.32.20.
------------------------------
6 years, 11 months
Feature packs and slots
by Sanne Grinovero
Hi all,
I'm trying to learn how to make proper use of the
`wildfly-feature-pack-build-maven-plugin` to replace our usage of the
assembly plugin.
We extensively use the module slots, and I need to keep the
"{$module.slot}" as a build parameter.
It looks like the Feature Pack plugin is expecting the module.xml
files to be statically committed into the same directory structure as
were they need to end up, but since the slot id needs to be part of
such path, looks like I can't use it? Should I pre-process the module
resources with the assembly plugin?
I was hoping for the feature-pack-build.xml to have a way to define
modules by giving it an identifier (possibly having parameters), point
them to a template xml (optionally filtered), and not having to deal
with the copy-to paths explicitly. It seems odd to have to copy the
jar files and other resources into a matching structure, maybe this
could be automated by the plugin?
Or perhaps I should look at the whole "feature pack" way of doing
things in a different way; are we supposed to only ever use the "main"
slot in a feature pack, and allow the consumer to override/filter such
ids at provisioning time?
Thanks,
Sanne
6 years, 11 months
Provisioning of WildFly 11.0.0.Final : errors in the feature pack?
by Sanne Grinovero
Hi all,
I'm attempting to provision an instance of WildFly 11.0.0.Final (full)
to run integration tests using the
`wildfly-server-provisioning-maven-plugin`, but I'm getting the
following error:
[ERROR] Failed to execute goal
org.wildfly.build:wildfly-server-provisioning-maven-plugin:1.2.4.Final:build
(server-provisioning-node1) on project
hibernate-search-integrationtest-wildfly: Execution
server-provisioning-node1 of goal
org.wildfly.build:wildfly-server-provisioning-maven-plugin:1.2.4.Final:build
failed: java.lang.RuntimeException: java.lang.RuntimeException: Failed
to process feature pack
/home/sanne/.m2/repository/org/wildfly/wildfly-feature-pack/11.0.0.Final/wildfly-feature-pack-11.0.0.Final.zip
modules: Could not extract resources from
org.apache.cxf:cxf-rt-ws-security?jandex: Failed to resolve
expression: ${org.apache.cxf:cxf-rt-ws-security?jandex}
Checking the content, one can see:
# module org.apache.cxf.ws-security contains:
<resources>
<artifact name="${org.apache.cxf:cxf-rt-ws-security?jandex}"/>
</resources>
# module org.apache.cxf.impl:
<resources>
<artifact name="${org.apache.cxf:cxf-rt-security?jandex}"/>
...
I assume this "?jandex" string is not intentional?
Thanks,
Sanne
6 years, 11 months
Deployment unit runtime-name - must it have a packaging type suffix?
by Jaikiran Pai
In context of this[1] forum thread, is runtime-name expected/mandated to
include even the packaging type suffix (.war, .ear etc) or can it be any
name? For example, for a deployment foo.war, is it valid to have it
deployed with a runtime-name "bar"? Or should it be bar.war?
What's happening in this case is that there are deployment unit
processors which identify the "type"[2] of the deployment based on the
deploymentUnit.getName() and in the absence of the suffix, end up not
recognizing the type of the deployment unit which then cascades into
issues like the one in that thread, where the WEB-INF/classes isn't
added as a resource root to the module of the deployment unit, since it
wasn't considered a WAR type deployment.
[1] https://developer.jboss.org/thread/276899
[2]
https://github.com/wildfly/wildfly/blob/master/undertow/src/main/java/org...
-Jaikiran
6 years, 11 months
How to use ELB URLs for Wildfly domain mode clustering
by sanjeewa temp
I have configured a Wildfly (teiid) cluster with a master and slave node
where master and slave resides in two different hosts. so far I have used
IP addresses of the hosts for 'management IP', 'public IP', 'unsecure IP'
and in the slave host controller to resolve the master from the slave. This
is working fine.
But I need to use load balancers in front of my hosts. So I have configured
a load balancer infront of each host and mapped load balancer 8080,
9990,9999 ports to my hosts port so that cluster can communicate using load
balancer URLs. Then I go ahead and gave my load balancer URLs in the
'management IP', 'public IP', 'unsecure IP' and in the slave host
controller to resolve the master from the slave. But slave is unable to
connect to master using the master load balancer URL. It logs the following
msgs on the console.
WARN [org.jboss.as.host.controller] (Controller Boot Thread)
WFLYHC0001: Could not connect to remote domain controller
remote://internal-***********************************.us-east-1.elb.amazonaws.com:9999
-- java.net.ConnectException: WFLYPRT0023: Could not connect to
remote://internal--***********************************.us-east-1.elb.amazonaws.com:9999.
The connection timed out
My slave configuration looks like following
<domain-controller>
<!-- Alternative remote domain controller configuration with a
host and port -->
<remote protocol="remote" host="internal-**************master
elb*****************.us-east-1.elb.amazonaws.com"
port="${jboss.domain.master.port:9999}"
security-realm="ManagementRealm" /></domain-controller><interfaces>
<interface name="management">
<inet-address
value="${jboss.bind.address.management:internal-*****************slave
elb*************.us-east-1.elb.amazonaws.com}" />
</interface>
<interface name="public">
<inet-address
value="${jboss.bind.address:internal-********************slave
elb************.us-east-1.elb.amazonaws.com}" />
</interface>
<interface name="unsecured">
<inet-address value="internal-*********************slave
elb**********.us-east-1.elb.amazonaws.com" />
</interface></interfaces>
I can successfully telnet to load balancer ports using load balancer URLs.
so they are configured properly. Any ideas on how to use load balancer URLs
for clustering in Wildfly.
6 years, 11 months
