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
