Re: xsl by extension
Quoting [EMAIL PROTECTED]: [snip] > So I'll be as -1 on adding this feature > ( or CGI support, for this matter :-) Damn! There goes my very next proposal =) - Christopher /** * Pleurez, pleurez, mes yeux, et fondez vous en eau! * La moitié de ma vie a mis l'autre au tombeau. *---Corneille */
Re: xsl by extension
On Fri, 7 Sep 2001, Pier Fumagalli wrote: > Of course none of this is portable across servlet containers, but we seem to > easily forget about that :) Being Tomcat the Reference Implementation, as an > ASF member, and Servlet JSR member, I'll never stop stressing out that IMNSO > relying on container-specific features IS to any extent WRONG unless this > can not in ANY WAY done otherwise. Implementing container-specific features ( like support for XSP ) without using container specific APIs is WRONG. Is like saying people shouldn't write Apache modules, but use only CGIs. I do agree that XSP is not standardized in any way - it's just a (nice) feature provided by resin. So I'll be as -1 on adding this feature ( or CGI support, for this matter :-) to tomcat3.3, the reference implementation. However people embedding tomcat may add whatever modules they need, and one of the goals of 3.3 was to make sure modules have the necesary power to do that in an efficient way. Costin
Re: xsl by extension
"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > Another ( and better ) solution - extend JspInterceptor ( well, the code > needs some cleanup - again I would recomend you do that in j34 workspace > ). > > Then you can add the dependencies and avoid any overhead - your XSP pages > will run as fast as a servlet, without any extra dispatching or > intermediary servlet. > > BTW, I'm happy I'm not alone on xsl and jasper :-) > > Let me know if I can help. Of course none of this is portable across servlet containers, but we seem to easily forget about that :) Being Tomcat the Reference Implementation, as an ASF member, and Servlet JSR member, I'll never stop stressing out that IMNSO relying on container-specific features IS to any extent WRONG unless this can not in ANY WAY done otherwise. One alternative I might be suggesting is Cocoon, which is fully portable across platforms, and deals with XML data more or less in the way that Javi needs to, but also that somehow is tricky, as you might get tied to the Cocoon architecture. Remember, never get down to compromises with your container unless you're forced to, and absolutely ready to be tied to that particular container for a very long time (I could understand sticking to Cocoon, since it runs in any servlet container, I wouldn't be so sure for certain Servlet API extensions, such as interceptors in TC3.x, or Valves -for what that matters- in TC4.x)... That's just my 0.02$, but wearing the hats I'm wearing, I believe I'm fairly on the fair side here... Pier
Re: xsl by extension
Another ( and better ) solution - extend JspInterceptor ( well, the code needs some cleanup - again I would recomend you do that in j34 workspace ). Then you can add the dependencies and avoid any overhead - your XSP pages will run as fast as a servlet, without any extra dispatching or intermediary servlet. BTW, I'm happy I'm not alone on xsl and jasper :-) Let me know if I can help. Costin
Re: xsl by extension
> > Thanks, craig, but i'm working with version 3.3. ¿isn't any > > alternative avalaible? > > Nope ... if you map your extension to your servlet, you cannot also map it > to the JSP servlet. Of course there are alternative :-) The easiest - have your xsp generate 'plain' jsp files, and redirect. Jasper doesn't support 'streams' anyway ( i.e. it can't process a stream, only a file or resource ), so you'll need a file with the current jasper ( or some very sophisticated tricks ). I doubt filters could help in any way ( at least with the current jasper ). Changing jasper to better work with this model is one of my goals in jasper34, it was a long discussion about using XSLT on jasper - unfortunately most people around didn't liked it. What I'm going to do is make sure j34 is modular enough and has the right hooks to allow someone to hook it with xslt ( or anything else for that matter !!!). I'm working ( very slow speed - as finishing 3.3 is the top priority ) on changing jasper to use SAX events, have a clean API, etc. You are more then welcomed to help - as this would be the right solution for your problem ( IMHO ). But generating the files is a decent solution as well. Costin
Re: xsl by extension
On Thu, 6 Sep 2001, javi . wrote: > Date: Thu, 06 Sep 2001 21:45:46 + > From: javi . <[EMAIL PROTECTED]> > Reply-To: [EMAIL PROTECTED] > To: [EMAIL PROTECTED] > Subject: Re: xsl by extension > > Thanks, craig, but i'm working with version 3.3. ¿isn't any > alternative avalaible? Nope ... if you map your extension to your servlet, you cannot also map it to the JSP servlet. > it seems it should be a quite common > problem... > That's why filters were added in servlet 2.3 :-). > jv > Craig > > >From: "Craig R. McClanahan" <[EMAIL PROTECTED]> > >Reply-To: [EMAIL PROTECTED] > >To: <[EMAIL PROTECTED]> > >Subject: Re: xsl by extension > >Date: Thu, 6 Sep 2001 14:37:43 -0700 (PDT) > > > >In a servlet 2.3 environment (i.e. Tomcat 4) you can do this sort of thing > >with a Filter. You would map *.xtp to the JSP servlet, and then apply > >your filter as well to the response. > > > >Craig > > > > > > > > i'm trying to add to tomcat a nice feature of resin: > > > automatically apply a xsl transformation over all files > > > with .xtp extension (xml templates). > > > > > > i've already done it, simply associating that extension > > > to my servlet. the servlet read the xsl path > > > from the .xtp itself. > > > > > > the problem is that i want to allow the jsp code in the > > > xtp file to be executed, so i must retrieve it via http and not from > > > the os file system... but when i do it, of course, my > > > xtp servlet catch de call and began a recursive loop! > > > > > > _ > Descargue GRATUITAMENTE MSN Explorer en http://explorer.msn.es/intl.asp > >
Re: xsl by extension
Ummm... perhaps invoke Jasper from your servlet?
Class clazz = Class.forName("org.apache.jasper.servlet.JspServlet");
HttpServlet jsp = (HttpServlet) clazz.newInstance();
jsp.init(context);
jsp.service(request, response);
That code is from Cocoon 2's JspGenerator, which uses Jasper to create
XML with JSP, which is then transformed and rendered in the Cocoon
pipeline.
--Jeff
On Thu, Sep 06, 2001 at 09:15:29PM +, javi . wrote:
> hello everybody!!
>
> i'm new here, and so excuse me if this thread has been
> started (and closed) before. and xcuse me for my spelling ;)
> my native language is java.
>
> i'm trying to add to tomcat a nice feature of resin:
> automatically apply a xsl transformation over all files
> with .xtp extension (xml templates).
>
> i've already done it, simply associating that extension
> to my servlet. the servlet read the xsl path
> from the .xtp itself.
>
> the problem is that i want to allow the jsp code in the
> xtp file to be executed, so i must retrieve it via http and not from
> the os file system... but when i do it, of course, my
> xtp servlet catch de call and began a recursive loop!
>
> is there any way to avoid that? i've look at the code
> by about ten hours and i don't see how to manage this
> problem...
>
> thank you very much in advance.
>
> Javi Moreno (jv)
>
>
>
> ps: i promise to post the servlet ;)
>
> pps: yes, i will try {to take another English course...}
Re: xsl by extension
Thanks, craig, but i'm working with version 3.3. ¿isn't any alternative avalaible? it seems it should be a quite common problem... jv >From: "Craig R. McClanahan" <[EMAIL PROTECTED]> >Reply-To: [EMAIL PROTECTED] >To: <[EMAIL PROTECTED]> >Subject: Re: xsl by extension >Date: Thu, 6 Sep 2001 14:37:43 -0700 (PDT) > >In a servlet 2.3 environment (i.e. Tomcat 4) you can do this sort of thing >with a Filter. You would map *.xtp to the JSP servlet, and then apply >your filter as well to the response. > >Craig > > > > > i'm trying to add to tomcat a nice feature of resin: > > automatically apply a xsl transformation over all files > > with .xtp extension (xml templates). > > > > i've already done it, simply associating that extension > > to my servlet. the servlet read the xsl path > > from the .xtp itself. > > > > the problem is that i want to allow the jsp code in the > > xtp file to be executed, so i must retrieve it via http and not from > > the os file system... but when i do it, of course, my > > xtp servlet catch de call and began a recursive loop! > > _ Descargue GRATUITAMENTE MSN Explorer en http://explorer.msn.es/intl.asp
Re: xsl by extension
In a servlet 2.3 environment (i.e. Tomcat 4) you can do this sort of thing
with a Filter. You would map *.xtp to the JSP servlet, and then apply
your filter as well to the response.
Craig
On Thu, 6 Sep 2001, javi . wrote:
> Date: Thu, 06 Sep 2001 21:15:29 +
> From: javi . <[EMAIL PROTECTED]>
> Reply-To: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Subject: xsl by extension
>
> hello everybody!!
>
> i'm new here, and so excuse me if this thread has been
> started (and closed) before. and xcuse me for my spelling ;)
> my native language is java.
>
> i'm trying to add to tomcat a nice feature of resin:
> automatically apply a xsl transformation over all files
> with .xtp extension (xml templates).
>
> i've already done it, simply associating that extension
> to my servlet. the servlet read the xsl path
> from the .xtp itself.
>
> the problem is that i want to allow the jsp code in the
> xtp file to be executed, so i must retrieve it via http and not from
> the os file system... but when i do it, of course, my
> xtp servlet catch de call and began a recursive loop!
>
> is there any way to avoid that? i've look at the code
> by about ten hours and i don't see how to manage this
> problem...
>
> thank you very much in advance.
>
> Javi Moreno (jv)
>
>
>
> ps: i promise to post the servlet ;)
>
> pps: yes, i will try {to take another English course...}
>
>
> _
> Descargue GRATUITAMENTE MSN Explorer en http://explorer.msn.es/intl.asp
>
>
