You are viewing a plain text version of this content. The canonical link for it is here.
Posted to slide-dev@jakarta.apache.org by Unger Richard <ru...@camino.at> on 2002/09/10 19:03:01 UTC

SlideRealm Problems

Hi!

Ok, I'm back from holidays, and I have finally done it. I've convinced my
network admin to punch a hole through the firewall for CVS, gotten the most
recent slide, torturously collected all dependencies and fought with the
build.xml file. I have a compiled full-dist.

It took me a while to figure out the logic behind it all, and even longer to
configure tomcat and slide to my liking, and move all the files which slide
puts in dist/server/... and dist/slide/... into their new homes within my
tomcat setup.

So is it working? No! Or at least, only partially. My problems are with the
wrappers, the slide webapp itself seems to be working fine.

My basic question is: What is the logic behind the catalina-wrapper classes?


* As near as I can tell all the various Host wrappers do is connect to a
namespace, add it as a context, and attempt to install various webapps whose
names are hard-coded in the wrapper classes. I don't really see the need for
all this, as all these tasks can be accomplished simply using tomcat and its
configuration, along with the webapp's web.xml files. Why the host wrappers?

* Next the SlideServerListener. Again, I do not fully see the point, except
that it initializes the domain at the outset, and provides a 'Home' for the
domain to live in. But since the Domain is static anyway, why bother? The
first host to access the domain would cause it to be initialized as it is. I
suppose the Listener class can ensure a clean shutdown of the domain when
the server goes down more easily than a finalize() method in the static
domain.

* Finally, the SlideRealm, the whole reason I am even bothering with the
wrapper classes at all: The SlideRealm.java file claims, in its sparse docs
to fall back on the 'tomcat', 'webdav' and 'default' namespaces if no
namespace with the same name as the Catalina Container the Realm is
contained in is found. Firstly, this is not the case, as far as I can tell.
If the namespace is not found with the same name as the Catalina Container
containing the realm, the Realm throws an exception. This is plain from the
code, and also what happens when I run my setup. Secondly, I don't see why
there is not a more flexible method for specifying the namespace, say as a
parameter of the realm if this is possible. Finally, would it not be better
to define the SlideRealm as a resource (like the UserDatabase Resource in
the Tomcat 4.1 sample server.xml), and allow many SlideRealms from any
container to refer to the resource definition. The Resource parameters could
then specify which namespace to use for authentication.

Is there a solution to my problem other than giving my namespace and all
hosts in my configuration the same name?

Is anyone working on the idea of a SlideRealm as a Catalina resource? Does
anyone else think it would be useful?

Richie
Richard Unger

PS: Without wanting to sound too mean - I really think Slide is a very cool
piece of Software, and a cool idea - I really think the docs for slide could
use some work, esp. with respect to explaining the rationale behind it, and
the broad details of project status and features. For example: It took me
more than 3 weeks to figure out that I would never get versioning working
with the release version of slide - it isn't mentioned anywhere that the
DeltaV features aren't in 1_0_16, and you need the CVS version for these. It
took me quite a while to find all the dependencies in such a way that they
all worked well together (links would be helpful) and even then I had to
hack the build.xml file and upgrade ant to get things compiling. And the
compiled results, the dist directory also takes some thinking over before
the content can be used. But like I said, I think slide is a very cool
project, so don't take my criticism too hard! Incidentally, I would be
pleased to contribute to the slide documentation if this is allowed...

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>