I've written a custom log4j appender that creates a new Solr document for each log entry and I'm having problems deploying it to JBoss.
The source is viewable on github but the real problem is trying to use the appender from JBoss.
The relevent bits of jboss-log4j.xml look like this:
<appender name="SOLR" class="com.stuartgrimshaw.solrIndexAppender.SolrIndexAppender" />
<root>
<priority value="${jboss.server.log.threshold}"/>
<appender-ref ref="CONSOLE"/>
<appender-ref ref="FILE"/>
<appender-ref ref="SOLR"/>
</root>
The dependencies for Solr are all available in the .war file that's supplied, but I'm guessing that when the appender is initialised quite early on in the boot process, that application hasn't been deployed yet, which is why I see this error in the log:
2009-11-29 10:40:57,715 ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] (main) Error installing to Create: name=jboss.system:service=Logging,type=Log4jService state=Configured mode=Manual requiredState=Create
java.lang.NoClassDefFoundError: org/apache/solr/client/solrj/SolrServerException
Is there any way I can delay the initialization till the solr app has been deployed, or is there a way to deploy the Solr app so it's libraries are visible to jboss while it boots?
I think you could either deploy the Solr libs in server/[jboss-configuration]/lib (in JBoss 4 that is, might be the same in newer versions), then they are available at boot time.
Or don't use the JBoss log4j configuration and define your own log4j.xml in your WAR (either in a JAR in lib or in classes). It will be loaded by the application classloader when it is deployed.
As you've discovered, you'd have to put your JAR into the JBoss config's lib directory in order to refer to its types in jboss-log4j.xml, but this is generally not good practise.
A pretty straightward alternative is to invoke the log4j API programmatically from inside your application. If you have a WAR, then define a ServetContextListener (or something similar) which is invoked when the WAR deploys, and which attaches your appender. Similarly, when undeployed, it detaches the appender.
See the answer to this previous question for how to get started doing this.
I am guessing that this is to manage your log files and make them easier to search, a la Splunk???? However, this feels like a fairly odd way of doing this.. kind of the "look, I can make a dog walk on it's hind legs" kind of thing... Cool, but why would you want to?
I think a much simpler, more robust approach is to a) grab Splunk Free Edition! b) have a seperate process that consumes your log files from disk and send them to Solr using Solr4J.
I think requiring Solr, just to do logging adds a huge level of complexity.
Related
I have an OSGi application (Eclipse plugin) that contains several bundles.
I have a com.domain.dependencies bundle that, as the name suggests, contains dependencies. There is NO code in this bundle. The concept is that all 3rd-party dependencies used by 1+ other bundles are contained in this bundle and made available to other bundles within the plugin. This has always worked for the past decade or so that this plugin has evolved.
The above bundle 'pulls in' log4j - an older log4j version 1.x. So, log4j has always been exposed as an available library to other bundles that use com.domain.dependencies.
Due to the recent security issues with log4j2, a company security directive/edict has stated that all use of log4j or log4j2 must be upgraded to log4j2 v2.16.0
Initially I thought I'd just change the declaration in the build.gradle file for com.domain.dependencies to pull in that newer log4j2 but discovered that log4j2 is split in to 'core' and 'api' jars. OK so I tried to use those instead. I then followed the Apache migration steps for moving from log4j 1.x to 2.x, updated all the code etc.
After the above, compilation fails. None of the other bundles 'see' log4j2 as they saw log4j. A bit of Googling and I see people talk about creating OSGi Fragments. What's a Fragment? I've read a bit about them and feel none the wiser when it comes to my issue.
I should point out that my plugin also has a dedicated bundle com.domain.log, which depends on com.domain.dependencies and it's the com.domain.log bundle that contains the log4j.properties file (which also needs tweaking for log4j2). This logging bundle wrapped log4j (and soon to be log4j2) to expose logging features to the other bundles within the plugin.
So when it comes to using fragments, I am confused. I see some articles on the internet suggest at least 2 bundles are required. I don't know if these have to be new, or if I can re-use my existing arrangement of bundles. I struggle to relate those articles to how things are currently set up in my plugin, but I wish to maintain the idea that com.domain.dependencies supplies dependencies to other bundles and has no code of itself, while also having the com.domain.log continue to expose the same logging functionality to the other bundles that need it.
My instinctive feelings are that com.domain.log which exposes logging functionality to my other bundles, should use log4j-api, while com.domain.dependencies should obtain log4j-core (implementation) and expose it to com.domain.log. However, I can imagine too many different ways to try and set this up, and all will fail unless I am doing it the right way. Basically, I need help from somebody who knows how to in an OSGi environment.
So, how should I wire-in log4j2 to mimic the traditional behaviour/functionality in my OSGi environment?
I have a possibly unique problem. We are using a thirdparty web library that uses log4j to log. Currently, our apps are set up to use the JBoss native logging.(We do this so we can vary the log printouts per environment)
The Thirdparty war file requires us to have a log4j.xml baked into the war its deployed in. Obviously we don't want that.
Here is what I have tried.
I have tried removing it and seeing if it will use the native jboss logger setup.
I have tried setting -Dlog4j.configuration to the path of the log4j.xml file.
I tried setting a system property of the jboss eap in the standalone-full file with the same name.
I dont have access to the source code, but I can decompile.
Any ideas?
I'm using Wildfly 11 with Java 8. If I deploy two WAR files with identical libraries
/WEB-INF/lib/javassist-3.18.1-GA.jar
Is there any advantage to including these libraries in the /WEB-INF/jboss-deployment-structure.xml like so
<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2">
<deployment>
<dependencies>
...
<module name="org.javassist" />
as opposed to including the JAR in my WAR files? That is, do I cut down on memory due to class loading or any similar advantage?
More than any advantage in memory or performance (that JBoss modules claims it can do), i think JBoss modules are more for take advantage of reuse of modules, or separate versions of the same module.
If you check the structure of the JBoss modules in file system, it remembers maven repository style, in this way you can review more easily the modules and versions available, or you can check the dependencies with the same tools of JBoss AS, as CLI or the Web console.
If you have an application and you can't scale a version of a specific framework/library you can stay with it, and you can have other applications with other versions of the same library. I know you can reach the same when you embed your jars into your application, but you have to do the same thing in all of your apps, with JBoss modules you just have to declare your dependencies and your application will be more lightweight.
In JBoss modules every jar you configure are a module, and every module has its own class loader(modular class loader), and every class loader knows exactly what classes it has to load (and its dependencies if apply), against a flat class loader (hierarchical), that loads all classes. This architecture makes JBoss modules faster (basically because is a new way to do the same thing of its ancestor, the JDK class loader).
In this link, you can check a more specific guide of JBoss modules that explains more concepts and surely has a better explanation.
In this link, you can find a short review and a pair of examples.
Hope this helps.
We need to display JBoss log files from within our web application. Is it possible to achieve this without using ServerConfigLocator ? The application must be able to run also with Websphere and we don't want dependencies on specific JARs.
JBoss's defined log directory is held in the jboss.server.log.dir system property. You can resolve that directory to a java.io.File, and read the files inside.
File logDir = new File(System.getProperty("jboss.server.log.dir"));
logDir.list(); // etc etc
You can also get this through ServerConfig.getServerLogDir() (on JBoss 4.x, anyway), but you said you wanted to avoid JAR dependencies.
You could use a custom log implementation. This would give you complete control over the logging behavior.
JBoss uses Log4j as its logging mechanism. WebSphere uses Jakarta Commons Logging, which can be configured to delegate to Log4j if it isn't already the default. If you already use Log4j in your application then I don't expect that this difference will cause you any new problems.
I would like to collect some best-practices on deployment of a web-application to a running Tomcat. Not long ago I had to describe the deployment process of our web-application and the process appeared rather confusing.
Say, we have an application in a WAR file (foo.war) correctly configured and not requiring additional configuration. In this case, the deployment process is rather easy:
Copy the foo.war file to the $CATALINA_HOME/webapps directory. If the application starts correctly, the application will automatically deploy to $CATALINA_HOME/webapps/foo directory.
To undeploy the application:
Remove the foo.war file from the $CATALINA_HOME/webapps. If the application unloads correctly, it will be unloaded and the $CATALINA_HOME/webapps/foo will be removed.
Now I want to override some context parameters in my running application. Having read the docs, all I need to do:
Create a context.xml file called foo.xml
Copy the file to the $CATALINA_BASE/conf/[enginename]/[hostname]/ directory.
Unfortunately, that did not work: the application would not restart. Empirically, we found out that the only working solution is when the war file is deployed to a location outside the $CATALINA_HOME/webapps.
Besides, the default values of the configurable context parameters in the WAR file should be specified in the web.xml, since context.xml in the WAR file is not read when there is a context.xml outside.
Here is an easy example of the foo.xml:
<?xml version='1.0' encoding='utf-8'?>
<Context docBase="/path-to-deployment-directory/foo.war">
<Parameter name="myparam" value="newvalue" override="false"/>
</Context>
Be sure to specify override=false for the parameter if you want the 'newvalue' to override the value specified in the WAR's web.xml. This was not obvious for us.
Thus, to deploy an aplication to a running Tomcat:
Create a context.xml file called foo.xml
Copy the file to the $CATALINA_BASE/conf/[enginename]/[hostname]/ directory.
Copy the foo.war to the location specified in the docBase of the foo.xml; the application will deploy automatically.
To apply new context parameters:
Add the parameter values to the foo.xml and save the file; the application will re-deploy automatically.
To undeploy the application:
Remove the foo.xml from the $CATALINA_BASE/conf/[enginename]/[hostname]/ directory
Note that removing the foo.war will also work, but will remove the foo.xml as well.
By now, I have the following questions:
Is it a best-practice at all to deploy a web-application without stopping the tomcat? I heard an opinion that deployment to a running tomcat is never needed since people run each application in a separate tomcat.
Is it a good idea to copy WAR files to $CATALINA_HOME/webapps or they should better be kept in a separate location?
How can I configure an application deployed to $CATALINA_HOME/webapps
Why there is no INFO line in the catalina.out for deployment of an application and there is one for undeployment? Is it configurable?
On question (1), Tomcat works great for deploying servlets into a running server. There may be concerns w.r.t. security or possibly D.O.S. or provisioning reasons why you would have separate server instances.
You have the flexibility to do either way, but it is often more convenient to deploy to an already running server. This is a BUILT-IN feature in the servlet architecture. :)
For (2), again it is at your discretion where you you want to put WARs. It sounds like you already have it configured a non-standard (non-default I should say) way. Check your server.xml file for the settings in your server instance(s). Check for attributes like unpackWARs and autoDeploy.
For (3) and (4), plus your (1,2) questions, it might be a good idea to consult the Tomcat docs for your version of Tomcat on its deployment model. You should be able to use the same docs to figure out how your server has been configured.
See Tomcat Web Application Deployment in the Tomcat manual, adjusting for your version of Tomcat.
One solution would be to use the manager application. If you decide that is safe to use it, then you can easily deploy, start, stop and undeploy applications:
http://localhost:8080/manager/deploy?path=[context_path]
http://localhost:8080/manager/start?path=[context_path]
http://localhost:8080/manager/stop?path=[context_path]
http://localhost:8080/manager/undeploy?path=[context_path]
There are ant tasks that can help you with these.
I am guessing, but do not know for sure, that stopping and starting an application will make it reread the context.xml.
Regarding your second question, I believe it is better for maintenance reasons to keep the war files in the webapps directory.