springframework-developer — Spring Framework developers list

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

Re: [Springframework-developer] Drools Support and Crypto Support

[Rod J. <ro...@in...>]

Rob

I think support for one or more rule engines would definitely be good.

Rgds
Rod

Rob Harrop wrote:
> All,
> 
> I have been thinking about adding two additional modules to support 
> Drools integration with Spring and to support simple crypto stuff as 
> well. For Drools, I was planning on adding in generic support through 
> the JSR 94 interfaces so that the support can be used with other rules 
> engines as well. As for crypto I was planning for some simple 
> FactoryBean implementations for Ciphers, MessageDigests etc plus a 
> template class to encapsulate encrypt, decrypt and digest.
> 
> What are your thoughts?
> 
> Rob
> 
> 
> -------------------------------------------------------
> 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
> 

-- 

____________________________________________________
Rod Johnson
CEO, Interface21 - Spring Services from the Source
http://www.springframework.com

Founder, Spring Framework:
http://www.springframework.org

Author, "Expert One-on-One J2EE Development Without EJB"
(May 2004, with Juergen Hoeller).
http://www.amazon.com/exec/obidos/ASIN/0764558315/

Author, "Expert One-on-One J2EE Design and Development"
(October 2002).
http://www.amazon.com/exec/obidos/tg/detail/-/0764543857/


____________________________________________________
Interface21 Limited
Registered Office Summit House, 2-2a Highfield Road, Dartford, Kent DA1 2JY
Registered in England and Wales No. 5187766
____________________________________________________

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] PROPAGATION_REQUIRES_NEW and JTA

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

Transaction suspension should work with all of Spring's local transaction
managers too, including HibernateTransactionManager. It's even simpler than
in the JTA case: no need for special server-specific setup.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Jim Engquist
Sent: Thursday, January 06, 2005 6:28 PM
To: spr...@li...
Subject: [Springframework-developer] PROPAGATION_REQUIRES_NEW and JTA



Hi Folks,

I'm wondering if it's possible to use PROPAGATION_REQUIRES_NEW *without*
using JTA.  I'm trying to use PROPAGATION_REQUIRES_NEW with the
following simple setup (using spring-framework-1.1):

HibernateTransactionManager whose sessionFactory is
a LocalSessionFactoryBean, and the sessionFactory
dataSource is a JDBC DriverManagerDataSource.

This isn't yielding the results I want yet.
I don't get any exceptions or obvious error
output, but I don't get the transactional behavior I expect either.
I'll need to do further work to diagnose, but first I
just want to make sure that such a configuration is intended to work.

Based on this post from Colin Sampaleanu, I suspect that JTA
may be required:

----
REQUIRES_NEW actually just suspends the current transaction, and then
 starts a new, unrelated transaction transaction to run the contained
 code in. If you commit the inner, new transaction, then rollback the
 outer, the inner transaciton will still be committed, as they are
 unrelated. This should work properly inside any JTA environment (as long
 as spring can get at the jta transaction manager) and the model is also
 essentially the same as the requires new support in the EJB spec.
----

Thanks for listening,
Jim Engquist





-------------------------------------------------------
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] PROPAGATION_REQUIRES_NEW and JTA

[Seth L. <set...@gm...>]

On Thu, 06 Jan 2005 10:27:35 -0700, Jim Engquist <jd...@ca...> wrote:
> 
> Hi Folks,
> 
> I'm wondering if it's possible to use PROPAGATION_REQUIRES_NEW *without*
> using JTA.  I'm trying to use PROPAGATION_REQUIRES_NEW with the
> following simple setup (using spring-framework-1.1):
> 
> HibernateTransactionManager whose sessionFactory is
> a LocalSessionFactoryBean, and the sessionFactory
> dataSource is a JDBC DriverManagerDataSource.
> 
> This isn't yielding the results I want yet.
> I don't get any exceptions or obvious error
> output, but I don't get the transactional behavior I expect either.
> I'll need to do further work to diagnose, but first I
> just want to make sure that such a configuration is intended to work.


If your setup is something like this, it won't work:

public class Bean {
   // marked as REQUIRES
  public void doA() {
    doB(); // run as REQUIRES_NEW
    doB(); // run as REQUIRES_NEW
  }

  public void doB() {
    ...
  }
}

Because when doB is called from inside doA, it's not going through the
proxy.  Therefore, it bypasses the transaction code.  Maybe this is
why you're not seeing the behavior you expect?

Seth

-- 
<a href="http://www.picklematrix.net/foaf.rdf">Seth Ladd's FOAF</a>
<a href="http://www.foaf-project.org/">What is FOAF?</a>

[Springframework-developer] PROPAGATION_REQUIRES_NEW and JTA

[Jim E. <jd...@ca...>]

Hi Folks,

I'm wondering if it's possible to use PROPAGATION_REQUIRES_NEW *without*
using JTA.  I'm trying to use PROPAGATION_REQUIRES_NEW with the
following simple setup (using spring-framework-1.1):

HibernateTransactionManager whose sessionFactory is
a LocalSessionFactoryBean, and the sessionFactory
dataSource is a JDBC DriverManagerDataSource.

This isn't yielding the results I want yet.  
I don't get any exceptions or obvious error
output, but I don't get the transactional behavior I expect either.
I'll need to do further work to diagnose, but first I  
just want to make sure that such a configuration is intended to work.

Based on this post from Colin Sampaleanu, I suspect that JTA
may be required:

----
REQUIRES_NEW actually just suspends the current transaction, and then 
 starts a new, unrelated transaction transaction to run the contained 
 code in. If you commit the inner, new transaction, then rollback the 
 outer, the inner transaciton will still be committed, as they are 
 unrelated. This should work properly inside any JTA environment (as long 
 as spring can get at the jta transaction manager) and the model is also 
 essentially the same as the requires new support in the EJB spec.
----

Thanks for listening,
Jim Engquist

Re: [Springframework-developer] PropertyEditor lookup question

[Steven D. <ste...@gm...>]

For clarities sake, this is the property editor I'm registering:

package sandbox;

import java.beans.PropertyEditor;
import java.beans.PropertyEditorSupport;
import java.util.HashMap;
import java.util.Map;

/**
 * <p>Property editor that delegates to other property editors based on
 * a prefix. This value should be:</p>
 * 
 * <pre>
 *    &ltprefix&gt;:some_value
 * </pre>
 * 
 * <p>So for example, to resolve class names add an entry to the delegates
 * property with key &quot;class&quot; and value 
 * <code>org.springframework.beans.propertyeditors.ClassEditor</code>. A
 * value that would match for <code>ClassEditor</code> would be:</p>
 * 
 * <pre>
 *    class:mypackage.myClass
 * </pre>
 * 
 * <p>If not prefix is found or the prefix is registered the value is
 * returned as a string.</p>
 * 
 * @since 06-01-2005
 * @author Steven Devijver
 */
public class DelegatingPropertyEditor extends PropertyEditorSupport {

	private Map delegates = null;
	
	public DelegatingPropertyEditor() {
		super();
		this.delegates = new HashMap();
	}
	
	public void setDelegates(Map delegates) {
		this.delegates = delegates;
	}
	
	public void setAsText(String text) throws IllegalArgumentException {
		boolean hasSemiColon = false;
		String key = null;
		String value = null;
		if (text.indexOf(":") > -1) {
			hasSemiColon = true;
			key = text.substring(0, text.indexOf(":"));
			value = text.substring(text.indexOf(":") + 1, text.length());
		}
		if (hasSemiColon && this.delegates.containsKey(key)) {
			PropertyEditor propertyEditor = (PropertyEditor)this.delegates.get(key);
			propertyEditor.setAsText(value);
			setValue(propertyEditor.getValue());
		} else {
			/*
			 * It's a string!
			 */
			setValue(text);
		}
	}
}



On Thu, 6 Jan 2005 15:52:58 +0100, Steven Devijver
<ste...@gm...> wrote:
> The key is java.lang.Object, I want to explicitly register for that.
> My property editor works for a normal property that accepts an Object
> parameter but apparently not for lists.
> 
> It would be nice to use the available property editors when handling
> lists and maps. The default editors would never be used as none are
> registered for Object. Likewise, when setting properties the default
> once would be used because they come first in the list.
> 
> 
> On Thu, 06 Jan 2005 14:14:30 +0000, Rob Harrop <ro...@ca...> wrote:
> > The key of the customEditors Map entries must be the name of the class
> > you are registering the property  editor for.
> >
> > Rob
> >
> > Steven Devijver wrote:
> >
> > >I register a delegating property editor like this:
> > >
> > >       <bean class="org.springframework.beans.factory.config.CustomEditorConfigurer">
> > >               <property name="customEditors">
> > >                       <map>
> > >                               <entry key="java.lang.Object">
> > >                                       <bean class="sandbox.DelegatingPropertyEditor">
> > >                                               <property name="delegates">
> > >                                                       <map>
> > >                                                               <entry key="classpath">
> > >                                                                       <bean class="org.springframework.beans.propertyeditors.InputStreamEditor"/>
> > >                                                               </entry>
> > >                                                               <entry key="class">
> > >                                                                       <bean class="org.springframework.beans.propertyeditors.ClassEditor"/>
> > >                                                               </entry>
> > >                                                       </map>
> > >                                               </property>
> > >                                       </bean>
> > >                               </entry>
> > >                       </map>
> > >               </property>
> > >       </bean>
> > >
> > >When I create this bean my property editor is not called. Why is that?
> > >
> > >       <bean id="aList" class="java.util.ArrayList">
> > >               <constructor-arg>
> > >                       <list>
> > >                               <value>classpath:sandbox.xml</value>
> > >                               <value>class:sandbox.TestSandBox</value>
> > >                               <value>a string</value>
> > >                       </list>
> > >               </constructor-arg>
> > >       </bean>
> > >
> > >Steven
> > >
> > >
> > >-------------------------------------------------------
> > >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...>]

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...>]

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

[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] PropertyEditor lookup question

[Steven D. <ste...@gm...>]

The key is java.lang.Object, I want to explicitly register for that.
My property editor works for a normal property that accepts an Object
parameter but apparently not for lists.

It would be nice to use the available property editors when handling
lists and maps. The default editors would never be used as none are
registered for Object. Likewise, when setting properties the default
once would be used because they come first in the list.


On Thu, 06 Jan 2005 14:14:30 +0000, Rob Harrop <ro...@ca...> wrote:
> The key of the customEditors Map entries must be the name of the class
> you are registering the property  editor for.
> 
> Rob
> 
> Steven Devijver wrote:
> 
> >I register a delegating property editor like this:
> >
> >       <bean class="org.springframework.beans.factory.config.CustomEditorConfigurer">
> >               <property name="customEditors">
> >                       <map>
> >                               <entry key="java.lang.Object">
> >                                       <bean class="sandbox.DelegatingPropertyEditor">
> >                                               <property name="delegates">
> >                                                       <map>
> >                                                               <entry key="classpath">
> >                                                                       <bean class="org.springframework.beans.propertyeditors.InputStreamEditor"/>
> >                                                               </entry>
> >                                                               <entry key="class">
> >                                                                       <bean class="org.springframework.beans.propertyeditors.ClassEditor"/>
> >                                                               </entry>
> >                                                       </map>
> >                                               </property>
> >                                       </bean>
> >                               </entry>
> >                       </map>
> >               </property>
> >       </bean>
> >
> >When I create this bean my property editor is not called. Why is that?
> >
> >       <bean id="aList" class="java.util.ArrayList">
> >               <constructor-arg>
> >                       <list>
> >                               <value>classpath:sandbox.xml</value>
> >                               <value>class:sandbox.TestSandBox</value>
> >                               <value>a string</value>
> >                       </list>
> >               </constructor-arg>
> >       </bean>
> >
> >Steven
> >
> >
> >-------------------------------------------------------
> >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] PropertyEditor lookup question

[Rob H. <ro...@ca...>]

The key of the customEditors Map entries must be the name of the class 
you are registering the property  editor for.

Rob

Steven Devijver wrote:

>I register a delegating property editor like this:
>
>	<bean class="org.springframework.beans.factory.config.CustomEditorConfigurer">
>		<property name="customEditors">
>			<map>
>				<entry key="java.lang.Object">
>					<bean class="sandbox.DelegatingPropertyEditor">
>						<property name="delegates">
>							<map>
>								<entry key="classpath">
>									<bean class="org.springframework.beans.propertyeditors.InputStreamEditor"/>
>								</entry>
>								<entry key="class">
>									<bean class="org.springframework.beans.propertyeditors.ClassEditor"/>
>								</entry>
>							</map>
>						</property>
>					</bean>
>				</entry>
>			</map>
>		</property>
>	</bean>
>
>When I create this bean my property editor is not called. Why is that?
>
>	<bean id="aList" class="java.util.ArrayList">
>		<constructor-arg>
>			<list>
>				<value>classpath:sandbox.xml</value>
>				<value>class:sandbox.TestSandBox</value>
>				<value>a string</value>
>			</list>
>		</constructor-arg>
>	</bean>
>
>Steven
>
>
>-------------------------------------------------------
>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

[Springframework-developer] PropertyEditor lookup question

[Steven D. <ste...@gm...>]

I register a delegating property editor like this:

	<bean class="org.springframework.beans.factory.config.CustomEditorConfigurer">
		<property name="customEditors">
			<map>
				<entry key="java.lang.Object">
					<bean class="sandbox.DelegatingPropertyEditor">
						<property name="delegates">
							<map>
								<entry key="classpath">
									<bean class="org.springframework.beans.propertyeditors.InputStreamEditor"/>
								</entry>
								<entry key="class">
									<bean class="org.springframework.beans.propertyeditors.ClassEditor"/>
								</entry>
							</map>
						</property>
					</bean>
				</entry>
			</map>
		</property>
	</bean>

When I create this bean my property editor is not called. Why is that?

	<bean id="aList" class="java.util.ArrayList">
		<constructor-arg>
			<list>
				<value>classpath:sandbox.xml</value>
				<value>class:sandbox.TestSandBox</value>
				<value>a string</value>
			</list>
		</constructor-arg>
	</bean>

Steven

[Springframework-developer] Extending JasperReports Support

[Rob H. <ro...@ca...>]

All,

There has been a request on the forum for subreport support in the 
Spring JasperReports classes. In order to add in a simple manner I need 
to add a Map property to the View class allowing for the list of 
subreport files to be specified along with the keys the are referenced 
by in the report file. My question is whether or not it is possible to 
specify Map properties when using BeanFactory property file config as 
would be used with ResourceBundleViewResolver?

Rob

[Springframework-developer] JaxRpcPortProxyFactoryBean: stubless use fails with "out" params

[Michael S. <mi...@sc...>]

I've stumbled again on my quest to make Axis and Spring work together in 
the way I want them to. One of my operations has an out parameter (in 
WSDL: a part of the output message that does not appear in the 
operation's parameterOrder attribute; see JAX-RPC 4.3.4).

Now, JaxRpcPortProxyFactoryBean passes in all arguments from the proxied 
interface to Call#invoke(Object[]). Unfortunately, in this specific 
case, that's not the right thing to do. Instead, two things ought to 
happen

(1) Only those arguments listed in the parameterOrder ought to be passed 
to invoke.

With the means of plain JAX-RPC this is not possible, AFAICT. For 
org.apache.axis.client.Call there's a way through getOperation() -> 
getParameters() -> getMode() == OUT.

(2) Out parameters need to be extracted from the call object somewhat 
painfully. In code generated by Axis' wsdl2java, it looks like this 
(slightly changed for readability)

    extractAttachments(_call);
    java.util.Map _output;
    _output = _call.getOutputParams();
    try {
        expiration.value = (Calendar) _output.get(
            new QName("http://ns", "expires"));
    } catch (Exception _exception) {
        expiration.value = (Calendar) JavaUtils.convert(_output.get(
            new QName("http://ns", "expires")), Calendar.class);
    }

Again, the needed metadata is provided by the Axis implementation 
classes, but are not in JAX-RPC.


When I started to write this message I thought of the problem as a 
hopeless case. In the meantime it looks quite solvable. I'll probably 
have a go at it in the next couple of days. Thus if anyone else intends 
to do something similar, please contact me.


Michael

-- 
Michael Schuerig                       Face reality and stare it down
mailto:mi...@sc...        --Jethro Tull, Silver River Turning
http://www.schuerig.de/michael/

[Springframework-developer] spring build.182 Build Successful

[<al...@jt...>]

<html><head>
<style>
.white { color:#FFFFFF }.index { background-color:#FFFFFF }.index-passed { =
color:#004400 }.index-failed { color:#FF0000; font-weight:bold }.index-head=
er { font-weight:bold }.link { font-family:arial,helvetica,sans-serif; font=
-size:10pt; color:#FFFFFF; text-decoration:none; }.tab-table { margin: 0em =
0em 0.5em 0em; }.tabs { font-family:arial,helvetica,sans-serif; font-size:8=
pt; color:#000000; font-weight:bold; padding: 0em 2em; background-color:#EE=
EEEE; }.tabs-link { color:#000000; text-decoration:none; }.tabs-link:visite=
d { color:#000000; text-decoration:none; }.tabs-selected { font-family:aria=
l,helvetica,sans-serif; font-size:8pt; color:#000000; font-weight:bold; pad=
ding: 0em 2em; }.tabs-selected { border: inset; }.header-title { font-famil=
y:arial,helvetica,sans-serif; font-size:12pt; color:#000000; font-weight:bo=
ld; }.header-label { font-weight:bold; }.header-data { font-family:arial,he=
lvetica,sans-serif; font-size:10pt; color:#000000; }.modifications-data { f=
ont-family:arial,helvetica,sans-serif; font-size:8pt; color:#000000; }.modi=
fications-sectionheader { background-color:#000066; font-family:arial,helve=
tica,sans-serif; font-size:10pt; color:#FFFFFF; }.modifications-oddrow { ba=
ckground-color:#CCCCCC }.modifications-evenrow { background-color:#FFFFCC }=
.changelists-oddrow { background-color:#CCCCCC }.changelists-evenrow { back=
ground-color:#FFFFCC }.changelists-file-spacer { background-color:#FFFFFF }=
.changelists-file-evenrow { background-color:#EEEEEE }.changelists-file-odd=
row { background-color:#FFFFEE }.changelists-file-header { background-color=
:#666666; font-family:arial,helvetica,sans-serif; font-size:8pt; color:#FFF=
FFF; }.compile-data { font-family:arial,helvetica,sans-serif; font-size:8pt=
; color:#000000; }.compile-error-data { font-family:arial,helvetica,sans-se=
rif; font-size:8pt; color:#FF0000; }.compile-warn-data { font-family:arial,=
helvetica,sans-serif; font-size:8pt; color:#CC9900; }.compile-sectionheader=
 { background-color:#000066; font-family:arial,helvetica,sans-serif; font-s=
ize:10pt; color:#FFFFFF; }.distributables-data { font-family:arial,helvetic=
a,sans-serif; font-size:8pt; color:#000000; }.distributables-sectionheader =
{ background-color:#000066; font-family:arial,helvetica,sans-serif; font-si=
ze:10pt; color:#FFFFFF; }.distributables-oddrow { background-color:#CCCCCC =
}.unittests-sectionheader { background-color:#000066; font-family:arial,hel=
vetica,sans-serif; font-size:10pt; color:#FFFFFF; }.unittests-oddrow { back=
ground-color:#CCCCCC }.unittests-data { font-family:arial,helvetica,sans-se=
rif; font-size:8pt; color:#000000; }.unittests-error { font-family:arial,he=
lvetica,sans-serif; font-size:8pt; color:#901090; }.unittests-failure { fon=
t-family:arial,helvetica,sans-serif; font-size:8pt; color:#FF0000; }.checks=
tyle-oddrow { background-color:#CCCCCC }.checkstyle-data { font-family:aria=
l,helvetica,sans-serif; font-size:8pt; color:#000000; }.checkstyle-sectionh=
eader { background-color:#000066; font-family:arial,helvetica,sans-serif; f=
ont-size:10pt; color:#FFFFFF; }
</style>
</head><body>
<p>
<table width=3D"98%" border=3D"0" cellspacing=3D"0" cellpadding=3D"2" align=
=3D"center"><tr><td class=3D"header-title">BUILD COMPLETE&nbsp;-&nbsp;     =
               build.182</td></tr><tr><td class=3D"header-data"><span class=
=3D"header-label">Date of build:&nbsp;</span>01/06/2005 00:16:18</td></tr><=
tr><td class=3D"header-data"><span class=3D"header-label">Time to build:&nb=
sp;</span>21 minutes 14 seconds</td></tr><tr><td class=3D"header-data"><spa=
n class=3D"header-label">Last changed:&nbsp;</span>01/05/2005 17:48:17</td>=
</tr><tr><td class=3D"header-data"><span class=3D"header-label">Last log en=
try:&nbsp;</span>Added few javadoc comments</td></tr></table><p>
<p>
<p>
<table xmlns=3D"http://www.w3.org/TR/html4/strict.dtd" width=3D"98%" border=
=3D"0" cellspacing=3D"0" cellpadding=3D"2" align=3D"center"><tr><td class=
=3D"compile-sectionheader">                        &nbsp;Errors/Warnings: (=
6)                    </td></tr><tr><td><pre class=3D"compile-data">Note: S=
ome input files use or override a deprecated API.<br class=3D"none"/>Note: =
Recompile with -deprecation for details.<br class=3D"none"/>Note: /jteam/bu=
ild2/checkout/spring/spring/mock/org/springframework/mock/web/MockHttpSessi=
on.java uses or overrides a deprecated API.<br class=3D"none"/>Note: Recomp=
ile with -deprecation for details.<br class=3D"none"/>Note: Some input file=
s use or override a deprecated API.<br class=3D"none"/>Note: Recompile with=
 -deprecation for details.<br class=3D"none"/></pre></td></tr></table><p>
<table xmlns=3D"http://www.w3.org/TR/html4/strict.dtd" width=3D"98%" border=
=3D"0" cellspacing=3D"0" cellpadding=3D"2" align=3D"center"><tr><td class=
=3D"compile-sectionheader">                        &nbsp;Javadoc Errors/War=
nings: (32)                    </td></tr><tr><td><pre class=3D"compile-data=
">/jteam/build2/checkout/spring/spring/src/org/springframework/jdbc/support=
/lob/OracleLobHandler.java:76: warning - Tag @see: reference not found: ora=
cle.sql.BLOB<br/>/jteam/build2/checkout/spring/spring/src/org/springframewo=
rk/jdbc/support/lob/OracleLobHandler.java:76: warning - Tag @see: reference=
 not found: oracle.sql.CLOB<br/>/jteam/build2/checkout/spring/spring/src/or=
g/springframework/jdbc/support/lob/OracleLobHandler.java:115: warning - Tag=
 @see: reference not found: oracle.sql.BLOB#DURATION_SESSION<br/>/jteam/bui=
ld2/checkout/spring/spring/src/org/springframework/jdbc/support/lob/OracleL=
obHandler.java:115: warning - Tag @see: reference not found: oracle.sql.BLO=
B#MODE_READWRITE<br/>/jteam/build2/checkout/spring/spring/src/org/springfra=
mework/jdbc/support/lob/OracleLobHandler.java:115: warning - Tag @see: refe=
rence not found: oracle.sql.CLOB#DURATION_SESSION<br/>/jteam/build2/checkou=
t/spring/spring/src/org/springframework/jdbc/support/lob/OracleLobHandler.j=
ava:115: warning - Tag @see: reference not found: oracle.sql.CLOB#MODE_READ=
WRITE<br/>/jteam/build2/checkout/spring/spring/src/org/springframework/jdbc=
/support/lob/OracleLobHandler.java:154: warning - Tag @see: reference not f=
ound: oracle.jdbc.OracleConnection<br/>/jteam/build2/checkout/spring/spring=
/src/org/springframework/jdbc/support/lob/OracleLobHandler.java:164: warnin=
g - Tag @see: reference not found: oracle.sql.BLOB#createTemporary<br/>/jte=
am/build2/checkout/spring/spring/src/org/springframework/jdbc/support/lob/O=
racleLobHandler.java:164: warning - Tag @see: reference not found: oracle.s=
ql.CLOB#createTemporary<br/>/jteam/build2/checkout/spring/spring/src/org/sp=
ringframework/jdbc/support/nativejdbc/JBossNativeJdbcExtractor.java:49: war=
ning - Tag @see: reference not found: org.jboss.resource.adapter.jdbc.Wrapp=
edConnection#getUnderlyingConnection<br/>/jteam/build2/checkout/spring/spri=
ng/src/org/springframework/jdbc/support/nativejdbc/JBossNativeJdbcExtractor=
.java:49: warning - Tag @see: reference not found: org.jboss.resource.adapt=
er.jdbc.WrappedStatement#getUnderlyingStatement<br/>/jteam/build2/checkout/=
spring/spring/src/org/springframework/jdbc/support/nativejdbc/JBossNativeJd=
bcExtractor.java:49: warning - Tag @see: reference not found: org.jboss.res=
ource.adapter.jdbc.WrappedResultSet#getUnderlyingResultSet<br/>/jteam/build=
2/checkout/spring/spring/src/org/springframework/jdbc/support/nativejdbc/We=
bLogicNativeJdbcExtractor.java:45: warning - Tag @see: reference not found:=
 weblogic.jdbc.extensions.WLConnection#getVendorConnection<br/>/jteam/build=
2/checkout/spring/spring/src/org/springframework/jdbc/support/nativejdbc/We=
bSphereNativeJdbcExtractor.java:34: warning - Tag @see: reference not found=
: com.ibm.ws.rsadapter.jdbc.WSJdbcConnection<br/>/jteam/build2/checkout/spr=
ing/spring/src/org/springframework/jdbc/support/nativejdbc/WebSphereNativeJ=
dbcExtractor.java:34: warning - Tag @see: reference not found: com.ibm.ws.r=
sadapter.jdbc.WSJdbcUtil#getNativeConnection<br/>/jteam/build2/checkout/spr=
ing/spring/src/org/springframework/jdbc/support/nativejdbc/WebSphereNativeJ=
dbcExtractor.java:34: warning - Tag @see: reference not found: com.ibm.ejs.=
cm.proxy.ConnectionProxy#getPhysicalConnection<br/>/jteam/build2/checkout/s=
pring/spring/src/org/springframework/orm/ibatis/SqlMapClientFactoryBean.jav=
a:174: warning - Tag @see: reference not found: com.ibatis.sqlmap.engine.tr=
ansaction.jdbc.JdbcTransactionConfig<br/>/jteam/build2/checkout/spring/spri=
ng/src/org/springframework/orm/ibatis/SqlMapClientFactoryBean.java:174: war=
ning - Tag @see: reference not found: com.ibatis.sqlmap.engine.transaction.=
jta.JtaTransactionConfig<br/>/jteam/build2/checkout/spring/spring/src/org/s=
pringframework/orm/ibatis/SqlMapClientFactoryBean.java:202: warning - Tag @=
see: reference not found: com.ibatis.sqlmap.engine.transaction.jdbc.JdbcTra=
nsactionConfig<br/>/jteam/build2/checkout/spring/spring/src/org/springframe=
work/orm/ibatis/SqlMapClientFactoryBean.java:202: warning - Tag @see: refer=
ence not found: com.ibatis.sqlmap.engine.transaction.jta.JtaTransactionConf=
ig<br/>/jteam/build2/checkout/spring/spring/src/org/springframework/transac=
tion/jta/WebLogicJtaTransactionManager.java:67: warning - Tag @see: referen=
ce not found: weblogic.transaction.TransactionManager#forceResume<br/>/jtea=
m/build2/checkout/spring/spring/src/org/springframework/transaction/jta/Web=
LogicServerTransactionManagerFactoryBean.java:45: warning - Tag @see: refer=
ence not found: weblogic.transaction.TxHelper#getTransactionManager<br/>/jt=
eam/build2/checkout/spring/spring/src/org/springframework/transaction/jta/W=
ebSphereTransactionManagerFactoryBean.java:47: warning - Tag @see: referenc=
e not found: com.ibm.ws.Transaction.TransactionManagerFactory#getTransactio=
nManager<br/>/jteam/build2/checkout/spring/spring/src/org/springframework/t=
ransaction/jta/WebSphereTransactionManagerFactoryBean.java:47: warning - Ta=
g @see: reference not found: com.ibm.ejs.jts.jta.JTSXA#getTransactionManage=
r<br/>/jteam/build2/checkout/spring/spring/src/org/springframework/transact=
ion/jta/WebSphereTransactionManagerFactoryBean.java:47: warning - Tag @see:=
 reference not found: com.ibm.ejs.jts.jta.TransactionManagerFactory#getTran=
sactionManager<br/>/jteam/build2/checkout/spring/spring/src/org/springframe=
work/web/context/ContextLoader.java:77: warning - Missing closing } charact=
er for inline tag: "{@link #loadParentContext(ServletContext) method for mo=
re information.<br/> &lt;/p&gt;"<br/>/jteam/build2/checkout/spring/spring/s=
rc/org/springframework/web/context/ContextLoader.java:77: warning - Missing=
 closing } character for inline tag: "{@link #loadParentContext(ServletCont=
ext) method for more information.<br/> &lt;/p&gt;"<br/>/jteam/build2/checko=
ut/spring/spring/src/org/springframework/web/context/ContextLoader.java:77:=
 warning - Missing closing } character for inline tag: "{@link #loadParentC=
ontext(ServletContext) method for more information.<br/> &lt;/p&gt;"<br/>/j=
team/build2/checkout/spring/spring/src/org/springframework/web/servlet/hand=
ler/metadata/PathMap.java:31: warning - @@org.apache.commons.attributes.Ind=
exed() is an unknown tag.<br/></pre></td></tr></table><p>
<table width=3D"98%" border=3D"0" cellspacing=3D"0" cellpadding=3D"2" align=
=3D"center"><tr><td colspan=3D"4" class=3D"unittests-sectionheader">       =
            &nbsp;Unit Tests: (2142)                </td></tr><tr><td class=
=3D"unittests-data" colspan=3D"2">                            All Tests Pas=
sed                        </td></tr><tr><td><table width=3D"98%" border=3D=
"0" cellspacing=3D"0" cellpadding=3D"2" align=3D"center"></table></td></tr>=
<tr></tr><tr><td colspan=3D"2">&nbsp;</td></tr></table><p>
<table width=3D"98%" border=3D"0" cellspacing=3D"1" cellpadding=3D"2" align=
=3D"center"><tr><td colspan=3D"6" class=3D"modifications-sectionheader">   =
                 &nbsp;Modifications since last build:&nbsp;               =
     (21)                </td></tr><tr class=3D"modifications-evenrow"><td =
class=3D"modifications-data">modified</td><td class=3D"modifications-data">=
dkopylenko</td><td class=3D"modifications-data">src/org/springframework/aop=
/beans/ServiceLocatorProxyCreator.java</td><td class=3D"modifications-data"=
>Added few javadoc comments</td></tr><tr class=3D"modifications-oddrow"><td=
 class=3D"modifications-data">modified</td><td class=3D"modifications-data"=
>colins</td><td class=3D"modifications-data">test/org/springframework/aop/b=
eans/ServiceLocatorProxyCreatorTest.java</td><td class=3D"modifications-dat=
a">enhance unit tests</td></tr><tr class=3D"modifications-evenrow"><td clas=
s=3D"modifications-data">modified</td><td class=3D"modifications-data">jhoe=
ller</td><td class=3D"modifications-data">src/org/springframework/beans/fac=
tory/support/DefaultListableBeanFactory.java</td><td class=3D"modifications=
-data">use linked map for getBeansOfType</td></tr><tr class=3D"modification=
s-oddrow"><td class=3D"modifications-data">modified</td><td class=3D"modifi=
cations-data">jhoeller</td><td class=3D"modifications-data">src/org/springf=
ramework/jndi/JndiLocatorSupport.java</td><td class=3D"modifications-data">=
changed logging to debug level</td></tr><tr class=3D"modifications-evenrow"=
><td class=3D"modifications-data">modified</td><td class=3D"modifications-d=
ata">jhoeller</td><td class=3D"modifications-data">src/org/springframework/=
remoting/rmi/RmiClientInterceptor.java</td><td class=3D"modifications-data"=
>added "prepare" methods and corresponding checks, for easier standalone us=
age</td></tr><tr class=3D"modifications-oddrow"><td class=3D"modifications-=
data">modified</td><td class=3D"modifications-data">jhoeller</td><td class=
=3D"modifications-data">src/org/springframework/remoting/rmi/JndiRmiClientI=
nterceptor.java</td><td class=3D"modifications-data">added "prepare" method=
s and corresponding checks, for easier standalone usage</td></tr><tr class=
=3D"modifications-evenrow"><td class=3D"modifications-data">modified</td><t=
d class=3D"modifications-data">jhoeller</td><td class=3D"modifications-data=
">src/org/springframework/remoting/caucho/BurlapClientInterceptor.java</td>=
<td class=3D"modifications-data">added "prepare" methods and corresponding =
checks, for easier standalone usage</td></tr><tr class=3D"modifications-odd=
row"><td class=3D"modifications-data">modified</td><td class=3D"modificatio=
ns-data">jhoeller</td><td class=3D"modifications-data">src/org/springframew=
ork/remoting/caucho/HessianClientInterceptor.java</td><td class=3D"modifica=
tions-data">added "prepare" methods and corresponding checks, for easier st=
andalone usage</td></tr><tr class=3D"modifications-evenrow"><td class=3D"mo=
difications-data">modified</td><td class=3D"modifications-data">jhoeller</t=
d><td class=3D"modifications-data">src/org/springframework/remoting/jaxrpc/=
LocalJaxRpcServiceFactory.java</td><td class=3D"modifications-data">introdu=
ced JaxRpcServicePostProcessor callback interface, introduced JAX-RPC dynam=
ic calls to avoid RMI port interface</td></tr><tr class=3D"modifications-od=
drow"><td class=3D"modifications-data">modified</td><td class=3D"modificati=
ons-data">jhoeller</td><td class=3D"modifications-data">src/org/springframe=
work/remoting/jaxrpc/ServletEndpointSupport.java</td><td class=3D"modificat=
ions-data">introduced JaxRpcServicePostProcessor callback interface, introd=
uced JAX-RPC dynamic calls to avoid RMI port interface</td></tr><tr class=
=3D"modifications-evenrow"><td class=3D"modifications-data">added</td><td c=
lass=3D"modifications-data">jhoeller</td><td class=3D"modifications-data">s=
rc/org/springframework/remoting/jaxrpc/JaxRpcServicePostProcessor.java</td>=
<td class=3D"modifications-data">introduced JaxRpcServicePostProcessor call=
back interface, introduced JAX-RPC dynamic calls to avoid RMI port interfac=
e</td></tr><tr class=3D"modifications-oddrow"><td class=3D"modifications-da=
ta">modified</td><td class=3D"modifications-data">jhoeller</td><td class=3D=
"modifications-data">src/org/springframework/remoting/jaxrpc/JaxRpcPortClie=
ntInterceptor.java</td><td class=3D"modifications-data">introduced JaxRpcSe=
rvicePostProcessor callback interface, introduced JAX-RPC dynamic calls to =
avoid RMI port interface</td></tr><tr class=3D"modifications-evenrow"><td c=
lass=3D"modifications-data">deleted</td><td class=3D"modifications-data">jh=
oeller</td><td class=3D"modifications-data">samples/jpetstore/src/org/sprin=
gframework/samples/jpetstore/service/server/JaxRpcOrderService.java</td><td=
 class=3D"modifications-data">introduced JaxRpcServicePostProcessor callbac=
k interface, introduced JAX-RPC dynamic calls to avoid RMI port interface</=
td></tr><tr class=3D"modifications-oddrow"><td class=3D"modifications-data"=
>deleted</td><td class=3D"modifications-data">jhoeller</td><td class=3D"mod=
ifications-data">samples/jpetstore/src/org/springframework/samples/jpetstor=
e/service/client/AxisPortProxyFactoryBean.java</td><td class=3D"modificatio=
ns-data">introduced JaxRpcServicePostProcessor callback interface, introduc=
ed JAX-RPC dynamic calls to avoid RMI port interface</td></tr><tr class=3D"=
modifications-evenrow"><td class=3D"modifications-data">added</td><td class=
=3D"modifications-data">jhoeller</td><td class=3D"modifications-data">sampl=
es/jpetstore/src/org/springframework/samples/jpetstore/service/client/BeanM=
appingServicePostProcessor.java</td><td class=3D"modifications-data">introd=
uced JaxRpcServicePostProcessor callback interface, introduced JAX-RPC dyna=
mic calls to avoid RMI port interface</td></tr><tr class=3D"modifications-o=
ddrow"><td class=3D"modifications-data">deleted</td><td class=3D"modificati=
ons-data">jhoeller</td><td class=3D"modifications-data">samples/jpetstore/s=
rc/org/springframework/samples/jpetstore/service/RemoteOrderService.java</t=
d><td class=3D"modifications-data">introduced JaxRpcServicePostProcessor ca=
llback interface, introduced JAX-RPC dynamic calls to avoid RMI port interf=
ace</td></tr><tr class=3D"modifications-evenrow"><td class=3D"modifications=
-data">added</td><td class=3D"modifications-data">jhoeller</td><td class=3D=
"modifications-data">samples/jpetstore/src/org/springframework/samples/jpet=
store/service/JaxRpcOrderService.java</td><td class=3D"modifications-data">=
introduced JaxRpcServicePostProcessor callback interface, introduced JAX-RP=
C dynamic calls to avoid RMI port interface</td></tr><tr class=3D"modificat=
ions-oddrow"><td class=3D"modifications-data">modified</td><td class=3D"mod=
ifications-data">jhoeller</td><td class=3D"modifications-data">test/org/spr=
ingframework/remoting/jaxrpc/JaxRpcSupportTests.java</td><td class=3D"modif=
ications-data">introduced JaxRpcServicePostProcessor callback interface, in=
troduced JAX-RPC dynamic calls to avoid RMI port interface</td></tr><tr cla=
ss=3D"modifications-evenrow"><td class=3D"modifications-data">modified</td>=
<td class=3D"modifications-data">jhoeller</td><td class=3D"modifications-da=
ta">samples/jpetstore/src/org/springframework/samples/jpetstore/domain/logi=
c/OrderService.java</td><td class=3D"modifications-data">introduced JaxRpcS=
ervicePostProcessor callback interface, introduced JAX-RPC dynamic calls to=
 avoid RMI port interface</td></tr><tr class=3D"modifications-oddrow"><td c=
lass=3D"modifications-data">modified</td><td class=3D"modifications-data">j=
hoeller</td><td class=3D"modifications-data">samples/jpetstore/client/clien=
tContext.xml</td><td class=3D"modifications-data">introduced JaxRpcServiceP=
ostProcessor callback interface, introduced JAX-RPC dynamic calls to avoid =
RMI port interface</td></tr><tr class=3D"modifications-evenrow"><td class=
=3D"modifications-data">modified</td><td class=3D"modifications-data">jhoel=
ler</td><td class=3D"modifications-data">samples/jpetstore/war/WEB-INF/serv=
er-config.wsdd</td><td class=3D"modifications-data">introduced JaxRpcServic=
ePostProcessor callback interface, introduced JAX-RPC dynamic calls to avoi=
d RMI port interface</td></tr></table><p>
<table width=3D"98%" border=3D"0" cellspacing=3D"0" cellpadding=3D"2" align=
=3D"center"><tr><td class=3D"distributables-sectionheader">                =
        &nbsp;Deployments by this build:&nbsp;(16)                    </td>=
</tr><tr><td class=3D"distributables-data">Building jar: /jteam/build2/chec=
kout/spring/spring/dist/spring-core.jar</td></tr><tr class=3D"distributable=
s-oddrow"><td class=3D"distributables-data">Building jar: /jteam/build2/che=
ckout/spring/spring/dist/spring-aop.jar</td></tr><tr><td class=3D"distribut=
ables-data">Building jar: /jteam/build2/checkout/spring/spring/dist/spring-=
context.jar</td></tr><tr class=3D"distributables-oddrow"><td class=3D"distr=
ibutables-data">Building jar: /jteam/build2/checkout/spring/spring/dist/spr=
ing-dao.jar</td></tr><tr><td class=3D"distributables-data">Building jar: /j=
team/build2/checkout/spring/spring/dist/spring-orm.jar</td></tr><tr class=
=3D"distributables-oddrow"><td class=3D"distributables-data">Building jar: =
/jteam/build2/checkout/spring/spring/dist/spring-web.jar</td></tr><tr><td c=
lass=3D"distributables-data">Building jar: /jteam/build2/checkout/spring/sp=
ring/dist/spring-webmvc.jar</td></tr><tr class=3D"distributables-oddrow"><t=
d class=3D"distributables-data">Building jar: /jteam/build2/checkout/spring=
/spring/dist/spring.jar</td></tr><tr><td class=3D"distributables-data">Buil=
ding jar: /jteam/build2/checkout/spring/spring/dist/spring-mock.jar</td></t=
r><tr class=3D"distributables-oddrow"><td class=3D"distributables-data">Bui=
lding war: /jteam/build2/checkout/spring/spring/autobuilds/apps/buildtest/d=
ist/buildtest.war</td></tr><tr><td class=3D"distributables-data">Building w=
ar: /jteam/build2/checkout/spring/spring/autobuilds/apps/buildtest/dist/bui=
ldtest.war</td></tr><tr class=3D"distributables-oddrow"><td class=3D"distri=
butables-data">Building war: /jteam/build2/checkout/spring/spring/autobuild=
s/apps/buildtest/dist/buildtest.war</td></tr><tr><td class=3D"distributable=
s-data">Building jar: /jteam/build2/checkout/spring/spring/autobuilds/apps/=
jpetstore/war/WEB-INF/lib/jpetstore.jar</td></tr><tr class=3D"distributable=
s-oddrow"><td class=3D"distributables-data">Building war: /jteam/build2/che=
ckout/spring/spring/autobuilds/apps/jpetstore/dist/jpetstore.war</td></tr><=
tr><td class=3D"distributables-data">Building jar: /jteam/build2/checkout/s=
pring/spring/autobuilds/apps/jpetstore/war/WEB-INF/lib/jpetstore.jar</td></=
tr><tr class=3D"distributables-oddrow"><td class=3D"distributables-data">Bu=
ilding war: /jteam/build2/checkout/spring/spring/autobuilds/apps/jpetstore/=
dist/jpetstore.war</td></tr></table>
</body></html>

Re: [Springframework-developer] Drools Support and Crypto Support

[Brian M. <br...@ap...>]

Drools support would be nice to have -- I am not using it with Spring 
right now, but have before, and letting spring config it for me would 
be the way to go. It is quite bean based now, so should be 
straightforward-ish, i think.

-Brian

On Jan 5, 2005, at 1:05 PM, Rob Harrop wrote:

> All,
>
> I have been thinking about adding two additional modules to support 
> Drools integration with Spring and to support simple crypto stuff as 
> well. For Drools, I was planning on adding in generic support through 
> the JSR 94 interfaces so that the support can be used with other rules 
> engines as well. As for crypto I was planning for some simple 
> FactoryBean implementations for Ciphers, MessageDigests etc plus a 
> template class to encapsulate encrypt, decrypt and digest.
>
> What are your thoughts?
>
> Rob
>
>
> -------------------------------------------------------
> 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] beandoc tool (and request for help)

[Erwin V. <erw...@er...>]

It would also be nice to see this as a Maven report.

Erwin Vervaet
----- Original Message ----- 
From: "Darren Davison" <da...@da...>
To: <spr...@li...>
Sent: Wednesday, January 05, 2005 6:16 PM
Subject: [Springframework-developer] beandoc tool (and request for help)



You can see the latest beandoc output from the JPetStore context files at
<http://springframework.sourceforge.net/beandoc/index.html> if you're
interested.

The basic stuff is now working quite well, the Ant task is implemented and
it's generally very configurable and/or skinnable (ie for a corporate, or
project look & feel).  It can also be extended with additional Decorator /
Transformer implementation combos if the defaults don't suffice.
Documentation is lacking (JavaDoc is OK but no ref docs yet).

Still looking for help in the graphic design department from anyone less
chromatically challenged than me - the last response to my plea wasn't 
exactly
overwhelming.  Unless anyone thinks the current design particularly 
compelling
that is. hehe. ;)

Regards,

-- 
Darren Davison
Public Key: #DD356B0D




-------------------------------------------------------
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

[Springframework-developer] Drools Support and Crypto Support

[Rob H. <ro...@ca...>]

All,

I have been thinking about adding two additional modules to support 
Drools integration with Spring and to support simple crypto stuff as 
well. For Drools, I was planning on adding in generic support through 
the JSR 94 interfaces so that the support can be used with other rules 
engines as well. As for crypto I was planning for some simple 
FactoryBean implementations for Ciphers, MessageDigests etc plus a 
template class to encapsulate encrypt, decrypt and digest.

What are your thoughts?

Rob

[Springframework-developer] beandoc tool (and request for help)

[Darren D. <da...@da...>]

You can see the latest beandoc output from the JPetStore context files at
<http://springframework.sourceforge.net/beandoc/index.html> if you're
interested.

The basic stuff is now working quite well, the Ant task is implemented an=
d
it's generally very configurable and/or skinnable (ie for a corporate, or
project look & feel).  It can also be extended with additional Decorator =
/
Transformer implementation combos if the defaults don't suffice.=20
Documentation is lacking (JavaDoc is OK but no ref docs yet).

Still looking for help in the graphic design department from anyone less
chromatically challenged than me - the last response to my plea wasn't ex=
actly
overwhelming.  Unless anyone thinks the current design particularly compe=
lling
that is. hehe. ;)

Regards,

--=20
Darren Davison
Public Key: #DD356B0D

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

[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] jpetstore upgraded to iBatis 2.0

[Peng W. <wp...@gm...>]

I would like to see there are a set of "complete" unit tests (from
DAO, Service to Presentation) to show us the best practice of
test-driven process with Spring. Have you guys done that? I think it
will benefit many users.


On Wed, 5 Jan 2005 10:42:39 -0000 (GMT), Darren Davison
<da...@da...> wrote:
> 
> On Tue, January 4, 2005 17:48, Colin Sampaleanu said:
> 
> > We'll have to update the jpetstore under autobuilds too. I'm not clear
> > if that's modified at all from the original. If not, the changed files
> > can just be copied over.
> 
> It *is* a modified version, package names are different but the code should be
> the same.  Main changes were in the JSP's to produce stripped down, cleaner
> HTML for the HttpUnit tests to work.
> 
> Regards,
> 
> --
> Darren Davison
> Public Key: #DD356B0D
> 
> 
> -------------------------------------------------------
> 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] jpetstore upgraded to iBatis 2.0

[Darren D. <da...@da...>]

On Tue, January 4, 2005 17:48, Colin Sampaleanu said:

> We'll have to update the jpetstore under autobuilds too. I'm not clear
> if that's modified at all from the original. If not, the changed files
> can just be copied over.

It *is* a modified version, package names are different but the code shou=
ld be
the same.  Main changes were in the JSP's to produce stripped down, clean=
er
HTML for the HttpUnit tests to work.

Regards,

--=20
Darren Davison
Public Key: #DD356B0D