Hello, feedback!
-----Mensagem original-----
De: Leo Simons [mailto:[EMAIL PROTECTED]
> class InterceptorContainer extends DefaultContainer
> implements EventManagerProvider { ... }
Sure. But that one of the improvements for Fortress 1.2 - exposing Events.
So it will be
public class DefaultContainer extends AbstractContainer
implements EventManagerProvider
> Do you think it would be possible to just reuse the MetaClass Attribute
> class and access methods? For example
> DefaultInterceptorManager.obtainComponentFamily() could just use
>
> Attributes.getAttributes( method );
Two points:
1. In a pursuit for no 'implementation locking' I've created a fa�ade for
MetaClass.
2. Performance problems: for each Attributes.getAttributes( method ) you
raise, a comparisson/match will take place.
> why? Isn't the metainfo supposed to be directed at the container, and
> the component is configured using Configurable semantics?
Metainfo should not be viewed as another way to configure. Meta should
describe behaviors. My idea on exposing the ExtendedMetaInfo is to allow
some 'component facilities' to be written. Today is interceptors, tomorrow
is 'who knows?' :-)
> QDoxSerializer leads the way!
>
> I think step two is already done elsewhere:
>
>
http://svn.metaclass.codehaus.org/trunk/tools/src/java/org/codehaus/metaclas
s/tools/qdox/
>
> I can't help but think that we can move away (but support of course)
> from our own xml format and use the metaclass one in one swell swoop.
> But that's bigger changes than what you're proposing.
I don't think it will please our users. Peter Royal, for instance, is a
defensor of no obligation of using attributes to declare behaviors.
> Oh, and static singleton factories I no like :-D
Yeah, totally agreed. I was in a rush, you know.
> Again, I think I see oppurtunity for bigger changes! We could get
> completely rid of our old proxy management code and recast it as
> utilization of some AOP or interceptor toolkit. That would completely
> integrate interceptor support as to "tacking it on". WDYT?
+1
> the way I'm seeing this is that "family" defines the association of any
> particular interceptor stack with any particular method on any
> particular component, ie it is a limited version of an "aspect". And
> instead of using pointcuts (ie
> https://dynaop.dev.java.net/nonav/release/1.0-beta/manual/ch01.html#d0e65)
> or some kind of interception point syntax (ie
> there's this new concept.
>
> I think its a better idea to go with the flow and terminology of the
> "pointcut" idea.
-1
Its not really pointcuts as it doesn't offer all possibilities that
pointcuts offers.
> looking pretty familiar again (= good thing). In my experience in the
> end I found that passing around an Invocation object is quite a bit
> cleaner, ie like
Yeah, might be.
> No offense, but I don't think we're able to maintain a very efficient
> proxy/interception library by ourselves. Looking at projects like
> HiveMind and Spring, you can also see how this has impacted them. A
> dedicated project like dynaop with dedicated experts is just so much
faster.
Probably. I did my best.
> How about this...we start another branch (so you don't need to miss your
> project deadline) that's a little more radical and weaves dynaop and
> metaclass right into the fortress core, then after that we look back and
> try and figure out a way forward. WDYT?
+1000
But someone must leads it avoiding going to the limbo. My departure is going
to be on 24th, so I couldn't do that.
Cheers,
hammett
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Apache Excalibur Project -- URL: http://excalibur.apache.org/
