springframework-developer — Spring Framework developers list

RE: [Springframework-developer] Request to add "port" to JavaMail SenderImpl settings

[Kopylenko, D. <dko...@ac...>]

Tim, everyone,

I've just committed the change to JavaMailSenderImpl. Now it's possible to
set the 'port' property and if not explicitly set, it uses the default one
i.e. -1 is used, as specified in JavaDoc for javax.mail.Service class.

Regards,
Dmitriy.


-----Original Message-----
From: Kopylenko, Dmitry [mailto:dko...@ac...] 
Sent: Thursday, November 06, 2003 7:49 AM
To: 'spr...@li...'
Subject: RE: [Springframework-developer] Request to add "port" to JavaMail
SenderImpl settings


Rod, Alef, Tim

I just saw it :-) I can take a look or Alef, do you want to do it?

Regards,
Dmitriy

-----Original Message-----
From: Rod Johnson [mailto:rod...@in...] 
Sent: Thursday, November 06, 2003 5:55 AM
To: spr...@li...
Subject: Re: [Springframework-developer] Request to add "port" to
JavaMailSenderImpl settings


Tim,

I've just drawn Dmitriy's attention to your SF request this morning :-)

Regards,
Rod

----- Original Message ----- 
From: "Tim McAuley" <ti...@mo...>
To: <spr...@li...>
Sent: Thursday, November 06, 2003 10:47 AM
Subject: [Springframework-developer] Request to add "port" to
JavaMailSenderImpl settings


> Hi,
>
> I was wondering if it could be possible to add a
> setPort() method to the JavaMailSenderImpl class.
>
> This would allow for sending email via a mail server
> which does not use the standard port of 25. I have
> looked at the code and all it should require is a new
> setting to be added for the port and the
> Transport.connect() call modified.
>
> I have placed a request on sourceforge for this at
> http://sourceforge.net/tracker/?group_id=73357&atid=537542
> (not sure if theses sourceforge facilities are used much).
>
> Thanks,
>
> Tim
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program. Does
> SourceForge.net help you be more productive?  Does it
> help you create better code?   SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/ 
> _______________________________________________
> Springframework-developer mailing list 
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program. Does
SourceForge.net help you be more productive?  Does it
help you create better code?   SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?   SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] Request to add "port" to JavaMail SenderImpl settings

[Kopylenko, D. <dko...@ac...>]

Rod, Alef, Tim

I just saw it :-) I can take a look or Alef, do you want to do it?

Regards,
Dmitriy

-----Original Message-----
From: Rod Johnson [mailto:rod...@in...] 
Sent: Thursday, November 06, 2003 5:55 AM
To: spr...@li...
Subject: Re: [Springframework-developer] Request to add "port" to
JavaMailSenderImpl settings


Tim,

I've just drawn Dmitriy's attention to your SF request this morning :-)

Regards,
Rod

----- Original Message ----- 
From: "Tim McAuley" <ti...@mo...>
To: <spr...@li...>
Sent: Thursday, November 06, 2003 10:47 AM
Subject: [Springframework-developer] Request to add "port" to
JavaMailSenderImpl settings


> Hi,
>
> I was wondering if it could be possible to add a
> setPort() method to the JavaMailSenderImpl class.
>
> This would allow for sending email via a mail server
> which does not use the standard port of 25. I have
> looked at the code and all it should require is a new
> setting to be added for the port and the
> Transport.connect() call modified.
>
> I have placed a request on sourceforge for this at 
> http://sourceforge.net/tracker/?group_id=73357&atid=537542
> (not sure if theses sourceforge facilities are used much).
>
> Thanks,
>
> Tim
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program. Does 
> SourceForge.net help you be more productive?  Does it
> help you create better code?   SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/ 
> _______________________________________________
> Springframework-developer mailing list 
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program. Does
SourceForge.net help you be more productive?  Does it
help you create better code?   SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Request to add "port" to JavaMailSenderImpl settings

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

Tim,

I've just drawn Dmitriy's attention to your SF request this morning :-)

Regards,
Rod

----- Original Message ----- 
From: "Tim McAuley" <ti...@mo...>
To: <spr...@li...>
Sent: Thursday, November 06, 2003 10:47 AM
Subject: [Springframework-developer] Request to add "port" to
JavaMailSenderImpl settings


> Hi,
>
> I was wondering if it could be possible to add a
> setPort() method to the JavaMailSenderImpl class.
>
> This would allow for sending email via a mail server
> which does not use the standard port of 25. I have
> looked at the code and all it should require is a new
> setting to be added for the port and the
> Transport.connect() call modified.
>
> I have placed a request on sourceforge for this at
> http://sourceforge.net/tracker/?group_id=73357&atid=537542
> (not sure if theses sourceforge facilities are used much).
>
> Thanks,
>
> Tim
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?   SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] Request to add "port" to JavaMailSenderImpl settings

[Alef A. \(JTeam\) <al...@jt...>]

A couple of weeks ago, I kind of promised to put this is already.
Totally forgot, so I'll have a look at it today.

Alef

> -----Oorspronkelijk bericht-----
> Van: spr...@li... 
> [mailto:spr...@li...]
>  Namens Tim McAuley
> Verzonden: Thursday, November 06, 2003 11:47 AM
> Aan: spr...@li...
> Onderwerp: [Springframework-developer] Request to add "port" 
> to JavaMailSenderImpl settings
> 
> 
> Hi,
> 
> I was wondering if it could be possible to add a
> setPort() method to the JavaMailSenderImpl class.
> 
> This would allow for sending email via a mail server
> which does not use the standard port of 25. I have
> looked at the code and all it should require is a new
> setting to be added for the port and the
> Transport.connect() call modified.
> 
> I have placed a request on sourceforge for this at 
> http://sourceforge.net/tracker/?group_id=73357&atid=537542
> (not sure if theses sourceforge facilities are used much).
> 
> Thanks,
> 
> Tim
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program. 
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?   SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/ 
> _______________________________________________
> Springframework-developer mailing list 
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 

[Springframework-developer] Request to add "port" to JavaMailSenderImpl settings

[Tim M. <ti...@mo...>]

Hi,

I was wondering if it could be possible to add a
setPort() method to the JavaMailSenderImpl class.

This would allow for sending email via a mail server
which does not use the standard port of 25. I have
looked at the code and all it should require is a new
setting to be added for the port and the
Transport.connect() call modified.

I have placed a request on sourceforge for this at 
http://sourceforge.net/tracker/?group_id=73357&atid=537542
(not sure if theses sourceforge facilities are used much).

Thanks,

Tim

[Springframework-developer] JDBC exception translation

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

This reminds me: we really need to try to increase the range of our error
codes in sql-error-codes.xml and make the SQLStateErrorCodeTranslator more
comprehensive.

Any volunteers for contributing vendor error codes based on Oracle manuals
etc. and SQLState codes based on the relevant SQL standard?

Regards,
Rod

----- Original Message ----- 
From: "jürgen höller [werk3AT]" <jue...@we...>
To: <spr...@li...>
Sent: Wednesday, November 05, 2003 8:35 PM
Subject: Re: [Springframework-developer] Reworked transaction managers and
Hibernate/JDO support


I've just added one more refactoring: I've dissolved ThreadObjectManager and
put the resource binding (for JDBC/JDO/Hibernate/etc) into
TransactionSynchronizationManager.

Additionally, DataSourceUtils and PersistenceManagerFactoryUtils now
register transaction synchronizations for JDBC Connections and JDO
PersistenceManagers, respectively: This mainly means that you are guaranteed
to get the same JDBC Connection or JDO PersistenceManager per DataSource
respectively PersistenceManagerFactory in a Spring-managed JTA transaction,
just like it already was the case with a Hibernate Session per
SessionFactory.

You can thus rely on receiving the same JDBC Connection within a JTA
transaction instead of having to trust your JTA implementation. Colin,
haven't you had concerns about that a while ago?

Juergen


________________________________

Von: spr...@li... im Auftrag von
jürgen höller [werk3AT]
Gesendet: Mi 05.11.2003 10:43
An: spr...@li...
Betreff: [Springframework-developer] Reworked transaction managers and
Hibernate/JDO support



I've committed a significant refactoring of our transaction manager
implementations: AbstractPlatformTransactionManager has a
"cleanupAfterCompletion" template method now, which has formerly been
handled by subclasses. It also cares about exception handling on commit
failure now, offering a "rollbackOnCommitFailure" property with the default
being "false". The latter is intended for misbehaving JDBC drivers or JDO
implementations; normally, there shouldn't be a need to set it to true.

HibernateTemplate and HibernateTransactionManager have a
"jdbcExceptionTranslator" property now, supporting a SQLExceptionTranslator
that kicks in when callback code throws an SQLException or
HibernateJDBCException. Default is SQLStateSQLExceptionTranslator because of
the ease of setup. The main rationale is to throw proper
DataIntegrityViolationExceptions on corresponding Hibernate-rethrown
SQLExceptions - Steve from the Hibernate team made be aware of the issue.

JdoTemplate and JdoInterceptor have a common base class JdoAccessor now,
similar to HibernateAccessor, and support for a JdoDialect. The latter
represents a strategy for retrieving the underlying JDBC connection and for
eagerly flushing a PersistenceManager, to be implemented for specific JDO
products. It also provides a hook for specific translation of JDOExceptions
to Spring's DataAccessException hierarchy. This allows for richer support of
JDO in Spring, like exporting transactions to JDBC access code and eager
flushing to make the latter aware of changes.

Juergen


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?   SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?   SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Reworked transaction managers and Hibernate/JDO support

[<jue...@we...>]

I've just added one more refactoring: I've dissolved ThreadObjectManager =
and put the resource binding (for JDBC/JDO/Hibernate/etc) into =
TransactionSynchronizationManager.
=20
Additionally, DataSourceUtils and PersistenceManagerFactoryUtils now =
register transaction synchronizations for JDBC Connections and JDO =
PersistenceManagers, respectively: This mainly means that you are =
guaranteed to get the same JDBC Connection or JDO PersistenceManager per =
DataSource respectively PersistenceManagerFactory in a Spring-managed =
JTA transaction, just like it already was the case with a Hibernate =
Session per SessionFactory.
=20
You can thus rely on receiving the same JDBC Connection within a JTA =
transaction instead of having to trust your JTA implementation. Colin, =
haven't you had concerns about that a while ago?
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von j=FCrgen h=F6ller [werk3AT]
Gesendet: Mi 05.11.2003 10:43
An: spr...@li...
Betreff: [Springframework-developer] Reworked transaction managers and =
Hibernate/JDO support



I've committed a significant refactoring of our transaction manager =
implementations: AbstractPlatformTransactionManager has a =
"cleanupAfterCompletion" template method now, which has formerly been =
handled by subclasses. It also cares about exception handling on commit =
failure now, offering a "rollbackOnCommitFailure" property with the =
default being "false". The latter is intended for misbehaving JDBC =
drivers or JDO implementations; normally, there shouldn't be a need to =
set it to true.

HibernateTemplate and HibernateTransactionManager have a =
"jdbcExceptionTranslator" property now, supporting a =
SQLExceptionTranslator that kicks in when callback code throws an =
SQLException or HibernateJDBCException. Default is =
SQLStateSQLExceptionTranslator because of the ease of setup. The main =
rationale is to throw proper DataIntegrityViolationExceptions on =
corresponding Hibernate-rethrown SQLExceptions - Steve from the =
Hibernate team made be aware of the issue.

JdoTemplate and JdoInterceptor have a common base class JdoAccessor now, =
similar to HibernateAccessor, and support for a JdoDialect. The latter =
represents a strategy for retrieving the underlying JDBC connection and =
for eagerly flushing a PersistenceManager, to be implemented for =
specific JDO products. It also provides a hook for specific translation =
of JDOExceptions to Spring's DataAccessException hierarchy. This allows =
for richer support of JDO in Spring, like exporting transactions to JDBC =
access code and eager flushing to make the latter aware of changes.

Juergen


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?   SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Bean factory getting access to its bean id

[Cameron B. <ca...@da...>]

I've just checkout this code.

The bean/@id attribute relaxing is fantastic thanks!

I can now use the Spring Framework as an Action Factory for 
Xwork/WebWork with no duplcation of configuration, using spring to 
define business related interceptors : components, transactions, 
security and webwork to provide web/view oriented interceptors : 
request-params, validation

xwork.xml snippet :

<package name="admin" namespace="/admin" extends="default">
    <action name="update" class="com.project.AdminUpdateAction" 
method="txUpdate">
       <result name="redirect">read.action?id=${id}</result>
    </action>
</package>

applicationContext.xml snippet :

<bean name="/admin/update" 
class="com.datacodex.spring.webwork.WebworkActionFactoryBean">
     <property name="sessionFactory"><ref 
local="sessionFactory"/></property>
     <property name="transactionManager"><ref 
local="transactionManager"/></property>
     <property name="transactionAttributes"><ref 
local="defaultActionTransactionAttributes"/></property>
</bean>

very simple, neat and clean !

Thanks guys for your fantastic framework.

Cameron.


jürgen höller [werk3AT] wrote:

>Cameron,
> 
>Good points. I've repeatedly considered relaxing that XML id requirement myself, BTW, to ease BeanNameUrlHandlerMapping-mapped controllers definitions with Spring's web MVC.
> 
>So I've just implemented the following changes:
> 
>- There's a BeanNameAware interface now, with a setBeanName method that gets called on initialization. BTW, the BeanFactory interface calls the canonical name "name" and alias names "aliases", while the XML bean definition format adopts the XML style of an id attribute, allowing for multiple aliases via a delimited "name" attribute.
> 
>- The "id" attribute is no longer required in the XML bean definition format. If no id is specified, the first name in the "name" attribute will be used as canonical name (all others as aliases). If no id and no name specified, an exception will get thrown. Note that you need to use the generic <ref bean=".../> syntax to reference any bean name, as the more restrictive <ref local="..."/> will be validated against local XML ids. In general, if you don't need to rely on XML id validation, always use <ref bean="..."/>.
> 
>- Spring already had a PropertiesFactoryBean class for making a properties file in the class path available as Properties bean in the bean factory. I've reworked this to also support local properties via a "properties" bean property (to be filled via "<props>" in the XML case). It can also merge properties from a file with locally defined ones. You should be able to use that instead of your own PropertiesFactoryBean implementation. There's also a ResourcePropertiesFactoryBean that loads a properties file as application context resource (via ApplicationContext.getResourceByPath).
> 
>If noone objects, I will commit these changes to CVS tomorrow. I guess the "id" relaxation is debatable, but I'm strongly for it as my colleagues at werk3AT tend to use BeanNameUrlHandlerMapping a lot and have repeatedly complained about the need for an additional id attribute. Cameron faces a similar use case for WebWork actions; we should ease such stuff, even if XML ids are still recommended for normal beans.
> 
>Juergen
> 
>
>	-----Ursprüngliche Nachricht----- 
>	Von: Cameron Braid [mailto:ca...@da...] 
>	Gesendet: Sa 01.11.2003 13:20 
>	An: spr...@li... 
>	Cc: 
>	Betreff: [[W3-SPAM]] - [Springframework-developer] Bean factory getting access to its bean id - Email found in subject
>	
>	
>
>	Is there any way that I can allow a bean factory to find out its id
>	attribute from the applicationContext.xml
>	
>	i.e. I am trying to get a grip on how spring works, and therefore I am
>	trying to write a little integration layer to make spring an action
>	factory for xwork, to allow me to use spring components and
>	interceptors.  I want to try and avoid repetition of configuration
>	wherever possible.
>	
>	I have it at the stage where I have a bean declaration like this :
>	
>	    <bean id="defaultActionTransactionAttributes"
>	class="com.datacodex.spring.beans.PropertiesFactoryBean">
>	        <property name="properties">
>	            <props>
>	                <prop key="execute">PROPAGATION_REQUIRED</prop>
>	            </props>
>	        </property>
>	    </bean>
>	
>	    <bean id="admin.SpringAdminAction" class="WebworkActionFactoryBean">
>	        <property
>	name="action"><value>/admin/SpringAdminAction</value></property>
>	        <property name="transactionManager"><ref
>	local="transactionManager"/></property>
>	        <property name="transactionAttributes"><ref
>	local="defaultActionTransactionAttributes"/></property>
>	    </bean>
>	
>	I would like to be able to access the id="admin.SpringAdminAction" value
>	(or the bean name attribute) from within the WebworkActionFactoryBean
>	therefore removing the need to have the extra 'action' property
>	<property name="action"><value>/admin/SpringAdminAction</value></property>.
>	
>	Idealy I would like to use the /admin/SpringAdminAction as the bean id
>	to make mapping from WebWork seamless, and without needing the
>	conversion to '.' style.
>	Therefore - is there any way that the bean id can be changed to allow
>	any valid xml string ?  Currently I am receiving an exception, from the
>	xml validator.  Can the id atttribuet be changed to be a
>	
>	[22:12:29]INFO [XmlBeanFactory] Loading XmlBeanFactory from InputStream
>	[[ReadStream com.caucho.vfs.FileReadStream@190a0d6]]
>	[22:12:29]ERROR[ContextLoader] Failed to initialize beans in application
>	context: Line 44 in XML document is invalid; nested exception is:
>	    org.xml.sax.SAXParseException: Attribute value
>	"/admin/SpringAdminAction" of type ID must be a name.
>	org.xml.sax.SAXParseException: Attribute value
>	"/admin/SpringAdminAction" of type ID must be a name.
>	    at org.apache.xerces.parsers.DOMParser.parse(Unknown Source)
>	    at org.apache.xerces.jaxp.DocumentBuilderImpl.parse(Unknown Source)
>	    at javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:76)
>	
>	The dtd states that it myst be a valid XML ID, and to use the optional
>	name attribute if you want an illegal name.  Though this will require
>	two identifyers for the bean, which I think is pointless.  Does the ID
>	have to be mandatory.  Can't a validation be implemented in java to
>	check that atleast the name or the id is supplied ?  Then the same for
>	the <!ATTLIST ref local IDREF #IMPLIED>  this could be a CDATA with java
>	based validation.
>	
>	Cheers,
>	
>	Cameron
>	
>	--
>	Any damn fool can write code that a computer can understand...
>	The trick is to write code that humans can understand.
>	[Martin Fowler http://www.martinfowler.com/distributedComputing/refactoring.pdf]
>	
>	
>	
>	
>	
>	-------------------------------------------------------
>	This SF.net email is sponsored by: SF.net Giveback Program.
>	Does SourceForge.net help you be more productive?  Does it
>	help you create better code?   SHARE THE LOVE, and help us help
>	YOU!  Click Here: http://sourceforge.net/donate/
>	_______________________________________________
>	Springframework-developer mailing list
>	Spr...@li...
>	https://lists.sourceforge.net/lists/listinfo/springframework-developer
>	
>
>N?HY޵隊X???'???u??w?+?m?$>? ????????xZ+??޶??*.m騭?k?ۜ?+?????^??????jכz?^??y!?DD????݅?i??^??P)brAޭ?m??????q???z?ݢv?{?)?~??{
>+?ׯzZ)z???X??X??*k?x???Š?u?ޖ?^?X???(??~??zw???i????l???q???z???l?X??)ߣ?)?)?~??{
>+?ׯzZ)er==
>


-- 
Any damn fool can write code that a computer can understand...
The trick is to write code that humans can understand.
[Martin Fowler http://www.martinfowler.com/distributedComputing/refactoring.pdf]

Re: [Springframework-developer] Singelton FactoryBeans are asked for an object before beanFactor.getBean(name) is called by application

[Cameron B. <ca...@da...>]

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
configurable lazy-init : excellent thanks.<br>
<br>
What are your plans for singleton FactoryBeans where getObject is a
prototype.&nbsp; Currently they are eager-inited.&nbsp;&nbsp; In this case I think
that the 'lazy-init' attribute should be ignored and should not call
getObject on the FactoryBean during the init phase<br>
<br>
Thanks.<br>
<br>
Cameron.<br>
<br>
j&uuml;rgen h&ouml;ller [werk3AT] wrote:<br>
<blockquote type="cite"
 cite="mid...@co...">
  <pre wrap="">I'Ve just added support for lazy initialization of singletons, and a "lazy-init" of the XML "bean" tag (with "false" as default). On the occasion, I've also reworked AbstractBeanDefinition/RootBeanDefinition/ChildBeanDefinition for more consistency in terms of parameter handling.
 
Juergen
 

________________________________

Von: <a class="moz-txt-link-abbreviated" href="mailto:spr...@li...">spr...@li...</a> im Auftrag von Rod Johnson
Gesendet: Mi 05.11.2003 09:37
An: <a class="moz-txt-link-abbreviated" href="mailto:spr...@li...">spr...@li...</a>
Betreff: [[W3-SPAM]] - Re: [Springframework-developer] Singelton FactoryBeans are asked for an object before beanFactor.getBean(name) is called by application - Email found in subject



  </pre>
  <blockquote type="cite">
    <pre wrap="">Good point: I've just added a check to ListableBeanFactoryImpl's
    </pre>
  </blockquote>
  <pre wrap=""><!---->preInstantiateSingletons method to ignore FactoryBeans that return
isSingleton=false. I'm also inclined to agree that adding some "lazy-init"
argument to the "bean" tag would make sense.

Yes, a lazy option would be good. However, I think eager instantiation is
the appropriate default.

Regards,
Rod




-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?   SHARE THE LOVE, and help us help
YOU!  Click Here: <a class="moz-txt-link-freetext" href="http://sourceforge.net/donate/">http://sourceforge.net/donate/</a>
_______________________________________________
Springframework-developer mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Spr...@li...">Spr...@li...</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/springframework-developer">https://lists.sourceforge.net/lists/listinfo/springframework-developer</a>




-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?   SHARE THE LOVE, and help us help
YOU!  Click Here: <a class="moz-txt-link-freetext" href="http://sourceforge.net/donate/">http://sourceforge.net/donate/</a>
_______________________________________________
Springframework-developer mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Spr...@li...">Spr...@li...</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/springframework-developer">https://lists.sourceforge.net/lists/listinfo/springframework-developer</a>

  </pre>
</blockquote>
<br>
<br>
<pre cols="72" class="moz-signature">-- 
Any damn fool can write code that a computer can understand...
The trick is to write code that humans can understand.
[Martin Fowler <a class="moz-txt-link-freetext" href="http://www.martinfowler.com/distributedComputing/refactoring.pdf">http://www.martinfowler.com/distributedComputing/refactoring.pdf</a>]</pre>
</body>
</html>

[Springframework-developer] Re: Plug'nPlay for AbstractApplicationContext & ListableBeanFactory

[roger h. <apo...@sn...>]

Juergen

Thanks for the clarification - now it all makes perfect sense ;)

Roger


"jürgen höller [werk3AT]" <jue...@we...> wrote in message
news:170...@co......
Roger,

ApplicationListener beans are not normally returned to application code.
They are registered with the application context and get automatically
notified of ApplicationEvents. Why would you want to touch an
ApplicationListener in another application object? I agree that prototype
listeners do not have any benefits, thus listeners will almost always be
singletons. I thus wouldn't mind changing that getBeansOfType call to
(false, false) but I don't see any misbehavior with the current
implementation either.

Juergen


________________________________

Von: spr...@li... im Auftrag von
roger holbrook
Gesendet: Mi 05.11.2003 11:10
An: spr...@li...
Betreff: [[W3-SPAM]] - [Springframework-developer] Re: Plug'nPlay for
AbstractApplicationContext & ListableBeanFactory - Email found in subject




Hi Juergen

At first glance the interfaces in the beans.factory.config interfaces look
great - Plug'nPlay restored !

On the use of getBeansOfType() in AbstractApplicationContext, to refine the
instances returned, there still seems to be something odd to me.  The code
from within AbstractApplicationContext() now looks like this:

private void refreshListeners() {
    logger.info("Refreshing listeners");
    Collection listeners = getBeansOfType(ApplicationListener.class, true,
false).values();
    logger.debug("Found " + listeners.size() + " listeners in bean
factory");
    for (Iterator it = listeners.iterator(); it.hasNext();) {
        ApplicationListener listener = (ApplicationListener) it.next();
        addListener(listener);
        logger.info("Application listener [" + listener + "] added");
    }
}

But I think the behaviour that follows will actually be a bit strange, ie:
- all singletons bean instances that implement ApplicationListener will have
been registered as listeners by the time they are returned from getBean() to
application code
- all prototype bean instances that implement ApplicationListener will NOT
have been registered as listeners by the time they are returned from
getBean() to application code
- a set of prototype bean instances that implement ApplicationListener WILL
have been registered as listeners, by the above code, but these will NOT be
returned from getBean() to any application code

I think I was probably expecting to see the above call looking like:

    Collection listeners = getBeansOfType(ApplicationListener.class, false,
false).values();

and the prototypes dealt with using something like
ApplicationContextAwareProcessor, but having said that, I suppose that could
take care of the singletons as well - tra la.

The bottom line is I actually have no idea at all how these listeners might
be being used - so this may all be completely irrelevant - anyway no
doubt you'll set me straight ;)

Roger


"jürgen höller [werk3AT]" <jue...@we...> wrote in message
news:170...@co......
Roger, everybody,

I've just committed all the stuff that I've been working on, including the
bean factory SPI interfaces, the reworked post-processors, and the
BeanNameAware interface. In the course of this, I've refined quite some API
signatures and even package locations - there is a new beans.factory.config
package now, with the post-processor interfaces moved there. Most
applications shouldn't be affected, but for example custom post-processor
implementations will be. For details, see the changelog and the new CVS
contents...

BTW, I've also adopted your suggestion regarding getBeansOfType and added
"includePrototypes" and "includeFactoryBeans" flags, indicating whether one
wants to perform those more expensive operations too.

Juergen


________________________________

Von: spr...@li... im Auftrag von
roger holbrook
Gesendet: Di 04.11.2003 18:04
An: spr...@li...
Betreff: [[W3-SPAM]] - [Springframework-developer] Re: Re: Re: Plug'nPlay
for AbstractApplicationContext & ListableBeanFactory - Email found in
subject



Thanks Colin

when Juergen actually commits the code, I'll give a try ;)



"Colin Sampaleanu" <col...@ex...> wrote in message
news:3FA...@ex......
> Roger,
>
> Try hitting the 'alternate' CVS server at sf.net described here:
>
>
http://sourceforge.net/docman/display_doc.php?docid=14033&group_id=1#firewal
l
>
> It does allow anon access, and last time I verified this (about a month
> ago), it was completely up to date, as opposed to 24 hours behind like
> the main anon server.
>
>
>
> roger holbrook wrote:
>
> >Hi Juergen
> >
> >The changes you describe sound great - & as soon as anonymous CVS catches
> >up, I'll check them out.  Unfortunately, all I can see so far is an empty
> >beans.factory.config directory :(
> >
> >Many thanks
> >
> >Roger
> >
> >
> >"jürgen höller [werk3AT]" <jue...@we...> wrote in message
> >news:170...@co......
> >Roger,
> >
> >I've adopted your idea of an SPI interface for bean factories: I've just
> >introduced ConfigurableBeanFactory and ConfigurableListableBeanFactory
> >interfaces in a new beans.factory.config package; I've also moved
> >BeanFactoryProcessor and BeanFactoryPostProcessor there. The latter's
> >postProcessBeanFactory method uses ConfigurableListableBeanFactory now,
as
> >does AbstractApplicationContext's getBeanFactory template method.
> >
> >I'm still not entirely sure why you would want to use a different bean
> >factory with AbstractApplicationContext to leverage AOP functionality.
All
> >of Spring's AOP support should work without making the bean factory
> >implementation explicitly aware of it. BeanPostProcessors and
> >BeanFactoryPostProcessors are automatically detected and applied if
defined
> >as beans in an application context.
> >
> >Thanks for the thorough code review, BTW :-)
> >
> >Juergen
> >
> >
> >________________________________
> >
> >Von: spr...@li... im Auftrag von
> >roger holbrook
> >Gesendet: So 02.11.2003 18:46
> >An: spr...@li...
> >Betreff: [[W3-SPAM]] - [[W3-SPAM]] - [[W3-SPAM]] - [[W3-SPAM]] -
> >[[W3-SPAM]] - [Springframework-developer] Re: Plug'nPlay for
> >AbstractApplicationContext & ListableBeanFactory - Email found in
subject -
> >Email found in subject - Email found in subject - Email found in
subject -
> >Email found in subject
> >
> >
> >
> >
> >Hi Juergen
> >
> >Many thanks for the explanation about
> >AbstractApplicationContext.getBeanFactory.
> >
> >Just to check I've got it straight - would the following be an accurate
> >summary:
> >- ListableBeanFactory & ApplicationContext are client facing interfaces
> >designed to hide all things related to implementation.
> >- ListableBeanFactoryImpl & AbstractApplicationContext provide consistent
> >out-of-the-box BeanFactory implementations that are considered of
essential
> >importance.
> >- Currently the linkage between these 2 default implementations happens
to
> >be that one acts as a delegate class for the other, ie. the return type
in
> >question.
> >
> >The reworking of JdbcBeanFactory as a subclass of
ListableBeanFactoryImpl,
> >obviously solves the wiring problem in this particular case - but it does
> >nothing for the general case of Plug'nPlay.  With the current
arrangement,
> >the one thing I cannot do is achieve effective easy reuse of all that
highly
> >crafted functionality that is so intricately wired up in
AbstractBeanFactory
> >and ListableBeanFactoryImpl - I cannot wrap and delegate !
> >
> >Aside from the implied name conflict, could you not preserve the original
> >intention of making the linkage between the two an internal interface:
> >
> >interface ListableBeanFactoryImp extends ListableBeanFactory {
> >
> >    public void ignoreDependencyType(Class type)
> >
> >    public void addBeanPostProcessor(BeanPostProcessor beanPostProcessor)
> >
> >    public final void destroySingletons()
> >
> >}
> >
> >The example that is actually motivating my thinking, is related to the
AOP
> >stuff.  If I want try to add functionality to a BeanFactory so that it
can
> >be aware of ProxyFactoryBean's for example, then the most simple approach
> >would be to use an XmlBeanFactory to read the bean definitions, but then
to
> >wrap and delegate to this, from within an AOP aware BeanFactory.  The
latter
> >could initialise itself via a BeanFactoryPostProcessor, and then provide
> >useful implementation support within the AOP module, ie it would again be
> >extending a ListableBeanFactoryImp interface, rather than anything client
> >facing.
> >
> >As you say, all this can obviously be achieved by building BeanFactory's
&
> >ApplicationContext's from scratch, but it seems a great shame not to be
able
> >to reuse the ListableBeanFactoryImpl class - it has so much to offer ;)
> >
> >Anyway, I am sure the you get the sense of what I am on about - I just
hope
> >I am not missing something fundamental to the whole issue ;)
> >
> >Roger
> >
> >
> >"jürgen höller [werk3AT]" <jue...@we...> wrote in message
> >news:420...@ma......
> >
> >
> >>First of all, thanks for your kind words, Roger -- I appreciate them!
:-)
> >>
> >>Regarding AbstractApplicationContext.getBeanFactory: I've indeed changed
> >>
> >>
> >its return value from ListableBeanFactory to ListableBeanFactoryImpl a
while
> >ago, reason being that AbstractApplicationContext needs some
configuration
> >stuff that AbstractBeanFactory and ListableBeanFactoryImpl offer. The
> >BeanFactory and ListableBeanFactory interfaces are intended for client
> >applications that access beans, they do not and should not include any
> >factory configuration or lifecycle methods.
> >
> >
> >>In detail, AbstractApplicationContext needs to invoke the following bean
> >>
> >>
> >factory implementation methods:
> >
> >
> >>- ignoreDependencyType: to register ApplicationContext as dependency
type
> >>
> >>
> >to ignore on autowiring (as it is set by the ApplicationContextAware
> >interface, not by a property value).
> >
> >
> >>- addBeanPostProcessor: to register BeanPostProcessors, both
> >>
> >>
> >ApplicationContextAwareProcessor and custom ones, before creating
> >application beans from the bean definitions.
> >
> >
> >>- destroySingletons: to destroy singleton instances on application
context
> >>
> >>
> >shutdown; particularly important for resource holders like a
BasicDataSource
> >or a LocalSessionFactoryBean.
> >
> >
> >>- Furthermore, the postProcessBeanFactory method in the
> >>
> >>
> >BeanFactoryPostProcessor interface declares a ListableBeanFactoryImpl
> >parameter to allow for access to all these bean factory configuration
> >methods. A ListableBeanFactory interface would be meaningless for this,
as
> >you can't do any post-processing of bean definitions without access to
them
> >and means to manipulate them.
> >
> >
> >>Let's not forget that is always possible to write an own
> >>
> >>
> >ApplicationContext implementation with any kind of bean factory
underneath,
> >or a direct implementation of bean factory functionality instead of a
> >delegate, by not deriving from AbstractApplicationContext. The latter is
> >specifically intended for ListableBeanFactoryImpl delegates, providing
rich
> >configuration functionality on top of them.
> >
> >
> >>Regarding JdbcBeanFactory: This one used a delegate
> >>
> >>
> >ListableBeanFactoryImpl underneath to be able to perform on-demand
> >refreshing. This is somewhat inconsistent with XmlBeanFactory's
> >implementation style: The latter derives from ListableBeanFactoryImpl and
> >adds various XML-related registerBeanDefinitions methods, leaving refresh
> >functionality to application contexts. IMO, that's a clear separation of
> >responsibilities: A BeanFactory is a low-level implementation; an
> >ApplicationContext builds higher-level functionality on top of it.
> >
> >
> >>Thus, I've changed JdbcBeanFactory to extend ListableBeanFactoryImpl and
> >>
> >>
> >provide a registerBeanDefinitions(sql) method. Of course, it still has
the
> >former (dataSource,sql) constructor as a convenience. I don't think that
> >anyone used JdbcBeanFactory's on-demand refresh anyway (or even loading
> >beans from a database in the first place), so that change shouldn't hurt.
So
> >you can use JdbcBeanFactory with AbstractApplicationContext too, as it is
a
> >ListableBeanFactoryImpl now :-)
> >
> >
> >>Rod, do you agree with the rationale? I believe it's straightforward and
> >>
> >>
> >consistent, particularly now that JdbcBeanFactory has adopted
> >XmlBeanFactory's implementation style. I hope you don't object to
> >JdbcBeanFactory being a ListableBeanFactoryImpl; as I've said, I believe
it
> >is important to provide consistent out-of-the-box BeanFactory
> >implementations (i.e. no refresh in bean factories but just in
application
> >contexts).
> >
> >
> >>Juergen
> >>
> >>
> >>-----Ursprüngliche Nachricht-----
> >>Von: Rod Johnson [mailto:rod...@in...]
> >>Gesendet: Sa 01.11.2003 17:32
> >>An: spr...@li...
> >>Cc:
> >>Betreff: Re: [Springframework-developer] Plug'nPlay for
> >>
> >>
> >AbstractApplicationContext & ListableBeanFactory
> >
> >
> >>
> >>Roger,
> >>
> >>
> >>
> >>>I've been lurking about for a fair while, being thoroughly impressed by
> >>>Springframework - the conception, the code, this excellent list, Rod's
> >>>
> >>>
> >>book,
> >>
> >>
> >>>in short the whole shebang - it seems quite a while since I encountered
> >>>
> >>>
> >a
> >
> >
> >>>project that more than anything, just seems to make me smile ;)  Many
> >>>thanks.
> >>>
> >>>
> >>Thanks. Made me smile :-)
> >>
> >>
> >>
> >>>First up is the subject line & the method
> >>>AbstractApplicationContext.getBeanFactory()
> >>>I am wondering if the signature for this method might have been changed
> >>>inadvertently ?  Prior to the introduction of support for
> >>>BeanFactoryPostProcessor's, the method was returning the
> >>>
> >>>
> >>ListableBeanFactory
> >>
> >>
> >>>interface, but thereafter it has been ListableBeanFactoryImpl.  As the
> >>>latter comes with a final modifier on each of the methods implementing
> >>>
> >>>
> >>that
> >>
> >>
> >>>interface, the opportunity for Plug'nPlay appears to have gone
> >>>
> >>>
> >missing...
> >
> >
> >>&
> >>
> >>
> >>>if I'm not mistaken, a first casualty would be the loss of a
> >>>
> >>>
> >>JdbcBeanFactory
> >>
> >>
> >>>within an AbstractApplicationContext.  Can someone shed some
> >>>light - am I just missing something ?
> >>>
> >>>
> >>I'll leave this one to Juergen, but I did notice it in passing and
> >>wondered...
> >>
> >>
> >>
> >>>By the way, on my wanderings I noticed the following typo in
> >>>AbstractBeanDefinition.equals()
> >>>
> >>>
> >>Thanks, fixed it. Ah, the beauty of open source. That code isn't
currently
> >>used btw, it was intended to allow for dynamic reconfiguration
eventually.
> >>There would have been an argument for zapping it for now, actually.
> >>
> >>Regards,
> >>Rod
> >>
> >>
> >>
> >>
> >>-------------------------------------------------------
> >>This SF.net email is sponsored by: SF.net Giveback Program.
> >>Does SourceForge.net help you be more productive?  Does it
> >>help you create better code?   SHARE THE LOVE, and help us help
> >>YOU!  Click Here: http://sourceforge.net/donate/
> >>_______________________________________________
> >>Springframework-developer mailing list
> >>Spr...@li...
> >>https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >>
> >>
> >>NHY??X'u?w+m?$>  xZ+? *.m?k +?^? j?z^?y! DD??i ^P)brA?m?q ?z
v
> >>
> >>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?   SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/





-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?   SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?   SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/













-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?   SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?   SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/

Re: [Springframework-developer] Singelton FactoryBeans are asked for an object before beanFactor.getBean(name) is called by application

[<jue...@we...>]

I'Ve just added support for lazy initialization of singletons, and a =
"lazy-init" of the XML "bean" tag (with "false" as default). On the =
occasion, I've also reworked =
AbstractBeanDefinition/RootBeanDefinition/ChildBeanDefinition for more =
consistency in terms of parameter handling.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Rod Johnson
Gesendet: Mi 05.11.2003 09:37
An: spr...@li...
Betreff: [[W3-SPAM]] - Re: [Springframework-developer] Singelton =
FactoryBeans are asked for an object before beanFactor.getBean(name) is =
called by application - Email found in subject



>Good point: I've just added a check to ListableBeanFactoryImpl's
preInstantiateSingletons method to ignore FactoryBeans that return
isSingleton=3Dfalse. I'm also inclined to agree that adding some =
"lazy-init"
argument to the "bean" tag would make sense.

Yes, a lazy option would be good. However, I think eager instantiation =
is
the appropriate default.

Regards,
Rod




-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?   SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Plug'nPlay for AbstractApplicationContext & ListableBeanFactory

[<jue...@we...>]

Roger,
=20
ApplicationListener beans are not normally returned to application code. =
They are registered with the application context and get automatically =
notified of ApplicationEvents. Why would you want to touch an =
ApplicationListener in another application object? I agree that =
prototype listeners do not have any benefits, thus listeners will almost =
always be singletons. I thus wouldn't mind changing that getBeansOfType =
call to (false, false) but I don't see any misbehavior with the current =
implementation either.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von roger holbrook
Gesendet: Mi 05.11.2003 11:10
An: spr...@li...
Betreff: [[W3-SPAM]] - [Springframework-developer] Re: Plug'nPlay for =
AbstractApplicationContext & ListableBeanFactory - Email found in =
subject




Hi Juergen

At first glance the interfaces in the beans.factory.config interfaces =
look
great - Plug'nPlay restored !

On the use of getBeansOfType() in AbstractApplicationContext, to refine =
the
instances returned, there still seems to be something odd to me.  The =
code
from within AbstractApplicationContext() now looks like this:

private void refreshListeners() {
    logger.info("Refreshing listeners");
    Collection listeners =3D getBeansOfType(ApplicationListener.class, =
true,
false).values();
    logger.debug("Found " + listeners.size() + " listeners in bean
factory");
    for (Iterator it =3D listeners.iterator(); it.hasNext();) {
        ApplicationListener listener =3D (ApplicationListener) =
it.next();
        addListener(listener);
        logger.info("Application listener [" + listener + "] added");
    }
}

But I think the behaviour that follows will actually be a bit strange, =
ie:
- all singletons bean instances that implement ApplicationListener will =
have
been registered as listeners by the time they are returned from =
getBean() to
application code
- all prototype bean instances that implement ApplicationListener will =
NOT
have been registered as listeners by the time they are returned from
getBean() to application code
- a set of prototype bean instances that implement ApplicationListener =
WILL
have been registered as listeners, by the above code, but these will NOT =
be
returned from getBean() to any application code

I think I was probably expecting to see the above call looking like:

    Collection listeners =3D getBeansOfType(ApplicationListener.class, =
false,
false).values();

and the prototypes dealt with using something like
ApplicationContextAwareProcessor, but having said that, I suppose that =
could
take care of the singletons as well - tra la.

The bottom line is I actually have no idea at all how these listeners =
might
be being used - so this may all be completely irrelevant - anyway no
doubt you'll set me straight ;)

Roger


"j=FCrgen h=F6ller [werk3AT]" <jue...@we...> wrote in =
message
news:170...@co......
Roger, everybody,

I've just committed all the stuff that I've been working on, including =
the
bean factory SPI interfaces, the reworked post-processors, and the
BeanNameAware interface. In the course of this, I've refined quite some =
API
signatures and even package locations - there is a new =
beans.factory.config
package now, with the post-processor interfaces moved there. Most
applications shouldn't be affected, but for example custom =
post-processor
implementations will be. For details, see the changelog and the new CVS
contents...

BTW, I've also adopted your suggestion regarding getBeansOfType and =
added
"includePrototypes" and "includeFactoryBeans" flags, indicating whether =
one
wants to perform those more expensive operations too.

Juergen


________________________________

Von: spr...@li... im Auftrag =
von
roger holbrook
Gesendet: Di 04.11.2003 18:04
An: spr...@li...
Betreff: [[W3-SPAM]] - [Springframework-developer] Re: Re: Re: =
Plug'nPlay
for AbstractApplicationContext & ListableBeanFactory - Email found in
subject



Thanks Colin

when Juergen actually commits the code, I'll give a try ;)



"Colin Sampaleanu" <col...@ex...> wrote in message
news:3FA...@ex......
> Roger,
>
> Try hitting the 'alternate' CVS server at sf.net described here:
>
>
http://sourceforge.net/docman/display_doc.php?docid=3D14033&group_id=3D1#=
firewal
l
>
> It does allow anon access, and last time I verified this (about a =
month
> ago), it was completely up to date, as opposed to 24 hours behind like
> the main anon server.
>
>
>
> roger holbrook wrote:
>
> >Hi Juergen
> >
> >The changes you describe sound great - & as soon as anonymous CVS =
catches
> >up, I'll check them out.  Unfortunately, all I can see so far is an =
empty
> >beans.factory.config directory :(
> >
> >Many thanks
> >
> >Roger
> >
> >
> >"j=FCrgen h=F6ller [werk3AT]" <jue...@we...> wrote in =
message
> >news:170...@co......
> >Roger,
> >
> >I've adopted your idea of an SPI interface for bean factories: I've =
just
> >introduced ConfigurableBeanFactory and =
ConfigurableListableBeanFactory
> >interfaces in a new beans.factory.config package; I've also moved
> >BeanFactoryProcessor and BeanFactoryPostProcessor there. The latter's
> >postProcessBeanFactory method uses ConfigurableListableBeanFactory =
now,
as
> >does AbstractApplicationContext's getBeanFactory template method.
> >
> >I'm still not entirely sure why you would want to use a different =
bean
> >factory with AbstractApplicationContext to leverage AOP =
functionality.
All
> >of Spring's AOP support should work without making the bean factory
> >implementation explicitly aware of it. BeanPostProcessors and
> >BeanFactoryPostProcessors are automatically detected and applied if
defined
> >as beans in an application context.
> >
> >Thanks for the thorough code review, BTW :-)
> >
> >Juergen
> >
> >
> >________________________________
> >
> >Von: spr...@li... im Auftrag =
von
> >roger holbrook
> >Gesendet: So 02.11.2003 18:46
> >An: spr...@li...
> >Betreff: [[W3-SPAM]] - [[W3-SPAM]] - [[W3-SPAM]] - [[W3-SPAM]] -
> >[[W3-SPAM]] - [Springframework-developer] Re: Plug'nPlay for
> >AbstractApplicationContext & ListableBeanFactory - Email found in
subject -
> >Email found in subject - Email found in subject - Email found in
subject -
> >Email found in subject
> >
> >
> >
> >
> >Hi Juergen
> >
> >Many thanks for the explanation about
> >AbstractApplicationContext.getBeanFactory.
> >
> >Just to check I've got it straight - would the following be an =
accurate
> >summary:
> >- ListableBeanFactory & ApplicationContext are client facing =
interfaces
> >designed to hide all things related to implementation.
> >- ListableBeanFactoryImpl & AbstractApplicationContext provide =
consistent
> >out-of-the-box BeanFactory implementations that are considered of
essential
> >importance.
> >- Currently the linkage between these 2 default implementations =
happens
to
> >be that one acts as a delegate class for the other, ie. the return =
type
in
> >question.
> >
> >The reworking of JdbcBeanFactory as a subclass of
ListableBeanFactoryImpl,
> >obviously solves the wiring problem in this particular case - but it =
does
> >nothing for the general case of Plug'nPlay.  With the current
arrangement,
> >the one thing I cannot do is achieve effective easy reuse of all that
highly
> >crafted functionality that is so intricately wired up in
AbstractBeanFactory
> >and ListableBeanFactoryImpl - I cannot wrap and delegate !
> >
> >Aside from the implied name conflict, could you not preserve the =
original
> >intention of making the linkage between the two an internal =
interface:
> >
> >interface ListableBeanFactoryImp extends ListableBeanFactory {
> >
> >    public void ignoreDependencyType(Class type)
> >
> >    public void addBeanPostProcessor(BeanPostProcessor =
beanPostProcessor)
> >
> >    public final void destroySingletons()
> >
> >}
> >
> >The example that is actually motivating my thinking, is related to =
the
AOP
> >stuff.  If I want try to add functionality to a BeanFactory so that =
it
can
> >be aware of ProxyFactoryBean's for example, then the most simple =
approach
> >would be to use an XmlBeanFactory to read the bean definitions, but =
then
to
> >wrap and delegate to this, from within an AOP aware BeanFactory.  The
latter
> >could initialise itself via a BeanFactoryPostProcessor, and then =
provide
> >useful implementation support within the AOP module, ie it would =
again be
> >extending a ListableBeanFactoryImp interface, rather than anything =
client
> >facing.
> >
> >As you say, all this can obviously be achieved by building =
BeanFactory's
&
> >ApplicationContext's from scratch, but it seems a great shame not to =
be
able
> >to reuse the ListableBeanFactoryImpl class - it has so much to offer =
;)
> >
> >Anyway, I am sure the you get the sense of what I am on about - I =
just
hope
> >I am not missing something fundamental to the whole issue ;)
> >
> >Roger
> >
> >
> >"j=FCrgen h=F6ller [werk3AT]" <jue...@we...> wrote in =
message
> >news:420...@ma......
> >
> >
> >>First of all, thanks for your kind words, Roger -- I appreciate =
them!
:-)
> >>
> >>Regarding AbstractApplicationContext.getBeanFactory: I've indeed =
changed
> >>
> >>
> >its return value from ListableBeanFactory to ListableBeanFactoryImpl =
a
while
> >ago, reason being that AbstractApplicationContext needs some
configuration
> >stuff that AbstractBeanFactory and ListableBeanFactoryImpl offer. The
> >BeanFactory and ListableBeanFactory interfaces are intended for =
client
> >applications that access beans, they do not and should not include =
any
> >factory configuration or lifecycle methods.
> >
> >
> >>In detail, AbstractApplicationContext needs to invoke the following =
bean
> >>
> >>
> >factory implementation methods:
> >
> >
> >>- ignoreDependencyType: to register ApplicationContext as dependency
type
> >>
> >>
> >to ignore on autowiring (as it is set by the ApplicationContextAware
> >interface, not by a property value).
> >
> >
> >>- addBeanPostProcessor: to register BeanPostProcessors, both
> >>
> >>
> >ApplicationContextAwareProcessor and custom ones, before creating
> >application beans from the bean definitions.
> >
> >
> >>- destroySingletons: to destroy singleton instances on application
context
> >>
> >>
> >shutdown; particularly important for resource holders like a
BasicDataSource
> >or a LocalSessionFactoryBean.
> >
> >
> >>- Furthermore, the postProcessBeanFactory method in the
> >>
> >>
> >BeanFactoryPostProcessor interface declares a ListableBeanFactoryImpl
> >parameter to allow for access to all these bean factory configuration
> >methods. A ListableBeanFactory interface would be meaningless for =
this,
as
> >you can't do any post-processing of bean definitions without access =
to
them
> >and means to manipulate them.
> >
> >
> >>Let's not forget that is always possible to write an own
> >>
> >>
> >ApplicationContext implementation with any kind of bean factory
underneath,
> >or a direct implementation of bean factory functionality instead of a
> >delegate, by not deriving from AbstractApplicationContext. The latter =
is
> >specifically intended for ListableBeanFactoryImpl delegates, =
providing
rich
> >configuration functionality on top of them.
> >
> >
> >>Regarding JdbcBeanFactory: This one used a delegate
> >>
> >>
> >ListableBeanFactoryImpl underneath to be able to perform on-demand
> >refreshing. This is somewhat inconsistent with XmlBeanFactory's
> >implementation style: The latter derives from ListableBeanFactoryImpl =
and
> >adds various XML-related registerBeanDefinitions methods, leaving =
refresh
> >functionality to application contexts. IMO, that's a clear separation =
of
> >responsibilities: A BeanFactory is a low-level implementation; an
> >ApplicationContext builds higher-level functionality on top of it.
> >
> >
> >>Thus, I've changed JdbcBeanFactory to extend ListableBeanFactoryImpl =
and
> >>
> >>
> >provide a registerBeanDefinitions(sql) method. Of course, it still =
has
the
> >former (dataSource,sql) constructor as a convenience. I don't think =
that
> >anyone used JdbcBeanFactory's on-demand refresh anyway (or even =
loading
> >beans from a database in the first place), so that change shouldn't =
hurt.
So
> >you can use JdbcBeanFactory with AbstractApplicationContext too, as =
it is
a
> >ListableBeanFactoryImpl now :-)
> >
> >
> >>Rod, do you agree with the rationale? I believe it's straightforward =
and
> >>
> >>
> >consistent, particularly now that JdbcBeanFactory has adopted
> >XmlBeanFactory's implementation style. I hope you don't object to
> >JdbcBeanFactory being a ListableBeanFactoryImpl; as I've said, I =
believe
it
> >is important to provide consistent out-of-the-box BeanFactory
> >implementations (i.e. no refresh in bean factories but just in
application
> >contexts).
> >
> >
> >>Juergen
> >>
> >>
> >>-----Urspr=FCngliche Nachricht-----
> >>Von: Rod Johnson [mailto:rod...@in...]
> >>Gesendet: Sa 01.11.2003 17:32
> >>An: spr...@li...
> >>Cc:
> >>Betreff: Re: [Springframework-developer] Plug'nPlay for
> >>
> >>
> >AbstractApplicationContext & ListableBeanFactory
> >
> >
> >>
> >>Roger,
> >>
> >>
> >>
> >>>I've been lurking about for a fair while, being thoroughly =
impressed by
> >>>Springframework - the conception, the code, this excellent list, =
Rod's
> >>>
> >>>
> >>book,
> >>
> >>
> >>>in short the whole shebang - it seems quite a while since I =
encountered
> >>>
> >>>
> >a
> >
> >
> >>>project that more than anything, just seems to make me smile ;)  =
Many
> >>>thanks.
> >>>
> >>>
> >>Thanks. Made me smile :-)
> >>
> >>
> >>
> >>>First up is the subject line & the method
> >>>AbstractApplicationContext.getBeanFactory()
> >>>I am wondering if the signature for this method might have been =
changed
> >>>inadvertently ?  Prior to the introduction of support for
> >>>BeanFactoryPostProcessor's, the method was returning the
> >>>
> >>>
> >>ListableBeanFactory
> >>
> >>
> >>>interface, but thereafter it has been ListableBeanFactoryImpl.  As =
the
> >>>latter comes with a final modifier on each of the methods =
implementing
> >>>
> >>>
> >>that
> >>
> >>
> >>>interface, the opportunity for Plug'nPlay appears to have gone
> >>>
> >>>
> >missing...
> >
> >
> >>&
> >>
> >>
> >>>if I'm not mistaken, a first casualty would be the loss of a
> >>>
> >>>
> >>JdbcBeanFactory
> >>
> >>
> >>>within an AbstractApplicationContext.  Can someone shed some
> >>>light - am I just missing something ?
> >>>
> >>>
> >>I'll leave this one to Juergen, but I did notice it in passing and
> >>wondered...
> >>
> >>
> >>
> >>>By the way, on my wanderings I noticed the following typo in
> >>>AbstractBeanDefinition.equals()
> >>>
> >>>
> >>Thanks, fixed it. Ah, the beauty of open source. That code isn't
currently
> >>used btw, it was intended to allow for dynamic reconfiguration
eventually.
> >>There would have been an argument for zapping it for now, actually.
> >>
> >>Regards,
> >>Rod
> >>
> >>
> >>
> >>
> >>-------------------------------------------------------
> >>This SF.net email is sponsored by: SF.net Giveback Program.
> >>Does SourceForge.net help you be more productive?  Does it
> >>help you create better code?   SHARE THE LOVE, and help us help
> >>YOU!  Click Here: http://sourceforge.net/donate/
> >>_______________________________________________
> >>Springframework-developer mailing list
> >>Spr...@li...
> =
>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >>
> >>
> >>N=18HY??X'u?=16w=1A+m?$> =12 xZ+? =17*.m?k +=0E?^? j?z^?=1Dy! =
DD=10?=11?i ^=0EP)brA?m?q =07?z
v
> >>
> >>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?   SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/





-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?   SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?   SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/













-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?   SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] Re: Is there a case for adding arbitrary bean metadata?

[roger h. <apo...@sn...>]

Hi Colin

Funny you should mention this, I had a similar line of thought a couple of
days ago, & also concluded that option 3, ie the use of
<meta-property></meta-property> was a natural solution.  However, I don't
think it needs to be exclusive to option 4, ie source level javadoc style
tags.  The two can happily co-exist as long as the mechanism for resolving
meta-data has a pluggable chain of handlers.  I guess in the normal scheme
of things this handler chain would look in the bean definition file, ahead
of the any attributes generated from the original source code.

For a good description of this sort of mechanism see the JBoss AOP docs:

http://www.jboss.org/index.html?module=html&op=userdisplay&id=developers/pro
jects/jboss/aop#chaining

Oh the meta-joys of life ;)

Roger


"Colin Sampaleanu" <co...@br...> wrote in message
news:3FA...@br......
> A friend has sent me some code for adding JMX instrumentation to beans
> in a Spring container, via BeanPostProcessor. Please see the email below
> for more details. Something like this, or extended from this, could make
> its way into Spring itself.
>
> Now what I am thinking is that when BeanPostProcessor comes into play
> (and not just for JMX), there is sometimes a usecase for being able to
> add arbitrary metadata to a bean definition inside the context. This JMX
> implementation is relatively simplistic; it instruments and exposes
> every singleton bean in the container, and exposes only the declared
> properties, but it needs to be told in a better fashion what to expose.
>
> Now one mechanism to handle JMX instrumenting in a more specific fashion
> is to modify the DTD to add elements specifically related to JMX, and
> BeanDefinition would just be modified in a simple fashion. I don't like
> this as it's too JMX specific.
>
> Another mechanism would be, as the deployer, for each bean that you want
> to expose, to add into the container a partner metadata bean which holds
> information on how to expose the target bean, and the JMX preprocessor
> would in fact work off these.
>
> However, it's arguably cleaner to just add the ability to add arbitrary
> metadata to bean definitions in the container. This metadata could be
> used in any fashion by any BeanPostProcessor implementations. This
> metadata could be parallel to the existing 'property' element,, e.g.
>   <bean id="x" class="x.y.z">
>     <property name="y"><value>zzzzz</value></property>
>     <meta-property name="a.b.c"><value>zzzzz</value></meta-property>
>   </bean>
> or maybe inline with existing properties, in which case Spring would
> form a parallel metadata tree to the defined properties. ie below, there
> is metadata being defined for the property 'y':
>   <bean id="x" class="x.y.z">
>     <property name="y">
>       <value>zzzzz</value>
>       <meta-property name="a.b.c"><value>zzzzz</value></meta-property>
>     </property>
>   </bean>
>
> The fourth way to get info to a JMX implementation of course is source
> level javadoc style tags, as currently being used for transactions and
> other metadata.
>
> What does everybody think of this approach to handling JMX in the first
> place, and the various mechanisms to get metadata to the JMX instrumenter?
>
> Regards,
> Colin
>
>
> Michael Zielenski wrote:
>
> >Here's the JMX code for Spring.
> >
> >What's included is a BeanPostProcessor that instruments and registers
beans in a given Spring context with an MBeanServer (factory wrapper bean is
also provided).  I've also included a wrapper around Sun's HTTP/HTML adaptor
from the RI.  Here's one way to write everything together:
> >
> ><beans>
> >
> > <bean id="mbeanServerFactory"
> >       class="com.whatever.common.spring.jmx.MBeanServerFactoryBean"
> >       singleton="true"
> >       init-method="initialize"
> >       destroy-method="destroy"/>
> >
> > <bean id="jmxHttpAdaptor"
> >       class="com.whatever.common.spring.jmx.HttpAdaptorWrapper"
> >       singleton="true"
> >       init-method="initialize"
> >       destroy-method="destroy"
> >       dependency-check="object">
> >     <property name="mbeanServer"><ref
bean="mbeanServerFactory"/></property>
> >     <property name="port"><value>9090</value></property>
> >     <property name="login"><value>admin</value></property>
> >     <property name="password"><value>admin</value></property>
> > </bean>
> >
> > <bean id="mbeanPostProcessor"
> >       class="com.whatever.common.spring.jmx.MBeanPostProcessor"
> >       singleton="true"
> >       dependency-check="object">
> >     <property name="server"><ref bean="mbeanServerFactory"/></property>
> > </bean>
> >
> >  ...
> >
> ></beans>
> >
> >
> >That's it.  I've been compiling against Sun's RI (1.2.1), and haven't
tried anything else yet.  Let me know how you make out.  Note that right now
all beans declared in the config are instrumented and registered; this is
obviously not ideal, so the next step would be to figure out how to convey
what to instrument to the postprocessor (i.e., extend the DTD and make this
part of RootBeanDefinition?  provide in the postprocessors config? etc).
> >
> >-----Original Message-----
> >From: Colin Sampaleanu
> >Sent: Monday, November 03, 2003 4:50 PM
> >To: Michael Zielenski
> >Subject: RE: Spring questions
> >
> >
> >That's pretty cool.   From what I know, now that sun has become a bit
less restrictive about bundling sun JMX classes, and have actually finished
the spec for the transport (it was never specified before), some people are
going back to the RI.
> >
> >In any case, I wouldn't mind looking at your stuff maybe. Perhaps it can
go into Spring itself.
> >
> >
> >-----Original Message-----
> >From: Michael Zielenski
> >Sent: November 3, 2003 4:46 PM
> >To: Colin Sampaleanu
> >Subject: RE: Spring questions
> >
> >
> >BTW, I added some basic JMX management to Spring, essentially a
BeanPostProcessor that instruments each bean in the context, exposing its
properties/attributes on the fly (no need to extend any JMX interfaces).  I
used the JMX RI (1.2.1), but quickly found that trying to deploy to
something like Resin was thorny since it already ships with a lame-ass JMX
impl itself.  I had a look at what else is out there (MX4J, XMOJO, etc), and
it seems they all bundle the javax.management classes *in their jars*...ick!
> >
> >-----Original Message-----
> >From: Colin Sampaleanu
> >Sent: Friday, October 31, 2003 11:00 AM
> >To: Michael Zielenski
> >Subject: RE: Spring questions
> >
> >
> >there's been talk of JMX support for the 1.1 timeframe
> >
> >-----Original Message-----
> >From: Michael Zielenski
> >Sent: October 31, 2003 10:57 AM
> >To: Colin Sampaleanu
> >Subject: RE: Spring questions
> >
> >
> >What about management?
> >
> >-----Original Message-----
> >From: Colin Sampaleanu
> >Sent: Friday, October 31, 2003 10:35 AM
> >To: Michael Zielenski
> >Subject: RE: Spring questions
> >
> >
> >Reconfigure is actually very hard to do due to the various lifecycles
that have to be managed, postprocessing, etc. Even outright reload gets
complicated, if you want to reload the same instance and have anybody
holding on to it just get the new values...
> >
> >
> >-----Original Message-----
> >From: Michael Zielenski
> >Sent: October 31, 2003 10:33 AM
> >To: Colin Sampaleanu
> >Subject: Spring questions
> >
> >
> >I've seen some reload methods here and there in Spring.  How does this
stuff actually work?  Is there a facility a la the log4j file watchdog that
will reload the context if the underlying config changes?  That would be
sweet (even sweeter if it could reconfigure existing bean instances, as
opposed to recreating the context from scratch).
> >
> >Also, is there any talk of adding management/instrumentation?  I guess it
would be easy enough to do with the AOP stuff...
> >
> >
> >
> >
>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?   SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/

[Springframework-developer] Re: Plug'nPlay for AbstractApplicationContext & ListableBeanFactory

[roger h. <apo...@sn...>]

Hi Juergen

At first glance the interfaces in the beans.factory.config interfaces look
great - Plug'nPlay restored !

On the use of getBeansOfType() in AbstractApplicationContext, to refine the
instances returned, there still seems to be something odd to me.  The code
from within AbstractApplicationContext() now looks like this:

private void refreshListeners() {
    logger.info("Refreshing listeners");
    Collection listeners = getBeansOfType(ApplicationListener.class, true,
false).values();
    logger.debug("Found " + listeners.size() + " listeners in bean
factory");
    for (Iterator it = listeners.iterator(); it.hasNext();) {
        ApplicationListener listener = (ApplicationListener) it.next();
        addListener(listener);
        logger.info("Application listener [" + listener + "] added");
    }
}

But I think the behaviour that follows will actually be a bit strange, ie:
- all singletons bean instances that implement ApplicationListener will have
been registered as listeners by the time they are returned from getBean() to
application code
- all prototype bean instances that implement ApplicationListener will NOT
have been registered as listeners by the time they are returned from
getBean() to application code
- a set of prototype bean instances that implement ApplicationListener WILL
have been registered as listeners, by the above code, but these will NOT be
returned from getBean() to any application code

I think I was probably expecting to see the above call looking like:

    Collection listeners = getBeansOfType(ApplicationListener.class, false,
false).values();

and the prototypes dealt with using something like
ApplicationContextAwareProcessor, but having said that, I suppose that could
take care of the singletons as well - tra la.

The bottom line is I actually have no idea at all how these listeners might
be being used - so this may all be completely irrelevant - anyway no
doubt you'll set me straight ;)

Roger


"jürgen höller [werk3AT]" <jue...@we...> wrote in message
news:170...@co......
Roger, everybody,

I've just committed all the stuff that I've been working on, including the
bean factory SPI interfaces, the reworked post-processors, and the
BeanNameAware interface. In the course of this, I've refined quite some API
signatures and even package locations - there is a new beans.factory.config
package now, with the post-processor interfaces moved there. Most
applications shouldn't be affected, but for example custom post-processor
implementations will be. For details, see the changelog and the new CVS
contents...

BTW, I've also adopted your suggestion regarding getBeansOfType and added
"includePrototypes" and "includeFactoryBeans" flags, indicating whether one
wants to perform those more expensive operations too.

Juergen


________________________________

Von: spr...@li... im Auftrag von
roger holbrook
Gesendet: Di 04.11.2003 18:04
An: spr...@li...
Betreff: [[W3-SPAM]] - [Springframework-developer] Re: Re: Re: Plug'nPlay
for AbstractApplicationContext & ListableBeanFactory - Email found in
subject



Thanks Colin

when Juergen actually commits the code, I'll give a try ;)



"Colin Sampaleanu" <col...@ex...> wrote in message
news:3FA...@ex......
> Roger,
>
> Try hitting the 'alternate' CVS server at sf.net described here:
>
>
http://sourceforge.net/docman/display_doc.php?docid=14033&group_id=1#firewal
l
>
> It does allow anon access, and last time I verified this (about a month
> ago), it was completely up to date, as opposed to 24 hours behind like
> the main anon server.
>
>
>
> roger holbrook wrote:
>
> >Hi Juergen
> >
> >The changes you describe sound great - & as soon as anonymous CVS catches
> >up, I'll check them out.  Unfortunately, all I can see so far is an empty
> >beans.factory.config directory :(
> >
> >Many thanks
> >
> >Roger
> >
> >
> >"jürgen höller [werk3AT]" <jue...@we...> wrote in message
> >news:170...@co......
> >Roger,
> >
> >I've adopted your idea of an SPI interface for bean factories: I've just
> >introduced ConfigurableBeanFactory and ConfigurableListableBeanFactory
> >interfaces in a new beans.factory.config package; I've also moved
> >BeanFactoryProcessor and BeanFactoryPostProcessor there. The latter's
> >postProcessBeanFactory method uses ConfigurableListableBeanFactory now,
as
> >does AbstractApplicationContext's getBeanFactory template method.
> >
> >I'm still not entirely sure why you would want to use a different bean
> >factory with AbstractApplicationContext to leverage AOP functionality.
All
> >of Spring's AOP support should work without making the bean factory
> >implementation explicitly aware of it. BeanPostProcessors and
> >BeanFactoryPostProcessors are automatically detected and applied if
defined
> >as beans in an application context.
> >
> >Thanks for the thorough code review, BTW :-)
> >
> >Juergen
> >
> >
> >________________________________
> >
> >Von: spr...@li... im Auftrag von
> >roger holbrook
> >Gesendet: So 02.11.2003 18:46
> >An: spr...@li...
> >Betreff: [[W3-SPAM]] - [[W3-SPAM]] - [[W3-SPAM]] - [[W3-SPAM]] -
> >[[W3-SPAM]] - [Springframework-developer] Re: Plug'nPlay for
> >AbstractApplicationContext & ListableBeanFactory - Email found in
subject -
> >Email found in subject - Email found in subject - Email found in
subject -
> >Email found in subject
> >
> >
> >
> >
> >Hi Juergen
> >
> >Many thanks for the explanation about
> >AbstractApplicationContext.getBeanFactory.
> >
> >Just to check I've got it straight - would the following be an accurate
> >summary:
> >- ListableBeanFactory & ApplicationContext are client facing interfaces
> >designed to hide all things related to implementation.
> >- ListableBeanFactoryImpl & AbstractApplicationContext provide consistent
> >out-of-the-box BeanFactory implementations that are considered of
essential
> >importance.
> >- Currently the linkage between these 2 default implementations happens
to
> >be that one acts as a delegate class for the other, ie. the return type
in
> >question.
> >
> >The reworking of JdbcBeanFactory as a subclass of
ListableBeanFactoryImpl,
> >obviously solves the wiring problem in this particular case - but it does
> >nothing for the general case of Plug'nPlay.  With the current
arrangement,
> >the one thing I cannot do is achieve effective easy reuse of all that
highly
> >crafted functionality that is so intricately wired up in
AbstractBeanFactory
> >and ListableBeanFactoryImpl - I cannot wrap and delegate !
> >
> >Aside from the implied name conflict, could you not preserve the original
> >intention of making the linkage between the two an internal interface:
> >
> >interface ListableBeanFactoryImp extends ListableBeanFactory {
> >
> >    public void ignoreDependencyType(Class type)
> >
> >    public void addBeanPostProcessor(BeanPostProcessor beanPostProcessor)
> >
> >    public final void destroySingletons()
> >
> >}
> >
> >The example that is actually motivating my thinking, is related to the
AOP
> >stuff.  If I want try to add functionality to a BeanFactory so that it
can
> >be aware of ProxyFactoryBean's for example, then the most simple approach
> >would be to use an XmlBeanFactory to read the bean definitions, but then
to
> >wrap and delegate to this, from within an AOP aware BeanFactory.  The
latter
> >could initialise itself via a BeanFactoryPostProcessor, and then provide
> >useful implementation support within the AOP module, ie it would again be
> >extending a ListableBeanFactoryImp interface, rather than anything client
> >facing.
> >
> >As you say, all this can obviously be achieved by building BeanFactory's
&
> >ApplicationContext's from scratch, but it seems a great shame not to be
able
> >to reuse the ListableBeanFactoryImpl class - it has so much to offer ;)
> >
> >Anyway, I am sure the you get the sense of what I am on about - I just
hope
> >I am not missing something fundamental to the whole issue ;)
> >
> >Roger
> >
> >
> >"jürgen höller [werk3AT]" <jue...@we...> wrote in message
> >news:420...@ma......
> >
> >
> >>First of all, thanks for your kind words, Roger -- I appreciate them!
:-)
> >>
> >>Regarding AbstractApplicationContext.getBeanFactory: I've indeed changed
> >>
> >>
> >its return value from ListableBeanFactory to ListableBeanFactoryImpl a
while
> >ago, reason being that AbstractApplicationContext needs some
configuration
> >stuff that AbstractBeanFactory and ListableBeanFactoryImpl offer. The
> >BeanFactory and ListableBeanFactory interfaces are intended for client
> >applications that access beans, they do not and should not include any
> >factory configuration or lifecycle methods.
> >
> >
> >>In detail, AbstractApplicationContext needs to invoke the following bean
> >>
> >>
> >factory implementation methods:
> >
> >
> >>- ignoreDependencyType: to register ApplicationContext as dependency
type
> >>
> >>
> >to ignore on autowiring (as it is set by the ApplicationContextAware
> >interface, not by a property value).
> >
> >
> >>- addBeanPostProcessor: to register BeanPostProcessors, both
> >>
> >>
> >ApplicationContextAwareProcessor and custom ones, before creating
> >application beans from the bean definitions.
> >
> >
> >>- destroySingletons: to destroy singleton instances on application
context
> >>
> >>
> >shutdown; particularly important for resource holders like a
BasicDataSource
> >or a LocalSessionFactoryBean.
> >
> >
> >>- Furthermore, the postProcessBeanFactory method in the
> >>
> >>
> >BeanFactoryPostProcessor interface declares a ListableBeanFactoryImpl
> >parameter to allow for access to all these bean factory configuration
> >methods. A ListableBeanFactory interface would be meaningless for this,
as
> >you can't do any post-processing of bean definitions without access to
them
> >and means to manipulate them.
> >
> >
> >>Let's not forget that is always possible to write an own
> >>
> >>
> >ApplicationContext implementation with any kind of bean factory
underneath,
> >or a direct implementation of bean factory functionality instead of a
> >delegate, by not deriving from AbstractApplicationContext. The latter is
> >specifically intended for ListableBeanFactoryImpl delegates, providing
rich
> >configuration functionality on top of them.
> >
> >
> >>Regarding JdbcBeanFactory: This one used a delegate
> >>
> >>
> >ListableBeanFactoryImpl underneath to be able to perform on-demand
> >refreshing. This is somewhat inconsistent with XmlBeanFactory's
> >implementation style: The latter derives from ListableBeanFactoryImpl and
> >adds various XML-related registerBeanDefinitions methods, leaving refresh
> >functionality to application contexts. IMO, that's a clear separation of
> >responsibilities: A BeanFactory is a low-level implementation; an
> >ApplicationContext builds higher-level functionality on top of it.
> >
> >
> >>Thus, I've changed JdbcBeanFactory to extend ListableBeanFactoryImpl and
> >>
> >>
> >provide a registerBeanDefinitions(sql) method. Of course, it still has
the
> >former (dataSource,sql) constructor as a convenience. I don't think that
> >anyone used JdbcBeanFactory's on-demand refresh anyway (or even loading
> >beans from a database in the first place), so that change shouldn't hurt.
So
> >you can use JdbcBeanFactory with AbstractApplicationContext too, as it is
a
> >ListableBeanFactoryImpl now :-)
> >
> >
> >>Rod, do you agree with the rationale? I believe it's straightforward and
> >>
> >>
> >consistent, particularly now that JdbcBeanFactory has adopted
> >XmlBeanFactory's implementation style. I hope you don't object to
> >JdbcBeanFactory being a ListableBeanFactoryImpl; as I've said, I believe
it
> >is important to provide consistent out-of-the-box BeanFactory
> >implementations (i.e. no refresh in bean factories but just in
application
> >contexts).
> >
> >
> >>Juergen
> >>
> >>
> >>-----Ursprüngliche Nachricht-----
> >>Von: Rod Johnson [mailto:rod...@in...]
> >>Gesendet: Sa 01.11.2003 17:32
> >>An: spr...@li...
> >>Cc:
> >>Betreff: Re: [Springframework-developer] Plug'nPlay for
> >>
> >>
> >AbstractApplicationContext & ListableBeanFactory
> >
> >
> >>
> >>Roger,
> >>
> >>
> >>
> >>>I've been lurking about for a fair while, being thoroughly impressed by
> >>>Springframework - the conception, the code, this excellent list, Rod's
> >>>
> >>>
> >>book,
> >>
> >>
> >>>in short the whole shebang - it seems quite a while since I encountered
> >>>
> >>>
> >a
> >
> >
> >>>project that more than anything, just seems to make me smile ;)  Many
> >>>thanks.
> >>>
> >>>
> >>Thanks. Made me smile :-)
> >>
> >>
> >>
> >>>First up is the subject line & the method
> >>>AbstractApplicationContext.getBeanFactory()
> >>>I am wondering if the signature for this method might have been changed
> >>>inadvertently ?  Prior to the introduction of support for
> >>>BeanFactoryPostProcessor's, the method was returning the
> >>>
> >>>
> >>ListableBeanFactory
> >>
> >>
> >>>interface, but thereafter it has been ListableBeanFactoryImpl.  As the
> >>>latter comes with a final modifier on each of the methods implementing
> >>>
> >>>
> >>that
> >>
> >>
> >>>interface, the opportunity for Plug'nPlay appears to have gone
> >>>
> >>>
> >missing...
> >
> >
> >>&
> >>
> >>
> >>>if I'm not mistaken, a first casualty would be the loss of a
> >>>
> >>>
> >>JdbcBeanFactory
> >>
> >>
> >>>within an AbstractApplicationContext.  Can someone shed some
> >>>light - am I just missing something ?
> >>>
> >>>
> >>I'll leave this one to Juergen, but I did notice it in passing and
> >>wondered...
> >>
> >>
> >>
> >>>By the way, on my wanderings I noticed the following typo in
> >>>AbstractBeanDefinition.equals()
> >>>
> >>>
> >>Thanks, fixed it. Ah, the beauty of open source. That code isn't
currently
> >>used btw, it was intended to allow for dynamic reconfiguration
eventually.
> >>There would have been an argument for zapping it for now, actually.
> >>
> >>Regards,
> >>Rod
> >>
> >>
> >>
> >>
> >>-------------------------------------------------------
> >>This SF.net email is sponsored by: SF.net Giveback Program.
> >>Does SourceForge.net help you be more productive?  Does it
> >>help you create better code?   SHARE THE LOVE, and help us help
> >>YOU!  Click Here: http://sourceforge.net/donate/
> >>_______________________________________________
> >>Springframework-developer mailing list
> >>Spr...@li...
> >>https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >>
> >>
> >>NHY??X'u?w+m?$>  xZ+? *.m?k +?^? j?z^?y! DD??i ^P)brA?m?q ?z
v
> >>
> >>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?   SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/





-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?   SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?   SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/

[Springframework-developer] Reworked transaction managers and Hibernate/JDO support

[<jue...@we...>]

I've committed a significant refactoring of our transaction manager =
implementations: AbstractPlatformTransactionManager has a =
"cleanupAfterCompletion" template method now, which has formerly been =
handled by subclasses. It also cares about exception handling on commit =
failure now, offering a "rollbackOnCommitFailure" property with the =
default being "false". The latter is intended for misbehaving JDBC =
drivers or JDO implementations; normally, there shouldn't be a need to =
set it to true.
=20
HibernateTemplate and HibernateTransactionManager have a =
"jdbcExceptionTranslator" property now, supporting a =
SQLExceptionTranslator that kicks in when callback code throws an =
SQLException or HibernateJDBCException. Default is =
SQLStateSQLExceptionTranslator because of the ease of setup. The main =
rationale is to throw proper DataIntegrityViolationExceptions on =
corresponding Hibernate-rethrown SQLExceptions - Steve from the =
Hibernate team made be aware of the issue.
=20
JdoTemplate and JdoInterceptor have a common base class JdoAccessor now, =
similar to HibernateAccessor, and support for a JdoDialect. The latter =
represents a strategy for retrieving the underlying JDBC connection and =
for eagerly flushing a PersistenceManager, to be implemented for =
specific JDO products. It also provides a hook for specific translation =
of JDOExceptions to Spring's DataAccessException hierarchy. This allows =
for richer support of JDO in Spring, like exporting transactions to JDBC =
access code and eager flushing to make the latter aware of changes.
=20
Juergen

Re: [Springframework-developer] Singelton FactoryBeans are asked for an object before beanFactor.getBean(name) is called by application

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

>Good point: I've just added a check to ListableBeanFactoryImpl's
preInstantiateSingletons method to ignore FactoryBeans that return
isSingleton=false. I'm also inclined to agree that adding some "lazy-init"
argument to the "bean" tag would make sense.

Yes, a lazy option would be good. However, I think eager instantiation is
the appropriate default.

Regards,
Rod

Re: [Springframework-developer] Singelton FactoryBeans are asked for an object before beanFactor.getBean(name) is called by application

[<jue...@we...>]

Cameron,
=20
Good point: I've just added a check to ListableBeanFactoryImpl's =
preInstantiateSingletons method to ignore FactoryBeans that return =
isSingleton=3Dfalse. I'm also inclined to agree that adding some =
"lazy-init" argument to the "bean" tag would make sense.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Cameron Braid
Gesendet: Mi 05.11.2003 05:26
An: spr...@li...
Betreff: [[W3-SPAM]] - Re: [Springframework-developer] Singelton =
FactoryBeans are asked for an object before beanFactor.getBean(name) is =
called by application - Email found in subject



Colin Sampaleanu wrote:

> This is happening because AbstractApplicationContext foreces
> singletons (which includes your FactoryBean) to be pre-instantiated.
> This essentially calls getBean() on the bean, which ends up calling
> getObject().
>
> Coincidentally, just a few days ago I asked here why singletons were
> always preinstantiated, with no ability to turn off this behaviour,
> but nobody commented... It probably makes sense to be able to turn
> this off for specific beans.
>
I agree.

Wouldn't it make sense to not preinstantiate FactoryBeans that aren't
singeltons (FactoryBean.isSingelton()=3Dfalse) since this initial =
instance
will be disposed of anyway.

Thanks,

Cameron.

> Regards,
> Colin
>
> Cameron Braid wrote:
>
>> I have a FactoryBean that is a singleton.  It is a prototype factory
>> (is that correct terminoligy?)
>>
>> When the application context initialized, the FactoryBean.getObject()
>> is being called before I call getBean() from my application.
>>
>> The problem is that the contract for BeanFactory.getObject() states
>> that it shoud never be null.
>>
>>     /**
>>      * Return an instance (possibly shared or independent) of the =
object
>>      * managed by this factory. As with a BeanFactory, this allows
>>      * support for both the Singleton and Prototype design pattern.
>>      * @return an instance of the bean *(should never be null)*
>>      * @throws Exception in case of creation errors
>>      */
>>     Object getObject() throws Exception;
>>
>> Though in my application, I can't gaurantee this.  I am relying on
>> source of information that doesn't exist until a servlet call is =
made.
>>
>> How come this happens, and is it necessary to create an instance that
>> gets thrown away ?
>>
>> Cheers
>>
>> Cameron
>
>
>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?   SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>


--
Any damn fool can write code that a computer can understand...
The trick is to write code that humans can understand.
[Martin Fowler =
http://www.martinfowler.com/distributedComputing/refactoring.pdf]





-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?   SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Singelton FactoryBeans are asked for an object before beanFactor.getBean(name) is called by application

[Cameron B. <ca...@da...>]

Colin Sampaleanu wrote:

> This is happening because AbstractApplicationContext foreces 
> singletons (which includes your FactoryBean) to be pre-instantiated. 
> This essentially calls getBean() on the bean, which ends up calling 
> getObject().
>
> Coincidentally, just a few days ago I asked here why singletons were 
> always preinstantiated, with no ability to turn off this behaviour, 
> but nobody commented... It probably makes sense to be able to turn 
> this off for specific beans.
>
I agree.

Wouldn't it make sense to not preinstantiate FactoryBeans that aren't 
singeltons (FactoryBean.isSingelton()=false) since this initial instance 
will be disposed of anyway.

Thanks,

Cameron.

> Regards,
> Colin
>
> Cameron Braid wrote:
>
>> I have a FactoryBean that is a singleton.  It is a prototype factory 
>> (is that correct terminoligy?)
>>
>> When the application context initialized, the FactoryBean.getObject() 
>> is being called before I call getBean() from my application.
>>
>> The problem is that the contract for BeanFactory.getObject() states 
>> that it shoud never be null.
>>
>>     /**
>>      * Return an instance (possibly shared or independent) of the object
>>      * managed by this factory. As with a BeanFactory, this allows
>>      * support for both the Singleton and Prototype design pattern.
>>      * @return an instance of the bean *(should never be null)*
>>      * @throws Exception in case of creation errors
>>      */
>>     Object getObject() throws Exception;
>>
>> Though in my application, I can't gaurantee this.  I am relying on 
>> source of information that doesn't exist until a servlet call is made.
>>
>> How come this happens, and is it necessary to create an instance that 
>> gets thrown away ?
>>
>> Cheers
>>
>> Cameron
>
>
>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?   SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>


-- 
Any damn fool can write code that a computer can understand...
The trick is to write code that humans can understand.
[Martin Fowler http://www.martinfowler.com/distributedComputing/refactoring.pdf]

Re: [Springframework-developer] Singelton FactoryBeans are asked for an object before beanFactor.getBean(name) is called by application

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

This is happening because AbstractApplicationContext foreces singletons 
(which includes your FactoryBean) to be pre-instantiated. This 
essentially calls getBean() on the bean, which ends up calling getObject().

Coincidentally, just a few days ago I asked here why singletons were 
always preinstantiated, with no ability to turn off this behaviour, but 
nobody commented... It probably makes sense to be able to turn this off 
for specific beans.

Regards,
Colin

Cameron Braid wrote:

> I have a FactoryBean that is a singleton.  It is a prototype factory 
> (is that correct terminoligy?)
>
> When the application context initialized, the FactoryBean.getObject() 
> is being called before I call getBean() from my application.
>
> The problem is that the contract for BeanFactory.getObject() states 
> that it shoud never be null.
>
>     /**
>      * Return an instance (possibly shared or independent) of the object
>      * managed by this factory. As with a BeanFactory, this allows
>      * support for both the Singleton and Prototype design pattern.
>      * @return an instance of the bean *(should never be null)*
>      * @throws Exception in case of creation errors
>      */
>     Object getObject() throws Exception;
>
> Though in my application, I can't gaurantee this.  I am relying on 
> source of information that doesn't exist until a servlet call is made.
>
> How come this happens, and is it necessary to create an instance that 
> gets thrown away ?
>
> Cheers
>
> Cameron

[Springframework-developer] Singelton FactoryBeans are asked for an object before beanFactor.getBean(name) is called by application

[Cameron B. <ca...@da...>]

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
I have a FactoryBean that is a singleton.&nbsp; It is a prototype factory
(is that correct terminoligy?)<br>
<br>
When the application context initialized, the FactoryBean.getObject()
is being called before I call getBean() from my application.<br>
<br>
The problem is that the contract for BeanFactory.getObject() states
that it shoud never be null.<br>
<br>
&nbsp;&nbsp;&nbsp; /**<br>
&nbsp;&nbsp;&nbsp; &nbsp;* Return an instance (possibly shared or independent) of the object<br>
&nbsp;&nbsp;&nbsp; &nbsp;* managed by this factory. As with a BeanFactory, this allows<br>
&nbsp;&nbsp;&nbsp; &nbsp;* support for both the Singleton and Prototype design pattern.<br>
&nbsp;&nbsp;&nbsp; &nbsp;* @return an instance of the bean <b>(should never be null)</b><br>
&nbsp;&nbsp;&nbsp; &nbsp;* @throws Exception in case of creation errors<br>
&nbsp;&nbsp;&nbsp; &nbsp;*/<br>
&nbsp;&nbsp;&nbsp; Object getObject() throws Exception;<br>
<br>
Though in my application, I can't gaurantee this.&nbsp; I am relying on
source of information that doesn't exist until a servlet call is made.<br>
<br>
How come this happens, and is it necessary to create an instance that
gets thrown away ?<br>
<br>
Cheers<br>
<br>
Cameron<br>
<br>
<br>
<pre cols="72" class="moz-signature">-- 
Any damn fool can write code that a computer can understand...
The trick is to write code that humans can understand.
[Martin Fowler <a class="moz-txt-link-freetext" href="http://www.martinfowler.com/distributedComputing/refactoring.pdf">http://www.martinfowler.com/distributedComputing/refactoring.pdf</a>]</pre>
</body>
</html>

[Springframework-developer] Is there a case for adding arbitrary bean metadata?

[Colin S. <co...@br...>]

A friend has sent me some code for adding JMX instrumentation to beans 
in a Spring container, via BeanPostProcessor. Please see the email below 
for more details. Something like this, or extended from this, could make 
its way into Spring itself.

Now what I am thinking is that when BeanPostProcessor comes into play 
(and not just for JMX), there is sometimes a usecase for being able to 
add arbitrary metadata to a bean definition inside the context. This JMX 
implementation is relatively simplistic; it instruments and exposes 
every singleton bean in the container, and exposes only the declared 
properties, but it needs to be told in a better fashion what to expose.

Now one mechanism to handle JMX instrumenting in a more specific fashion 
is to modify the DTD to add elements specifically related to JMX, and 
BeanDefinition would just be modified in a simple fashion. I don't like 
this as it's too JMX specific.

Another mechanism would be, as the deployer, for each bean that you want 
to expose, to add into the container a partner metadata bean which holds 
information on how to expose the target bean, and the JMX preprocessor 
would in fact work off these.

However, it's arguably cleaner to just add the ability to add arbitrary 
metadata to bean definitions in the container. This metadata could be 
used in any fashion by any BeanPostProcessor implementations. This 
metadata could be parallel to the existing 'property' element,, e.g.
  <bean id="x" class="x.y.z">
    <property name="y"><value>zzzzz</value></property>
    <meta-property name="a.b.c"><value>zzzzz</value></meta-property>
  </bean>
or maybe inline with existing properties, in which case Spring would 
form a parallel metadata tree to the defined properties. ie below, there 
is metadata being defined for the property 'y':
  <bean id="x" class="x.y.z">
    <property name="y">
      <value>zzzzz</value>
      <meta-property name="a.b.c"><value>zzzzz</value></meta-property>
    </property>
  </bean>

The fourth way to get info to a JMX implementation of course is source 
level javadoc style tags, as currently being used for transactions and 
other metadata.

What does everybody think of this approach to handling JMX in the first 
place, and the various mechanisms to get metadata to the JMX instrumenter?

Regards,
Colin


Michael Zielenski wrote:

>Here's the JMX code for Spring.
> 
>What's included is a BeanPostProcessor that instruments and registers beans in a given Spring context with an MBeanServer (factory wrapper bean is also provided).  I've also included a wrapper around Sun's HTTP/HTML adaptor from the RI.  Here's one way to write everything together:
> 
><beans>
> 
> <bean id="mbeanServerFactory"
>       class="com.whatever.common.spring.jmx.MBeanServerFactoryBean"
>       singleton="true"
>       init-method="initialize"
>       destroy-method="destroy"/>
> 
> <bean id="jmxHttpAdaptor"
>       class="com.whatever.common.spring.jmx.HttpAdaptorWrapper"
>       singleton="true"
>       init-method="initialize"
>       destroy-method="destroy"
>       dependency-check="object">
>     <property name="mbeanServer"><ref bean="mbeanServerFactory"/></property>
>     <property name="port"><value>9090</value></property>
>     <property name="login"><value>admin</value></property>
>     <property name="password"><value>admin</value></property>
> </bean>
> 
> <bean id="mbeanPostProcessor"
>       class="com.whatever.common.spring.jmx.MBeanPostProcessor"
>       singleton="true"
>       dependency-check="object">
>     <property name="server"><ref bean="mbeanServerFactory"/></property>
> </bean>
> 
>  ...
> 
></beans>
>
>
>That's it.  I've been compiling against Sun's RI (1.2.1), and haven't tried anything else yet.  Let me know how you make out.  Note that right now all beans declared in the config are instrumented and registered; this is obviously not ideal, so the next step would be to figure out how to convey what to instrument to the postprocessor (i.e., extend the DTD and make this part of RootBeanDefinition?  provide in the postprocessors config? etc).
>
>-----Original Message-----
>From: Colin Sampaleanu 
>Sent: Monday, November 03, 2003 4:50 PM
>To: Michael Zielenski
>Subject: RE: Spring questions
>
>
>That's pretty cool.   From what I know, now that sun has become a bit less restrictive about bundling sun JMX classes, and have actually finished the spec for the transport (it was never specified before), some people are going back to the RI.
> 
>In any case, I wouldn't mind looking at your stuff maybe. Perhaps it can go into Spring itself.
> 
>
>-----Original Message-----
>From: Michael Zielenski 
>Sent: November 3, 2003 4:46 PM
>To: Colin Sampaleanu
>Subject: RE: Spring questions
>
>
>BTW, I added some basic JMX management to Spring, essentially a BeanPostProcessor that instruments each bean in the context, exposing its properties/attributes on the fly (no need to extend any JMX interfaces).  I used the JMX RI (1.2.1), but quickly found that trying to deploy to something like Resin was thorny since it already ships with a lame-ass JMX impl itself.  I had a look at what else is out there (MX4J, XMOJO, etc), and it seems they all bundle the javax.management classes *in their jars*...ick!
>
>-----Original Message-----
>From: Colin Sampaleanu 
>Sent: Friday, October 31, 2003 11:00 AM
>To: Michael Zielenski
>Subject: RE: Spring questions
>
>
>there's been talk of JMX support for the 1.1 timeframe
>
>-----Original Message-----
>From: Michael Zielenski 
>Sent: October 31, 2003 10:57 AM
>To: Colin Sampaleanu
>Subject: RE: Spring questions
>
>
>What about management?
>
>-----Original Message-----
>From: Colin Sampaleanu 
>Sent: Friday, October 31, 2003 10:35 AM
>To: Michael Zielenski
>Subject: RE: Spring questions
>
>
>Reconfigure is actually very hard to do due to the various lifecycles that have to be managed, postprocessing, etc. Even outright reload gets complicated, if you want to reload the same instance and have anybody holding on to it just get the new values...
> 
>
>-----Original Message-----
>From: Michael Zielenski 
>Sent: October 31, 2003 10:33 AM
>To: Colin Sampaleanu
>Subject: Spring questions
>
>
>I've seen some reload methods here and there in Spring.  How does this stuff actually work?  Is there a facility a la the log4j file watchdog that will reload the context if the underlying config changes?  That would be sweet (even sweeter if it could reconfigure existing bean instances, as opposed to recreating the context from scratch).
> 
>Also, is there any talk of adding management/instrumentation?  I guess it would be easy enough to do with the AOP stuff...
> 
>
>  
>

Re: [Springframework-developer] Documentation based on DocBook: call for decision :)

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

On Tuesday 04 November 2003 12:55, Alef Arendsen (JTeam) wrote:

> Yup, there's some extra targets included in my local build.xml (docpdf,
> dochtml, dochtml-single), basically I ripped them from Hibernate. Works
> quite well... About the images and code-listings, I hjaven't had a look
> at that yet, will see if that works!

the example pdf in the docs folder shows the code in the velocity chapter 
overlapping the shaded region.  I like the docBook idea though - one 
source, many end-formats.


-- 

Darren Davison
Public Key: http://www.davison.uk.net/key.jsp

Re: [Springframework-developer] Plug'nPlay for AbstractApplicationContext & ListableBeanFactory

[<jue...@we...>]

Roger, everybody,
=20
I've just committed all the stuff that I've been working on, including =
the bean factory SPI interfaces, the reworked post-processors, and the =
BeanNameAware interface. In the course of this, I've refined quite some =
API signatures and even package locations - there is a new =
beans.factory.config package now, with the post-processor interfaces =
moved there. Most applications shouldn't be affected, but for example =
custom post-processor implementations will be. For details, see the =
changelog and the new CVS contents...
=20
BTW, I've also adopted your suggestion regarding getBeansOfType and =
added "includePrototypes" and "includeFactoryBeans" flags, indicating =
whether one wants to perform those more expensive operations too.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von roger holbrook
Gesendet: Di 04.11.2003 18:04
An: spr...@li...
Betreff: [[W3-SPAM]] - [Springframework-developer] Re: Re: Re: =
Plug'nPlay for AbstractApplicationContext & ListableBeanFactory - Email =
found in subject



Thanks Colin

when Juergen actually commits the code, I'll give a try ;)



"Colin Sampaleanu" <col...@ex...> wrote in message
news:3FA...@ex......
> Roger,
>
> Try hitting the 'alternate' CVS server at sf.net described here:
>
>
http://sourceforge.net/docman/display_doc.php?docid=3D14033&group_id=3D1#=
firewal
l
>
> It does allow anon access, and last time I verified this (about a =
month
> ago), it was completely up to date, as opposed to 24 hours behind like
> the main anon server.
>
>
>
> roger holbrook wrote:
>
> >Hi Juergen
> >
> >The changes you describe sound great - & as soon as anonymous CVS =
catches
> >up, I'll check them out.  Unfortunately, all I can see so far is an =
empty
> >beans.factory.config directory :(
> >
> >Many thanks
> >
> >Roger
> >
> >
> >"j=FCrgen h=F6ller [werk3AT]" <jue...@we...> wrote in =
message
> >news:170...@co......
> >Roger,
> >
> >I've adopted your idea of an SPI interface for bean factories: I've =
just
> >introduced ConfigurableBeanFactory and =
ConfigurableListableBeanFactory
> >interfaces in a new beans.factory.config package; I've also moved
> >BeanFactoryProcessor and BeanFactoryPostProcessor there. The latter's
> >postProcessBeanFactory method uses ConfigurableListableBeanFactory =
now,
as
> >does AbstractApplicationContext's getBeanFactory template method.
> >
> >I'm still not entirely sure why you would want to use a different =
bean
> >factory with AbstractApplicationContext to leverage AOP =
functionality.
All
> >of Spring's AOP support should work without making the bean factory
> >implementation explicitly aware of it. BeanPostProcessors and
> >BeanFactoryPostProcessors are automatically detected and applied if
defined
> >as beans in an application context.
> >
> >Thanks for the thorough code review, BTW :-)
> >
> >Juergen
> >
> >
> >________________________________
> >
> >Von: spr...@li... im Auftrag =
von
> >roger holbrook
> >Gesendet: So 02.11.2003 18:46
> >An: spr...@li...
> >Betreff: [[W3-SPAM]] - [[W3-SPAM]] - [[W3-SPAM]] - [[W3-SPAM]] -
> >[[W3-SPAM]] - [Springframework-developer] Re: Plug'nPlay for
> >AbstractApplicationContext & ListableBeanFactory - Email found in
subject -
> >Email found in subject - Email found in subject - Email found in
subject -
> >Email found in subject
> >
> >
> >
> >
> >Hi Juergen
> >
> >Many thanks for the explanation about
> >AbstractApplicationContext.getBeanFactory.
> >
> >Just to check I've got it straight - would the following be an =
accurate
> >summary:
> >- ListableBeanFactory & ApplicationContext are client facing =
interfaces
> >designed to hide all things related to implementation.
> >- ListableBeanFactoryImpl & AbstractApplicationContext provide =
consistent
> >out-of-the-box BeanFactory implementations that are considered of
essential
> >importance.
> >- Currently the linkage between these 2 default implementations =
happens
to
> >be that one acts as a delegate class for the other, ie. the return =
type
in
> >question.
> >
> >The reworking of JdbcBeanFactory as a subclass of
ListableBeanFactoryImpl,
> >obviously solves the wiring problem in this particular case - but it =
does
> >nothing for the general case of Plug'nPlay.  With the current
arrangement,
> >the one thing I cannot do is achieve effective easy reuse of all that
highly
> >crafted functionality that is so intricately wired up in
AbstractBeanFactory
> >and ListableBeanFactoryImpl - I cannot wrap and delegate !
> >
> >Aside from the implied name conflict, could you not preserve the =
original
> >intention of making the linkage between the two an internal =
interface:
> >
> >interface ListableBeanFactoryImp extends ListableBeanFactory {
> >
> >    public void ignoreDependencyType(Class type)
> >
> >    public void addBeanPostProcessor(BeanPostProcessor =
beanPostProcessor)
> >
> >    public final void destroySingletons()
> >
> >}
> >
> >The example that is actually motivating my thinking, is related to =
the
AOP
> >stuff.  If I want try to add functionality to a BeanFactory so that =
it
can
> >be aware of ProxyFactoryBean's for example, then the most simple =
approach
> >would be to use an XmlBeanFactory to read the bean definitions, but =
then
to
> >wrap and delegate to this, from within an AOP aware BeanFactory.  The
latter
> >could initialise itself via a BeanFactoryPostProcessor, and then =
provide
> >useful implementation support within the AOP module, ie it would =
again be
> >extending a ListableBeanFactoryImp interface, rather than anything =
client
> >facing.
> >
> >As you say, all this can obviously be achieved by building =
BeanFactory's
&
> >ApplicationContext's from scratch, but it seems a great shame not to =
be
able
> >to reuse the ListableBeanFactoryImpl class - it has so much to offer =
;)
> >
> >Anyway, I am sure the you get the sense of what I am on about - I =
just
hope
> >I am not missing something fundamental to the whole issue ;)
> >
> >Roger
> >
> >
> >"j=FCrgen h=F6ller [werk3AT]" <jue...@we...> wrote in =
message
> >news:420...@ma......
> >
> >
> >>First of all, thanks for your kind words, Roger -- I appreciate =
them!
:-)
> >>
> >>Regarding AbstractApplicationContext.getBeanFactory: I've indeed =
changed
> >>
> >>
> >its return value from ListableBeanFactory to ListableBeanFactoryImpl =
a
while
> >ago, reason being that AbstractApplicationContext needs some
configuration
> >stuff that AbstractBeanFactory and ListableBeanFactoryImpl offer. The
> >BeanFactory and ListableBeanFactory interfaces are intended for =
client
> >applications that access beans, they do not and should not include =
any
> >factory configuration or lifecycle methods.
> >
> >
> >>In detail, AbstractApplicationContext needs to invoke the following =
bean
> >>
> >>
> >factory implementation methods:
> >
> >
> >>- ignoreDependencyType: to register ApplicationContext as dependency
type
> >>
> >>
> >to ignore on autowiring (as it is set by the ApplicationContextAware
> >interface, not by a property value).
> >
> >
> >>- addBeanPostProcessor: to register BeanPostProcessors, both
> >>
> >>
> >ApplicationContextAwareProcessor and custom ones, before creating
> >application beans from the bean definitions.
> >
> >
> >>- destroySingletons: to destroy singleton instances on application
context
> >>
> >>
> >shutdown; particularly important for resource holders like a
BasicDataSource
> >or a LocalSessionFactoryBean.
> >
> >
> >>- Furthermore, the postProcessBeanFactory method in the
> >>
> >>
> >BeanFactoryPostProcessor interface declares a ListableBeanFactoryImpl
> >parameter to allow for access to all these bean factory configuration
> >methods. A ListableBeanFactory interface would be meaningless for =
this,
as
> >you can't do any post-processing of bean definitions without access =
to
them
> >and means to manipulate them.
> >
> >
> >>Let's not forget that is always possible to write an own
> >>
> >>
> >ApplicationContext implementation with any kind of bean factory
underneath,
> >or a direct implementation of bean factory functionality instead of a
> >delegate, by not deriving from AbstractApplicationContext. The latter =
is
> >specifically intended for ListableBeanFactoryImpl delegates, =
providing
rich
> >configuration functionality on top of them.
> >
> >
> >>Regarding JdbcBeanFactory: This one used a delegate
> >>
> >>
> >ListableBeanFactoryImpl underneath to be able to perform on-demand
> >refreshing. This is somewhat inconsistent with XmlBeanFactory's
> >implementation style: The latter derives from ListableBeanFactoryImpl =
and
> >adds various XML-related registerBeanDefinitions methods, leaving =
refresh
> >functionality to application contexts. IMO, that's a clear separation =
of
> >responsibilities: A BeanFactory is a low-level implementation; an
> >ApplicationContext builds higher-level functionality on top of it.
> >
> >
> >>Thus, I've changed JdbcBeanFactory to extend ListableBeanFactoryImpl =
and
> >>
> >>
> >provide a registerBeanDefinitions(sql) method. Of course, it still =
has
the
> >former (dataSource,sql) constructor as a convenience. I don't think =
that
> >anyone used JdbcBeanFactory's on-demand refresh anyway (or even =
loading
> >beans from a database in the first place), so that change shouldn't =
hurt.
So
> >you can use JdbcBeanFactory with AbstractApplicationContext too, as =
it is
a
> >ListableBeanFactoryImpl now :-)
> >
> >
> >>Rod, do you agree with the rationale? I believe it's straightforward =
and
> >>
> >>
> >consistent, particularly now that JdbcBeanFactory has adopted
> >XmlBeanFactory's implementation style. I hope you don't object to
> >JdbcBeanFactory being a ListableBeanFactoryImpl; as I've said, I =
believe
it
> >is important to provide consistent out-of-the-box BeanFactory
> >implementations (i.e. no refresh in bean factories but just in
application
> >contexts).
> >
> >
> >>Juergen
> >>
> >>
> >>-----Urspr=FCngliche Nachricht-----
> >>Von: Rod Johnson [mailto:rod...@in...]
> >>Gesendet: Sa 01.11.2003 17:32
> >>An: spr...@li...
> >>Cc:
> >>Betreff: Re: [Springframework-developer] Plug'nPlay for
> >>
> >>
> >AbstractApplicationContext & ListableBeanFactory
> >
> >
> >>
> >>Roger,
> >>
> >>
> >>
> >>>I've been lurking about for a fair while, being thoroughly =
impressed by
> >>>Springframework - the conception, the code, this excellent list, =
Rod's
> >>>
> >>>
> >>book,
> >>
> >>
> >>>in short the whole shebang - it seems quite a while since I =
encountered
> >>>
> >>>
> >a
> >
> >
> >>>project that more than anything, just seems to make me smile ;)  =
Many
> >>>thanks.
> >>>
> >>>
> >>Thanks. Made me smile :-)
> >>
> >>
> >>
> >>>First up is the subject line & the method
> >>>AbstractApplicationContext.getBeanFactory()
> >>>I am wondering if the signature for this method might have been =
changed
> >>>inadvertently ?  Prior to the introduction of support for
> >>>BeanFactoryPostProcessor's, the method was returning the
> >>>
> >>>
> >>ListableBeanFactory
> >>
> >>
> >>>interface, but thereafter it has been ListableBeanFactoryImpl.  As =
the
> >>>latter comes with a final modifier on each of the methods =
implementing
> >>>
> >>>
> >>that
> >>
> >>
> >>>interface, the opportunity for Plug'nPlay appears to have gone
> >>>
> >>>
> >missing...
> >
> >
> >>&
> >>
> >>
> >>>if I'm not mistaken, a first casualty would be the loss of a
> >>>
> >>>
> >>JdbcBeanFactory
> >>
> >>
> >>>within an AbstractApplicationContext.  Can someone shed some
> >>>light - am I just missing something ?
> >>>
> >>>
> >>I'll leave this one to Juergen, but I did notice it in passing and
> >>wondered...
> >>
> >>
> >>
> >>>By the way, on my wanderings I noticed the following typo in
> >>>AbstractBeanDefinition.equals()
> >>>
> >>>
> >>Thanks, fixed it. Ah, the beauty of open source. That code isn't
currently
> >>used btw, it was intended to allow for dynamic reconfiguration
eventually.
> >>There would have been an argument for zapping it for now, actually.
> >>
> >>Regards,
> >>Rod
> >>
> >>
> >>
> >>
> >>-------------------------------------------------------
> >>This SF.net email is sponsored by: SF.net Giveback Program.
> >>Does SourceForge.net help you be more productive?  Does it
> >>help you create better code?   SHARE THE LOVE, and help us help
> >>YOU!  Click Here: http://sourceforge.net/donate/
> >>_______________________________________________
> >>Springframework-developer mailing list
> >>Spr...@li...
> =
>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >>
> >>
> >>N=18HY??X'u?=16w=1A+m?$> =12 xZ+? =17*.m?k +=0E?^? j?z^?=1Dy! =
DD=10?=11?i ^=0EP)brA?m?q =07?z
v
> >>
> >>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?   SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/





-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?   SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] AbstractWizardFormController

[<jue...@we...>]

Trevor,
=20
Go ahead, that makes sense! I haven't been aware that the default =
mechanism wouldn't work with buttions.
=20
Juergen

________________________________

Von: spr...@li... im Auftrag =
von Trevor Cook
Gesendet: Di 04.11.2003 19:14
An: Spring Developers
Betreff: [[W3-SPAM]] - [Springframework-developer] =
AbstractWizardFormController - Email found in subject



The current wizard only works correctly with form submissions using:

<input type=3D"submit" ...>

For various reasons, we normally use buttons, as in:

<button type=3D"submit" ...>

The problem is that <input> only submits the 1 clicked button, <button>
submits all the buttons, so you need a different way to check which =
button
was clicked.  I have modified the class adding the following 2 methods:

        protected boolean isFinish(HttpServletRequest request)
        protected boolean isCancel(HttpServletRequest request)

which contain the current logic for determining the workflow.  However, =
they
can be overridden to allow customization beyond just the name of the
parameters (for special cases such as mine :) ).  This change does not
affect any existing "out-of-the-box" functionality.

If there are no objections, I will commit these changes tonight.

Trevor



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?   SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] AbstractWizardFormController

[Trevor C. <pr...@se...>]

The current wizard only works correctly with form submissions using:

<input type="submit" ...>

For various reasons, we normally use buttons, as in:

<button type="submit" ...>

The problem is that <input> only submits the 1 clicked button, <button>
submits all the buttons, so you need a different way to check which button
was clicked.  I have modified the class adding the following 2 methods:

	protected boolean isFinish(HttpServletRequest request)
	protected boolean isCancel(HttpServletRequest request)

which contain the current logic for determining the workflow.  However, they
can be overridden to allow customization beyond just the name of the
parameters (for special cases such as mine :) ).  This change does not
affect any existing "out-of-the-box" functionality.

If there are no objections, I will commit these changes tonight.

Trevor