A correction: "Are those object" -> "Are those classes"
Ramnivas Laddad wrote:
Are those object generated a priori or dynamically during runtime? If
the former is the case, then you should be able to weave into those
classes using the -inpath option. If the later is the case, you should
be able to get the expected behavior using load-time weaving (LTW).
-Ramnivas
vinodh.t.subbiah@xxxxxxxxxxxx
wrote:
Hi Ramnivas ,
Yes I tried with ILOG
and
it works ! .But when I use ILOG's Dynamic binding mechanism to create
my
XOM(Execution Object Model) from my XML Schema ,It creates all the
XML objects as a Child of IlrXMLObject internally .In this case I'm not
able to trace any flow as everything becomes dynamically generated and
by ILOG ..So my code trace stops at the execute method and if there any
calls from irl (ILOG RULE LANGUAGE) file to other classes in my
workspace
it shows the trace again.!
Anybody come across such
situation
.Please let me know if you have any solution.
Thanks for your reply.
Regards,
Vinodh
Vinodh Subbiah
Decision Support Service Development Team
JPM Chase
614 213 1574 (W)
602 403 8451(M)
vinodhts@xxxxxxxxx
Vinodh,
While I haven't used ILOG myself (used Jess instead), I have looked at
both ILOG API and JSR94 (at the time of AspectJ in Action, JSR94 wasn't
quite ready). I believe you should be able to just map the examples and
general idea in AspectJ in Action to ILOG/JSR94.
-Ramnivas
===
Ramnivas Laddad,
Author, AspectJ in Action
http://ramnivas.com
M: (408)203-4621
vinodh.t.subbiah@xxxxxxxxxxxx
wrote:
Hi All,
Thanks for all the replies.Yes I find out some of the bugs I introduced
into my (like stackoverflow ) and I fixed it.Now I'm able to run my
program
with all your help.(Thanks to everyone)
But now my main task is to use this aspect with my rules engine .We are
using JSR 94 API for executing our rules.I saw one example in AspectJ
in Action for using it with JESS but as we are using ILOG it is bit
different
as im not expert in JESS .Do anyone tried loading any external file
containing
your rules like that in ILOG and try to trace it using AspectJ ?
Please advise.
I'm using RAD 6.0 and AspectJ M5 - ILOG rule studio offers a free
plugin
for RAD 6.0 and Im using it to execute my rules - FYI .
Thanking you ,
With regards,
Vinodh Subbiah
Decision Support Service Development Team
JPM Chase
614 213 1574 (W)
602 403 8451(M)
vinodhts@xxxxxxxxx
Vinodh
As I understand it, the IDE shows static pointcuts, where dynamic
pointcuts,
like cflowbelow, may apply, but not necessarily where they will
apply.
So it shows that the call to executeRules may be captured. But when it
gets to that point in the execution of the program, it looks for the
dynamic
rule (am I within the control flow of a call to executeRules?), which
fails,
so you do not get a match.
As written, your pointcut will only capture calls to executeRules
nested
within a call to executeRules. If you meant to exclude nested calls,
then
Andy's succinct !cflowbelow should capture only the top level calls.
The other trails to pursue include the distinction between call and
execute,
and what code is being woven. You have used a call, which suggests you
have control over (ie can weave into) your code but not the code being
called. If that is the case, then if that code contains executeRules,
the
pointcut is not being woven into that call.
Hope this helps...
Elizabeth
CONFIDENTIAL AND PRIVILEGED INFORMATION NOTICE
This e-mail, and any attachments, may contain information that
is confidential, subject to copyright, or exempt from disclosure.
Any unauthorized review, disclosure, retransmission,
dissemination or other use of or reliance on this information
may be unlawful and is strictly prohibited.
AVIS D'INFORMATION CONFIDENTIELLE ET PRIVILÉGIÉE
Le présent courriel, et toute pièce jointe, peut contenir de
l'information qui est confidentielle, régie par les droits
d'auteur, ou interdite de divulgation. Tout examen,
divulgation, retransmission, diffusion ou autres utilisations
non autorisées de l'information ou dépendance non autorisée
envers celle-ci peut être illégale et est strictement interdite. |
_______________________________________________
ajdt-dev mailing list
ajdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ajdt-dev
_______________________________________________
ajdt-dev mailing list
ajdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ajdt-dev
_______________________________________________
ajdt-dev mailing list
ajdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ajdt-dev
_______________________________________________
ajdt-dev mailing list
ajdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ajdt-dev
_______________________________________________
ajdt-dev mailing list
ajdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ajdt-dev
|