Hi, On 24.03.2010 14:03, Carsten Ziegeler wrote: > 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?
Uh, this smells like pandorrah's box ... lets reconsider this for a moment ;-) > >> >> * 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. The intent of this interface was not really that it would be internal: bundles could implement this and register as a service and some configuration could instruct request-level log messages to be directed there ... But probably, this is a bad idea ... Maybe this has never been used ... Maybe it does not even work correctly ... Regards Felix
