[JBoss Web Development] New message: "Log4j inside Jboss"
by Felipe Armoni
JBoss development,
A new message was posted in the thread "Log4j inside Jboss":
http://community.jboss.org/message/529364#529364
Author : Felipe Armoni
Profile : http://community.jboss.org/people/komyg
Message:
--------------------------------------------------------------
Hi, I've created a Web Service application inside Jboss 4.2.2-GA and I want to set up the jboss log4j configuration so that my Web Service logs inside a custom log file (not inside the server.xml).
To do this I've altered the jboss-log4j.xml file to create another appender. This file is below:
<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE log4j:configuration SYSTEM "log4j.dtd"><!-- ===================================================================== --><!-- --><!-- Log4j Configuration --><!-- --><!-- ===================================================================== --><!-- $Id: jboss-log4j.xml 65459 2007-09-19 00:25:51Z mailto:dimitris@jboss.org $ --><!-- | For more configuration infromation and examples see the Jakarta Log4j | owebsite: http://jakarta.apache.org/log4j --><log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/" debug="false"> <!-- ================================= --> <!-- Preserve messages in a local file --> <!-- ================================= --> <!-- A time/date based rolling appender --> <appender name="FILE" class="org.jboss.logging.appender.DailyRollingFileAppender"> <errorHandler class="org.jboss.logging.util.OnlyOnceErrorHandler"/> <param name="File" value="${jboss.server.log.dir}/server.log"/> <param name="Append" value="false"/> <!-- Rollover at midnight each day --> <param name="DatePattern" value="'.'yyyy-MM-dd"/> <!-- Rollover at the top of each hour --> <layout class="org.apache.log4j.PatternLayout"> <!-- The default pattern: Date Priority Category Message\n --> <param name="ConversionPattern" value="%d %-5p %m%n"/> <!-- The full pattern: Date MS Priority Category (Thread:NDC) Message\n <param name="ConversionPattern" value="%d %-5r %-5p (%t:%x) %m%n"/> --> </layout> </appender> <!-- A size based file rolling appender <param name="ConversionPattern" value="%d %-5p %m%n"/> </layout>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </appender> --> <!-- ============================== --> <!-- Append messages to the console --> <!-- ============================== --> <appender name="CONSOLE" class="org.apache.log4j.ConsoleAppender"> <errorHandler class="org.jboss.logging.util.OnlyOnceErrorHandler"/> <param name="Target" value="System.out"/> <param name="Threshold" value="INFO"/> <layout class="org.apache.log4j.PatternLayout"> <!-- The default pattern: Date Priority Category Message\n --> <!-- <param name="ConversionPattern" value="%d %-5p %m%n"/> -->&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <param name="ConversionPattern" value="%-5p (%t:%x) %m%n"/> </layout> </appender> <!-- ====================== --> <!-- More Appender examples --> <!-- ====================== --> <!-- Buffer events and log them asynchronously <appender name="ASYNC" class="org.apache.log4j.AsyncAppender"> <errorHandler class="org.jboss.logging.util.OnlyOnceErrorHandler"/> <appender-ref ref="FILE"/> <appender-ref ref="CONSOLE"/> <appender-ref ref="SMTP"/> </appender> --> <!-- EMail events to an administrator <appender name="SMTP" class="org.apache.log4j.net.SMTPAppender"> <errorHandler class="org.jboss.logging.util.OnlyOnceErrorHandler"/> <param name="Threshold" value="ERROR"/> <param name="To" value="mailto:admin@myhost.domain.com"/> <param name="From" value="mailto:nobody@myhost.domain.com"/> <param name="Subject" value="JBoss Sever Errors"/> <param name="SMTPHost" value="localhost"/> <param name="BufferSize" value="10"/> <layout class="org.apache.log4j.PatternLayout"> <param name="ConversionPattern" value="[%d,%c] %m%n"/> </layout> </appender> --> <!-- Syslog events <appender name="SYSLOG" class="org.apache.log4j.net.SyslogAppender"> <errorHandler class="org.jboss.logging.util.OnlyOnceErrorHandler"/> <param name="Facility" value="LOCAL7"/> <param name="FacilityPrinting" value="true"/> <param name="SyslogHost" value="localhost"/> <layout class="org.apache.log4j.PatternLayout"> <param name="ConversionPattern" value="[%d,%c] %m%n"/> </layout> </appender> --> <!-- Log events to JMS (requires a topic to be created) --> <!-- Log events through SNMP --> <!-- Emit events as JMX notifications <param name="ConversionPattern" value="%d %-5p %m"/> </layout> </appender> --> <!-- ================ --> <!-- Limit categories --> <!-- ================ --> <!-- Limit the org.apache category to INFO as its DEBUG is verbose --> <category name="org.apache"> <priority value="INFO"/> </category> <!-- Limit the jacorb category to WARN as its INFO is verbose --> <category name="jacorb"> <priority value="WARN"/> </category> <!-- Limit the org.jgroups category to WARN as its INFO is verbose --> <category name="org.jgroups"> <priority value="WARN"/> </category> <!-- Limit the org.quartz category to INFO as its DEBUG is verbose --> <category name="org.quartz"> <priority value="INFO"/> </category> <!-- Limit JBoss categories --> <!-- Limit the JSR77 categories --> <category name="org.jboss.management"> <priority value="INFO"/> </category> <!-- Show the evolution of the DataSource pool in the logs inUse/Available/Max --> <!-- Limit the org.jboss.serial (jboss-serialization) to INFO as its DEBUG is verbose --> <category name="org.jboss.serial"> <priority value="INFO"/> </category> <!-- Decrease the priority threshold for the org.jboss.varia category --> <!-- Enable JBossWS message tracing --> <!-- | An example of enabling the custom TRACE level priority that is used | by the JBoss internals to diagnose low level details. This example | turns on TRACE level msgs for the org.jboss.ejb.plugins package and its | subpackages. This will produce A LOT of logging output. | | Note: since jboss AS 4.2.x, the trace level is supported natively by | log4j, so although the custom org.jboss.logging.XLevel priority will | still work, there is no need to use it. The two examples that follow | will both enable trace logging. --> <!-- | Logs these events to SNMP: - server starts/stops - cluster evolution (node death/startup) - When an EJB archive is deployed (and associated verified messages) - When an EAR archive is deployed &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; --> <!-- Clustering logging --> <!-- Uncomment the following to redirect the org.jgroups and org.jboss.ha categories to a cluster.log file. <param name="ConversionPattern" value="%d %-5p %m%n"/> --> <!-- Afis Appender --> <appender name="AfisAppender" class="org.jboss.logging.appender.DailyRollingFileAppender"> <errorHandler class="org.jboss.logging.util.OnlyOnceErrorHandler"/> <param name="File" value="${jboss.server.log.dir}/afis_interface.log"/> <param name="Append" value="false"/> <!-- Rollover at midnight each day --> <param name="DatePattern" value="'.'yyyy-MM-dd"/> <layout class="org.apache.log4j.PatternLayout"> <param name="ConversionPattern" value="%d %-5p (%t:%x) %m%n"/> </layout> </appender> <category name="AfisLogger">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <appender-ref ref="AfisAppender"/>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <appender-ref ref="CONSOLE"/>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <priority value="DEBUG"/> </category> <!-- ======================= --> <!-- Setup the Root category --> <!-- ======================= -->
After that I created a logger inside my Web Service with the same name as the category tag and logged the message received by the service:
logger = Logger.getLogger("AfisLogger");
logger.debug(message);
However I noticed that even though the log file afis_interfaces.log is indeed created, it remains empty as if I wasn't writing anything to it.
Please help me.
Thanks,
Komyg
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/529364#529364
15 years, 7 months
[JBoss Microcontainer Development] New message: "ClassLoadingAdmin"
by Adrian Brock
JBoss development,
A new message was posted in the thread "ClassLoadingAdmin":
http://community.jboss.org/message/529360#529360
Author : Adrian Brock
Profile : http://community.jboss.org/people/adrian@jboss.org
Message:
--------------------------------------------------------------
To mirror what is available in OSGi's PackageAdmin class, I've created a ClassLoadingAdmin interfacethat is implemented by both ClassLoading and Domain.
https://svn.jboss.org/repos/jbossas/projects/jboss-cl/trunk/classloading/...
along with some supporting classes.
This required tidying up the way dependencies were stored for Modules for a number of reasons.
1) The cleanup of dependsOnMe() had some problems, there was a TODO in the code about it.
2) When using ShutdownPolicy=GARBAGE_COLLECTION (GC) the dependsOnMe() no longer gets updated on the DependencyInfo
so it needs to be maintained on the Module.
3) We need to keep track of dependencies after undeployment for the GC shutdown policy so we can handle
refreshModules(null) to re-resolve all deployments that have dependencies that are out-of-date.
4) Some of the queries need to be look at specific types of dependencies, e.g. those exporting a package or importing a module.
The major changes in this are;
* the remembering of the "resolvedModule" in the RequirementsDependencyItem and maintaining it
properly, including the dependsOnMe processing.
* holding a set of "lazyShutdownModules" in the Module class that get cleaned up after calls to refreshModules().
There's probably some other stuff that can get added ClassLoadingAdmin? e.g. those importing a package.
For now I've just been guided by what is available in OSGi, although I have generalized some of that api.
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/529360#529360
15 years, 7 months
[JBoss Microcontainer Development] New message: "Deployment lazyResolve and lazyStart"
by Adrian Brock
JBoss development,
A new message was posted in the thread "Deployment lazyResolve and lazyStart":
http://community.jboss.org/message/529354#529354
Author : Adrian Brock
Profile : http://community.jboss.org/people/adrian@jboss.org
Message:
--------------------------------------------------------------
With https://jira.jboss.org/jira/browse/JBDEPLOY-247
You can now do lazyResolve and lazyStart for deployments.
However, beyond what OSGi will do there's nothing that actually sets this up.
I propose we add a new META-INF/jboss-deployment.xml which would be some generic
metadata for this kind of processing and other possible deployment control parameters.
e.g. something like
<deployment xmlns="urn:jboss:deployment:1.0">
<!-- Deploy this deployment in the described stage initially - i.e. no classloader -->
<required-stage>DESCRIBE</required-stage>
<!-- Only create the classloader when somebody wants to import our package or module -->
<lazy-resolve/>
<!-- Only move the deployment to the REAL stage when somebody loads a class from our classloader - with an optional filter -->
<lazy-start filter="com.acme.somepackage"/>
</deployment>
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/529354#529354
15 years, 7 months
[JBoss Microcontainer Development] New message: "How to migrate AssembledDirectory"
by Thomas Diesler
JBoss development,
A new message was posted in the thread "How to migrate AssembledDirectory":
http://community.jboss.org/message/529343#529343
Author : Thomas Diesler
Profile : http://community.jboss.org/people/thomas.diesler@jboss.com
Message:
--------------------------------------------------------------
How do I migratethis to VFS 3.0
public VirtualFile assembleBundle(String name, String[] resourcePaths, Class<?>... packages) throws Exception
{
AssembledDirectory assembledDirectory = createAssembledDirectory(name, "", resourcePaths, packages);
return assembledDirectory;
}
public Bundle deployBundle(String name, OSGiMetaData metaData, String resourcePath, Class<?>... packages) throws Exception
{
AssembledDirectory assembledDirectory = createAssembledDirectory(name, "", new String[] { resourcePath }, packages);
return deployBundle(assembledDirectory, metaData);
}
public Bundle deployBundle(String name, OSGiMetaData metaData, String[] resourcePaths, Class<?>... packages) throws Exception
{
AssembledDirectory assembledDirectory = createAssembledDirectory(name, "", resourcePaths, packages);
return deployBundle(assembledDirectory, metaData);
}
This question relates to the more general issue of VFS not beeing documented adequaltely.
https://jira.jboss.org/jira/browse/JBVFS-113
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/529343#529343
15 years, 7 months
[Javassist Development] New message: "A few Javassist proxy patches"
by Mark Struberg
JBoss development,
A new message was posted in the thread "A few Javassist proxy patches":
http://community.jboss.org/message/529280#529280
Author : Mark Struberg
Profile : http://community.jboss.org/people/struberg
Message:
--------------------------------------------------------------
Hi!
I'm working on Apache OpenWebbeans and we use javassist - so first of all thanks for providing it!
I found a few issues which are mainly based on the way javassist got used in many projects, which caused loss of permgenspace with every invocation. I tried to address this with a few patches.
The problem is caused by the current javassist usage pattern of calling ProxyFactory.createClass().newInstance() which currently (due to the broken cache), always creates a new class for the proxy. And once this class gets classloaded, you cannot easily get rid of it from the ClassLoaders class map. In the worst case the generated proxy class gets registered in the SystemClassLoader and can never get freed again. Another problem is that setting the default method handler with ProxyFactore.setMethodHandler() will store this MethodHandler in a static field, thus the class will hold a reference to this MethodHandler - even if it is not used anymore. Thus the MethodHandler (and all the instances it references) imo can never get garbage collected.
There were also a few problems with deserialization, mainly because it did drop the assigned MehodHandler and used the DefaultMethodHandler instead. I added new bytecode to support MethodHandler serialization along with the proxyInstance.
To understand my need: instead of creating a fresh proxyClass every time, I switched OWB to use the following pattern
1.) ProxyFactory.useCache = false; since the current implementation fo the internal class cache imo inherently creates mem losses
2.) create the ProxyFactory only once and cache this class in our own code:
2.a) ProxyFactory pf = new ProxyFactory()
2.b) pf.setInterfaces(...);
2.c) pf.setSuperclass(...);
2.d) Class proxyClass = pf.creatClass();
3.) create a new proxy instance with it's own MethodHandler by always only using the same cached proxy Class for a certain original class
Object proxyInstance = proxyClass.newInstance(); +
((ProxyObject)proxyInstance).setHandler(new BeanMethodHandler(beaninfo));
I didn't really need the MethodFilter in my use cases, so we need think about where this fits into the picture.
Most foundings are explained in my patches available at github
http://github.com/struberg/javassist
Those patches are tested with OpenWebBeans and Weld (thanks to David R. Allen), but I'm sure there is still room for improvement
One of the areas I'm not 100% sure is deserialization on another VM which may already contain other proxy classes of that kind (with different javassist name). I now check if the interfaces and the superclass is the same if I found a javassist proxyClass with Class.forName on deserialization, maybe there is something missing still.
This szenario mainly may concern replication in big clusters, and the behaviour of the patched version is of course heavily improved at least.
Oh yes, we should really cleanup the pom.xml!
I can volunteer with all the maven stuff too if needed.
txs and LieGrue,
strub
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/529280#529280
15 years, 7 months