Odd class loader behavior

["Michael J. Walsh" <ja...@nemonik.com>]

I'm having some really odd behavior for a mailet I've written.  As is typical, 
the mailet and its supporting classes is jar'ed up into the james block 
archive (james.bar).

A jar -tvf james.bar looks like so

org/
org/apache
org/apache/james/
.... cut short to get to the point ...
org/apache/james/util/SchedulerNotifyOutputStream.class
org/apache/james/util/SqlResources.class
org/nemonik/
org/nemonik/project/
org/nemonik/project/info/
org/nemonik/project/info/InfoFoo.class
org/nemonik/project/Foo.class
org/nemonik/project/FooHandler.class
org/nemonik/project/myMailet.class


My myMailet extends GenericMailet, creates a FooHandler object that in turns 
creates a Foo object, who in turn creates a InfoFoo object, or that's the way 
things ought to work.  I should note that MyMailet, FooHandler, and Foo are 
all at the same package <org.nemonik.project>, where as InfoFoo is in the 
subpackage <org.nemonik.project.info>. This normally shouldn't be a problem, 
but for some reason it is here.  Note, InfoHandler does have the correct 
import directive  org.nemonik.project.info.InfoFoo.

By simply running James from the command-line I have no clue what is going on, 
since the the application continues to run, but just doesn't move on past the 
point of creating the InfoFoo object.

By running James as so

C:\james-2.0a2-20020128-src>\jdk1.3.1_01\bin\java -Xdebug 
-Xrunjdwp:transport=dt_shmem,server=y,suspend=y 
-Djava.ext.dirs=C:\james-2.0a2-20020128-src\dist\lib  -jar 
C:\james-2.0a2-20020128-src\dist\bin\phoenix-loader.jar

I'm able to attach NetBeans' JPDA debugger across a shared memory into James 
and debug up until the attempted creation of the InfoFoo object, just as 
things get unhinged as java.lang.ClassLoader.checkPackageAccess is placed on 
the call stack.

I also put debugging code into InfoFoo, but the code never gets called, so it 
doesn't appear InfoFoo ever gets initialized.

Any pointers?  Am I missing something here, or have I completely lost 
something fundamental.

-Michael


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>