We Keep Coding

How to use global-module class for ejb home/remote?

Migrating an existing project to maven and wildfly and had to move some files around creating the following situation.
core.jar
ejb1.jar
ejb2.jar
With the ejb-jar.xml for ejb1.jar having the following:
<ejb-jar>
<enterprise-beans>
<session id="Value">
..
<home>path.to.ejb1Home</home>
<remote>path.to.ejb1</remote>
...
The classes referenced in the home and remote tags have moved to be inside core.jar
Meanwhile ejb2.jar has dependencies on other parts of core.jar.
What looked like the easiest resolution was to create a global module and place core.jar in it, creating the appropriate module.xml and entry in standalone.sh to make it accessible to all deployments.
module.xml
<?xml version="1.0" encoding="UTF-8"?>
<module xmlns="urn:jboss:module:1.0" name="path.to">
<resources>
<resource-root path="core-1.0.jar"/>
</resources>
<dependencies>
</dependencies>
</module>
With this setup, ejb2.jar deploys as expected but ejb1.jar throws the following error:
Caused by: java.lang.NoClassDefFoundError: Failed to link path.to.ejb1
(Module "path.to" from local module loader #4c40b76e (finder: local
module finder #2ea6137 (roots: /opt/wildfly/modules,
/opt/wildfly/modules/system/layers/base))): javax/ejb/EJBObject

You should carefully think about your requirement. Usually, you don't need to provide common resources, especially application interfaces, as module, especially as global module. Choose the right solution for your requirements, not a solutions that looks easy at first sight without knowing the implications.
I would recommend these possibilities in the order given (see the Class Loading in Wildfly Documentation for more information):
Reconsider your requirement for different EARs. Provide the core jar as library with your EAR.
Even with more than one EAR: provide the core.jar as library. This is no redundancy, this is just separation.
Consider not using a global module. Just install your custom module. Provide a jboss-deployment-structure.xml file, adding this module as additional dependency. If the module contains annotated classes or interfaces, which should be considered upon deployment, set the attribute annotations=true with the module dependency configuration.
Add a global module to your configuration file. Probably you can even use the `annotations' property, but this is something I don't know and I didn't check.
An example for the jboss-deployment-structure.xml file:
<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.3">
<ear-subdeployments-isolated>false</ear-subdeployments-isolated>
<deployment>
<dependencies>
<module name="my.custom.module" export="true" annotations="true"/>
</dependencies>
</deployment>
</jboss-deployment-structure>
EDIT:
When installing modules, don't forget to provide transitive module dependencies to other modules your own module depends on. User your module.xml file to do so. In your case, you probably need at least a dependency to the javax.ejb.api module.

Module not excluded on Wildfly

We want to exclude the modules\system\layers\base\javax\servlet\jstl\api\main\jboss-jstl-api_1.2_spec-1.1.2.Final.jar from our web application deployment (WAR file).
Hence we have the following configuration in src\main\webapp\WEB-INF\jboss-deployment-structure.xml:
<?xml version='1.0' encoding='UTF-8'?>
<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2">
<deployment>
<exclusions>
<module name="javax.servlet.jstl.api"/>
</exclusions>
<dependencies>
<module name="deployment.my-dependencies.jar"/>
</dependencies>
</deployment>
</jboss-deployment-structure>
In the Wildfly log I see that my-dependencies.jar is added as a ModuleDependency. But when searching for javax.servlet.jstl.api I only see this:
2015-04-03 15:22:11,971 DEBUG [org.jboss.modules] (ServerService
Thread Pool -- 12) Module javax.servlet.jstl.api:main defined by local
module loader #1f7c9157 (finder: local module finder #2b29f6e7 (roots:
C:\Users\me\Documents\wildfly-8.2.0.Final\modules,C:\Users\me\Documents\wildfly-8.2.0.Final\modules\system\layers\base))
Why isn't the module excluded?

Update: It seems that modules that are part of a user dependency can not be excluded.
It seems like the mechanism doesn't work as described in the Wildfly documentation. I was not able to exclude that module.

Yep. I was trying to upgrade to Spring Framework to v4.3. It has upped some minimum dependency requirements. One such example is Jackson min version required is 2.6+
Wildfly loads jackson that comes packaged (v2.4.1 in Wildfly 8.2.1), and it won't be excluded using jboss-deployment-structure.xml.
I was trying to see if the upgrade did not involve making changes to the installed server which takes this upgrade out of source control.

failing to load log4j2 while running fatjar

i am working on a project where i utilize log4j2 logging.
while developing in intellij, all works fine and the logging is done as expected. the log4j2.xml is linked through java property passed to jvm on startup via intellij settings.
but once i try to run a standalone gradle built fat-jar, i'm experiencing the following problems:
java -Dlog4j.debug=true -Dlog4j.configurationFile=/home/aaa/log4j2.xml -jar /home/aaa/myjar-SNAPSHOT.jar
exceptions:
ERROR StatusLogger Unrecognized format specifier [d]
ERROR StatusLogger Unrecognized conversion specifier [d] starting at position 16 in conversion pattern.
ERROR StatusLogger Unrecognized format specifier [thread]
ERROR StatusLogger Unrecognized conversion specifier [thread] starting at position 25 in conversion pattern.
...
ERROR StatusLogger No log4j2 configuration file found. Using default configuration: logging only errors to the console.
i don't even understand where those [thread]s come from, since i get the same error even while using a basic simplest config in my log4j2:
<?xml version="1.0" encoding="UTF-8" ?><Configuration status="WARN" monitorInterval="86400">
<Appenders>
<Console name="console-log" target="SYSTEM_OUT">
<PatternLayout
pattern="%-5p %d{yyyy-MM-dd HH:mm:ss.SSS} ${hostName} %c{1} %msg %throwable{7}%n"/>
</Console>
</Appenders>
<Loggers>
<Root level="info" additivity="false">
<AppenderRef ref="console-log"/>
</Root>
</Loggers>
any thoughts are welcome. thanks.

in fatJar, dependencies can provide a log4j-provider.properties in the META-INF that cause this issue,
remove it in the gradle task :
task fatJar(type: Jar) {
manifest {
attributes 'Implementation-Title': 'project',
'Implementation-Version': project.version,
'Main-Class': 'com.sample.CLI'
}
baseName = project.name + '-all'
from {
configurations.compile.collect {
it.isDirectory() ? it : zipTree(it).matching {
exclude 'META-INF/**.RSA'
exclude 'META-INF/MANIFEST.MF'
exclude 'META-INF/log4j-provider.properties'
} } }
with jar
}

The problem is described here: https://issues.apache.org/jira/browse/LOG4J2-673
Unfortunately at the moment there only seems to be a solution for the maven-shade-plugin: https://github.com/edwgiz/maven-shaded-log4j-transformer
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-shade-plugin</artifactId>
<version>2.4.3</version>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>shade</goal>
</goals>
<configuration>
<finalName>${project.artifactId}${appSuffix}</finalName>
<transformers>
...
<transformer
implementation="com.github.edwgiz.mavenShadePlugin.log4j2CacheTransformer.PluginsCacheFileTransformer">
</transformer>
</transformers>
...
</configuration>
</execution>
</executions>
<dependencies>
<dependency>
<groupId>com.github.edwgiz</groupId>
<artifactId>maven-shade-plugin.log4j2-cachefile-transformer</artifactId>
<version>2.1</version>
</dependency>
</dependencies>
</plugin>
</plugins>

Kinda late to this party, but I thought I'd add my situation, in case it helps anyone.
I build my own fat jar out of a subset of classes and jars from the larger project. The essential class runs, but I was getting all the "Unrecognized format specifier" and all. Most of the answers involve mvn shade or other such, so that wasn't helping me. But poking around, I learned that log4j-web.jar also includes the Log4jPlugins.dat file, causing the problems. Removing that from the build, and all is good.
(And I thought my build script was so tricky, including all the jars by project name, eg all jars for "log4j.")

The LoggerContextFactory binds the Log4j API to its implementation. The Log4j LogManager locates a LoggerContextFactory by locating all instances of META-INF/log4j-provider.properties, a standard java.util.Properties file, and then inspecting each to verify that it specifies a value for the Log4jAPIVersion property that conforms to the version required by the LogManager.
Incase of fat jar, you can also explicitly specify log4j2 to use LoggerContextFactory in your application by:
System.setProperty("log4j2.loggerContextFactory", "org.apache.logging.log4j.core.impl.Log4jContextFactory")
or as specified in the log4j-provider.properties file included in your log4j-core jar.

When you run your application from an IDE, jar runs itself without embedding the dependencies and you don't have conflict of log settings. But when you convert the application into a fat jar then all the dependencies will be injected into your project's jar file and your log4j settings that come from external jar files (dependencies) may be conflicted while fatJar process merge them into a single artifact.
In this case i think your "Log4j2Plugins.dat" files may be conflicted. To be sure, you can open your fatJar file with a zip editor (ex: 7Zip), navigate to path in fatJar as below and delete one of the conflicted files (you can choose smallest one by size) from your fatJar. Run the fatJar and check the logging is working properly.
\META-INF\org\apache\logging\log4j\core\config\plugins\Log4j2Plugins.dat
Now we can check the dependencies (artifacts) and find which of them contain the "Log4j2Plugins.dat" files. So you can exclude the modules that have the file from your build tool and then your fatJar creation process will exclude the conflicted files and your new fatJar can start logging as expected.
In my case, my fatJar module imports some other modules from Spring Boot and when i exclude the conflicted logging libraries, my fatJar starts logging without any error.
configurations {
all*.exclude module: 'spring-boot'
all*.exclude module: 'spring-boot-starter-logging'
all*.exclude module: 'logback-classic'
all*.exclude module: 'commons-logging'
}

How can I make Tycho load platform specific fragment into the test runtime for any OS?

I'm using Tycho to build and test some eclipse plugins. I have one bundle that has many platform specific fragments. I also have one test bundle that is using tycho-surefire-plugin to test the original bundle that has the platform specific fragments. However, Tycho is not including the current platform's fragment into the test runtime.
All of the platform specific fragments look like the win64 fragment manifest listed below. (There are actually six fragments in total, one for each platform combination I need to support.)
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: Liferay AUI Upgrade Tool Win64
Bundle-SymbolicName: com.liferay.laut.win32.win32.x86_64;singleton:=true
Bundle-Version: 1.0.2.qualifier
Bundle-RequiredExecutionEnvironment: JavaSE-1.6
Fragment-Host: com.liferay.ide.alloy.core
Eclipse-BundleShape: dir
Eclipse-PlatformFilter: (& (osgi.ws=win32)(osgi.os=win32)(osgi.arch=x86_64))
Bundle-Vendor: Liferay, Inc.
Example win64 fragment pom.xml's <build> section
<build>
<plugins>
<plugin>
<groupId>org.eclipse.tycho</groupId>
<artifactId>target-platform-configuration</artifactId>
<configuration>
<environments>
<environment>
<os>win32</os>
<ws>win32</ws>
<arch>x86_64</arch>
</environment>
</environments>
</configuration>
</plugin>
</plugins>
</build>
When I try to execute my Tycho build and it runs the surefire test plugin (no matter which OS I try), the correct platform fragment is not added into the runtime.
I've seen various posts on stackoverflow about similar questions but in those cases the fragments loaded into the test runtime were not platform-specific fragments with OS filters.

This is a good question - but if you know the right trick, the solution is fortunately not complicated: Simply configure Tycho to include the feature which contains all fragments into the test runtime.
Create a feature in an eclipse-feature module which includes all
the native fragments. Make sure that the platform filters for each
plug-in is correct: On the Plug-Ins tab of the feature.xml editor,
you need to select the correct os/ws/arch that each fragment applies
to. This is some manual effort, but typically can re-use this
feature to include your fragments into a p2 repository/update site.
Include this feature into the test runtime with the following POM configuration:
<plugin>
<groupId>org.eclipse.tycho</groupId>
<artifactId>target-platform-configuration</artifactId>
<version>${tycho-version}</version>
<configuration>
<dependency-resolution>
<extraRequirements>
<requirement>
<type>eclipse-feature</type>
<id>fragment-containing-feature</id>
<versionRange>0.0.0</versionRange>
</requirement>
</extraRequirements>
</dependency-resolution>
</configuration>
</plugin>
A potential pitfall is the <environments> configuration of the eclipse-feature module: You don't need anything special for that module; just have the module inherit the <environments> configuration from the parent POM. Note that the parent POM shall configure all the environments your build supports - and only the fragment modules need to override the global configuration.

Send/redirect/route java.util.logging.Logger (JUL) to Logback using SLF4J?

Is it possible to have a typical call to java.util.logging.Logger and have it route to Logback using SLF4J? This would be nice since I wouldn't have to refactor the old jul code line by line.
EG, say we have this line:
private static Logger logger = Logger.getLogger(MahClass.class.getName());
//...
logger.info("blah blah blah");
It would be nice to configure this to call through SLF4J.

It's very easy and not a performance issue anymore.
There are two ways documented in the SLF4J manual. There are also precise examples in the Javadocs
Add jul-to-slf4j.jar to your classpath. Or through maven dependency:
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>jul-to-slf4j</artifactId>
<version>1.7.0</version>
</dependency>
If you don't have logging.properties (for java.util.logging), add this to your bootstrap code:
SLF4JBridgeHandler.removeHandlersForRootLogger();
SLF4JBridgeHandler.install();
If you have logging.properties (and want to keep it), add this to it:
handlers = org.slf4j.bridge.SLF4JBridgeHandler
In order to avoid performance penalty, add this contextListener to logback.xml (as of logback version 0.9.25):
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<contextListener class="ch.qos.logback.classic.jul.LevelChangePropagator">
<!-- reset all previous level configurations of all j.u.l. loggers -->
<resetJUL>true</resetJUL>
</contextListener>
...
</configuration>