[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [aspectj-users] AJDT 1.3 and aspectj
|
Wes/Andy,
Hopefully without jinxing myself, I can confirm that the order of advice precednce between 1.2 and 1.3/1.5 is what was causing my problems. So far my app has been running without any hicups. Now I know that Wes said that order is/was never guaranteed, but under 1.2 it did the "right" thing as far as my aspects are concerned. Is there an easy for me to see the precednce or is that something that is under the covers? I have never seen it within the Visualize or the outline view under AJDT. It would be nice to have this so that if you have 2 or more aspects interacting on the same piece of code, you know what is going on. Shall I enter this as a bug on this one?
Okay, now to find a solution that will allow me to migrate to 1.3/1.5. Should I combine these into 1 so that I gurantee the order or can I declare the proper precedence in such a way that it wwork properly? Here are my aspeects and the order in which they need to happen: [Or maybe I should just move to Spring and be done with it :-)]
public aspect TransactionControl
{
pointcut transaction(HibernateTransaction tc) :
target(tc) && execution(public * HibernateTransaction.*(..));
// Second - after the Hibernate session has been opened
before(HibernateTransaction tc) : transaction(tc)
{
HibernateHelper.start();
}
// Third - But before the Hibernate session has been closed.
after(HibernateTransaction tc) returning : transaction(tc)
{
HibernateHelper.commit();
}
// Third - But before the Hibernate session has been closed.
after(HibernateTransaction tc) throwing : transaction(tc)
{
HibernateHelper.rollback();
}
}
public aspect HibernateAspect
{
pointcut hibernateClassList() :
within(com.tascon.tim.provider.hibernate.*);
pointcut hibernateFetch(HibernateProviderBase hpb) :
execution(public * *.*(..)) && !execution(public * *.set*(..))
&& target(hpb);
// First
before(HibernateProviderBase hpb) : hibernateClassList() &&
hibernateFetch(hpb)
{
try
{
hpb.sess = HibernateHelper.openSession();
}
catch(Exception e)
{
}
}
// Last
after(HibernateProviderBase hpb) :
hibernateClassList() && hibernateFetch(hpb)
{
HibernateHelper.closeSession();
}
}
Ron
-----Original Message-----
From: Ron DiFrango
Sent: Tue 10/4/2005 2:21 PM
To: Wes Isberg; aspectj-users@xxxxxxxxxxx; Andy Clement
Cc:
Subject: RE: [aspectj-users] AJDT 1.3 and aspectj
Wes,
Andy I are having a side conversation on this issue. We really think it has to do with aspect precedence.
As for the switch out, it was the compiler/weaver only. No code changes to this stuff at all! It is not the advice that is failing, but slowly over the 4 hours, I run out of database connection via the connection pool and JTA transactio nmanagers. So eventually JBoss pukes and says no more transactions or database connections available [I forget the specific error and I am not near the compute rthat it happened on]. As I type this emails, I am beginning to wonder if the after advice for committing or rolling back the transactions is some running after I close out the HibernateSession which holds the database connection related to the transaction.
I guess to prove/disprove this I could either add precednce [not sure what the order is] between my HibernateAspect & TransactionControl control aspect. Or another option would be to combine these into one. Any thoughts?
Now this has worked for me over the past 2 years or so under aspectj 1.2, so maybe I have been lucky or living right so far.
By the way, I am logging this via another aspects and here is my code to prove it :-)
package com.tascon.tim.aop;
import org.aspectj.lang.JoinPoint;
public aspect ExceptionHandler
{
public pointcut classList() : within(com.tascon..*);
before(Throwable e) :
classList()
&& handler(*)
&& args(e)
{
log(thisJoinPointStaticPart, e);
}
private void log(JoinPoint.StaticPart jp, Throwable e)
{
// MessageLog.writeErrorMessage(
// jp.getSignature().getName(),
// e,
// jp.getSignature().getDeclaringType());
System.out.println("RRD Type: " + jp.getSignature().getDeclaringType());
System.out.println("RRD Signature: " + jp.getSignature());
System.out.println("RRD at: " + jp.getSourceLocation());
System.out.println("RRD exception: " + e.getMessage() );
System.out.println("RRD stack trace: " + e.getStackTrace() );
}
}
Ron
-----Original Message-----
From: Wes Isberg [mailto:wes@xxxxxxxxxxxxxx]
Sent: Tue 10/4/2005 1:47 PM
To: aspectj-users@xxxxxxxxxxx
Cc:
Subject: RE: [aspectj-users] AJDT 1.3 and aspectj
Hi Ron -
(Some comments while Andy is home...)
As between advice in two aspects unrelated by precedence, there are
no guarantees about order on a join point, even from compile to compile.
There may of course be engineering regularities between compiles and
between versions of the compiler/weaver !
When you say the system gradually fails over 4 hours or so, you're
suspecting that a leak in memory or transactions? I can't tell if
you're suspecting that the advice stops running or if it is running
at the wrong times, and how that would cause it to fail not immediately
but after 4 hours.
Also, when you say you migrated from 1.2 variants, did you change the
code or just the compiler/weaver? If you changed the code, you might
have introduced some semantic difference. You might try building and
running the 1.2.1 code under AspectJ 1.5.
Finally, it might help to see when advice operations fail (in part
since your advice catch and ignore exceptions).
aspect LogAdviceExceptions {
after() throwing(Throwable t) : adviceexecution()
&& !within(LogAdviceExceptions) && within({youraspects}) {
// log...
}
}
Failures that take 4 hours to show up are particularly annoying!
Wes
> ------------Original Message------------
> From: "Ron DiFrango" <rdifrango@xxxxxxxxxxxxxxxxxxx>
> To: "Andy Clement" <andrew.clement@xxxxxxxxx>, aspectj-users@xxxxxxxxxxx
> Date: Tue, Oct-4-2005 8:14 AM
> Subject: RE: [aspectj-users] AJDT 1.3 and aspectj
>
> Andy,
>
> One more thought though and this is likely bad on my part. Since I
> have not established precednce between my aspects, how does aspectj
> determine how to apply overlapping concerns to a single source file?
>
> Ron
>
> -----Original Message-----
> From: Andy Clement [mailto:andrew.clement@xxxxxxxxx]
> Sent: Tue 10/4/2005 9:34 AM
> To: Ron DiFrango
> Cc:
> Subject: Re: [aspectj-users] AJDT 1.3 and aspectj
>
>
>
> We haven't changed precedence rules so that won't be the problem.
> Eclipse 3.1 AJDT currently includes the latest AspectJ Development
> builds of AJ5 - we are upgrading AJDT with a new AJ at least every
> Monday. You can decompile the classes to see their woven form - but
> I'd say as a first pass use -showWeaveInfo to verify everything that
> was getting advised with 1.2 is still getting advised with 1.5.
>
> If the bytecode is broken in some way, my guess would be a method with
> a finally block being advised and the finally block not executing as
> expected. Can you put some diagnostic advice on the calls in the
> finally block that should be clearing resources and verify the
> clearing up is happening as expected?
>
> Andy.
>
> On 04/10/05, Ron DiFrango <rdifrango@xxxxxxxxxxxxxxxxxxx> wrote:
> > Andy,
> >
> > I will do that this evening [I will have to get my ANT build going]
> to see what happens. Whcih version of aspectj is built into the AJDT
> version for Eclipse 3.1.
> >
> > Also, one other thought, all these aspect for transaction control,
> etc. are store in seperate files. So I am wondering if order/precedence
> has changed between versions and is causing the transaction boundaries
> to get started/stopped at the wrong points in the application.
> >
> > Boy, I wish we have a generate source option from aspectj 1.2 on
> wards so I could see this a whole lot easier :-)
> >
> > Ron
> >
>
>
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>
>
_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-users
