[Biojava-dev] Bug report: getClassLoader() null return not handled

[Thomas Down]

Hi Shuvankar,

App-server type systems tend to have their own ClassLoaders, so
even if it's running on totally standard Sun-type VM it's possible
to get this sort of issue.

The fix I've applied based on David's suggestion *might* help you,
but I can't make any promises.  When it's not possible to find the
appropriated ClassLoader (because getClassLoader() returns null)
we now try to use the system classloader.  This might allow Biojava
to load its resource files, but I can see two possible problems:

    - The app-server's security policies don't allow application code
      to use the systemClassLoader (in which case you'll get a
      SecurityException at some point)

    - Depending on how your app is deployed, there's a good chance
      that the biojava.jar file won't be accessible via the system
      ClassLoader.  In this case, BioJava still won't be able to
      load resources.

It's worth giving the new code a try (it's in CVS now.  Unfortunately,
last night's automatic build failed because I forgot to check a file
in.  Hopefully tommorow's build will be fine though).  However, if things
still don't work you might have to take this up with sybase.

     Thomas.



On Sat, May 08, 2004 at 04:03:49PM +0530, Shuvankar Mukherjee wrote:
> I am having similar problem while using biojava on Sybase's EAserver on
> Windows NT.
> I have prepared utility classes which works fine as stand-alone but could
> not be used as AlphabetManager does not get initialized. (Same problem as
> david mentioned).
> 
> EAserver (formerly jaguar) uses a sun VM.
> Is the bug fixed in the current nightly build??? Could not follow David's
> fix ??
> 
> EAserver is not even supporting a call of
>             System.out.println("ClassLoader is
> :"+this.getClass().getClassLoader().getClass().getName());
> 
> while the standalone application supports the call and gives the following
> output.
> 
>         ClassLoader is :sun.misc.Launcher$AppClassLoader
> 
> Please advise ASAP.
> 
> regards
> 
> Shuvankar Mukherjee
> 
> 
> > Thomas Down wrote:
> >
> > > Thanks for pointing this out.
> > >
> > > The same problem actually occurs in quite a lot of places -- quite a
> > > few areas of the BioJava "guts" do things with ClassLoaders.  I've
> > > added a little ClassTools utility which provides a safe method for
> > > getting hold of ClassLoaders.  Should be in CVS soon, or grab
> > > tommorow's nightly build.
> > >
> > Excellent. Thanks.
> >
> > > I'd be very interested to hear how you get on with IKVM.  To date, I
> > > don't know of anyone who's used Biojava with a non-Sun-derived Java
> > > implementation.
> >
> >
> > After making hackish fixes myself (which I'll replace with your new
> > build), I can directly
> > run biojava apps using the biojava.jar file.  However, my normal mode of
> > usage is
> > to run the biojava.jar through an IKVM utility (ikvmc) that translates
> > the java bytecodes into
> > IL (aka .NET) bytecodes.  This is a simple one step process that
> > produces a .NET
> > assembly file biojava.dll.  The assembly includes all the resources in
> > the original .jar.
> > Now, I can just use the biojava API directly from any .NET language.
> > I'm actually in the beginning stages of developing a custom language for
> > bioinformatics
> > (and scientific computing in general) called Scigol.
> > So, now I can transparently access biojava (or any java) APIs from my
> > scigol programs.
> > I plan to do the same with python in future (either using Python.NET
> > or Jython via IKVM compilation).
> > Next I plan to embedd the ikvmc functionality into the scigol
> > interpreter (no compiler yet)
> > so that the user can just drop .jar files into their scigol library path
> > and then use the APIs
> > directly.
> > Note that I'm doing all this uner Linux using Novell's (formerly
> > Ximian's) mono
> > implementation of the .NET stuff.  This means that the Java standard
> > APIs are
> > being supplied by the Class-path project (from which IKVM distributes a
> > IL version as classpath.dll).  The main missing part from class-path is
> > Swing.
> > For this I'm investigating SwingWT - and open source implementation of
> Swing
> > that targets IBM's SWT GUI API (which uses native peers on various
> > platforms).
> > It is cool to see the SwingSet demo running with a native look under
> > Linux/Gnome!
> > I'd like to be able to use Swing from Scigol & C# under Linux & Windows.
> >
> > Thomas Down wrote:
> >
> > > I actually found calls to getClassLoader in 20 files, they should all
> > > now be fixed.
> > >
> > > (Out of interest, do the IKVM developers give any specific reason for
> > > returning null?  I find it a little bit worrying, because it seems to
> > > suggest that the VM isn't really distinguishing between its bootstrap
> > > classpath (with the core classes) and the application classpath.  I
> > > don't know if this distinction has ever been formally specified by
> > > Sun, but it's something a lot of developers take for granted now.)
> > >
> > Their initial comment when I pasted a bit of the offenting biojava code
> > to the ikvm mailing list
> > was to say that the code was buggy (I explained about the null return &
> > the Sun docs).
> > However, I agree with you, that a behaviour closer to Sun's would be
> > helpful.  I don't understand
> > exactly how the ikvm remapping plumbing works, so perhaps making it
> > perform that
> > way is difficult for some reason.  The remapping does some trickery to
> > make obejcts, strings,
> > exceptions etc. look like the appropriate classes from each API. (e.g.
> > So I can access the
> > System.Exception.InnerException property of an exception caught on the
> > CLI side, say in
> > C#, and if the exception was thrown from Java I'll get the same as if I
> > called java's getCause()
> > method (except that the return result is a CLI Exception class!) ).
> >
> > I will post again to the ikvm list with your comment above (unless you
> > object) and ask why
> > ikvm behaves that way and if there is any reason why making it behave
> > more like the JDK
> > would be difficult or bad.
> >
> > Oh - one other thing.  One reply from the ikvm list commented that the
> > resource names
> > should have a leading '/' on them.  I don't know if that is true or not
> > - but the getResourceAsStream()
> > calls work as is now.
> >
> > Thanks very much for your feedback and fixes.
> > Cheers,
> > -David.
> >
> > _______________________________________________
> > biojava-dev mailing list
> > biojava-dev at biojava.org
> > http://biojava.org/mailman/listinfo/biojava-dev
> >
> _______________________________________________
> biojava-dev mailing list
> biojava-dev at biojava.org
> http://biojava.org/mailman/listinfo/biojava-dev