Re: Compiling with Servlet spec 2.3 classloading
Hi Jakob, [EMAIL PROTECTED] wrote: Your solution definitely looks nicer than mine! -- and a somewhat other and larger project ;-) Have you made a Cocoon hook for this? or should I try to give it a go? Please do. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Compiling with Servlet spec 2.3 classloading
Your solution definitely looks nicer than mine! -- and a somewhat other and larger project ;-) Have you made a Cocoon hook for this? or should I try to give it a go? I too find the pizza compiler somewhat strange - been looking around for other compilers, but an awfull lot of the are inheretedly based on classpaths instead of ClassLoaders - can't wait to see the JDT compiler make star imports in my xsp pages! Regards Jakob Dalsgaard Udvikler e-mail: [EMAIL PROTECTED] Vesterbrogade 149 1620 København V Tlf.: 70 25 80 30 Fax.: 70 25 80 31 Christopher Oliver <[EMAIL PROTECTED]> 12/15/02 12:37 AM To: [EMAIL PROTECTED], [EMAIL PROTECTED] cc: Subject: Re: Compiling with Servlet spec 2.3 classloading I've also had to try to solve the embedded compiling problem (for other reasons) and I've also tried to use Pizza. Unfortunately, Pizza is very poor quality code and has severe limitations that made it unusable for me. Instead I've used the eclipse.org Java Development Tools compiler (which is excellent) to implement a simple embeddable compiler API. I've placed a copy of the source code on my ftp server if anyone is interested in using it (ftp://ftp.primaryinterface.com/pub/javacAPI). There is no license for the code I've written. The API itself has no dependencies on other software. And the provided implementation has no dependencies other than on eclipse (don't know if that is a problem for Apache projects...). The provided zip file contains source, compiled code, javadocs, and a couple of example programs: one that simulates the javac command line compiler, and another that demonstrates compiling source code in memory and dynamically loading the resulting classes. Regards, Chris Stefano Mazzocchi wrote: > [EMAIL PROTECTED] wrote: > >> Gee, now I've been lurking about the cocoon mailing lists for years, >> posting small and easily ignorable questions - and now this reply; >> it's probably the first time I see: "You are my man, really. I love >> this." on this mailing list... thanks Stefano - nice to know that I >> might be on the right path. > > > Hey, you saved me from writing a java compiler, isn't that something? ;-) > >> Actually I haven't patched pizza, just extended one of their classes ;-) > > > Even better. > >> I tried to compile pizza myself but ran into some troubles getting >> the bootstrap compiler for the pizza files up and running, and since >> extending their classes did the trick I didn't bother too much. As a >> side note: I kinda like the strongly typed hashtables of the pizza >> language (highly irrelevant for the classloading matter) >> >> The code is actually written for my employer, but he has on more >> occasions agreed to let solutions sieve back to the open source >> community - and this thing is really small > > > Great. > >> A small disclaimer: I haven't tested this beast thoroughly, but I >> know for sure that statements like "import >> java.util.logging.SocketHandler" and "import java.util.loggging.*" >> work equally well - which was one of my major concerns since all I >> have is a classloader (and not a jar-file) and hence I cannot list >> the contents of a package (I might be wrong on this). But it seems >> that the pizza compiler is doing *the right thing* (tm) and scanning >> all star-imports for classes not explicitly imported. > > > good > >> First of all a big thank you to the Pizza people for creating the >> compiler that makes my small addon possible - as written I've posted >> a message on the pizzacompiler discussion forum, asking whether they >> would like to add my stuff, >> http://sourceforge.net/forum/forum.php?thread_id=766013&forum_id=129481, >> but no reply yet - apparently not everybody is as eager about >> classloding compilers as cocoon folkes. I will immediately send of an >> email to the developers asking if they could accept my stuff. In the >> mean time please copy my stuff if you need it. Find attached a >> zip-file containing both source and compiled version - dump the >> neupart-pizza.jar into WEB-INF, edit cocoon.xconf to use the >> com.neupart.cocoon.pizza.ClassLoadingPizza compiler instead of the >> normal Pizza compiler class - and off you go! > > > Great. I'll try it ASAP. > >> This version might not be the final say on the issue! > > > ok > > thanks much > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Java compiler API [WAS Re: Compiling with Servlet spec 2.3 classloading]
Hi, Great stuff, Chris! I didn't realize Eclipse comes with its own compiler. Your API is a great tool to abstract out the inner details of a compiler. I'll check out both of them to see how they could be used in a useful way in some of the things I have in mind. I'm primarily interested in coming up with a way to define Scheme-like hygienic macros for Java, which would allow extending the Java language syntax in a clean way by developers: http://webweavertech.com/ovidiu/weblog/archives/000122.html Having a compiler API that can be used makes a huge difference. Regards, Ovidiu On Saturday, Dec 14, 2002, at 15:37 US/Pacific, Christopher Oliver wrote: I've also had to try to solve the embedded compiling problem (for other reasons) and I've also tried to use Pizza. Unfortunately, Pizza is very poor quality code and has severe limitations that made it unusable for me. Instead I've used the eclipse.org Java Development Tools compiler (which is excellent) to implement a simple embeddable compiler API. I've placed a copy of the source code on my ftp server if anyone is interested in using it (ftp://ftp.primaryinterface.com/pub/javacAPI). There is no license for the code I've written. The API itself has no dependencies on other software. And the provided implementation has no dependencies other than on eclipse (don't know if that is a problem for Apache projects...). The provided zip file contains source, compiled code, javadocs, and a couple of example programs: one that simulates the javac command line compiler, and another that demonstrates compiling source code in memory and dynamically loading the resulting classes. Regards, Chris Stefano Mazzocchi wrote: [EMAIL PROTECTED] wrote: Gee, now I've been lurking about the cocoon mailing lists for years, posting small and easily ignorable questions - and now this reply; it's probably the first time I see: "You are my man, really. I love this." on this mailing list... thanks Stefano - nice to know that I might be on the right path. Hey, you saved me from writing a java compiler, isn't that something? ;-) Actually I haven't patched pizza, just extended one of their classes ;-) Even better. I tried to compile pizza myself but ran into some troubles getting the bootstrap compiler for the pizza files up and running, and since extending their classes did the trick I didn't bother too much. As a side note: I kinda like the strongly typed hashtables of the pizza language (highly irrelevant for the classloading matter) The code is actually written for my employer, but he has on more occasions agreed to let solutions sieve back to the open source community - and this thing is really small Great. A small disclaimer: I haven't tested this beast thoroughly, but I know for sure that statements like "import java.util.logging.SocketHandler" and "import java.util.loggging.*" work equally well - which was one of my major concerns since all I have is a classloader (and not a jar-file) and hence I cannot list the contents of a package (I might be wrong on this). But it seems that the pizza compiler is doing *the right thing* (tm) and scanning all star-imports for classes not explicitly imported. good First of all a big thank you to the Pizza people for creating the compiler that makes my small addon possible - as written I've posted a message on the pizzacompiler discussion forum, asking whether they would like to add my stuff, http://sourceforge.net/forum/ forum.php?thread_id=766013&forum_id=129481, but no reply yet - apparently not everybody is as eager about classloding compilers as cocoon folkes. I will immediately send of an email to the developers asking if they could accept my stuff. In the mean time please copy my stuff if you need it. Find attached a zip-file containing both source and compiled version - dump the neupart-pizza.jar into WEB-INF, edit cocoon.xconf to use the com.neupart.cocoon.pizza.ClassLoadingPizza compiler instead of the normal Pizza compiler class - and off you go! Great. I'll try it ASAP. This version might not be the final say on the issue! ok thanks much - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Java compiler API [WAS Re: Compiling with Servlet spec 2.3 classloading]
Hi, Great stuff, Chris! I didn't realize Eclipse comes with its own compiler. Your API is a great tool to abstract out the inner details of a compiler. I'll check out both of them to see how they could be used in a useful way in some of the things I have in mind. I'm primarily interested in coming up with a way to define Scheme-like hygienic macros for Java, which would allow extending the Java language syntax in a clean way by developers: http://webweavertech.com/ovidiu/weblog/archives/000122.html Having a compiler API that can be used makes a huge difference. Regards, Ovidiu On Saturday, Dec 14, 2002, at 15:37 US/Pacific, Christopher Oliver wrote: I've also had to try to solve the embedded compiling problem (for other reasons) and I've also tried to use Pizza. Unfortunately, Pizza is very poor quality code and has severe limitations that made it unusable for me. Instead I've used the eclipse.org Java Development Tools compiler (which is excellent) to implement a simple embeddable compiler API. I've placed a copy of the source code on my ftp server if anyone is interested in using it (ftp://ftp.primaryinterface.com/pub/javacAPI). There is no license for the code I've written. The API itself has no dependencies on other software. And the provided implementation has no dependencies other than on eclipse (don't know if that is a problem for Apache projects...). The provided zip file contains source, compiled code, javadocs, and a couple of example programs: one that simulates the javac command line compiler, and another that demonstrates compiling source code in memory and dynamically loading the resulting classes. Regards, Chris Stefano Mazzocchi wrote: [EMAIL PROTECTED] wrote: Gee, now I've been lurking about the cocoon mailing lists for years, posting small and easily ignorable questions - and now this reply; it's probably the first time I see: "You are my man, really. I love this." on this mailing list... thanks Stefano - nice to know that I might be on the right path. Hey, you saved me from writing a java compiler, isn't that something? ;-) Actually I haven't patched pizza, just extended one of their classes ;-) Even better. I tried to compile pizza myself but ran into some troubles getting the bootstrap compiler for the pizza files up and running, and since extending their classes did the trick I didn't bother too much. As a side note: I kinda like the strongly typed hashtables of the pizza language (highly irrelevant for the classloading matter) The code is actually written for my employer, but he has on more occasions agreed to let solutions sieve back to the open source community - and this thing is really small Great. A small disclaimer: I haven't tested this beast thoroughly, but I know for sure that statements like "import java.util.logging.SocketHandler" and "import java.util.loggging.*" work equally well - which was one of my major concerns since all I have is a classloader (and not a jar-file) and hence I cannot list the contents of a package (I might be wrong on this). But it seems that the pizza compiler is doing *the right thing* (tm) and scanning all star-imports for classes not explicitly imported. good First of all a big thank you to the Pizza people for creating the compiler that makes my small addon possible - as written I've posted a message on the pizzacompiler discussion forum, asking whether they would like to add my stuff, http://sourceforge.net/forum/ forum.php?thread_id=766013&forum_id=129481, but no reply yet - apparently not everybody is as eager about classloding compilers as cocoon folkes. I will immediately send of an email to the developers asking if they could accept my stuff. In the mean time please copy my stuff if you need it. Find attached a zip-file containing both source and compiled version - dump the neupart-pizza.jar into WEB-INF, edit cocoon.xconf to use the com.neupart.cocoon.pizza.ClassLoadingPizza compiler instead of the normal Pizza compiler class - and off you go! Great. I'll try it ASAP. This version might not be the final say on the issue! ok thanks much - 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: Compiling with Servlet spec 2.3 classloading
Christopher Oliver wrote: OK. Done. I've placed the most permissive, non-copyleft license I could find on this code. Thank you very much; sorry for being a PITA, but small details sometimes can bring problems down the road. I appreciate it, thanks :-) -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Compiling with Servlet spec 2.3 classloading
OK. Done. I've placed the most permissive, non-copyleft license I could find on this code. Regards, Chris Nicola Ken Barozzi wrote: Christopher Oliver wrote: [...] There is no license for the code I've written. Please, add a license to it, possibly an Apache-derived license. If code is not licensed, we cannot use it, because we have no right to do so. When/if the time will come, you can always decide to donate it to Apache. Sorry for these legal points, and IANAL, but I'm having problems ATM to get a program that some want to donate to Apache that is not licensed and we have to track down all contributors to sign an agreement. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Compiling with Servlet spec 2.3 classloading
Christopher Oliver wrote: [...] There is no license for the code I've written. Please, add a license to it, possibly an Apache-derived license. If code is not licensed, we cannot use it, because we have no right to do so. When/if the time will come, you can always decide to donate it to Apache. Sorry for these legal points, and IANAL, but I'm having problems ATM to get a program that some want to donate to Apache that is not licensed and we have to track down all contributors to sign an agreement. Thank you. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Compiling with Servlet spec 2.3 classloading
I've also had to try to solve the embedded compiling problem (for other reasons) and I've also tried to use Pizza. Unfortunately, Pizza is very poor quality code and has severe limitations that made it unusable for me. Instead I've used the eclipse.org Java Development Tools compiler (which is excellent) to implement a simple embeddable compiler API. I've placed a copy of the source code on my ftp server if anyone is interested in using it (ftp://ftp.primaryinterface.com/pub/javacAPI). There is no license for the code I've written. The API itself has no dependencies on other software. And the provided implementation has no dependencies other than on eclipse (don't know if that is a problem for Apache projects...). The provided zip file contains source, compiled code, javadocs, and a couple of example programs: one that simulates the javac command line compiler, and another that demonstrates compiling source code in memory and dynamically loading the resulting classes. Regards, Chris Stefano Mazzocchi wrote: [EMAIL PROTECTED] wrote: Gee, now I've been lurking about the cocoon mailing lists for years, posting small and easily ignorable questions - and now this reply; it's probably the first time I see: "You are my man, really. I love this." on this mailing list... thanks Stefano - nice to know that I might be on the right path. Hey, you saved me from writing a java compiler, isn't that something? ;-) Actually I haven't patched pizza, just extended one of their classes ;-) Even better. I tried to compile pizza myself but ran into some troubles getting the bootstrap compiler for the pizza files up and running, and since extending their classes did the trick I didn't bother too much. As a side note: I kinda like the strongly typed hashtables of the pizza language (highly irrelevant for the classloading matter) The code is actually written for my employer, but he has on more occasions agreed to let solutions sieve back to the open source community - and this thing is really small Great. A small disclaimer: I haven't tested this beast thoroughly, but I know for sure that statements like "import java.util.logging.SocketHandler" and "import java.util.loggging.*" work equally well - which was one of my major concerns since all I have is a classloader (and not a jar-file) and hence I cannot list the contents of a package (I might be wrong on this). But it seems that the pizza compiler is doing *the right thing* (tm) and scanning all star-imports for classes not explicitly imported. good First of all a big thank you to the Pizza people for creating the compiler that makes my small addon possible - as written I've posted a message on the pizzacompiler discussion forum, asking whether they would like to add my stuff, http://sourceforge.net/forum/forum.php?thread_id=766013&forum_id=129481, but no reply yet - apparently not everybody is as eager about classloding compilers as cocoon folkes. I will immediately send of an email to the developers asking if they could accept my stuff. In the mean time please copy my stuff if you need it. Find attached a zip-file containing both source and compiled version - dump the neupart-pizza.jar into WEB-INF, edit cocoon.xconf to use the com.neupart.cocoon.pizza.ClassLoadingPizza compiler instead of the normal Pizza compiler class - and off you go! Great. I'll try it ASAP. This version might not be the final say on the issue! ok thanks much - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Compiling with Servlet spec 2.3 classloading
... and here comes a version that works on Windows as well ... Deep, deep inside pizza they introduce a platform dependency that I must rip out again; therefore this new version - and star imports are still not possible :-( Jakob Dalsgaard Udvikler e-mail: [EMAIL PROTECTED] Vesterbrogade 149 1620 København V Tlf.: 70 25 80 30 Fax.: 70 25 80 31 neupart-pizza-20021121.zip Description: Zip archive - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Compiling with Servlet spec 2.3 classloading
[EMAIL PROTECTED] wrote: Gee, now I've been lurking about the cocoon mailing lists for years, posting small and easily ignorable questions - and now this reply; it's probably the first time I see: "You are my man, really. I love this." on this mailing list... thanks Stefano - nice to know that I might be on the right path. Hey, you saved me from writing a java compiler, isn't that something? ;-) Actually I haven't patched pizza, just extended one of their classes ;-) Even better. I tried to compile pizza myself but ran into some troubles getting the bootstrap compiler for the pizza files up and running, and since extending their classes did the trick I didn't bother too much. As a side note: I kinda like the strongly typed hashtables of the pizza language (highly irrelevant for the classloading matter) The code is actually written for my employer, but he has on more occasions agreed to let solutions sieve back to the open source community - and this thing is really small Great. A small disclaimer: I haven't tested this beast thoroughly, but I know for sure that statements like "import java.util.logging.SocketHandler" and "import java.util.loggging.*" work equally well - which was one of my major concerns since all I have is a classloader (and not a jar-file) and hence I cannot list the contents of a package (I might be wrong on this). But it seems that the pizza compiler is doing *the right thing* (tm) and scanning all star-imports for classes not explicitly imported. good First of all a big thank you to the Pizza people for creating the compiler that makes my small addon possible - as written I've posted a message on the pizzacompiler discussion forum, asking whether they would like to add my stuff, http://sourceforge.net/forum/forum.php?thread_id=766013&forum_id=129481, but no reply yet - apparently not everybody is as eager about classloding compilers as cocoon folkes. I will immediately send of an email to the developers asking if they could accept my stuff. In the mean time please copy my stuff if you need it. Find attached a zip-file containing both source and compiled version - dump the neupart-pizza.jar into WEB-INF, edit cocoon.xconf to use the com.neupart.cocoon.pizza.ClassLoadingPizza compiler instead of the normal Pizza compiler class - and off you go! Great. I'll try it ASAP. This version might not be the final say on the issue! ok thanks much -- Stefano Mazzocchi <[EMAIL PROTECTED]> - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Compiling with Servlet spec 2.3 classloading
Nicola Ken Barozzi wrote:
Stefano Mazzocchi wrote:
[EMAIL PROTECTED] wrote:
To the developers
I've created a Pizza Compiler for Cocoon that uses the ClassLoader
retrieved from ClassUtils.getClassLoader () instead of a classpath
consisting of jar files and classes directories when compiling java
files. I've posted a message in the Pizzacompiler discussion forum
asking if the pizza developers want my code.
I'm posting this message to the cocoon-dev mailing list to follow up
on others earlier threads regarding compilers and classloading, for
example: http://w6.metronet.com/~wjm/tomcat/2001/Feb/msg00488.html
I'm deploying cocoon in a Jboss/Jetty environment; and I've turned
off Java 2 ClassLoading in favour of Servlet Spec 2.3 ClassLoading.
I might be wrong, but the general difference between them two is:
- in Java 2 classloading, the parent classloader is always asked
first, then a classloader tries to locate the class itself
- in Servlet Spec 2.3 the webapp classloader tries to locate the
class in WEB-INF/lib, WEB-INF/classes or, when deployed in an
enterprise application, in the interfaces to the ejb-layer (which
are not found in any files within the webapp).
The beauty (IMHO) of Servlet Spec 2.3 class loading is that you get
the Xalan/Xerces/whatever that you deploy with your application, and
_not_ the Xalan/Xerces/whatever is delivered by the JDK or deploy
environment - much less hazzle. With this classloading scheme I can
take an arbitrary JDK and expect to get the proper classes loaded. I
know there's the workaround with endorsed lib and such - but then I
have to keep my JDK as up to date as my app.
The problem with Servlet Spec 2.3 is that the compiler cannot get
the interfaces in a neat .jar file and hence cannot load the
classes. I've not been able to find any freely available java
compiler that uses a ClassLoader when compiling. Therefore I've made
a alternate version of the Pizzac java compiler class for cocoon
that uses an alternate ClassReader class for Pizza. This combination
seems to work.
If there's interest in my solution I'll post the files to the list.
YEEE!!!
YEAH! :-D
WOOHO ! :-P
You are my man, really. I love this.
Yep. This one of the main hacky-zones of the Cocoon code base. Solving
this will be a major step forward, and will be most useful for blocks also !
Please keep us posted !
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: Compiling with Servlet spec 2.3 classloading
Ups, a little warning. The implementation I've provided can only do star-imports on packages listed in the system/boot classpath since these imports seems to be handled by the normal Pizza ClassReader - doing star-imports from packages not in jar-files in the system/boot classpath is not supported since is not possible to scan packages through the java.lang.ClassLoader interface. But stay tuned - this problem _must_ be solved! and I belive it can Jakob Dalsgaard Udvikler e-mail: [EMAIL PROTECTED] Vesterbrogade 149 1620 København V Tlf.: 70 25 80 30 Fax.: 70 25 80 31 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Compiling with Servlet spec 2.3 classloading
Gee, now I've been lurking about the cocoon mailing lists for years,
posting small and easily ignorable questions - and now this reply; it's
probably the first time I see: "You are my man, really. I love this." on this mailing
list... thanks Stefano - nice to know that I might be on
the right path.
Actually I haven't patched pizza, just extended one of their classes ;-) I
tried to compile pizza myself but ran into some troubles getting the
bootstrap compiler for the pizza files up and running, and since extending
their classes did the trick I didn't bother too much. As a side note: I
kinda like the strongly typed hashtables of the pizza language (highly
irrelevant for the classloading matter)
The code is actually written for my employer, but he has on more occasions
agreed to let solutions sieve back to the open source community - and this
thing is really small
A small disclaimer: I haven't tested this beast thoroughly, but I know for
sure that statements like "import java.util.logging.SocketHandler" and
"import java.util.loggging.*" work equally well - which was one of my
major concerns since all I have is a classloader (and not a jar-file) and
hence I cannot list the contents of a package (I might be wrong on this).
But it seems that the pizza compiler is doing *the right thing* (tm) and
scanning all star-imports for classes not explicitly imported.
First of all a big thank you to the Pizza people for creating the compiler
that makes my small addon possible - as written I've posted a message on
the pizzacompiler discussion forum, asking whether they would like to add
my stuff,
http://sourceforge.net/forum/forum.php?thread_id=766013&forum_id=129481,
but no reply yet - apparently not everybody is as eager about classloding
compilers as cocoon folkes. I will immediately send of an email to the
developers asking if they could accept my stuff. In the mean time please
copy my stuff if you need it. Find attached a zip-file containing both
source and compiled version - dump the neupart-pizza.jar into WEB-INF,
edit cocoon.xconf to use the com.neupart.cocoon.pizza.ClassLoadingPizza
compiler instead of the normal Pizza compiler class - and off you go!
This version might not be the final say on the issue!
Jakob Dalsgaard
Udvikler
e-mail: [EMAIL PROTECTED]
Vesterbrogade 149
1620 København V
Tlf.: 70 25 80 30
Fax.: 70 25 80 31
Stefano Mazzocchi <[EMAIL PROTECTED]>
11/19/02 04:29 PM
Please respond to cocoon-dev
To: [EMAIL PROTECTED]
cc:
Subject:Re: Compiling with Servlet spec 2.3 classloading
[EMAIL PROTECTED] wrote:
> To the developers
>
> I've created a Pizza Compiler for Cocoon that uses the ClassLoader
> retrieved from ClassUtils.getClassLoader () instead of a classpath
> consisting of jar files and classes directories when compiling java
files.
> I've posted a message in the Pizzacompiler discussion forum asking if
the
> pizza developers want my code.
>
> I'm posting this message to the cocoon-dev mailing list to follow up on
> others earlier threads regarding compilers and classloading, for
example:
> http://w6.metronet.com/~wjm/tomcat/2001/Feb/msg00488.html
>
> I'm deploying cocoon in a Jboss/Jetty environment; and I've turned off
> Java 2 ClassLoading in favour of Servlet Spec 2.3 ClassLoading. I might
be
> wrong, but the general difference between them two is:
>
> - in Java 2 classloading, the parent classloader is always asked first,
> then a classloader tries to locate the class itself
> - in Servlet Spec 2.3 the webapp classloader tries to locate the class
in
> WEB-INF/lib, WEB-INF/classes or, when deployed in an enterprise
> application, in the interfaces to the ejb-layer (which are not found in
> any files within the webapp).
>
> The beauty (IMHO) of Servlet Spec 2.3 class loading is that you get the
> Xalan/Xerces/whatever that you deploy with your application, and _not_
the
> Xalan/Xerces/whatever is delivered by the JDK or deploy environment -
much
> less hazzle. With this classloading scheme I can take an arbitrary JDK
and
> expect to get the proper classes loaded. I know there's the workaround
> with endorsed lib and such - but then I have to keep my JDK as up to
date
> as my app.
>
> The problem with Servlet Spec 2.3 is that the compiler cannot get the
> interfaces in a neat .jar file and hence cannot load the classes. I've
not
> been able to find any freely available java compiler that uses a
> ClassLoader when compiling. Therefore I've made a alternate version of
the
> Pizzac java compiler class for cocoon that uses an alternate ClassReader
> class for Pizza. This combination seems to work.
>
> If there's interest in my solution I&#x
Re: Compiling with Servlet spec 2.3 classloading
Stefano Mazzocchi wrote: [EMAIL PROTECTED] wrote: To the developers I've created a Pizza Compiler for Cocoon that uses the ClassLoader retrieved from ClassUtils.getClassLoader () instead of a classpath consisting of jar files and classes directories when compiling java files. I've posted a message in the Pizzacompiler discussion forum asking if the pizza developers want my code. I'm posting this message to the cocoon-dev mailing list to follow up on others earlier threads regarding compilers and classloading, for example: http://w6.metronet.com/~wjm/tomcat/2001/Feb/msg00488.html I'm deploying cocoon in a Jboss/Jetty environment; and I've turned off Java 2 ClassLoading in favour of Servlet Spec 2.3 ClassLoading. I might be wrong, but the general difference between them two is: - in Java 2 classloading, the parent classloader is always asked first, then a classloader tries to locate the class itself - in Servlet Spec 2.3 the webapp classloader tries to locate the class in WEB-INF/lib, WEB-INF/classes or, when deployed in an enterprise application, in the interfaces to the ejb-layer (which are not found in any files within the webapp). The beauty (IMHO) of Servlet Spec 2.3 class loading is that you get the Xalan/Xerces/whatever that you deploy with your application, and _not_ the Xalan/Xerces/whatever is delivered by the JDK or deploy environment - much less hazzle. With this classloading scheme I can take an arbitrary JDK and expect to get the proper classes loaded. I know there's the workaround with endorsed lib and such - but then I have to keep my JDK as up to date as my app. The problem with Servlet Spec 2.3 is that the compiler cannot get the interfaces in a neat .jar file and hence cannot load the classes. I've not been able to find any freely available java compiler that uses a ClassLoader when compiling. Therefore I've made a alternate version of the Pizzac java compiler class for cocoon that uses an alternate ClassReader class for Pizza. This combination seems to work. If there's interest in my solution I'll post the files to the list. YEEE!!! YEAH! :-D You are my man, really. I love this. Stefano, you once said that probably you would have had to make your own compiler to get round this problem, so does this mean that you're not going to do it anymore? ;-) Let's throw away normal class-path based classloading as soon as possible. THIS problem has been the major portability issue for cocoon on different platforms (like early WebSphere or WebLogic, for example) for dynamically compiled stuff (like sitemap in 2.0.x and XSP in all versions). Now, as much as I like this, I don't want Cocoon to maintain a forked version of Pizza. Have you given back your patches to the pizza folks or this is just your own personal release for it? In any case, we *really* need to incorporate this so we must find a proper way. +1000 -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Compiling with Servlet spec 2.3 classloading
[EMAIL PROTECTED] wrote: To the developers I've created a Pizza Compiler for Cocoon that uses the ClassLoader retrieved from ClassUtils.getClassLoader () instead of a classpath consisting of jar files and classes directories when compiling java files. I've posted a message in the Pizzacompiler discussion forum asking if the pizza developers want my code. I'm posting this message to the cocoon-dev mailing list to follow up on others earlier threads regarding compilers and classloading, for example: http://w6.metronet.com/~wjm/tomcat/2001/Feb/msg00488.html I'm deploying cocoon in a Jboss/Jetty environment; and I've turned off Java 2 ClassLoading in favour of Servlet Spec 2.3 ClassLoading. I might be wrong, but the general difference between them two is: - in Java 2 classloading, the parent classloader is always asked first, then a classloader tries to locate the class itself - in Servlet Spec 2.3 the webapp classloader tries to locate the class in WEB-INF/lib, WEB-INF/classes or, when deployed in an enterprise application, in the interfaces to the ejb-layer (which are not found in any files within the webapp). The beauty (IMHO) of Servlet Spec 2.3 class loading is that you get the Xalan/Xerces/whatever that you deploy with your application, and _not_ the Xalan/Xerces/whatever is delivered by the JDK or deploy environment - much less hazzle. With this classloading scheme I can take an arbitrary JDK and expect to get the proper classes loaded. I know there's the workaround with endorsed lib and such - but then I have to keep my JDK as up to date as my app. The problem with Servlet Spec 2.3 is that the compiler cannot get the interfaces in a neat .jar file and hence cannot load the classes. I've not been able to find any freely available java compiler that uses a ClassLoader when compiling. Therefore I've made a alternate version of the Pizzac java compiler class for cocoon that uses an alternate ClassReader class for Pizza. This combination seems to work. If there's interest in my solution I'll post the files to the list. YEEE!!! You are my man, really. I love this. Let's throw away normal class-path based classloading as soon as possible. THIS problem has been the major portability issue for cocoon on different platforms (like early WebSphere or WebLogic, for example) for dynamically compiled stuff (like sitemap in 2.0.x and XSP in all versions). Now, as much as I like this, I don't want Cocoon to maintain a forked version of Pizza. Have you given back your patches to the pizza folks or this is just your own personal release for it? In any case, we *really* need to incorporate this so we must find a proper way. -- Stefano Mazzocchi <[EMAIL PROTECTED]> - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
