avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew C. Oliver" <acoli...@apache.org>
Subject Re: [FOP Avalonization] IoC the holy grail?
Date Tue, 03 Sep 2002 15:30:24 GMT
Ad homnim attacks asside Berin, I extended the discussion that you were 
already having and took the example and explained why I disagreed with 
it.  If you do not like my jovial way of expressing it that would is not 
my concern.


>>SoC = that which wraps or needs poi to fit it into its own component 
>>extraction.  POI just needs to worry about reading and 
>>writing the file 
>>formats it works with, not about fitting into any particular 
>>component 
>>model.  (We have folks who have asked to turbineize it too). 
>>If Morphos 
>>is Avalonized or the HSSF Serializer that makes sense.  The 
>>API does NOT 
>>make sense avalonized.  POI should have as few dependancies 
>>as possible 
>>as what it is concerned with is VERY limited (by design).  (I 
>>can't take 
>>credit for that...thank Stefano -- I disagreed with him at 
>>the time but 
>>I see his wisdom)
> 
> 
> Sure, POI should have as few dependencies as possible.  However,
> if proper componentization of POI makes sense for POI, then
> I suggest you don't throw the baby out with the bath water.
>

POI is properly componentized for an API.


> The suggestions we provided don't necessarily mean you have
> to use Avalon, but it very well may cause POI to have a cleaner
> and more robust design.
> 

This is a growing concern of mine.  The view that everything should be
avalonized.  I joined this list for two reasons:  1. To further my 
understanding of Avalon 2. To raise the issue that the over agressive 
stance of this project is self defeating.  It is not necessary to 
avalonize every API or issue out there.

> 
> 
>>At one time we thought it made a lot of sense to make POI use 
>>log4j so 
>>that we could leave lots of tracing info in it for autopsies 
>>(if POI couldn't read/write a file and died, we could trace 
>>its life).  But what happened when people tried to deploy POI 
>>with their existing log4j 
>>application that used a different version of log4j?  Death and 
>>destruction and for want of deploying something that they 
>>wouldn't want to log in production anyhow (1000x slower).
>>
>>(and we tried commons logging but it didn't really solve that problem)
> 
> 
> And how does this relate to the _Avalon_ list?
> 

It illustrates my point that it is not ALWAYS appropraite to avalonize 
every piece of software out there.  It MAY be useful to create wrappers.

I illustrated the effect of another dependancy tree's incorporation and 
the negative effect it had.

> 
> 
>>So What would happen if you tied it to Avalon?  Same thing.  Someone 
>>deploys POI with a different version of whatever Avalon pieces and in 
>>the words of Marvin the Marshian kaboom.. an Earth shattering Kaboom.
> 
> 
> This is strawman rationalization and pure FUD.  Have you used Avalon?

Yes.

> We avoided 90% of the issues that caused Log4J and Commons Logging to
> fail.  

its the 10% that is 80% of the work.

> The fact that you say this crap means you have no clue what
> Component Oriented Design is or affords you.  The truth is that as long
> as the service interface (i.e. how you use a component) remains the
> same,
> then it doesn't matter which component implementation you use.  It will
> *still* work.  Keep in mind that this is true of whatever component
> architecture you use--whether you want to invent your own or use one
> that
> exists (like Avalon).
> 

This is not true in real world implementation.  This is IMHO pure 
achedemia.  Look at JAMES.  Try and switch the version of Avalon.  HA!
Doesn't work.


> 
> 
>>So in short APIs stay APIs.  Things which need them as components get 
>>component wrappers.  The dependancy  tree stays clean.
> 
> 
> Again, this is not related to the Avalon list at all, take it up on the
> POI list.
> 

No this is related to the ISSUE and the EXAMPLE!  The Example was POI. 
I extended it.  However I have the same issue with the recurring theme 
that everything must be avalonized.

> 
> 
>>>In which case I would create a set of active/behaviour orientated 
>>>classes.
>>>Something like OLEComponentVisitor. These "behaviour" 
>>
>>components I would 
>>
>>>strongly recomend use Avalon interfaces if you can.
>>>
>>
>>-1 While wrapping it is fine.  Making POI APIs depend on 
>>Avalon is just 
>>silly.
> 
> 
> Take it up on the POI list--I don't care about your infightings as long
> as it doesn't infect our list.
> 
> 

Give me a break.  I'm illustrating using the EXAMPLE that was on this 
list.  Its not infighting.


> 
>>-1 - Wrapping makes sense.  Heck if I were writting an 
>>application that 
>>I deemed it appropriate I'd wrap it in Components and 
>>Services.  But not 
>>in the core API.  NOT everything tht CAN be avalonized should 
>>be.  Less 
>>is more.
> 
> 
> 
> How the h-e-double-hocky-sticks do you propose to wrap with
> components something that is not originally a component?  If
> you want to reuse existing components, you have to design for
> components.  It's that simple.  Beyond that, take it off this
> list.  I don't care about your objections to POI API changes,
> this isn't the POI list.

Give me a break.  So every API in the world must be avalonized?  Who 
said we don't have components?

Normally I like/respect you alot Berin but someone really pee'd in your 
sanka today.

In an application. .  I'll use something OTHER than POI as an example 
(apparently everyone but me is allowed to use it):

Lets say you have a tarrif resolution system.  Its not based on avalon 
but it processes tarifs and outputs a result.  Well fine, does it need 
to necessarily be based on Avalon?  No.  You can wrap it inside a 
component or service (depending on which is appropriate) and your 
Component based application can use it.

The issue being that things like POI and the aforementioned system are 
primitives in a larger application.  They do not need to directly depend 
on the compoents etc.  You can utilize the bridge pattern and stay 
effectively component and/or service based.  It is not necessary for 
every dang API out there to support every avalon interface.  I don't 
think it serves Avalon or the projects that use it.  I've been watching 
this for awhile and have remained silent.

-Andy




--
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