Hi Garry:
See notes in-line.
> -----Original Message-----
> From: Gary Shea [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, 26 February, 2002 22:31
> To: Avalon Developers List
> Subject: Excalibur and the new Service interfaces
>
>
> I followed a bit of the Resolvable/Service/etc. debate, and am wondering
> if the outcome has made its way into Excalibur code yet. I'm thinking
> of using Excalibur in a project I'm working on, and would like to be
> using the newest conventions...
>
> Any advice/hints?
>
Excalibur packages that are "clean" and independent of the
Component/Service interface question (i.e. Component is not passed
as a method parameter) include the following:
collections
concurrent,
i18n
io
logger
monitor
naming
property
proxy
In addition, all of the XML package is clean except one class that
has a dependency on ComponentManager (but I would need to closer to
address "real" dependence level this implies).
The problematic Excalibur packages include:
excalibur.component <-- component here, component there,
component everywhere ...!
excalibur.pool <-- implies Component on pooled resource
but could be easily updated to be Component neutral
excalibur.datasource <-- due to pool dependencies
The real problem concerns the component package, not only due to
the Component parameter issue, but also, it is heavily biased
towards the pooled resource model - which in turn requires pooled
object to implement the Pooled interface (which complicates life
much in the same way that Component complicating things in framework).
While excalibur.pool can be easily updated, the excalibur.component
package makes the broad assumption that everything is a Component and
it is itself dependent on the pool package - so updating pool would
break the component package. A practical solution would be to add
an excalibur.service package together with a excalibur.snooker (a
alternative to pool) package.
So if your serious about non-Component components, the practical
advise is not to use the Excalibur pool or component packages and
focus on leveraging the framework.
Cheers, Steve.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
