From lieber@ccs.neu.edu Sun Dec 13 20:06:46 1998 Received: from stockberg.ccs.neu.edu (lieber@stockberg.ccs.neu.edu [129.10.116.114]) by amber.ccs.neu.edu (8.9.1a/8.9.1) with ESMTP id UAA13805; Sun, 13 Dec 1998 20:02:40 -0500 (EST) Received: (from lieber@localhost) by stockberg.ccs.neu.edu (8.9.1a/8.9.1) id UAA29064; Sun, 13 Dec 1998 20:02:40 -0500 (EST) Date: Sun, 13 Dec 1998 20:02:40 -0500 (EST) From: Karl Lieberherr Message-Id: <199812140102.UAA29064@stockberg.ccs.neu.edu> To: lorenz@ccs.neu.edu, predrag@ccs.neu.edu Subject: Re: APPCs Cc: lieber@ccs.neu.edu, mira@informatik.uni-siegen.de Status: R Hi Predrag: there are two kinds of APPCs APPCs with one or more main-entries: augmenting APPCs and APPCs without a main-entry: enhancing APPCs The augmenting APPCs have a traversal that may be empty and zero or more participants each corresponding to a traversal along a unique path. Enhancing APPCs are aspect-like and for those a turn-on/turn-off capability is meaningful. So the current answer is: for enhancing APPCs we also have turn-on/turn-off. -- Karl ========================================== >From predrag@ccs.neu.edu Sun Dec 13 12:58:28 1998 >From: Predrag Petkovic >To: "David H. Lorenz" >cc: Karl Lieberherr >Subject: APPCs > >Professor- > >I have one question. >When we have APPCs and code for CCG in Java, can we change Java code to >implement APPCs? > >In AspectJ, we have .ajava files with aspects and Java classes. Tutorial >says that we can plug in aspect when we run > > ajweaver Point.ajava Some-Aspect.ajava > >and plug off aspect when we run > > ajweaver Point.ajava > >I know that APPCs can be implemented using Java Beans, but it is >because those APPCs only traverse objects. >In AspectJ, there is no object traversing, but there is methods weaving >("before" and "after" some method), and adding new methods and data >members to the classes. > >--Predrag > > From lieber@ccs.neu.edu Mon Dec 14 07:30:00 1998 Received: from stockberg.ccs.neu.edu (lieber@stockberg.ccs.neu.edu [129.10.116.114]) by amber.ccs.neu.edu (8.9.1a/8.9.1) with ESMTP id HAA29707; Mon, 14 Dec 1998 07:29:57 -0500 (EST) Received: (from lieber@localhost) by stockberg.ccs.neu.edu (8.9.1a/8.9.1) id HAA01520; Mon, 14 Dec 1998 07:29:57 -0500 (EST) Date: Mon, 14 Dec 1998 07:29:57 -0500 (EST) From: Karl Lieberherr Message-Id: <199812141229.HAA01520@stockberg.ccs.neu.edu> To: lieber@ccs.neu.edu, mira@informatik.uni-siegen.de Subject: Re: APPCs Cc: lorenz@ccs.neu.edu, predrag@ccs.neu.edu Status: R Hi Mira: I agree with your message. aspect-appc or enhancing appc are both good names. Although aspect appcs don't traverse, we can use strategy graphs to define sets of classes and other sets and substructures adaptively. -- Karl >From mira@informatik.uni-siegen.de Mon Dec 14 03:40:11 1998 >From: "Mira Mezini" >Cc: lorenz@ccs.neu.edu, predrag@ccs.neu.edu, lieber@ccs.neu.edu, > mira@informatik.uni-siegen.de >In-Reply-To: <199812140102.UAA29064@stockberg.ccs.neu.edu> from "Karl Lieberherr" at Dec 13, 98 08:02:40 pm > >Hi all, > >good question. I have been thinking about that the last couple of >days. Up to now, we actually focused on the implementation of >traversal based APPCs with JavaBeans. But, that's just the current >state of the art. > >As long as we consider only traversal based APPCs, >there is no need to change the CCG code. We even assume that >only .class files are available for the CCG, i.e., we require our >tool to work even with third party CCGs. I think this is the >only reasonable assumption we can do, if we talk about component- >oriented programming. Bills traversal bean takes the object to >be traversed and the traversal graph and traverses the object according >to the traversal graph producing events. These events are heard by the >APPCs which call back on the CCG objects to get the information >they need. > >This is different with the aspect appcs, i.e., those that add aspects >to the CCG rather than enhancing the CCG with new functionality. >In this case there is no traversal gping on. The CCG code needs >to be modified in order to activate aspect appcs in the right place. >Assume a class Point and an aspect that logs all write accesses >on point objects. So, before setting the variables ax or y, by >invoking setX, resp. setY, the code in the LogAppc need to >be executed. How do we achieve that. My solution is binary adaptation >of CCG .class files. The adaptation would turn the Point class >to a java bean that fires events after entering a set* method. > >The inputs of our tool (preprocessor, appc compiler, ..., call >it what you wnat) will be (in the case: no traversal involved) >(a) .class files, (b) .appc (conatining appcs), and (c) .conn >(containing maps, or connector specifications. The .appc files >will be translated into java beans as now. The semantics of >the specifications in .conn consists roughly in two steps: >(1) instantiate appc beans and properly initialize their "adapting" >related state (I mean all variables that are involved with >the adaptation functionalty of appcs beans, and >(2) perform a binary adaptation of the CCG code in the >roght places (classes that are specified to implement >ICGs in the .conn file. >This is more or less turning-on as I think about it. Turning off >could be implemented as removing the corresponding appc from >the listeners list of the CCG. > >To summarize: yes we will have turning-on/off of the >aspect-appcs. > >- Mira > > >> >Professor- >> > >> >I have one question. >> >When we have APPCs and code for CCG in Java, can we change Java code to >> >implement APPCs? >> > >> >In AspectJ, we have .ajava files with aspects and Java classes. Tutorial >> >says that we can plug in aspect when we run >> > >> > ajweaver Point.ajava Some-Aspect.ajava >> > >> >and plug off aspect when we run >> > >> > ajweaver Point.ajava >> > >> >I know that APPCs can be implemented using Java Beans, but it is >> >because those APPCs only traverse objects. >> >In AspectJ, there is no object traversing, but there is methods weaving >> >("before" and "after" some method), and adding new methods and data >> >members to the classes. > >