Mailing-List: contact hivemind-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: hivemind-user@jakarta.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Message-ID: <42EAA78B.4070100@evolva.ro>
Date: Sat, 30 Jul 2005 00:02:51 +0200
From: Alexandru Popescu <the_mindstorm@evolva.ro>
User-Agent: Mozilla Thunderbird 1.0+ (Windows/20050712)
MIME-Version: 1.0
To: hivemind-user@jakarta.apache.org
Subject: Re: Hivemind + AOP : Which approach to take?
References: <200507292150.j6TLo56T009625@carmanconsulting.com>
In-Reply-To: <200507292150.j6TLo56T009625@carmanconsulting.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

#: by James Carman's words the mind was *winged* :#
> I would have to say that I believe in the KISS (keep it simple, stupid)
> principle.  Proxies are just fine in many cases.  The performance costs of
> proxies vs. "weaving" are negligible compared to what the methods are
> already doing, for the most part.  Now, if you do run into a situation where
> the proxies are just too darned slow for you, then you can tweak the system
> by using a different approach AOP or runtime class generation (CGLIB or
> Javassist).  I would venture to say that you probably won't need to do it.
> In other words, YAGNI.  Don't get me wrong, I do like AOP for certain tasks,
> but when a framework such as HiveMind gives you a simplified solution (like
> MethodInterceptors), why not use it?
> 

Sorry I have been understood this way. I was not advocating against Hivemind, Spring or some other 
aop solutions. To me the initial post seemed to be a research for an intro in aop. From this point 
of view I considered some clarifications were needed.

However, the KISS principle is here applied only to the framework development, as from my point of 
view the users are required to in both situations to learn only the pointcut definition language (I 
wouldn't bring into discussion a few interfaces API that are used in AW or AJ f.e.).

As regards the fact that proxy solutions are covering many cases I agree with you. But I usually 
tend to use cleaner befores and afters, instead of always using arounds.

I don't want to start a flame, but considering interceptors as aop is not 100% correct. Interceptors 
were introduced as a pattern, that at the point of aop concepts implementation seemed appropriate to 
be used. You can do with them some of the things you are doing with aop, but that's all. Sorry if i 
sound kinnda `religious� about it :-).

:alex |.::the_mindstorm::.|

> 
> -----Original Message-----
> From: Alexandru Popescu [mailto:the_mindstorm@evolva.ro] 
> Sent: Friday, July 29, 2005 5:35 PM
> To: hivemind-user@jakarta.apache.org
> Subject: Re: Hivemind + AOP : Which approach to take?
> 
> #: by Vinicius Carvalho's words the mind was *winged* :#
>> In reply for James: 
>> Haven't tried yet, promise I'll try over the weekend. And BTW Thanks a
>> lot for the post.
>> 
>> Alexandru:
>> 
>> "You can do offline weaving so there is no need for special
>> classloaders." My mistake, I'm so sorry for that, did not know about
>> that feature :D
>> I found some annoying problems with Annotations and eclipse plugin as well
> :(
>> 
> 
> I have to agree that the plugin is not our powerfull point :-s. I would be
> interested to hear what 
> problems have you faced with Annotations.
> 
>> I think it's my fault the definition of intrusive on the email
>> context. As you can see by my name and grammar (English is not my
>> native language :P). What I'd like to say is: I prefer proxy based
>> once your original code is preserved, you don't need to re-compile it
>> to add/remove features from your aspects.
>> 
> 
> Unfortunately, the proxy based solution is not something I would recommend
> to anyone. It is a very 
> easy approach (look how many so called aop solutions based on proxies are
> out-there, compaired with 
> real aop solutions) and you are loosing some of the features (f.e. static
> typing) which will finally 
> influence the performance. But this is quite another story.
> 
>> Not justifying my mistakes, just making them clear :P
>> 
> 
> No problem. For myself it is quite the same: English is not my mother
> language :-).
> 
> take care,
> :alex |.::the_mindstorm::.|
> 
>> Thanks all
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: hivemind-user-help@jakarta.apache.org
>> 
>> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: hivemind-user-help@jakarta.apache.org
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: hivemind-user-help@jakarta.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-user-help@jakarta.apache.org