db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michelle Caisse <mcai...@sonic.net>
Subject Re: log4j class loader
Date Thu, 08 Mar 2012 03:41:17 GMT
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!
>
>


Mime
View raw message