Well, I feel silly :-) Yes, I had overlooked the extra parameter to StreamSource... the new code is checked in and works great. Thanks. Extra overhead for getResource() is no big deal because it's all done just once at configuration (re)load time.
I saw a few posts to one of the tomcat lists which suggested that URLConnection.getLastModified() is rarely ever implemented. Do you know if this actually works? Thanks, Jeff Schnitzer [EMAIL PROTECTED] > -----Original Message----- > From: Guy Evans [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, January 30, 2002 1:50 AM > To: Jeff Schnitzer; [EMAIL PROTECTED] > Subject: RE: [Mav-user] Some changes to maverick 1.0 > > Hi Jeff, > > I've had a quick look at the URLConnection stuff related to > getResourceAsStream(). > > If you print out the getResource() URL it corresponds to something like > "jndi:/localhost/si/html/xslt/reports.xsl", and the actual URLConnection > is > an instance of the class of > org.apache.naming.resources.DirContextURLConnection. For mysetup that is > part of the tomcat installation. Looking through that code it looks like > everything maps to normal files at the end of the day; there are no > additional TCP/IP connections. > > So there's going to be some overhead through the couple of additional > objects that are created and the extra code it has to go through. I would > be surprised if it was significant but it may make sense to have this a > development debug option since it's unlikely to be needed in a production > environment. > > Cheers > Guy > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]On Behalf Of Jeff Schnitzer > > Sent: 28 January 2002 03:41 > > To: [EMAIL PROTECTED] > > Subject: RE: [Mav-user] Some changes to maverick 1.0 > > > > > > I've checked in most of the changes for these features. Maverick now > > uses getResourceAsStream() instead of getRealPath(), and <param name="" > > value=""/> elements within <controller> elements are now populated on > > the controller bean. > > > > I have one question before I add timestamp checking on XSL files: Is > > creading and checking the date of a URLConnection for every request > > going to cause performance issues? The mechanism by which > > URL/URLConnection interacts with the container is not clear to me. > > > > Thanks, > > Jeff Schnitzer > > [EMAIL PROTECTED] > > > > > -----Original Message----- > > > From: Guy Evans [mailto:[EMAIL PROTECTED]] > > > Sent: Tuesday, January 22, 2002 1:42 AM > > > To: [EMAIL PROTECTED] > > > Cc: Steve Sowerby > > > Subject: [Mav-user] Some changes to maverick 1.0 > > > > > > Hi, > > > > > > Over the last few weeks we've made some small changes to Maverick 1.0. > > > I'd > > > thought I'd enumerate them here, hopefully either they are already > > > superceeded by Maverick 2.0 or if the changes we made are considered > > > useful > > > they can be rolled into a future Maverick 2.0 relelase? Anyway, the > > > changes > > > are :- > > > > > > * We couldn't use maverick within a .war file since it makes some > > calls to > > > getRealPath() on the webapp context. As I understand it if a web app > > is > > > run > > > directly from a .war file then getRealPath() can return null and > > > getResource() or getResourceAsStream() should be used instead. This > > > required small changes to ConfigLoader.java and > > PipelineTransforming.java. > > > Grepping through the 2.0 source code it appears that there are still > > calls > > > to getRealPath(). > > > > > > * We were finding that a lot of our commands would use the same basic > > > controller class but with slightly different options (e.g. retrievals > > from > > > a > > > database.) Initially, this led to a proliferation of classes which > > > typically just passed some parameters to the base class constructor. > > To > > > help prevent the number of classes we modified the controller creation > > so > > > that within the maverick.xml <param name=" " value=" "/> could be > > > contained > > > within the <controller> element. These parameters were then used to > > "bean > > > populate" the controller in exactly the same way as if they had been > > > passed > > > as URL query parameters. > > > > > > I suspect that the factory mechanism in v2.0 would provide another > > > solution > > > to this problem? > > > > > > * Just before an XSL transformation is used, we check the modification > > > time > > > of the underlying file. If the file has been modified since the > > template > > > was created the in-memory template is recomputed. This means we can > > > simply > > > change the XSLT file and maverick will automagically detect the > > changes. > > > > > > If it would be useful we can send patches against the 1.0 release for > > the > > > above changes. > > > > > > Cheers > > > Guy > > > > > > > > > _______________________________________________ > > > Mav-user mailing list > > > [EMAIL PROTECTED] > > > https://lists.sourceforge.net/lists/listinfo/mav-user > > > > _______________________________________________ > > Mav-user mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/mav-user > > _______________________________________________ Mav-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mav-user
