Rafal Krzewski wrote:
>
> Raphael Luta wrote:
> > We have no problems with the Service infrastructure but a lot of code
> > sits in the CVS that *should* be Turbine services but currently are not
> > and are in the process of being moved as service.
> > During this process, we still need to initialize the components that are not
> > yet services and this is done by overriding the Turbine servlet init() method.
> >
> > When all the components are moved, this init() should be empty and thus
> > we can remove the subclass.
> >
> > The only alternative I see to this process is writing a new service that
> > would only initialize all the other components without providing any real
> > "service" method, but I find this solution much more a perversion of the
> > Turbine service model than the subclass one.
>
> I feel exactly the opposite. For me, writing a temporary wrapper service
> seems
> to be much less intrusive action.
>
> Initializing other subsystems is a very nice 'service' itself, isn't it?
>
> Move your ininitalization code from Layout into this wrapper service
> (JetspeedInitService?) and avoid creating the subclass alltogether.
>
In that case, I may mis-understand what you're doing with services.
My understanding of the Turbine service system is that it provides a way
to register initable singleton components that can be accessed from
other classes and provide well defined functionalities, usually through
an interface declaration independant of the actual implementations.
The typical service package pattern being:
<service>/
<service_interface>.java
<service_implementation>.java
<static_service_accessor>.java
If this is a correct definition and the real intent of the service
framework, what is the point of a JetspeedInitService with an empty
service interface and which can't be used by any other classes ?
It's a hack in my book.
If my defintion is incorrect, I definitely like to know what your definition
is but I think the name "service" is then misleading : you should rather use
"component" to define those classes without implying that these classes may
be of use for others classes (which is something I associate with "service").
In any case, whatever implementation method is used for this transitional
period, it won't be in the code in one month so this argument is really
for the sake of discussion.
--
Rapha�l Luta - [EMAIL PROTECTED]
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
