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 help out? I'll see what I can do. Be forewarned, forward progress will take at least a week to start seeing. I'll just liase with a subset of this group though. .duncan -- James Duncan Davidson http://x180.net/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [report] Classloading problems between Catalina and Cocoon
- Original Message - From: "Pier P. Fumagalli" [EMAIL PROTECTED] To: "James Duncan Davidson" [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: "Cocoon" [EMAIL PROTECTED]; "Tomcat" [EMAIL PROTECTED]; "James Davidson" [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 [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 project like KJC is probably more realistic. There was very high interest at the time that this was percolating around, but if Bill M. has now left, well... Then its a staffing concern. Rgh. I'm still digging, so... A compiler relying on a ClassLoader instead of single .class files is definitely required, not only in Servlet world, but also in the IDE space. I heard that Forte was having issues with the current JavaC too, we might want to check with them what were their requirements (and if I'm not wrong, they were exactly the same as ours!) (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 changes, too. We are distributing the patched version with the IDE (see file /modules/ext/javac.jar in the IDE distribution). We tried to submit the changes back to the Javac team (Bill M., I heard), but weren't successful. So maybe we could try again now ? It looks like there is enough interest in the community. Do you know who we should contact now ? Petr Pier -- -- -- Pier P. Fumagalli mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
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 changes, too. We are distributing the patched version with the IDE (see file /modules/ext/javac.jar in the IDE distribution). We tried to submit the changes back to the Javac team (Bill M., I heard), but weren't successful. So maybe we could try again now ? It looks like there is enough interest in the community. Do you know who we should contact now ? Good news, when I had a chat with Bill Maddox about the Compiler he mentioned me about some changes you were making in that direction, and I'm pleased to hear that you guys made it... 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 help out? Pier (who will keep Tomcat and Cocoon informed) -- Pier Fumagalli - Sun Microsystems Inc. - mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
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). Despite these tools are really cool, i still think there is a lack of user friendly interfacing that could bring these tools to the higher level (or lower, depending on how you see that :) The question is are you aware of projects of GUIs for Tomcat and others? If yes, i'm sorry to disturb you, but would like a to have a link anyway. If no, do you think a swing interface could be plugged to tomcat? (not talking of integrating it directly, but more an external remote utility that could operate from anywhere) Have a nice day, peace. /-/ Frederic "pepe" barachant IO labs GFX and TOOLS for and from Lightwave and Aura I C Q : ASK Visit http://www.io-labs.com and http://www.kframed.com right now ! join our board http://www.io-labs.com/cgi-local/ikonboard/ikonboard.cgi for latest news - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
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 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). Despite these tools are really cool, i still think there is a lack of user friendly interfacing that could bring these tools to the higher level (or lower, depending on how you see that :) The question is are you aware of projects of GUIs for Tomcat and others? If yes, i'm sorry to disturb you, but would like a to have a link anyway. If no, do you think a swing interface could be plugged to tomcat? (not talking of integrating it directly, but more an external remote utility that could operate from anywhere) Have a nice day, peace. Frederic, I am not quite sure what you expect from a GUI tool for Tomcat. All the major IDEs (Forte, JBuilder, VisualAge) allow you to develop servlets/JSPs in the IDE and test and debug them in Tomcat. IDEs in general are quite tightly integrated with servers. And there is more to be expected in the future. There are initiatives to design a standard interface between tools and J2EE servers, which would allow you to manage your servers from a GUI and deploy to it. If you are interested, you can look at http://java.sun.com/aboutJava/communityprocess/jsr/jsr_077_management.html http://java.sun.com/aboutJava/communityprocess/jsr/jsr_088_deploy.html Petr /-/ Frederic "pepe" barachant IO labs GFX and TOOLS for and from Lightwave and Aura I C Q : ASK Visit http://www.io-labs.com and http://www.kframed.com right now ! join our board http://www.io-labs.com/cgi-local/ikonboard/ikonboard.cgi for latest news - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
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 http://opensource.go.com/Trove/index.html for more info on it). The big hurdle to go across is definitely the parser... As I told Stef some time ago there is already a free Java compiler. It's called Kopi. You can get it from the kaffe project (and it's own website). Kopi works well enough, especially if you're compiling what you know to be syntactically correct code. It's GPLed but does that exclude you from using it? Nic - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
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 http://opensource.go.com/Trove/index.html for more info on it). The big hurdle to go across is definitely the parser... As I told Stef some time ago there is already a free Java compiler. It's called Kopi. You can get it from the kaffe project (and it's own website). Kopi works well enough, especially if you're compiling what you know to be syntactically correct code. It's GPLed but does that exclude you from using it? 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. If there was already a java compiler with a better license I would have already patched it :) :) :) Maybe we can talk to those guys and ask to change their license... Duncan? Pier -- Pier P. Fumagalli mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
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 the BSD licence from them. If there was already a java compiler with a better license I would have already patched it :) :) :) Better? I would argue that BSD is the problem here. Why not just use the GPL? massive-flame-war-errupts/ Nic - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
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 about. Well you could get dispensation for the BSD licence from them. That's our best shot... We just need a volunteer to do it... Nick? :) :) :) If there was already a java compiler with a better license I would have already patched it :) :) :) Better? I would argue that BSD is the problem here. Why not just use the GPL? massive-flame-war-errupts/ Please, don't start it, we're Ccing 250 mailing lists :) :) :) Pier -- Pier Fumagalli http://www.betaversion.org/ mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
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 classpath becomes the same as your compiler classpath). 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. "Pier P. Fumagalli" [EMAIL PROTECTED] writes: 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 JAVAC doesn't rely on the classloader, but on single File objects, and that causes problems when compiling stuff like JSP... Pier and I started talking about a JSR for Java Compilation API months ago and I even wrote a JSR-ignition document but the 'javac' team sucked it, well, I don't know anything about it. I'll check up on this. We were talking with Bill Maddox, and apparently, he left Sun for Transmeta without saying anything. That's why the whole discussion went down the drain. Just a FYI.. Pier -- Tom Reilly Allaire Corp. http://www.allaire.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
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 possibility (and your runtime classpath becomes the same as your compiler classpath). Possibly. The thing is that loading classes through a ClassLoader has an extreme amount of overhead. When the compiler accesses the class, all of its static initializers would be run. None of this stuff is necessary for basic compilation. Reading the .class files as resources (I'm pretty sure) has the same problem. At least, we were never able to resolve the problem when attempting to do something similar, but things have changed a lot since then. Loading .class files as resources might work now. -Paul 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. "Pier P. Fumagalli" [EMAIL PROTECTED] writes: 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 JAVAC doesn't rely on the classloader, but on single File objects, and that causes problems when compiling stuff like JSP... Pier and I started talking about a JSR for Java Compilation API months ago and I even wrote a JSR-ignition document but the 'javac' team sucked it, well, I don't know anything about it. I'll check up on this. We were talking with Bill Maddox, and apparently, he left Sun for Transmeta without saying anything. That's why the whole discussion went down the drain. Just a FYI.. Pier -- Tom Reilly Allaire Corp. http://www.allaire.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
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 very high interest at the time that this was percolating around, but if Bill M. has now left, well... Then its a staffing concern. Rgh. I'm still digging, so... -- James Duncan Davidson http://x180.net/ !try; do(); - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
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 compilation becomes a possibility (and your runtime classpath becomes the same as your compiler classpath). 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. 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 http://opensource.go.com/Trove/index.html for more info on it). The big hurdle to go across is definitely the parser... Pier -- Pier P. Fumagalli mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
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 project like KJC is probably more realistic. There was very high interest at the time that this was percolating around, but if Bill M. has now left, well... Then its a staffing concern. Rgh. I'm still digging, so... A compiler relying on a ClassLoader instead of single .class files is definitely required, not only in Servlet world, but also in the IDE space. I heard that Forte was having issues with the current JavaC too, we might want to check with them what were their requirements (and if I'm not wrong, they were exactly the same as ours!) Pier -- Pier P. Fumagalli mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
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 document but the 'javac' team sucked it, well, I don't know anything about it. I'll check up on this. -- James Duncan Davidson http://x180.net/ !try; do(); - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[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 wants to be a completely portable servlet these three points make it nearly impossible to design such a thing today, namely because: today's java compilation technology stinks! It doesn't rely on classloading but directly on classpaths, which are simply *ONE* of the possible implementation of classloading. So, there is no way to say to the java compiler "hey, compile this stream I pass you importing the classes available on your classloader". Too damn easy: you need to stream the source on a file, then add the file to the classpath, then instantiate the javac classes passing an array of parameters. All right, it was designed for command line, but is it so hard to shape it into something more modern than 30-year-old command-line stuff? Pier and I started talking about a JSR for Java Compilation API months ago and I even wrote a JSR-ignition document but the 'javac' team sucked it, well, I don't know anything about it. So, 6 months later, we are still with the same stinking problem of having to pass classpaths to the compiler. Ok, those of you who worked with classloaders know that classpaths are poor-man implementation of the beautiful classloading concept. But now you are required to transform a beautiful concept into a stupid one and try to provide an 'classpath' equivalence of your classloading capabilities. Imagine having a classloader that remotely connects to a Jini-based storage system with hot-swap capabilities and all that, tell me, how can I compile my server page so that it includes that class loaded from my jini-classloader? No shit there is no Java CPAN and making one is a pain in the ass: all stinking classes need to be there on your disk at compilation time, no way around it (yes, folks, I even tried to decompile the whole javac to see if I could take parts out and hook the internals, but nothing, no way! the design faults are deep into the very core of the compiler for what I could tell) Sorry for the rant, but grrr Anyway, we are left with this decades-old concept of classpath and we must keep it for now. Ok, so, hopefully, there is a standard way to access the classpath: yeah, a system property, but guess what? each servlet engine will probably sandbox you into your own classloader which has probably nothing to do with the system classpath (in fact, the system classpath should be empty or more or less so for a good system!) Catalina does exactly this. But Jasper works, right? yeah, it does, at the expense of not being portable across servlet engines: it uses a catalina-specific context attribute to obtain its own classloader. Cocoon does the same, hoping that either the Servlet API expert group comes up with a standard attribute for context classpath (which is a stupid idea since it will need to be deprecated in the future when better compilation technologies emerge, but solves the problem for now), or somebody writes a "really-modern" java compiler (I sware, I might well start writing one when I have some time!) Ok, so far so good, the problem is that Catalina expects that JSP are such a great thing that all web applications will want to use them. So, instead of placing jasper.jar into a WEB-INF/lib where it should reside if there was parity for technologies, it resides on the catalina main library /lib and gets 'spoiled' by this fact. Cocoon doesn't pretend to be "the" server pages solution and more modestly reside on its own WEB-INF/lib. Great but the problem is that Catalina tells us our classpath based on our WEB-INF/lib, but forgets to tell us where the Servlet API is! Since it's not part of the system classloader because Catalina is bootstrapped, javac is *NOT* able to compile because it doesn't find the servlets. Easy, you say: add servlet.jar to your WEB-INF/lib. WRONG! the same class loaded on different classloaders is considered a different class, so Cocoon extends javax.servlet.Servlet but *MY* version not Catalina's! Thus, Catalina pukes "you're not a servlet!" and fails to run us. But we are not finished. Even if you add "servlet.jar" to Catalina system classpath, another big problem remains: sealed jar files. The Tomcat people are fully aware of this, but I tried to see what caused the problems with Cocoon in particular. So, it results that if you remove "crimson.jar" from Catalina's /lib it works! Why so? Because crimson.jar is sealed. Now, I thought, what the hell? I'm not touching the /lib directory and I'm fully happy with crimson.jar being the default JAXP parser for all the webapps hosted, but why should this limit my ability to add *MY OWN* JAXP parser to my own library? Ok, so, if it's a sealing problem, we just have to 'unseal' crimson. So I
