DO NOT REPLY [Bug 10379] New: - Improvement to FOP Classloader

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10379>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10379

Improvement to FOP Classloader

           Summary: Improvement to FOP Classloader
           Product: Fop
           Version: all
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Enhancement
          Priority: Other
         Component: general
        AssignedTo: fop-dev@xml.apache.org
        ReportedBy: raultman@fcci-group.com


>From the FOP devlist:

> -----Original Message-----
> From: Peter B. West [mailto:pbwest@powerup.com.au]
> 
> The discussion has thrown up some interesting points, and I hope to see 
> Rhett get involved in this soon.
> 
> I hope also that the work Rhett is talking about will give us a solid 
> framework for changes to our support framework, both with the JVM and 
> possibly with the frequently changing jars that we bundle.  There may be 
> other initiatives happening within Apache on that front.

I think a multiplexing classloader would give us a really serious boost with 
regard to flexibility.  This is going to be an extremely important issue not 
only as JVM versions become more important, but also as the differences between 
each vendor interpretation of the VM becomes apparrent.  By supplying a 
classloader that can, based on various properties, deduce the correct class to 
load, we can keep FOP's implementation disentangled from most of these concerns.
 
The actual act of selecting the correct location for loading a class is really 
not that hard, but a classloader that makes decisions for FOP is something 
that's going to also need someone with good experience in FOP development.  
Currently, that person isn't me.  I think that maybe if I and someone who's a 
more core FOP developer could get together in private email we could get a good 
structure for this classloader hammered out.  From there, implementation of it 
would be pretty easy for me to handle.

So, is anyone game?  Like I said, I can write it, but if I design this thing in 
a vacuum, it may not be nearly as good as it could be.

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org