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:59:18 GMT
Thanks Steve.  I'm going to shut up now though to provide harmony.  At 
least someone understood.

-Andy

Stephen McConnell wrote:
> 
> For what its worth - I think Andrew's opinions are completely 
> appropriate for this list.
> 
> One of the most frequent questions I get asked "off-list" is "when 
> should I use Avalon" in the process of building a new system.  The 
> Avalon component model is brilliant in the right scope - generally, that 
> scope is reasonably easily established along the lines the Berin 
> described.  Another consideration is re-use which has not been raised.  
> There is a balance between using the Avalon patterns (and inherent 
> dependencies) and the consistency that this provides across an 
> implementation.  Sometimes that consistency isn't justified.  My take is 
> that Andrew is putting forward a case where it isn't justified - ok - it 
> may be a point to debate - but without any doubt - the subject is 
> dealing with Avalon boundaries and that is completely relevant to this 
> list.
> 
> Cheers, Steve.
> 
> 
> Berin Loritsch wrote:
> 
>>> From: news [mailto:news@main.gmane.org] On Behalf Of Andrew C. Oliver
>>>
>>>   
>>>
>>>>> Now, I'm dealing with a problem I already had with POI (we want to 
>>>>> avalonize it too probably).
>>>>>
>>>>>       
>>>>
>>> We do?  I don't.  Wrapper it with an avalon thing, but I'll -1 the 
>>> hell out of any attempt to make the bits and pieces avalonized.  And 
>>> I'll fly over to Italy and beat you (nkb) with a wet noodle if you 
>>> mark anything with LogEnabled in POI.  Its inappropriate IMHO in a 
>>> low level API.
>>>   
>>
>>
>> Andrew, there is no need to grandstand on this list.  If you want
>> to dispute the componentization of POI then do it on that list.
>> Do not spout your objections here, it is not the appropriate
>> list.
>>
>>
>>  
>>
>>> 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.
>>
>> 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.
>>
>>
>>  
>>
>>> 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?
>>
>>
>>  
>>
>>> 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?
>> We avoided 90% of the issues that caused Log4J and Commons Logging to
>> fail.  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).
>>
>>
>>  
>>
>>> 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.
>>
>>
>>  
>>
>>>> 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.
>>
>>
>>  
>>
>>> -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.
>>
>>
>> -- 
>> To unsubscribe, e-mail:   
>> <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
>> For additional commands, e-mail: 
>> <mailto:avalon-dev-help@jakarta.apache.org>
>>
>>  
>>
> 





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