avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen McConnell" <mcconn...@apache.org>
Subject RE: Excalibur and the new Service interfaces
Date Wed, 27 Feb 2002 02:32:45 GMT


Hi Garry:

See notes in-line.

> -----Original Message-----
> From: Gary Shea [mailto:shea@gtsdesign.com]
> 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:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message