Rafal Krzewski wrote:
>
> [EMAIL PROTECTED] wrote:
>
> > Yes and no. If you consider that the resources should be complete
upon
> > the start of the application, then the use of RuntimeException is
valid
> > but if you consider the cases we discussed with Jason where the
resources
> > can be completed after the initialization (by querying an
administrator to
> > provide the correct values), such an exception really becomes an
> > applicative exception and should be processed by any code using
such a
> > service.
>
> I disagree. J2EE specfications state that the configuration
information
> is built in three stages
> - component creation
> - application assembly
> - application deployment
> After that application is up and running.
> I think that querying the administrator (or the first user) for
> configuration
> values at runtime is a bad idea.
>
Well, it may simplify the configuration step by providing a GUI for
configuration,
but I've got no strong opinion on that, if you think RuntimeException
I'll trust
you on that.
> > the static accessor class and service interface should not be in
the package of
> > the implementation but in the services package.
> >
> > For example, for a 'GlobalCache' service, the default service
template
> > should be IMO:
> >
> > org.apache.turbine.services.GlobalCache - static accessor
> > org.apache.turbine.services.GlobalCacheService - service definition
> > org.apache.turbine.services.globalcache - default service impl
package
> >
org.apache.turbine.services.globalcache.PersistentGlobalCacheService
> > - example impl of the
service
> > It allows people to use:
> > import org.apache.turbine.services.*;
> > and access any services they wish.
>
> I like this idea! The only downside I see, is that the 'services'
> package
> would become rather bloated, and the framework classes would be
hidden
> among among actual services. Maybe we should move those classes into
> 'services.framework' package? What do you think?
>
Yes, I could be a good idea to move the actual service framework in a
subpackage
because very few classes actually need to access these apart from the
services
themselves. (I can only think of Turbine itself)
As for the bloat of the services package, it's not worse than the
current
flurry of subpackages in there ;)
Anyway, I think I'll experiment this in Jetspeed and see how it fares.
--
Rapha�l Luta - [EMAIL PROTECTED]
Vivendi Universal Networks - Services Manager / Paris
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
