You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Nicola Ken Barozzi <ni...@apache.org> on 2002/09/03 11:34:34 UTC
[FOP Avalonization] IoC the holy grail?
I'm doing some work on Avalonizing FOP, as it has been decided it's the
right way.
We are using already LogEnabled, and now it's time for Configuration,
but most important of all, usage of the SourceResolver.
Now, I'm dealing with a problem I already had with POI (we want to
avalonize it too probably).
When we have big object pacakge structures and classes, it becomes
somewhat impractical to use IoC.
For example, in POI there are tons of classes that represent portions of
the OLE2 file format.
Shall I have all of these become container-components?
Or in FOP: there needs to be an ImageFactoryService, but the problem is
that it needs to be used by projects deep in the call stack.
How can I make these components serviceable?
Should I?
It seems that when the model becomes too finegrained, the Avalon
patterns become difficult to use.
Comments, ideas?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [FOP Avalonization] IoC the holy grail?
Posted by "Andrew C. Oliver" <ac...@apache.org>.
+1 totally on unit tests. This is the chief path to quality and not
breaking things or having them break silently.
-andy
Paul Hammant wrote:
> Nicola,
>
> My only comment in addition to that of the others is that make sure you
> write unit tests for each component as you refactor. At work we have
> written a an AbstractPhoenixTestCase that pretends to be Pheonix for
> testing of a component. Now, that is just for Phoenix and perhaps you
> default impl for FOP should be a home-grown container tightly coupled to
> FOP and in FOP's codebase. Either way, if it is lifecycle aware, it
> will be similar to the AbstractPhoenixTestCase we wrote (but can't
> submit to Apache CVS). With Unit testing, or more accurately
> integration testing, you will be able to prove that as you refactor,
> things continue to work. It will help the bravery aspect drawn from XP.
>
> Good luck & will love to see the product.
>
> - Paul
>
>
>
>> I'm doing some work on Avalonizing FOP, as it has been decided it's
>> the right way.
>>
>> We are using already LogEnabled, and now it's time for Configuration,
>> but most important of all, usage of the SourceResolver.
>>
>> Now, I'm dealing with a problem I already had with POI (we want to
>> avalonize it too probably).
>>
>> When we have big object pacakge structures and classes, it becomes
>> somewhat impractical to use IoC.
>>
>> For example, in POI there are tons of classes that represent portions
>> of the OLE2 file format.
>> Shall I have all of these become container-components?
>>
>> Or in FOP: there needs to be an ImageFactoryService, but the problem
>> is that it needs to be used by projects deep in the call stack.
>>
>> How can I make these components serviceable?
>> Should I?
>>
>> It seems that when the model becomes too finegrained, the Avalon
>> patterns become difficult to use.
>>
>> Comments, ideas?
>>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [FOP Avalonization] IoC the holy grail?
Posted by Paul Hammant <Pa...@yahoo.com>.
Nicola,
My only comment in addition to that of the others is that make sure you
write unit tests for each component as you refactor. At work we have
written a an AbstractPhoenixTestCase that pretends to be Pheonix for
testing of a component. Now, that is just for Phoenix and perhaps you
default impl for FOP should be a home-grown container tightly coupled to
FOP and in FOP's codebase. Either way, if it is lifecycle aware, it
will be similar to the AbstractPhoenixTestCase we wrote (but can't
submit to Apache CVS). With Unit testing, or more accurately
integration testing, you will be able to prove that as you refactor,
things continue to work. It will help the bravery aspect drawn from XP.
Good luck & will love to see the product.
- Paul
> I'm doing some work on Avalonizing FOP, as it has been decided it's
> the right way.
>
> We are using already LogEnabled, and now it's time for Configuration,
> but most important of all, usage of the SourceResolver.
>
> Now, I'm dealing with a problem I already had with POI (we want to
> avalonize it too probably).
>
> When we have big object pacakge structures and classes, it becomes
> somewhat impractical to use IoC.
>
> For example, in POI there are tons of classes that represent portions
> of the OLE2 file format.
> Shall I have all of these become container-components?
>
> Or in FOP: there needs to be an ImageFactoryService, but the problem
> is that it needs to be used by projects deep in the call stack.
>
> How can I make these components serviceable?
> Should I?
>
> It seems that when the model becomes too finegrained, the Avalon
> patterns become difficult to use.
>
> Comments, ideas?
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [FOP Avalonization] IoC the holy grail?
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Peter Donald wrote:
> Ahh - forget everything I said. Berin said exactly what I wanted to
say but
> better! Drat it ;)
Naa, I didn't understand much at first.
Then I read yours, and I still wasn't convinced.
Then I went back to Berin's and understood =:-)
Anyway, my quick comments.
Peter Donald wrote:
> On Tue, 3 Sep 2002 19:34, Nicola Ken Barozzi wrote:
>
>>I'm doing some work on Avalonizing FOP, as it has been decided it's the
>>right way.
>>
>>We are using already LogEnabled, and now it's time for Configuration,
>>but most important of all, usage of the SourceResolver.
>>
>>Now, I'm dealing with a problem I already had with POI (we want to
>>avalonize it too probably).
>>
>>When we have big object pacakge structures and classes, it becomes
>>somewhat impractical to use IoC.
>>
>>For example, in POI there are tons of classes that represent portions of
>>the OLE2 file format.
>>Shall I have all of these become container-components?
>>
>>Or in FOP: there needs to be an ImageFactoryService, but the problem is
>>that it needs to be used by projects deep in the call stack.
>>
>>How can I make these components serviceable?
>>Should I?
>>
>>It seems that when the model becomes too finegrained, the Avalon
>>patterns become difficult to use.
>>
>>Comments, ideas?
>
>
> It is hard to give a good explanation without knowing either system well
> enough. However I would generally recomend that if it does not "feel" right
> to do something then it probably isn't.
:-) I am totally with you on this. It's true in life in general; look at
the equations of relativity, or even only the old
earth-center-of-the-universe debacle: when it's cool, it shows, when it
suffers, it shows.
> Which means you either needs some
> rearchitecturing of the application or need to not use Avalon at that level.
I was thinking of the latter.
> Let me use the POI components as an example. I know absolutely zero about them
> so ignore any of the glaring inaccuracies ;)
>
> The classes in POI represent bits of OLE2 file. Presumably they are passive
> (ie they just hold data) or they are reactive (they just "react" to method
> calls on them). In the first case, Avalon interfaces have no place being part
> of the object. In the second case I would tend to pass the relevent services
> in via the method parameters.
>
> So rather than
>
> OLEThingieMaJig tmj = ...;
> tmj.enableLogging( logger );
> tmj.service( sm );
> tmj.doStuff();
>
> I would do
>
> OLEThingieMaJig tmj = ...;
> tmj.doStuff( logger, sm );
>
> or preferrably
>
> OLEThingieMaJig tmj = ...;
> MyRequiredService myRequiredService = ...;
> tmj.doStuff( logger, myRequiredService );
>
> or maybe
>
> OLEThingieMaJig tmj = ...;
> MyRequiredService myRequiredService = ...;
> try
> {
> logger.debug( "Pre-doStuff" );
> tmj.doStuff( myRequiredService );
> logger.debug( "Post-doStuff" );
> }
> catch( SomeException se )
> {
> logger.debug( "Somexception occured!", se );
> }
>
> You will notice that the last version knows nothing about avalon. You will
> also notice that as I went down through the examples, less and less work was
> placed on the shoulders of the OLEComponent and more and more work was placed
> on the shoulders of container of OLEComponents.
>
> However this may seem like a lot of work - especially if there is no real
> notion of containers for the objects (or the containers are other
> OLEComponents).
Exactly!
> 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.
>
> So I guess my recomendation would be to separate passive (ie data holding) and
> active (ie behaviour orientated) objects and restrict your Avalonization to
> the active objects. If this is not possible for whatever reason I would tend
> to pass the needed resources into the behaviour bits (ie methods etc).
A kind of command-pattern.
> If that is still not possible then I would recomend creating another API layer
> for working with the low level components. Perhaps a good idea would be to
> use something like
>
> interface OLEContext
> {
> Object getMyMagicStuff();
> int getOtherStuff();
> String performMagic(String someParam);
> }
>
> OLEComponent.myMethod( OLEContext ctx );
Ah, nice.
A sort of pass the servicemanager-context in with the call.
It reduces the number of parameters and makes the method signatures
invariant with changes to the servicemanager-context methods.
> And after doing that for low level components would restrict avalonization to
> high level service orientated/or pluggable components.
Yup.
> Not sure if that hepled any?
Yeah, thanks :-)
You added the pass-the-service bit that I didn't get from Berin's post :-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [FOP Avalonization] IoC the holy grail?
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Andrew C. Oliver wrote:
...
> 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.
This is what we are all saying.
You got it ;-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [FOP Avalonization] IoC the holy grail?
Posted by Stephen McConnell <mc...@apache.org>.
Two issues:
(a) Cornerstone refernence to BlockContext - can be overcome by
addition of a type descriptor that declares the context type dependecies
in a container indepedent manner however Pete's -1 prevents me from
doing that - apparently Pete does not like anyone doing anything with
Cornerstone that isn't Phoenix specific and consitent with his long term
plans (see CVS hostory for details)
(b) There appears to be a bug in the file persistence - running the
James confiugration using the current Cornerstone fails - I have not
investigated because I'm sick to death of -1s and I've better things to
do with my time.
Cheers, Steve.
Berin Loritsch wrote:
>>From: Stephen McConnell [mailto:mcconnell@apache.org]
>>
>>Aside from that James CVS cannot run in Merlin using the current
>>cornerstone due to the -1s from Pete which is the reason why I'm
>>maintaining a fork of cornertone content so I can run James
>>indepedently
>>of Phoenix.
>>
>>
>>
>
>Stephen, have you tried to use the COmponentProxyGenerator in the
>Container package? You won't need the Component interface anymore.
>As to the descriptor issues, I can't help you.
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [FOP Avalonization] IoC the holy grail?
Posted by Berin Loritsch <bl...@apache.org>.
> From: Stephen McConnell [mailto:mcconnell@apache.org]
>
> Aside from that James CVS cannot run in Merlin using the current
> cornerstone due to the -1s from Pete which is the reason why I'm
> maintaining a fork of cornertone content so I can run James
> indepedently
> of Phoenix.
>
Stephen, have you tried to use the COmponentProxyGenerator in the
Container package? You won't need the Component interface anymore.
As to the descriptor issues, I can't help you.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [FOP Avalonization] IoC the holy grail?
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
>Andrew wrote:
>
>>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.
>>
>>
>
>Define by what you mean by switching the version of Avalon. DO you
>mean "Phoenix"? If so, then yes, JAMES was depending on Alpha software,
>which has no guarantees of compatibility across versions. Now that
>Phoenix has reached Beta status, you should not experience those issues
>anymore. Nine times out of ten, the fixes were simple.
>
>Anything else, and I would really like to know about it.
>
>
James depends on Avalon Framework, Corenerstone, Excalibur and Phoneix.
The James --> Framework dependency is ok - no problem.
The James --> Cornerstone dependency is broken .. try runnning current
cornerstone with James default config and it doesn't work.
The James --> Phoneix dependency is ok (and progressively moving to a
deployment concern and independent of a the main components)
The James --> Excalibur dependency is ok (ignoring the missing extension
jar depedency declarations across several excalibur projects)
Aside from that James CVS cannot run in Merlin using the current
cornerstone due to the -1s from Pete which is the reason why I'm
maintaining a fork of cornertone content so I can run James indepedently
of Phoenix.
I think that's the complete picture!
Cheers, Steve.
:-)
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [FOP Avalonization] IoC the holy grail?
Posted by Berin Loritsch <bl...@apache.org>.
> From: news [mailto:news@main.gmane.org] On Behalf Of Andrew C. Oliver
>
> 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.
If you intended your comments to be jovial, you should put the
visual clues in your email to suggest that. I found none to
clue me in.
> > 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.
That's fine. Your posts seemed to suggest that you would not even
consider
componentization even if it made sense. That IMNSHO is a rediculous
stance. Be objective. Honestly, I have no clue what the POI API looks
like. I offered some pertinent points that proved that most of POI
wouldn't
benefit from componentization, however I made some room for the fact
that
there may be room for some components within POI.
> > 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.
Again, that comment was to prove that you don't need Avalon to use
components.
Components are built on the Bridge pattern which identifies *interfaces*
that
an implementation must satisfy. The client uses the Interface and not
the
implementation. There is more, but you are not limited to Avalon to use
components. There are several component architectures to choose from,
but
there comes a point of diminishing returns. Components do not work well
for
representing data/documents/information. It would be foolish to try to
make
it work.
Deciding which portions of the API should be moved out into "services"
is
the point of "more robust design". Whether they are implemented in a
"Role Your Own" component architecture or Avalon is irrelevant.
> >>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.
It's the 10% that relates to misuse, or improperly specified
things. We are addressing as much as we can.
> > 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.
Define by what you mean by switching the version of Avalon. DO you
mean "Phoenix"? If so, then yes, JAMES was depending on Alpha software,
which has no guarantees of compatibility across versions. Now that
Phoenix has reached Beta status, you should not experience those issues
anymore. Nine times out of ten, the fixes were simple.
Anything else, and I would really like to know about it.
> > 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?
Are you sure I am saying it must be Avalonized?
> Normally I like/respect you alot Berin but someone really
> pee'd in your
> sanka today.
probably true ;P
> 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.
Yes, but it can't use things that are already Avalon components.
For instance, if you wanted it to be able to pull a resource from
the SourceResolver, you wouldn't be able to without some complex
wrapping code.
The SourceResolver does help to allow an application to add new
protocol types easily that POI/Tarrif resolution system wouldn't
know about or otherwise use. Something like that requires the
ability to have your wrapper to replace certain pieces in your
API regarding URI resolution. If you do not plan ahead for that
possibility, then you will code yourself into a corner, and
then you make it really difficult to use your software in another
context.
> 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.
Again, I did not say POI should use Avalon. Nor did I say POI
*should* use components. I did offer advice that would help *if*
POI/whatever app used components--regardless of whether it created
its own component architecture or reused one that exists already.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [FOP Avalonization] IoC the holy grail?
Posted by "Andrew C. Oliver" <ac...@apache.org>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [FOP Avalonization] IoC the holy grail?
Posted by Berin Loritsch <bl...@apache.org>.
> From: news [mailto:news@main.gmane.org] On Behalf Of Andrew C. Oliver
>
> Debugging applications with thick ancestry is a laborious task. But
> that gets into Cocoon and Cocoon is in may ways (don't get me wrong I
> love Cocoon) the ultimate Avalon Anti-pattern.
On this point we agree. However, sometimes it takes making mistakes
to learn better ways of doing things. It also takes a keen eye to
determine
how to best fix the problem while still providing backwards
compatibility.
In many ways it can be done, in other ways it requires some things to be
changed in backwards incompatible ways.
Good tools to help with debugging are proper use of logging,
instrumentation,
and a good debugger that lets you step through your software. Avalon
does
have tools to make logging and instrumentation happen, but the debugger
is
out of its control. Does that mean you have to use Avalon? no. Does
it
mean that Avalon is the best thing since sliced bread? For many
applications
I think it is, but there are several applications where it is
ill-suited.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [FOP Avalonization] IoC the holy grail?
Posted by "Andrew C. Oliver" <ac...@apache.org>.
>>>> 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.
>>>
>
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> A bit strong, huh?
>
Thats because I was talking to you. It was totally in jest.
>> surely I must have been sleep deprived. I don't remember the
>> conversation, but I believe you. There are some blackout periods that
>> I barely remember. (like those days where I was sorting through the
>> Cocoon code at the mess of gazillion interfaces and dependancies
>> trying to debug some little nuiance)
>
>
> No, it's because you don't give a damn about logging, and never got
> interested about it.
> Not that you should BTW.
>
No the dependency trees are pretty thick and I sure as heck haven't been
able to configure logging reliably so thats true. (That would go to my
other issue which I'll do everyone a favor and keep to myself).
Debugging applications with thick ancestry is a laborious task. But
that gets into Cocoon and Cocoon is in may ways (don't get me wrong I
love Cocoon) the ultimate Avalon Anti-pattern.
-Andy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [FOP Avalonization] IoC the holy grail?
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Andrew C. Oliver wrote:
>
>>>
>>> We do? I don't. Wrapper it with an avalon thing, but I'll -1 the hell
>>
>>
>>
>> Shut up, Andrew, I know all this, you know all this, in fact this is
>> what the thread is all about: Avalon makes sense for Services, and POI
>> is a Services but NOT made on services.
>>
>> Don't worry.
>>
>
> Then I must have totally misunderstood the conversation. Boy man. I
> love this community... its the ultimate flamefest. Over the past month
> you chew up peter. I see an issue I care about (the "lets avalonize
> EVERYTHING and have one huge dependency tree from h*ll" issue), say
> something and Berin verbally flogs me. I extend your example and I'm
> off topic. Sorry that a non-club member posted. Go back to your
> regular programming. To think someone gave a talk on services to the
> our jug the other night and I was like "Dude you must get involved in
> avalon" -- I think I'll revise that to "leech but don't dare post on
> any issue" next time I see him. gosh.
>>> 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.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
A bit strong, huh?
>> Gee, man, I did it before, it was shit, I changed it to our wrapper
>> again.
>> See, I'm innocent!
>>
>> It was you that asked to alavonize it, and I came to the conclusion
>> that it didn't make sense low level.
>> No news under the sun.
>>
>
> surely I must have been sleep deprived. I don't remember the
> conversation, but I believe you. There are some blackout periods that I
> barely remember. (like those days where I was sorting through the
> Cocoon code at the mess of gazillion interfaces and dependancies trying
> to debug some little nuiance)
No, it's because you don't give a damn about logging, and never got
interested about it.
Not that you should BTW.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [FOP Avalonization] IoC the holy grail?
Posted by "Andrew C. Oliver" <ac...@apache.org>.
>>
>> We do? I don't. Wrapper it with an avalon thing, but I'll -1 the hell
>
>
> Shut up, Andrew, I know all this, you know all this, in fact this is
> what the thread is all about: Avalon makes sense for Services, and POI
> is a Services but NOT made on services.
>
> Don't worry.
>
Then I must have totally misunderstood the conversation. Boy man. I
love this community... its the ultimate flamefest. Over the past month
you chew up peter. I see an issue I care about (the "lets avalonize
EVERYTHING and have one huge dependency tree from h*ll" issue), say
something and Berin verbally flogs me. I extend your example and I'm
off topic. Sorry that a non-club member posted. Go back to your
regular programming. To think someone gave a talk on services to the
our jug the other night and I was like "Dude you must get involved in
avalon" -- I think I'll revise that to "leech but don't dare post on
any issue" next time I see him. gosh.
>> 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.
>
>
> Gee, man, I did it before, it was shit, I changed it to our wrapper again.
> See, I'm innocent!
>
> It was you that asked to alavonize it, and I came to the conclusion that
> it didn't make sense low level.
> No news under the sun.
>
surely I must have been sleep deprived. I don't remember the
conversation, but I believe you. There are some blackout periods that I
barely remember. (like those days where I was sorting through the
Cocoon code at the mess of gazillion interfaces and dependancies trying
to debug some little nuiance)
> <snip/>
>
>> NOT everything tht CAN be avalonized should be.
>
>
> The nail, the hammer...
>
The screw, nut or bolt, the hammer...
> > Less is more.
>
> Nonsense sentence.
>
no.. cliche.
-Andy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [FOP Avalonization] IoC the holy grail?
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Andrew C. Oliver wrote:
> (cc: stefano because I used his name in vane)
>
> Peter Donald wrote:
>
>> On Tue, 3 Sep 2002 19:34, Nicola Ken Barozzi wrote:
>>
>>> I'm doing some work on Avalonizing FOP, as it has been decided it's the
>>> right way.
>>>
>>> We are using already LogEnabled, and now it's time for Configuration,
>>> but most important of all, usage of the SourceResolver.
>>>
>>> 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
Shut up, Andrew, I know all this, you know all this, in fact this is
what the thread is all about: Avalon makes sense for Services, and POI
is a Services but NOT made on services.
Don't worry.
> 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.
Gee, man, I did it before, it was shit, I changed it to our wrapper again.
See, I'm innocent!
It was you that asked to alavonize it, and I came to the conclusion that
it didn't make sense low level.
No news under the sun.
<snip/>
> NOT everything tht CAN be avalonized should be.
The nail, the hammer...
> Less is more.
Nonsense sentence.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [FOP Avalonization] IoC the holy grail?
Posted by "Andrew C. Oliver" <ac...@apache.org>.
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:
>> <ma...@jakarta.apache.org>
>> For additional commands, e-mail:
>> <ma...@jakarta.apache.org>
>>
>>
>>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [FOP Avalonization] IoC the holy grail?
Posted by "Andrew C. Oliver" <ac...@apache.org>.
> also FWIW, I think the whole thread (perhaps minus the misunderstood but in
> some properly decomponentized communication system definately marked as
> <type><subjective>hilarious</subjective></type> pasta comments) should be on
> avalon-users rather than here.
>
> -- absolutely no serious remarks beyond this line --
>
> Finally, I think we should all wait with answering these questions until
> Berin's book comes out (I've read a bit); 90% of answers will no doubt be in
> there and flames will not be neccessary...though if nicola ever does get buried
> in noodles I want to see the pictures! =)
>
Oh that would be nice. The thing about NKB though is he'd probably like
that. :-p
> cheers,
>
> - Leo, via webmail
>
> PS: I feel Andrew's comments in this thread have been 90% appropriate (though
> the 10% may cause problems with the log4j community), but I do in fact feel
> that by my dictionary "Andrew's opinions" is too generic a term to mark them as
> completely appropriate on this list. I for one am sure some of you may take
> personal offence to his remarks on beer :D
>
If Log4J thinks having an API tied to Log4J is a good idea and than I
have about 100 emails that say otherwise.
American standard domestic beer (coors, budweiser, etc) is fermented
rice mixed with horse urine and an extra helping of water.
But I have even better more controversial opinions on Wine and Scotch
which could offend a much larger percentage of the populace. See some
here: http://www.trilug.org/~acoliver/
> PPS: yes, it has been a long day. Sorry.
>
> PPPS: perhaps we should instead all fly over to Italy (I suggest Berin's
> publisher pays my ticket given recent propagandic remarks) to listen to Andy's
> remarks on beer. Could maybe help us all cheer up a bit...
Yes... Me too!
On a more serious but still off topic note... How many of you folks are
coming to the Apachecon? I'm trying to spring for it.. . (though its
actually cheaper to fly to italy than vegas...long story)
-Andy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [FOP Avalonization] IoC the holy grail?
Posted by le...@apache.org.
Quoting Stephen McConnell <mc...@apache.org>:
>
> For what its worth - I think Andrew's opinions are completely
> appropriate for this list.
also FWIW, I think the whole thread (perhaps minus the misunderstood but in
some properly decomponentized communication system definately marked as
<type><subjective>hilarious</subjective></type> pasta comments) should be on
avalon-users rather than here.
-- absolutely no serious remarks beyond this line --
Finally, I think we should all wait with answering these questions until
Berin's book comes out (I've read a bit); 90% of answers will no doubt be in
there and flames will not be neccessary...though if nicola ever does get buried
in noodles I want to see the pictures! =)
cheers,
- Leo, via webmail
PS: I feel Andrew's comments in this thread have been 90% appropriate (though
the 10% may cause problems with the log4j community), but I do in fact feel
that by my dictionary "Andrew's opinions" is too generic a term to mark them as
completely appropriate on this list. I for one am sure some of you may take
personal offence to his remarks on beer :D
PPS: yes, it has been a long day. Sorry.
PPPS: perhaps we should instead all fly over to Italy (I suggest Berin's
publisher pays my ticket given recent propagandic remarks) to listen to Andy's
remarks on beer. Could maybe help us all cheer up a bit...
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [FOP Avalonization] IoC the holy grail?
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Stephen McConnell [mailto:mcconnell@apache.org]
>
> For what its worth - I think Andrew's opinions are completely
> appropriate for this list.
>
> ...
>
> the subject is dealing with Avalon boundaries and that is
> completely relevant to this list.
Agreed.
And my $2M (adjusted for inflation):
As one who has seen FOP from the inside, I'd go for a more
componentized model - but keep all interfaces etc. within FOP -
don't add a dependency on Avalon/Framework. That'd give you the
advantages of a componentized model but without the extra
baggage of dependencies.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [FOP Avalonization] IoC the holy grail?
Posted by Stephen McConnell <mc...@apache.org>.
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: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [FOP Avalonization] IoC the holy grail?
Posted by Berin Loritsch <bl...@apache.org>.
> 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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [FOP Avalonization] IoC the holy grail?
Posted by "Andrew C. Oliver" <ac...@apache.org>.
(cc: stefano because I used his name in vane)
Peter Donald wrote:
> On Tue, 3 Sep 2002 19:34, Nicola Ken Barozzi wrote:
>
>>I'm doing some work on Avalonizing FOP, as it has been decided it's the
>>right way.
>>
>>We are using already LogEnabled, and now it's time for Configuration,
>>but most important of all, usage of the SourceResolver.
>>
>>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.
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)
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)
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.
So in short APIs stay APIs. Things which need them as components get
component wrappers. The dependancy tree stays clean.
>
> 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.
> So I guess my recomendation would be to separate passive (ie data holding) and
> active (ie behaviour orientated) objects and restrict your Avalonization to
> the active objects. If this is not possible for whatever reason I would tend
> to pass the needed resources into the behaviour bits (ie methods etc).
>
> If that is still not possible then I would recomend creating another API layer
> for working with the low level components. Perhaps a good idea would be to
> use something like
>
> interface OLEContext
> {
> Object getMyMagicStuff();
> int getOtherStuff();
> String performMagic(String someParam);
> }
>
> OLEComponent.myMethod( OLEContext ctx );
>
> And after doing that for low level components would restrict avalonization to
> high level service orientated/or pluggable components.
>
> Not sure if that hepled any?
>
-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.
-Andy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [FOP Avalonization] IoC the holy grail?
Posted by Peter Donald <pe...@apache.org>.
On Tue, 3 Sep 2002 19:34, Nicola Ken Barozzi wrote:
> I'm doing some work on Avalonizing FOP, as it has been decided it's the
> right way.
>
> We are using already LogEnabled, and now it's time for Configuration,
> but most important of all, usage of the SourceResolver.
>
> Now, I'm dealing with a problem I already had with POI (we want to
> avalonize it too probably).
>
> When we have big object pacakge structures and classes, it becomes
> somewhat impractical to use IoC.
>
> For example, in POI there are tons of classes that represent portions of
> the OLE2 file format.
> Shall I have all of these become container-components?
>
> Or in FOP: there needs to be an ImageFactoryService, but the problem is
> that it needs to be used by projects deep in the call stack.
>
> How can I make these components serviceable?
> Should I?
>
> It seems that when the model becomes too finegrained, the Avalon
> patterns become difficult to use.
>
> Comments, ideas?
It is hard to give a good explanation without knowing either system well
enough. However I would generally recomend that if it does not "feel" right
to do something then it probably isn't. Which means you either needs some
rearchitecturing of the application or need to not use Avalon at that level.
Let me use the POI components as an example. I know absolutely zero about them
so ignore any of the glaring inaccuracies ;)
The classes in POI represent bits of OLE2 file. Presumably they are passive
(ie they just hold data) or they are reactive (they just "react" to method
calls on them). In the first case, Avalon interfaces have no place being part
of the object. In the second case I would tend to pass the relevent services
in via the method parameters.
So rather than
OLEThingieMaJig tmj = ...;
tmj.enableLogging( logger );
tmj.service( sm );
tmj.doStuff();
I would do
OLEThingieMaJig tmj = ...;
tmj.doStuff( logger, sm );
or preferrably
OLEThingieMaJig tmj = ...;
MyRequiredService myRequiredService = ...;
tmj.doStuff( logger, myRequiredService );
or maybe
OLEThingieMaJig tmj = ...;
MyRequiredService myRequiredService = ...;
try
{
logger.debug( "Pre-doStuff" );
tmj.doStuff( myRequiredService );
logger.debug( "Post-doStuff" );
}
catch( SomeException se )
{
logger.debug( "Somexception occured!", se );
}
You will notice that the last version knows nothing about avalon. You will
also notice that as I went down through the examples, less and less work was
placed on the shoulders of the OLEComponent and more and more work was placed
on the shoulders of container of OLEComponents.
However this may seem like a lot of work - especially if there is no real
notion of containers for the objects (or the containers are other
OLEComponents).
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.
So I guess my recomendation would be to separate passive (ie data holding) and
active (ie behaviour orientated) objects and restrict your Avalonization to
the active objects. If this is not possible for whatever reason I would tend
to pass the needed resources into the behaviour bits (ie methods etc).
If that is still not possible then I would recomend creating another API layer
for working with the low level components. Perhaps a good idea would be to
use something like
interface OLEContext
{
Object getMyMagicStuff();
int getOtherStuff();
String performMagic(String someParam);
}
OLEComponent.myMethod( OLEContext ctx );
And after doing that for low level components would restrict avalonization to
high level service orientated/or pluggable components.
Not sure if that hepled any?
--
Cheers,
Peter Donald
Doubt is not a pleasant condition, but certainty is absurd.
-- Voltaire
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [FOP Avalonization] IoC the holy grail?
Posted by "Andrew C. Oliver" <ac...@apache.org>.
>>For example, in POI there are tons of classes that represent
>>portions of
>>the OLE2 file format.
>>Shall I have all of these become container-components?
>
>
> There is no reason for that. It is your Document Object Model
>
>
You know in 3.0 I'm thinking about making all of these builders of
sorts. Meaning: NO gazillion instances of NumberRecord or
LabelSSTRecord, instead you'll have one instance (that you can keep or
throw away) operating on some manner of memory grab bag which will store
bytes. Or possibly a single CellValueManager which stores a few
parallel arrays for the properties of hte cells. It would only be
objectified during serialization and only for an instant (and maybe not
even then --- combine the two above).
We didn't do this for 2.0 because it will be holy hell to debug, so I
only want to do it once our featureset is mature (meaning graphs,
formulas and everything in between).. We'll be there by the end of the
lingering on 2.0 schedule.
>
>>How can I make these components serviceable?
>
>
> Do not make services out of objects.
>
>
>>Should I?
>
>
> No.
>
Agree that its totally silly to make bits and pieces of APIs like POI
and (guessing without familiarity) FOP into components.
My thought would be that one could make an interface (not a Java
interface I mean some kind of wrapper or something) to HSSF a component,
but not any part of POI.
And for the record anything like that would end up in the contrib
because there is no sense to create a dependancy on avalon for such a
thing. (I realize you just were making an example but I felt the need
to elaborate)
>
>
>>It seems that when the model becomes too finegrained, the Avalon
>>patterns become difficult to use.
>
>
> That is because you are thinking in pure OO terms. You need to
> stretch and think in terms of services/components.
>
The process of taking in an input and outputting Excel or other formats
could be thought of as a service.
The thing that does the actual output that must be manipulated by the
service and its deligates could be thought of as a component. (the
wrapper around POI if you think there is a need to do so)
At least thats my thinking. (But I'm not an Avalon-genius)
-Andy
>
>>Comments, ideas?
>
>
> See above.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [FOP Avalonization] IoC the holy grail?
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Leo Simons wrote:
>>-----Oorspronkelijk bericht-----
>>Van: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
...
>>It seems that when the model becomes too finegrained, the Avalon
>>patterns become difficult to use.
>>
>>Comments, ideas?
>
>
> Especially when dealing with existing systems, this can become a
> problem. Most programmers maintain some kind of clean organisation
> at the coarse level and then 'mess up' further down the road. In
> order to do effective IoC, you first need good SoC.
>
> Not being familiar with POI or FOP internals, I can't really do
> a good analysis here. I'd suggest doing avalonization of the
> coarse components first (ie what you would make into 'blocks'),
> maintaining the 'lack of rigid structure' in the finer-grained
> subsystems. It might not be beneficial at all (or worth the effort)
> to avalonize these projects completely.
What I have experienced in the logging effort.
We tried to pass loggers round using the object hierarchy - please
forgive me! ;-) - and you can imagine how it went.
We now use a static logger, using our own Facade on top of commons logging.
In this way via a system property it's easy to enable simple system.out
or use commons logging, and remaon separated from other logging stuff in
the system.
> If you end up with lots of really small components that (for
> example) all depend on an ImageFactoryService, it probably makes
> more sense to have something like
>
> ImageCreatorRegistry
> {
> ImageFactoryService m_ifs;
>
> service( ServiceManager sm )
> {
> m_ifs = (ImageFactoryService)sm.lookup(
> ImageFactoryService.ROLE);
> }
>
> ImageCreator getImageCreator(ImageCreator.ThisKindPlease tkp)
> {
> return new ImageCreator( m_ifs, tkp );
> }
> }
>
> though the above makes no sense at all to me (no idea how what code
> uses what kind of factory to do something) it isn't a violation of
> IoC =)
Well, it's a factory.
The problem is that using FOP in a server environment, each instance
needs to have its own resolving strategies.
So I would ask for a ImageCreator via a ImageCreator.ThisKindPlease.
I am actively asking for a specific kind of ImageCreator, which means
that the registry needs to be smart...
Again a third option, thanks :-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [FOP Avalonization] IoC the holy grail?
Posted by Leo Simons <le...@apache.org>.
> -----Oorspronkelijk bericht-----
> Van: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
> Verzonden: dinsdag 3 september 2002 11:35
> Aan: Avalon Developers List
> Onderwerp: [FOP Avalonization] IoC the holy grail?
>
> I'm doing some work on Avalonizing FOP, as it has been
> decided it's the
> right way.
great wisdom, you have shown =)
> Now, I'm dealing with a problem I already had with POI (we want to
> avalonize it too probably).
>
> When we have big object pacakge structures and classes, it becomes
> somewhat impractical to use IoC.
Hmm.
> For example, in POI there are tons of classes that represent
> portions of
> the OLE2 file format.
> Shall I have all of these become container-components?
Nope. Not everything is a component, or should be. I always suggest
that data representation is not made into components. If your
definition for component is "a passive entity that performs a
specific role", it should quickly become clear that things that
do not perform a specific role should not be component.
> Or in FOP: there needs to be an ImageFactoryService, but the
> problem is
> that it needs to be used by projects deep in the call stack.
>
> How can I make these components serviceable?
Are they components? If they are, you should be able to chuck
them into a container easily enough that supports Servicable.
You can also do
MyComponentImpl
{
service( ServiceManager sm )
{
myNonComponentButServicable.service(sm);
my2ndNonComponentButServicable.service(sm);
}
}
if it really doesn't make sense to use a 'real' container,
but that probably indicates you shouldn't use Servicable
Either.
> Should I?
Can't say at all in this case. What do you mean by "project"?
> It seems that when the model becomes too finegrained, the Avalon
> patterns become difficult to use.
>
> Comments, ideas?
Especially when dealing with existing systems, this can become a
problem. Most programmers maintain some kind of clean organisation
at the coarse level and then 'mess up' further down the road. In
order to do effective IoC, you first need good SoC.
Not being familiar with POI or FOP internals, I can't really do
a good analysis here. I'd suggest doing avalonization of the
coarse components first (ie what you would make into 'blocks'),
maintaining the 'lack of rigid structure' in the finer-grained
subsystems. It might not be beneficial at all (or worth the effort)
to avalonize these projects completely.
If you end up with lots of really small components that (for
example) all depend on an ImageFactoryService, it probably makes
more sense to have something like
ImageCreatorRegistry
{
ImageFactoryService m_ifs;
service( ServiceManager sm )
{
m_ifs = (ImageFactoryService)sm.lookup(
ImageFactoryService.ROLE);
}
ImageCreator getImageCreator(ImageCreator.ThisKindPlease tkp)
{
return new ImageCreator( m_ifs, tkp );
}
}
though the above makes no sense at all to me (no idea how what code
uses what kind of factory to do something) it isn't a violation of
IoC =)
cheers,
Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [FOP Avalonization] IoC the holy grail?
Posted by Peter Donald <pe...@apache.org>.
Ahh - forget everything I said. Berin said exactly what I wanted to say but
better! Drat it ;)
On Tue, 3 Sep 2002 22:58, Berin Loritsch wrote:
> > From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
> >
> > I'm doing some work on Avalonizing FOP, as it has been
> > decided it's the
> > right way.
> >
> > We are using already LogEnabled, and now it's time for Configuration,
> > but most important of all, usage of the SourceResolver.
> >
> > Now, I'm dealing with a problem I already had with POI (we want to
> > avalonize it too probably).
> >
> > When we have big object pacakge structures and classes, it becomes
> > somewhat impractical to use IoC.
>
> Keep in mind what the purpose of services and information are. A
> service acts on information, provides information, or changes
> information.
>
> In both FOP and POI, you have a complex document format, and relatively
> few services. That is fine. Let your services focus on *doing*,
> and your document format focus on representing the document.
>
> One of the issues with trying to componentize (which is what you
> are really talking about) is that too many people try to make
> the *document* or *information* into components. Those don't make
> good components--and you are finally finding out the hard way why
> not.
>
> The ResourceManager works by fetching information so that you can
> use it and interpret it or embed it in your finished document.
>
> What you want is a DocumentBuilder service (or something like that)
> that will be the entry point for FOP/POI, that will generate a
> document in a stream format. In fact you guys might be able to
> come up with the same interface. No matter how you decide to do it,
> you will most likely deploy the "builder" pattern.
>
> In FOP you would typically have an adaptor that writes the information
> to the stream, as well as a builder that assembles the document from
> the incomming XSL:FO document. Beyond that, the internal services that
> you would use might vary tremendously.
>
> The best rule of thumb is to focus on the services acting on your
> document model. And above all DO NOT HAVE an ACTIVE document model.
> The Document should be passive, built by external services, or altered
> the same way.
>
> > For example, in POI there are tons of classes that represent
> > portions of
> > the OLE2 file format.
> > Shall I have all of these become container-components?
>
> There is no reason for that. It is your Document Object Model
>
> > Or in FOP: there needs to be an ImageFactoryService, but the
> > problem is
> > that it needs to be used by projects deep in the call stack.
>
> I assume by "projects" that you are referring to "objects".
>
> Like I said above, adopt a proper design pattern like the "builder"
> pattern, and when the time comes for the ImageFactoryService to
> be used, the builder accesses it. Or perhaps it is not the builder
> that uses it, but the adaptor that serializes the information to
> a stream. Either way, it is used by the proper service.
>
> > How can I make these components serviceable?
>
> Do not make services out of objects.
>
> > Should I?
>
> No.
>
> > It seems that when the model becomes too finegrained, the Avalon
> > patterns become difficult to use.
>
> That is because you are thinking in pure OO terms. You need to
> stretch and think in terms of services/components.
>
> > Comments, ideas?
>
> See above.
--
Cheers,
Peter Donald
----------------------------------------
Whatever you do will be insignificant,
but it is very important that you do it.
--Gandhi
----------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [FOP Avalonization] IoC the holy grail?
Posted by Peter Donald <pe...@apache.org>.
On Tue, 3 Sep 2002 23:14, Nicola Ken Barozzi wrote:
> Ah, ok.
> The fact is that The OM is basically reactive, in a sense that the data
> structure is able to reply to methods, which are used by the builder via
> a common interface for all objects.
>
> How do these methods get hold of common library services?
>
> The common solution is use of static stuff, like in log4j, where to log
> inside these data structures I get a logger via the static method.
>
> It's a cross-cutting concern, so I cross-cut the hierarchy via static
> methods.
Sounds like a perfect case for visitors or similar ;)
--
Cheers,
Peter Donald
--------------------------------------------
Beer is proof that God loves us and wants
us to be happy. -- Benjamin Franklin
--------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [FOP Avalonization] IoC the holy grail?
Posted by Berin Loritsch <bl...@apache.org>.
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
>
> Berin Loritsch wrote:
> >
> > Keep in mind what the purpose of services and information are. A
> > service acts on information, provides information, or changes
> > information.
> >
> > In both FOP and POI, you have a complex document format, and
> > relatively few services. That is fine. Let your services focus on
> > *doing*, and your document format focus on representing the
> document.
>
> Yes, but object shave methods, not only data...
However what do those methods do? Do they add a new document portion,
remove it, or something more complex?
If it is a service, it probably needs to be factored out.
<snip/>
> Ah, ok.
> The fact is that The OM is basically reactive, in a sense
> that the data
> structure is able to reply to methods, which are used by the
> builder via
> a common interface for all objects.
Pretty much.
> How do these methods get hold of common library services?
They don't. The services are performed on behalf of the object
model by the parent service. When the document fragment is
built, it is attached. That means for some types of fragments
like images, you have to have an image descriptor so that the
Adaptor service at the end so that the adaptor knows how to
retrieve the real resource.
> The common solution is use of static stuff, like in log4j,
> where to log
> inside these data structures I get a logger via the static method.
>
> It's a cross-cutting concern, so I cross-cut the hierarchy via static
> methods.
It's a common thing to do, however you do need to be careful with
statics. Statics are the antonym of components. Components protect
against refactoring because you work with known interfaces, and
encapsulate logic neatly. Statics hinder refactoring because there
are always undocumented dependencies on the static. Once you
change a static to non-static you will find that no matter how
religious you were about documenting the dependencies, you will
find that the changes are more far-reaching than you expect.
So what to do?
Use "descriptors" or enable fragmenting the document so that you can
build the parts in pieces and reassemble them later when necessary.
The output adaptor is reactive in that it responds to the document
model, and converts it to a stream. If you use "descriptor" objects,
you can delay things like grabbing an image until you need to serialize
it. You can also deploy a document "validator" service to ensure
everything needed for the document is there.
> > Like I said above, adopt a proper design pattern like the "builder"
> > pattern, and when the time comes for the ImageFactoryService to be
> > used, the builder accesses it.
>
> Ahhh...
>
> > Or perhaps it is not the builder
> > that uses it, but the adaptor that serializes the information to a
> > stream. Either way, it is used by the proper service.
>
> Now I get your idea better...
> Instead of
>
> method(unresolvedparam){
> resolved = getService().resolve(unresolvedparam)
> use(resolved);
> }
>
> I should do
>
> method(resolved ){
> use(resolved);
> }
>
> :-D
Yep. Or even better, your service acts on the document model,
and the document model only holds information!
> >>How can I make these components serviceable?
> >
> > Do not make services out of objects.
>
> IE, objects shouldn't use services at all.
Pretty much.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [FOP Avalonization] IoC the holy grail?
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Berin Loritsch wrote:
>>From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
>>
>>I'm doing some work on Avalonizing FOP, as it has been
>>decided it's the
>>right way.
>>
>>We are using already LogEnabled, and now it's time for Configuration,
>>but most important of all, usage of the SourceResolver.
>>
>>Now, I'm dealing with a problem I already had with POI (we want to
>>avalonize it too probably).
>>
>>When we have big object pacakge structures and classes, it becomes
>>somewhat impractical to use IoC.
>
>
> Keep in mind what the purpose of services and information are. A
> service acts on information, provides information, or changes
> information.
>
> In both FOP and POI, you have a complex document format, and relatively
> few services. That is fine. Let your services focus on *doing*,
> and your document format focus on representing the document.
Yes, but object shave methods, not only data...
> One of the issues with trying to componentize (which is what you
> are really talking about) is that too many people try to make
> the *document* or *information* into components. Those don't make
> good components--and you are finally finding out the hard way why
> not.
>
> The ResourceManager works by fetching information so that you can
> use it and interpret it or embed it in your finished document.
>
> What you want is a DocumentBuilder service (or something like that)
> that will be the entry point for FOP/POI, that will generate a
> document in a stream format. In fact you guys might be able to
> come up with the same interface. No matter how you decide to do it,
> you will most likely deploy the "builder" pattern.
>
> In FOP you would typically have an adaptor that writes the information
> to the stream, as well as a builder that assembles the document from
> the incomming XSL:FO document. Beyond that, the internal services that
> you would use might vary tremendously.
>
> The best rule of thumb is to focus on the services acting on your
> document model. And above all DO NOT HAVE an ACTIVE document model.
> The Document should be passive, built by external services, or altered
> the same way.
Ah, ok.
The fact is that The OM is basically reactive, in a sense that the data
structure is able to reply to methods, which are used by the builder via
a common interface for all objects.
How do these methods get hold of common library services?
The common solution is use of static stuff, like in log4j, where to log
inside these data structures I get a logger via the static method.
It's a cross-cutting concern, so I cross-cut the hierarchy via static
methods.
>>For example, in POI there are tons of classes that represent
>>portions of
>>the OLE2 file format.
>>Shall I have all of these become container-components?
>
> There is no reason for that. It is your Document Object Model
This is what I thought of too, now I'm more confident it's right :-)
>>Or in FOP: there needs to be an ImageFactoryService, but the
>>problem is
>>that it needs to be used by projects deep in the call stack.
>
> I assume by "projects" that you are referring to "objects".
Yup.
> Like I said above, adopt a proper design pattern like the "builder"
> pattern, and when the time comes for the ImageFactoryService to
> be used, the builder accesses it.
Ahhh...
> Or perhaps it is not the builder
> that uses it, but the adaptor that serializes the information to
> a stream. Either way, it is used by the proper service.
Now I get your idea better...
Instead of
method(unresolvedparam){
resolved = getService().resolve(unresolvedparam)
use(resolved);
}
I should do
method(resolved ){
use(resolved);
}
:-D
>>How can I make these components serviceable?
>
> Do not make services out of objects.
IE, objects shouldn't use services at all.
>>Should I?
>
> No.
>
>>It seems that when the model becomes too finegrained, the Avalon
>>patterns become difficult to use.
>
>
> That is because you are thinking in pure OO terms. You need to
> stretch and think in terms of services/components.
:-D
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [FOP Avalonization] IoC the holy grail?
Posted by Berin Loritsch <bl...@apache.org>.
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
>
> I'm doing some work on Avalonizing FOP, as it has been
> decided it's the
> right way.
>
> We are using already LogEnabled, and now it's time for Configuration,
> but most important of all, usage of the SourceResolver.
>
> Now, I'm dealing with a problem I already had with POI (we want to
> avalonize it too probably).
>
> When we have big object pacakge structures and classes, it becomes
> somewhat impractical to use IoC.
Keep in mind what the purpose of services and information are. A
service acts on information, provides information, or changes
information.
In both FOP and POI, you have a complex document format, and relatively
few services. That is fine. Let your services focus on *doing*,
and your document format focus on representing the document.
One of the issues with trying to componentize (which is what you
are really talking about) is that too many people try to make
the *document* or *information* into components. Those don't make
good components--and you are finally finding out the hard way why
not.
The ResourceManager works by fetching information so that you can
use it and interpret it or embed it in your finished document.
What you want is a DocumentBuilder service (or something like that)
that will be the entry point for FOP/POI, that will generate a
document in a stream format. In fact you guys might be able to
come up with the same interface. No matter how you decide to do it,
you will most likely deploy the "builder" pattern.
In FOP you would typically have an adaptor that writes the information
to the stream, as well as a builder that assembles the document from
the incomming XSL:FO document. Beyond that, the internal services that
you would use might vary tremendously.
The best rule of thumb is to focus on the services acting on your
document model. And above all DO NOT HAVE an ACTIVE document model.
The Document should be passive, built by external services, or altered
the same way.
> For example, in POI there are tons of classes that represent
> portions of
> the OLE2 file format.
> Shall I have all of these become container-components?
There is no reason for that. It is your Document Object Model
> Or in FOP: there needs to be an ImageFactoryService, but the
> problem is
> that it needs to be used by projects deep in the call stack.
I assume by "projects" that you are referring to "objects".
Like I said above, adopt a proper design pattern like the "builder"
pattern, and when the time comes for the ImageFactoryService to
be used, the builder accesses it. Or perhaps it is not the builder
that uses it, but the adaptor that serializes the information to
a stream. Either way, it is used by the proper service.
> How can I make these components serviceable?
Do not make services out of objects.
> Should I?
No.
> It seems that when the model becomes too finegrained, the Avalon
> patterns become difficult to use.
That is because you are thinking in pure OO terms. You need to
stretch and think in terms of services/components.
> Comments, ideas?
See above.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>