Excalibur and the new Service interfaces

[Gary Shea <sh...@gtsdesign.com>]

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?

Thanks,

        Gary


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: Excalibur and the new Service interfaces

[Leo Sutic <le...@inspireinfrastructure.com>]

> From: Gary Shea [mailto:shea@gtsdesign.com]
> 
> I followed a bit of the Resolvable/Service/etc. debate, and am wondering
> if the outcome has made its way into Excalibur code yet.

The outcome made its way into the org.apache.avalon.framework.service
package. That's all there is for now.

> Any advice/hints?

If you can get away with it, *don't* use the newest conventions.

If you stick with Component / ComponentManager you have the ECM and
its associated classes. There is nothing similar for ServiceManager.

My advice is this: Stick with Component/ComponentManager. Once we
get around to Avalon 5, porting the code should be simple.

Of course, if you absolutely need to get rid of Component, go for 
the service package.

/LS




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: Excalibur and the new Service interfaces

[Stephen McConnell <mc...@apache.org>]

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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>