[Design of AOP on JBoss (Aspects/JBoss)] - Expose AOP debugging information
by Wouterdb
Hi,
I attended the JBoss AOP session at AOSD 09 and learned there that the interfaces to JBoss AOP are being refactored. I think this is a good time to propose an introspective API for JBoss AOP.
With an introspective API it is possible to inspect all internal state of JBoss AOP that is relevant for application programmers, in terms of JBoss AOP abstractions. It shows how aspects integrate with the base code, which aspects are present, which bindings are present and who they are related. This allows for faster debugging by providing an opening in the black box.
In my work on AOP debugging (https://lirias.kuleuven.be/handle/123456789/222697) I have made a partial implementation of such an API. I support only method execution joinpoints and old style advices.
I would propose (at least) the following operations in the introspective API (per domain):
| //aspects
| AspectDefinition aspectForName(String aspectName)
| List<AspectDefinition> allAspects()
|
| //advices
| InterceptorFactory advicesFor(AspectDefinition aspect)
|
| //bindings
| AdviceBinding bindingForName(String name)
| List<AdviceBinding> allBindings()
|
| //reverse operation of AdviceBinding.getInterceptorFactories()
| List<AdviceBinding> bindingsFor(InterceptorFactory advice)
|
|
note 1: Advice applications indicate the presence of an advice on a certain joinpoint, caused by a certain binding. Thus an AdviceApplication references: an advice/InterceptorFactory, a binding/AdviceBinding, a cflow (residue/dynamic condition) and a joinpoint.
| List<AdviceApplication> applicationsFor(Method m)
| List<AdviceApplication> applicationsFor(Field m)
| List<AdviceApplication> applicationsFor(Class clazz)
|
| //for per instance AOP
| List<AdviceApplication> applicationsFor(Object object)
|
| List<AdviceApplication> applicationsFor(AdviceBinding binding)
| List<AdviceApplication> applicationsFor(InterceptorFactory advice)
|
|
| //JoinPoint
| // get all joinpoints on/in a class/method/field
| List<JoinPoint> joinPointsFor(Class m)
| List<JoinPoint> joinPointsFor(Method m)
| List<JoinPoint> joinPointsFor(Field m)
|
| List<AdviceApplication> applicationsFor(JoinPoint joinpoint)
| List<AdviceBinding> bindingsFor(JoinPoint joinpoint)
|
note 2 :Whether an advice applied to a field joinpoint is considered to be applied to the field or inside methods accessing the field and whether call joinpoints are part of the caller or the callee is unclear, this is open for discussion.
note 3 :It is (in some cases) possible to make these methods instance methods of their first argument, but it is beyond me whether this would be a good idea
If you would think such an API is a good thing to have and to build, the code of my implementation is available on http://distrinet.cs.kuleuven.be/software/AODA/versies/paper01/index.html in the packages JBoss Agent and JBoss Backend. The code for collecting some of the information is in JBossAgent adb.jagent.Agent. I could also give some pointers to similar things and perhaps some guidelines.
If you would think such an API is a good thing to have, but not to build, I'm willing to implement a first version myself, after note 2 and 3 have been resolved.
I hope I make sense,
Wouter
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4220604#4220604
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4220604
17 years
[Design of JBoss jBPM] - task attributes
by tom.baeyens＠jboss.com
there is a kind of loose relation between the execution and the task. loads of possibilities. this is an attempt to come to a comprehensive set of task proeprties in jpdl so that a) the properties are intuitive and b) they cover all use cases scenarios.
so the following i would see as attributes on the task activity in jpdl:
completion = "last | first | unsynchronized | {int} | {percentage}"
completion indicates when this task is considered complete in the context of subtasks.
last is the default and means that this task is considered complete when the last subtask completes.
first means that this task is considered complete when the fist subtask completes. The remaining tasks will be left open. Another attribute remaining-subtasks="keep | cancel" could be introduced to specify what has to happen with the remaining subtasks.
unsynchronized means that after creation of the task, the process execution will continue and the task will remain open.
{int} would specify a number of tasks that have to be completed before this task is considered completed. potentially, we could add a filter based on outcome of the tasks. e.g. completion="5 approve, disapprove" would mean that this task completes with outcome approve when the 5th subtasks completed with outcome approve, otherwise, (when no 5 tasks approve tasks can be reached) this task completes with disapprove.
{percentage} would be similar to {int}, but this time it specifies the number of tasks that have to be completed as a % of the total number of tasks.
on-cancel = "continue | cascade | throw"
on-cancel specifies what needs to happen when this task is cancelled.
continue is the default and means that the execution is triggered when this task is cancelled.
cascade means that the whole process instance is cancelled when this task is cancelled
throw means that cancelling this task is not allowed and an exception will be thrown.
on-signal = "keep | cancel"
specifies what happens with this task when the related execution is signalled. this can happen because of a timer that fires on the tasks or just because this signal is given programmatically.
keep means that the task is left as is, but the task will be updated so that it will not signal the execution when it completes.
cancel means that the task is cancelled when the execution is signalled.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4220566#4220566
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4220566
17 years
[Design of Messaging on JBoss (Messaging/JBoss)] - Re: management notifications for JBM2
by timfox
"jmesnil" wrote : I'm adding notifications to JBM2 trunk.
| Currently we have:
|
| BINDING_ADDED / BINDING_REMOVED -> when queues (or diverts) are created/deleted
| SECURITY_AUTHENTICATION_VIOLATION -> when user authentication fails
| SECURITY_PERMISSION_VIOLATION -> when user has not the required permission
| CONSUMER_CREATED / CONSUMER_CLOSED
|
| for CONSUMER_CREATED / CONSUMER_CLOSED, I'm adding to the notifications the consumer count for the given queue. Using this in a filter, we can be notified when e.g. there is no consumer on the queue.
|
| What is missing is notifications when producers are created/closed since the producer concept is on the client side and the sessions is handling the messages sent by the clients on the server side.
| However it'd be interesting to be notified when someone starts/stops producing on an address
|
| I'm planning to add a few more notifications:
|
| PAGING_STARTED / PAGING_STOPPPED -> when paging is activated
| NODE_ACTIVATED -> when a backup node is activated and becomes the live node.
|
| After that, there are other notifications that I could add but they are lower priority:
|
For beta, let's just do the first ones. The lower priority ones can happen some time later.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4220562#4220562
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4220562
17 years