Are there any such mechanism in WAS v6?

As for EJB 3.0, adding interceptors requires annotations that is modificatio
n of source code, while I need mechanism without modification of component s
ource code.

[ Post a follow-up to this message ]

mutilin@ispras.ru wrote:
> Are there any such mechanism in WAS v6?

No
>
> As for EJB 3.0, adding interceptors requires annotations that is
> modification of source code, while I need mechanism without
> modification of component source code.

What are you trying to achieve with these interceptors? Maybe we can
propose an alternative solution if we know why you think you need this
non-standard feature.

[ Post a follow-up to this message ]

>What are you trying to achieve with these interceptors? Maybe we can
>propose an alternative solution if we know why you think you need this
>non-standard feature.
It would be great! I want to suspend certains invocations of EJB components 
to test defferent interleavings of these invocations. To check that componen
t works fine regardless of thread/process schedulling and network delays.

To accomplish this, I need to pass the control before execution of invocatio
n of EJB method to my method, in which I can suspend or continue invocation.

[ Post a follow-up to this message ]

Adding interceptors in EJB 3.0 does not require modification of source code 
-- interceptors can be defined using XML instead.  Or you may use a combinat
ion of both.  In general, all EJB3 functions that can be defined using annot
ations can alternately be d
efined using XML.

mutilin@ispras.ru wrote:[vbcol=seagreen]
> Are there any such mechanism in WAS v6?
>
> As for EJB 3.0, adding interceptors requires annotations that is modification of s
ource code, while I need mechanism without modification of component source code.[/v
bcol]

[ Post a follow-up to this message ]

mutilin@ispras.ru wrote: 
[vbcol=seagreen]
> It would be great! I want to suspend certains invocations of EJB
> components to test defferent interleavings of these invocations. To
> check that component works fine regardless of thread/process
> schedulling and network delays.

I don't understand why you would want to do this. Are you testing to see
if the container actually works? That is guaranteed by compliance to the
J2EE specification, and if you find problems you can report them to IBM
through normal support channels. It would seem to be more productive for
you to test your own code, rather than our code ...

[ Post a follow-up to this message ]

>I don't understand why you would want to do this. Are you testing to see
>if the container actually works? That is guaranteed by compliance to the
>J2EE specification, and if you find problems you can report them to IBM
>through normal support channels. It would seem to be more productive for
>you to test your own code, rather than our code ...

I don't want to test IBM container implementation. I want to test concurrent
 issues of my application. It is true that container do much work to control
 the concurrency, but there is still a room for errors.
I found at least three sources of errors:
1. If I do some synchronization to shared data manually, I can do something 
wrong.
2. The incorrect settings of transaction context (Required, ...)
3. Wrong database isolation level (Read uncommited, ...)

[ Post a follow-up to this message ]

>Adding interceptors in EJB 3.0 does not require modification of source code --
>interceptors can be defined using XML instead. Or you may use a combination
>of both. In general, all EJB3 functions that can be defined using annotatio
ns
>can alternately be defined using XML.
It is good, that there is no need to modify the code.
Are you planning to make some mechanism for configuration the containers of 
all aplications working in the same profile? For instance, suppose that I ne
ed to add some extra security checks for each incoming call, how can I do th
at?

[ Post a follow-up to this message ]

mutilin@ispras.ru wrote: 
[vbcol=seagreen]
> I don't want to test IBM container implementation. I want to test concurre
nt issues of my application. It is true that container do much work to contr
ol the concurrency, but there is still a room for errors.
> I found at least three sources of errors:
> 1. If I do some synchronization to shared data manually, I can do somethin
g wrong.
> 2. The incorrect settings of transaction context (Required, ...)
> 3. Wrong database isolation level (Read uncommited, ...)
>

You can test this without needing interceptors. Lots of people already
do. You just need good test tools.

[ Post a follow-up to this message ]

mutilin@ispras.ru wrote: 
[vbcol=seagreen]
> It is good, that there is no need to modify the code. Are you
> planning to make some mechanism for configuration the containers of
> all aplications working in the same profile? For instance, suppose
> that I need to add some extra security checks for each incoming call,
> how can I do that?
>
You can do that now, using JAAS login modules.

[ Post a follow-up to this message ]

>You can test this without needing interceptors. Lots of people already
>do. You just need good test tools.
Please, could you recommend good tools for testing concurrency issues?

[ Post a follow-up to this message ]