Hello Wildfly devs,
At my job we want to move to Linux ARM64 machines for our deployments.
The issue we see is that the current (22.0.1) distribution does not include
native binaries for linux-aarch64 architecture :-/
$ find ./ -name "*.so"
I've found https://issues.redhat.com/browse/WFLY-13302 (and
https://issues.apache.org/jira/browse/ARTEMIS-2705) but those are opened
almost an year ago and it is not clear whether they will be resolved any
As far as I understand your recommendation is to build the binaries
locally. This is OK but it adds some extra complexity to the deployment and
Since ARM64 becomes more and more popular for server side deployments I
would like to ask you whether those tickets could be resolved in near
I am trying to move from wildfly-9 (don't laugh!) to wildfly-23. My old wildfly config file was maintained manually. With 23 I am trying to use standalone-full, modified using jboss-cli.bat. The adding of the queues seems to work but when I go to the admin page (port 9990) and try to look at the message queues I get the error: No ActiveMQ Server is available.
Can anyone shed any light on this please? ActiveMQ is there as a module since it is in standalone-full.xml. I give the following commands before adding the queues:
Software Engineer Specialist, Apex
38th Floor, 25 Canada Square,
Canary Wharf, London E14 5LQ
T: 020-8081-2367 / 07966-451-521
FIS | Advancing the way the world pays, banks and invests(tm)
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. FIS is a trading name of the following companies: Advanced Portfolio Technologies Ltd (No: 6312142) | Alphakinetic Limited (No: 06897969) | Clear2Pay Limited (No: 5792457) | eFunds International Limited (No: 1930117) | Fidelity Information Services Limited (No: 2225203) | FIS Derivatives Utility Services (UK) Limited (No: 9398140) | FIS Energy Solutions Limited (No: 1889028) | FIS Global Execution Services Limited (No. 3127109) | FIS Capital Markets UK Limited (No: 982833) | Integrity Treasury Solutions Europe Limited (No: 3289271) | Metavante Technologies Limited (No: 2659326) | Virtus Partners Limited (No: 06602363) | all registered in England & Wales with their registered office at 25 Canada Square, London E14 5LQ | FIS Global Execution Services Limited is authorised and regulated by the Financial Conduct Authority | FIS Banking Solutions UK Limited (No: 3517639) and FIS Payments (UK) Limited (No: 4215488) both registered in England & Wales with their registered office at 1st Floor Tricorn House, 51-53 Hagley Road, Edgbaston, Birmingham, West Midlands, B16 8TU, United Kingdom | FIS Payments (UK) Limited is authorised and regulated by the Financial Conduct Authority; some services are covered by the Financial Ombudsman Service (in the UK) | Worldpay (UK) Limited (No: 07316500 / FCA No: 530923) | Worldpay Limited (No: 03424752 / FCA No: 504504) | Worldpay AP Limited (No: 05593466 / FCA No: 502597) all registered in England & Wales with their registered office at The Walbrook Building, 25 Walbrook, London EC4N 8AF and authorised by the Financial Conduct Authority under the Payment Service Regulations 2017 for the provision of payment services. Worldpay (UK) Limited is authorised and regulated by the Financial Conduct Authority for consumer credit activities | Worldpay B.V. has its registered office in Amsterdam, the Netherlands (Handelsregister KvK No: 60494344). WPBV holds a licence from and is included in the register kept by De Nederlandsche Bank, which registration can be consulted through www.dnb.nl. Clear2Pay Scotland Limited (No: SC157659), registered in Scotland with registered office at 19 Rose Street, Edinburgh, Scotland, EH2 2PR | Calls to and from the companies may be recorded for quality purposes. | All of the named companies are part of FIS (Fidelity National Information Services, Inc.).
Jandex 2.4.0.Final was released on Wed (with a couple of bigger changes
that are technically breaking, but not for ordinary Jandex API callers: 3
new methods on `IndexView`, new storage format version) and now it’s time
to talk about $SUBJ.
As you might have noticed, I’m slowly taking over Jandex maintenance from
Jason. We have agreed that it’s time to do a 3.0 release with some changes
that are visibly breaking for everyone. Hence this wide distribution.
You can find the current plan for 3.0 here:
https://github.com/wildfly/jandex/milestone/3, but I’ll repeat the
important points here:
- Move to SmallRye, both on GitHub and in the Maven coordinates space. The
`groupId` will change, but the package name will not. This has the
potential to cause nondeterministic classpath, so configuring Enforcer to
ban `org.jboss:jandex` will be a good idea.
- Move to Java 8 as the base.
- Uniform API to access annotations. Currently, each `AnnotationTarget` has
a slightly different set of methods to access annotations, and I’d really
like to unify that.
- `Indexer.index()` will no longer return `ClassInfo`. The very existence
of this return type prevents doing post-processing in `Indexer.complete()`,
which we’d need to do to properly resolve some recursive generic
declarations. The recently introduced `Index.of()` methods are a nicer way
to quickly construct an index for test purposes.
- Runtime-invisible annotations (i.e., `RetentionPolicy.CLASS`) will be
visible in the index. Hopefully this is just an FYI.
- I’d like to merge the Maven plugin into the main codebase, and hopefully
also the `typeannotation-test` artifact.
Also, Jandex will use (at this point, more like continue using) GitHub
Issues for issue tracking. The JANDEX project in Red Hat JIRA will be
Of course, the purpose of this email is to let you voice any concerns you
may have. Feel free to either reply to this email, or file an issue in the
existing Jandex repo on GitHub (it will be transferred to SmallRye, so
nothing will get lost), or add a comment to one of the existing issues.
We've been busy working on WildFly 25, but I've neglected to announce the
expected schedule. This is what we're shooting for:
Fri Aug 27 -- Core Feature Freeze
Wed Sep 1 -- Feature freeze / WF 25 Beta1 Tag
Fri Sep 10 -- WildFly Core code freeze
Wed Sep 15 -- WF 25 tag
Thu Sep 16 -- WF 25 available on wildfly.org
Good afternoon! You may or may not know that we've been working on adding
Micrometer support to WildFly (it's currently in a feature pack, which you
can find here: https://github.com/jasondlee/wildfly-micrometer-extension).
Among the questions we need to answer is how to handle application metrics.
Currently, with MicroProfile Metrics, all application metrics are put into
one bucket, as the spec assumes a single deployment. With Micrometer, we're
not necessarily bound by that, so I'm curious what WildFly users think: are
application metrics ok in one bucket, or should we allow for separate
application metrics registries? If so, how should that look? (How) should
meter names be modified for each registry (e.g., prepended with the
If you have opinions, please let us know as we're still early in the
development and implementation of this feature, so changes now are much
Responses here or on the WildFly ticket would be great:
Principal Software Engineer
Red Hat JBoss EAP
Hello! Resending this message originally sent on 2021-07-27 since the
non-delivery issue on this mailing list has been resolved.
I’m currently reviewing the proposal  of WFLY-14934  feature request
and I’m struggling to understand what are the objectives of this feature.
The “Relevant Installation Types” section with selected “OpenShift s2i” in
the proposal  suggest this feature is OpenShift focused. However the
only differences between this new feature and existing bootable JAR can be
observed on bare metal. On bare metal this feature brings the same features
as bootable JAR does but it adds three things: persistent configuration,
multiple deployments and direct access to each file of the provisioned
server. In S2I scenarios there seems to be no difference between bootable
JAR and this feature. Form of the server in the application image is as far
as I know transparent for the user.
What are the real use-case scenarios of this feature?
 https://issues.redhat.com/browse/WFLY-14934 and
Jan (Honza) Kasik
Quality Engineer, EAP QE