There is a difference between a NoClassDefFoundError and a 
ClassNotFoundException.  What class are you getting the NoClassDefFoundError 
on?  A NoClassDefFoundError is usually caused by a) a ClassNotFoundExcpetion or 
b) an exception that occurs during static initialization of a class.  

Can you provide the stack trace?

Ralph

> On Nov 3, 2014, at 1:46 PM, Paul Benedict <[email protected]> wrote:
> 
> Right now my code cannot see the API classes; so I get a
> NoClassDefFoundError. If I can see the classes, that will be a win :-) even
> if the functionality will fail.
> 
> 
> Cheers,
> Paul
> 
> On Mon, Nov 3, 2014 at 2:42 PM, Ralph Goers <[email protected]>
> wrote:
> 
>> The Log4j API is going to look for its implementation. It does that by
>> looking for a property file using ClassLoader.getResources(). If that file
>> cannot be located because it is in a different ClassLoader then you will
>> have problems.
>> 
>> When you say it doesn’t work, what exactly is happening?
>> 
>> Ralph
>> 
>>> On Nov 3, 2014, at 12:51 PM, Paul Benedict <[email protected]> wrote:
>>> 
>>> The first smart thing to do in Wildfly 8.1 is install a common instance
>> of
>>> log4j2. You do this by creating a module. Here are my steps:
>>> 
>>> 1. Go to <WildFlyHome>/modules
>>> 2. Create folders org/apache/log4j2/main
>>> 3. Drop in the api jar.
>>> 4. Create a module.xml with this content:
>>> 
>>> <?xml version="1.0" encoding="UTF-8"?>
>>> <module xmlns="urn:jboss:module:1.3" name="org.apache.log4j2">
>>>   <resources>
>>>       <resource-root path="log4j-api-2.1.jar"/>
>>>   </resources>
>>> </module>
>>> 
>>> PS: I could have also dropped in the "core" jar but I am being
>>> conservative. Since I can't get anything to work, this is the minimal.
>>> 
>>> Then inside my ejb-jar project, I create myself a
>>> META-INF/jboss-deployment-descriptor.xml file like this:
>>> 
>>> <jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.0">
>>> <deployment>
>>>   <dependencies>
>>>     <module name="org.apache.log4j2" />
>>>   </dependencies>
>>> </deployment>
>>> </jboss-deployment-structure>
>>> 
>>> That should automatically map the jar into my module's classpath. I've
>> done
>>> this before but I am obviously missing something because it's not
>> working.
>>> If anyone can help by following these steps and figuring this out, I'd be
>>> happy to hear someone's success story.
>>> 
>>> Cheers,
>>> Paul
>>> 
>>> On Sat, Nov 1, 2014 at 7:00 PM, Ralph Goers <[email protected]>
>>>> wrote:
>>>> 
>>>>> I am not aware that we have implemented any specific support for EARs.
>>>>> That said, I am not sure we need to. I’ve also looked at the Log4j 1.x
>> code
>>>>> and don’t see anything specific to supporting META-INF or EARs.
>>>>> 
>>>>> Log4j will load log4j2.xml from the classpath, so you should be able to
>>>>> do something like what is described at
>>>>> https://developer.jboss.org/wiki/HowToPutAnExternalFileInTheClasspath
>> <
>>>>> https://developer.jboss.org/wiki/HowToPutAnExternalFileInTheClasspath
>>> .
>>>>> I believe you can also place it in the /lib directory or whatever
>> directory
>>>>> is defined in the library-directory element of the deployment
>> descriptor.
>>>>> See
>>>>> 
>> http://javahowto.blogspot.com/2006/10/use-library-directory-in-javaee-5-apps.html
>>>>> <
>>>>> 
>> http://javahowto.blogspot.com/2006/10/use-library-directory-in-javaee-5-apps.html
>>>>>> .
>>>>> 
>>>>> What app server are you using?
>>>>> 
>>>>> Ralph
>>>>> 
>>>>> 
>>>>> 
>>>>>> On Nov 1, 2014, at 10:56 AM, Paul Benedict <[email protected]>
>>>>> wrote:
>>>>>> 
>>>>>> When I used log4j 1.x, I could put my log4j.xml in the
>>>>> <EarRoot>/META-INF
>>>>>> folder and it was found. I did try this with log4j 2.0.2 and the
>>>>>> configuration was not found.
>>>>>> 
>>>>>> I read this but it only talks about WARs. I don't have a WAR but an
>> EAR
>>>>>> with EJB modules.
>>>>>> http://logging.apache.org/log4j/2.x/manual/webapp.html
>>>>>> 
>>>>>> So is this feature missing in 2.x? Or did I do something wrong?
>>>>>> 
>>>>>> Cheers,
>>>>>> Paul
>>>>> 
>>>> 
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>> 
>> 


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to