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