Jboss 7 classpath and external properties

C:\jboss-as-7.1.1.Final\bin>standalone.bat -P=C:\jboss-as-7.1.1.Final\modules\xxxxx\xxxx.properties

-P or –properties, would load the specified properties into jboss system environment

See boot.log with above properties:

	12:31:56,005 INFO  [org.jboss.modules] JBoss Modules version 1.1.1.GA
	12:31:56,137 INFO  [org.jboss.msc] JBoss MSC version 1.0.2.GA
	12:31:56,168 INFO  [org.jboss.as] JBAS015899: JBoss AS 7.1.1.Final "Brontes" starting
	12:31:56,170 DEBUG [org.jboss.as.config] Configured system properties:
		FPW.details.sql = SELECT  xxxxxx
		awt.toolkit = sun.awt.windows.WToolkit
		camel.context.startonboot = true
		camel.scan.class.resolver = org.apache.camel.jboss.JBossPackageScanClassResolver

		java.net.preferIPv4Stack = true
		java.runtime.name = Java(TM) SE Runtime Environment
		java.runtime.version = 1.6.0_31-b05
		java.specification.name = Java Platform API Specification
		java.specification.vendor = Sun Microsystems Inc.
		java.specification.version = 1.6
		java.util.logging.manager = org.jboss.logmanager.LogManager
		java.vendor = Sun Microsystems Inc.
		java.vendor.url = http://java.sun.com/
		java.vendor.url.bug = http://java.sun.com/cgi-bin/bugreport.cgi
		java.version = 1.6.0_31
		java.vm.info = mixed mode
		java.vm.name = Java HotSpot(TM) 64-Bit Server VM
		java.vm.specification.name = Java Virtual Machine Specification
		java.vm.specification.vendor = Sun Microsystems Inc.
		java.vm.specification.version = 1.0
		java.vm.vendor = Sun Microsystems Inc.
		java.vm.version = 20.6-b01
		javax.management.builder.initial = org.jboss.as.jmx.PluggableMBeanServerBuilder
		javax.xml.datatype.DatatypeFactory = __redirected.__DatatypeFactory
		javax.xml.parsers.DocumentBuilderFactory = __redirected.__DocumentBuilderFactory
		javax.xml.parsers.SAXParserFactory = __redirected.__SAXParserFactory
		javax.xml.stream.XMLEventFactory = __redirected.__XMLEventFactory
		javax.xml.stream.XMLInputFactory = __redirected.__XMLInputFactory
		javax.xml.stream.XMLOutputFactory = __redirected.__XMLOutputFactory
		javax.xml.transform.TransformerFactory = __redirected.__TransformerFactory
		javax.xml.validation.SchemaFactory:http://www.w3.org/2001/XMLSchema = __redirected.__SchemaFactory
		javax.xml.xpath.XPathFactory:http://java.sun.com/jaxp/xpath/dom = __redirected.__XPathFactory
		jboss.home.dir = C:\jboss-as-7.1.1.Final

	12:31:56,231 DEBUG [org.jboss.as.config] VM Arguments: -XX:+TieredCompilation -Dprogram.name=standalone.bat -Xms64M -Xmx512M -XX:MaxPermSize=256M -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djava.net.preferIPv4Stack=true -Dorg.jboss.resolver.warning=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djboss.server.default.config=standalone.xml -Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=n -Dorg.jboss.boot.log.file=C:\jboss-as-7.1.1.Final\standalone\log\boot.log -Dlogging.configuration=file:C:\jboss-as-7.1.1.Final\standalone/configuration/logging.properties
	12:31:56,874 INFO  [org.xnio] XNIO Version 3.0.3.GA
	12:31:56,874 INFO  [org.jboss.as.server] JBAS015888: Creating http management service using socket-binding (management-http)
	12:31:56,882 INFO  [org.xnio.nio] XNIO NIO Implementation Version 3.0.3.GA
	12:31:56,888 INFO  [org.jboss.remoting] JBoss Remoting version 3.2.3.GA
	12:31:56,956 INFO  [org.jboss.as.security] JBAS013101: Activating Security Subsystem
	12:31:56,969 INFO  [org.jboss.as.webservices] JBAS015537: Activating WebServices Extension
	12:31:56,983 INFO  [org.jboss.as.logging] JBAS011502: Removing bootstrap log handlers
	12:31:56,983 INFO  [org.jboss.as.connector] JBAS010408: Starting JCA Subsystem (JBoss IronJacamar 1.0.9.Final)
	12:31:56,996 INFO  [org.jboss.as.security] JBAS013100: Current PicketBox version=4.0.7.Final

Above properties are loaded into system properties and were from composerinterfacesmgr.properties.

However, if using above parameter alone, it still wont put the properties into classpath, so below spring application context configuration wont work:

<bean class="com.bfm.app.jmim.conf.Configurer">
	<property name="locations">
		<list>
			<value>classpath:xxxx.properties</value>
		</list>
	</property>
</bean>

To resolve, as for current, the only solution is to create new modules, and put the properties inside the module, and specify to depend on this module in jboss-deployment-structure.xml: https://community.jboss.org/wiki/HowToPutAnExternalFileInTheClasspath

<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.1">
	<deployment>
		<exclusions>
			<module name="org.apache.log4j" />
			<module name="org.slf4j" />
			<module name="org.slf4j.impl" />
			<module name="org.slf4j.ext" />
            <module name="org.slf4j.jcl-over-slf4j" />
			<module name="org.apache.commons.logging" />
			<module name="org.jboss.logging.jul-to-slf4j-stub" />
			<module name="org.jboss.logging" />
			<module name="org.jboss.as.logging" />
		</exclusions>
		<dependencies>
			<module name="org.osgi.core" />
			<module name="com.xxxx.xxxx" />
		</dependencies>
<!-- 		<resources> -->
<!-- 			<resource-root path="xxxx.properties" /> -->
<!-- 		</resources> -->
	</deployment>
</jboss-deployment-structure>

With above two together, the application would work. If only create a module, and put the properties into classpath, it might not work either. For example, log4j.xml,


    <appender name="emailAppender" class="org.apache.log4j.net.SMTPAppender">
	<param name="Threshold" value="DEBUG"/>
	<param name="To" value="${smtp.error.recipient}" />
    <param name="BufferSize" value="1" />
	<layout class="org.apache.log4j.PatternLayout">
		<param name="ConversionPattern" value="%d %-5p [%t] %c{2} (%F:%L) - %m%n" />
	</layout>
</appender>

Above requires a system property or at least the classloader of log4j aware of. So the first change, specify the -P / –properties needed to put that properties into system environment.

Good concise explanation on jvm memeory

As we know objects are created inside heap memory and Garbage collection is a process which removes dead objects from Java Heap space and returns memory back to Heap in Java. For the sake of Garbage collection Heap is divided into three main regions named as New Generation, Old or Tenured Generation and Perm space. New Generation of Java Heap is part of Java Heap memory where newly created object are stored, During the course of application many objects created and died but those remain live they got moved to Old or Tenured Generation by Java Garbage collector thread on Major or full garbage collection. Perm space of Java Heap is where JVM stores Meta data about classes and methods, String pool and Class level details. You can see How Garbage collection works in Java for more information on Heap in Java and Garbage collection.

Log4j email appender is default to ERROR level

I have been keeping wondering why my email appender is not working. The log4j xsd might be better if they can provide feedback on malformed configuration. Combine Threshold or logger level with SMTPAppender, without throwing exception is really confusing. While the only way to change logging level for SMTPAppender is actually implement and provide TriggeringEventEvaluator.

http://stackoverflow.com/questions/3544269/log4j-smtp-digest-aggregate-emails

By default, an email message will be sent when an ERROR or higher severity message is appended. The triggering criteria can be modified by setting the evaluatorClass property with the name of a class implementing TriggeringEventEvaluator, setting the evaluator property with an instance of TriggeringEventEvaluator or nesting a triggeringPolicy element where the specified class implements TriggeringEventEvaluator. 

while the xsd never warns the combination of threshold and levels with SMTPAppender,is confusing:

	<appender name="emailAppender" class="org.apache.log4j.net.SMTPAppender">
		<param name="SMTPHost" value="mailhost.core.blackrock.com" />
		<param name="Threshold" value="DEBUG"/>

	<logger name="com.bfm.app.xxxx">
		<level value="info" />
		<appender-ref ref="emailAppender" />

Known bug between JAXB and Camel

https://issues.apache.org/jira/browse/CAMEL-4955:

https://java.net/jira/browse/JAXB-860;

basically, if using Jaxb-api; jaxb-impl version 2.2.x, and camel version before 2.10 (not yet released), it might on-off/intermittent throwing NPE exception, while parsing camel-context xml.

The NPE is about com/sun/xml/bind/v2/runtime/ClassBeanInfoImpl.checkOverrideProperties()

I have encountered above exception, on off when deploying a web application, onto Jboss 7.1.1. Because default jaxb module in jboss 7, is
C:\jboss-as-7.1.1.Final\modules\javax\xml\bind\api\main\jboss-jaxb-api_2.2_spec-1.0.3.Final

put the old versioned jaxb library into application library folder, seems solved the problem for now. I might need to exclude the jboss jaxb module in jboss-deployment-structure.xml if needed later.

some references

https://community.jboss.org/message/739232


Interesting.
It works now, I've just rolled back JAXB Version inside JBOSS.
 
If anyone has the same problem, the solution for JBOSS 7.1.1 FInal is:
 
Go into $JBOSS_HOME/modules/com/sun/xml/bind/main
delete all files (jaxb-impl-2.2.4.jar, jaxb-xjc-2.2.4.jar etc, 5 files)
 
The simplest way is to take the same module, version 2.2, from JBOSS 7.0.1, it has jaxb 2.2, just copy all 5 files from
jboss_7.0.1/modules/com/sun/xml/bind/main/*
to
jboss_7.1.1.Final/modules/com/sun/xml/bind/main/
 
I am using camel 2.9.2 again, no snapshot version (or 2.10) necessary.
 
I've started and stopped it again at least 10 times, it's working. Now I understand, why I did not get such a trouble with jboss 7.0.1.
 
it could be also helpful:
http://java.net/jira/browse/JAXB-860

Pasted from <https://community.jboss.org/message/739232> 


===============================================================

Reading between the lines I think you have encountered an incompatibility between Apache Camel and JAXB 2.2 (which is part of the standard JEE6 spec and also incorporated into Java 7).
 
It looks like the Camel folks are actively working on a fix for their 2.10.0 release.

Pasted from <https://community.jboss.org/message/739232> 

================================================================

https://issues.apache.org/jira/browse/CAMEL-4955
Due to a bug of JAXB RI included in JDK 7, (see http://java.net/jira/browse/JAXB-860)
NPE raised while creating CamelContext in camel-spring. I't a show-stopper for everyone using camel-spring with JDK 7.
related mailing list thread: http://mail-archives.apache.org/mod_mbox/camel-users/201108.mbox/%3CCAJ_S2Sn+Y692R48yrYBZoB66Pz1YPC6H-i=ZozBFPa=G54D78w@mail.gmail.com%3E


Pasted from <https://issues.apache.org/jira/browse/CAMEL-4955> 

Java class loading again jboss XML Apis

XML-Apis.jar and others like xerces.jar, jaxb.jar etc almost always cause problem during deployment. The solution is almost always continue using Jdk or container provided library, instead of duplicating these inside application ear or war.

If mandatory to deploy own specified version of above library, endorsed library or jboss-class-loading XML, or jboss-deployment-structure.xml should be configured.