Discussions

Although I'm an experienced Java and Web developer, but I'm trying a tactic that I've seldom seen mentioned in JSP newsgroups.

Basically, I would like a JB to emit pure XML into a JSP which wraps it in the proper code to cause IEv5.5 to perform the XML/XSL transformation (instead of the server). I've been able to get this logic to work in other web crafting environments (Tango and ASP), but have not been able to get it to work from JSPs.

I've got a local JB (ClassInfoBean2.java) with a method that emits a chunk of XML. The following code is in the associated JSP.

[NOTE: The <xsl:output...> lines were the recommendation I found in a note from 1/8/01 in the Orion newsgroup who's subject is "XSL on Orion returns content
type text/xml instead of text/html". Whether these lines are present or not has made no difference in solving my problem.]

The associated XSL file is too long to try to post in this note. The content probably isn't a part of the problem since the browser doesn't even try to do the transformation. When I copy the following XML into an XML file, the browser loads the file and performs the transformation perfectly. However the browser refuses to perform the transformation when the same XML is emitted from a JSP file.

Now when this is sent to IEv5 (with the latest XSLT updates installed), the XSL file should be loaded and used to transform the XML data into the appropriate HTML--but this is not happening and I can't tell what's missing.

Specifically, I can't tell if the browser isn't able to find the XSL file (thus the subject of this note), or if the browser doesn't know that this is really an XML page that warrants XML/XSL processing, or if the browser thinks there's a valid reason (ie., security) to avoid doing the transformation. No errors are produced--the browser simply refuses to do the transformation.

In this setting, I have several questions.

1. Given the <?xml-stylesheet...> statement shown above, where should I put the XSL file? Perhaps with the JSP files? (This worked for the CSS files in this project.) Perhaps a different path in the href value would be appropriate? Any suggestions?

2. Do I need to explicitly tell Orion or Tomcat to handle XSL and/or CSS file types? There wouldn't be much for Orion to do except emit their contents 'as is' and let the downstream device do the processing. If I don't do this then it would seem that these files would be (apparently) served from a different server (http://whatever:8080/something vs http://whatever/something). I mention this because it occurred to me that the browser's sandbox might be interfering with loading the XSL file from what appears to be a different domain that where the original page is served from. My gut feeling is that this shouldn't be necessary, but I don't want to leave any stone unturned in this search.

3. There's a possibility that the browser is confused since the URL ends in JSP but I'm returning XML content. That is, the browser may not realize that it is appropriate for it to do the XSL transformation. The first two lines should remove any of the browser's doubt about the content type of the page, but since nothing I've done has made a difference I don't want to rule this out as a possible cause of confusion.

My plan is to produce a transform object which detects the browser's capabilities and pushes the transformation as close to the browser as possible. In the case of IE5, then we would emit XML with an appropriate reference to a transformation file. In browsers that don't handle XML but have a JRE, we would emit a page with a reference to a compiled transformation (produced by Sun's XSLT compiler). If the browser has no XML nor JRE support, then the Server will perform the transformation and emit HTML. The ultimate goal is to maximize the utilization of the browser's capabilities.

Anyone had any luck getting IEv5 to participate in this tactic from a JSP page? Any suggestions would be appreciated.

I believe that without the contentType being set as a "Page Directive" IE has no way of knowing what is coming at it is XML. It probably assumes whatever is the default type. If I had the time, I would test this theory out.

Great post! I have to concur with Raj here. I didn't read through the entire posting, because my first gut instinct was that the content type was never correctly set. I think you have done everything else correctly (but I've never tried to send pure XML to the browser before).

Also, if you were to do this in a servlet instead, one of the first methods you call is response.setContentType(...) which is the equivalent of doing the <%@ page contentType= %> that Raj mentions. If you do not do this, the default content type is test/html.

However, the netscape requires your response to be explicitly to be mentioned. Yes , it is a good idea to mention your response always.

If you have mentioned your response to be res.setContenttype ( as xml) , then it will send and xml output as well please mention the version as 1.0 as required.
otherwise I am not able to see anything immediate. However, please send ur code to my email address at
bp8475 at sbc dot com.Let me try to run it using the Xalan parser that I have.

Prasath .

I can also send some references where you can see details for all these

Hi
I am Deepak Bhatt, working as a java developer in Frankfurt(Germany) with 2.8 year experience in java,servlet,JSP,Ejb and worked on the application server like Weblogic version 5.1 if you have a suitable vaccancy in your company do let me know
My mailId= bhattdeepak75 at hotmail dot com

I also got an email from Anders Dahlberg suggesting an alternative way of doing the contentType as shown below:

<% response.setContentType("text/xml"); %>

Both of these suggestions solved this problem.

At this point, I've gotten all of the basic mechanisms working and am well on my way to meeting the goals I mentioned in my original note. When I've gotten it all working, I'll post more info on how well it works (and more importantly, how well it seems to scale).

I am very interested in knowing your findings. Up until recently, only IE5 had built in capabilities to deal with XML. Is your user base fixed on using IE5?. In many of the projects that I have been involved in we had to support 4th generation browsers (NS4+, IE4+). There were also other browsers like AOL's that also had to be supported.

The approach of XML/XSL transformation on the client side works only if you know that the client browser is capable of it. Aside from that, the onus of transforming the data is on the client processor. What volume of data does your XML encapsulate. What if the situation warrants that the XML (after it has been transformed) has to be presented in several pages?.

Well, my user base is not fixed on using IE5. Instead they are fixed on using everything from IE through WebTV as well as handheld devices (eg., PDAs and Cell Phones) and nearly any networked appliances.

My goal is separate the various layers so different team members can specialize in a reasonable number of different technologies. The guys who know how to get the right data out of the repositories are not colliding with the business logic guys nearly as often as they do today; the guys who know how to work with the downstream device's presentation capabilities aren't colliding with the business logic or database folks either. Right now, I've got a team that are forced to be 'jacks of all trades' instead of being our company gurus in particular disciplines.

So the backend focuses only on accumulating the data through JB/JDBC or EJBs which is then fed to the JSPs. The JSPs only worry about filtering/reducing the data as needed for the detected downstream device. XSLTs are used to control all formatting and layout issues while CSS is used for the purely cosmetic stuff. Using BrowserHawk/J by CyScape, the JSP also determines the capabilities of the downstream device--which determines which stylesheets to utilize.

If that device is IE5 (with the latest XML update), then we only have to ship an XML file with a reference to an XSL transformation. If that device can do the transformation in their JRE, then we'll ship them an appropriate XSLTc precompiled transformation along with the raw XML data so they can do the transformation themselves. If JRE/XSLT capabilities are totally lacking in the client, then the server will do the transformation and emit the HTML directly to the browser--but this is a last resort.

As far as the volume of XML data that gets moved over the wire, one of the tasks of the JSPs (along with the BrowserHawk/J objects) is to reduce the data to the minimum that the stylesheet will require.

The overall goal is to utilize the downstream client as much as possible to lighten the load on the servers.

You might be surprised to find that an HTML page that contains a huge table with lots of rows and columns takes about 20 times longer to download and render as HTML than sending the equivalent XML data with an XSL stylesheet and letting the browser do the rendering. The performance I'm measuring is the time beginning with pressing 'Refresh' until the page is completely downloaded and rendered.

I was stunned the first time I saw the performance differences. In retrospect, it makes sense. There's is usually less data to transmit over the wire (comparing the number of bytes of HTML data vs the XML/XSL data that can generate the same HTML screen). As mentioned above, HTML tables are terribly expensive to render in the browser (especially if they are not fixed-size tables) whereas an XML/XSL transformation is an order of magnitude faster to render in the same browser.

Anyway to return to your original point, my motivation is that my customers typically are trying to screw a wide variety of different clients onto their existing traditional Client/Server applications. This includes clients written in C/C++ and VB/Delphi as well as using any HTML capable device as a client.

So my basic requirement is to provide an infrastructure to simplify and optimize our development efforts as we screw New Age Clients onto these aging, and often antique, Client/Server apps.

> You might be surprised to find that an HTML page that
> contains a huge table with lots of rows and columns takes
> about 20 times longer to download and render as HTML than
> sending the equivalent XML data with an XSL stylesheet
> and letting the browser do the rendering. The performance
> I'm measuring is the time beginning with pressing'Refresh'
> until the page is completely downloaded and rendered.

That was something that I did'nt know and frankly would'nt have suspected. Useful bit of information to know.

Here's a bit more info on a complication associated with this tactic. In particular, with each page refresh, I was getting lots of Socket Write Errors. There are lots of reasons for these errors--some of them are self-inflicted and others are simply unavoidable.

It is normal for a browser to abruptly close an existing connection to a server if the user reloads the page, or if the user presses the Stop button during a download. This will usually case a socket write error resulting in a lengthy stacktrace being dumped to the app server's log file.

But I was getting this error as many as four times per refresh in my original architecture and I had what appeared to be a massive memory leak in my AppServer. I also found that this same problem existed regardless of which AppServer I tried (which included Tomcat, JRun and Orion).

Last weekend, I found that the source of my problem was purely IE5 and XML. I cobbled a way to test this with Netscape and this problem does not happen at all.

As mentioned in earlier posts, I'm basically using JSPs to generate pure XML pages with references to XSL stylesheets so that IE5 can do the transformations (instead of using server resources). In the following description, I don't mean to suggest that I've debugged into IE5 and understand how the IE5 engine actually works--rather I'm describing what seems to be the behavior.

Here's the scenario. You're looking at a web page with a link to a JSP. When you click this link, the browser requests the JSP page. This JSP emits a page directive to change the contentType to "text/xml". It seems that as soon as IE5 gets this contentType switch, it abruptly drops the existing connection to the server and immediately requests the same page again.

Well, this can cause problems on the server. For example, if the JSP page takes a non-trivial amount of time to render itself, then the socket write error will almost always occur since the 'peer' (IE5 in the case) always abruptly terminates the first connection to start the second. If the first JSP page request had time to open a database connection (before the second page request yanked the rug), then the socket write error may also interrupt the JSP's ability to execute enough logic to get to close the database connection at the bottom of the page. This tends to leave database connections hanging until they timeout.

In my case, I was using a frameset which contained four JSPs--each of which emitted XML. In this case, each time I pressed F5, I saw four complete sets of "Socket Write Error" tracedumps along with stranding four different database connections. Imagine this problem in a scenario where hundreds or even thousands of customers were requesting updates to this frameset. There are two painpoints. First is the penalty of forcing the server to deal with needless exception handling four times per reload action (a performance penalty associated with dumping the stacktrace to the log file). Second are the resources held in limbo by stranded database connections (which looks like a big memory leak).

My workaround is to avoid sending a pure XML page to IE5. Instead I send the XML data in an XML data island and use JavaScript to do the transformation. [Sample code follows] IE5 is still doing the transformation but since we're sending a real HTML file with embedded XML, instead of a real XML file, we don't have IE5 requesting every page twice.

I would prefer to be sending pure XML/XSL to the browsers that can handle it. But even when/if this problem is fixed by MS, we still have to accommodate the millions of IE5 installations that don't have the patch. So this workaround is likely to stay online for a long time in my apps.

I guess you could say that instead of fixing the problem, I'm avoiding the situation that leads to the problem in the first place.

Another variation is to have the JS actually replace the entire BODY section of the page. This would let the XSL file have complete control over the attributes of the Body tag. In my case, this wasn't necessary.

I have tried using the sample files (test.xsl and test.jsp) but I can't get IE to perform the transform. After I add the line to set the content type to text/xml, IE recognizes that it is an XML document (if you view File | Properties), but it still renders it as an HTML file (the long string with all of the data appended).

Are you sure that your IE5 installation has the updated XML/XSL objects? Fully functional XSL transformations require that most IE5 installations go to the MS website to download the latest updates to the MSXML Parsers (I believe the last release was last fall, around September, and is called version 3.0).

If you don't have these updates, then you'll have the problem you described above.

I would expect the browser to want that at a minimum. But as one poster described you also want to deliver the right content type also.

I don't quite understand why you'd want to create a browser dependency by doing things this way when you can control everything if you perform the transformation on the server instead. I think the benefits far out weight any gains you'd get by doing this on the browser side.

You're exactly right about the browser-dependency issue. However, for an intranet application it is much easier to specify the 'supported browser' and in this case it can make sense to take full advantage of the client's capabilities.

On another front, I'm mainly doing things this way to be ready to take advantage of compiled transformations (eg., XSLTc from Sun). This way the transformation can safely be done at the client, as long as the client has a JDK at v1.1.4 or later.

My overall goal is to intelligiently push as much processing as makes sense out of the over-worked server and onto the under-utilized client.

With the work I'm doing at the moment, we adopt the exact technique described in this thread of sending XML directly to clients with a reference to an XSLT stylesheet (stored server-side incidentally) attached. We add the XSLT reference to the XML server-side via the DOM createProcessingInstruction function, which is slightly different to the approach described elsewhere in this thread.

The reason we adopt this approach is that our clients are PDAs connected to our web servers via GSM mobile phones, therefore connection speeds are dreadful. We are finding that an XML document is about a quarter or a fifth of the size of the resulting XSLT generated HTML file.

> Hi Folks,
>
> Although I'm an experienced Java and Web developer, but I'm trying a tactic that I've seldom seen mentioned in JSP newsgroups.
>
> Basically, I would like a JB to emit pure XML into a JSP which wraps it in the proper code to cause IEv5.5 to perform the XML/XSL transformation (instead of the server). I've been able to get this logic to work in other web crafting environments (Tango and ASP), but have not been able to get it to work from JSPs.
>
> I've got a local JB (ClassInfoBean2.java) with a method that emits a chunk of XML. The following code is in the associated JSP.
>
> [NOTE: The <xsl:output...> lines were the recommendation I found in a note from 1/8/01 in the Orion newsgroup who's subject is "XSL on Orion returns content
> type text/xml instead of text/html". Whether these lines are present or not has made no difference in solving my problem.]
>
> This JSP code is about as simple as it gets.
>
> <?xml version="1.0"?>
> <?xml-stylesheet type="text/xsl"
> href="ClassInfo2.xsl"?>
>
> <xsl:output method = "html"
> indent = "yes"
> doctype-system = "http://www.w3.org/DTD/HTML4-strict-dtd"
> doctype-public = "-//W3C//DTD HTML 4.0//EN"
> media-type= "text/html" />
>
> <jsp:useBean id="ClassInfoBeanId"
> scope="session"
> class="school.ClassInfoBean2" />
> <jsp:setProperty
> name="ClassInfoBeanId" property="*" />
>
> <root>
> <jsp:getProperty
> name="ClassInfoBeanId"
> property="xmlData" />
> </root>
>
> The associated XSL file is too long to try to post in this note. The content probably isn't a part of the problem since the browser doesn't even try to do the transformation. When I copy the following XML into an XML file, the browser loads the file and performs the transformation perfectly. However the browser refuses to perform the transformation when the same XML is emitted from a JSP file.
>
> Here's the XML output that the JSP emits:
>
> <?xml version="1.0"?>
> <?xml-stylesheet type="text/xsl"
> href="ClassInfo2.xsl"?>
> <xsl:output method = "html"
> indent = "yes"
> doctype-system = "http://www.w3.org/DTD/HTML4-strict-dtd"
> doctype-public = "-//W3C//DTD HTML 4.0//EN"
> media-type= "text/html" />
> <root>
> <title>Class Info</title>
> <stylesheet>resources.css</stylesheet>
> <studentinfo>
> <id>234567890</id>
> </studentinfo>
> <class>
> <id>23</id>
> <name>ThisName</name>
> <descr>Relatively longggg Description</descr>
> <section>ThisSection</section>
> <dept>ThisDept</dept>
> <maxsize>18</maxsize>
> <credits>3</credits>
> <startdate>1-18-2001</startdate>
> <starttime>13:00</starttime>
> <finishtime>15:30</finishtime>
> <building>thisBuilding</building>
> <room>thisRoom</room>
> </class>
> </root>
>
> Now when this is sent to IEv5 (with the latest XSLT updates installed), the XSL file should be loaded and used to transform the XML data into the appropriate HTML--but this is not happening and I can't tell what's missing.
>
> Specifically, I can't tell if the browser isn't able to find the XSL file (thus the subject of this note), or if the browser doesn't know that this is really an XML page that warrants XML/XSL processing, or if the browser thinks there's a valid reason (ie., security) to avoid doing the transformation. No errors are produced--the browser simply refuses to do the transformation.
>
> In this setting, I have several questions.
>
> 1. Given the <?xml-stylesheet...> statement shown above, where should I put the XSL file? Perhaps with the JSP files? (This worked for the CSS files in this project.) Perhaps a different path in the href value would be appropriate? Any suggestions?
>
> 2. Do I need to explicitly tell Orion or Tomcat to handle XSL and/or CSS file types? There wouldn't be much for Orion to do except emit their contents 'as is' and let the downstream device do the processing. If I don't do this then it would seem that these files would be (apparently) served from a different server (http://whatever:8080/something vs http://whatever/something). I mention this because it occurred to me that the browser's sandbox might be interfering with loading the XSL file from what appears to be a different domain that where the original page is served from. My gut feeling is that this shouldn't be necessary, but I don't want to leave any stone unturned in this search.
>
> 3. There's a possibility that the browser is confused since the URL ends in JSP but I'm returning XML content. That is, the browser may not realize that it is appropriate for it to do the XSL transformation. The first two lines should remove any of the browser's doubt about the content type of the page, but since nothing I've done has made a difference I don't want to rule this out as a possible cause of confusion.
>
> My plan is to produce a transform object which detects the browser's capabilities and pushes the transformation as close to the browser as possible. In the case of IE5, then we would emit XML with an appropriate reference to a transformation file. In browsers that don't handle XML but have a JRE, we would emit a page with a reference to a compiled transformation (produced by Sun's XSLT compiler). If the browser has no XML nor JRE support, then the Server will perform the transformation and emit HTML. The ultimate goal is to maximize the utilization of the browser's capabilities.
>
> Anyone had any luck getting IEv5 to participate in this tactic from a JSP page? Any suggestions would be appreciated.
>
> Cheers,
> Jeff Chapman
>
> Jeff dot Chapman at pervasive dot com
> Pervasive Software

TechTarget provides technology professionals with the information they need to perform their jobs - from developing strategy, to making cost-effective purchase decisions and managing their organizations technology projects - with its network of technology-specific websites, events and online magazines.