Hi Chris, Thanks for helping polish the rough edges of b19; [...]
> A few questions: > > 1) Where does the 'Application' fit in? Previously I had a > subclass of > Component that setup: > > - HostRouter > - Any number of filters, assigning the first filter as the > 'root' and > the last filter pointing to the HostRouter You can have a look at the updated tutorial examples to see how applications can be used. Let me try to summarize: - a Component contains a set of Connectors (Client and Server) - a Container is a Component that also contains a set VirtualHosts - a VirtualHost is a Router somewhat similar to the old NRE's HostRouter class - an Application can be attached to VirtualHosts in order to get calls - an Application always gets request with a "baseRefresres" property set relatively to the source VirtualHost - an Application automatically has a call logging service (no need to setup a NRE's LogFilter) - an Application automatically has a status setting service (no need to setup a NRE's StatusFilter) - an Application can designate its root handler by overriding the "createRoot()" method - an Application acts both as a deployment descriptor and a runtime handler > 2) "Renamed Handler into Finder. Note: Handler is still used, > but for a > new purpose!" > > Ouch! Hmmm, okay this is not ideal. I've been thinking on this again and here is the new plan: - as in beta 18, I'll keep Restlet as the top-level class (instead of Handler in the pre-beta 19) - BUT, the handleGet|handlePut|handlePost|... methods from Restlet will be moved to Handler because their are only used by this subclass, not by Component, Connector, Chainer, Application. This was the main concern which led me to push Restlet down one level in the hierarchy. OTOH, I will ensure that Handler (as in b18) can be used in a way similar to Restlet (as in b18) if needed: like overriding the handleGet() method to catch all GET calls, without having the override the findTarget() method. > 3) Lars brought this up earlier, but I'll reiterate: where are the > no-arg constructors? Or where's the docs explaining what the various > constructors do? The whole object/wrappedObject relationship > is a little > confusing -- what does it mean when a Filter wraps another > filter, or a > Component wraps another Component? Ok, I'll get rid of the wrapperConstructors. Otherwise, you'll see many constructors taking|requiring an instance of Context. This class is taking a very important role in b19. Each Restlet instance is "living" inside a given context. If you don't provide one via the constructor, an implicit one will be created. The context provides access to the rest of the container for each Restlet, services like logging, client connector invocations and access to configuration parameters. For example, if your Application runs inside a Servlet container, a specific instance of Context (a subclass actually) will be provided, where all logging messages will endup in the Servlet's application log. Also, the Restlet can invoke Client connectors, but can't manage them (start|stop) as this is the role of the container, and because they can be shared between several applications. > For instance, shouldn't I be able to create a Filter outside the > framework and, on plugging it in the proper references (like Context) > are resolved from the connections? I'm not sure if I fully understand this question, but you can indeed create an instance of Filter outside any container. Then attach it to an Application instance (via the "root" property for example). In this case, you will need to ensure that the Filter shares the same context by calling myFilter.setContext(myApplication.getContext()). There are two levels of Context: - Container's context giving access to all client and server connectors, to the container's log and container's parameters - Application's context giving access to container's connectors (potentially restricted to a few connectors), to the application's log and application's parameters. In addition, each Application has its own LocalClient connector to access to the local resources relative to the application (think about the WAR packaging) As a result: - in a Container, all Application instances, all container's connectors, all VirtualHosts will share the same Container's context - in an Application, all Restlets (root and attached ones) will share the same Application's context More soon too :-) Jerome
