- From: Yves Lafon <ylafon@w3.org>
- Date: Wed, 23 Mar 2005 15:00:08 +0100 (MET)
- To: "Laird, Brian" <BLaird@perseco.com>
- cc: www-jigsaw@w3.org
- Message-ID: <Pine.GSO.4.62.0503231446510.18102@gnenaghyn.vaevn.se>
On Tue, 22 Mar 2005, Laird, Brian wrote: > Hey Yves, > > I did try the FramedResource within the indexer, but I found a place in > the code where the basic indexer requires a file on the physical disk to > be "triggered" so there didn't seem to be a way to get indexer to > "build" or simulate that the file actually was there. In my last email I was in fact proposing another solution :) Instead of having a directory with a custom indexer, replace that with a leaf resource that will use the remaining part of the URL as a parameter. This should be done by extending lookupOther (see HTTPFrame). ( if (ls.getRemainingPath().endsWith(".flow")) ... ) This is done by the lookup done in the frame (rather than the resource). Like this: Directory+ServletDirectoryFrame | ------ servlet + modified ServletWrapperFrame | |---------- foo.flow |---------- bar.flow > I am pasting in another message that I sent that you might not have > seen. This one explains how I got it working even after trying to use > the ServletDirectoryFrame. The problem that I was running into was that > the *.flow as the resource name was causing a lot of problems. I don't like that much the redefinition of getMatchingCharCount, even if it will work. > ---------------------------------Previous Message--------------------------- > Yves, > > I got it working but I would say it is an ugly yet workable solution. Here is what I did: > > - turned checkSensitivity off > - created a class that extends DirectoryResource (see below) > - created a new resource using this instead of DirectoryResource > - Added the ServletDirectoryFrame underneath it to have a proper servlet context > > package jigsaw.extenstions; > import org.w3c.jigsaw.resources.DirectoryResource; > public class MyDirectory extends DirectoryResource { > > protected int getMatchingCharsCount(String s1, String s2) > { > if (s1 == null || s2 == null || s1.length() == 0 || s2.length() == 0) > { > return -1; > } > if (s1.endsWith(s2)) > { > return 1; > } > return super.getMatchingCharsCount(s1, s2); > } > } > > The getMatchingCharsCount is from the ContainerResource class which is > called when check sensitivity is turned off and the container can't find > the resource any other way. I am assuming this was intended to handle > things capitalization problems (ex: index.html vs. Index.html). It is a > simple implementation, but it was really difficult to come to this > solution. > > What I don't understand is that in the servlet spec you can do something > like this: > > servletA can be defined to listen on anything *.extension. > > I would think that Jigsaw should be able to handle this using the extensions, but I was never able to get it work because there wasn't a physical file that corresponded unless I made one which doesn't make sense for me. Is this something that can be added to the existing indexers or would this be a whole new indexer? > > Hope this helps... > > Brian > ----------------------------end of message--------------------------- > > Looking back at the things I tried, I did try to extend the lookupOther but it would never get called because of the getMatchingCharsCount method that I ended up overriding. > > Let me know what you think, > Brian > > > -----Original Message----- > From: Yves Lafon [mailto:ylafon@w3.org] > Sent: Tuesday, March 22, 2005 4:45 AM > To: Laird, Brian > Cc: www-jigsaw@w3.org > Subject: RE: Servlet setup question > > > On Mon, 14 Mar 2005, Laird, Brian wrote: > >> Hey Yves, >> >> Did you see my follow up email about this? I couldn't get the indexer >> to work without having a physical file located on the disk. If you >> didn't get my other email let me know and I can resend it. I really >> would like your opinion about what I am doing and if it is "o.k." from a >> design sense or if it is a really big hack. > > By "the indexer" you mean the one used for jsp? How about replacing the > FileResource by a FramedResource? > > Going back to your solution, the best solution would be to extend the > ServletDirectoryFrame, and change the "lookupOther" method to fit your > need. If lookupOther is defined, then the frame must be put on a > FramedResource (ie: not a "physical" resource). It won't be a container > per-se but from what I understood of the situation you won't have files > underneath, so the remaining part of the URI is treated as extra > parameters. You can see VirtualHostFrame as an example. > > (FramedResource calls frames[i].lookup(ls,lr), in HTTPFrame, lookup calls > (depending if it is attached to a file resource or not, lookupFile, > lookupDirectory or lookupOther). > Thanks, > >> >> Thanks, >> Brian >> >> ________________________________ >> >> From: Yves Lafon [mailto:ylafon@w3.org] >> Sent: Thu 3/10/2005 11:59 AM >> To: Laird, Brian >> Cc: www-jigsaw@w3.org >> Subject: RE: Servlet setup question >> >> >> >> >> On Wed, 2 Mar 2005, Laird, Brian wrote: >> >>> Yves, >>> >>> I am still struggling with this one. I build a custom resource which >>> just extends the ServletWrapper. Since I am using JDK 1.4 I decided it >>> would use regular expressions. Here is the code: >> >> the Lookup mechanism works only on containers, while ServletWrapper is a >> "leaf" resource. >> So the lookup mechanism is never called. >> >>> >>> package org.w3c.jigsaw.servlet; >>> >>> import org.w3c.tools.resources.LookupResult; >>> import org.w3c.tools.resources.LookupState; >>> import org.w3c.tools.resources.ProtocolException; >>> >>> >>> public class PersecoFrameworkServletWrapper extends ServletWrapper >>> { >>> public boolean lookup(LookupState ls, LookupResult lr) throws ProtocolException >>> { >>> if (ls.getURI() != null && ls.getURI().matches(getIdentifier())) >>> { >>> lr.setTarget(getResourceReference()); >>> return true; >>> } >>> return super.lookup(ls, lr); >>> } >>> } >>> >>> Then I defined a DirectoryResource with a ServletDirectoryFrame >>> underneath it. Then I added a resource under that directory with the >>> identifier of *.flow and pointed it to the class above. In stepping >>> through the code it just never seems to get my class. I always get a >>> 404 back from the server. Can you let me know what I am doing wrong on >>> this? I should be extending the ServletWrapperFrame instead? >> >> Wouldn't it be possible to have an indexer to handle this? >> you can map the "flow" extension to a FileResource+ServletMapperFrame and >> point to the URI of the servlet in charge of handling them. >> (a bit like for JSPs [1]) >> The servlet is located using an internal lookup, so it may be everywhere >> on the server. >> Or maybe I just misread what you really want there :) >> Thanks, >> >> [1] http://www.w3.org/Jigsaw/Doc/User/jsp.html >> >> >>> >>> Thanks, >>> Brian >>> >>> -----Original Message----- >>> From: Yves Lafon [mailto:ylafon@w3.org] >>> Sent: Wednesday, February 23, 2005 4:25 AM >>> To: Laird, Brian >>> Cc: www-jigsaw@w3.org >>> Subject: Re: Servlet setup question >>> >>> >>> On Tue, 22 Feb 2005, Laird, Brian wrote: >>> >>>> How do I configure a servlet in Jigsaw to listen on a specific >>>> extension? This extension will not be mapped to any physical file on >>>> the disk. My example is that I want to have a servlet listen in a >>>> specific directory for anything with .flow at the end. Is this possible >>>> and how would I go about doing it? In that same directory, I will >>>> probably have some images and static files. >>> >>> It is easy to do in the Jigsaw framework, but I don't know how to do that >>> with servlets. >>> The way to do this in Jigsaw is to overload the "lookup" method of a >>> resource or a frame. >>> >>> If your .flow are linked to existing files, the ServletMapperFrame on top >>> of a FileResource is the way to go (much like jsp, it delegates everything >>> to a servlet with the path of the .jsp given to the servlet, see [1]) >>> It might work without any physical file on the disk if you replace the >>> FileResource by a FramedResource which is only virtual. >>> Thanks, >>> >>> [1] http://www.w3.org/Jigsaw/Doc/User/jsp.html >>> >>>> >>>> >>>> >>>> Thanks in advance, >>>> >>>> Brian >>>> >>>> >>>> ************************************************************************ >>>> This e-mail and any accompanying documents or files contain information that is the >>>> property of Perseco, that is intended solely for those to whom this e-mail is addressed >>>> (i.e., those identified in the "To" and "Cc" boxes), and that is confidential, proprietary, >>>> and/or privileged. If you are not an intended recipient of this e-mail, you are hereby >>>> notified that any viewing, use, disclosure, forwarding, copying, or distribution of any of >>>> this information is strictly prohibited and may be subject to legal sanctions. If you have >>>> received this e-mail in error, please notify the sender immediately of any unintended >>>> recipients, and delete the e-mail, all attachments, and all copies of both from your system. >>>> >>>> While we have taken reasonable precautions to ensure that any attachments to this e-mail >>>> have been swept for viruses, we cannot accept liability for any damage sustained as a >>>> result of software viruses. >>>> ************************************************************************ >>>> >>> >>> >> >> -- >> Yves Lafon - W3C >> "Baroula que barouleras, au tiéu toujou t'entourneras." >> >> >> ************************************************************************ >> This e-mail and any accompanying documents or files contain information that is the >> property of Perseco, that is intended solely for those to whom this e-mail is addressed >> (i.e., those identified in the "To" and "Cc" boxes), and that is confidential, proprietary, >> and/or privileged. If you are not an intended recipient of this e-mail, you are hereby >> notified that any viewing, use, disclosure, forwarding, copying, or distribution of any of >> this information is strictly prohibited and may be subject to legal sanctions. If you have >> received this e-mail in error, please notify the sender immediately of any unintended >> recipients, and delete the e-mail, all attachments, and all copies of both from your system. >> >> While we have taken reasonable precautions to ensure that any attachments to this e-mail >> have been swept for viruses, we cannot accept liability for any damage sustained as a >> result of software viruses. >> ************************************************************************ >> > > -- Yves Lafon - W3C "Baroula que barouleras, au tiéu toujou t'entourneras."
Received on Wednesday, 23 March 2005 14:01:01 UTC