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 02:28:18 GMT
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!
>
>


Mime
View raw message