db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <craig.russ...@oracle.com>
Subject Re: log4j class loader
Date Wed, 07 Mar 2012 02:36:10 GMT
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