[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [aspectj-users] XDoclet integration?
|
Ted,
Overuse of tags is indeed a big concern. (in general, it will
be interesting to see how metadata in JSR 175 gets used in
practice. I think it will be a chaotic situation for a while :-( ).
If developer start tagging code instead of thinking what poincut
could capture the intended join points would go contrary to the
obliviousness.
That said, there are a few cases where metadata is useful,
especially when it is impossible to extract the characteristics
of a join point based on method names etc.
The question then is how to best express the metadata.
Following is the guideline I have been using:
1. Global concern:
"Authenticate all public methods in banking module".
Solution:
Use a hand-written (sub)aspect that defines pointcut using
wildcards. No explicit metadata used.
2. Class level concern:
"Lazy initialize that field".
Solution:
Use a nested hand-written aspect that defines pointcut using
explicit name of the enclosing class.
3. Global concern with class level control:
"Ensure thread safe access" translated into "Surround the
state access methods with a synchronized block" or
"use read-write lock pattern" etc.
Solution:
Use the participant pattern. The base aspect contain one
or more abstract pointcuts and each class contains a nested
subaspect that extends the base aspect and provides a definition
for each abstract pointcut.
(Variations such as packages level participant are also useful).
4. Global concern with method level control:
"Execute the following method in transaction context" or
"Surround slow running methods with a wait cursor".
Solution:
Currently I still use the participant pattern. In doing
so I am fusing together characteristics of all methods
in a aspect. While this style has served well so far,
I do think the information expressed in the participant
subaspect isn't quite right place.
This is the case where XDoclet/JSR175 metadata can be
helpful. I can now declare the "participation" by adding
metadata where it belongs -- the method themselves.
-Ramnivas
--- Ted Neward <tneward@xxxxxxxxxxxxx> wrote:
> I think this is a bad road to go down.
>
> Aspects have traditionally been useful because the aspect itself
> contains the knowledge of which classes/methods/fields/etc to weave
> against, rather than deferring that to the class or component itself.
> This helps keep the intelligence regarding how and when the aspect
> should weave within one place, rather than scattering it all over the
> codebase. Aspects are somewhat intrusive by nature, and shouldn't be
> considered across component boundaries.
>
> In contrary, interception-based frameworks work best when they are
> established at component boundaries, allowing the components to
> declare
> which sorts of services they wish provided at the interception
> points.
> This is where 175 will have its best success, IMHO, since it will
> provide a natural replacement for deployment descriptors in J2EE
> applications, allowing components to declare which services should be
> injected into the thread's call flow.
>
> Frankly, I understand the desire to make AspectJ fit in with both
> paradigms, but I think in the long run we're going to regret going
> down
> that road; I think it would create a situation in which complex use
> of
> aspects in this manner would create more problems than using aspects
> would solve. Case in point: given this "declarative" style of
> aspects,
> how would dominates clauses be honored and/or specified?
>
> Ted Neward
> Author, Instructor, Presenter: Java and .NET
> http://www.neward.net/ted/weblog
> http://www.javageeks.com
> http://www.clrgeeks.com
>
>
> > -----Original Message-----
> > From: aspectj-users-admin@xxxxxxxxxxx
> > [mailto:aspectj-users-admin@xxxxxxxxxxx] On Behalf Of Ramnivas
> Laddad
> > Sent: Saturday, August 16, 2003 1:27 PM
> > To: aspectj-users@xxxxxxxxxxx
> > Subject: Re: [aspectj-users] XDoclet integration?
> >
> >
> > Ron,
> >
> > I have been looking into it, but haven't ventured into implementing
>
> > so far. My thinking has been pretty much along the line you
> > specified (an alternative to the participant pattern).
> >
> > The main aim for such integration would be to automatically
> > create subaspects for implementing concerns such as
> > transaction management. I think keeping the input source
> > intact and generate additional files (aspects) will be a
> > simpler and more explainable solution.
> >
> > For example, if I had a class as follows:
> > public class Account {
> > /**
> > * @transaction required
> > */
> > public void credit(float amount) {
> > ...
> > }
> >
> > /**
> > * @transaction required
> > */
> > public void debit(float amount) {
> > ...
> > }
> >
> > ...
> > }
> >
> > And the base transaction aspect as follows:
> >
> > public abstract aspect AbstractTransactionAspect {
> > abstract poitncut transactedOperations();
> >
> > Object around() : transactedOperations() {
> > // begin, commit, rollback logic
> > }
> > }
> >
> > XDoclet integration would generate the following concrete
> > aspect to create a system specific subaspect:
> >
> > /** XDoclet generated -- do not hand-modify **/
> > public aspect SystemTransactionAspect
> > extends AbstractTransactionAspect {
> > public pointcut transactedOperations()
> > : execution(void Account.credit(float amount))
> > || execution(void Account.debit(float amount))
> > }
> >
> > Now users won't need to understand the details of the
> > transaction aspects; simply understanding the tags and
> > XDoclet task will suffice.
> >
> > Asides:
> > 1. Use of semantically meaningful tags such as @atomic instead
> > of @transaction may be better suited
> > 2. More sophisticated transaction management may be supported
> > such as required-new vs. required. Perhaps AspectJ/XDoclet
> > integration for transaction management may use the same
> > tags as EJB/XDoclet integration.
> >
> > -Ramnivas
> >
> > --- Ron Bodkin <rbodkin@xxxxxxxxxxx> wrote:
> > > Has anyone looked at integrating AspectJ with XDoclet? I
> > was thinking
> > > this could be helpful to prototype uses of metadata with AspectJ
> > > programs. With JSR-175 now available for community review,
> > this seems
> > > like an opportune time. It should also be instructive in thinking
>
> > > about what pointcuts and compiler support will be required
> > for 175...
> > >
> > > I think it would be possible to use XDoclet to generate code like
> > > this:
> > >
> > > /**
> > > @tag attr="val"
> > > */
> > > class Foo {...}
> > >
> > > ->
> > >
> > > public interface tagMarker {}
> > > class Foo implements tagMarker { ... }
> > >
> > > and
> > >
> > > class Foo {
> > > /** @tag */ void methodA(int x) { ... }
> > > /** @tag */ int methodB() { ... }
> > > /** @tag */ int field;
> > > }
> > >
> > > ->
> > >
> > > public abstract aspect tagReader {
> > > abstract public pointcut tagExecution();
> > > abstract public pointcut tagGet();
> > > abstract public pointcut tagSet();
> > > }
> > >
> > > /** empty class that contains any user-defined code to access
> these
> > > pointcuts */ public abstract aspect tagReaderExtension extends
> > > tagReader { }
> > >
> > > class Foo {
> > > // use the participant pattern: an alternative is to generate
>
> > > concrete
> > > // pointcuts in the tagReader aspect that contains all the
> > > pointcuts
> > > static aspect MetadataParticipant extends tagReaderExtension
> {
> > > public pointcut tagExecution() :
> > > execution(void Foo.methodA(int)) || execution(int
> > > Foo.methodB());
> > > public pointcut tagGet() : get(int Foo.field);
> > > public pointcut tagSet() : set(int Foo.field);
> > > }
> > > void methodA(int x) { ... }
> > > int methodB() { ... }
> > > }
> > >
> > > This would allow writing pointcuts that refer to tagged methods,
> > > interfaces, or classes. From a first look at how XDoclet
> generation
> > > works, this looks like it would be relatively straightforward.
> > > However, I've not tried to write custom XDoclet code before, so
> I'm
> > > curious if anyone who has could comment on the feasibility
> > and ease of
> > > doing this. Would it be easier if we limited it to only
> > generating new
> > > files instead of adding code to existing ones?
> > >
> > > Ron
> > >
> > > p.s. I believe it would also be possible to generate a way of
> > > accessing attributes for the tags as follows. However, this seems
>
> > > rather klunky, so I'd sooner wait til there's a primitive
> pointcut
> > > descriptor to access them than use XDoclet code generation...
> > >
> > > /**
> > > @tag attr="val"
> > > */
> > > class Foo {...}
> > >
> > > ->
> > >
> > > interface tagMarkerInterface {
> > > String getAttr();
> > > }
> > >
> > > aspect tagReaderMarkerInterface {
> > > String tagMarkerInterface.attr;
> > >
> > > public String tagMarkerInterface.getAttr() {
> > > return attr;
> > > }
> > >
> > > before(Foo obj) : initialization(Foo.new(..)) && target(obj)
> {
> > > obj.attr = "val";
> > > }
> > > }
> > >
> > > class Foo implements tagMarkerInterface { ... }
> > >
> > > and
> > >
> > > class Foo {
> > > /** @tag attr="val1" */ void methodA(int x) { ... }
> > > /** @tag attr="val2" */ int methodB() { ... }
> > > }
> > >
> > > ->
> > >
> > > class Foo {
> > > static aspect MetadataParticipant {
> > > ThreadLocal attrHolder = new ThreadLocal();
> > > pointcut tagExecution() :
> > > execution(void Foo.methodA(int)) || execution(int
> > > Foo.methodB());
> > > String getAttr() { return (String)(attrHolder.get()); }
> > > before() : execution(void Foo.methodA(int)) {
> > > attrHolder.set("val1");
> > > }
> > > before() : execution(int Foo.methodB()) {
> > > attrHolder.set("val2");
> > > }
> > > }
> > > void methodA(int x) { ... }
> > > int methodB() { ... }
> > > }
> > >
> > > Ron Bodkin
> > > Chief Technology Officer
> > > New Aspects of Security
> > >
> >
> >
> > __________________________________
> > Do you Yahoo!?
> > Yahoo! SiteBuilder - Free, easy-to-use web site design
> > software http://sitebuilder.yahoo.com
> > _______________________________________________
> > aspectj-users mailing list
> > aspectj-users@xxxxxxxxxxx
> > http://dev.eclipse.org/mailman/listinfo/aspect> j-users
> >
>
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/aspectj-users
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com