I want to do something like:
<insertFromJNDI env-entry-name="java:comp/env/conf/app-log-path" as="logPath" />
<if test='!isDefined("logPath") && isDefined("catalina.home")'>
<then>
<property name="logPath" value="${catalina.home}/logs/" />
</then>
</if>
<appender name="ROLLING_FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
<file>${logPath:-logs/}myapp.log</file>
</appender>
that is, allow a JNDI property to be sent in to my logging configuration, and if that is not found then try using catalina.home, and if that is not found then use a default value. Is this possible? It seems to me that is should be, but the never seems to take effect, maybe properties can't be updated in this manner? The documentation (chapter 3 of the manual) makes the property substituton seem quite powerful, but I just can't seem to get it working properly.
I believe I got an old or incorrect demo. Immediately after posting this, I realized that the attribute is condition="" instead of test="".
Related
suppose I have an external library with a class called Foo. I can't change Foo to have a private constructor, but I have a FooFactory class that I wrote.
So I have FooFactory.getAFoo() but I want checkstyle to catch any new Foo() in the rest of my code, to force using the factory.
I have this:
<module name="IllegalTokenText">
<property name="tokens" value="LITERAL_NEW"/>
<property name="format" value="Foo"/>
</module>
but this doesn't seem to detect a new Foo().
I could use a regex but this is much cleaner.
I had a similar problem with preventing extending a class:
<module name="IllegalTokenText">
<property name="tokens" value="EXTENDS_CLAUSE"/>
<property name="format" value="AndroidTestCase"/>
</module>
Neither of these checkstyle module seem to do anything at all.
What am I doing wrong?
IllegalTokenText checks for illegal text on the token itself, not on subsequent IDENT tokens or some such. So that is why it seems to do nothing in your case.
In your case, you may want to try using the SevNTU Checkstyle extension, which offers a check called ForbidInstantiation which might solve your problem. They have no documentation that I am aware of, so I am linking the source code with Javadoc. When you use SevNTU Checkstyle, be sure to use the right versions of regular Checkstyle and SevNTU Checkstyle, because not all combinations are compatible (overview).
If that does not help, you will have to roll your own.
I created a custom layout (as shown in Chapter 6: Layouts, http://logback.qos.ch/manual/layouts.html), so do I have to patch logback, or there is a configurable way to let logback knows about my custom layout class?
Thank you.
You can reference your layout in logback.xml by using the full namespace of your custom layout. So if your layout is at com.mydomain.logback.layouts.MyCustomLayout then in your logback.xml, you'd have an appender definition that looks something like this:
<appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
<layout class="com.mydomain.logback.layouts.MyCustomLayout" />
</appender>
Now every time a log event gets passed through the STDOUT appender, it will be processed by your custom appender. No need to recompile Logback.
I have the following three components defined in the Caste-Windsor XML configuration for my application:
<component id="StringFactory"
service="IStringFactory, MyApp"
type="DefaultStringFactory, MyApp"
lifestyle="singleton"
/>
<component id="TheString"
type="System.String"
factoryId="StringFactory"
factoryCreate="CreateString"
>
<parameters>
<name>SomeString</name>
</parameters>
</component>
<component id="TheTarget"
service="ITarget, MyApp"
type="TheTarget, MyApp"
lifestyle="transient"
>
<parameters>
<aString>${TheString}</aString>
</parameters>
</component>
And the following facility defined:
<facility id="factory.support"
type="Castle.Facilities.FactorySupport.FactorySupportFacility, Castle.MicroKernel"
/>
When I run the application and set a breakpoint in the constructor of the TheObject class, the value passed in as the aString parameter is "${TheString}" when I expect it to resolve to the value of the component with that name.
Also, I have a breakpoint in the StringFactory constructor and CreateString method, neither of which are hit. I know the configuration is being used as other components are resolving correctly.
What am I missing or doing wrong here?
UPDATE
In light of the huge tangient this topic has taken, I've refactored the code above to remove anything to do with connection strings. The original intent of this post was about injecting a property with the value returned from a method on another object. Somehow that point was lost in a discussion about why I'm using XML versus code-based configuration and if this is a good way to inject a connection string.
The above approach is far from an original idea and it was pulled from several other discussions on this topic and our requirements are what they are. I'd like help understanding why the configuration as it is in place (whether the right approach or not) isn't working as expected.
I did verify that the first two components are being instantiated correctly. When I call Container.Resolve("TheString"), I get the correct value back. For whatever reason, The parameter syntax is not working correctly.
Any ideas?
While not a definitive solution to what I need to do in my application, I believe I've figured out what is wrong with the code. Or at least I've found a way to make it work which hints at the original problem.
I replaced the String type for TheString with a custom class. That's it. Once I did that, everything worked fine.
My guess is that it has something to do with the fact that I was trying to use a ValueType (primitive) as a component. I guess Castle doesn't support it.
So, knowing that's the case, I can now move on to figuring out if this approach is really going to work or if we need to change direction.
UPDATE
For the sake of completeness, I thought I'd go ahead and explain what I did to solve my problem AND satisfy my requirements.
As before, I have access to my configuration settings through an IConfigurationService defined as:
<component id="ConfigurationService"
service="MyApp.IConfigurationService, MyApp"
type="MyApp.RuntimeConfigurationService, MyApp"
lifestyle="singleton"
/>
This is automatically injected into my (new) IConnectionFactory which is responsible for generating IDbConnection objects based on the connection strings defined in the application's configuration file. The factory is declared as:
<component id="ConnectionFactory"
service="MyApp.Factories.IConnectionFactory, MyApp"
type="MyApp.Factories.DefaultConnectionFactory, MyApp"
lifestyle="singleton"
/>
In order to resolve what connection is used by my repository, I declare each connection as a component using the ConnectionFactory to create each instance:
<component id="MyDbConnection"
type="System.Data.IDbConnection,
System.Data, Version=2.0.0.0, Culture=neutral,
PublicKeyToken=b77a5c561934e089"
factoryId="ConnectionFactory"
factoryCreate="CreateConnection"
lifestyle="transient"
>
<parameters>
<connectionStringName>MyDB</connectionStringName>
</parameters>
</component>
Notice the fully described reference to System.Data. I found this is necessary whenever referencing assemblies in the GAC.
Finally, my repository is defined as:
<component id="MyRepository"
service="MyApp.Repositories.IMyRepository, MyApp"
type="MyApp.Sql.SqlMyRepository, MyApp.Sql"
lifestyle="transient"
>
<parameters>
<connection>${MyDbConnection}</connection>
</parameters>
</component>
Now everything resolves correctly and I don't have ANY hard-coded strings compiled into my code. No connection string names, app setting keys or whatever. The app is completely reconfigurable from the XML files which is a requirement I must satisfy. Plus, other devs that will be working with the solution can manage the actual connection strings in the way they are used to. Win-win.
Hope this helps anyone else that runs into a similar scenario.
You don't really need XML registrations here, since you probably don't need to swap components or change the method used without recompiling. Writing a configurable app does not imply having to use XML registrations.
The problem with this particular XML registration you posted is that the connection string is a parameter, but it's treated like a service.
Doing this with code registrations is much easier, e.g.:
var container = new WindsorContainer();
container.Register(Component.For<IConfigurationService>().ImplementedBy<RuntimeConfigurationService>());
container.Register(Component.For<ITheRepository>().ImplementedBy<TheRepository>()
.LifeStyle.Transient
.DynamicParameters((k, d) => {
var cfg = k.Resolve<IConfigurationService>();
d["connectionString"] = cfg.GetConnectionString();
k.ReleaseComponent(cfg);
}));
Or if you don't want to depend on IConfigurationService, you could do something like:
container.Register(Component.For<ITheRepository>().ImplementedBy<TheRepository>()
.LifeStyle.Transient
.DependsOn(Property.ForKey("connectionString")
.Is(ConfigurationManager.ConnectionStrings[ConfigurationManager.AppSettings["connName"]].ConnectionString))
I'm using ant+ivy+nexus to build and publish my java OSGi projects (just good old jars if you're unfamiliar with OSGi). After the usual mind-melting period one has when engaging with new tech I've got a mostly functional system. But, I now have two dimensions of artifact variation: snapshot/release and main/test.
The main/test dimension speaks for itself really. The snapshot/release is essential for publishing into nexus in a maven-friendly way. (Extremely useful for integration with open-source OSGi runtimes). So, I have the following artifacts on a per-project basis, and I have many many projects:
project-revision.xml (bp)
project-test-revision.xml (b)
project-revision-SNAPSHOT.xml (bp)
project-test-revision-SNAPSHOT.xml (b)
b = successfully building
p = successfully publishing
(I haven't yet got the test stuff publishing correctly)
It's taken me a while to get that far without duplicating code everywhere in my build scripts, but I've managed it... with one big caveat. For the SNAPSHOT branch I append "-SNAPSHOT" to all revisions. In ant I manage to achieve this programatically, but for ivy I'm using a duplicated ivy.xml; ivy-SNAPSHOT.xml. This has
<info ... revision="x.x-SNAPSHOT">
Notice the -SNAPSHOT. Without this I could never get my
<ivy:deliver>
<ivy:resolve>
<ivy:publish>
chain of commands to correctly publish artifact and maven pom. (Remember I have a requirement to make this maven friendly... I'll be damned if I actually end up using maven to build it mind!)
Now I'm stuck introducing the test/main dimension. I'm ideally looking to publish
project-test-revision(-SNAPSHOT).jar
(Note the optional snapshot). I really don't want to do this by specifying
<info ... module="project-test" ... >
as opposed to <info ... module="project" ... > in yet another ivy file. If I went this route (like I've already started) then I simply end up with loads of ivy-Option1-Option2...-OptionN.xml files. With each new two-value variation doubling the number of build and ivy files. That's crap. There's got to be a better way. I just can't find it.
If you have managed to successfully get ivy publishing artifacts with embellished names from one ivy file, would you mind posting the configuration snippets that achieve this? Would be extremely useful. (Don't forget maven won't know about configurations so I need to get the variations into the filename and pom).
Many thanks
Alastair
Ok, update: I've now got the artifact publishing. I struggled a little while I had the test conf extending the default conf. I'd get a complaint during publishing that the default configuration artifacts weren't present... something I don't care about while only publishing the test case. By making them independent but overlapping I get back fine-grain control of what to publish.
BUT!!!!! There's no viable test pom - that's NOT publishing yet. Well, actually it does publish, but it contains data for the non-test case. So this is still not maven friendly. If anyone has suggestions on this that'd be great.
either way, the code I'm now using, in case it helps you too:
ivy.xml:
<info
organisation="MY_ORGANISATION"
module="MY_PROJECT"
status="integration"
revision="1.0-SNAPSHOT">
</info>
<configurations>
<conf name="default" description="Default compilation configuration; main classes only" visibility="public"/>
<conf name="test" description="Test-inclusive compilation configuration. Don't forget to also add Default compilation configuration where needed. This does not extend default conf" visibility="public"/>
</configurations>
<publications>
<artifact name="MY_PROJECT type="jar" ext="jar" conf="default"/>
<artifact name="MY_PROJECT type="pom" ext="pom" conf="default"/>
<artifact name="MY_PROJECT-test" type="jar" ext="jar" conf="test"/>
<artifact name="MY_PROJECT-test" type="pom" ext="pom" conf="test"/>
</publications>
<dependencies>
<dependency org="MY_ORGANISATION" name="ANOTHER_PROJECT" rev="1.0-SNAPSHOT" transitive="true" conf="*"/>
<dependency org="junit" name="junit" rev="[4,)" transitive="true" conf="test->*"/>
</dependencies>
build.xml:
<property name="project.generated.ivy.file" value="SNAPSHOT_OR_RELEASE_IVY_XML_FILE" />
<property name="ivy.publish.status" value="RELEASE_OR_INTEGRATION" />
<property name="project.qualifier" value="-SNAPSHOT_OR_EMPTY" />
<property name="ivy.configuration" value="DEFAULT_OR_TEST" />
<target name="publish" depends="init-publish">
<ivy:deliver
deliverpattern="${project.generated.ivy.file}"
organisation="${project.organisation}"
module="${project.artifact}"
status="${ivy.publish.status}"
revision="${project.revision}${project.qualifier}"
pubrevision="${project.revision}${project.qualifier}"
conf="${ivy.configuration}"
/>
<ivy:resolve conf="${ivy.configuration}" />
<ivy:makepom
ivyfile="${project.generated.ivy.file}"
pomfile="${project.pom.file}"
/>
<ivy:publish
resolver="${ivy.omnicache.publisher}"
module="${project.artifact}"
organisation="${project.organisation}"
revision="${project.revision}${project.qualifier}"
pubrevision="${project.revision}${project.qualifier}"
pubdate="now"
overwrite="true"
publishivy="true"
status="${ivy.publish.status}"
artifactspattern="${project.artifact.dir}/[artifact]-[revision](-[classifier]).[ext]"
conf="${ivy.configuration}"
/>
</target>
This seems like a carelessness error, but I can't seem to find the cause. Logging with logback/slf4j (most recent version slf4j-api-1.6.1, logback core/classic 0.9.24). Simplest log configuration for testing is:
<configuration>
<appender name="stdout" class="ch.qos.logback.core.ConsoleAppender">
<layout class="ch.qos.logback.classic.PatternLayout">
<!-- DONT USE THIS FORMATTER FOR LIVE LOGGING THE %L LINE NUMBER OUTPUTTER IS SLOW -->
<pattern>%le %-1r [%c{1}:%L] %m%n</pattern>
</layout>
</appender>
<root level="DEBUG">
<appender-ref ref="stdout" />
</root>
</configuration>
Every log setup starts with logback's internal status lines:
11:21:27,825 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Could NOT find resource [logback.groovy]
11:21:27,826 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Found resource [logback-test.xml] at [file:.../logback-test.xml]
11:21:28,116 |-INFO in ch.qos.logback.classic.joran.action.ConfigurationAction - debug attribute not set
11:21:28,124 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - About to instantiate appender of type [ch.qos.logback.core.ConsoleAppender]
11:21:28,129 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - Naming appender as [stdout]
11:21:28,180 |-INFO in ch.qos.logback.core.joran.action.NestedComplexPropertyIA - Pushing component [layout] on top of the object stack.
11:21:28,206 |-WARN in ch.qos.logback.core.ConsoleAppender[stdout] - This appender no longer admits a layout as a sub-component, set an encoder instead.
11:21:28,206 |-WARN in ch.qos.logback.core.ConsoleAppender[stdout] - To ensure compatibility, wrapping your layout in LayoutWrappingEncoder.
11:21:28,206 |-WARN in ch.qos.logback.core.ConsoleAppender[stdout] - See also http://logback.qos.ch/codes.html#layoutInsteadOfEncoder for details
11:21:28,207 |-INFO in ch.qos.logback.classic.joran.action.RootLoggerAction - Setting level of ROOT logger to DEBUG
11:21:28,207 |-INFO in ch.qos.logback.core.joran.action.AppenderRefAction - Attaching appender named [stdout] to Logger[ROOT]
which is, according to the docs, the format logback uses for default. It then finishes reading the config (which is set up to output a different format) and continues with the properly formatted output. There's a config parameter <configuration debug="false"> which does not affect this.
Anyone know how to shut this off?
If you set the debug attribute of the configuration element to true, you will get all status information to the console. If this is your problem, just set it to false or remove it.
If you have any configuration problems of level WARN or above, you will also get all status information logged to the console (including messages of level INFO). The best solution to this problem is to fix the problem (in your case replace the <layout> element with an <encoder> element).
If you for some reason cannot fix the problem, but want to remove the status-information from the console, you can instead configure an alternative StatusListener. Use the NopStatusListener to completely remove the status-information:
<configuration>
<statusListener class="ch.qos.logback.core.status.NopStatusListener" />
<!-- etc -->
</configuration>
As described in the docs, if warnings or errors occur during the parsing of the configuration file, logback will automatically print status data on the console.
Follow http://logback.qos.ch/codes.html#layoutInsteadOfEncoder i.e.
the link mentioned by logback in its warning message. Once you follow the steps mentioned therein, that is, if you replace <layout> element with <encoder>, logback will stop printing messages on the console.
Ceki answer is correct:
(...)if warnings or errors occur during the parsing of the configuration file, logback will automatically print status data on the console.
Once you get it right, there won't be any pollution in the first lines of your log anymore.
As of March 2015, in Logback 1.1.2, you need to use <encoder> sub-component - <layout> is now deprecated and if use it, error messages will appear. You cannot control this, it´s Logback default behavior.
Some internal classes have been renamed too, and even the examples in their manual page are outdated!
Here is the code snippet from their Errors Code Help page, which has the correct way to config the logger. This fixed the issue completely in my project.
http://logback.qos.ch/codes.html#layoutInsteadOfEncoder
<appender name="FILE" class="ch.qos.logback.core.FileAppender">
<file>testFile.log</file>
...
<encoder class="ch.qos.logback.classic.encoder.PatternLayoutEncoder">
<pattern>%msg%n</pattern>
</encoder>
</appender>
I had the same problem i added this line
<!-- Stop output INFO at start -->
<statusListener class="ch.qos.logback.core.status.NopStatusListener" />
in the logback and it succefully worked
I realized Steve found the fix but he didn't mention it on the thread. In case if any other person hit the same issue here is the fix.
Replace "<layout>" elements with "<encoder>..</encoder>"
The culprit is:
<layout class="ch.qos.logback.classic.PatternLayout">
I prefer to use status listener in order to switch off own logback logs:
<configuration>
<statusListener class="ch.qos.logback.core.status.NopStatusListener" />
...
</configuration>
But as was mentioned NopStatusListener also prevents showing warning and errors. So you can write your custom status listener and change log level for it manually:
package com.your.package;
import ch.qos.logback.core.status.OnConsoleStatusListener;
import ch.qos.logback.core.status.Status;
import java.util.List;
public class PrintOnlyWarningLogbackStatusListener extends OnConsoleStatusListener {
private static final int LOG_LEVEL = Status.WARN;
#Override
public void addStatusEvent(Status status) {
if (status.getLevel() == LOG_LEVEL) {
super.addStatusEvent(status);
}
}
#Override
public void start() {
final List<Status> statuses = context.getStatusManager().getCopyOfStatusList();
for (Status status : statuses) {
if (status.getLevel() == LOG_LEVEL) {
super.start();
}
}
}
}
Then use it in your logback.xml file:
<configuration>
<statusListener class="com.your.package.PrintOnlyWarningLogbackStatusListener" />
...
</configuration>
Struggled with the same problem myself i.e. there were a bunch of lines logged right at the beginning which were not related to my code. Here is how I fixed it.
<configuration debug="false">
<appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
<!-- <encoder> <pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level
%logger{36} - %msg%n</pattern> </encoder> -->
<encoder>
<pattern>%d{HH:mm:ss.SSS} %-5level %logger{10} - %msg%n</pattern>
</encoder>
</appender>
<root level="error">
<appender-ref ref="STDOUT" />
</root>
<logger name="fun.n.games" level="DEBUG" />
This is running with the following entry in the pom.xml
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-classic</artifactId>
<version>1.2.3</version>
</dependency>
This seems to be Fixed in 0.9.29. Just made several tests. No Joran INFO anymore. I guess this is the fixing commit.
I've tried everything and nothing worked for me. My problem was due to multiple logback.xml files in my classpath. This is the common case in multi modular projects.
When there is only one logback.xml file in classpath, there is no ambiguity and the problem is solved.
Using the logback.groovy: statusListener(NopStatusListener) (in the src/test/resources/logback.groovy) works.
(A valid use case is e.g. if working with ANT in Eclipse, using logback logging, groovy classes and unit tests where the unit tests take the src/test/resources/logback.groovy, but will also see the src/main/resources/logback.groovy (or similar) you cannot exclude (if ANT's classpath is said to use the projects classpath).)
Just for people landing here because of the status messages logged by ch.qos.logback.access.tomcat.LogbackValve#LogbackValve (recent versions). Just set the quiet flag:
var v = new LogbackValve();
v.setQuiet(true); // disable status messages!
v.setFilename("logback-access.xml");
See also the documentation for XML configuration.