if [ -z "$STARTUP_WAIT" ]; then
STARTUP_WAIT=30
fi
if [ -z "$SHUTDOWN_WAIT" ]; then
SHUTDOWN_WAIT=30
fi
Entries tagged [wildfly]
Setting longer startup / shutdown timeout to wildfly-init-redhat.sh
TweetPosted on Friday Feb 27, 2015 at 03:27PM in WildFly
I’m using bin/init.d/wildfly-init-redhat.sh to operate WildFly instance via service command on CentOS. it has some timeout defaults as follows:
If startup or shutdown takes longer than 30 seconds, the service commands will stop waiting and finished. this brings trouble to some automation mechanism such as shell scripts for deployment on cheaper environment. these variables can be set more longer in /etc/default/wildfly.conf as follows.
## The amount of time to wait for startup STARTUP_WAIT=1800 ## The amount of time to wait for shutdown SHUTDOWN_WAIT=1800
There’s a template for this file at bin/init.d/wildfly.conf in WildFly distribution.
Tags: wildfly
Building latest WildFly against latest Undertow
TweetPosted on Wednesday Feb 25, 2015 at 09:34PM in WildFly
Today I had to make some modification to WildFly and Undertow. I’ve got stucked at build most, and had to make many try and error so I leave about it as note. I’m bad at using Maven so I spent most of time at making WildFly to reference latest Undertow package. I tried something like mvn clean install -Dversion.io.undertow=1.2.0.Beta9-SNAPSHOT in wildfly package but it didn’t work. eventually, I installed following packages into my Maven repository.
wildfly-core
Obtain same version as specified in version.org.wildfly.core property in pom.xml of wildfly package (it can be obtained using git tag).
The pom.xml file in this package keeps version.io.undertow property. wildfly package references this property so you need to modify it to desired version of Undertow. I modified it to 1.2.0.Beta9-SNAPSHOT before install it to local Maven repository. note that -Dmaven.test.skip=true makes build fail but -DskipTests=true might work.
undertow
This package doesn’t have annoying dependencies so you just need to make modification you desired and install to your local repository. keep version element in pom.xml and ensure that it is same to version.io.undertow property in wildfly-core.
wildfly
This package has dependency to wildfly-core. ensure that version.io.undertow in wildfly-core is desired one. the build will be made in wildfly/build/target/wildfly-9.0.0.Alpha2-SNAPSHOT.zip.
My final recipe is following:
-
Run
mvn clean installforundertow(1.2.0.Beta9-SNAPSHOT). changes to java code here but no changes to pom here. -
Run
mvn clean installforwildfly-core(1.0.0.Alpha19). before install, I updated<version.io.undertow>to1.2.0.Beta9-SNAPSHOT. -
Run
mvn clean installforwildfly(9.0.0.Alpha2-SNAPSHOT). changes to java code here but no changes to pom here.
Tips about building WildFly
How to configure WildFly to use secure session cookie and httpOnly
TweetPosted on Wednesday Feb 25, 2015 at 09:00AM in WildFly
Issue following command via jboss-cli:
/subsystem=undertow/servlet-container=default/setting=session-cookie:add(http-only=true,secure=true)
Lean example of integration test Maven project for WildFly
TweetPosted on Monday Feb 23, 2015 at 11:20PM in Technology
I created similar example before, but it was redundant. I created more lean version so leave here with some notes. check my GitHub repository for details.
The project contains AppServer class, which extends ExternalResource so it can be used with @Rule annotation of JUnit as follows. note that mavenit is the name of WAR file to be tested.
public class HelloImplIT {
@ClassRule
public static AppServer appServer = new AppServer();
private static Hello sut;
@BeforeClass
public static void beforeClass() {
sut = appServer.lookup("mavenit", HelloImpl.class, Hello.class);
}
@Test
public void test() {
Assert.assertEquals("Hello world!", sut.hello());
}
}
The project is easy to use with both of IDE and standalone. to run IT classes with IDE, you need to launch the application server, deploy the project as WAR package, then run a IT class from IDE. if you launched the server at not 8080 port, specify the port in app-server.port system property.
To run IT classes in standalone Maven, use following command. it automatically launches WildFly instance with port offset of 30000, deploy the WAR file, running IT classes, undeploy the WAR and stops WildFly. the command is intended to use from a Jenkins job.
mvn verify -Pintegration-test-with-wildfly \ -Djava.home=/Library/Java/JavaVirtualMachines/jdk8/Contents/Home/jre \ -Djboss-as.home=/Users/kyle/servers/wildfly-8.2.0.Final \ -Dwildfly.port=39990 \ -Dapp-server.port=38080 \ -Dwildfly.jvmArgs="-Djboss.server.base.dir=/Users/kyle/servers/wildfly-8.2.0.Final/standalone-mavenit -Djboss.socket.binding.port-offset=30000 -ea"
You can configure following parameters through command line argument:
-
JAVA_HOME⇒-Djava.home -
WildFly distribution ⇒
-Djboss-as.home -
jboss.server.base.dir⇒ inside-Dwildfly.jvmArgs -
Port offset ⇒
-Djboss.socket.binding.port-offsetinside-Dwildfly.jvmArgs. you need to set-Dwildfly.portand-Dapp-server.portaccordingly.
Using JSL Inheritance with JBeret
TweetPosted on Sunday Feb 22, 2015 at 06:28PM in Technology
In practical use, many boilerplate code will appear to Job definition XMLs of JSR352 batch such as definition of Listeners, Properties and attribute such as item-count of chunk element. to overcome this, there is the specification of JSL Inheritance but it deferred to next version of JBatch spec but JBeret supports this specification already. it’s very useful to eliminate annoying fragments appear repeatedly so I tested it. WildFly 8.2.0.Final was used for test.
Parent XML
Parent XML begins as follows:
<?xml version="1.0" encoding="UTF-8"?>
<job id="parent" abstract="true" version="1.0" xmlns="http://xmlns.jcp.org/xml/ns/javaee">
<properties>
<property name="someJobProp" value="someJobPropValue"/>
</properties>
<listeners>
<listener ref="myJobListener"/>
</listeners>
Declared property named someJobProp become visible from child XMLs. myJobListener will be included implicitly in child XMLs as well.
Parent XML has an abstract step element which will be referenced from child XMLs as follows. these properties and listeners for a step will be included implicitly too. we can override javax.transaction.global.timeout at there. it will be affected to all of child steps.
<step id="mySimpleStep" abstract="true">
<properties>
<property name="javax.transaction.global.timeout" value="1800"/>
</properties>
<listeners>
<listener ref="myStepListener"/>
</listeners>
</step>
It is the same for chunk based step. it can be used to eliminate defining item-count for all of chunk steps.
<step id="myChunkStep" abstract="true">
<properties>
<property name="javax.transaction.global.timeout" value="900"/>
<property name="jberet.local-tx" value="true"/>
</properties>
<listeners>
<listener ref="myStepListener"/>
<listener ref="myChunkListener"/>
</listeners>
<chunk item-count="3"/>
</step>
</job>
Child XML
Child XML became very simple thanks to inheritance as follows. you need to specify parent and jsl-name attributes to reference its parent. parent means the name of parent attribute. jsl-name means XML file name of referencing element.
<?xml version="1.0" encoding="UTF-8"?>
<job id="child" parent="parent" jsl-name="parent" version="1.0" xmlns="http://xmlns.jcp.org/xml/ns/javaee">
<step id="simpleStep" next="chunkStep" parent="mySimpleStep" jsl-name="parent">
<batchlet ref="myBatchlet"/>
</step>
<step id="chunkStep" parent="myChunkStep" jsl-name="parent">
<chunk>
<reader ref="myItemReader"/>
<writer ref="myItemWriter"/>
</chunk>
</step>
</job>
Launching example job
-
Clone the repository
-
Build the WAR and deploy it to your WildFly
-
Run a JUnit test class named JobTest. it invokes the job through remote EJB invocation.
Log
You can see Properties, Listeners and item-count attribute were inherited as expected.
(Batch Thread - 1) Job child starting
(Batch Thread - 1) Job child, Step simpleStep starting
(Batch Thread - 1) hello world!
(Batch Thread - 1) jobProps: {someJobProp=someJobPropValue}
(Batch Thread - 1) stepProps: {javax.transaction.global.timeout=1800}
(Batch Thread - 1) Job child, Step simpleStep done
(Batch Thread - 1) Job child, Step chunkStep starting
(Batch Thread - 1) jobProps: {someJobProp=someJobPropValue}
(Batch Thread - 1) stepProps: {jberet.local-tx=true, javax.transaction.global.timeout=900}
(Batch Thread - 1) Job child, Step chunkStep chunk starting
(Batch Thread - 1) write: [1, 2, 3]
(Batch Thread - 1) Job child, Step chunkStep chunk done
(Batch Thread - 1) Job child, Step chunkStep chunk starting
(Batch Thread - 1) write: [4, 5, 6]
(Batch Thread - 1) Job child, Step chunkStep chunk done
(Batch Thread - 1) Job child, Step chunkStep chunk starting
(Batch Thread - 1) write: [7, 8, 9]
(Batch Thread - 1) Job child, Step chunkStep chunk done
(Batch Thread - 1) Job child, Step chunkStep chunk starting
(Batch Thread - 1) write: [0]
(Batch Thread - 1) Job child, Step chunkStep chunk done
(Batch Thread - 1) Job child, Step chunkStep done
(Batch Thread - 1) Job child done