David H. DeWolf wrote: > No, actually this is VERY helpful. It's CRITICAL to us to make sure > that pluto is: > > 1) Lightweight > 2) Very Easy to Use > > We've had a push lately to accomplish #2 but perhaps have forgotten #1 > in the process. Please continue to remind us about this. . .I'll work > on nailing this lightweight configuration down near the begining of > next week.
Thanks. That will be good. In light of this, I'm going to try and identify the areas that I'm finding difficult to handle. I may be that much, if not all, of my problem here is not knowing where to look for the corresponding documentation. My fundamental difficulty seems to be understanding the configuration of Pluto, its test environment, and its relationship to general servlet configuration. Please bear in mind that I have limited experience with using/configuring Tomcat so I may be lacking some assumed or implicit knowledge here. ... At heart, Pluto configuration seems to involve way too many files and options: - tomcat configuration (server.xml, tomcat-users.xml) - pluto servlet configuration (conf/Catalina/localhost/pluto.xml, testsuite.xml) - webapps/pluto/WEB-INF/web.xml, pluto-portal-driver-config.xml, pluto-portal-driver-services-config.xml - webapps/testsuite/WEB-INF/web.xml, portlet.xml, testsuite-config.xml, testsuite-2-config.xml (though I recognize much of this is for configuring the test suite itself) - key values defined in XML files definingh server context values - key values defined in java source code - key values defined in JSP pages I'm sure there's a sensible rationale for all this, but for someone approaching the software from outside, it's pretty daunting trying to figure out how the various configuration options fit together. Because of all the indirection/late binding within Pluto, I find it's difficult to resolve these uncertainties just by looking at the code. I'd like to have a diagram or one-pager showing how all the bits of configuration fit together, and I'll even have a shot at making one if I ever get to the point that I think I have a sufficient grasp of how the parts fit together. ... The recent introduction of required-authorization in the default configuration is also an added hurdle for getting a simple system up and running. ... I think it would be good to have a very simple default (or easily selected) deployment with a very simple test page, so that it would be easier to distinguish portal setup from the test portlet setup. It also think would be good if there were some sensible built-in defaults for many of the configuration options so that one can start with very minimal configuration and add bits as the need arises to override the basic default behaviours. (I'm also doing some work with other web application frameworks that do this, and it really makes it much easier to learn how the pieces fit together.) #g -- Graham Klyne Research Technology Service Oxford University Computing Services
