MuleStudio: support log4j-configuration when running as Mule-app

[GoogleCodeExporter]

This relates to issue #254 where a log4j.xml file for local/dev usage was put 
in src/test/resources to avoid that the dev-log-config ended up in the 
production log-config.

Background
----------
MuleStudio 3.4 and onward (and probably any older version) does not pick up 
src/test/resources/log4j.xml when selecting "Run as Mule-application".
Studio picks up log4j.xml or log4j.properties if put in src/main/resources, 
otherwise it falls back to using a log4j.properties bundled with the Studio 
mule-runtime.

Problem
-------
The only way to control logging levels when running in Studio is to add a 
log4j.properties file to src/main/resources. This would be an extra step which 
is non-intuitive for many users.

Proposed solution
---------------
1. Add a log4j.properties in src/main/resources and let the log4j-precedence 
(log4.xml before log4j.properties) take place when deployed to a standalone 
Mule-instance (where we would have both log4j.properties and log4j.xml in this 
case)
2. Remove src/test/resources/log4j.xml introduced with issue 254

Drawbacks
---------
We would have two log4j configuration formats.

Original issue reported on code.google.com by hakan.d...@gmail.com on 23 Jan 2014 at 11:41

[GoogleCodeExporter]

Is this reported as a bug in Mule Studio?
Not picking up files under src/test/resources on the classpath must be treated 
as a bug, right?

Can src/test/resources be added manually to the classpath in Mule Studio as a 
workaround?

Original comment by magnus.l...@gmail.com on 23 Jan 2014 at 12:20

[GoogleCodeExporter]

I'll try to clarify why I don't think this is a bug in MuleStudio:

1. src/test/resources (and src/test/java) is part of the classpath in 
MuleStudio after generating Studio project files with "mvn studio:studio"- so 
running unit/functional tests works as expected

2. When starting the Mule-container with "Run as Mule-app" is seems that the 
Studio-Mule-runtime excludes src/test/... from the classpath.
I find this reasonable, when launching the Mule-app you would probably want to 
run the application under as-close-conditions-as-possible to when the app is 
deployed to a standalone Mule-instance, where src/test/... wouldn't be 
available since it's not packaged with the app.

Original comment by hakan.d...@gmail.com on 23 Jan 2014 at 4:28

[GoogleCodeExporter]

But that should imply that we never ever could get test flows running with the 
Mule Studio launcher???

Then I find the whole concept failing...

Bug or not, I find it very important that we raise a feature request to be able 
to add on the test-parts to the classpath when required!

Original comment by magnus.l...@gmail.com on 24 Jan 2014 at 12:46

[GoogleCodeExporter]

Original comment by hakan.d...@gmail.com on 23 Feb 2014 at 3:25

• Added labels: Milestone-Release0.6.2
• Removed labels: Milestone-Release0.6.1