We Keep Coding

Does depedent project in java take log4j config of parent project?

I am having project A and project B, A has jar dependency of project B. I have defined log4j.xml in project A but I am not able to see logs of sub-project(B.jar) in file appender as well as tomcat server console. Does project B will take log4j.xml form parent project A or not then which config does it use?

There is one log4j config for your entire JVM (unless you're working in a containerized environment using class loaders and.... that's not what's described).
Missing log messages implies that the configuration from log4j either (a) isn't what you think it is (i.e. a different log4j.xml is being used) or (b) doesn't have the right settings for the missing log lines.
Adding the following to the JVM at startup may help:
-Dlog4j.debug
It may also be possible to browse the log4j settings via MBeans in jconsole.

If you want all apps (WAR files) in a Tomcat instance to have the same logging configs, the simple solution is to arrange that all WAR files have a copy of the same config file.
If you want the apps to share a common logging framework (with a single configuration), then you should consider using Context Selectors, as described in the Log4j 2 documentation.
Using Context Selectors
There are a few patterns for achieving the desired state of logging separation using ContextSelectors:
Place the logging jars in the container's classpath and set the system property log4j2.contextSelector to org.apache.logging.log4j.core.selector.BasicContextSelector. This will create a single LoggerContext using a single configuration that will be shared across all applications.
Place the logging jars in the container's classpath and use the default ClassLoaderContextSelector. Follow the instructions to initialize Log4j 2 in a web application. Each application can be configured to share the same configuration used at the container or can be individually configured. If status logging is set to debug in the configuration there will be output from when logging is initialized in the container and then again in each web application.
Follow the instructions to initialize Log4j 2 in a web application and set the system property or servlet context parameter log4j2.contextSelector to org.apache.logging.log4j.core.selector.JndiContextSelector. This will cause the container to use JNDI to locate each web application's LoggerContext. Be sure to set the isLog4jContextSelectorNamed context parameter to true and also set the log4jContextName and log4jConfiguration context parameters.
The exact method for setting system properties depends on the container. For Tomcat, edit $CATALINA_HOME/conf/catalina.properties. Consult the documentation for other web containers.
I don't think there is a direct equivalent in Log4j 1.x.

weblogic security realm export via wlst

Just trying to export the default weblogic security realm via wlst, same function as in gui via Security Realms > myrealm > Migration > Export/Import. When I do it via the gui it creates a file called
exportIndex.dat
Just wondering if this is metadata for the gui only? Does anyone know? Can't find much info about this file from the docs. Also can't find the path-to-MBean/mbeanname for it here:
('DomainServices/DomainRuntimeService/DomainConfiguration/mydomain
/SecurityConfiguration/mydomain/DefaultRealm/myrealm/..path-to-MBean/mbeanname..')The other 4 files i can import/export via wlst by cding to correct realm path. These guys I can import/export just fine:
DefaultAuthenticator.dat
XACMLRoleMapper.dat
XACMLAuthorizer.dat
DefaultCredentialMapper.dat

You will find your answers in this documentation

Using Spring #PropertySource in a Maven submodule

In a Spring-boot application, I was having a single module and I was able to inject a configuration file, e.g. "my.properties", that was located in src/main/resources as follows:
#Configuration
#PropertySource("/my.properties")
public class MyConf{
}
Everything was ok, but then I created submodules and now I moved that configuration file in a submodule. When I start the main application I gedt the following exception:
org.springframework.beans.factory.BeanDefinitionStoreException: Failed to parse configuration class [com.myapp.MainApplication]; nested exception is java.io.FileNotFoundException: Could not open ServletContext resource [/home/jeanvaljean/workspace/mainmodule/secondarymodule/my.properties]
As I see, I can solve the issue by writing
#PropertySource("/src/main/resources/my.properties")
Doing this, the path is correct and the file can be loaded.
Anyway, that is an horrible solution, and I'm pretty sure that there is a more elegant and flexible alternative. Any solution?

Spring has a few different implementations of how to find a resource. By using the prefix classpath: you are telling Spring to search for the resource in all the classpath, rather than in the classes that are bundled with your application.
Depending on the ApplicationContenxt, Spring will use a different default Resource class. It looks like in your case, Spring was instantiating a FileSystemResource, which only finds files available on the filesystem with either relative or absolute paths (but not inside jars!). My rule of thumb is to never prefix something if it's in the same module/component/jar, and always prefix it with classpath: if I know it's in a different module/component/jar (some people get mad at this :).
You can read a more in the Spring Documentation - Resources

java spring images in resources folder not available (404 error)

I am working on a Web Application using the Spring Framework in version 4.1.5
I have a resources folder configured and set up correctly and am already loading css, js and image files out of that.
<mvc:resources mapping="/images/**" location="/resources/" />
However, I am also using the resources folder for uploading images into it and displaying them in the frontend. And there's a point where I'm currently stuck and am not proceeding my understanding. I am getting 404 Error (resource not available), while others are working perfectly fine. The paths are all correct and the files are successfully uploaded, I am sure of that.
I have also seen the reverse effect - renaming or even removing resources out of the resources folder does not impact their accessibility over their web url. I am not copying any files to another folder during building the application, so I am working with those files in the resources folder. I also have looked for the filename on my filesystem and its not there anymore, so I assume there must be some cache in place.
Does Spring build an index or cache over the existing resource files at startup? Do I have to refresh any ApplicationContext after uploading files to notify the framework of changes in the file system and if so, how do I do that?
Hopefully someone can help me here :)
Thank you,
Tom
EDIT:
When calling an URL like: localhost:8080/EstelV2/images/testimage.jpg
I run into a 404 resource is not available, even though the testimage.jpg is in the correct folder structure on the file system and get the log output:
2015-04-30 22:13:05,035 - [DEBUG] - [http-nio-8080-exec-4] (DispatcherServlet.java:845) - DispatcherServlet with name 'spring-dispatcher' processing GET request for [/EstelV2/images/testimage.jpg]
2015-04-30 22:13:05,035 - [DEBUG] - [http-nio-8080-exec-4] (AbstractHandlerMethodMapping.java:297) - Looking up handler method for path /images/testimage.jpg
2015-04-30 22:13:05,041 - [DEBUG] - [http-nio-8080-exec-4] (AbstractHandlerMethodMapping.java:305) - Did not find handler method for [/images/testimage.jpg]
2015-04-30 22:13:05,041 - [DEBUG] - [http-nio-8080-exec-4] (AbstractUrlHandlerMapping.java:168) - Matching patterns for request [/images/testimage.jpg] are [/images/**]
2015-04-30 22:13:05,042 - [DEBUG] - [http-nio-8080-exec-4] (AbstractUrlHandlerMapping.java:193) - URI Template variables for request [/images/testimage.jpg] are {}
2015-04-30 22:13:05,042 - [DEBUG] - [http-nio-8080-exec-4] (AbstractUrlHandlerMapping.java:123) - Mapping [/images/testimage.jpg] to HandlerExecutionChain with handler [ResourceHttpRequestHandler [locations=[ServletContext resource [/resources/]], resolvers=[org.springframework.web.servlet.resource.PathResourceResolver#280f257d]]] and 1 interceptor
2015-04-30 22:13:05,042 - [DEBUG] - [http-nio-8080-exec-4] (DispatcherServlet.java:931) - Last-Modified value for [/EstelV2/images/testimage.jpg] is: -1
2015-04-30 22:13:05,042 - [DEBUG] - [http-nio-8080-exec-4] (DispatcherServlet.java:1018) - Null ModelAndView returned to DispatcherServlet with name 'spring-dispatcher': assuming HandlerAdapter completed request handling
2015-04-30 22:13:05,042 - [DEBUG] - [http-nio-8080-exec-4] (FrameworkServlet.java:996) - Successfully completed request

Soo after hours of investigations I came to a conclusion:
My problem was not related to spring, it was a problem about my eclipse project. It seemed, as long as I didn't refresh my project in eclipse, the newly uploaded files were not accessible by the tomcat server - and the old ones which were removed from the file system but still were in the eclipse project kept being accessible.
I turned on both auto-refresh options at Preferences -> General -> Workspace -> "Refresh using native hooks and polling" and "Refresh on access", which solved my problem for now.
Thank you for your help!

servlet specification not mention that WEB_INF is Document root
A special directory exists within the application hierarchy named WEB-INF. This directory contains all things related to the application that aren’t in the document root of the application. The WEB-INF node is not part of the public document tree of the application. No file contained in the WEB-INF directory may be served directly to a client by the container. However, the contents of the WEB-INF directory are visible to servlet code using the getResource and getResourceAsStream method calls on the ServletContext, and may be exposed using the RequestDispatcher calls. so use it for secure your content only but for images put it in other folder in your web path

How to configure C3p0.properties file in a jar file's classpath to read C3P0-config.xml outside the classpath

May be I have phrased the question wrongly but here's the issue. I have a library called util, inside util we have a database class that will be using C3P0 for database connectivity. This util library is used by different devs within the team .
To make life easier for everyone since we have a modular system, each module in the system can specify it's own database connection and properties as it sees fit for their module. The only reason we are doing this is because the methods for calling executing queries are all defined in this libraries and so instead of everyone rewriting the same code over and over it's much efficient to use a shared lib with that functionality.
The current set up is that I have the C3P0.properties file inside my util library classpath and inside it I have defined the path of the C3P0-config.xml file like this.
com.mchange.v2.c3p0.cfg.xml=./conf/c3p0-config.xml
I then build and the jar and give it to the rest of the devs . They then create a conf directory in their application and add the c3p0-config.xml.
The Strucuture of the Directory looks like this
Parent directory - module name {
Sub directories
-lib -> {Util.jar & other jars}
-conf -> {c3p0-config.xml & other config files}
-logs
-modulename.jar
}
On executing the jar file we get the error
2014-02-12 20:50:59 INFO MLog:124 - MLog clients using log4j logging.
2014-02-12 20:50:59 DEBUG MLog:101 - Could not find resource path text file for path '/com/mchange/v2/cfg/vmConfigResourcePaths.txt'. Skipping.
2014-02-12 20:50:59 DEBUG MLog:101 - Added paths from resource path text file at '/mchange-config-resource-paths.txt'
2014-02-12 20:50:59 DEBUG MLog:101 - Reading VM config for path list /com/mchange/v2/log/default-mchange-log.properties, /mchange-commons.properties, /c3p0.properties, hocon:/reference,/application,/c3p0,/, /mchange-log.properties, /
2014-02-12 20:50:59 DEBUG MLog:101 - The configuration file for resource identifier '/mchange-commons.properties' could not be found. Skipping.
java.io.FileNotFoundException: Resource not found at path '/mchange-commons.properties'.
at com.mchange.v2.cfg.BasicPropertiesConfigSource.propertiesFromSource(BasicPropertiesConfigSource.java:64)
at com.mchange.v2.cfg.BasicMultiPropertiesConfig.firstInit(BasicMultiPropertiesConfig.java:185)
at com.mchange.v2.cfg.BasicMultiPropertiesConfig.<init>(BasicMultiPropertiesConfig.java:110)
at com.mchange.v2.cfg.ConfigUtils.read(ConfigUtils.java:63)
at com.mchange.v2.cfg.ConfigUtils.readVmConfig(ConfigUtils.java:115)
at com.mchange.v2.cfg.MLogConfigSource.readVmConfig(MLogConfigSource.java:46)
at com.mchange.v2.log.MLogConfig.refresh(MLogConfig.java:59)
at com.mchange.v2.log.MLog.refreshConfig(MLog.java:59)
at com.mchange.v2.log.MLog.<clinit>(MLog.java:51)
at com.mchange.v2.naming.JavaBeanReferenceMaker.<clinit>(JavaBeanReferenceMaker.java:51)
at com.mchange.v2.c3p0.impl.PoolBackedDataSourceBase.<clinit>(PoolBackedDataSourceBase.java:260)
2014-02-12 20:50:59 DEBUG MLog:101 - The configuration file for resource identifier 'hocon:/reference,/application,/c3p0,/' could not be found. Skipping.
java.io.FileNotFoundException: HOCON lib (typesafe-config) is not available. Also, no resource available at '/reference,/application,/c3p0,/' for HOCON identifier 'hocon:/reference,/application,/c3p0,/'.
at com.mchange.v2.cfg.BasicMultiPropertiesConfig.configSource(BasicMultiPropertiesConfig.java:86)
at com.mchange.v2.cfg.BasicMultiPropertiesConfig.firstInit(BasicMultiPropertiesConfig.java:184)
at com.mchange.v2.cfg.BasicMultiPropertiesConfig.<init>(BasicMultiPropertiesConfig.java:110)
at com.mchange.v2.cfg.ConfigUtils.read(ConfigUtils.java:63)
at com.mchange.v2.cfg.ConfigUtils.readVmConfig(ConfigUtils.java:115)
at com.mchange.v2.cfg.MLogConfigSource.readVmConfig(MLogConfigSource.java:46)
at com.mchange.v2.log.MLogConfig.refresh(MLogConfig.java:59)
at com.mchange.v2.log.MLog.refreshConfig(MLog.java:59)
at com.mchange.v2.log.MLog.<clinit>(MLog.java:51)
at com.mchange.v2.naming.JavaBeanReferenceMaker.<clinit>(JavaBeanReferenceMaker.java:51)
at com.mchange.v2.c3p0.impl.PoolBackedDataSourceBase.<clinit>(PoolBackedDataSourceBase.java:260)
2014-02-12 20:50:59 DEBUG MLog:101 - The configuration file for resource identifier '/mchange-log.properties' could not be found. Skipping.
java.io.FileNotFoundException: Resource not found at path '/mchange-log.properties'.
at com.mchange.v2.cfg.BasicPropertiesConfigSource.propertiesFromSource(BasicPropertiesConfigSource.java:64)
at com.mchange.v2.cfg.BasicMultiPropertiesConfig.firstInit(BasicMultiPropertiesConfig.java:185)
at com.mchange.v2.cfg.BasicMultiPropertiesConfig.<init>(BasicMultiPropertiesConfig.java:110)
at com.mchange.v2.cfg.ConfigUtils.read(ConfigUtils.java:63)
at com.mchange.v2.cfg.ConfigUtils.readVmConfig(ConfigUtils.java:115)
at com.mchange.v2.cfg.MLogConfigSource.readVmConfig(MLogConfigSource.java:46)
at com.mchange.v2.log.MLogConfig.refresh(MLogConfig.java:59)
at com.mchange.v2.log.MLog.refreshConfig(MLog.java:59)
at com.mchange.v2.log.MLog.<clinit>(MLog.java:51)
at com.mchange.v2.naming.JavaBeanReferenceMaker.<clinit>(JavaBeanReferenceMaker.java:51)
at com.mchange.v2.c3p0.impl.PoolBackedDataSourceBase.<clinit>(PoolBackedDataSourceBase.java:260)
What could be the problem ? What I'm I doing wrong ?

In the log messages and stack traces that you've shown, there is nothing wrong at all. These are all DEBUG level messages. (c3p0 & com.mchange libraries should usually be logged at INFO.)
c3p0 & mchange-commons-java check for potential config information in lots of different places. In many of those places, they find nothing, and so move on. Logging at DEBUG, you are watching the process of libraries checking for, e.g., /mchange-log.properties, in the CLASSPATH and failing to find it. At DEBUG, the libraries log that they looked, that they did not find, and the Exception that went along with not finding.
None of this is of concern at all. It is normal.
The main question is whether the config users put in c3p0-config.xml is taking. You are using a relative directory for the file, rather than an absolute filesystem location. I presume that will work, with relative being interpreted relative to the working directory of the process, but I'm not sure it will work, and even if it does, are you sure that it won't be fragile, depend on how users start up your process? Will users run a script that will ensure the proper working directory?