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.
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 deploying all necessary Jetty bundles to an OSGi-container and launch a server instance. Yet although I'm deploying jetty-webapp and the corresponding jar contains the file org\eclipse\jetty\webapp\webdefault.xml, at startup I'm presented the error
java.io.FileNotFoundException: D:\eclipse\org\eclipse\jetty\webapp\webdefault.xml
(D:\eclipse is the eclipse installation I'm launching from)
Why isn't Jetty using the file it comes with? When I copy the file from the jar to the requested location, Jetty runs fine - but that can't be a feasible solution.
I wouldn't mind having to provide the file, but then again I don't know how to pass the path to Jetty. The launch happens directly from within an eclipse launch configuration, no maven involved.
If you use jetty-osgi-boot.jar, than you have to set the following system properties:
-Djetty.home.bundle=org.eclipse.jetty.osgi.boot
-Djetty.port=8080
The value is the symbolic name of the osgi-boot bundle that contains a default configuration.
More info in the documentation of jetty: http://www.eclipse.org/jetty/documentation/current/framework-jetty-osgi.html
Alternatively you can use the org.apache.felix.http.jetty bundle. You can find information about it here: http://felix.apache.org/documentation/subprojects/apache-felix-http-service.html
Or you can use Pax Web: https://ops4j1.jira.com/wiki/display/paxweb/Advanced+Jetty+Configuration
I used the jetty-osgi before. Nowadays I use the felix stuff as it can be configured via configadmin. Pax-web can also be used via configAdmin. I have not tried it yet but as much as I heard it has its benefits (e.g. better servlet context handling with HTTPService)
I have DN 2.x on Eclipse RCP (currently Helios).
I'm having trouble Turning the DN LOG on.
I use log4j.properties, where i define all the DataNucleus Categories LOG levels.
It LOGS fine with the "external" enhancer (i just pass the argument on the "VM Arguments" of the RUN configurations -Dlog4j.configuration=file:"...\log4j.properties"), but can't get the log to work on the main app... tried the same approach with no success.
Anyone using DN with eclipse?
I don't use DN. So I can't address your problem, directly. I can say, in general, if you have an application using Log4j, it will search the classpath for files named log4j.properties and log4j.xml. In your case, try moving your log4j.properties file to a place you are 100% certain is in the classpath (like the root folder of all your packages).
From there, if your logging turns on, then you know your properties file isn't in the classpath. However, if your file is definitely in the classpath, then the culprit is likely something else turning off logging application-wide. Do you see logging at all? If not, then this is likely the problem. At that point you need to figure out which Facade you're using: apache commons or SLF4J. Both have the power to replace the logger implementation with NOOP loggers, which ignore all log requests.
With Commons, you have to check the commons-logging.properties file. With SLF4J, you have to check the project dependencies (usually in a lib directory somewhere), insuring that there isn't a NO-OP jar in the list.
I've recently written my first grails application.
The application is a "product" in that I'd like to build a single version of the application that can be deployed to multiple customers as a war file.
I need to be able to configure each application differently.
What is the "best practice" for deploying a grails application as a product.
I found this documentation after some searching on the grails site.
3.4 Externalized Configuration
The default configuration file Config.groovy in grails-app/conf is fine in the majority of cases, but there may be circumstances where you want to maintain the configuration in a file outside the main application structure. For example if you are deploying to a WAR some administrators prefer the configuration of the application to be externalized to avoid having to re-package the WAR due to a change of configuration.
In order to support deployment scenarios such as these the configuration can be externalized. To do so you need to point Grails at the locations of the configuration files Grails should be using by adding a grails.config.locations setting in Config.groovy:
grails.config.locations = [ "classpath:${appName}-config.properties",
"classpath:${appName}-config.groovy",
"file:${userHome}/.grails/${appName}-config.properties",
"file:${userHome}/.grails/${appName}-config.groovy"]
In the above example we're loading configuration files (both Java properties files and ConfigSlurper configurations) from different places on the classpath and files located in USER_HOME.
Ultimately all configuration files get merged into the config property of the GrailsApplication object and are hence obtainable from there.
See the section on External configuration at this link. I'm not sure if this will configure everything you need but it should be a start and will cover the basics such as data sources.