On Tue, 07 Dec 2004 20:44:01 +0000 Upayavira <[EMAIL PROTECTED]> wrote:
> My understanding of this bug is that it is simply a matter of how it > handles its configuration - i.e. it won't let you run it without any > targets configured, but you don't want to configure targets when > precompiling XSPs. > > I did make one stab at fixing it, but failed. In some months I'll get > another chance, but can't look at it immediately. > > Regards, Upayavira > Hi Upayavira, the old precompiling uses the XSP - ProgramGenerator and all needed stuff from XSP and the old Cocoon-class used this components in order to compile the xsp, but this is moved. Here are the diffs: Cocoon: http://svn.apache.org/viewcvs.cgi/cocoon/trunk/src/java/org/apache/cocoon/Cocoon.java?rev=27653&r1=27559&r2=27653&diff_format=h CocoonWrapper: http://svn.apache.org/viewcvs.cgi/cocoon/trunk/src/java/org/apache/cocoon/bean/CocoonWrapper.java?rev=27653&r1=27559&r2=27653&diff_format=h CocoonBean: http://svn.apache.org/viewcvs.cgi/cocoon/trunk/src/java/org/apache/cocoon/bean/CocoonBean.java?rev=27653&r1=27559&r2=27653&diff_format=h It looks for me that the XSP-prcompiling was done in the Cocoon-class with the XSP-components. A new implementation needs the XSP-components and should be inside the XSP-block? My problem was to extend the CocoonWrapper, where I have no access to the private Cocoon, which is needed. So if I change the private to protected it could work or copy and paste all together to new XSPWrapper (this will not touch the CocoonWrapper). But anyway it looks like the precompiling can only be done with a new CLIWrapper inside the XSP-block. Best Regards, Simon --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
