We are using Wildfly 8.0.0 Final but are in the process of moving to Wildfly 8.2. We are using Arquillian to run our unit tests in the container. I have noticed that Arquillian always seems to use the Wildfly standalone.xml.
It would be useful to be able to tell Arquillian what configuration to use when starting Wildfly. Wildfly comes with several different configuration files. It would be useful to have able to have Arquillian run wildfly with a specific configuration or even tell Arquillian what configuration to use for a test.
We use the Wildfly CLI to configure wildfly properties. This configuration is stored in the configuration file. If we could specify which configuration to use in starting Wildfly for a test we could then test our different configurations.
This seems reasonable, but I haven't found a way to do this.
The Wildfly configuration file is specified by the startup parameter, --server-config.
As John wrote, you can. Adding an example of /arquillian.xml:
(This is for WFly 10.x but it's been the same since AS 7 I think.)
<arquillian xmlns="http://jboss.org/schema/arquillian"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="
http://jboss.org/schema/arquillian
http://jboss.org/schema/arquillian/arquillian_1_0.xsd">
<container qualifier="jbossas-managed" default="true">
<configuration>
<property name="jbossHome">target/wildfly-10.1.0.Final</property>
<property name="serverConfig">standalone-full.xml</property>
<property name="javaVmArguments">-Xms64m -Xmx2048m -Dorg.jboss.resolver.warning=true -Djboss.socket.binding.port-offset=100</property>
<property name="managementPort">10090</property>
<!--<property name="javaVmArguments">-Xms64m -Xmx2048m -Dorg.jboss.resolver.warning=true -agentlib:jdwp=transport=dt_socket,address=8000,server=y,suspend=y</property>-->
</configuration>
</container>
</arquillian>
Yes, just specify serverConfig in your arquillian.xml. By default it will be standalone.xml
Related
Our product is using Jetty to deploy a webapp in which we are triggering the jetty using the ant build target like below
<exec executable="**/jetty.sh" failonerror="true">
<env key="JETTY_CONF" value="***/jetty.conf"/>
<env key="JETTY_LOGS" value="${logs}"/>
<env key="JETTY_PID" value="${logs}/jetty.pid"/>
<env key="TMPDIR" value="${tmp.dir}"/>
<!-- location where jetty will extract the war -->
<env key="JAVA_OPTIONS"
value="-server -d64 ${heapOptions} ${gcOptions} ${sslOptions} ${debugFlags} -Dsettings.path=${settings.path} -Dlog4j.configuration=file:///${xmlFile} -Djetty.secure.port=${*} -Dapp.dir=${*} -Drs.data.dir=${*} -Disutest=${isutest} -Disftest=${ftest} -Disrtest=${rtest} -Disrtestlocal=${rtestlocal} -Dlogs.dir=${logs.dir} -Ddist.dir=${*()} "/>
<env key="JAVA" value="${JAVA_HOME}/bin/java"/>
<arg value="${com}"/>
</exec>
In this I am wondering if the -Dlog4j.configuration=file:///${xmlFile} is it for the Jetty to configure the logs or is it webapp specific .
If it is for jetty to configure log4j I do not see any log4j related libraries in jetty. So, need a little clarification on this.
from Jetty 1.0 thru 9.0 Jetty used an in-house Logging Facade, that wrote to STDERR (System.err), with an optional configuration to use slf4j (since Jetty 6.0).
From Jetty 10.0 on-wards Jetty uses the slf4j logging facade (and has it's own jetty-slf4j-impl that writes to STDERR/System.err).
Not once has Jetty depended on or shipped with log4j.
If you see log4j in your configuration, it's something that you (or your predecessors) have added on top of Jetty.
Some tools like Hadoop need to explicitly especify the name of workers (section Slaves File in docs), but when deploys with Docker Swarm it assigns automatic container names, so workers file doesn't work anymore as the names in it don't exist. Is there any way to avoid this file or, at least, assign aliases for containers (independently of container name) to make it work?
Maybe I can't use docker-compose.yml file and I must create the services manually over the cluster... Any kind of light on the subject would be really appreciated
Well, Hadoop documentation sucks... Apparently if you set the alias of master node in the core-site.xml file you can omit the workers file. These are the step I followed:
Customized the core-site.xml file (in my docker-compose.yml file I put my master service with the name nodemaster). This file must be in master and workers nodes:
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="configuration.xsl"?>
<configuration>
<configuration>
<property>
<name>fs.defaultFS</name>
<value>hdfs://nodemaster:9000</value>
</property>
<property>
<name>fs.default.name</name>
<value>hdfs://nodemaster:9000</value>
</property>
</configuration>
</configuration>
Now when you run:
start-dfs.sh
start-yarn.sh
I'll connect to the master automatically
On the last few weeks I've been working on a JavaFX Application to deploy for both Unix and Windows. At the moment, I'm trying to customize the install scripts/ config files.
On MacOS I simply included the script to the class path using <property> on my ANT build file like this:
<property name="classpath" location="package/macosx/App-dmg-setup.scpt"/>
But when I try to do the same on Windows, doesn't work (continues using the default config file). I've already tried absolute path, env.CLASSPATH instead of classpath, and some other alternatives, with no success.
Thanks a lot ;)
Cheers!
Ok sorry this question, actually I was inadvertently changing the basedir variable. The correct definition should only be:
<path id="fxant">
<filelist>
<file name="${java.home}\..\lib\ant-javafx.jar"/>
<file name="${java.home}\lib\jfxrt.jar"/>
<file name="${basedir}"/>
</filelist>
</path>
<taskdef resource="com/sun/javafx/tools/ant/antlib.xml"
uri="javafx:com.sun.javafx.tools.ant"
classpathref="fxant"/>
Without another (re)definition.
Once again, thanks!
I'm new to grails and wondering whether there is a way to add a third party servlet in a grails application?
I'm trying to use Waffle with grails. I was successfully able to use Waffle in an MVC app using spring security as described here: https://github.com/dblock/waffle/blob/master/Docs/spring/SpringSecurityAuthenticationProvider.md
In my MVC app I was able to add beans like this for authentication:
<bean id="waffleNegotiateSecurityFilter" class="waffle.spring.NegotiateSecurityFilter">
<property name="provider" ref="waffleSecurityFilterProviderCollection"/>
<property name="allowGuestLogin" value="false"/>
<property name="principalFormat" value="fqn"/>
<property name="roleFormat" value="both"/>
</bean>
You have to add filters mapping to web.xml
install web.xml using grails command
> grails install-templates
Than edit web.xml file (inside src/templates )
and add the mapping as stated by the documentation you showed us.
Then add beans definition to grails resources
/conf/spring/resources.groogy
Translating xml bean definition to grails spring groovy DSL can be a little difficult. If you have any problem refear to the guide about grails and spring or ask here.
I have just been struggling with this for a few days and ended up with doing the following in a plain Grails 2.4.4 project:
grails create-app
grails install-templates
Then modification of BuildConfig.groovy
dependencies {
...
compile "com.google.guava:guava:18.0"
compile "com.github.dblock.waffle:waffle-jna:1.7.3"
compile "net.java.dev.jna:jna:4.1.0"
compile "net.java.dev.jna:jna-platform:4.1.0"
compile "org.slf4j:slf4j-api:1.7.9"
....
}
I then created context.xml below ..\META-INF with the following content:
<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE Context>
<Context>
<Valve className="waffle.apache.NegotiateAuthenticator" principalFormat="fqn" roleFormat="both" protocols="Negotiate,NTLM" />
<Realm className="waffle.apache.WindowsRealm" />
</Context>
And then added the following to the ..\templates\web.xml file:
<display-name>/#grails.project.key#</display-name>
<security-constraint>
<display-name>Waffle Security Constraint</display-name>
<web-resource-collection>
<web-resource-name>Protected Area</web-resource-name>
<url-pattern>/</url-pattern>
<http-method>DELETE</http-method>
<http-method>GET</http-method>
<http-method>POST</http-method>
<http-method>PUT</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>Everyone</role-name>
</auth-constraint>
</security-constraint>
<security-role>
<role-name>Everyone</role-name>
</security-role>
....
....
To verify that it actually worked, I added a line to index.gsp
<p>You are logged in as remote user <b>${request.getRemoteUser()}</b> in session <b>${session.getId()}</b>.</p>
I tested this under Tomcat 7.0.57 and had to add some jars to the Tomcat lib to get i to work. I added slf4j-api-1.7.9.jar, guava-18.0.jar, jna-platform-4.1.0.jar, jna-4.1.0.jar, waffle-tomcat7-1.7.3.jar, waffle-jna-1.7.3.jar. Still wonder why this is actually necessary when the same jars are also added to BuildConfig.groovy.
I have a problem with a build where I have to resolve non-standard artifacts through Apache Ivy.
Problem:
I have dependencies on two artifacts (a.jar and a-lib.jar).
The two dependencies come only as part of a single installer (a_installer.jar).
The installer can be downloaded, the embedded artifacts themselves not.
It's possible to manipulate the installer to unpack the needed dependencies.
Requirements:
I have to resolve/download the artifacts during the build (I cannot keep the installer or the extracted artifacts with my code).
I cannot use a repository to store the extracted artifacts.
Subclassing/Extending Ivy/whatever is perfectly fine.
Has anyone solved a similar problem, or some helpful information to share?
Or maybe I'm approaching the problem in the wrong way? From what I found so far on the web, people seem to use Ivy just to download files and post-process them manually (with Ant/whatever) after the fact, and not actually resolving more complicated dependencies within Ivy.
Thanks
PS: I don't care whether the installer is also put into the ivy download cache, but I would like to download the installer only one time (and not for both dependencies).
The problem with a call to "ivy:retrieve" is that you need to also add an "artifact" tag in your ivy.xml (complete with URL) in order to retrieve a dependency not found in a Maven respository...
I don't like this for two reasons
The ivy.xml should just declare your dependencies, not their locations.
Need additonal custom logic in the build.xml to handle the 3rd party package
Ideally it should be your repository settings that decide how to download the various jars, that is why I like the packager resolver. Even if the library I want is not in Maven, I can configure ivy to handle it.
The following is an example of turning the jreleaseinfo project into an ivy dependency (hosted in sourceforge, I couldn't find it in Maven)
ivy.xml:
<?xml version="1.0" encoding="ISO-8859-1"?>
<ivy-module version="2.0">
<info organisation="com.myspotontheweb" module="ivy_packager"/>
<dependencies>
<dependency org="ch.oscg" name="jreleaseinfo" rev="1.3.0"/>
</dependencies>
</ivy-module>
Declare two resolvers. Default is Maven2, the other is a packager configured to look locally for instructions. (See also the Ivy Roundup project)
ivysettings.xml
<ivysettings>
<settings defaultResolver="maven2"/>
<resolvers>
<ibiblio name="maven2" m2compatible="true"/>
<packager name="repackage" buildRoot="${user.home}/.ivy2/packager/build" resourceCache="${user.home}/.ivy2/packager/cache">
<ivy pattern="file:///${basedir}/repository/[organisation]/[module]/[revision]/ivy.xml"/>
<artifact pattern="file:///${basedir}/repository/[organisation]/[module]/[revision]/packager.xml"/>
</packager>
</resolvers>
<modules>
<module organisation="ch.oscg" name="jreleaseinfo" resolver="repackage"/>
</modules>
</ivysettings>
The magic is containing in the "packager" file. At resolve time this will be used to generate an ANT script that both downloads and extracts the required jars.
(No need to put this logic into your build.xml)
repository/ch.oscg/jreleaseinfo/1.3.0/packager.xml
<packager-module version="1.0">
<property name="name" value="${ivy.packager.module}"/>
<property name="version" value="${ivy.packager.revision}"/>
<property name="zipname" value="${name}-${version}"/>
<resource dest="archive" url="http://sourceforge.net/projects/jreleaseinfo/files/jreleaseinfo/jreleaseinfo%201.3.0/jreleaseinfo-1.3.0.zip/download" sha1="9386d92758e627d04c2480b820731fd538b13a3f" type="zip"/>
<build>
<move file="archive/${zipname}/${zipname}.jar" tofile="artifacts/jars/${name}.jar"/>
</build>
</packager-module>
To reduce the number of files I omitted the module's ivy.xml. This appears to be optional unless you want to declare it's licence and other attributes that should be present in a public repository.
I think this is very straightforward: 'ivy:retrieve' a_installer and then unzip a.j and a-lib into your lib directory (or wherever you want it). This should be easily to do with ant?
I have to wonder if there is some complication you haven't mentioned that prevents you from doing this.