Felix Meschberger wrote >> a) copy the request and response util classes from engine to api so >> people have everything in a single place >> b) create the utilities bundle as Felix suggested >> c) leave everything as it is >> >> I'm personally in favour of a) :) > > I came to dislike mixing API (interfaces, exceptions) with > implementations (classes, utilities). Thus my preference would be b. But > (a) would be ok for me, too. Puuuh, great :) I think utility classes are more API than implementation, but maybe they are more an indicator that the API is incomplete :) Anyway, it would be great if we can continue with a)
> > We should also discuss about the rest of the o.a.s.engine contents: > > * EngineConstants > sling.home/sling.home.url - maybe move to SlingConstants > and have them provided by the SlingSettingsService ? Yes, > SLING_CURRENT_SERVLET_NAME - maybe make this an official > request attribute while handling a sling request (and > move the constant to SlingConstants) ? > or add this to the SlingHttpServletRequest ? Let's move the constant > SLING_SERLVET_NAME - This is Sling Engine specific for > initializing servlets with configuraiton. > Shouldn't we move initialization of Servlets to the > Servlet Resolver which also registers them with the > ResourceResolver ? Yes, sounds good to me, however this is used in the engine.servlets package, class AbstractServiceReferenceConfig. Here we also have the ErrorHandler interface. I think the AbstractServiceReferenceConfig is more an internal class, so maybe we should just deprecate this as well. And maybe we should move the error handler into the API as well? > > * RequestLog - this is probably Engine specific and > should stay here. But: do we need it really ?? I think this more an internal interface, so maybe we should just deprecate it. Carsten -- Carsten Ziegeler [email protected]
