RE: java.util.ConcurrentModificationException
Title: RE: java.util.ConcurrentModificationException A ConcurrentModificationException is thrown by a non-synchronized Collection when more than one thread tries to modify the Collection. Try synchronizing the Collection or simply calling the session.invalidate() as suggested in previous responses. Ted Rice -Original Message- From: Arun Jayaprakash [mailto:[EMAIL PROTECTED]] Sent: 21 May 2001 08:56 To: Orion-Interest Subject: java.util.ConcurrentModificationException Hello everybody, I recently switched over from Apache Tomcat v3.2.1 to Orion v1.4.5. I deployed an application (that I had developed with Tomcat) using Orion and did the necessary configuring. The application works fine until the point when I logout. Tomcat never gave any trouble, but Orion keeps throwing a java.util.ConcurrentModificationException. This exception occurs when I remove all the attributes in my session object. Can anybody tell me why this happens and how to remove it? Thanks and regards, Arun Jayaprakash. __ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/
RE: Caching XLS style sheets (MVC Architecture)
Title: RE: Caching XLS style sheets (MVC Architecture) I asked a question on an MVC application architecture using XLS, and got advice to cache XLS / XSLT style sheets, and pre compile them. Can someone give me some more background on this. How? What if the content is dynamic? (2 million items and 100,000 of styles + with any combination) Thanks in advance, Vic In terms of the MVC architecture, here are the appropriate parts: The Model - The component responsible for holding any precompiled stylesheets, caching them there, and retrieving them with the appropriate keys(e.g. request path + browser agent type). Maybe some other elementary operations such as creating an XML Parser Pool to be used in a high throughput scenario such as you suggest. The Control - A JSP Tag / Class /Servlet responsible for interpretting the Input (XML with embedded PIs) and applying the XSL Transformation. The model is then queried for any pre-cached instances or resources used in the transforms. The Display - Output of JSP Page or Servlet presented in a client specific manner (e.g. HTML, WML, DHTML, etc). In the case of the JSP Tag i would suggest a BodyTag implementation that interprets it's contents as XML and hands them to the control. The Servlet scenario could take arguments such as the XML Source and the XSL Stylesheet to apply and hand them to the control. In terms of dynamic content, it is not a problem. We have a very similar situation and have succesfully implemented a solution along the lines suggested above. If the content is dynamic it needs to be generated via a processing mechanism (e.g batch process, jsp request, etc.). The embedded XSL stylesheets however, i assume, don't change and are static. As you encounter a uninterpreted stylesheet you can interpret in on the fly and then cache it for further use. Then the next time you encounter the same stylesheet, you won't need to recompile it, just retrieve it from cache. Having dynamic content on which to apply the stylesheet still allows you to cache/precompile the styleheets. They are simply applied to the new content with which they are associated. Hope this helps. Ted Rice Apama, Inc.
FW: Caching XLS style sheets
-Original Message-From: Ted R. Rice Sent: Wednesday, May 09, 2001 8:15 AMTo: 'Orion-Interest'Subject: RE: Caching XLS style sheets in actuality, caching pre-compiled stylesheets and then using them repeatedly is very possible and you will see large performance gains via this mechanism. in terms of applying the XSL, the general model is to create JSP Pages which produce XML content and have this content either be handled by a JSP Tag Extension, which you place inside the JSP Page, or a Servlet set up as content filter for all XML Content. The Servlet method is only available in spec 2.3 However, regardless of the implementation, caching can be performed by static cache shared across all instances of your object. When a JSP Page is processed, you can generate a unique key for this page based upon the servletPath(i.e., request.getServletPath()) and user-Agent header in the request (only applicable if applying different XSL stylesheets for different browser agents). Once you exctract the appropriate XSL Stylesheet from the XML and compile it, you can cache the compiled version using the generated key. In our case what we cache is a Saxon TransformManager. Then, using the dynamic content generated by the JSP Page, you can always look up and apply the pre-compiled style-sheet for the unique JSP Page - Browser Agent combination. Please note, the stylesheet is compiled and cached in a lazy manner, meaning it is done the first time a request for a particular stylesheet is made. This could easily be retrofitted to build all needed stylesheets at startup. hope that helps. Ted -Original Message-From: Vic Cekvenich [mailto:[EMAIL PROTECTED]]Sent: Sunday, May 06, 2001 5:55 PMTo: Orion-InterestSubject: Caching XLS style sheets I asked a question on an MVC application architecture using XLS, and got advice to cache XLS / XSLT style sheets, and pre compile them. Can someone give me some more background on this. How? What if the content is dynamic? (2 million items and 100,000 of styles + with any combination) Thanks in advance, Vic
RE: How about the latest xerces.jar and xalan.jar?
i've experience similar issues with orion 1.4.7 and saxon 6.2.1. if you update the versions of xerces to 1.3 and xalan to 2.0, you will get the MethodNotFound error when doing any javax.xml package calls. only way i got around it was: 1. remove jaxp.jar from the orion dir 2. open up xalan.jar and remove all the javax.xml classes additionally, we use UTF-8 encoding on all of XML/XSLT files to support localization. if you set the default-charset in the global-web-applicaiton.xml to be UTF-8 it will not work as it complains about unrecognized UTF-8 characters in the XML files. hoewever, the second you remove the default-charset it works perfectly. everything i've mentioned was never a problem until 1.4.7. none of our code has changed and it never had an issue with the default-charset, jaxp, or xalan/xerces. ted rice -Original Message- From: Duffey, Kevin Sent: Fri 3/9/2001 9:42 AM To: Orion-Interest Cc: Subject: How about the latest xerces.jar and xalan.jar? Orion team (and whoever else is interested), I am working on a small framework that uses Saxon and requires the latest xerces.jar file. I just did an autoupdate and it downloaded xerces.jar into the orion folder (I deleted the one that was there because of the problem I am about to describe). When I started my app, the MethodNotFound error I got when I left the 589KB version of xerces.jar in the Orion folder came back. So two things. First, can you please add the latest xerces 1.3.0. Its 1.5MB in size, but it adds a lot of new functionality that some of us are now using. Secondly, why is it when xerces.jar is in the Orion folder, Orion does NOT use the version I have in the WEB-INF/lib folder? I thought (sorry if I don't recall what the specs say on this) that libraries in the WEB-INF/lib of a web-app override the ones in a server dir? Thanks. winmail.dat
