Re: log4j class loader
Hi Michelle, I think this problem is due to the maven setup. If you have maven set up your classpath, and declare a dependency on log4j, then maven will put the log4j.jar file into the classpath. But in order to have maven also put log4j.properties into the classpath, you need tell maven to add a dependency on a resources directory that has the log4j.properties. For example, build resources resource directorysrc/main/resources/directory /resource /resources What the above snippet does is to add src/main/resources to the classpath when building the jar file. Something similar needs to be done for exectck or tck... Craig On Mar 7, 2012, at 6:28 PM, Michelle Caisse wrote: Which classloader is the one used to load log4j? -- Michelle On 3/6/2012 7:36 PM, Craig L Russell wrote: Hi Michelle, On Mar 6, 2012, at 5:50 PM, Michelle Caisse wrote: On 3/2/2012 11:25 AM, Craig L Russell wrote: It looks like log4j looks in the class loader that loads the log4j classes [1], so putting the configuration file directory in the class loader used to load log4j should work. Would it then also be the case that putting the configuration file in the directory from which the log4j jar file is loaded should work? I tried this and it did not work. I looked in Enhance.java and couldn't quite figure out where the log4j jar file is being added to the class path. Log4j is handled by maven's dependency management. The same is currently true for the DataNucleus jars, though I had worked on an alternative to remove DataNucleus from the classpath when the IUT was run. If you're using maven for dependency management, then maven is only going to add the log4j.jar to the classpath, not the directory in which log4j.jar is located. I'd suggest *not* using maven for dependencies for jdori, as it makes jdori not like iut. How about creating a directory for the known jdori dependencies including the log4j.properties and all of DN dependencies and treating it just like an iut except that it's configured by exectck. Then as soon as jdori works, we can expect that a properly set up iut will also work. I understand that there is then a bit of duplicate work to configure jdori if you use mvn dependency management for DN, but I think removing DN and its dependencies from mvn management is actually a good thing. Craig -- Michelle URL[] classPathURLs = new URL[2]; ArrayListURL cpList = new ArrayListURL(); ClassLoader loader = null; try { cpList.add((new File(enhancedIdDirName)).toURI().toURL()); cpList.add((new File(fromDirName)).toURI().toURL()); String[] jars = {jar}; if (impl.equals(iut)) { fi = FileUtils.iterateFiles(new File(iutLibsDirectory), jars, true); while (fi.hasNext()) { cpList.add(fi.next().toURI().toURL()); } } loader = new URLClassLoader(cpList.toArray(classPathURLs), getClass().getClassLoader()); // Utilities.printClasspath(loader); } catch (MalformedURLException ex) { Logger.getLogger(Enhance.class.getName()).log(Level.SEVERE, null, ex); } Actually, I can't figure out where DataNucleus and log4j are being added to the class path of the loader. Craig [1] sources from log4j /** 69 This method will search for coderesource/code in different 70 places. The search order is as follows: 71 72 ol 73 74 pliSearch for coderesource/code using the thread context 75 class loader under Java2. If that fails, search for 76 coderesource/code using the class loader that loaded this 77 class (codeLoader/code). Under JDK 1.1, only the the class 78 loader that loaded this class (codeLoader/code) is used. 79 80 pliTry one last time with 81 codeClassLoader.getSystemResource(resource)/code, that is is 82 using the system class loader in JDK 1.2 and virtual machine's 83 built-in class loader in JDK 1.1. 84 85 /ol 86 */ 87 static public URL getResource(String resource) { 88 ClassLoader classLoader = null; 89 URL url = null; 90 91 try { 92 if(!java1 !ignoreTCL) { 93 classLoader = getTCL(); 94 if(classLoader != null) { 95 LogLog.debug(Trying to find [+resource+] using context classloader 96 +classLoader+.); 97 url = classLoader.getResource(resource); 98 if(url != null) { 99 return url; 100 } 101 } 102 } 103 104 // We could not find resource. Ler us now try with the 105 // classloader that loaded this class. 106 classLoader = Loader.class.getClassLoader(); 107 if(classLoader != null) { 108 LogLog.debug(Trying to find [+resource+] using +classLoader 109 + class loader.); 110 url = classLoader.getResource(resource); 111 if(url != null) { 112 return url; 113 } 114 } 115 } catch(IllegalAccessException t) { 116 LogLog.warn(TSTR,
Re: log4j class loader
We already have resource paths set up in the tck project that include src/conf, which contains log4j.properties. I tried adding the same lines to exectck, but still get the log4j warning. I looked at the jdo-tck-3.1-SNAPSHOT.jar file and both log4j-1.2.13.jar and log4j.properties are in the jar at the root level. -- Michelle On 3/7/2012 8:16 PM, Craig L Russell wrote: Hi Michelle, I think this problem is due to the maven setup. If you have maven set up your classpath, and declare a dependency on log4j, then maven will put the log4j.jar file into the classpath. But in order to have maven also put log4j.properties into the classpath, you need tell maven to add a dependency on a resources directory that has the log4j.properties. For example, build resources resource directorysrc/main/resources/directory /resource /resources What the above snippet does is to add src/main/resources to the classpath when building the jar file. Something similar needs to be done for exectck or tck... Craig On Mar 7, 2012, at 6:28 PM, Michelle Caisse wrote: Which classloader is the one used to load log4j? -- Michelle On 3/6/2012 7:36 PM, Craig L Russell wrote: Hi Michelle, On Mar 6, 2012, at 5:50 PM, Michelle Caisse wrote: On 3/2/2012 11:25 AM, Craig L Russell wrote: It looks like log4j looks in the class loader that loads the log4j classes [1], so putting the configuration file directory in the class loader used to load log4j should work. Would it then also be the case that putting the configuration file in the directory from which the log4j jar file is loaded should work? I tried this and it did not work. I looked in Enhance.java and couldn't quite figure out where the log4j jar file is being added to the class path. Log4j is handled by maven's dependency management. The same is currently true for the DataNucleus jars, though I had worked on an alternative to remove DataNucleus from the classpath when the IUT was run. If you're using maven for dependency management, then maven is only going to add the log4j.jar to the classpath, not the directory in which log4j.jar is located. I'd suggest *not* using maven for dependencies for jdori, as it makes jdori not like iut. How about creating a directory for the known jdori dependencies including the log4j.properties and all of DN dependencies and treating it just like an iut except that it's configured by exectck. Then as soon as jdori works, we can expect that a properly set up iut will also work. I understand that there is then a bit of duplicate work to configure jdori if you use mvn dependency management for DN, but I think removing DN and its dependencies from mvn management is actually a good thing. Craig -- Michelle URL[] classPathURLs = new URL[2]; ArrayListURL cpList = new ArrayListURL(); ClassLoader loader = null; try { cpList.add((new File(enhancedIdDirName)).toURI().toURL()); cpList.add((new File(fromDirName)).toURI().toURL()); String[] jars = {jar}; if (impl.equals(iut)) { fi = FileUtils.iterateFiles(new File(iutLibsDirectory), jars, true); while (fi.hasNext()) { cpList.add(fi.next().toURI().toURL()); } } loader = new URLClassLoader(cpList.toArray(classPathURLs), getClass().getClassLoader()); // Utilities.printClasspath(loader); } catch (MalformedURLException ex) { Logger.getLogger(Enhance.class.getName()).log(Level.SEVERE, null, ex); } Actually, I can't figure out where DataNucleus and log4j are being added to the class path of the loader. Craig [1] sources from log4j /** 69 This method will search for coderesource/code in different 70 places. The search order is as follows: 71 72 ol 73 74 pliSearch for coderesource/code using the thread context 75 class loader under Java2. If that fails, search for 76 coderesource/code using the class loader that loaded this 77 class (codeLoader/code). Under JDK 1.1, only the the class 78 loader that loaded this class (codeLoader/code) is used. 79 80 pliTry one last time with 81 codeClassLoader.getSystemResource(resource)/code, that is is 82 using the system class loader in JDK 1.2 and virtual machine's 83 built-in class loader in JDK 1.1. 84 85 /ol 86 */ 87 static public URL getResource(String resource) { 88 ClassLoader classLoader = null; 89 URL url = null; 90 91 try { 92 if(!java1 !ignoreTCL) { 93 classLoader = getTCL(); 94 if(classLoader != null) { 95 LogLog.debug(Trying to find [+resource+] using context classloader 96 +classLoader+.); 97 url = classLoader.getResource(resource); 98 if(url != null) { 99 return url; 100 } 101 } 102 } 103 104 // We could not find resource. Ler us now try with the 105 // classloader that loaded this class. 106 classLoader = Loader.class.getClassLoader();
[jira] [Created] (JDO-707) Refactor JDO parent child poms
Refactor JDO parent child poms Key: JDO-707 URL: https://issues.apache.org/jira/browse/JDO-707 Project: JDO Issue Type: Improvement Components: api, tck Affects Versions: JDO 3 maintenance release 1 (3.1) Reporter: Matthew T. Adams Assignee: Matthew T. Adams Fix For: JDO 3 maintenance release 1 (3.1) Create a parent-pom module, make modules api, exectck tck inherit from it, then create a simple multimodule root pom which can be used to build all projects. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (JDO-707) Refactor JDO parent child poms
[ https://issues.apache.org/jira/browse/JDO-707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthew T. Adams updated JDO-707: - Attachment: JDO-707-1.patch This patch effectively changes the root pom to be a simple multimodule pom and creates a new module, parent-pom, to house a new, JDO parent pom and changes the api, exectck tck modules to inherit it. Refactor JDO parent child poms Key: JDO-707 URL: https://issues.apache.org/jira/browse/JDO-707 Project: JDO Issue Type: Improvement Components: api, tck Affects Versions: JDO 3 maintenance release 1 (3.1) Reporter: Matthew T. Adams Assignee: Matthew T. Adams Labels: parent, pom Fix For: JDO 3 maintenance release 1 (3.1) Attachments: JDO-707-1.patch Create a parent-pom module, make modules api, exectck tck inherit from it, then create a simple multimodule root pom which can be used to build all projects. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (JDO-708) Create JIRA component entry for exectck parent-pom modules
Create JIRA component entry for exectck parent-pom modules -- Key: JDO-708 URL: https://issues.apache.org/jira/browse/JDO-708 Project: JDO Issue Type: Task Affects Versions: JDO 3 maintenance release 1 (3.1) Reporter: Matthew T. Adams Fix For: JDO 3 maintenance release 1 (3.1) The exectck doesn't have a JIRA component entry, so it cannot be identified as a component when entering an issue. If the parent-pom module that is created as part of JDO-707 is accepted, then we also need to create a JIRA component for that, too. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira