- 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