cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pier Fumagalli <>
Subject Re: [Kernel2.2] Comments
Date Wed, 31 Mar 2004 19:38:40 GMT
On 31 Mar 2004, at 20:15, Pier Fumagalli wrote:
> On 31 Mar 2004, at 19:55, Hamilton Verissimo de Oliveira (Engenharia - 
> SPO) wrote:
>> -----Mensagem original-----
>> De: Pier Fumagalli []
>>>> I don't understand what you base that "yes" on. Will the 
>>>> classloading
>>>> work? Yes, it will. But will *the* *rest* of the system work? You 
>>>> have
>>>> no guarantee at all.
>>> I wrote 3 servlet containers in my life... :-) I can guarantee that
>>> class loading _will_ work, and it will be entirely transparent by
>>> component/composer classes.
>> Falaccy (Appeal to authority)
> Ok, bad call... But as a proof I wrote some code :-)

Bad call again... :-) Let me explain... The class loading code is 
trivial, it is done by the JVM in itself, it doesn't rely on anything 
weird, undocumented, or in any reason "strange" or custom built.

Blocks exactly behave like webapps from a class loading perspective, no 
more, no less.

That said, during the design of the last two Servlet specifications, 
the idea of proxy classes came out here and there, but always ditched 

A) servlet contexts lookup is not often used, and when you do it, you 
gotta know what you're doing

B) the JDK 1.2 lack of proxy classes doesn't allow to have decoupling 
of requested instance / requestor

C) given that servlet context lookup is based on "Object" keys, rather 
than "Class" role-interfaces the cross-context lookup mechanism would 
have to be deprecated entirely and rewritten from scratch

With my take on the kernel I had a completely clean whiteboard to fill 
up, that's why I used every single bit of functionality I could find in 
the VM to implement what I needed (and that came out to be what Stefano 
required for blocks).

That's why the code is so small, if I could save 2 lines of code by 
relying on something that the VM provided (collections, for example) I 
did it...

In the last revision I also found that the URLClassLoader (by digging 
up in the JVM sources) provided an "addURL()" call, which basically 
meant that I didn't have to write a class loader myself (apart from a 
simple inner class that re-exposes the protected addURL)

As I said again and again, I'm not reinventing the wheel, I'm just 
looking at the JVM with a whiteboard marker in my left hand, and the 
pile of requirements in my right, and when you do it with a fresh 
perspective forgetting about what was there "before" you'll see that 
there are some pretty amazing stuff in there...

I'm not saying "my solution is THE solution", I'm just saying that it 
works (buggy, yeah, but no core issues AFAICS), and before saying 
something like "it won't work", take a step back, look at the code, and 
look at the JVM..


View raw message