You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jdo-dev@db.apache.org by Craig L Russell <cr...@oracle.com> on 2012/03/02 19:25:52 UTC
log4j class loader
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.
I looked in Enhance.java and couldn't quite figure out where the log4j
jar file is being added to the class path.
URL[] classPathURLs = new URL[2];
ArrayList<URL> cpList = new ArrayList<URL>();
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 <code>resource</code> in different
70
places. The search order is as follows:
71
72
<ol>
73
74
<p><li>Search for <code>resource</code> using the thread context
75
class loader under Java2. If that fails, search for
76
<code>resource</code> using the class loader that loaded this
77
class (<code>Loader</code>). Under JDK 1.1, only the the class
78
loader that loaded this class (<code>Loader</code>) is used.
79
80
<p><li>Try one last time with
81
<code>ClassLoader.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, t);
117
} catch(InvocationTargetException t) {
118
if (t.getTargetException() instanceof InterruptedException
119
|| t.getTargetException() instanceof InterruptedIOException) {
120
Thread.currentThread().interrupt();
121
}
122
LogLog.warn(TSTR, t);
123
} catch(Throwable t) {
124
//
125
// can't be InterruptedException or InterruptedIOException
126
// since not declared, must be error or RuntimeError.
127
LogLog.warn(TSTR, t);
128
}
129
130
// Last ditch attempt: get the resource from the class path. It
131
// may be the case that clazz was loaded by the Extentsion class
132
// loader which the parent of the system class loader. Hence the
133
// code below.
134
LogLog.debug("Trying to find ["+resource+
135
"] using ClassLoader.getSystemResource().");
136
return ClassLoader.getSystemResource(resource);
137
}
138
13
Craig L Russell
Architect, Oracle
http://db.apache.org/jdo
408 276-5638 mailto:Craig.Russell@oracle.com
P.S. A good JDO? O, Gasp!
Re: log4j class loader
Posted by Michelle Caisse <mc...@sonic.net>.
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>
> <directory>src/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];
>>>>> ArrayList<URL> cpList = new ArrayList<URL>();
>>>>> 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 <code>resource</code> in different
>>>>> 70
>>>>> places. The search order is as follows:
>>>>> 71
>>>>> 72
>>>>> <ol>
>>>>> 73
>>>>> 74
>>>>> <p><li>Search for <code>resource</code> using the thread context
>>>>> 75
>>>>> class loader under Java2. If that fails, search for
>>>>> 76
>>>>> <code>resource</code> using the class loader that loaded this
>>>>> 77
>>>>> class (<code>Loader</code>). Under JDK 1.1, only the the class
>>>>> 78
>>>>> loader that loaded this class (<code>Loader</code>) is used.
>>>>> 79
>>>>> 80
>>>>> <p><li>Try one last time with
>>>>> 81
>>>>> <code>ClassLoader.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, t);
>>>>> 117
>>>>> } catch(InvocationTargetException t) {
>>>>> 118
>>>>> if (t.getTargetException() instanceof InterruptedException
>>>>> 119
>>>>> || t.getTargetException() instanceof InterruptedIOException) {
>>>>> 120
>>>>> Thread.currentThread().interrupt();
>>>>> 121
>>>>> }
>>>>> 122
>>>>> LogLog.warn(TSTR, t);
>>>>> 123
>>>>> } catch(Throwable t) {
>>>>> 124
>>>>> //
>>>>> 125
>>>>> // can't be InterruptedException or InterruptedIOException
>>>>> 126
>>>>> // since not declared, must be error or RuntimeError.
>>>>> 127
>>>>> LogLog.warn(TSTR, t);
>>>>> 128
>>>>> }
>>>>> 129
>>>>> 130
>>>>> // Last ditch attempt: get the resource from the class path. It
>>>>> 131
>>>>> // may be the case that clazz was loaded by the Extentsion class
>>>>> 132
>>>>> // loader which the parent of the system class loader. Hence the
>>>>> 133
>>>>> // code below.
>>>>> 134
>>>>> LogLog.debug("Trying to find ["+resource+
>>>>> 135
>>>>> "] using ClassLoader.getSystemResource().");
>>>>> 136
>>>>> return ClassLoader.getSystemResource(resource);
>>>>> 137
>>>>> }
>>>>> 138
>>>>> 13
>>>>> Craig L Russell
>>>>> Architect, Oracle
>>>>> http://db.apache.org/jdo
>>>>> 408 276-5638 mailto:Craig.Russell@oracle.com
>>>>> P.S. A good JDO? O, Gasp!
>>>>>
>>>>>
>>>>
>>>>
>>>
>>> Craig L Russell
>>> Architect, Oracle
>>> http://db.apache.org/jdo
>>> 408 276-5638 mailto:Craig.Russell@oracle.com
>>> P.S. A good JDO? O, Gasp!
>>>
>>>
>>
>
> Craig L Russell
> Architect, Oracle
> http://db.apache.org/jdo
> 408 276-5638 mailto:Craig.Russell@oracle.com
> P.S. A good JDO? O, Gasp!
>
>
Re: log4j class loader
Posted by Craig L Russell <cr...@oracle.com>.
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>
<directory>src/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];
>>>> ArrayList<URL> cpList = new ArrayList<URL>();
>>>> 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 <code>resource</code> in different
>>>> 70
>>>> places. The search order is as follows:
>>>> 71
>>>> 72
>>>> <ol>
>>>> 73
>>>> 74
>>>> <p><li>Search for <code>resource</code> using the thread context
>>>> 75
>>>> class loader under Java2. If that fails, search for
>>>> 76
>>>> <code>resource</code> using the class loader that loaded this
>>>> 77
>>>> class (<code>Loader</code>). Under JDK 1.1, only the the class
>>>> 78
>>>> loader that loaded this class (<code>Loader</code>) is used.
>>>> 79
>>>> 80
>>>> <p><li>Try one last time with
>>>> 81
>>>> <code>ClassLoader.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, t);
>>>> 117
>>>> } catch(InvocationTargetException t) {
>>>> 118
>>>> if (t.getTargetException() instanceof InterruptedException
>>>> 119
>>>> || t.getTargetException() instanceof InterruptedIOException) {
>>>> 120
>>>> Thread.currentThread().interrupt();
>>>> 121
>>>> }
>>>> 122
>>>> LogLog.warn(TSTR, t);
>>>> 123
>>>> } catch(Throwable t) {
>>>> 124
>>>> //
>>>> 125
>>>> // can't be InterruptedException or InterruptedIOException
>>>> 126
>>>> // since not declared, must be error or RuntimeError.
>>>> 127
>>>> LogLog.warn(TSTR, t);
>>>> 128
>>>> }
>>>> 129
>>>> 130
>>>> // Last ditch attempt: get the resource from the class path. It
>>>> 131
>>>> // may be the case that clazz was loaded by the Extentsion class
>>>> 132
>>>> // loader which the parent of the system class loader. Hence the
>>>> 133
>>>> // code below.
>>>> 134
>>>> LogLog.debug("Trying to find ["+resource+
>>>> 135
>>>> "] using ClassLoader.getSystemResource().");
>>>> 136
>>>> return ClassLoader.getSystemResource(resource);
>>>> 137
>>>> }
>>>> 138
>>>> 13
>>>> Craig L Russell
>>>> Architect, Oracle
>>>> http://db.apache.org/jdo
>>>> 408 276-5638 mailto:Craig.Russell@oracle.com
>>>> P.S. A good JDO? O, Gasp!
>>>>
>>>>
>>>
>>>
>>
>> Craig L Russell
>> Architect, Oracle
>> http://db.apache.org/jdo
>> 408 276-5638 mailto:Craig.Russell@oracle.com
>> P.S. A good JDO? O, Gasp!
>>
>>
>
Craig L Russell
Architect, Oracle
http://db.apache.org/jdo
408 276-5638 mailto:Craig.Russell@oracle.com
P.S. A good JDO? O, Gasp!
Re: log4j class loader
Posted by Michelle Caisse <mc...@sonic.net>.
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];
>>> ArrayList<URL> cpList = new ArrayList<URL>();
>>> 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 <code>resource</code> in different
>>> 70
>>> places. The search order is as follows:
>>> 71
>>> 72
>>> <ol>
>>> 73
>>> 74
>>> <p><li>Search for <code>resource</code> using the thread context
>>> 75
>>> class loader under Java2. If that fails, search for
>>> 76
>>> <code>resource</code> using the class loader that loaded this
>>> 77
>>> class (<code>Loader</code>). Under JDK 1.1, only the the class
>>> 78
>>> loader that loaded this class (<code>Loader</code>) is used.
>>> 79
>>> 80
>>> <p><li>Try one last time with
>>> 81
>>> <code>ClassLoader.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, t);
>>> 117
>>> } catch(InvocationTargetException t) {
>>> 118
>>> if (t.getTargetException() instanceof InterruptedException
>>> 119
>>> || t.getTargetException() instanceof InterruptedIOException) {
>>> 120
>>> Thread.currentThread().interrupt();
>>> 121
>>> }
>>> 122
>>> LogLog.warn(TSTR, t);
>>> 123
>>> } catch(Throwable t) {
>>> 124
>>> //
>>> 125
>>> // can't be InterruptedException or InterruptedIOException
>>> 126
>>> // since not declared, must be error or RuntimeError.
>>> 127
>>> LogLog.warn(TSTR, t);
>>> 128
>>> }
>>> 129
>>> 130
>>> // Last ditch attempt: get the resource from the class path. It
>>> 131
>>> // may be the case that clazz was loaded by the Extentsion class
>>> 132
>>> // loader which the parent of the system class loader. Hence the
>>> 133
>>> // code below.
>>> 134
>>> LogLog.debug("Trying to find ["+resource+
>>> 135
>>> "] using ClassLoader.getSystemResource().");
>>> 136
>>> return ClassLoader.getSystemResource(resource);
>>> 137
>>> }
>>> 138
>>> 13
>>> Craig L Russell
>>> Architect, Oracle
>>> http://db.apache.org/jdo
>>> 408 276-5638 mailto:Craig.Russell@oracle.com
>>> P.S. A good JDO? O, Gasp!
>>>
>>>
>>
>>
>
> Craig L Russell
> Architect, Oracle
> http://db.apache.org/jdo
> 408 276-5638 mailto:Craig.Russell@oracle.com
> P.S. A good JDO? O, Gasp!
>
>
Re: log4j class loader
Posted by Craig L Russell <cr...@oracle.com>.
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];
>> ArrayList<URL> cpList = new ArrayList<URL>();
>> 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 <code>resource</code> in different
>> 70
>> places. The search order is as follows:
>> 71
>> 72
>> <ol>
>> 73
>> 74
>> <p><li>Search for <code>resource</code> using the thread context
>> 75
>> class loader under Java2. If that fails, search for
>> 76
>> <code>resource</code> using the class loader that loaded this
>> 77
>> class (<code>Loader</code>). Under JDK 1.1, only the the class
>> 78
>> loader that loaded this class (<code>Loader</code>) is used.
>> 79
>> 80
>> <p><li>Try one last time with
>> 81
>> <code>ClassLoader.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, t);
>> 117
>> } catch(InvocationTargetException t) {
>> 118
>> if (t.getTargetException() instanceof InterruptedException
>> 119
>> || t.getTargetException() instanceof InterruptedIOException) {
>> 120
>> Thread.currentThread().interrupt();
>> 121
>> }
>> 122
>> LogLog.warn(TSTR, t);
>> 123
>> } catch(Throwable t) {
>> 124
>> //
>> 125
>> // can't be InterruptedException or InterruptedIOException
>> 126
>> // since not declared, must be error or RuntimeError.
>> 127
>> LogLog.warn(TSTR, t);
>> 128
>> }
>> 129
>> 130
>> // Last ditch attempt: get the resource from the class path. It
>> 131
>> // may be the case that clazz was loaded by the Extentsion class
>> 132
>> // loader which the parent of the system class loader. Hence the
>> 133
>> // code below.
>> 134
>> LogLog.debug("Trying to find ["+resource+
>> 135
>> "] using ClassLoader.getSystemResource().");
>> 136
>> return ClassLoader.getSystemResource(resource);
>> 137
>> }
>> 138
>> 13
>> Craig L Russell
>> Architect, Oracle
>> http://db.apache.org/jdo
>> 408 276-5638 mailto:Craig.Russell@oracle.com
>> P.S. A good JDO? O, Gasp!
>>
>>
>
>
Craig L Russell
Architect, Oracle
http://db.apache.org/jdo
408 276-5638 mailto:Craig.Russell@oracle.com
P.S. A good JDO? O, Gasp!
Re: log4j class loader
Posted by Michelle Caisse <mc...@sonic.net>.
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.
-- Michelle
>
> URL[] classPathURLs = new URL[2];
> ArrayList<URL> cpList = new ArrayList<URL>();
> 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 <code>resource</code> in different
> 70
> places. The search order is as follows:
> 71
> 72
> <ol>
> 73
> 74
> <p><li>Search for <code>resource</code> using the thread context
> 75
> class loader under Java2. If that fails, search for
> 76
> <code>resource</code> using the class loader that loaded this
> 77
> class (<code>Loader</code>). Under JDK 1.1, only the the class
> 78
> loader that loaded this class (<code>Loader</code>) is used.
> 79
> 80
> <p><li>Try one last time with
> 81
> <code>ClassLoader.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, t);
> 117
> } catch(InvocationTargetException t) {
> 118
> if (t.getTargetException() instanceof InterruptedException
> 119
> || t.getTargetException() instanceof InterruptedIOException) {
> 120
> Thread.currentThread().interrupt();
> 121
> }
> 122
> LogLog.warn(TSTR, t);
> 123
> } catch(Throwable t) {
> 124
> //
> 125
> // can't be InterruptedException or InterruptedIOException
> 126
> // since not declared, must be error or RuntimeError.
> 127
> LogLog.warn(TSTR, t);
> 128
> }
> 129
> 130
> // Last ditch attempt: get the resource from the class path. It
> 131
> // may be the case that clazz was loaded by the Extentsion class
> 132
> // loader which the parent of the system class loader. Hence the
> 133
> // code below.
> 134
> LogLog.debug("Trying to find ["+resource+
> 135
> "] using ClassLoader.getSystemResource().");
> 136
> return ClassLoader.getSystemResource(resource);
> 137
> }
> 138
> 13
> Craig L Russell
> Architect, Oracle
> http://db.apache.org/jdo
> 408 276-5638 mailto:Craig.Russell@oracle.com
> P.S. A good JDO? O, Gasp!
>
>