Bugs, Features, FAQs (1-10)?

Alexandre Rafalovitch writes:
 > 1) Once you setup VirtualHost resource, an editor would not let you access
 > the resources sitting under VirtualHost resource (eg. MirrorDirectory).
 > Instead it tries to access /Admin/Editor/mirror. This problems rises from
 > the fact that VirtualHost resource is substituting its parent URL for its
 > own URL which confuses editor trying to costruct url of a resource based
 > on its parent's url + resource name. You can still edit the resource
 > directly (eg. /Admin/Editor/virtualHost/mirror), but that is not a
 > solution.

I can't seem to be able to reproduce that. If you look at the lookup
method of the VirtualHost resource, you will see that in case it's
an internal lookup (the one the editor uses), than lookup is
appropriately handled. I did (right now), setup VirtualHost and
MirrorDirectory, and I am still able to accesss MirrorDirrectory
attributes using the std path.

 > 2) LookupState.getRemainingPath() would not put / at the end of the
 > directory. Therefore, if a resource uses getRemainingPath and then uses
 > that to proxy to the other host, it would get into infinite loop as the
 > redirection request by server (at least Jigsaw server) would get /
 > stripped off again, etc. It can be worked around by checking IsDirectory
 > flag and puting / at the end if it was, but I think this should be done by
 > Jigsaw itself.

I guess I see your point. I didn't run into that since
ForwardDirectory takes the full request URL (without touching it) to
build the client-side request url. 
I am still not convinced that having Jigsaw internals add an extra /
at the end of the last component is a good idea: LookupState is really
meant to parse the URL, and you shouldn't have to worry about slashes
when using it (in the sense that / is a syntactic thingy saying
isDirectory). What I mean is: if LookupState is to releive you from
syntax, than isDirectory seems to me a better alternative than /.
[I am not convinced by my own 'not convinced' argument though]

 > 3) This is in between a bug and FAQ entry: How can a container restrict
 > the children it can have. I know it is possible to do by throwing
 > exception during registerResource, but it is both undeclared and
 > non-evident.  registerResource is not declared to through any exceptions,
 > so the only way it to throw runtime Exception, which is a bad thing. It
 > works, but it is ugly. Are there any other way to do that and if there are
 > not, maybe there should be. After all, it could be usefull in many cases.
 > (eg, ServletDirectory could use that). Workaround could be to do that
 > during lookup time and delete the offending resource, but that could be
 > ugly in many caases.

That's a good point. Also you may want some resources to be included
oinly in some specific kind of containers (ie ServletWrapper and
ServletDirectory). I guess the only solution I can think of is to have
registerResource throw an (explicit) BadChildException [this is an
incompatible API change, btw]
Should we go for that ? (yes until I hear some complaints - has
entered the todo)

 > 4) There is no URLAttribute/URLField in standard distribution, but it
 > clearly would be profitable. Eg. I could not make MirrorDirectory work
 > until I supplied the URL in the way it wanted it. And the way I knew it
 > did not work was because I was getting root instead of mirror when I try
 > to access it. URL field that would accept only properly formed URLs would
 > be very nice.

It has been floating around, I can't remember why it didn't went into
release. I will make sure to fix that.

 >  Things that were talked about, but I am not sure what the state on them
 > is:
 > 
 > 5) When I mark my field Mandatory what does it do? Does it get checked
 > anywhere and enforced? (FAQ?)

A resource editor is supposed to check that MANDATORY fields are not
left blanks. I am not sure the current form based editor does ensure
that constraint, so this can only be used as a hint right now (the
idea is that if your resource cannot initialize itself if an attribute
is not present, than that attr should be made MANDATORY).

 > 6) There is still an OutgoingElement class hidden in FilteredResource. As
 > far as I can see, it is not used anywhere and just confuses people.

I got rid of it yesterday ;-)

 > 7) Host names for VirtualHost require port number to be inluded.
 > (FAQ?)

Added to the FAQ [oops, no FAQ entry on virtual host] Added to virtual
host ref manual:
---
Each child of the VirualHostResource must be named under the host name
it will serve. If you have a machine A with names name.foo.com and
alias.foo.com, and if the server is running on port 8001, then
requests prefixed by http://name.foo.com:8001/ will be dispatched to
the child resource of the virtual host resource named
name.foo.com:8001 and requests prefixed by http://alias.foo.com:8001
to child resource alias.foo.com:8001.
---

 > 8) Host names for VirtualHost again, should they be matched as Case
 > Sensetive or Case Insensetive? I am not sure HTTP1.1 standing is on host
 > names. If insensetive, VirtualHost should do some more work about not
 > letting two names for the same host, etc.

They should be case insensitive, fix:
- registerResource redefined on VirtualHostResource, to lower the case
  of the identifier for the resource
- lookup lower the case of the host name before looking up for a
  child.
[done]

 > 9) Should there be ErrorResponce on filters? I have tried to use
 > DebugFilter to check the errors on my configurations, but some of the
 > request just do not generate filterOut call. That could present problems
 > for some of the filters that do synchronization/logging as well.

Something have already changed in filters: it is no longer the dutie
of resources to invoke filters. This is now handled by Jigsaw itself
Note that this is "nearly" not an incompatible API change, the only
difference you see - as a resource programmer - is that the split of
the HTTPResource::perform method is no longer splitted into filterIn,
filterOut and dispatch. It is just perform with only the request as an
argument.
Also, filters can now define an exceptionFilter method, altogether the
four methods on filters are:
- lookup
- ingoingFilter
- outgoingFilter
- exceptionFilter
Semantics: 
. lookup is called at lookup time. If something fais during lookup,
then any filter that was invoked before failure will get their
exceptionFilter method called. 
. Before request is performed, ingoingFilter methods are called on all
filters. If sonething fails during that stage, all filters whose
ingoing method have been called before failure will get their
exceptionFilter method called. If a filter is able to generate a reply
at ingoing time, then remaining filters are *not* called, all filters
whose ingoing have been called previous to reply will get called.
. [same semantics has last step for outgoing filters, after request
processing]

As was noted in my "open issues" mail, we might have to add yet
another method to handle the case where the output stream of a reply
is fetched by the resource (servlets, for example)

 > GHOSTS:
 >  
 > 10) I managed to get Jigsaw into state when it would not serve a
 > particular page under any circumstances and does so not by returning 400,
 > but by doing something real bad on the connection. I do not have steps for
 > reliably reproducing it, but once I get Jigsaw into that stage it stays
 > there. Last time it locked up on /Admin/Editor and I was able to try
 > accessing it in many different ways. Here are the list of responces: 
 > Netscape3. --" Document contains no data" in a popup error box. 
 > MSIE3      --"Server return invalid headers" or some such
 > HTTPClient --"Unexpected EOF". This one just dies.
 > direct telnet -- dies without returning any data.
 > Neither debug filter nor logs show theose requests at all.
 > 
 >  I think it could be something with sockets, but have no idea what it can
 > be.
 > 
 > I am running Jigsaw(two of them in fact. :-} ) under JDK1.1 on Win95
 > without recompilation.

If ever you get that kind of situation, make your best to send me a
thread dump. I ahven't seen that kind of problems, but I must admit
that I haven't kept Jigsaw running on Win95 for long (I work under
solaris and winNT mainly)

 > Regards,
 >   Alex.
 > Ps. I understand that unswering this email all at once is a pain. Answers
 > with Q numbers in them would probably be good idea (eg."RE: bugs,
 > Features,...(q1-5)") 

Too late ;-)

Thanks a lot for this detailed report,
Anselm.

Received on Thursday, 27 March 1997 04:54:20 UTC