You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Geoff Longman <gl...@gmail.com> on 2006/04/27 14:53:10 UTC
AspectJ and T5
http://howardlewisship.com/blog/2006/04/gambling-on-aspectj.html
It's a gamble for sure.
Pls reassure me that my 9 team members will never have to look at,
learn, or understand anything about AspectJ to use T5. Ie. it will be
am implementation detail of T5 and not a "feature". Also, that any
mention of AspectJ will relegated to an "appendix" in the
documentation for T5 that 99.9999% of Tapestry 5 users can ignore.
Geoff
--
The Spindle guy. http://spindle.sf.net
Blog: http://jroller.com/page/glongman
Other interests: http://www.squidoo.com/spaceelevator/
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: AspectJ and T5
Posted by Geoff Longman <gl...@gmail.com>.
whew. thanks for the clarification. I think that's the way to do it for sure.
Geoff
On 4/28/06, James Carman <ja...@carmanconsulting.com> wrote:
> Okay, my Tapestry 5 warm fuzzy feelings have returned.
>
> -----Original Message-----
> From: Howard Lewis Ship [mailto:hlship@gmail.com]
> Sent: Friday, April 28, 2006 11:41 AM
> To: Tapestry development
> Subject: Re: AspectJ and T5
>
> Absolutely!
>
> AspectJ will be part of the internal implementation of Tapestry. I'm
> using it (so far) to enforce basic coding standards and contracts, and
> to simplify code related to thread synchronization.
>
> However, Tapestry 5 applications will not use AspectJ. AspectJ will
> need to be on the runtime classpath, but Tapestry 5 applications will
> not ever have to see it. Tapestry 5 application code will not be
> transformed or weaved or whatever by AspectJ.
>
> Tapestry 4 performs aspect oriented operations when it creates an
> "enhanced" subclass. Tapestry 5 will do something similar, except
> that it transforms the class as it is loaded. But this Tapestry AOP
> support is internal to Tapestry (driven entirely off of annotations in
> Tapestry 5).
>
> This is part of the very careful split between Tapestry internal
> implementation and Tapestry application development, something that's
> all merged together in Tapestry 4.
>
> The goal I'm following is that only the absolute minimum necessary is
> exposed in the public space. Much of the code is and will be in the
> org.apache.tapestry.internal package, with the message "hands off" ...
> even though there will likely be a lot of tested, reusable code in
> there. Tapestry needs the freedom to change its internals at any time,
> without breaking any outside code. I may eventually split
> tapestry-core into a pure API library (mostly annotations, plus a
> scattering of interfaces and classes), and a seperate implementation
> library.
>
> On 4/27/06, James Carman <ja...@carmanconsulting.com> wrote:
> > Yes, please don't make us use AspectJ to develop in tapestry. I don't
> > care if you want to use AspectJ behind the scenes to implement Tapestry,
> > but please don't make us have to weave aspects into our classes to get
> > stuff done. Also, we need to figure out how to allow HiveMind to support
> > aspects the way Spring does. I don't think it's going to be difficult. I
> > just haven't had the time to sit down and code it up.
> >
> > > http://howardlewisship.com/blog/2006/04/gambling-on-aspectj.html
> > >
> > > It's a gamble for sure.
> > >
> > > Pls reassure me that my 9 team members will never have to look at,
> > > learn, or understand anything about AspectJ to use T5. Ie. it will be
> > > am implementation detail of T5 and not a "feature". Also, that any
> > > mention of AspectJ will relegated to an "appendix" in the
> > > documentation for T5 that 99.9999% of Tapestry 5 users can ignore.
> > >
> > > Geoff
> > >
> > > --
>
>
> --
> Howard M. Lewis Ship
> Independent J2EE / Open-Source Java Consultant
> Creator and PMC Chair, Apache Tapestry
> Creator, Jakarta HiveMind
>
> Professional Tapestry training, mentoring, support
> and project work. http://howardlewisship.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
--
The Spindle guy. http://spindle.sf.net
Blog: http://jroller.com/page/glongman
Other interests: http://www.squidoo.com/spaceelevator/
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
RE: AspectJ and T5
Posted by James Carman <ja...@carmanconsulting.com>.
Okay, my Tapestry 5 warm fuzzy feelings have returned.
-----Original Message-----
From: Howard Lewis Ship [mailto:hlship@gmail.com]
Sent: Friday, April 28, 2006 11:41 AM
To: Tapestry development
Subject: Re: AspectJ and T5
Absolutely!
AspectJ will be part of the internal implementation of Tapestry. I'm
using it (so far) to enforce basic coding standards and contracts, and
to simplify code related to thread synchronization.
However, Tapestry 5 applications will not use AspectJ. AspectJ will
need to be on the runtime classpath, but Tapestry 5 applications will
not ever have to see it. Tapestry 5 application code will not be
transformed or weaved or whatever by AspectJ.
Tapestry 4 performs aspect oriented operations when it creates an
"enhanced" subclass. Tapestry 5 will do something similar, except
that it transforms the class as it is loaded. But this Tapestry AOP
support is internal to Tapestry (driven entirely off of annotations in
Tapestry 5).
This is part of the very careful split between Tapestry internal
implementation and Tapestry application development, something that's
all merged together in Tapestry 4.
The goal I'm following is that only the absolute minimum necessary is
exposed in the public space. Much of the code is and will be in the
org.apache.tapestry.internal package, with the message "hands off" ...
even though there will likely be a lot of tested, reusable code in
there. Tapestry needs the freedom to change its internals at any time,
without breaking any outside code. I may eventually split
tapestry-core into a pure API library (mostly annotations, plus a
scattering of interfaces and classes), and a seperate implementation
library.
On 4/27/06, James Carman <ja...@carmanconsulting.com> wrote:
> Yes, please don't make us use AspectJ to develop in tapestry. I don't
> care if you want to use AspectJ behind the scenes to implement Tapestry,
> but please don't make us have to weave aspects into our classes to get
> stuff done. Also, we need to figure out how to allow HiveMind to support
> aspects the way Spring does. I don't think it's going to be difficult. I
> just haven't had the time to sit down and code it up.
>
> > http://howardlewisship.com/blog/2006/04/gambling-on-aspectj.html
> >
> > It's a gamble for sure.
> >
> > Pls reassure me that my 9 team members will never have to look at,
> > learn, or understand anything about AspectJ to use T5. Ie. it will be
> > am implementation detail of T5 and not a "feature". Also, that any
> > mention of AspectJ will relegated to an "appendix" in the
> > documentation for T5 that 99.9999% of Tapestry 5 users can ignore.
> >
> > Geoff
> >
> > --
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator and PMC Chair, Apache Tapestry
Creator, Jakarta HiveMind
Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: AspectJ and T5
Posted by Howard Lewis Ship <hl...@gmail.com>.
Absolutely!
AspectJ will be part of the internal implementation of Tapestry. I'm
using it (so far) to enforce basic coding standards and contracts, and
to simplify code related to thread synchronization.
However, Tapestry 5 applications will not use AspectJ. AspectJ will
need to be on the runtime classpath, but Tapestry 5 applications will
not ever have to see it. Tapestry 5 application code will not be
transformed or weaved or whatever by AspectJ.
Tapestry 4 performs aspect oriented operations when it creates an
"enhanced" subclass. Tapestry 5 will do something similar, except
that it transforms the class as it is loaded. But this Tapestry AOP
support is internal to Tapestry (driven entirely off of annotations in
Tapestry 5).
This is part of the very careful split between Tapestry internal
implementation and Tapestry application development, something that's
all merged together in Tapestry 4.
The goal I'm following is that only the absolute minimum necessary is
exposed in the public space. Much of the code is and will be in the
org.apache.tapestry.internal package, with the message "hands off" ...
even though there will likely be a lot of tested, reusable code in
there. Tapestry needs the freedom to change its internals at any time,
without breaking any outside code. I may eventually split
tapestry-core into a pure API library (mostly annotations, plus a
scattering of interfaces and classes), and a seperate implementation
library.
On 4/27/06, James Carman <ja...@carmanconsulting.com> wrote:
> Yes, please don't make us use AspectJ to develop in tapestry. I don't
> care if you want to use AspectJ behind the scenes to implement Tapestry,
> but please don't make us have to weave aspects into our classes to get
> stuff done. Also, we need to figure out how to allow HiveMind to support
> aspects the way Spring does. I don't think it's going to be difficult. I
> just haven't had the time to sit down and code it up.
>
> > http://howardlewisship.com/blog/2006/04/gambling-on-aspectj.html
> >
> > It's a gamble for sure.
> >
> > Pls reassure me that my 9 team members will never have to look at,
> > learn, or understand anything about AspectJ to use T5. Ie. it will be
> > am implementation detail of T5 and not a "feature". Also, that any
> > mention of AspectJ will relegated to an "appendix" in the
> > documentation for T5 that 99.9999% of Tapestry 5 users can ignore.
> >
> > Geoff
> >
> > --
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator and PMC Chair, Apache Tapestry
Creator, Jakarta HiveMind
Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: AspectJ and T5
Posted by James Carman <ja...@carmanconsulting.com>.
Yes, please don't make us use AspectJ to develop in tapestry. I don't
care if you want to use AspectJ behind the scenes to implement Tapestry,
but please don't make us have to weave aspects into our classes to get
stuff done. Also, we need to figure out how to allow HiveMind to support
aspects the way Spring does. I don't think it's going to be difficult. I
just haven't had the time to sit down and code it up.
> http://howardlewisship.com/blog/2006/04/gambling-on-aspectj.html
>
> It's a gamble for sure.
>
> Pls reassure me that my 9 team members will never have to look at,
> learn, or understand anything about AspectJ to use T5. Ie. it will be
> am implementation detail of T5 and not a "feature". Also, that any
> mention of AspectJ will relegated to an "appendix" in the
> documentation for T5 that 99.9999% of Tapestry 5 users can ignore.
>
> Geoff
>
> --
> The Spindle guy. http://spindle.sf.net
> Blog: http://jroller.com/page/glongman
> Other interests: http://www.squidoo.com/spaceelevator/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
James Carman, President
Carman Consulting, Inc.
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org