Develop Reference

Isn't it possible to configure logging INSIDE the application when using jboss AS 7.1.1.Final?

I read a lot but I couldn't figure out how I could specify for example the log level for specific classes.
Only way I could figure out was in the standalone.xml but why should I configure some application specific setting very general in the server? This complicates the deployment process unnecessary.
Isn't it somehow possible to define the specific log level and the output files somewhere inside the war without touching the server?
Btw. it doesn't matter if log4j or commons-logging or slf4j or whatever is used.

Using a logging.properties file or a log4j configuration file in your deployment will work in JBoss EAP 6.x and WildFly (formerly JBoss AS). Note though that a log4j configuration would only work if you use log4j for your logging facade.
That said I agree with Marko that this should probably be done in the server configuration. I would also encourage you to use the CLI or web interface rather than editing the raw XML as well. You can get some more information on the documentation.

I am sorry for not providing a direct answer, but consider this: the application being in charge of logging levels is a bad idea most of the time as this is something an AS admin should be able to change at any time. For example, the point of the DEBUG or TRACE log levels is to be able to place a lot of such statements in the code without hurting the production server's performance. However, once a bug is detected, you want to be able to lower the logging level without rebuilding the application. This should be a purely administrative task.
On the other hand, I do recognize the need to at least have a decent starting point for the logging configuration and I don't know of any architecture which would allow the application to provide defaults which are overridable by the server configuration.

What is the SLF4J equivalent to Log4j's "-Dlog4j.debug" option?

I have a J2EE application running under GF2 and OS X 10.8.4 which has suddenly, and without an y apparent cause stopped logging all of the information my team expects it to.
When deployed under Windows or Linux this issue does not occur. We suspect that it is either an OS update or some issue with the logging subsystem.
The application uses SLF4j and I would like to know what it's doing and where it might be getting its properties from. Under log4j there is an option "-Dlog4j.debug" which writes to STDOUT and tells where it is loading its properties from. Is there an equivalent option in SLF4J?

slf4j is just a facade - an common API - for any of several different logging backends. How to do what you want, depends on which backend you use. E.g. logback has the debug attribute in the configuration file telling it to log verbosely what it is doing.
The best approach for slf4j in a web application is to use the jdk14 bridge, allowing you to directly use the glassfish logging system. As a web application is not allowed to directly use the underlying file system this is the only way you can be fully compliant and still log.

GWT DevMode Options and Concepts

I just read the GWT Guide for Compiling and Debugging and have several similarly-related questions:
What's an example use case for the -whitelist and -blacklist DevMode options and why are they not available for production mode?
Difference between DevMode and HostedMode? Use cases for both?
What sort of "extra" stuff happens when you specify the -extra flag?
What is -workDir and why must it be writeable? What gets written there? What can I use it for?
Is the embedded Jetty instance the same as the codeserver? If not, what is the difference?
Where does the "story of your compile" report (soyc) get generated and how to configure this location?
These questions are so closely-related I figured it would be better to ask them all up front rather than spam SO with 6 different micro-questions. Thanks in advance!

-whitelist and -blacklist are actually never used. They're a left over from the legacy hosted mode which embedded a browser widget (and could control the Same-Origin Policy), rather than being embedded in the browser through a plugin.
HostedMode is currently the same as DevMode. It only exists for backwards-compatibility (see above)
properties files for all your Messages and Constants for all your locales (provided you configured a #Generate for those) to make it easier to bootstrap I18N, compile report –if you also pass -compileReport–, CSS maps of obfuscated CssResource class names, and logs of GWT-RPC serialization policies (which classes were included/excluded and why).
-workDir is where GWT writes most of it's temporary data (not all, some things go to the OS temporary folder –configurable with the -Djava.io.tmpdir= system property– or to a .gwt-unitCache folder –configurable with the -Dgwt.persistentunitcachedir= system property–). When you do distributed builds, the workDir has to be shared by all machines (either shared on the network, or by copying files around).
In DevMode, the embedded Jetty server runs your webapp (your server code and your static resources) from the -war folder (defaults to war/ in the current directory). The codeserver is what serves your client code. In DevMode, the codeserver uses a raw TCP connection to communicate with the plugin that sits in your browser; in SuperDevMode, the codeserver is a Jetty instance that serves JavaScript compiled (almost) on the fly, it doesn't host your webapp though.
See #3 above, and http://www.gwtproject.org/doc/latest/DevGuideCompileReport.html
BTW, the GWT project now has a new home: http://www.gwtproject.org

Different configuration/run "modes" under OSGi?

I have a Java application built with OSGi that I want to run in different modes, say a remote & local data source. I would like to be able to build and deploy a single version so that I could run the app as a service in remote mode and then stop the service & try different things in local mode.
I am using declarative services.
Would there be a way to do this?
# app -remote
Starting app in remote mode
Disabling com.example.data.local.FileStoreDao
Enabling com.example.data.remote.MySqlDao
...
And conversely:
# app -local
Starting app in localmode
Disabling com.example.data.remote.MySqlDao
Enabling com.example.data.local.FileStoreDao
...
Or something similar.

To quote Richard Hall:
The configuration of your application == The set of installed bundles.
The best and most maintainable solution will be to install a (slightly) different set of bundles for each of your runtime "modes". So for example, most of the bundles would be the same but you deploy either the MySqlDao bundle or the FileStoreDao. Using a tool or launcher that allows to you easily setup and launch different combinations of bundles will be critical.
If you really want to do this without changing the set of bundles, you could package both MySqlDao and FileStoreDao into a single bundle and use DS to enable/disable one or the other based on config data coming from Config Admin.

Not sure what framework you're using, but in Equinox, you can pass a different config file with a command line swich:
http://www.eclipse.org/equinox/documents/quickstart-framework.php
You could have two config files, and have a wrapper (java or batch file?) around the OSGi bootstrapper to select the proper config file. I have done something like this, but in my case I ended up going with two distros with different plugins, as it was simpler and it was all that I needed. Hope this helps

java.lang.LinkageError on jBoss while running app with log4j custom layout class

I am trying to configure a custom layout class to Log4J as described in my previous post. The class uses java.util.regex.Matcher to identify potential credit card numbers in log messages. It works perfectly in unit tests, also in a minimal web app containing a single servlet. However when I try to deploy it with our app in JBoss, I get the following error:
--- MBEANS THAT ARE THE ROOT CAUSE OF THE PROBLEM ---
ObjectName: jboss.web.deployment:war=MyWebApp-2010_02-SNAPSHOT.war,id=476602902
State: FAILED
Reason: java.lang.LinkageError: java/util/regex/Matcher
I couldn't even find any info on this form of the error - typically LinkageError seems to show up with a "loader constrain violation" message, like in here.
Technical details: we use JBoss 4.2, Java 5, Log4J 1.2.12. We deploy our app in an .ear, which contains (among others) the above mentioned .war file, and the custom layout class in a separate jar file (let's call it Commons). We override the default settings in jboss-log4j.xml with our own log4j.properties located in a different folder, which is added to the classpath at startup, and is provided via Sapient's Carbon framework.
Update to #skaffman's answer:
The reason we have a separate log4j.properties file is the scheme propagated by Sapient Carbon. This basically decouples the configuration and data files from the application server environment, so that they are accessible via Carbon's lookup functionality and they can be stored in a directory external to the app server. We inherited this setup, and we hate it because it causes us lots of trouble with deployment, classpath issues etc. since it does not adhere to the JEE conventions. We aim to get rid of it in the long run, but it's gonna take time :-(
Even though the separate log4j.properties file is not best practice, it certainly works. It has been functioning in our app for years, and I could also make it work with a minimalist web app containing a single servlet (not using Sapient Carbon). If log4j.properties is put into the classpath, Log4J reads it properly when the web app is launched, and reconfigures logging accordingly.
Update#2: An interesting finding is that Matcher is not even used in MyWebApp, only in the Commons module (and another module, in a separate jar). In Commons, it has been used before, in a class called StringHelper, which is used indirectly by MyWebApp, via other modules.
I guess this rules out the possibility of two different Matcher class versions loaded by different classloaders. So my only remaining guess is that Matcher is loaded by two different classloaders when it is used from the jar and the war, and then attempted to pass from one to the other. This is explained by Frank Kieviet's excellent article. However, I believe that such a setup would cause a "loader constraint violation" rather than this form of the error.
Update#3: If I add this appender (example 3.8) to jboss-log4j.xml, the error disappears, and the server runs perfectly :-o This obviously has to do something with loading log4j.jar, because this setup requires the jar to be present in the server lib directory. It works also if I change the appender type to org.jboss.logging.appender.FileAppender, and set log level to WARN, which results in an empty ucl.log file. This may suit as a temporary workaround, but I am still eager to fully understand what's going on here.
What does this error message mean, and how can I fix it properly?
Epilogue
After a long wait, I finally got to eliminate Carbon from the logging process and migrate our logging config into server/conf/jboss-log4j.xml. This required that I publish our custom log filter class in a separate jar in the server/lib directory. After this, the class loading works again, without the workaround described in Update#3 above :-)

My first reaction is that in JBoss it's not possible to override the log4j configuration like that. JBoss isn't allowing log4j to locate its own configuration, as it normally would, the location of conf/jboss-log4j.xml is specified in conf/jboss-service.xml.
To my knowledge, all log4j configuration in a given JBoss server must be centralised in to a single file, usually conf/jboss-log4j.xml.
Have you tried, as a test, moving the contents of your log4j.properties into the existing conf/jboss-log4j.xml file? If that works fine, then the problem is almost certainly caused by your attempt to override log4j. Having said that, I'd be surprised if jboss/log4j is that fragile, but perhaps in certain cases, it rejects this.

you either have two classes of different signatures but the same path in your environment or you compiled against another signature of j.u.r.Matcher. Since this is standard Java API, I think you should check your source and compilation targets and the JVM runtime version of your JBoss installation.
Edit:
After that is ruled out, I'm sure, the classloader (the server's) that manages the appenders and tries to load the appender that's using your custom layout can't see the custom layout class instance. So you have two options:
Deploy your custom layout JAR to the server's lib-directory along with log4j.
Deploy log4j along with your application and isolate the application with your own classloader (jboss-app.xml):
<jboss-app>
<loader-repository>
com.myapplication:loader=MyClassLoader
<loader-repository-config>java2ParentDelegation=false</loader-repository-config
</loader-repository>
</jboss-app>
I hope, the problem will go away then.