springframework-developer

[Springframework-developer] ServiceLocatorProxyFactoryBean

[Colin S. <col...@ex...>]

A few days ago I checked in ServiceLocatorProxyFactoryBean. I originally 
did a prototype version of this prompted by a  couple of weblog entries 
by Mike Spille:

http://www.pyrasun.com/mike/mt/archives/2004/11/06/15.46.14/index.html
http://www.pyrasun.com/mike/mt/archives/2004/11/07/12.58.49/index.html

Basically, the idea is that if somebody doesn't want to use the existing 
lookup method injection, because it seems too 'magic', they can instead 
define service locator interfaces like

interface TestServiceLocator {
  TestService getTestService();
}

or

interface TestServiceLocator {
  TestService getTestService(String id);
}

Then the proxy factory actually creates an a proxy which implements the 
interface to internally do a normal getBean call and returns the object. 
This proxy can be injected into the client code to be used as needed.

I put it in
  org.springframework.aop.beans
since it depends on AOP classes. In some respects, that's not a great 
package, since this is not at all about AOP or even a generic proxy 
mechanism, but if it was included in the normal beans hierarchy it 
wouldn't have the dependent classes included with it in the base jar..

Colin

Re: [Springframework-developer] ServiceLocatorProxyFactoryBean

[Dmitriy K. <dko...@ru...>]

Colin, Juergen,

are you planning to include this in 1.1.4?

Dmitriy.

Colin Sampaleanu wrote:

> A few days ago I checked in ServiceLocatorProxyFactoryBean. I 
> originally did a prototype version of this prompted by a  couple of 
> weblog entries by Mike Spille:
>
> http://www.pyrasun.com/mike/mt/archives/2004/11/06/15.46.14/index.html
> http://www.pyrasun.com/mike/mt/archives/2004/11/07/12.58.49/index.html
>
> Basically, the idea is that if somebody doesn't want to use the 
> existing lookup method injection, because it seems too 'magic', they 
> can instead define service locator interfaces like
>
> interface TestServiceLocator {
>  TestService getTestService();
> }
>
> or
>
> interface TestServiceLocator {
>  TestService getTestService(String id);
> }
>
> Then the proxy factory actually creates an a proxy which implements 
> the interface to internally do a normal getBean call and returns the 
> object. This proxy can be injected into the client code to be used as 
> needed.
>
> I put it in
>  org.springframework.aop.beans
> since it depends on AOP classes. In some respects, that's not a great 
> package, since this is not at all about AOP or even a generic proxy 
> mechanism, but if it was included in the normal beans hierarchy it 
> wouldn't have the dependent classes included with it in the base jar..
>
> Colin
>
>
>
> -------------------------------------------------------
> The SF.Net email is sponsored by: Beat the post-holiday blues
> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] ServiceLocatorProxyFactoryBean

[Colin S. <col...@ex...>]

Yes, I checked it into the main tree. But there's no real risk to it, 
it's a pretty small amount of code that doesn't affect anything else, 
and we're already using it in a project.

Dmitriy Kopylenko wrote:

> Colin, Juergen,
>
> are you planning to include this in 1.1.4?
>
> Dmitriy.
>
> Colin Sampaleanu wrote:
>
>> A few days ago I checked in ServiceLocatorProxyFactoryBean. I 
>> originally did a prototype version of this prompted by a  couple of 
>> weblog entries by Mike Spille:
>>
>> http://www.pyrasun.com/mike/mt/archives/2004/11/06/15.46.14/index.html
>> http://www.pyrasun.com/mike/mt/archives/2004/11/07/12.58.49/index.html
>>
>> Basically, the idea is that if somebody doesn't want to use the 
>> existing lookup method injection, because it seems too 'magic', they 
>> can instead define service locator interfaces like
>>
>> interface TestServiceLocator {
>>  TestService getTestService();
>> }
>>
>> or
>>
>> interface TestServiceLocator {
>>  TestService getTestService(String id);
>> }
>>
>> Then the proxy factory actually creates an a proxy which implements 
>> the interface to internally do a normal getBean call and returns the 
>> object. This proxy can be injected into the client code to be used as 
>> needed.
>>
>> I put it in
>>  org.springframework.aop.beans
>> since it depends on AOP classes. In some respects, that's not a great 
>> package, since this is not at all about AOP or even a generic proxy 
>> mechanism, but if it was included in the normal beans hierarchy it 
>> wouldn't have the dependent classes included with it in the base jar..
>>
>> Colin
>>
>>
>>
>> -------------------------------------------------------
>> The SF.Net email is sponsored by: Beat the post-holiday blues
>> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
>> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
>
> -------------------------------------------------------
> The SF.Net email is sponsored by: Beat the post-holiday blues
> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] ServiceLocatorProxyFactoryBean

[Juergen H. <ju...@in...>]

Colin,

The class is there but it's called "ServiceLocatorProxyCreator". I prefer
the name "ServiceLocatorProxyFactoryBean", as it's more in line with our
naming conventions in general and with "(Transaction)ProxyFactoryBean" in
general.

Regarding the package where it resides: "org.springframework.aop.beans" is
OK, I guess, but what's the general guideline for that package? We need to
put package-level javadoc in there, explaining the purpose of the package in
a sentence or two.

I've also refined the implementation a bit: For no-arg locator methods, we
should use BeanFactoryUtils.beanOfTypeIncludingAncestors to determine a
single bean of the given type in the entire BeanFactory hierarchy.

Furthermore, we should let the proxy's "toString" method say something like
"Service locator: mypackage.MyServiceLocatorInterface". Should be easy to
add via using a specific dummy target with overridden toString
implementation for the proxy.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Colin Sampaleanu
Sent: Wednesday, January 05, 2005 3:02 PM
To: spr...@li...
Subject: Re: [Springframework-developer] ServiceLocatorProxyFactoryBean


Yes, I checked it into the main tree. But there's no real risk to it,
it's a pretty small amount of code that doesn't affect anything else,
and we're already using it in a project.

Dmitriy Kopylenko wrote:

> Colin, Juergen,
>
> are you planning to include this in 1.1.4?
>
> Dmitriy.
>
> Colin Sampaleanu wrote:
>
>> A few days ago I checked in ServiceLocatorProxyFactoryBean. I
>> originally did a prototype version of this prompted by a  couple of
>> weblog entries by Mike Spille:
>>
>> http://www.pyrasun.com/mike/mt/archives/2004/11/06/15.46.14/index.html
>> http://www.pyrasun.com/mike/mt/archives/2004/11/07/12.58.49/index.html
>>
>> Basically, the idea is that if somebody doesn't want to use the
>> existing lookup method injection, because it seems too 'magic', they
>> can instead define service locator interfaces like
>>
>> interface TestServiceLocator {
>>  TestService getTestService();
>> }
>>
>> or
>>
>> interface TestServiceLocator {
>>  TestService getTestService(String id);
>> }
>>
>> Then the proxy factory actually creates an a proxy which implements
>> the interface to internally do a normal getBean call and returns the
>> object. This proxy can be injected into the client code to be used as
>> needed.
>>
>> I put it in
>>  org.springframework.aop.beans
>> since it depends on AOP classes. In some respects, that's not a great
>> package, since this is not at all about AOP or even a generic proxy
>> mechanism, but if it was included in the normal beans hierarchy it
>> wouldn't have the dependent classes included with it in the base jar..
>>
>> Colin
>>
>>
>>
>> -------------------------------------------------------
>> The SF.Net email is sponsored by: Beat the post-holiday blues
>> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
>> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
>
> -------------------------------------------------------
> The SF.Net email is sponsored by: Beat the post-holiday blues
> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] ServiceLocatorProxyFactoryBean

[Colin S. <col...@ex...>]

Although it's more verbose, I have no real issue with changing the name 
to your suggestion. Keith came up with this name, the original name I 
used for the first prototype was worse.

The package is a compromise. Realistically the code should probably live 
somewhere under org.springframework.beans; while it uses AOP classes 
that's somewhat irrelevant for most users, in that the class doesn't 
provide general AOP functionality, but is an enhancement of basic bean 
container bean access. Lookup method injection, which relies on cglib 
directly (not using AOP classes) lives internally under 
or.springframework.bean. But this uses ProxyFactoryBean, which is not 
included in the base jar, so needed to go somewhere under the aop tree.

A possible future enhancement I was thinking of was to eliminate the use 
of reflection on every invocation, by doing those lookups ahead of time, 
which would make it more efficient for getting prototypes. It didn't 
seem worth it at this time, especially considering a getBean call itself 
has some overhead anyway.

Colin

Juergen Hoeller wrote:

>Colin,
>
>The class is there but it's called "ServiceLocatorProxyCreator". I prefer
>the name "ServiceLocatorProxyFactoryBean", as it's more in line with our
>naming conventions in general and with "(Transaction)ProxyFactoryBean" in
>general.
>
>Regarding the package where it resides: "org.springframework.aop.beans" is
>OK, I guess, but what's the general guideline for that package? We need to
>put package-level javadoc in there, explaining the purpose of the package in
>a sentence or two.
>
>I've also refined the implementation a bit: For no-arg locator methods, we
>should use BeanFactoryUtils.beanOfTypeIncludingAncestors to determine a
>single bean of the given type in the entire BeanFactory hierarchy.
>
>Furthermore, we should let the proxy's "toString" method say something like
>"Service locator: mypackage.MyServiceLocatorInterface". Should be easy to
>add via using a specific dummy target with overridden toString
>implementation for the proxy.
>
>Juergen
>
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...]On Behalf
>Of Colin Sampaleanu
>Sent: Wednesday, January 05, 2005 3:02 PM
>To: spr...@li...
>Subject: Re: [Springframework-developer] ServiceLocatorProxyFactoryBean
>
>
>Yes, I checked it into the main tree. But there's no real risk to it,
>it's a pretty small amount of code that doesn't affect anything else,
>and we're already using it in a project.
>
>Dmitriy Kopylenko wrote:
>
>  
>
>>Colin, Juergen,
>>
>>are you planning to include this in 1.1.4?
>>
>>Dmitriy.
>>
>>Colin Sampaleanu wrote:
>>
>>    
>>
>>>A few days ago I checked in ServiceLocatorProxyFactoryBean. I
>>>originally did a prototype version of this prompted by a  couple of
>>>weblog entries by Mike Spille:
>>>
>>>http://www.pyrasun.com/mike/mt/archives/2004/11/06/15.46.14/index.html
>>>http://www.pyrasun.com/mike/mt/archives/2004/11/07/12.58.49/index.html
>>>
>>>Basically, the idea is that if somebody doesn't want to use the
>>>existing lookup method injection, because it seems too 'magic', they
>>>can instead define service locator interfaces like
>>>
>>>interface TestServiceLocator {
>>> TestService getTestService();
>>>}
>>>
>>>or
>>>
>>>interface TestServiceLocator {
>>> TestService getTestService(String id);
>>>}
>>>
>>>Then the proxy factory actually creates an a proxy which implements
>>>the interface to internally do a normal getBean call and returns the
>>>object. This proxy can be injected into the client code to be used as
>>>needed.
>>>
>>>I put it in
>>> org.springframework.aop.beans
>>>since it depends on AOP classes. In some respects, that's not a great
>>>package, since this is not at all about AOP or even a generic proxy
>>>mechanism, but if it was included in the normal beans hierarchy it
>>>wouldn't have the dependent classes included with it in the base jar..
>>>
>>>Colin
>>>      
>>>

Re: [Springframework-developer] ServiceLocatorProxyFactoryBean

[Juergen H. <ju...@in...>]

Colin,

I had the very same thought regarding the package. I've just reimplemented
ServiceLocatorProxyFactoryBean with direct JDK Proxy usage, which works
nicely and results in the same amount of code. As you say, the use of AOP is
pretty irrelevant for users, so neither the living in
org.springframework.aop nor the dependency on aopalliance.jar is really
intuitive.

I believe that putting the reworked ServiceLocatorProxyFactoryBean (with
direct JDK Proxy usage) into the org.springframework.beans.factory.config
package is the better option. It's analogous to what we do for
SingleConnectionDataSource and TransactionAwareDataSourceProxy, which use a
JDK Proxy too (to return proxied Connections).

For such specific use cases where just the resulting proxy is relevant, the
AOP framework is probably overkill and should be avoided to minimize
dependencies. For example, the JDBC DataSource stuff can be used completely
outside a BeanFactory: spring-core.jar and spring-dao.jar are enough there,
no need to depend on spring-aop.jar and aopalliance.jar too.

The remoting client stuff is a slightly different matter: While there are
convenience XxxProxyFactoryBeans, an XxxClientInterceptor can be used
directly there, as final element in an interceptor chain. Furthermore, the
remoting package has more dependencies anyway, so the additional dependency
on the AOP framework doesn't hurt there.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Colin Sampaleanu
Sent: Thursday, January 06, 2005 3:54 PM
To: spr...@li...
Subject: Re: [Springframework-developer] ServiceLocatorProxyFactoryBean


Although it's more verbose, I have no real issue with changing the name
to your suggestion. Keith came up with this name, the original name I
used for the first prototype was worse.

The package is a compromise. Realistically the code should probably live
somewhere under org.springframework.beans; while it uses AOP classes
that's somewhat irrelevant for most users, in that the class doesn't
provide general AOP functionality, but is an enhancement of basic bean
container bean access. Lookup method injection, which relies on cglib
directly (not using AOP classes) lives internally under
or.springframework.bean. But this uses ProxyFactoryBean, which is not
included in the base jar, so needed to go somewhere under the aop tree.

A possible future enhancement I was thinking of was to eliminate the use
of reflection on every invocation, by doing those lookups ahead of time,
which would make it more efficient for getting prototypes. It didn't
seem worth it at this time, especially considering a getBean call itself
has some overhead anyway.

Colin

Juergen Hoeller wrote:

>Colin,
>
>The class is there but it's called "ServiceLocatorProxyCreator". I prefer
>the name "ServiceLocatorProxyFactoryBean", as it's more in line with our
>naming conventions in general and with "(Transaction)ProxyFactoryBean" in
>general.
>
>Regarding the package where it resides: "org.springframework.aop.beans" is
>OK, I guess, but what's the general guideline for that package? We need to
>put package-level javadoc in there, explaining the purpose of the package
in
>a sentence or two.
>
>I've also refined the implementation a bit: For no-arg locator methods, we
>should use BeanFactoryUtils.beanOfTypeIncludingAncestors to determine a
>single bean of the given type in the entire BeanFactory hierarchy.
>
>Furthermore, we should let the proxy's "toString" method say something like
>"Service locator: mypackage.MyServiceLocatorInterface". Should be easy to
>add via using a specific dummy target with overridden toString
>implementation for the proxy.
>
>Juergen
>
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...]On Behalf
>Of Colin Sampaleanu
>Sent: Wednesday, January 05, 2005 3:02 PM
>To: spr...@li...
>Subject: Re: [Springframework-developer] ServiceLocatorProxyFactoryBean
>
>
>Yes, I checked it into the main tree. But there's no real risk to it,
>it's a pretty small amount of code that doesn't affect anything else,
>and we're already using it in a project.
>
>Dmitriy Kopylenko wrote:
>
>
>
>>Colin, Juergen,
>>
>>are you planning to include this in 1.1.4?
>>
>>Dmitriy.
>>
>>Colin Sampaleanu wrote:
>>
>>
>>
>>>A few days ago I checked in ServiceLocatorProxyFactoryBean. I
>>>originally did a prototype version of this prompted by a  couple of
>>>weblog entries by Mike Spille:
>>>
>>>http://www.pyrasun.com/mike/mt/archives/2004/11/06/15.46.14/index.html
>>>http://www.pyrasun.com/mike/mt/archives/2004/11/07/12.58.49/index.html
>>>
>>>Basically, the idea is that if somebody doesn't want to use the
>>>existing lookup method injection, because it seems too 'magic', they
>>>can instead define service locator interfaces like
>>>
>>>interface TestServiceLocator {
>>> TestService getTestService();
>>>}
>>>
>>>or
>>>
>>>interface TestServiceLocator {
>>> TestService getTestService(String id);
>>>}
>>>
>>>Then the proxy factory actually creates an a proxy which implements
>>>the interface to internally do a normal getBean call and returns the
>>>object. This proxy can be injected into the client code to be used as
>>>needed.
>>>
>>>I put it in
>>> org.springframework.aop.beans
>>>since it depends on AOP classes. In some respects, that's not a great
>>>package, since this is not at all about AOP or even a generic proxy
>>>mechanism, but if it was included in the normal beans hierarchy it
>>>wouldn't have the dependent classes included with it in the base jar..
>>>
>>>Colin
>>>
>>>



-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] ServiceLocatorProxyFactoryBean

[Juergen H. <ju...@in...>]

Forgot to mention: The direct use of a JDK Proxy is of course only an option
if we're always dealing with interfaces, which is the case in the JDBC
DataSource and the service locator use cases.

Juergen


-----Original Message-----
From: Juergen Hoeller [mailto:ju...@in...]
Sent: Thursday, January 06, 2005 4:14 PM
To: spr...@li...
Subject: Re: [Springframework-developer] ServiceLocatorProxyFactoryBean


Colin,

I had the very same thought regarding the package. I've just reimplemented
ServiceLocatorProxyFactoryBean with direct JDK Proxy usage, which works
nicely and results in the same amount of code. As you say, the use of AOP is
pretty irrelevant for users, so neither the living in
org.springframework.aop nor the dependency on aopalliance.jar is really
intuitive.

I believe that putting the reworked ServiceLocatorProxyFactoryBean (with
direct JDK Proxy usage) into the org.springframework.beans.factory.config
package is the better option. It's analogous to what we do for
SingleConnectionDataSource and TransactionAwareDataSourceProxy, which use a
JDK Proxy too (to return proxied Connections).

For such specific use cases where just the resulting proxy is relevant, the
AOP framework is probably overkill and should be avoided to minimize
dependencies. For example, the JDBC DataSource stuff can be used completely
outside a BeanFactory: spring-core.jar and spring-dao.jar are enough there,
no need to depend on spring-aop.jar and aopalliance.jar too.

The remoting client stuff is a slightly different matter: While there are
convenience XxxProxyFactoryBeans, an XxxClientInterceptor can be used
directly there, as final element in an interceptor chain. Furthermore, the
remoting package has more dependencies anyway, so the additional dependency
on the AOP framework doesn't hurt there.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Colin Sampaleanu
Sent: Thursday, January 06, 2005 3:54 PM
To: spr...@li...
Subject: Re: [Springframework-developer] ServiceLocatorProxyFactoryBean


Although it's more verbose, I have no real issue with changing the name
to your suggestion. Keith came up with this name, the original name I
used for the first prototype was worse.

The package is a compromise. Realistically the code should probably live
somewhere under org.springframework.beans; while it uses AOP classes
that's somewhat irrelevant for most users, in that the class doesn't
provide general AOP functionality, but is an enhancement of basic bean
container bean access. Lookup method injection, which relies on cglib
directly (not using AOP classes) lives internally under
or.springframework.bean. But this uses ProxyFactoryBean, which is not
included in the base jar, so needed to go somewhere under the aop tree.

A possible future enhancement I was thinking of was to eliminate the use
of reflection on every invocation, by doing those lookups ahead of time,
which would make it more efficient for getting prototypes. It didn't
seem worth it at this time, especially considering a getBean call itself
has some overhead anyway.

Colin

Juergen Hoeller wrote:

>Colin,
>
>The class is there but it's called "ServiceLocatorProxyCreator". I prefer
>the name "ServiceLocatorProxyFactoryBean", as it's more in line with our
>naming conventions in general and with "(Transaction)ProxyFactoryBean" in
>general.
>
>Regarding the package where it resides: "org.springframework.aop.beans" is
>OK, I guess, but what's the general guideline for that package? We need to
>put package-level javadoc in there, explaining the purpose of the package
in
>a sentence or two.
>
>I've also refined the implementation a bit: For no-arg locator methods, we
>should use BeanFactoryUtils.beanOfTypeIncludingAncestors to determine a
>single bean of the given type in the entire BeanFactory hierarchy.
>
>Furthermore, we should let the proxy's "toString" method say something like
>"Service locator: mypackage.MyServiceLocatorInterface". Should be easy to
>add via using a specific dummy target with overridden toString
>implementation for the proxy.
>
>Juergen
>
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...]On Behalf
>Of Colin Sampaleanu
>Sent: Wednesday, January 05, 2005 3:02 PM
>To: spr...@li...
>Subject: Re: [Springframework-developer] ServiceLocatorProxyFactoryBean
>
>
>Yes, I checked it into the main tree. But there's no real risk to it,
>it's a pretty small amount of code that doesn't affect anything else,
>and we're already using it in a project.
>
>Dmitriy Kopylenko wrote:
>
>
>
>>Colin, Juergen,
>>
>>are you planning to include this in 1.1.4?
>>
>>Dmitriy.
>>
>>Colin Sampaleanu wrote:
>>
>>
>>
>>>A few days ago I checked in ServiceLocatorProxyFactoryBean. I
>>>originally did a prototype version of this prompted by a  couple of
>>>weblog entries by Mike Spille:
>>>
>>>http://www.pyrasun.com/mike/mt/archives/2004/11/06/15.46.14/index.html
>>>http://www.pyrasun.com/mike/mt/archives/2004/11/07/12.58.49/index.html
>>>
>>>Basically, the idea is that if somebody doesn't want to use the
>>>existing lookup method injection, because it seems too 'magic', they
>>>can instead define service locator interfaces like
>>>
>>>interface TestServiceLocator {
>>> TestService getTestService();
>>>}
>>>
>>>or
>>>
>>>interface TestServiceLocator {
>>> TestService getTestService(String id);
>>>}
>>>
>>>Then the proxy factory actually creates an a proxy which implements
>>>the interface to internally do a normal getBean call and returns the
>>>object. This proxy can be injected into the client code to be used as
>>>needed.
>>>
>>>I put it in
>>> org.springframework.aop.beans
>>>since it depends on AOP classes. In some respects, that's not a great
>>>package, since this is not at all about AOP or even a generic proxy
>>>mechanism, but if it was included in the normal beans hierarchy it
>>>wouldn't have the dependent classes included with it in the base jar..
>>>
>>>Colin
>>>
>>>



-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] ServiceLocatorProxyFactoryBean

[Juergen H. <ju...@in...>]

Actually, I'd like to name this class "ServiceLocatorFactoryBean": It
essentially creates a service locator for a given interface. There's no
proxy pattern involved from the user's perspective - just a JDK proxy from
the implementation point of view.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Juergen Hoeller
Sent: Thursday, January 06, 2005 4:16 PM
To: spr...@li...
Subject: Re: [Springframework-developer] ServiceLocatorProxyFactoryBean


Forgot to mention: The direct use of a JDK Proxy is of course only an option
if we're always dealing with interfaces, which is the case in the JDBC
DataSource and the service locator use cases.

Juergen


-----Original Message-----
From: Juergen Hoeller [mailto:ju...@in...]
Sent: Thursday, January 06, 2005 4:14 PM
To: spr...@li...
Subject: Re: [Springframework-developer] ServiceLocatorProxyFactoryBean


Colin,

I had the very same thought regarding the package. I've just reimplemented
ServiceLocatorProxyFactoryBean with direct JDK Proxy usage, which works
nicely and results in the same amount of code. As you say, the use of AOP is
pretty irrelevant for users, so neither the living in
org.springframework.aop nor the dependency on aopalliance.jar is really
intuitive.

I believe that putting the reworked ServiceLocatorProxyFactoryBean (with
direct JDK Proxy usage) into the org.springframework.beans.factory.config
package is the better option. It's analogous to what we do for
SingleConnectionDataSource and TransactionAwareDataSourceProxy, which use a
JDK Proxy too (to return proxied Connections).

For such specific use cases where just the resulting proxy is relevant, the
AOP framework is probably overkill and should be avoided to minimize
dependencies. For example, the JDBC DataSource stuff can be used completely
outside a BeanFactory: spring-core.jar and spring-dao.jar are enough there,
no need to depend on spring-aop.jar and aopalliance.jar too.

The remoting client stuff is a slightly different matter: While there are
convenience XxxProxyFactoryBeans, an XxxClientInterceptor can be used
directly there, as final element in an interceptor chain. Furthermore, the
remoting package has more dependencies anyway, so the additional dependency
on the AOP framework doesn't hurt there.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Colin Sampaleanu
Sent: Thursday, January 06, 2005 3:54 PM
To: spr...@li...
Subject: Re: [Springframework-developer] ServiceLocatorProxyFactoryBean


Although it's more verbose, I have no real issue with changing the name
to your suggestion. Keith came up with this name, the original name I
used for the first prototype was worse.

The package is a compromise. Realistically the code should probably live
somewhere under org.springframework.beans; while it uses AOP classes
that's somewhat irrelevant for most users, in that the class doesn't
provide general AOP functionality, but is an enhancement of basic bean
container bean access. Lookup method injection, which relies on cglib
directly (not using AOP classes) lives internally under
or.springframework.bean. But this uses ProxyFactoryBean, which is not
included in the base jar, so needed to go somewhere under the aop tree.

A possible future enhancement I was thinking of was to eliminate the use
of reflection on every invocation, by doing those lookups ahead of time,
which would make it more efficient for getting prototypes. It didn't
seem worth it at this time, especially considering a getBean call itself
has some overhead anyway.

Colin

Juergen Hoeller wrote:

>Colin,
>
>The class is there but it's called "ServiceLocatorProxyCreator". I prefer
>the name "ServiceLocatorProxyFactoryBean", as it's more in line with our
>naming conventions in general and with "(Transaction)ProxyFactoryBean" in
>general.
>
>Regarding the package where it resides: "org.springframework.aop.beans" is
>OK, I guess, but what's the general guideline for that package? We need to
>put package-level javadoc in there, explaining the purpose of the package
in
>a sentence or two.
>
>I've also refined the implementation a bit: For no-arg locator methods, we
>should use BeanFactoryUtils.beanOfTypeIncludingAncestors to determine a
>single bean of the given type in the entire BeanFactory hierarchy.
>
>Furthermore, we should let the proxy's "toString" method say something like
>"Service locator: mypackage.MyServiceLocatorInterface". Should be easy to
>add via using a specific dummy target with overridden toString
>implementation for the proxy.
>
>Juergen
>
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...]On Behalf
>Of Colin Sampaleanu
>Sent: Wednesday, January 05, 2005 3:02 PM
>To: spr...@li...
>Subject: Re: [Springframework-developer] ServiceLocatorProxyFactoryBean
>
>
>Yes, I checked it into the main tree. But there's no real risk to it,
>it's a pretty small amount of code that doesn't affect anything else,
>and we're already using it in a project.
>
>Dmitriy Kopylenko wrote:
>
>
>
>>Colin, Juergen,
>>
>>are you planning to include this in 1.1.4?
>>
>>Dmitriy.
>>
>>Colin Sampaleanu wrote:
>>
>>
>>
>>>A few days ago I checked in ServiceLocatorProxyFactoryBean. I
>>>originally did a prototype version of this prompted by a  couple of
>>>weblog entries by Mike Spille:
>>>
>>>http://www.pyrasun.com/mike/mt/archives/2004/11/06/15.46.14/index.html
>>>http://www.pyrasun.com/mike/mt/archives/2004/11/07/12.58.49/index.html
>>>
>>>Basically, the idea is that if somebody doesn't want to use the
>>>existing lookup method injection, because it seems too 'magic', they
>>>can instead define service locator interfaces like
>>>
>>>interface TestServiceLocator {
>>> TestService getTestService();
>>>}
>>>
>>>or
>>>
>>>interface TestServiceLocator {
>>> TestService getTestService(String id);
>>>}
>>>
>>>Then the proxy factory actually creates an a proxy which implements
>>>the interface to internally do a normal getBean call and returns the
>>>object. This proxy can be injected into the client code to be used as
>>>needed.
>>>
>>>I put it in
>>> org.springframework.aop.beans
>>>since it depends on AOP classes. In some respects, that's not a great
>>>package, since this is not at all about AOP or even a generic proxy
>>>mechanism, but if it was included in the normal beans hierarchy it
>>>wouldn't have the dependent classes included with it in the base jar..
>>>
>>>Colin
>>>
>>>



-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer



-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] ServiceLocatorProxyFactoryBean

[Juergen H. <ju...@in...>]

I've relaxed the check for accepted service locator methods, and added some
further refinements:

* ServiceLocatorFactoryBean accepts methods with any method name now, as
long as they are defined in the service locator interface (for example,
"UserService userService()"). Previously, only methods whose name starts
with "get" were accepted. Note that "toString" and co are still properly
handled, as they are not defined in the service locator interface.

* For single-arg methods, ServiceLocatorFactoryBean accepts any argument
type. Any passed-in argument is simply stringified via toString. This allows
to pass in an int or a custom enumeration type, mapping them onto beans via
their string representations.

* To allow for flexible mappings between service ids (passed into the
service locator) and bean names (in the bean factory), I've added a
"serviceMappings" bean property of type java.util.Properties. This allows to
map the service id "1" to the bean name "testService1", for example.

* As a special "serviceMappings" key, the empty String can be mapped onto a
bean name too. Null and empty String as argument are equivalent to a no-arg
factory method. Without explicit mapping for the empty String, a matching
bean will be found in the bean factory; with explicit mapping in
"serviceMappings", the given bean name will be used. This allows to map a
no-arg factory method to a specific bean.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Juergen Hoeller
Sent: Thursday, January 06, 2005 10:32 PM
To: spr...@li...
Subject: RE: [Springframework-developer] ServiceLocatorProxyFactoryBean


Actually, I'd like to name this class "ServiceLocatorFactoryBean": It
essentially creates a service locator for a given interface. There's no
proxy pattern involved from the user's perspective - just a JDK proxy from
the implementation point of view.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Juergen Hoeller
Sent: Thursday, January 06, 2005 4:16 PM
To: spr...@li...
Subject: Re: [Springframework-developer] ServiceLocatorProxyFactoryBean


Forgot to mention: The direct use of a JDK Proxy is of course only an option
if we're always dealing with interfaces, which is the case in the JDBC
DataSource and the service locator use cases.

Juergen


-----Original Message-----
From: Juergen Hoeller [mailto:ju...@in...]
Sent: Thursday, January 06, 2005 4:14 PM
To: spr...@li...
Subject: Re: [Springframework-developer] ServiceLocatorProxyFactoryBean


Colin,

I had the very same thought regarding the package. I've just reimplemented
ServiceLocatorProxyFactoryBean with direct JDK Proxy usage, which works
nicely and results in the same amount of code. As you say, the use of AOP is
pretty irrelevant for users, so neither the living in
org.springframework.aop nor the dependency on aopalliance.jar is really
intuitive.

I believe that putting the reworked ServiceLocatorProxyFactoryBean (with
direct JDK Proxy usage) into the org.springframework.beans.factory.config
package is the better option. It's analogous to what we do for
SingleConnectionDataSource and TransactionAwareDataSourceProxy, which use a
JDK Proxy too (to return proxied Connections).

For such specific use cases where just the resulting proxy is relevant, the
AOP framework is probably overkill and should be avoided to minimize
dependencies. For example, the JDBC DataSource stuff can be used completely
outside a BeanFactory: spring-core.jar and spring-dao.jar are enough there,
no need to depend on spring-aop.jar and aopalliance.jar too.

The remoting client stuff is a slightly different matter: While there are
convenience XxxProxyFactoryBeans, an XxxClientInterceptor can be used
directly there, as final element in an interceptor chain. Furthermore, the
remoting package has more dependencies anyway, so the additional dependency
on the AOP framework doesn't hurt there.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Colin Sampaleanu
Sent: Thursday, January 06, 2005 3:54 PM
To: spr...@li...
Subject: Re: [Springframework-developer] ServiceLocatorProxyFactoryBean


Although it's more verbose, I have no real issue with changing the name
to your suggestion. Keith came up with this name, the original name I
used for the first prototype was worse.

The package is a compromise. Realistically the code should probably live
somewhere under org.springframework.beans; while it uses AOP classes
that's somewhat irrelevant for most users, in that the class doesn't
provide general AOP functionality, but is an enhancement of basic bean
container bean access. Lookup method injection, which relies on cglib
directly (not using AOP classes) lives internally under
or.springframework.bean. But this uses ProxyFactoryBean, which is not
included in the base jar, so needed to go somewhere under the aop tree.

A possible future enhancement I was thinking of was to eliminate the use
of reflection on every invocation, by doing those lookups ahead of time,
which would make it more efficient for getting prototypes. It didn't
seem worth it at this time, especially considering a getBean call itself
has some overhead anyway.

Colin

Juergen Hoeller wrote:

>Colin,
>
>The class is there but it's called "ServiceLocatorProxyCreator". I prefer
>the name "ServiceLocatorProxyFactoryBean", as it's more in line with our
>naming conventions in general and with "(Transaction)ProxyFactoryBean" in
>general.
>
>Regarding the package where it resides: "org.springframework.aop.beans" is
>OK, I guess, but what's the general guideline for that package? We need to
>put package-level javadoc in there, explaining the purpose of the package
in
>a sentence or two.
>
>I've also refined the implementation a bit: For no-arg locator methods, we
>should use BeanFactoryUtils.beanOfTypeIncludingAncestors to determine a
>single bean of the given type in the entire BeanFactory hierarchy.
>
>Furthermore, we should let the proxy's "toString" method say something like
>"Service locator: mypackage.MyServiceLocatorInterface". Should be easy to
>add via using a specific dummy target with overridden toString
>implementation for the proxy.
>
>Juergen
>
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...]On Behalf
>Of Colin Sampaleanu
>Sent: Wednesday, January 05, 2005 3:02 PM
>To: spr...@li...
>Subject: Re: [Springframework-developer] ServiceLocatorProxyFactoryBean
>
>
>Yes, I checked it into the main tree. But there's no real risk to it,
>it's a pretty small amount of code that doesn't affect anything else,
>and we're already using it in a project.
>
>Dmitriy Kopylenko wrote:
>
>
>
>>Colin, Juergen,
>>
>>are you planning to include this in 1.1.4?
>>
>>Dmitriy.
>>
>>Colin Sampaleanu wrote:
>>
>>
>>
>>>A few days ago I checked in ServiceLocatorProxyFactoryBean. I
>>>originally did a prototype version of this prompted by a  couple of
>>>weblog entries by Mike Spille:
>>>
>>>http://www.pyrasun.com/mike/mt/archives/2004/11/06/15.46.14/index.html
>>>http://www.pyrasun.com/mike/mt/archives/2004/11/07/12.58.49/index.html
>>>
>>>Basically, the idea is that if somebody doesn't want to use the
>>>existing lookup method injection, because it seems too 'magic', they
>>>can instead define service locator interfaces like
>>>
>>>interface TestServiceLocator {
>>> TestService getTestService();
>>>}
>>>
>>>or
>>>
>>>interface TestServiceLocator {
>>> TestService getTestService(String id);
>>>}
>>>
>>>Then the proxy factory actually creates an a proxy which implements
>>>the interface to internally do a normal getBean call and returns the
>>>object. This proxy can be injected into the client code to be used as
>>>needed.
>>>
>>>I put it in
>>> org.springframework.aop.beans
>>>since it depends on AOP classes. In some respects, that's not a great
>>>package, since this is not at all about AOP or even a generic proxy
>>>mechanism, but if it was included in the normal beans hierarchy it
>>>wouldn't have the dependent classes included with it in the base jar..
>>>
>>>Colin
>>>
>>>



-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer



-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer



-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer