[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [aspectj-users] Aspectj discussion
|
Mohan Radhakrishnan wrote:
Hi
Thanks. Yes. I read the doc. that
explains design patterns based on AOP. The Command manager code here
also helps. Actually I started using introductions like this and
thought that this is not reusable. That is why I wanted reusable ideas.
package aspectworks;
public class AccountFactory{
private AccountFactory(){
}
public Account getNewAccount(){
Account account = createAccount();
System.out.println( "Account created" );
return account;
}
public Account createAccount(){
return new CheckingAccount();
}
private static aspect SingletonAspect{
private static ThreadLocal
AccountFactory.holder_ = new ThreadLocal();
private static AccountFactory
AccountFactory.factory = null;
private static Class AccountFactory.clazz
= AccountFactory.class;
public SingletonAspect(){
}
public static AccountFactory
AccountFactory.getInstance() {
if ( holder_.get() == null ) {
synchronized( clazz ){
if( factory == null ) {
factory = new AccountFactory();
}
holder_.set( Boolean.TRUE );
}
}
return factory;
}
}
}
Sean R. Drucker wrote:
I would like to learn about "Weaving different advices for the same class at
different times without stopping the JVM" as well. If you find some source,
please post it back this list.
Thanks... Sean
----- Original Message -----
From: "Mohan Radhakrishnan" <mradhakrishnan@xxxxxxxxxxxxxxxx>
To: <aspectj-users@xxxxxxxxxxx>
Sent: Tuesday, May 06, 2003 7:48 AM
Subject: [aspectj-users] Aspectj discussion
Hi,
I am a newbie. Is this a very low volume list? I am interested in using
aspects. Have read some of the code of the nanning project since it is a
framework using dynamic proxies etc.
Is there a more popular forum somewhere? I don't receive many mails.
The idea is to learn about
1. Reusable aspects.
2. Weaving diffent advices for the same class at different times withou t
stopping the JVM.
3. Aspect patterns
Mohan
_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/aspectj-users
_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/aspectj-users
"Weaving diffent advices for the same class at different times without stopping the JVM." If you mean with this changing the behavior of an advice at runtime, you could use an approach based on delegating advice code to commands. You could have a class that decides which command to execute. Here is a draft to give you some ideas (not compiled, untested code follows):
- Have a generic command interface:
public interface ICommand
{
// p contains info about the JoinPoint that executed this command
// Additional parameters would be necessary.
public Object doAdvice(JoinPoint p);
}
-Have a command manager that decides what command to execute. This
decision could be taken using configuration files(for static desicions)
and/or the state of your system (for runtime decision).
public interface ICommandManager
{
public boolean hasCommand(String key);
public void setCommand(String key, ICommand c);
public void removeCommand(String key);
public ICommand getCommand(String key) throws
CommandNotFoundException;
}
Note that you can modify at runtime the commands avalaible for a
given key. Each key could represent an unique name for advices. For
example, using an administration application, an administrator could
associate commands with advices at runtime or change that
associations. This results in changes in runtime behaviour of the
system.
- Finally you could use all of this from an advice in an aspect:
package sample;
public aspect MyAspect
{
...
pointcut mypointcut(): call(* sample.otherpackage.*.set*(..));
before(): mypointcut()
{
try
{
ICommand
delegate=getCommandManager().getCommand("sample.MyAspect.mypointcut.before");
delegate.doAdvice(thisJoinPoint);
}catch(CommandNotFoundException ex)
{
// If not command found do nothing.
}
}
...
}
Of course this approach doesn't allow to change a pointcut's
definition at runtime. If you want this you should look for another AOP
language or framework.
Hope this helps you,
Enrique J. Amodeo Rubio
Try this (again uncompiled untested code):
public interface Singleton
{
// We use this interface with the sole purpose of marking which
clases
// are singleton. It is empty
}
public SingletonAspect
{
private Map instances=new HashMap();
pointcut instanceCreation(): initialization(Singleton+.new());
Singleton around(): instanceCreation()
{
Singleton r=null;
// Localize the class of the constructor being called
Class
instanceClass=thisJoinPointStaticPart.getSourceLocation().getWithinType();
if(instances.containsKey(instanceClass))
r=(Singleton)instances.get(instanceClass);
else
{
r=(Singleton)proceed();
instances.put(instanceClass, r);
}
return r;
}
}
So if you want the class sample.mypackage.MyClass to be a Singleton you
write the following aspects:
public aspect MyClassIsASingleton
{
// Make MyClass implements Singleton
declare parents: sample.mypackage.MyClass implements Singleton;
}
As you can see this is truly reusable aspect. It's the same idea
exposed in
http://www.cs.ubc.ca/~jan/AODPs
As a guideline I prefer not to use introductions. Instead I use marker
interfaces and Maps and Sets in the aspect.
This approach has a performance penalty if you have a huge number of
classes (or objects, in the case of subject/observer pattern in
http://www.cs.ubc.ca/~jan/AODPs ). The lookup (and insertion) time in
the Map will degrade if we have a lot of entries (How many? I haven't
measured it yet). But in the case of the SingletonAspect I expect you
don't have more than 100 singletons in your system so performance it's
not a problem. Other case could be the subject/observer pattern
(potentially for hundred of thousand objects in really big systems).
Enrique J. Amodeo Rubio.