Add natives for ARM64 to Wildfly distro
by Julien Faye
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"
./modules/system/layers/base/org/apache/activemq/artemis/journal/main/lib/linux-i686/libartemis-native-32.so
./modules/system/layers/base/org/apache/activemq/artemis/journal/main/lib/linux-x86_64/libartemis-native-64.so
./modules/system/layers/base/org/wildfly/openssl/main/lib/linux-x86_64/libwfssl.so
./modules/system/layers/base/org/wildfly/openssl/main/lib/linux-s390x/libwfssl.so
I've found https://issues.redhat.com/browse/WFLY-13302 (and
https://issues.redhat.com/browse/WFSSL-32 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
time soon.
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
upgrade processes.
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
future ?
Thank you!
Regards,
Julien
4 years, 5 months
WildFly 24 Development Schedule
by Brian Stansberry
Here's the schedule I'd like to shoot for as we work on WildFly 24. This
is basically three months after WildFly 23, and lines us up to do 25 in
mid-September (so the final polishing after the typical summer vacations)
and then 26 in early December (before things slow down at year end.)
Fri May 21 -- Core Feature Freeze
Wed May 26 -- Feature freeze / WF 24 Beta1 Tag
Fri Jun 4 -- WildFly Core code freeze
Wed Jun 9 -- WF 24 tag
Thu Jun 10 -- WF 24 available on wildfly.org
Best regards,
Brian
4 years, 11 months
mod_jk integration.
by back button
Hi,
I can't find wildfly-users on this page https://lists.jboss.org/archives/ only wildfly-dev.
Can you please let me know where I can find users list or better still give me information on a task I am doing at the moment.
I am using the instructions found in a book for administrating wildlfy.
The first four steps are every clear the last step which is not on par with the previous 4 steps.
It doesn't describe where and how am I supposed to check the ajp listener ?
After checking where and how I am supposed to update with the following code ?
If you wish to respond I have listed all steps in reverse order.
Thanks
STEP 5
14.1.2. Configuring WildFly to receive AJP requests
Done with mod_jk, now let’s move to WildFly configuration. First of all, check that your current
version of WildFly includes an ajp listener:
/subsystem=undertow/server=default-server/:read-resource(recursive=false)
{
"outcome" => "success",
"result" => {
"default-host" => "default-host",
"servlet-container" => "default",
"ajp-listener" => {"ajp" => undefined},
"host" => {"default-host" => undefined},
"http-listener" => {"default" => undefined},
"https-listener" => undefined
}
}
In our case the ajp-listener is included in the configuration. In case the ajp-listener does not show
up in your configuration, then you can add it as follows:
/subsystem=undertow/server=default-server/ajp-listener=default-ajp:add(socket-
binding=ajp)
So with the above configuration, all incoming requests included in the JKMount directive by
Apache configuration, will be transparently routed to WildFly.
STEP 4
worker.list=loadbalancer,status
# Define Node1
worker.node1.port=8009
worker.node1.host=localhost
worker.node1.type=ajp13
worker.node1.lbfactor=1
# Define Node2
worker.node2.port=8159
worker.node2.host=localhost
worker.node2.type=ajp13
worker.node2.lbfactor=1
# Load-balancing behavior
worker.loadbalancer.type=lb
worker.loadbalancer.balance_workers=node1,node2
worker.loadbalancer.sticky_session=1
worker.status.type=status
STEP 3
Now create the file mod-jk.conf in your Apache configuration folder. This file will contain the
mod_jk configuration including the web context we are going to route from Apache to WildFly.
295LoadModule jk_module
modules/mod_jk.so
# Where to find workers.properties
JkWorkersFile conf/workers.properties
# Where to put jk logs
JkLogFile logs/mod_jk.log
# Set the jk log level
JkLogLevel info
# Mount your applications
JkMount /myapp/* loadbalancer
JkShmFile logs/jk.shm
You can download the above script from here: http://bit.ly/2G1GfVH
Here is a description for the most important settings:
The LoadModule directive references the mod_jk library you have downloaded. You must indicate
the exact same name with the "modules" file path prefix.
The JkMount directive tells Apache which URLs it should forward to the mod_jk module. In the
above file, all requests with URL path /myapp/* are sent to the mod_jk load-balancer.
The JkWorkersFile references in turn the cluster configuration and thus contains the (static) list of
nodes that are part of the Web farm. The worker file, named workers.properties, follows here:
STEP 2
Mod_jk configuration will be stored in a file apart, hence include this line in your httpd.conf:
Include conf/mod-jk.conf
STEP 1
14.1.1. Configuring Apache Web server side
In order to install mod_jk, as first step download the latest stable Apache mod_jk connectors from
http://tomcat.apache.org/download-connectors.cgi .Once completed the download, copy the
connector to the modules folder of your Apache 2 distribution:
$ cp mod_jk.so $APACHE_HOME/modules
5 years
Context Propagation
by Kabir Khan
Hi,
I am currently working on porting context propagation from the WildFly
Reactive Feature Pack to WildFly itself, and have a question about how to
proceed.
In the feature pack I have the following setup
* A microprofile-context-propagation layer, which contains the core
subsystem and propagation providers for:
- CDI
- Application (Just TCCL)
* A microprofile-context-propagation-jta layer which provides propagation
for transactions
During the porting process I am finally revisiting some long outstanding
things:
* Extending Application to also propagate the NamespaceContextSelector
(Jakarta EE naming)
* JAX-RS context propagation
* Servlet context propagation
Now, a lot of providers are starting to rely on more stuff in layers which
might not be provisioned. One thing I could do is have a layer for each of
these, so e.g:
- microprofile-context-propagation-jaxrs would provide propagation of the
RestEasy context and make sure the JAX-RS layers are available
- microprofile-context-propagation-servlet would provide propagation of the
Servlet context and make sure the undertow layers are available
and so on.
While ^^ is the cleanest solution, I think it is way too fine-grained, and
the list of what people need to provision might become quite long.
I am currently working on something where you just have the
microprofile-context-propagation layer, which contains all the providers,
and does a check when the deployment is first initialised. If when loading,
say, the RestEasy provider, and RestEasy is not there, it will log an INFO
message along the lines of:
Class
org.wildfly.extension.microprofile.context.propagation.providers.jaxrs.JaxRsThreadContextSnapshotFactory
could not be loaded, because the underlying layers are not provisioned. You
will not get context propagation for the 'JAX-RS' thread context type
This message is printed when the deployment's context manager is first
loaded (i.e. on deploy) and not on every attempt to do propagation.
Does anybody see any problems with this approach? To me it is more
user-friendly, but others might have different opinions.
Thanks,
Kabir
5 years
Move some dependencies to a new testbom in wildfly-core
by Lin Gao
Hi folks,
WildFly-core's root pom acting as BOM and getting imported into WildFly's
root pom via dependencyManagement
to be able to align the shared dependencies, it works good most of the time
but has problems[1] on dependencies
which are used only for testing in wildfly-core but are used in production
in WildFly full. Please refer to the
Jira issue[1] for more detail and context.
There is a PR[2] open to address that problem by introducing a *testbom*
which contains such dependencies. Any
module depending on such dependencies can add the *testbom* with an import
scope.
The PR tries to move the following dependencies from WildFly-core's root
pom to the new created *testbom*:
- commons-io:commons-io
- com.fasterxml.jackson.core:jackson-databind
- xalan:xalan
Once the PR gets approved, it needs any project depending on
wildfly-core's root pom to check, like adding
the commons-io:commons-io dependency in case of WildFly full[3].
Does anyone see problems with such a move? Thank you !
[1] https://issues.redhat.com/browse/WFLY-14431
[2] https://github.com/wildfly/wildfly-core/pull/4572
[3]
https://github.com/wildfly/wildfly/compare/master...gaol:update_test_depe...
Best Regards
--
Lin Gao
Senior Software Engineer
JBoss Sustaining Engineering Team
5 years
Move some dependencies to a new testbom in wildfly-core
by Lin Gao
Hi folks,
WildFly-core's root pom acting as BOM and getting imported into WildFly's
root pom via dependencyManagement
to be able to align the shared dependencies, it works good most of the time
but has problems[1] on dependencies
which are used only for testing in wildfly-core but are used in production
in WildFly full. Please refer to the
Jira issue[1] for more detail and context.
There is a PR[2] open to address that problem by introducing a
*testbom* which
contains such dependencies. Any
module depending on such dependencies can add the *testbom* with an import
scope.
The PR tries to move the following dependencies from WildFly-core's root
pom to the new created *testbom*:
- commons-io:commons-io
- com.fasterxml.jackson.core:jackson-databind
- xalan:xalan
Once the PR gets approved, it needs any project depending on
wildfly-core's root pom to check, like adding
the commons-io:commons-io dependency in case of WildFly full[3].
Does anyone see problems with such a move? Thank you !
[1] https://issues.redhat.com/browse/WFLY-14431
[2] https://github.com/wildfly/wildfly-core/pull/4572
[3]
https://github.com/wildfly/wildfly/compare/master...gaol:update_test_depe...
Best Regards
--
Lin Gao
Senior Software Engineer
JBoss Sustaining Engineering Team
5 years
