Re: [report] Classloading problems between Catalina and Cocoon

on 2/27/01 7:57 AM, Pier P. Fumagalli at [EMAIL PROTECTED] wrote: > Now, since Forte/NetBeans is now part of Sun, I believe that the best way to > go is to have the two teams to talk together (not really easy as I know > you're in Czechoslovakia and we are in California :) > > Duncan, can you he

Re: [report] Classloading problems between Catalina and Cocoon

Hi frederic! frederic barachant wrote: > Hi guys. > i've been watching the list for a week by now, to understand how things work here. > I'm a not so long C/C++ coder (7 years in graphics programming and GUI design) and > went to Java last year. I'm very enthusiastic about it, and all products f

Re: Re: [report] Classloading problems between Catalina and Cocoon

- Original Message - From: "frederic barachant" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, February 27, 2001 5:14 PM Subject: Re: Re: [report] Classloading problems between Catalina and Cocoon > Hi guys. > i've been watching the list for

Re: Re: [report] Classloading problems between Catalina and Cocoon

Hi guys. i've been watching the list for a week by now, to understand how things work here. I'm a not so long C/C++ coder (7 years in graphics programming and GUI design) and went to Java last year. I'm very enthusiastic about it, and all products from apache, gnu,... (using gcc, apache and tomcat

Re: [report] Classloading problems between Catalina and Cocoon

Petr Jiricka <[EMAIL PROTECTED]> wrote: > > (Replying late, as I am behind in my e-mail.) > > Yes, we (Forte/NetBeans) are having very similar problems as Cocoon and JSP. > What we did is we patched Javac to allow loading java files from other > sources than java.io.File, and did some other chan

Re: [report] Classloading problems between Catalina and Cocoon

dson" <[EMAIL PROTECTED]>; "Servlet API Experts" <[EMAIL PROTECTED]>; "JAXP Expert Group" <[EMAIL PROTECTED]> Sent: Friday, February 23, 2001 4:17 AM Subject: Re: [report] Classloading problems between Catalina and Cocoon > James Duncan Davidson <[

Re: [report] Classloading problems between Catalina and Cocoon

Nic Ferrier <[EMAIL PROTECTED]> wrote: > "Pier P. Fumagalli" <[EMAIL PROTECTED]> 23-Feb-01 12:35:53 PM > >> It doesn't prevent anyone from using or modifying >> it, but it is impossible to redistribute it together a >> BSD-like licensed application like Tomcat, and >> that's what I'm concerned ab

Re: [report] Classloading problems between Catalina and Cocoon

>>> "Pier P. Fumagalli" <[EMAIL PROTECTED]> 23-Feb-01 12:35:53 PM >>> >It doesn't prevent anyone from using or modifying >it, but it is impossible to redistribute it together a >BSD-like licensed application like Tomcat, and >that's what I'm concerned about. Well you could get dispensation for

Re: [report] Classloading problems between Catalina and Cocoon

Nic Ferrier <[EMAIL PROTECTED]> wrote: "Pier P. Fumagalli" <[EMAIL PROTECTED]> 23-Feb-01 3:15:00 AM > >> If someone can check out what JavaCC produces >> as an output, then it wouldn't be "that" hard to come >> up with a compiler, using InfoSeek's Trove Class File >> API (Check out

Re: [report] Classloading problems between Catalina and Cocoon

>>> "Pier P. Fumagalli" <[EMAIL PROTECTED]> 23-Feb-01 3:15:00 AM >>> >If someone can check out what JavaCC produces >as an output, then it wouldn't be "that" hard to come >up with a compiler, using InfoSeek's Trove Class File >API (Check out >for mor

Re: [report] Classloading problems between Catalina and Cocoon

James Duncan Davidson <[EMAIL PROTECTED]> wrote: > on 2/22/01 8:40 AM, Tom Reilly at [EMAIL PROTECTED] wrote: > >> That said, I think javac is never going to be this compiler, at least >> not any time soon. They just re-wrote it and I doubt they'll do it >> again. A more mobile open source proje

Re: [report] Classloading problems between Catalina and Cocoon

Tom Reilly <[EMAIL PROTECTED]> wrote: > > +1 > > There's no reason going from .java to a Class object should be any > harder than going from .class to a Class object. If the compiler used > ClassLoader's instead of manually reading .class files in through the > file system, fast in-memory com

Re: [report] Classloading problems between Catalina and Cocoon

on 2/22/01 8:40 AM, Tom Reilly at [EMAIL PROTECTED] wrote: > That said, I think javac is never going to be this compiler, at least > not any time soon. They just re-wrote it and I doubt they'll do it > again. A more mobile open source project like KJC is probably more > realistic. There was ver

Re: [report] Classloading problems between Catalina and Cocoon

Tom Reilly wrote: > > +1 > > There's no reason going from .java to a Class object should be any > harder than going from .class to a Class object. If the compiler used > ClassLoader's instead of manually reading .class files in through the > file system, fast in-memory compilation becomes a p

Re: [report] Classloading problems between Catalina and Cocoon

+1 There's no reason going from .java to a Class object should be any harder than going from .class to a Class object. If the compiler used ClassLoader's instead of manually reading .class files in through the file system, fast in-memory compilation becomes a possibility (and your runtime clas

Re: [report] Classloading problems between Catalina and Cocoon

on 2/15/01 10:12 AM, Stefano Mazzocchi at [EMAIL PROTECTED] wrote: > today's java compilation technology stinks! Or rather, the method of accessing today's Java compiler stinks. > Pier and I started talking about a JSR for Java Compilation API months > ago and I even wrote a JSR-ignition docume

Re: [report] Classloading problems between Catalina and Cocoon

James Duncan Davidson <[EMAIL PROTECTED]> wrote: > on 2/15/01 10:12 AM, Stefano Mazzocchi at [EMAIL PROTECTED] wrote: > >> today's java compilation technology stinks! > > Or rather, the method of accessing today's Java compiler stinks. Nono, the whole technology stinks. To include Java classes

[report] Classloading problems between Catalina and Cocoon

[sorry for the cross post, but all of you should be aware of this] Cocoon is a devilishly complex java application for mainly three reasons: 1) it uses a huge number of dependencies to external APIs and applications 2) it recompiles parts of itself at startup for optimization 3) by design, it