"IllegalArgumentException: Bean factory must allow eager class loading" with 1.5.2.RELEASE when using JRebel #8488

yglodt · 2017-03-03T20:13:14Z

A project of mine does not start with 1.5.2 anymore. With 1.5.1 it runs fine.

I start the application like this:

package tld.mine;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;

@SpringBootApplication
public class App {

	public static void main(final String... args) {
		SpringApplication.run(App.class, args); // this is line 10
	}
}

The exceptions thrown are here:

[ERROR] [03.03.17 20:08:35]          SpringApplication.java:815  Application startup failed
java.lang.IllegalStateException: Error processing condition on org.springframework.boot.autoconfigure.context.PropertyPlaceholderAutoConfiguration.propertySourcesPlaceholderConfigurer
	at org.springframework.boot.autoconfigure.condition.SpringBootCondition.matches(SpringBootCondition.java:64) ~[spring-boot-autoconfigure-1.5.2.RELEASE.jar:1.5.2.RELEASE]
	at org.springframework.context.annotation.ConditionEvaluator.shouldSkip(ConditionEvaluator.java:102) ~[spring-context-4.3.7.RELEASE.jar:4.3.7.RELEASE]
	at org.springframework.context.annotation.ConfigurationClassBeanDefinitionReader.loadBeanDefinitionsForBeanMethod(ConfigurationClassBeanDefinitionReader.java:178) ~[spring-context-4.3.7.RELEASE.jar:4.3.7.RELEASE]
	at org.springframework.context.annotation.ConfigurationClassBeanDefinitionReader.loadBeanDefinitionsForConfigurationClass(ConfigurationClassBeanDefinitionReader.java:140) ~[spring-context-4.3.7.RELEASE.jar:4.3.7.RELEASE]
	at org.springframework.context.annotation.ConfigurationClassBeanDefinitionReader.loadBeanDefinitions(ConfigurationClassBeanDefinitionReader.java:116) ~[spring-context-4.3.7.RELEASE.jar:4.3.7.RELEASE]
	at org.springframework.context.annotation.ConfigurationClassPostProcessor.processConfigBeanDefinitions(ConfigurationClassPostProcessor.java:320) ~[spring-context-4.3.7.RELEASE.jar:4.3.7.RELEASE]
	at org.springframework.context.annotation.ConfigurationClassPostProcessor.postProcessBeanDefinitionRegistry(ConfigurationClassPostProcessor.java:228) ~[spring-context-4.3.7.RELEASE.jar:4.3.7.RELEASE]
	at org.springframework.context.support.PostProcessorRegistrationDelegate.invokeBeanDefinitionRegistryPostProcessors(PostProcessorRegistrationDelegate.java:270) ~[spring-context-4.3.7.RELEASE.jar:4.3.7.RELEASE]
	at org.springframework.context.support.PostProcessorRegistrationDelegate.invokeBeanFactoryPostProcessors(PostProcessorRegistrationDelegate.java:93) ~[spring-context-4.3.7.RELEASE.jar:4.3.7.RELEASE]
	at org.springframework.context.support.AbstractApplicationContext.invokeBeanFactoryPostProcessors(AbstractApplicationContext.java:686) ~[spring-context-4.3.7.RELEASE.jar:4.3.7.RELEASE]
	at org.springframework.context.support.AbstractApplicationContext.__refresh(AbstractApplicationContext.java:524) ~[spring-context-4.3.7.RELEASE.jar:4.3.7.RELEASE]
	at org.springframework.context.support.AbstractApplicationContext.jrLockAndRefresh(AbstractApplicationContext.java) ~[spring-context-4.3.7.RELEASE.jar:4.3.7.RELEASE]
	at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java) ~[spring-context-4.3.7.RELEASE.jar:4.3.7.RELEASE]
	at org.springframework.boot.context.embedded.EmbeddedWebApplicationContext.refresh(EmbeddedWebApplicationContext.java:122) ~[spring-boot-1.5.2.RELEASE.jar:1.5.2.RELEASE]
	at org.springframework.boot.SpringApplication.refresh(SpringApplication.java:737) [spring-boot-1.5.2.RELEASE.jar:1.5.2.RELEASE]
	at org.springframework.boot.SpringApplication.refreshContext(SpringApplication.java:370) [spring-boot-1.5.2.RELEASE.jar:1.5.2.RELEASE]
	at org.springframework.boot.SpringApplication.run(SpringApplication.java:314) [spring-boot-1.5.2.RELEASE.jar:1.5.2.RELEASE]
	at org.springframework.boot.SpringApplication.run(SpringApplication.java:1162) [spring-boot-1.5.2.RELEASE.jar:1.5.2.RELEASE]
	at org.springframework.boot.SpringApplication.run(SpringApplication.java:1151) [spring-boot-1.5.2.RELEASE.jar:1.5.2.RELEASE]
	at tld.mine.App.main(App.java:10) [classes/:?]
Caused by: java.lang.IllegalArgumentException: Bean factory must allow eager class loading
	at org.springframework.util.Assert.isTrue(Assert.java:92) ~[spring-core-4.3.7.RELEASE.jar:4.3.7.RELEASE]
	at org.springframework.boot.autoconfigure.condition.BeanTypeRegistry.get(BeanTypeRegistry.java:93) ~[spring-boot-autoconfigure-1.5.2.RELEASE.jar:1.5.2.RELEASE]
	at org.springframework.boot.autoconfigure.condition.OnBeanCondition.collectBeanNamesForType(OnBeanCondition.java:185) ~[spring-boot-autoconfigure-1.5.2.RELEASE.jar:1.5.2.RELEASE]
	at org.springframework.boot.autoconfigure.condition.OnBeanCondition.getBeanNamesForType(OnBeanCondition.java:171) ~[spring-boot-autoconfigure-1.5.2.RELEASE.jar:1.5.2.RELEASE]
	at org.springframework.boot.autoconfigure.condition.OnBeanCondition.getMatchingBeans(OnBeanCondition.java:139) ~[spring-boot-autoconfigure-1.5.2.RELEASE.jar:1.5.2.RELEASE]
	at org.springframework.boot.autoconfigure.condition.OnBeanCondition.getMatchOutcome(OnBeanCondition.java:110) ~[spring-boot-autoconfigure-1.5.2.RELEASE.jar:1.5.2.RELEASE]
	at org.springframework.boot.autoconfigure.condition.SpringBootCondition.matches(SpringBootCondition.java:47) ~[spring-boot-autoconfigure-1.5.2.RELEASE.jar:1.5.2.RELEASE]
	... 19 more
[ WARN] [03.03.17 20:08:35]  AbstractApplicationContext.java:1005 Exception thrown from LifecycleProcessor on context close
java.lang.IllegalStateException: LifecycleProcessor not initialized - call 'refresh' before invoking lifecycle methods via the context: org.springframework.boot.context.embedded.AnnotationConfigEmbeddedWebApplicationContext@58fb7731: startup date [Fri Mar 03 20:08:33 UTC 2017]; root of context hierarchy
	at org.springframework.context.support.AbstractApplicationContext.getLifecycleProcessor(AbstractApplicationContext.java:417) ~[spring-context-4.3.7.RELEASE.jar:4.3.7.RELEASE]
	at org.springframework.context.support.AbstractApplicationContext.doClose(AbstractApplicationContext.java:1002) [spring-context-4.3.7.RELEASE.jar:4.3.7.RELEASE]
	at org.springframework.context.support.AbstractApplicationContext.close(AbstractApplicationContext.java:961) [spring-context-4.3.7.RELEASE.jar:4.3.7.RELEASE]
	at org.springframework.boot.SpringApplication.handleRunFailure(SpringApplication.java:794) [spring-boot-1.5.2.RELEASE.jar:1.5.2.RELEASE]
	at org.springframework.boot.SpringApplication.run(SpringApplication.java:325) [spring-boot-1.5.2.RELEASE.jar:1.5.2.RELEASE]
	at org.springframework.boot.SpringApplication.run(SpringApplication.java:1162) [spring-boot-1.5.2.RELEASE.jar:1.5.2.RELEASE]
	at org.springframework.boot.SpringApplication.run(SpringApplication.java:1151) [spring-boot-1.5.2.RELEASE.jar:1.5.2.RELEASE]
	at tld.mine.App.main(App.java:10) [classes/:?]
[ERROR] [03.03.17 20:08:35]  DefaultSingletonBeanRegistry.java:581  Destroy method on bean with name 'org.springframework.boot.autoconfigure.internalCachingMetadataReaderFactory' threw an exception
java.lang.IllegalStateException: ApplicationEventMulticaster not initialized - call 'refresh' before multicasting events via the context: org.springframework.boot.context.embedded.AnnotationConfigEmbeddedWebApplicationContext@58fb7731: startup date [Fri Mar 03 20:08:33 UTC 2017]; root of context hierarchy
	at org.springframework.context.support.AbstractApplicationContext.getApplicationEventMulticaster(AbstractApplicationContext.java:404) ~[spring-context-4.3.7.RELEASE.jar:4.3.7.RELEASE]
	at org.springframework.context.support.ApplicationListenerDetector.postProcessBeforeDestruction(ApplicationListenerDetector.java:97) ~[spring-context-4.3.7.RELEASE.jar:4.3.7.RELEASE]
	at org.springframework.beans.factory.support.DisposableBeanAdapter.destroy(DisposableBeanAdapter.java:253) ~[spring-beans-4.3.7.RELEASE.jar:4.3.7.RELEASE]
	at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.destroyBean(DefaultSingletonBeanRegistry.java:578) [spring-beans-4.3.7.RELEASE.jar:4.3.7.RELEASE]
	at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.destroySingleton(DefaultSingletonBeanRegistry.java:554) [spring-beans-4.3.7.RELEASE.jar:4.3.7.RELEASE]
	at org.springframework.beans.factory.support.DefaultListableBeanFactory.destroySingleton(DefaultListableBeanFactory.java:961) [spring-beans-4.3.7.RELEASE.jar:4.3.7.RELEASE]
	at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.destroySingletons(DefaultSingletonBeanRegistry.java:523) [spring-beans-4.3.7.RELEASE.jar:4.3.7.RELEASE]
	at org.springframework.beans.factory.support.AbstractBeanFactory.destroySingletons(AbstractBeanFactory.java) [spring-beans-4.3.7.RELEASE.jar:4.3.7.RELEASE]
	at org.springframework.beans.factory.support.DefaultListableBeanFactory.destroySingletons(DefaultListableBeanFactory.java:968) [spring-beans-4.3.7.RELEASE.jar:4.3.7.RELEASE]
	at org.springframework.context.support.AbstractApplicationContext.destroyBeans(AbstractApplicationContext.java:1033) [spring-context-4.3.7.RELEASE.jar:4.3.7.RELEASE]
	at org.springframework.context.support.AbstractApplicationContext.doClose(AbstractApplicationContext.java:1009) [spring-context-4.3.7.RELEASE.jar:4.3.7.RELEASE]
	at org.springframework.context.support.AbstractApplicationContext.close(AbstractApplicationContext.java:961) [spring-context-4.3.7.RELEASE.jar:4.3.7.RELEASE]
	at org.springframework.boot.SpringApplication.handleRunFailure(SpringApplication.java:794) [spring-boot-1.5.2.RELEASE.jar:1.5.2.RELEASE]
	at org.springframework.boot.SpringApplication.run(SpringApplication.java:325) [spring-boot-1.5.2.RELEASE.jar:1.5.2.RELEASE]
	at org.springframework.boot.SpringApplication.run(SpringApplication.java:1162) [spring-boot-1.5.2.RELEASE.jar:1.5.2.RELEASE]
	at org.springframework.boot.SpringApplication.run(SpringApplication.java:1151) [spring-boot-1.5.2.RELEASE.jar:1.5.2.RELEASE]
	at tld.mine.App.main(App.java:10) [classes/:?]

The text was updated successfully, but these errors were encountered:

snicoll · 2017-03-03T20:32:04Z

Sorry but that's not enough for us to figure out what went wrong. Can you please share a sample that we can run?

wilkinsona · 2017-03-03T20:38:18Z

@yglodt That's a result of this change: #8439. Can you please describe how and why you have customised your application's bean factory?

philwebb · 2017-03-03T20:39:06Z

Specifically are you calling setAllowEagerClassLoading(false) (and if so, why)

yglodt · 2017-03-03T20:51:11Z

@philwebb setAllowEagerClassLoading() does not occur in my code
@snicoll I can unfortunately not share the code. It's part of a larger application which I can not easily dissect

I will try to figure out if there is any special bean factory stuff and comment back.

yglodt · 2017-03-03T21:05:05Z

I don't see anything special in my configuration, just the usual @Bean.

I use the following configuration annotations, spread over several config classes:

@Configuration
@EnableJdbcHttpSession(maxInactiveIntervalInSeconds = 86400, tableName = "spring_session")
@EnableWebSocketMessageBroker
@EnableWebSecurity
@EnableScheduling
@EnableAsync
@ComponentScan(basePackages = "tld.mine")

wilkinsona · 2017-03-03T21:17:09Z

Something must be setting it to false. Can you please try debugging your app with a breakpoint on the setter in DefaultListableBeanFactory and see what's calling it?

yglodt · 2017-03-05T09:34:51Z

This is what I came up with so far. Is it of any help?

wilkinsona · 2017-03-05T16:11:55Z

Is it of any help?

Not much, unfortunately. I can see that you've got the required breakpoint in place, but, judging by the stack of the suspended thread, it wasn't tripped. That's rather baffling as they field's value defaults to true yet the failure you're seeing requires the value to be false.

Can you please try debugging again with a breakpoint on the field itself. Eclipse should then suspend the thread whenever the field is accessed or modified. It's when it's modified that's of particular interest (although it would also be interesting to have confirmation that's its value is true when it's first accessed).

ursjoss · 2017-03-05T16:43:50Z

Hi all

I have a similar situation in my project. It won't start anymore with spring boot 1.5.2. Nothing I'm aware of is explicitly setting allowEagerClassLoading to false.

The problem occurs when ConfigurationClassBeanDefinitionReader is attempting to load the bean definition (loadBeanDefinitionsForConfigurationClass) for configuration class ConfigurationPropertiesRebinderAutoConfiguration.

While doing it's work, OnBeanCondition.collectBeanNamesForType calls BeanTypeRegistry.get(beanFactory). It's third line asserts listableBeanFactory.isAllowEagerClassLoading() is true. Funnily it returns false even though I can see the property of listableBeanFactory is set to true in the debugger.

The debugger does not even jump into listableBeanFactory.isAllowEagerClassLoading(). Some proxy issue?

You can check it out here: https://github.com/ursjoss/sipamato/tree/tb_spring_boot_1_5_2. Start the project with profile DB_JOOQ.

HTH. Thanks and cheers, Urs

wilkinsona · 2017-03-05T17:09:59Z

@ursjoss Thanks very much. I've just tried your app and it started successfully for me using the DB_JOOQ profile. With a breakpoint set at the same point as you it suspends the VM at the exact same point as you, however it returns true in my case having gone into isAllowEagerClassLoading() as expected. I'm currently at a loss to explain the difference in behaviour.

@ursjoss and @yglodt What OS and JVM are you running on? I tried on OS X using Oracle JDK 8 (1.8.0_121-b13).

ursjoss · 2017-03-05T17:21:39Z

@wilkinsona Thanks for investing time on this.

OS: Arch Linux (4.9.11-1-ARCH #1 SMP PREEMPT x86_64 GNU/Linux), JDK: openjdk version "1.8.0_121"
OpenJDK Runtime Environment (build 1.8.0_121-b13)
OpenJDK 64-Bit Server VM (build 25.121-b13, mixed mode)

By the way: Followin your pm, I did another attempt of debugging. Even before, I had a breakpoint in the setter and getter for allowEagerClassLoading. Both break points never tripped. Now I also set a break point on the field declaration/initialization (DefaultListableBeanFactory line 153). The debugger did stop there and the field was initialized to true.

Later I'll give it a go to run the project on windows, to see the behavior there...

ursjoss · 2017-03-05T18:18:27Z

@wilkinsona I can confirm the project starts without flaw on Windows: java version "1.8.0_121" Java(TM) SE Runtime Environment (build 1.8.0_121-b13) Java HotSpot(TM) 64-Bit Server VM (build 25.121-b13, mixed mode)

How can we proceed?

By the way: Sorry for not mentioning the snapshot dependency on wicket-bootstrap

yglodt · 2017-03-05T18:19:09Z

I run Fedora 25 with their packaged OpenJDK 64-Bit Server VM (build 25.121-b14, mixed mode)

ursjoss · 2017-03-05T18:20:27Z

so looks like something openjdk/linux specific

ursjoss · 2017-03-05T19:02:17Z

@yglodt Are you able to verify whether your project works on a non-Linux machine?

I'm going to try out mine with oracle-jdk on linux to try narrowing the issue down...

yglodt · 2017-03-05T19:06:59Z

@ursjoss Yes I can do that, tomorrow. I have no Windows machine available here.

brsanthu · 2017-03-05T19:16:14Z

We are using latest spring boot 2.x snapshot and it is throwing same error for me. It worked with earlier snapshot. Here is system info.

Darwin sanbook.local 16.3.0 Darwin Kernel Version 16.3.0: Thu Nov 17 20:23:58 PST 2016; root:xnu-3789.31.2~1/RELEASE_X86_64 x86_64 i386 MacBookPro13,3 Darwin
java version "1.8.0_121"
Java(TM) SE Runtime Environment (build 1.8.0_121-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.121-b13, mixed mode)

We haven't specified any customization of bean factory and not calling setAllowEagerClassLoading(false) anywhere.

I tried to create a simple project with basic dependency but couldn't reproduce the issue. So I guess some dependency we have may be causing this issue.

ursjoss · 2017-03-05T20:43:53Z

I installed oracle-jdk on my archlinux machine.

java version "1.8.0_121"
Java(TM) SE Runtime Environment (build 1.8.0_121-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.121-b13, mixed mode)

Switching back and forth between openjdk and oracle-jdk, I noticed the following:

Running the project via maven works (mvn clean install && mvn spring-boot:run), regardless of the jdk.
Running the project through STS Boot dashboard fails, also regardless of the jdk.

My STS:

Version: 3.8.3.RELEASE
Build Id: 201612191351
Platform: Eclipse Neon.2 (4.6.2)

wilkinsona · 2017-03-05T21:01:41Z

So it now looks like this isn't specific to Linux (@brsanthu has the problem on mac OS) or Open JDK.

@ursjoss In light of your latest update, I've had another attempt at reproducing the problem on mac OS using the Oracle JDK and STS 3.8.3.RELEASE but without any joy. I've also tried on Fedora 25 running via mvn spring-boot:run and java -jar with no joy either.

@brsanthu and @yglodt How are you launching your apps when they fail?
@ursjoss Does yours fail in STS if you launch as a Java application rather than through the STS dashboard?

ursjoss · 2017-03-05T21:23:04Z

@wilkinsona good point:

Running the app via STS as java application works flawlessly
running it as spring boot app (RunAs -> Spring Boot App) or via Boot Dashboard doesn't.

Tested on linux using openjdk.

wilkinsona · 2017-03-05T21:48:28Z

@ursjoss Thanks.

Running as a Spring Boot app sets a few system properties:

-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=64131
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false
-Dspring.liveBeansView.mbeanDomain
-Dspring.application.admin.enabled=true
-Djava.security.egd=file:/dev/./urandom
-Dfile.encoding=UTF-8

It also adds a program argument:

--spring.output.ansi.enabled=always

I would guess, although I can't explain why, that it's one or more of these that's causing the change in behaviour. Would you mind experimenting with running as a Java application using these system properties to see if you can narrow things down a bit further?

/cc @kdvolder @martinlippert who work on STS

yglodt · 2017-03-05T22:37:01Z

I run it in Eclipse as Java application. Note that I use JRebel. I have not yet tried if it behaves different without JRebel.

ursjoss · 2017-03-05T22:40:38Z

@wilkinsona I tried those parameters on the command line. All went fine.

It then started to play with the parameters in the boot dashboard and found that it's actually JRebel.

Removing the jrebel-agent both on linux and on windows resulted in successfully launching the application - and vice versa: adding jrebel-agent on windows and launching the app through the boot dashboard resulted in the same failure as on linux.

I have opened a ticket with JRebel referring to this thread.

Thanks a lot to all involved in nailing down this issue.

brsanthu · 2017-03-06T00:27:11Z

Yes, removing the ${jrebel_args} parameter successfully starts the app for me too.

wilkinsona · 2017-03-06T09:57:00Z

Thanks, everyone.

@ursjoss Is the ticket that you opened against JRebel publicly accessible? I'd like to be able to follow that discussion as it might influence what we decide to do here. If it's going to take a while for the problem to be fixed, a note in the documentation may be in order.

ursjoss · 2017-03-06T10:19:51Z

@wilkinsona I have opened the ticket via JRebel Eclipse plugin (which defaults to sending the relevant logs etc.). I (still) have the same question about gettting a ticket number and being able to track the status of the ticket. I have not heard from ZeroTurnAround since. I will ask them via twitter if I don't hear from them by tomorrow.

Ristop · 2017-03-06T11:03:17Z

Hi, i'm Risto from ZeroTurnaround support team. We have opened a ticked for this issue and are working on getting it fixed. Unfortunately there is no public jira available, but i will keep you informed about the progress.

Ristop · 2017-03-07T11:46:18Z

The issue should now be resolved in the latest nightly build. You can download the nightly from here.

wilkinsona · 2017-03-07T12:01:51Z

That was quick! Thanks very much, @Ristop.

ursjoss · 2017-03-07T12:05:19Z

I can confirm the nightly build solves the issue in my case. Thanks @Ristop

brsanthu · 2017-03-07T17:16:44Z

Can confirm that with new build it is working for Spring Boot 2.x.x snapshot version too.

FlowerWrong · 2017-03-08T02:59:39Z

The same problem, waiting for jrebel release.

roboojack · 2017-03-08T17:00:55Z

I can confirm that the JRebel Agent 7.0.6-SNAPSHOT (201703081621) nightly release fixes the bug in IntelliJ.

VittorioZinno · 2017-03-10T15:13:34Z

So do I, thanks a lot guys

JasonCL2015 · 2017-03-15T08:28:39Z

Thanks a lot everyone!

akageun · 2017-03-17T08:03:14Z

I was having the same problem. Thanks~

bestv5 · 2017-03-20T09:39:58Z

I was having the same problem. Thanks~

geodavies · 2017-03-20T15:08:28Z

Thanks, this fixed it for me.

ArloL · 2017-03-23T12:52:15Z

7.0.6 has been released: https://zeroturnaround.com/software/jrebel/download/changelog/7-x/

spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Mar 3, 2017

snicoll added the status: waiting-for-feedback We need additional information before we can continue label Mar 3, 2017

spring-projects-issues added status: feedback-provided Feedback has been provided and removed status: waiting-for-feedback We need additional information before we can continue labels Mar 3, 2017

wilkinsona added status: waiting-for-feedback We need additional information before we can continue and removed status: feedback-provided Feedback has been provided labels Mar 3, 2017

spring-projects-issues added status: feedback-provided Feedback has been provided and removed status: waiting-for-feedback We need additional information before we can continue labels Mar 5, 2017

wilkinsona changed the title ~~IllegalStateException and IllegalArgumentException with 1.5.2~~ "IllegalArgumentException: Bean factory must allow eager class loading" with 1.5.2.RELEASE when using JRebel Mar 6, 2017

wilkinsona closed this as completed Mar 7, 2017

wilkinsona added status: invalid An issue that we don't feel is valid and removed status: feedback-provided Feedback has been provided status: waiting-for-triage An issue we've not yet triaged labels Mar 7, 2017

"IllegalArgumentException: Bean factory must allow eager class loading" with 1.5.2.RELEASE when using JRebel #8488

"IllegalArgumentException: Bean factory must allow eager class loading" with 1.5.2.RELEASE when using JRebel #8488

Comments

yglodt commented Mar 3, 2017

snicoll commented Mar 3, 2017

wilkinsona commented Mar 3, 2017

philwebb commented Mar 3, 2017

yglodt commented Mar 3, 2017

yglodt commented Mar 3, 2017 • edited Loading

wilkinsona commented Mar 3, 2017

yglodt commented Mar 5, 2017

wilkinsona commented Mar 5, 2017

ursjoss commented Mar 5, 2017

wilkinsona commented Mar 5, 2017

ursjoss commented Mar 5, 2017 • edited Loading

ursjoss commented Mar 5, 2017

yglodt commented Mar 5, 2017

ursjoss commented Mar 5, 2017

ursjoss commented Mar 5, 2017

yglodt commented Mar 5, 2017

brsanthu commented Mar 5, 2017

ursjoss commented Mar 5, 2017 • edited Loading

wilkinsona commented Mar 5, 2017

ursjoss commented Mar 5, 2017

wilkinsona commented Mar 5, 2017

yglodt commented Mar 5, 2017

ursjoss commented Mar 5, 2017 • edited Loading

brsanthu commented Mar 6, 2017

wilkinsona commented Mar 6, 2017

ursjoss commented Mar 6, 2017 • edited Loading

Ristop commented Mar 6, 2017

Ristop commented Mar 7, 2017

wilkinsona commented Mar 7, 2017

ursjoss commented Mar 7, 2017

brsanthu commented Mar 7, 2017

FlowerWrong commented Mar 8, 2017

roboojack commented Mar 8, 2017

VittorioZinno commented Mar 10, 2017 • edited Loading

JasonCL2015 commented Mar 15, 2017 • edited by philwebb Loading

akageun commented Mar 17, 2017

bestv5 commented Mar 20, 2017

geodavies commented Mar 20, 2017

ArloL commented Mar 23, 2017

yglodt commented Mar 3, 2017 •

edited

Loading

ursjoss commented Mar 5, 2017 •

edited

Loading

ursjoss commented Mar 5, 2017 •

edited

Loading

ursjoss commented Mar 5, 2017 •

edited

Loading

ursjoss commented Mar 6, 2017 •

edited

Loading

VittorioZinno commented Mar 10, 2017 •

edited

Loading

JasonCL2015 commented Mar 15, 2017 •

edited by philwebb

Loading