Re: Need to switch to subclassing?
Gurkan, I obviously DO call a method of a bean instance. So this scenario is
perfectly valid from the spec perspective.
LieGrue,
strub
--- Gurkan Erdogdu gurkanerdo...@yahoo.com schrieb am Di, 11.5.2010:
Von: Gurkan Erdogdu gurkanerdo...@yahoo.com
Betreff: Re: Need to switch to subclassing?
An: dev@openwebbeans.apache.org
Datum: Dienstag, 11. Mai, 2010 08:00 Uhr
Not expected to work. For interceptor
working, you have to call method on bean instance. So, move
your method into other class (this must not be hard!)
Spec. does not talk about anything about proxied or
subclassing. It is leaved to implementation choice.
Thanks;
--Gurkan
From: Mark Struberg strub...@yahoo.de
To: dev@openwebbeans.apache.org
Sent: Tue, May 11, 2010 8:30:15 AM
Subject: Need to switch to subclassing?
Hi!
There is a subtle difference between implementing
interceptors via proxy or via subclasses.
I have the following service which imports data from a
legacy system into my db. Since commits are very performance
intense, they should get imported in packages of 100. So
I'll get 100 'Employees' from my legacy system and then call
a @Transactional method to store them in my own database.
public void ImportService() {
public void importEmployee() {
ListLegacyEmployee les;
while ((les =
getNext100EmployeesFromLegacy()) != nul) {
importLegacyEmployees(le);
}
}
@Transactional
protected
importLegacyEmployees(ListLegacyEmployee les) {
for (LegacyEmployee le: les) {
employeeService.store(le);
}
}
}
This would actually _not_ when using proxies for the
interceptor handling, because calling a method on an own
class doesn't invoke the proxyhandler.
So is this expected to work?
Sure, I could easily move the importLegacyEmployees() to an
own service, but that would infringe classic OOP heavily
imo.
Gurkan, what does the spec say here, I did find nothing.
The old spec explicitly mentioned that we need to use
subclassing, but I cannot find this anymore.
LieGrue,
strub
Re: Need to switch to subclassing?
This will also not work on EJB containers. For example, in EJB Hello
@Interceptors(MyInterceptor.class)
public Hello implemenet IHello{
public void method1(){
method2();
}
public void method2(){
...
}
}
@Local
public interface IHello{
public void method1();
public void method2();
}
main(){
IHello proxy = getting from intitial context
proxy.method1();
}
Calling method2() from method1() does not trigger interception. Interceptor is
called ones when client calls method1() on bean proxy. You could try it on
OpenEJB for example
Thanks;
Gurkan
From: Mark Struberg strub...@yahoo.de
To: dev@openwebbeans.apache.org
Sent: Tue, May 11, 2010 8:30:15 AM
Subject: Need to switch to subclassing?
Hi!
There is a subtle difference between implementing interceptors via proxy or via
subclasses.
I have the following service which imports data from a legacy system into my
db. Since commits are very performance intense, they should get imported in
packages of 100. So I'll get 100 'Employees' from my legacy system and then
call a @Transactional method to store them in my own database.
public void ImportService() {
public void importEmployee() {
ListLegacyEmployee les;
while ((les = getNext100EmployeesFromLegacy()) != nul) {
importLegacyEmployees(le);
}
}
@Transactional
protected importLegacyEmployees(ListLegacyEmployee les) {
for (LegacyEmployee le: les) {
employeeService.store(le);
}
}
}
This would actually _not_ when using proxies for the interceptor handling,
because calling a method on an own class doesn't invoke the proxyhandler.
So is this expected to work?
Sure, I could easily move the importLegacyEmployees() to an own service, but
that would infringe classic OOP heavily imo.
Gurkan, what does the spec say here, I did find nothing. The old spec
explicitly mentioned that we need to use subclassing, but I cannot find this
anymore.
LieGrue,
strub
Re: Need to switch to subclassing?
Call on proxy instance not actual bean instance.
From: Mark Struberg strub...@yahoo.de
To: dev@openwebbeans.apache.org
Sent: Tue, May 11, 2010 9:07:20 AM
Subject: Re: Need to switch to subclassing?
Gurkan, I obviously DO call a method of a bean instance. So this scenario is
perfectly valid from the spec perspective.
LieGrue,
strub
--- Gurkan Erdogdu gurkanerdo...@yahoo.com schrieb am Di, 11.5.2010:
Von: Gurkan Erdogdu gurkanerdo...@yahoo.com
Betreff: Re: Need to switch to subclassing?
An: dev@openwebbeans.apache.org
Datum: Dienstag, 11. Mai, 2010 08:00 Uhr
Not expected to work. For interceptor
working, you have to call method on bean instance. So, move
your method into other class (this must not be hard!)
Spec. does not talk about anything about proxied or
subclassing. It is leaved to implementation choice.
Thanks;
--Gurkan
From: Mark Struberg strub...@yahoo.de
To: dev@openwebbeans.apache.org
Sent: Tue, May 11, 2010 8:30:15 AM
Subject: Need to switch to subclassing?
Hi!
There is a subtle difference between implementing
interceptors via proxy or via subclasses.
I have the following service which imports data from a
legacy system into my db. Since commits are very performance
intense, they should get imported in packages of 100. So
I'll get 100 'Employees' from my legacy system and then call
a @Transactional method to store them in my own database.
public void ImportService() {
public void importEmployee() {
ListLegacyEmployee les;
while ((les =
getNext100EmployeesFromLegacy()) != nul) {
importLegacyEmployees(le);
}
}
@Transactional
protected
importLegacyEmployees(ListLegacyEmployee les) {
for (LegacyEmployee le: les) {
employeeService.store(le);
}
}
}
This would actually _not_ when using proxies for the
interceptor handling, because calling a method on an own
class doesn't invoke the proxyhandler.
So is this expected to work?
Sure, I could easily move the importLegacyEmployees() to an
own service, but that would infringe classic OOP heavily
imo.
Gurkan, what does the spec say here, I did find nothing.
The old spec explicitly mentioned that we need to use
subclassing, but I cannot find this anymore.
LieGrue,
strub
Re: Need to switch to subclassing?
I could not find this explicitly stated in the EJB spec neither - so maybe
OpenEJB needs a fix too? :D
Nah, just like to know what the 299 spec intends. Such things should work the
same in Weld, CanDI, OWB and all other JSR-299 containers. I bet there are only
very few developers (users!) out there which would find a bug caused by such a
behaviour.
So my main concern is not the behaviour itself, but that it's currently not
really well defined how it should behave.
I'll post this also on the weld list to get a feeling what they expect it to do.
LieGrue,
strub
--- On Tue, 5/11/10, Gurkan Erdogdu gurkanerdo...@yahoo.com wrote:
From: Gurkan Erdogdu gurkanerdo...@yahoo.com
Subject: Re: Need to switch to subclassing?
To: dev@openwebbeans.apache.org
Date: Tuesday, May 11, 2010, 6:11 AM
This will also not work on EJB
containers. For example, in EJB Hello
@Interceptors(MyInterceptor.class)
public Hello implemenet IHello{
public void method1(){
method2();
}
public void method2(){
...
}
}
@Local
public interface IHello{
public void method1();
public void method2();
}
main(){
IHello proxy = getting from intitial context
proxy.method1();
}
Calling method2() from method1() does not trigger
interception. Interceptor is called ones when client calls
method1() on bean proxy. You could try it on OpenEJB for
example
Thanks;
Gurkan
From: Mark Struberg strub...@yahoo.de
To: dev@openwebbeans.apache.org
Sent: Tue, May 11, 2010 8:30:15 AM
Subject: Need to switch to subclassing?
Hi!
There is a subtle difference between implementing
interceptors via proxy or via subclasses.
I have the following service which imports data from a
legacy system into my db. Since commits are very performance
intense, they should get imported in packages of 100. So
I'll get 100 'Employees' from my legacy system and then call
a @Transactional method to store them in my own database.
public void ImportService() {
public void importEmployee() {
ListLegacyEmployee les;
while ((les =
getNext100EmployeesFromLegacy()) != nul) {
importLegacyEmployees(le);
}
}
@Transactional
protected
importLegacyEmployees(ListLegacyEmployee les) {
for (LegacyEmployee le: les) {
employeeService.store(le);
}
}
}
This would actually _not_ when using proxies for the
interceptor handling, because calling a method on an own
class doesn't invoke the proxyhandler.
So is this expected to work?
Sure, I could easily move the importLegacyEmployees() to an
own service, but that would infringe classic OOP heavily
imo.
Gurkan, what does the spec say here, I did find nothing.
The old spec explicitly mentioned that we need to use
subclassing, but I cannot find this anymore.
LieGrue,
strub
Re: Need to switch to subclassing?
http://openejb.979440.n4.nabble.com/Possible-OPENEJB-Bug-with-Interceptors-td982087.html
From: Mark Struberg strub...@yahoo.de
To: dev@openwebbeans.apache.org
Sent: Tue, May 11, 2010 9:22:11 AM
Subject: Re: Need to switch to subclassing?
I could not find this explicitly stated in the EJB spec neither - so maybe
OpenEJB needs a fix too? :D
Nah, just like to know what the 299 spec intends. Such things should work the
same in Weld, CanDI, OWB and all other JSR-299 containers. I bet there are only
very few developers (users!) out there which would find a bug caused by such a
behaviour.
So my main concern is not the behaviour itself, but that it's currently not
really well defined how it should behave.
I'll post this also on the weld list to get a feeling what they expect it to do.
LieGrue,
strub
--- On Tue, 5/11/10, Gurkan Erdogdu gurkanerdo...@yahoo.com wrote:
From: Gurkan Erdogdu gurkanerdo...@yahoo.com
Subject: Re: Need to switch to subclassing?
To: dev@openwebbeans.apache.org
Date: Tuesday, May 11, 2010, 6:11 AM
This will also not work on EJB
containers. For example, in EJB Hello
@Interceptors(MyInterceptor.class)
public Hello implemenet IHello{
public void method1(){
method2();
}
public void method2(){
...
}
}
@Local
public interface IHello{
public void method1();
public void method2();
}
main(){
IHello proxy = getting from intitial context
proxy.method1();
}
Calling method2() from method1() does not trigger
interception. Interceptor is called ones when client calls
method1() on bean proxy. You could try it on OpenEJB for
example
Thanks;
Gurkan
From: Mark Struberg strub...@yahoo.de
To: dev@openwebbeans.apache.org
Sent: Tue, May 11, 2010 8:30:15 AM
Subject: Need to switch to subclassing?
Hi!
There is a subtle difference between implementing
interceptors via proxy or via subclasses.
I have the following service which imports data from a
legacy system into my db. Since commits are very performance
intense, they should get imported in packages of 100. So
I'll get 100 'Employees' from my legacy system and then call
a @Transactional method to store them in my own database.
public void ImportService() {
public void importEmployee() {
ListLegacyEmployee les;
while ((les =
getNext100EmployeesFromLegacy()) != nul) {
importLegacyEmployees(le);
}
}
@Transactional
protected
importLegacyEmployees(ListLegacyEmployee les) {
for (LegacyEmployee le: les) {
employeeService.store(le);
}
}
}
This would actually _not_ when using proxies for the
interceptor handling, because calling a method on an own
class doesn't invoke the proxyhandler.
So is this expected to work?
Sure, I could easily move the importLegacyEmployees() to an
own service, but that would infringe classic OOP heavily
imo.
Gurkan, what does the spec say here, I did find nothing.
The old spec explicitly mentioned that we need to use
subclassing, but I cannot find this anymore.
LieGrue,
strub
Re: Need to switch to subclassing?
Such things should work the same in Weld, CanDI, OWB and all other
JSR-299 containers
Mmmm, I am not the same. Java EE specifications do not explicitly define some
behaviors. Containers could implement those areas with their own way but they
are all required to pass the Java EE TCK. Therefore, one behavior in one
container may be differently functioned from other containers. This is mostly
observed on container specific security managements.
This is the main motivation behind the TCKs.
Thanks;
--Gurkan
From: Mark Struberg strub...@yahoo.de
To: dev@openwebbeans.apache.org
Sent: Tue, May 11, 2010 9:22:11 AM
Subject: Re: Need to switch to subclassing?
I could not find this explicitly stated in the EJB spec neither - so maybe
OpenEJB needs a fix too? :D
Nah, just like to know what the 299 spec intends. Such things should work the
same in Weld, CanDI, OWB and all other JSR-299 containers. I bet there are only
very few developers (users!) out there which would find a bug caused by such a
behaviour.
So my main concern is not the behaviour itself, but that it's currently not
really well defined how it should behave.
I'll post this also on the weld list to get a feeling what they expect it to do.
LieGrue,
strub
--- On Tue, 5/11/10, Gurkan Erdogdu gurkanerdo...@yahoo.com wrote:
From: Gurkan Erdogdu gurkanerdo...@yahoo.com
Subject: Re: Need to switch to subclassing?
To: dev@openwebbeans.apache.org
Date: Tuesday, May 11, 2010, 6:11 AM
This will also not work on EJB
containers. For example, in EJB Hello
@Interceptors(MyInterceptor.class)
public Hello implemenet IHello{
public void method1(){
method2();
}
public void method2(){
...
}
}
@Local
public interface IHello{
public void method1();
public void method2();
}
main(){
IHello proxy = getting from intitial context
proxy.method1();
}
Calling method2() from method1() does not trigger
interception. Interceptor is called ones when client calls
method1() on bean proxy. You could try it on OpenEJB for
example
Thanks;
Gurkan
From: Mark Struberg strub...@yahoo.de
To: dev@openwebbeans.apache.org
Sent: Tue, May 11, 2010 8:30:15 AM
Subject: Need to switch to subclassing?
Hi!
There is a subtle difference between implementing
interceptors via proxy or via subclasses.
I have the following service which imports data from a
legacy system into my db. Since commits are very performance
intense, they should get imported in packages of 100. So
I'll get 100 'Employees' from my legacy system and then call
a @Transactional method to store them in my own database.
public void ImportService() {
public void importEmployee() {
ListLegacyEmployee les;
while ((les =
getNext100EmployeesFromLegacy()) != nul) {
importLegacyEmployees(le);
}
}
@Transactional
protected
importLegacyEmployees(ListLegacyEmployee les) {
for (LegacyEmployee le: les) {
employeeService.store(le);
}
}
}
This would actually _not_ when using proxies for the
interceptor handling, because calling a method on an own
class doesn't invoke the proxyhandler.
So is this expected to work?
Sure, I could easily move the importLegacyEmployees() to an
own service, but that would infringe classic OOP heavily
imo.
Gurkan, what does the spec say here, I did find nothing.
The old spec explicitly mentioned that we need to use
subclassing, but I cannot find this anymore.
LieGrue,
strub
Re: Need to switch to subclassing?
Oki let me rephrase: I'd like to know if the spec (or Gavin) intends to define
this behaviour or if it is 'intentionally left undefined'.
LieGrue,
strub
--- On Tue, 5/11/10, Gurkan Erdogdu gurkanerdo...@yahoo.com wrote:
From: Gurkan Erdogdu gurkanerdo...@yahoo.com
Subject: Re: Need to switch to subclassing?
To: dev@openwebbeans.apache.org
Date: Tuesday, May 11, 2010, 6:47 AM
Such things should
work the same in Weld, CanDI, OWB and all other
JSR-299 containers
Mmmm, I am not the same. Java EE specifications do not
explicitly define some behaviors. Containers could implement
those areas with their own way but they are all required to
pass the Java EE TCK. Therefore, one behavior in one
container may be differently functioned from other
containers. This is mostly observed on container specific
security managements.
This is the main motivation behind the TCKs.
Thanks;
--Gurkan
From: Mark Struberg strub...@yahoo.de
To: dev@openwebbeans.apache.org
Sent: Tue, May 11, 2010 9:22:11 AM
Subject: Re: Need to switch to subclassing?
I could not find this explicitly stated in the EJB spec
neither - so maybe OpenEJB needs a fix too? :D
Nah, just like to know what the 299 spec intends. Such
things should work the same in Weld, CanDI, OWB and all
other JSR-299 containers. I bet there are only very few
developers (users!) out there which would find a bug caused
by such a behaviour.
So my main concern is not the behaviour itself, but that
it's currently not really well defined how it should
behave.
I'll post this also on the weld list to get a feeling what
they expect it to do.
LieGrue,
strub
--- On Tue, 5/11/10, Gurkan Erdogdu gurkanerdo...@yahoo.com
wrote:
From: Gurkan Erdogdu gurkanerdo...@yahoo.com
Subject: Re: Need to switch to subclassing?
To: dev@openwebbeans.apache.org
Date: Tuesday, May 11, 2010, 6:11 AM
This will also not work on EJB
containers. For example, in EJB Hello
@Interceptors(MyInterceptor.class)
public Hello implemenet IHello{
public void method1(){
method2();
}
public void method2(){
...
}
}
@Local
public interface IHello{
public void method1();
public void method2();
}
main(){
IHello proxy = getting from
intitial context
proxy.method1();
}
Calling method2() from method1() does not trigger
interception. Interceptor is called ones when client
calls
method1() on bean proxy. You could try it on OpenEJB
for
example
Thanks;
Gurkan
From: Mark Struberg strub...@yahoo.de
To: dev@openwebbeans.apache.org
Sent: Tue, May 11, 2010 8:30:15 AM
Subject: Need to switch to subclassing?
Hi!
There is a subtle difference between implementing
interceptors via proxy or via subclasses.
I have the following service which imports data from
a
legacy system into my db. Since commits are very
performance
intense, they should get imported in packages of 100.
So
I'll get 100 'Employees' from my legacy system and
then call
a @Transactional method to store them in my own
database.
public void ImportService() {
public void importEmployee() {
ListLegacyEmployee
les;
while ((les =
getNext100EmployeesFromLegacy()) != nul) {
importLegacyEmployees(le);
}
}
�...@transactional
protected
importLegacyEmployees(ListLegacyEmployee les)
{
for (LegacyEmployee le: les)
{
employeeService.store(le);
}
}
}
This would actually _not_ when using proxies for the
interceptor handling, because calling a method on an
own
class doesn't invoke the proxyhandler.
So is this expected to work?
Sure, I could easily move the importLegacyEmployees()
to an
own service, but that would infringe classic OOP
heavily
imo.
Gurkan, what does the spec say here, I did find
nothing.
The old spec explicitly mentioned that we need to use
subclassing, but I cannot find this anymore.
LieGrue,
strub
Re: Need to switch to subclassing?
Here's something that will solve your problem, use AspectJ.
On Tue, May 11, 2010 at 2:51 AM, Mark Struberg strub...@yahoo.de wrote:
Oki let me rephrase: I'd like to know if the spec (or Gavin) intends to
define this behaviour or if it is 'intentionally left undefined'.
LieGrue,
strub
--- On Tue, 5/11/10, Gurkan Erdogdu gurkanerdo...@yahoo.com wrote:
From: Gurkan Erdogdu gurkanerdo...@yahoo.com
Subject: Re: Need to switch to subclassing?
To: dev@openwebbeans.apache.org
Date: Tuesday, May 11, 2010, 6:47 AM
Such things should
work the same in Weld, CanDI, OWB and all other
JSR-299 containers
Mmmm, I am not the same. Java EE specifications do not
explicitly define some behaviors. Containers could implement
those areas with their own way but they are all required to
pass the Java EE TCK. Therefore, one behavior in one
container may be differently functioned from other
containers. This is mostly observed on container specific
security managements.
This is the main motivation behind the TCKs.
Thanks;
--Gurkan
From: Mark Struberg strub...@yahoo.de
To: dev@openwebbeans.apache.org
Sent: Tue, May 11, 2010 9:22:11 AM
Subject: Re: Need to switch to subclassing?
I could not find this explicitly stated in the EJB spec
neither - so maybe OpenEJB needs a fix too? :D
Nah, just like to know what the 299 spec intends. Such
things should work the same in Weld, CanDI, OWB and all
other JSR-299 containers. I bet there are only very few
developers (users!) out there which would find a bug caused
by such a behaviour.
So my main concern is not the behaviour itself, but that
it's currently not really well defined how it should
behave.
I'll post this also on the weld list to get a feeling what
they expect it to do.
LieGrue,
strub
--- On Tue, 5/11/10, Gurkan Erdogdu gurkanerdo...@yahoo.com
wrote:
From: Gurkan Erdogdu gurkanerdo...@yahoo.com
Subject: Re: Need to switch to subclassing?
To: dev@openwebbeans.apache.org
Date: Tuesday, May 11, 2010, 6:11 AM
This will also not work on EJB
containers. For example, in EJB Hello
@Interceptors(MyInterceptor.class)
public Hello implemenet IHello{
public void method1(){
method2();
}
public void method2(){
...
}
}
@Local
public interface IHello{
public void method1();
public void method2();
}
main(){
IHello proxy = getting from
intitial context
proxy.method1();
}
Calling method2() from method1() does not trigger
interception. Interceptor is called ones when client
calls
method1() on bean proxy. You could try it on OpenEJB
for
example
Thanks;
Gurkan
From: Mark Struberg strub...@yahoo.de
To: dev@openwebbeans.apache.org
Sent: Tue, May 11, 2010 8:30:15 AM
Subject: Need to switch to subclassing?
Hi!
There is a subtle difference between implementing
interceptors via proxy or via subclasses.
I have the following service which imports data from
a
legacy system into my db. Since commits are very
performance
intense, they should get imported in packages of 100.
So
I'll get 100 'Employees' from my legacy system and
then call
a @Transactional method to store them in my own
database.
public void ImportService() {
public void importEmployee() {
ListLegacyEmployee
les;
while ((les =
getNext100EmployeesFromLegacy()) != nul) {
importLegacyEmployees(le);
}
}
�...@transactional
protected
importLegacyEmployees(ListLegacyEmployee les)
{
for (LegacyEmployee le: les)
{
employeeService.store(le);
}
}
}
This would actually _not_ when using proxies for the
interceptor handling, because calling a method on an
own
class doesn't invoke the proxyhandler.
So is this expected to work?
Sure, I could easily move the importLegacyEmployees()
to an
own service, but that would infringe classic OOP
heavily
imo.
Gurkan, what does the spec say here, I did find
nothing.
The old spec explicitly mentioned that we need to use
subclassing, but I cannot find this anymore.
LieGrue,
strub
Re: Need to switch to subclassing?
I don't have Gurkan's experience in the spec, but this seems to be what
section 7.2 is all about. When do you treat a method call as a business
method invocation, and how does that affect things like Decorators and
Interceptor invocation.
The only wording that hints this shouldn't work when calling another method
inside the bean is When the container invokes a method of a bean.
I do think there is a need for a subclassing approach, specifically for
dependent scoped objects that we can not proxy.
Sincerely,
Joe
On Tue, May 11, 2010 at 1:30 AM, Mark Struberg strub...@yahoo.de wrote:
Hi!
There is a subtle difference between implementing interceptors via proxy or
via subclasses.
I have the following service which imports data from a legacy system into
my db. Since commits are very performance intense, they should get imported
in packages of 100. So I'll get 100 'Employees' from my legacy system and
then call a @Transactional method to store them in my own database.
public void ImportService() {
public void importEmployee() {
ListLegacyEmployee les;
while ((les = getNext100EmployeesFromLegacy()) != nul) {
importLegacyEmployees(le);
}
}
@Transactional
protected importLegacyEmployees(ListLegacyEmployee les) {
for (LegacyEmployee le: les) {
employeeService.store(le);
}
}
}
This would actually _not_ when using proxies for the interceptor handling,
because calling a method on an own class doesn't invoke the proxyhandler.
So is this expected to work?
Sure, I could easily move the importLegacyEmployees() to an own service,
but that would infringe classic OOP heavily imo.
Gurkan, what does the spec say here, I did find nothing. The old spec
explicitly mentioned that we need to use subclassing, but I cannot find this
anymore.
LieGrue,
strub
Re: Need to switch to subclassing?
Yes, thanks Joe. For @Dependent it seems that it's pretty much clear. The
question is if we should use the same mechanism for @NormalScoped beans also.
But Gurkans argument with the EJB Interceptor spec is a strong indicator that
it is not mandatory.
LieGrue,
strub
--- Joseph Bergmark bergm...@gmail.com schrieb am Di, 11.5.2010:
Von: Joseph Bergmark bergm...@gmail.com
Betreff: Re: Need to switch to subclassing?
An: dev@openwebbeans.apache.org
Datum: Dienstag, 11. Mai, 2010 15:42 Uhr
I don't have Gurkan's experience in
the spec, but this seems to be what
section 7.2 is all about. When do you treat a method
call as a business
method invocation, and how does that affect things like
Decorators and
Interceptor invocation.
The only wording that hints this shouldn't work when
calling another method
inside the bean is When the container invokes a method of
a bean.
I do think there is a need for a subclassing approach,
specifically for
dependent scoped objects that we can not proxy.
Sincerely,
Joe
On Tue, May 11, 2010 at 1:30 AM, Mark Struberg strub...@yahoo.de
wrote:
Hi!
There is a subtle difference between implementing
interceptors via proxy or
via subclasses.
I have the following service which imports data from a
legacy system into
my db. Since commits are very performance intense,
they should get imported
in packages of 100. So I'll get 100 'Employees' from
my legacy system and
then call a @Transactional method to store them in my
own database.
public void ImportService() {
public void importEmployee() {
ListLegacyEmployee les;
while ((les =
getNext100EmployeesFromLegacy()) != nul) {
importLegacyEmployees(le);
}
}
@Transactional
protected
importLegacyEmployees(ListLegacyEmployee les) {
for (LegacyEmployee le: les) {
employeeService.store(le);
}
}
}
This would actually _not_ when using proxies for the
interceptor handling,
because calling a method on an own class doesn't
invoke the proxyhandler.
So is this expected to work?
Sure, I could easily move the importLegacyEmployees()
to an own service,
but that would infringe classic OOP heavily imo.
Gurkan, what does the spec say here, I did find
nothing. The old spec
explicitly mentioned that we need to use subclassing,
but I cannot find this
anymore.
LieGrue,
strub
RE: Need to switch to subclassing?
Hi!
I'd definitely would go the subclassing route.
The problem you describe here is one of my biggest concerns of how Spring's AOP
works.
This is just not real AOP - it is dynamic proxy creation - not more, not less.
An average developer will never be able to figure out what is going wrong here.
I had this problem once too, the solution I used then was not to use (the
implicit) this., but to
use a reference to the service object (the proxy instance).
In your case this would mean you need to get access to the proxy and then call
thisProxy.importLegacyEmployees.
That way the call goes through the AOP layer ... but ... I'd consider it as
nasty workaround.
Ciao,
Mario
-Original Message-
From: Mark Struberg [mailto:strub...@yahoo.de]
Sent: Tuesday, May 11, 2010 7:30 AM
To: dev@openwebbeans.apache.org
Subject: Need to switch to subclassing?
Hi!
There is a subtle difference between implementing interceptors via proxy or via
subclasses.
I have the following service which imports data from a legacy system into my
db. Since commits are very performance intense, they should get imported in
packages of 100. So I'll get 100 'Employees' from my legacy system and then
call a @Transactional method to store them in my own database.
public void ImportService() {
public void importEmployee() {
ListLegacyEmployee les;
while ((les = getNext100EmployeesFromLegacy()) != nul) {
importLegacyEmployees(le);
}
}
@Transactional
protected importLegacyEmployees(ListLegacyEmployee les) {
for (LegacyEmployee le: les) {
employeeService.store(le);
}
}
}
This would actually _not_ when using proxies for the interceptor handling,
because calling a method on an own class doesn't invoke the proxyhandler.
So is this expected to work?
Sure, I could easily move the importLegacyEmployees() to an own service, but
that would infringe classic OOP heavily imo.
Gurkan, what does the spec say here, I did find nothing. The old spec
explicitly mentioned that we need to use subclassing, but I cannot find this
anymore.
LieGrue,
strub
