Hi Alexander,
that’s really a deal ;) So, I would like to offer sample code to show the
problem using a concrete example. Hopefully, there is really a solution
possible when using:
- Inter-type definitions (even possible in Spring aspects via so-called
“Introductions” when using “declare-parents”)
- Aspects instantiated per “this” or “target”
Would be kind to check whether this is really possible here. I’m really looking
forward to reading from you again :-)
Here comes my Spring AspectJ annotated aspect:
/* AOP aspect running on all methods being called on objects of type
“IdmAdaptor” */
package com.xxxxx.fs.idm.ws.aop;
@Aspect
public class FSConnectionAspect {
/* match all methods located in classes implementing interface
“IdmAdaptor” and limited to Spring bean“fsIdmAdaptor” */
@Pointcut("execution(within(com.xxxxx.fs.idm.ws.IdmAdaptor+) and
bean(fsIdmAdaptor)")
public void operations() {
}
@Around("operations")
public Object handleConnection(ProceedingJoinPointjoinpoint) {
Object retVal = null;
try {
Connection conn =
ConnectionManager.getConnection(<host>, <port>, <mode>,<user>, <password>);
try {
conn.connect();
Object[] args = joinpoint.getArgs();
/*
* how to pass and access the connection object
to the
* pointcut implementation without changing the
interface method
* signature there? Here in the example the
signature is
* “public boolean
enableAccount(EnableAccountType parameters)”, see below!
*/
Object result = joinpoint.proceed(args);
} catch (IOException e) {
} catch (AuthenticationException e) {
} catch(MaximumNumberOfSessionsExceededException e) {
} finally {
if (conn.isConnected()) {
try {
conn.close();
} catch (IOException e) {
}
}
}
} catch (Throwable e) {
}
return retVal;
}
}
Here comes my Spring bean implementing the “IdmAdaptor” interface where the
pointcut defined in the aspect works with. It has to use the connection object
administrated within the aspect. The question: how to do that?
package com.xxxxx.fs.idm.ws.impl;
public class FSIdmAdaptor implements IdmAdaptor,
ApplicationContextAware {
...
@Override
public boolean enableAccount(EnableAccountTypeparameters)
throws IdmFaultMessage {
boolean retVal = false;
...
//here the connection object is used created and managed in the
Spring AspectJ aspect
AdminService adminService =conn.getService(AdminService.class)
...
return retVal;
}
...
@Override
public void setApplicationContext(ApplicationContextapplicationContext)
throws BeansException {
this.applicationContext = applicationContext;
}
}
Am 18. Februar 2015 23:34:44 MEZ, schrieb Alexander Kriegisch
<alexan...@kriegisch.name>:
>I forgot to mention: An alternative approach might be aspects
>instantiated perthis or pertarget, keeping state for your objects if
>you want to avoid ITD.
>
>
>> Hi Holger.
>>
>> Some more or less extensive code snippets would be helpful, but as
>far as I
>> understand you want to inject a value into certain objects. Unless
>there is
>> some kind of "value store" such as a map of key/value pairs or so in
>your
>> object, you can use ITD (inter-type definition) in order to add
>members to the
>> desired types.
>>
>> If you provide some sample code - ideally a fully functional SSCCE
>> (http://sscce.org/) - I am sure someone will suggest an aspect which
>will show
>> you how to do that based on your code. Concrete examples are usually
>more
>> helpful than abstract ones.
>>
>> Tit for tat, code for code - deal? ;-)
>>
>> Regards
>> --
>> Alexander Kriegisch
>> http://scrum-master.de
>>
>>
>> Holger King schrieb am 18.02.2015 23:04:
>>
>>> I just moved a cross-cutting-concern (the creation and closing of a
>>> non-JDBC-connection) from a web service to a Spring AOP AspectJ
>>> implementation. This aspect is being called each time any method of
>the
>>> web service interface is requested.
>>>
>>> The problem: the pointcut (= web service implementation) needs the
>>> connection being created in the advice! But as the method signatures
>are
>>> defined by the web service contract (the WSDL document has been
>>> converted to Java classes via "wsdl2java" based on the contract
>first
>>> approach) they cannot be adapted and modified to take over the new
>>> connection parameter.
>>>
>>> It's clear that the other way around where the AspectJ advice gets
>the
>>> parameter used in the method call matching the pointcut defintion is
>
>>> possible.
>>>
>>> Even changing existing parameter values and passing the same
>arguments
>>> list (having the same types) to the implementation where the
>pointcut
>>> matches does work (using "&& args()" in the pointcut in combination
>with
>>> joinpoint.proceed(jointpoint.getArgs()))
>>>
>>> But here the problem exists, as it's not sufficient to just change
>>> parameter values. Instead, a complete new variable owning the
>connection
>>> created in the advice needs to be accessible in the objects the
>pointcut
>>> matches.
>>>
>>> Do you have any idea how to realize that? Or is it a complete wrong
>>> approach to do that using Java aspects - although connection
>handling
>>> might be a typical cross-cutting-concern?
>>
>
>_______________________________________________
>aspectj-users mailing list
>aspectj-users@eclipse.org
>To change your delivery options, retrieve your password, or unsubscribe
>from this list, visit
>https://dev.eclipse.org/mailman/listinfo/aspectj-users
_______________________________________________
aspectj-users mailing list
aspectj-users@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/aspectj-users
