You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Carsten Ziegeler <cz...@apache.org> on 2010/03/10 12:53:48 UTC
Re: Creating a Sling Utilities Bundle
Felix Meschberger wrote
> Hi all,
>
> We currently have a multi-faceted issue: We have the Sling API bundle
> containing a number of utility classes (HtmlResponse, ResourceUtil). In
> addition there are two utility classes in the Engine bundle
> (RequestUtil, ResourceUtil) which are of general interest.
>
> The problem with the locations of these classes are (1) mixing
> implementations into an API bundle is problematic, (2) extending
> implementations means increasing the API version, (3) using the Engine
> bundle utilities creates a dependency on the Engine bundle.
>
> I think we should create a new Utilities bundle which will host these
> utility classes.
>
> The classes are simply copied and then further developed in the new
> utilities bundle while the old classes are simply deprecated and removed
> in future versions. This will keep the classes distinct and not create a
> dependency to the new util bundle in the API bundle.
>
> WDYT ?
I don't have a definitiv answer.
Now I think that having a dependency on the engine bundle is bad and
maybe we could move all the public stuff from the engine bundle to
somewhere else - either the api bundle or a possible new utility bundle.
I'm not worried about too many bundles, but I'm a little bit worried
about too many dependencies or modules a developer has to know when
developing a sling application. having the utility code in the api
bundle has the advantage that everything a developer has to know and
needs is in a single place.
And in addition things like the ResourceUtil class (in the api) are
very useful and you can make good use of it all over the place. But on
the other hand we have a bug to add most of these methods to the
resource interface :)
So I'm definitly +1 on moving things out of the engine bundle.
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: Creating a Sling Utilities Bundle
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Wed, Mar 24, 2010 at 3:02 PM, Carsten Ziegeler <cz...@apache.org> wrote:
> ...Ok, so the RequestLog is engine specific and should stay in the engine
> bundle. The question is if we should deprecate it and make it an
> internal interface or leave it like it is....
I'm for deprecating and making internal - we have the
RequestProgressTracker to log what happens with requests, that's
probably good enough for now.
-Bertrand
Re: Creating a Sling Utilities Bundle
Posted by Carsten Ziegeler <cz...@apache.org>.
Am 24.03.10 14:54, schrieb Felix Meschberger:
>> 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 ;-)
:) Error handler is more an interface of the engine, so maybe we should
leave it like it is - usually people will not implement such a service.
>>> * 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 ...
:)
Ok, so the RequestLog is engine specific and should stay in the engine
bundle. The question is if we should deprecate it and make it an
internal interface or leave it like it is.
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: Creating a Sling Utilities Bundle
Posted by Felix Meschberger <fm...@gmail.com>.
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
Re: Creating a Sling Utilities Bundle
Posted by Carsten Ziegeler <cz...@apache.org>.
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
cziegeler@apache.org
Re: Creating a Sling Utilities Bundle
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
On 24.03.2010 12:04, Carsten Ziegeler wrote:
> I moved the service, but how do we proceed?
>
> We can:
> 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.
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 ?
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 ?
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 ?
* RequestLog - this is probably Engine specific and
should stay here. But: do we need it really ??
Regards
Felix
Re: Creating a Sling Utilities Bundle
Posted by Carsten Ziegeler <cz...@apache.org>.
Felix Meschberger wrote
> Hi,
>
> On 24.03.2010 12:04, Carsten Ziegeler wrote:
>> I moved the service, but how do we proceed?
>
> How about adding two methods to the SlingSettingsService ?
>
> * String getSlingHome();
> * URL getSlingHome();
> (I think Java 5 allows this)
>
> or
>
> * Type getSlingHome(Class<Type> type);
>
> where type is one of String, File, URL (this is probably too fancy ;-) )
>
Yes, I think that's really too fancy :)
I would go for two methods either with the same name or different name.
I'll create an issue for this and implement it.
Carsten
> The goal is to reflect the sling.home framework property
>
> Regards
> Felix
>
>>
>> We can:
>> 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) :)
>>
>> Carsten
>>
>>
>
--
Carsten Ziegeler
cziegeler@apache.org
Re: Creating a Sling Utilities Bundle
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
On 24.03.2010 12:04, Carsten Ziegeler wrote:
> I moved the service, but how do we proceed?
How about adding two methods to the SlingSettingsService ?
* String getSlingHome();
* URL getSlingHome();
(I think Java 5 allows this)
or
* Type getSlingHome(Class<Type> type);
where type is one of String, File, URL (this is probably too fancy ;-) )
The goal is to reflect the sling.home framework property
Regards
Felix
>
> We can:
> 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) :)
>
> Carsten
>
>
Re: Creating a Sling Utilities Bundle
Posted by Carsten Ziegeler <cz...@apache.org>.
I moved the service, but how do we proceed?
We can:
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) :)
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: Creating a Sling Utilities Bundle
Posted by Carsten Ziegeler <cz...@apache.org>.
Bertrand Delacretaz wrote
> On Tue, Mar 23, 2010 at 8:41 AM, Carsten Ziegeler <cz...@apache.org> wrote:
>> ...As a first step I would like to move the SlingSettingsService interface
>> to the api bundle.
>> My proposal is to:
>> - Add the interface to the API in the o.a.s.api.services package
>> - Deprecate the interface in the enigne bundle and let it extend
>> from the interface in the API
>> - Let the service impl in the engine bundle register itself for
>> both interfaces.
>>
>> WDYT?
>
> +1
>
Ok, thanks, so I'll go ahead with the change.
Regards
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: Creating a Sling Utilities Bundle
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Tue, Mar 23, 2010 at 8:41 AM, Carsten Ziegeler <cz...@apache.org> wrote:
> ...As a first step I would like to move the SlingSettingsService interface
> to the api bundle.
> My proposal is to:
> - Add the interface to the API in the o.a.s.api.services package
> - Deprecate the interface in the enigne bundle and let it extend
> from the interface in the API
> - Let the service impl in the engine bundle register itself for
> both interfaces.
>
> WDYT?
+1
-Bertrand
Re: Creating a Sling Utilities Bundle
Posted by Carsten Ziegeler <cz...@apache.org>.
Carsten Ziegeler wrote
> Ok, this conversion got stuck a little bit, but so far I think we more
> or less agree that having api/utility classes in the engine bundle is bad.
>
> So what about taking small steps and solve this first?
>
As a first step I would like to move the SlingSettingsService interface
to the api bundle.
My proposal is to:
- Add the interface to the API in the o.a.s.api.services package
- Deprecate the interface in the enigne bundle and let it extend
from the interface in the API
- Let the service impl in the engine bundle register itself for
both interfaces.
WDYT?
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: Creating a Sling Utilities Bundle
Posted by Carsten Ziegeler <cz...@apache.org>.
Ok, this conversion got stuck a little bit, but so far I think we more
or less agree that having api/utility classes in the engine bundle is bad.
So what about taking small steps and solve this first?
Carsten
--
Carsten Ziegeler
cziegeler@apache.org