[kaffe] Re: 1.1.0 wishlist

[Dalibor Topic]

Hallo Helmer,

--- Helmer Krämer <hkraemer at freenet.de> wrote:
> On Mon, 12 May 2003 09:21:59 -0700 (PDT)
> Dalibor Topic <robilad at yahoo.com> wrote:
> 
> 
> Hi Dalibor,
> 
> you seem to be too quick for me ...
> 
> > +   fix 1.2 style class loading
> 
> If nobody else is working on this one at the moment, I could provide
> a (surprisingly) working patch. It basically makes kaffe distinguish
> between the bootclasspath and the application classpath and defines a
> code source for the application classes. Biggest issue with this patch
> is the nonexisting support for certificates.

That would be really nice to have. Given that kaffe's current class laoder
doesn't do any certificate processing either, AFAIK, that's better than nothing
;)
 
> > I've got a patch that lets tomcat 4 load quite a bit. It'll need some
> polishing
> > before I can check it in, though.
> 
> what does "quite a bit" mean? Does it start and run?

the 'quite' came from my memory, but it turns out the improvement was not that
exciting. it now throws an exception during loading at a later point.

bash-2.05a$ bin/catalina.sh run
Using CATALINA_BASE:   /tmp/topic/jakarta-tomcat-4.1.24
Using CATALINA_HOME:   /tmp/topic/jakarta-tomcat-4.1.24
Using CATALINA_TMPDIR: /tmp/topic/jakarta-tomcat-4.1.24/temp
Using JAVA_HOME:       /tmp/topic/tomkaffe/
Exception during startup processing
java.lang.reflect.InvocationTargetException:
java.lang.ExceptionInInitializerError: [exception was
java.util.MissingResourceException: Bundle
org.apache.catalina.core.LocalStrings not found    
org.apache.catalina.core.LocalStrings   ]
        at java.lang.reflect.Method.invoke0(Method.java:native)
        at java.lang.reflect.Method.invoke(Method.java:256)
        at java.lang.reflect.Constructor.newInstance(Constructor.java:90)
        at java.lang.Class.newInstance(Class.java:398)
        at
org.apache.commons.digester.ObjectCreateRule.begin(ObjectCreateRule.java:253)
        at org.apache.commons.digester.Rule.begin(Rule.java:200)
        at
org.apache.commons.digester.Digester.startElement(Digester.java:1268)
        at org.apache.xerces.parsers.AbstractSAXParser.startElement(source file
unknown:line unknown, pc 0x8407609)
        at org.apache.xerces.impl.dtd.XMLDTDValidator.startElement(source file
unknown:line unknown, pc 0x848ae61)
        at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanStartElement(source
file unknown:line unknown, pc 0x8775ce6)
        at
org.apache.xerces.impl.XMLDocumentScannerImpl$ContentDispatcher.scanRootElementHook(source
file unknown:line unknown, pc 0x83b5620)
        at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(source
file unknown:line unknown, pc 0x869c5f0)
        at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(source file
unknown:line unknown, pc 0x8724cb1)
        at org.apache.xerces.parsers.DTDConfiguration.parse(source file
unknown:line unknown, pc 0x84a8a7a)
        at org.apache.xerces.parsers.DTDConfiguration.parse(source file
unknown:line unknown, pc 0x8440cee)
        at org.apache.xerces.parsers.XMLParser.parse(source file unknown:line
unknown, pc 0x8668d31)
        at org.apache.xerces.parsers.AbstractSAXParser.parse(source file
unknown:line unknown, pc 0x848223b)
        at org.apache.commons.digester.Digester.parse(Digester.java:1543)
        at org.apache.catalina.startup.Catalina.start(Catalina.java:449)
        at org.apache.catalina.startup.Catalina.execute(Catalina.java:400)
        at org.apache.catalina.startup.Catalina.process(Catalina.java:180)
        at java.lang.reflect.Method.invoke0(Method.java:native)
        at java.lang.reflect.Method.invoke(Method.java:256)
        at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:203)

that's further than with current kaffe, though there is some nasty problem with
resource loading. I'm using the ResourceBundle implementation from GNU
Classpath here.

The patch essentially rips out parts of kaffe's class library and replaces them
by Classpath's implementation. It's not polished, and definitely won't go in in
that form, since I haven't really looked at Classpath's implementation of the
classes I replaced. The patch also irresponsibly fakes a few things, like stack
trace elements. It's an ugly hack and by no means supposed to be used other
than a demonstration of 'we can get a bit further loading tomcat using some
bits from classpath'. That being said, it's attached.

cheers,
dalibor topic

__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tomcat.patch.bz2
Type: application/octet-stream
Size: 73512 bytes
Desc: tomcat.patch.bz2
Url : http://kaffe.org/pipermail/kaffe/attachments/20030513/8edba057/attachment-0003.obj