springframework-developer — Spring Framework developers list

[Springframework-developer] Turning off autocommit in JBoss / Oracle datasource

[Levkovitch, L. <lle...@ac...>]

I think I've sent this to a wrong list before... Sorry!
=========================
Thanks to Rod and Colin for responses and advice, and big thanks to Dmitriy
for on-site debugging!

My problem was actually in my own code. Because I am using some special
features of Oracle 9 (namely, XMLType), I have to get a connection and
create my own prepared statements with it. I was getting this connection
from my DAO's datasource (getDs().getConnection()), instead of using
DataSourceUtils.getConnection(getDs()) as the documentation instructs. As
soon as I changed that, all my transactions started to work perfectly! 

Now I understand that I don't really have to change the autocommit property,
but in case someone is interested, here is what I found out (and it isn't
much!). According to JBoss forums, autocommit is SUPPOSED to be off with my
configuration (which is really just the default Oracle config file for
JBoss). 
Oracle's instructions for creating a datasource file do not discuss
autocommit at all, and it seems that there's no property in the datasource
configuration that controls it; one can only change it programmatically. 
I guess in my case it is off by default, but then something switches it on
as JBoss starts up with whatever services I have set up there. Not that it
bothers me now, since Spring takes care of everything.  

Once again - thanks, everyone!
Lidia

-----Original Message-----
Folks,

I am using a datasource to have my Spring DAOs connect to Oracle database.
Apparently, with my set up, autocommit is turned on, and this is not what I
need! I have actually put this line of code inside one of the DAOs'
afterPropertiesSet() method:
logger.debug("autocommit is " + getDs().getConnection().getAutoCommit());
and this prints "autocommit is true". 

Is there a way to configure my datasource so that autocommit is set to
false? I am using JBoss 3.2.1 with Oracle 9.2. In one of JBoss forums it
actually.

The datasource is defined in myapp-ds.xml file like this:
(this is based on the example that came with JBoss) <datasources>
  <local-tx-datasource>
    <jndi-name>myapp-ds</jndi-name>
 
	<connection-url>jdbc:oracle:thin:@[my database
name]</connection-url>
    <driver-class>oracle.jdbc.driver.OracleDriver</driver-class>
    <user-name>[my user name]</user-name>
    <password>[my password]</password>
    <min-pool-size>3</min-pool-size>
    <max-pool-size>30</max-pool-size>
    <blocking-timeout-millis>3000</blocking-timeout-millis>
    <idle-timeout-minutes>15</idle-timeout-minutes> 
	
<exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.OracleEx
ceptionSorter</exception-sorter-class-name>
  </local-tx-datasource>
</datasources>

All my DAO objects use the dataSource bean which is defined in my
application context as follows: <bean id="dataSource"
class="org.springframework.jndi.JndiObjectFactoryBean"
singleton="true" lazy-init="default" autowire="default"
dependency-check="default">
- <property name="jndiName">
  <value>myapp-ds</value> 
  </property>
- <property name="resourceRef">
  <value>true</value> 
  </property>
  </bean>

Thank you very much!
Lidia

Re: [Springframework-developer] Turning off autocommit in JBoss / Oracle datasource

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

Colin,

I'm working with Lidia on that one. I'm so curious what the hell is going on... The log actually says that the TxManager initiating rollback (when unchecked exception is 
thrown from the service method), but the actual data is committed... We'll let you know.

Regards,
Dmitriy.


Colin Sampaleanu wrote:

> Actually I think this is just bad usage/config of Spring.
> 
> A connection returned from a DataSource is normally set to 
> autocommit=true as per the Connection JavaDocs.
> 
> Now our TransactionManagers (like DataSourceTransactionManager) do set 
> autocommit to false when starting a transaction, and restore it back to 
> whatever it was afterwards.
> 
> My feeling Lidia is that you are not properly wrapping your DAO/Mapper 
> objects in either Spring declarative or programmatic transactions, so in 
> your test code you are not actually getting a connection while in a 
> transaciton. How to do transactional wrapping is described in a fair 
> amount of detail in the Spring manual. If you have any need for more 
> info after looking at that, or think that the problem is something else, 
> please post another message with more info.
> 
> Regards,
> Colin
> 
> Rod Johnson wrote:
> 
>> Lidia
>>
>> You're right. Autocommit is evil in non-trivial apps. However, this is
>> really a JBoss question. Have you checked their lists/forums/FAQs?
>>
>> Regards
>> Rod
>>
>> ----- Original Message -----
>> From: "Levkovitch, Lidia" <lle...@su...>
>> To: <spr...@li...>
>> Sent: Wednesday, May 12, 2004 7:02 PM
>> Subject: [Springframework-developer] Turning off autocommit in JBoss /
>> Oracle datasource
>>
>>
>>  
>>
>>> Folks,
>>>
>>> I am using a datasource to have my Spring DAOs connect to Oracle 
>>> database.
>>> Apparently, with my set up, autocommit is turned on, and this is not 
>>> what
>>>   
>>
>> I
>>  
>>
>>> need!
>>> I have actually put this line of code inside one of the DAOs'
>>> afterPropertiesSet() method:
>>> logger.debug("autocommit is " + 
>>> getDs().getConnection().getAutoCommit());
>>> and this prints "autocommit is true".
>>>
>>> Is there a way to configure my datasource so that autocommit is set to
>>> false? I am using JBoss 3.2.1 with Oracle 9.2. In one of JBoss forums it
>>> actually.
>>>
>>> The datasource is defined in myapp-ds.xml file like this:
>>> (this is based on the example that came with JBoss)
>>> <datasources>
>>>  <local-tx-datasource>
>>>    <jndi-name>myapp-ds</jndi-name>
>>>
>>> <connection-url>jdbc:oracle:thin:@[my database
>>> name]</connection-url>
>>>    <driver-class>oracle.jdbc.driver.OracleDriver</driver-class>
>>>    <user-name>[my user name]</user-name>
>>>    <password>[my password]</password>
>>>    <min-pool-size>3</min-pool-size>
>>>    <max-pool-size>30</max-pool-size>
>>>    <blocking-timeout-millis>3000</blocking-timeout-millis>
>>>    <idle-timeout-minutes>15</idle-timeout-minutes>
>>>
>>>
>>>   
>>
>> <exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.OracleEx 
>>
>>  
>>
>>> ceptionSorter</exception-sorter-class-name>
>>>  </local-tx-datasource>
>>> </datasources>
>>>
>>> All my DAO objects use the dataSource bean which is defined in my
>>> application context as follows:
>>> <bean id="dataSource"
>>>   
>>
>> class="org.springframework.jndi.JndiObjectFactoryBean"
>>  
>>
>>> singleton="true" lazy-init="default" autowire="default"
>>> dependency-check="default">
>>> - <property name="jndiName">
>>>  <value>myapp-ds</value>
>>>  </property>
>>> - <property name="resourceRef">
>>>  <value>true</value>
>>>  </property>
>>>  </bean>
>>>
>>> Thank you very much!
>>> Lidia
>>>   
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by Sleepycat Software
> Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
> deliver higher performing products faster, at low TCO.
> http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Turning off autocommit in JBoss / Oracle datasource

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

Actually I think this is just bad usage/config of Spring.

A connection returned from a DataSource is normally set to 
autocommit=true as per the Connection JavaDocs.

Now our TransactionManagers (like DataSourceTransactionManager) do set 
autocommit to false when starting a transaction, and restore it back to 
whatever it was afterwards.

My feeling Lidia is that you are not properly wrapping your DAO/Mapper 
objects in either Spring declarative or programmatic transactions, so in 
your test code you are not actually getting a connection while in a 
transaciton. How to do transactional wrapping is described in a fair 
amount of detail in the Spring manual. If you have any need for more 
info after looking at that, or think that the problem is something else, 
please post another message with more info.

Regards,
Colin

Rod Johnson wrote:

>Lidia
>
>You're right. Autocommit is evil in non-trivial apps. However, this is
>really a JBoss question. Have you checked their lists/forums/FAQs?
>
>Regards
>Rod
>
>----- Original Message -----
>From: "Levkovitch, Lidia" <lle...@su...>
>To: <spr...@li...>
>Sent: Wednesday, May 12, 2004 7:02 PM
>Subject: [Springframework-developer] Turning off autocommit in JBoss /
>Oracle datasource
>
>
>  
>
>>Folks,
>>
>>I am using a datasource to have my Spring DAOs connect to Oracle database.
>>Apparently, with my set up, autocommit is turned on, and this is not what
>>    
>>
>I
>  
>
>>need!
>>I have actually put this line of code inside one of the DAOs'
>>afterPropertiesSet() method:
>>logger.debug("autocommit is " + getDs().getConnection().getAutoCommit());
>>and this prints "autocommit is true".
>>
>>Is there a way to configure my datasource so that autocommit is set to
>>false? I am using JBoss 3.2.1 with Oracle 9.2. In one of JBoss forums it
>>actually.
>>
>>The datasource is defined in myapp-ds.xml file like this:
>>(this is based on the example that came with JBoss)
>><datasources>
>>  <local-tx-datasource>
>>    <jndi-name>myapp-ds</jndi-name>
>>
>><connection-url>jdbc:oracle:thin:@[my database
>>name]</connection-url>
>>    <driver-class>oracle.jdbc.driver.OracleDriver</driver-class>
>>    <user-name>[my user name]</user-name>
>>    <password>[my password]</password>
>>    <min-pool-size>3</min-pool-size>
>>    <max-pool-size>30</max-pool-size>
>>    <blocking-timeout-millis>3000</blocking-timeout-millis>
>>    <idle-timeout-minutes>15</idle-timeout-minutes>
>>
>>
>>    
>>
><exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.OracleEx
>  
>
>>ceptionSorter</exception-sorter-class-name>
>>  </local-tx-datasource>
>></datasources>
>>
>>All my DAO objects use the dataSource bean which is defined in my
>>application context as follows:
>><bean id="dataSource"
>>    
>>
>class="org.springframework.jndi.JndiObjectFactoryBean"
>  
>
>>singleton="true" lazy-init="default" autowire="default"
>>dependency-check="default">
>>- <property name="jndiName">
>>  <value>myapp-ds</value>
>>  </property>
>>- <property name="resourceRef">
>>  <value>true</value>
>>  </property>
>>  </bean>
>>
>>Thank you very much!
>>Lidia
>>    
>>

Re: [Springframework-developer] Turning off autocommit in JBoss / Oracle datasource

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

Lidia

You're right. Autocommit is evil in non-trivial apps. However, this is
really a JBoss question. Have you checked their lists/forums/FAQs?

Regards
Rod

----- Original Message -----
From: "Levkovitch, Lidia" <lle...@su...>
To: <spr...@li...>
Sent: Wednesday, May 12, 2004 7:02 PM
Subject: [Springframework-developer] Turning off autocommit in JBoss /
Oracle datasource


> Folks,
>
> I am using a datasource to have my Spring DAOs connect to Oracle database.
> Apparently, with my set up, autocommit is turned on, and this is not what
I
> need!
> I have actually put this line of code inside one of the DAOs'
> afterPropertiesSet() method:
> logger.debug("autocommit is " + getDs().getConnection().getAutoCommit());
> and this prints "autocommit is true".
>
> Is there a way to configure my datasource so that autocommit is set to
> false? I am using JBoss 3.2.1 with Oracle 9.2. In one of JBoss forums it
> actually.
>
> The datasource is defined in myapp-ds.xml file like this:
> (this is based on the example that came with JBoss)
> <datasources>
>   <local-tx-datasource>
>     <jndi-name>myapp-ds</jndi-name>
>
> <connection-url>jdbc:oracle:thin:@[my database
> name]</connection-url>
>     <driver-class>oracle.jdbc.driver.OracleDriver</driver-class>
>     <user-name>[my user name]</user-name>
>     <password>[my password]</password>
>     <min-pool-size>3</min-pool-size>
>     <max-pool-size>30</max-pool-size>
>     <blocking-timeout-millis>3000</blocking-timeout-millis>
>     <idle-timeout-minutes>15</idle-timeout-minutes>
>
>
<exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.OracleEx
> ceptionSorter</exception-sorter-class-name>
>   </local-tx-datasource>
> </datasources>
>
> All my DAO objects use the dataSource bean which is defined in my
> application context as follows:
> <bean id="dataSource"
class="org.springframework.jndi.JndiObjectFactoryBean"
> singleton="true" lazy-init="default" autowire="default"
> dependency-check="default">
> - <property name="jndiName">
>   <value>myapp-ds</value>
>   </property>
> - <property name="resourceRef">
>   <value>true</value>
>   </property>
>   </bean>
>
> Thank you very much!
> Lidia
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by Sleepycat Software
> Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to
> deliver higher performing products faster, at low TCO.
> http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] Turning off autocommit in JBoss / Oracle datasource

[Levkovitch, L. <lle...@ac...>]

Folks,

I am using a datasource to have my Spring DAOs connect to Oracle database.
Apparently, with my set up, autocommit is turned on, and this is not what I
need!
I have actually put this line of code inside one of the DAOs'
afterPropertiesSet() method:
logger.debug("autocommit is " + getDs().getConnection().getAutoCommit());
and this prints "autocommit is true". 

Is there a way to configure my datasource so that autocommit is set to
false? I am using JBoss 3.2.1 with Oracle 9.2. In one of JBoss forums it
actually.

The datasource is defined in myapp-ds.xml file like this:
(this is based on the example that came with JBoss)
<datasources>
  <local-tx-datasource>
    <jndi-name>myapp-ds</jndi-name>
 
	<connection-url>jdbc:oracle:thin:@[my database
name]</connection-url>
    <driver-class>oracle.jdbc.driver.OracleDriver</driver-class>
    <user-name>[my user name]</user-name>
    <password>[my password]</password>
    <min-pool-size>3</min-pool-size>
    <max-pool-size>30</max-pool-size>
    <blocking-timeout-millis>3000</blocking-timeout-millis>
    <idle-timeout-minutes>15</idle-timeout-minutes> 
	
<exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.OracleEx
ceptionSorter</exception-sorter-class-name>
  </local-tx-datasource>
</datasources>

All my DAO objects use the dataSource bean which is defined in my
application context as follows:
<bean id="dataSource" class="org.springframework.jndi.JndiObjectFactoryBean"
singleton="true" lazy-init="default" autowire="default"
dependency-check="default">
- <property name="jndiName">
  <value>myapp-ds</value> 
  </property>
- <property name="resourceRef">
  <value>true</value> 
  </property>
  </bean>

Thank you very much!
Lidia

RE: [Springframework-developer] Bean not advised because another dependency grabs it first?

[James C. <jim...@do...>]

A simpler example may be in order.

<bean id="SAO" class="MySAO" />

<bean id="AutoProxy"
class="org.springframework.aop.framework.autoproxy.BeanNameAutoProxyCreator"
>
	<property name="interceptorNames">
		<list>
			<idref local="transactionInterceptor"/>
		</list>
	</property>
	<property name="beanNames">
		<list>
			<idref local="SAO"/>
		</list>
	</property>
</bean>

<bean id="ClassThatUsesSAO" class="MyBusinessObject">
	<property name="sao"><ref bean="SAO" /></property>
</bean>

The problem is that the "ClassThatUsesSAO" is noticed first be Spring, and
Spring discovers that there is a property on this bean that uses the "SAO"
bean. Spring then instantiates the SAO bean and sets the resulting value to
the property on the "ClassThatUsesSAO". Unfortunately, the SAO bean is not
auto proxied at this time, and never will be as far as the
"ClassThatUsesSAO" is concerned. 

Is there any way to ensure that the autoproxy has a chance to advise the
"SAO" bean prior to invoking setSao() on the "ClassThatUsesSAO"?

RE: [Springframework-developer] Bean not advised because another dependency grabs it first?

[James C. <jim...@do...>]

There was a thread last week that introduced the AutowireByInterface
approach and how it's different from autowire="byType".

 

Primarily, autowire="byType" is an all or nothing approach. If I mark a bean
this way, any setter on my bean will get wired if there is a matching bean
type in Spring. There are a couple drawbacks to this approach that are
discussed in the reference docs, but for me, I just want to be more explicit
in my wiring needs. I don't want a getAge(int) method on one of my beans
accidentally getting wired up to some constructor argument that I may have
in my Spring configuration.

 

The AutowireByInterface allows me to use the following configuration:

 

<bean id="SecuritySAO" class="my.sao.SecuritySAOImpl" />

 

<bean id="SecuritySAOAware" class="my.spring.AutowireByInterface">

            <property
name="interface"><value>my.aware.SecuritySAOAware</value></property>

            <property name="property"><value>securitySAO</value></property>

            <property name="value"><ref bean="SecuritySAO" /></property>

</bean>

 

<bean id="MyAccountAction" class="my.webwork.MyAccountAction"
singleton="false" />

 

If I load 'MyAccountAction' from Spring, the SecuritySAO class is wired on
only if my.webwork.MyAccountAction implements the my.aware.SecuritySAOAware
interface. This makes it vary declarative, and requires no configuration
(other than adding the AutowireByInterface bean post processor). It has all
of the advantages of autowire by type, and none of the disadvantages. It is
really working well for us.

 

  _____  

From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Dmitriy Kopylenko
Sent: Tuesday, May 11, 2004 10:56 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Bean not advised because another
dependency grabs it first?

 

I'm just trying to understand what is the purpose of
my.spring.AutowireByInterface class? Why not just use 'autowire="byType"'
attribute of beans needing SecuritySAO dependency?

Regards,
Dmitriy.

James Cook wrote:



I'm experiencing a problem with the order that my beans are wired together.
I have an SAO bean (id=SecuritySAO) and it is a singleton. 
 
I want this bean to be advised by a BeanNameAutoProxyCreator so it will be
control transactions.
 
I also want this bean to be wired into another BeanPostProcessor class I
wrote called SAOAware.
 
The problem is that the SecuritySAO bean is created initially be the
SAOAware bean because it is a property of the latter. This means that the
AutoProxy bean has not yet had an opportunity to work its magic on the bean
and proxy it.
 
When I use the SAOAware bean, the SecuritySAO object is not proxied and not
weaved into the transation interceptor. I have tried to use the depends-on
to cause the AutoProxy to instrument the bean first, but it didn't make any
difference. I have also used the ordered property of both post processors
without any effect also.
 
Am I missing something else?
 
 
<bean id="SecuritySAO" class="my.SecuritySAOImpl" />
 
 
<bean id="AutoProxy"
class="org.springframework.aop.framework.autoproxy.BeanNameAutoProxyCreator"
  
       <property name="proxyTargetClass"><value>true</value></property>
       <property name="order"><value>1</value></property>
       <property name="interceptorNames">
              <list>
                      <idref local="transactionInterceptor"/>
              </list>
       </property>
       <property name="beanNames">
              <list>
                      <idref local="jpp.SecuritySAO"/>
              </list>
       </property>
</bean>
 
<bean id="SAOAware" class="my.spring.AutowireByInterface"
depends-on="AutoProxy">
       <property name="order"><value>100</value></property>
       <property name="interface"><value>my.SAOAware</value></property>
       <property name="property"><value>securitySAO</value></property>
       <property name="value"><ref bean="SecuritySAO" /></property>
</bean>
 
 
 
 
-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer
  

 

RE: [Springframework-developer] Pre-binding validation

[Oliver H. <Oli...@ou...>]

In the event of validation failure couldn't you just rollback the
current transaction and start a new one for the rest of the request? Or,
even simpler, use Session.evict to make sure that it will never get
flushed.=20



> -----Original Message-----
> From: Daniel Miller [mailto:mi...@pa...]=20
> Sent: Wednesday, 12 May 2004 1:19 PM
> To: spr...@li...
> Subject: RE: [Springframework-developer] Pre-binding validation
>=20
>=20
> Hi Seth,
>=20
> > Please point out my error(s) here if I have made one or many.
> >
> > One potential solution (inspired by above mentioned post): Create a=20
> > RequestWrapper that can be validated just like the=20
> persistent object=20
> > to which the request will be bound (I realize this could be messy=20
> > because it is essentially reverse reflection aka emulation). Then=20
> > invoke
> the
> > validator substituting the wrapped request for the actual object=20
> > _before_ binding.
>=20
> >Great thinking, Daniel.  I've always used a Command/FormBean because
> often the web workflow doesn't match up to the domain objects=20
> close enough.  But you're right, I wouldn't want any flush()=20
> to happen until after validation.
>=20
> >For this scenario to happen, a call to find() or iterate()=20
> would have=20
> >to
> be called /on the session for this request/, correct? =20
> Assuming a usual setup of one session for the request, and=20
> the request itself is not multithreaded, how would this=20
> condition arise?
>=20
> After validation failure: processFormSubmission() -> showForm() ->
> referenceData() which could load objects from the database=20
> using a find() or iterate().
>=20
> Thanks for the quick feedback.
> Daniel
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by Sleepycat Software
> Learn developer strategies Cisco, Motorola, Ericsson & Lucent=20
> use to deliver higher performing products faster, at low TCO.=20
> http://www.sleepycat.com/telcomwpreg.php?> From=3Dosdnemail3
>=20
>=20
> _______________________________________________
> Springframework-developer mailing list=20
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by Sleepycat Software
> Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to=20
> deliver higher performing products faster, at low TCO.=20
> http://www.sleepycat.com/telcomwpreg.php?> From=3Dosdnemail3
>=20
>=20
> _______________________________________________
> Springframework-developer mailing list=20
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20

RE: [Springframework-developer] Pre-binding validation

[Daniel M. <mi...@pa...>]

Hi Seth,

> Please point out my error(s) here if I have made one or many.
>
> One potential solution (inspired by above mentioned post):
> Create a RequestWrapper that can be validated just like the persistent
> object to which the request will be bound (I realize this could be messy
> because it is essentially reverse reflection aka emulation). Then invoke
the
> validator substituting the wrapped request for the actual object _before_
> binding.

>Great thinking, Daniel.  I've always used a Command/FormBean because
often the web workflow doesn't match up to the domain objects close
enough.  But you're right, I wouldn't want any flush() to happen until
after validation.

>For this scenario to happen, a call to find() or iterate() would have to
be called /on the session for this request/, correct?  Assuming a usual
setup of one session for the request, and the request itself is not
multithreaded, how would this condition arise?

After validation failure: processFormSubmission() -> showForm() ->
referenceData() which could load objects from the database using a find() or
iterate().

Thanks for the quick feedback.
Daniel

-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Pre-binding validation

[Seth L. <se...@eh...>]

> Please point out my error(s) here if I have made one or many.
> 
> One potential solution (inspired by above mentioned post):
> Create a RequestWrapper that can be validated just like the persistent
> object to which the request will be bound (I realize this could be messy
> because it is essentially reverse reflection aka emulation). Then invoke the
> validator substituting the wrapped request for the actual object _before_
> binding.

Great thinking, Daniel.  I've always used a Command/FormBean because 
often the web workflow doesn't match up to the domain objects close 
enough.  But you're right, I wouldn't want any flush() to happen until 
after validation.

For this scenario to happen, a call to find() or iterate() would have to 
be called /on the session for this request/, correct?  Assuming a usual 
setup of one session for the request, and the request itself is not 
multithreaded, how would this condition arise?

Thanks!
Seth

[Springframework-developer] Pre-binding validation

[Daniel M. <mi...@pa...>]

Recently while browsing the Help list (man do I still have a life or not?) I
came across this post:

https://sourceforge.net/forum/message.php?msg_id=2564738

It got me thinking about a potential problem with Spring MVC. Spring MVC
allows the user to bind the submit request directly to a persistent object
(assume that the command object has been loaded using a Hibernate DAO in
formBackingObject()). This eliminates a lot of code needed to transfer data
from the form (i.e. Struts ActionForm) to the persistent object. However
there is a potential problem here:

All data that does not trigger binding failure is bound directly to the
persistent object _before_ validation.

If I understand the thread local session pattern correctly, any
transactional method call that performs a flush after this point will cause
Hibernate to collect all of the persistent objects that it knows about (all
objects in the current session) and update the database with the contained
values.

<quote reference="hibernate_reference.pdf" chapter="8.4">

Persistent instances (ie. objects loaded, saved, created or queried by the
Session) may be manipulated by the application and any changes to persistent
state will be persisted when the Session is flushed (see "flushing" below).
So the most straightforward way to update the state of an object is to
load() it, and then manipulate it directly.

</quote>

and the relevant section on flushing:

<quote reference="hibernate_reference.pdf" chapter="8.9">

>From time to time the Session will execute the SQL statements needed to
synchronize the JDBC connection's state with the state of objects held in
memory. This process, flush, occurs by default at the following points
• from some invocations of find() or iterate()
• from net.sf.hibernate.Transaction.commit()
• from Session.flush()

</quote>

Very sneaky, we don't even need to call update(persistent_object) to get our
object persisted.

At this point, Spring invokes a validator with the persistent object as its
subject. If there are errors, the user will be forwarded back to the form.
However, the database could be in an inconsistent state because any value
that was successfully bound to the persistent object could possibly already
have been persisted to the database due to some unrelated transactional
method call.

Please point out my error(s) here if I have made one or many.

One potential solution (inspired by above mentioned post):
Create a RequestWrapper that can be validated just like the persistent
object to which the request will be bound (I realize this could be messy
because it is essentially reverse reflection aka emulation). Then invoke the
validator substituting the wrapped request for the actual object _before_
binding.

Feedback is greatly appreciated.
Thanks.

Daniel Miller

Re: [Springframework-developer] Bean not advised because another dependency grabs it first?

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

I'm just trying to understand what is the purpose of  
my.spring.AutowireByInterface class? Why not just use 
'autowire="byType"' attribute of beans needing SecuritySAO dependency?

Regards,
Dmitriy.

James Cook wrote:

>I'm experiencing a problem with the order that my beans are wired together.
>I have an SAO bean (id=SecuritySAO) and it is a singleton. 
>
>I want this bean to be advised by a BeanNameAutoProxyCreator so it will be
>control transactions.
>
>I also want this bean to be wired into another BeanPostProcessor class I
>wrote called SAOAware.
>
>The problem is that the SecuritySAO bean is created initially be the
>SAOAware bean because it is a property of the latter. This means that the
>AutoProxy bean has not yet had an opportunity to work its magic on the bean
>and proxy it.
>
>When I use the SAOAware bean, the SecuritySAO object is not proxied and not
>weaved into the transation interceptor. I have tried to use the depends-on
>to cause the AutoProxy to instrument the bean first, but it didn't make any
>difference. I have also used the ordered property of both post processors
>without any effect also.
>
>Am I missing something else?
>
>
><bean id="SecuritySAO" class="my.SecuritySAOImpl" />
>
>
><bean id="AutoProxy"
>class="org.springframework.aop.framework.autoproxy.BeanNameAutoProxyCreator"
>  
>
>	<property name="proxyTargetClass"><value>true</value></property>
>	<property name="order"><value>1</value></property>
>	<property name="interceptorNames">
>		<list>
>			<idref local="transactionInterceptor"/>
>		</list>
>	</property>
>	<property name="beanNames">
>		<list>
>			<idref local="jpp.SecuritySAO"/>
>		</list>
>	</property>
></bean>
>
><bean id="SAOAware" class="my.spring.AutowireByInterface"
>depends-on="AutoProxy">
>	<property name="order"><value>100</value></property>
>	<property name="interface"><value>my.SAOAware</value></property>
>	<property name="property"><value>securitySAO</value></property>
>	<property name="value"><ref bean="SecuritySAO" /></property>
></bean>
>
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by Sleepycat Software
>Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
>deliver higher performing products faster, at low TCO.
>http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>  
>

[Springframework-developer] Bean not advised because another dependency grabs it first?

[James C. <jim...@do...>]

I'm experiencing a problem with the order that my beans are wired together.
I have an SAO bean (id=SecuritySAO) and it is a singleton. 

I want this bean to be advised by a BeanNameAutoProxyCreator so it will be
control transactions.

I also want this bean to be wired into another BeanPostProcessor class I
wrote called SAOAware.

The problem is that the SecuritySAO bean is created initially be the
SAOAware bean because it is a property of the latter. This means that the
AutoProxy bean has not yet had an opportunity to work its magic on the bean
and proxy it.

When I use the SAOAware bean, the SecuritySAO object is not proxied and not
weaved into the transation interceptor. I have tried to use the depends-on
to cause the AutoProxy to instrument the bean first, but it didn't make any
difference. I have also used the ordered property of both post processors
without any effect also.

Am I missing something else?


<bean id="SecuritySAO" class="my.SecuritySAOImpl" />


<bean id="AutoProxy"
class="org.springframework.aop.framework.autoproxy.BeanNameAutoProxyCreator"
>
	<property name="proxyTargetClass"><value>true</value></property>
	<property name="order"><value>1</value></property>
	<property name="interceptorNames">
		<list>
			<idref local="transactionInterceptor"/>
		</list>
	</property>
	<property name="beanNames">
		<list>
			<idref local="jpp.SecuritySAO"/>
		</list>
	</property>
</bean>

<bean id="SAOAware" class="my.spring.AutowireByInterface"
depends-on="AutoProxy">
	<property name="order"><value>100</value></property>
	<property name="interface"><value>my.SAOAware</value></property>
	<property name="property"><value>securitySAO</value></property>
	<property name="value"><ref bean="SecuritySAO" /></property>
</bean>

Re: [Springframework-developer] Prototype handling support

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

Colin

I didn't say your solution was bad, just that I'm in love with mine.

As yours is merely a FactoryBean and not an IoC core mod (should have read
your email more closely) I see no issue in putting it in if it's useful.

Sorry!

R

----- Original Message -----
From: "Colin Sampaleanu" <col...@ex...>
To: <spr...@li...>
Sent: Tuesday, May 11, 2004 9:11 PM
Subject: Re: [Springframework-developer] Prototype handling support


> I can certainly keep it to myself, it's not a big deal. I agree that
> your solution is the strategic one, and would be more convenient to use
> to boot. However, I don't think the two solutions are covering the exact
> same use cases given that my code is completely usable without cglib or
> other code modification. It actually consists of just the small
> FactoryBean implementation, plus a simpler variant of FactoryBean
> (called ObjectFactory) which is what it returns, that has only a
> getObject() method in it which throws BeansException (as opposed to
> FactoryBean's Exception).
>
> I do agree that it's not worth modifying the container in any way (i.e.
> changes to the DTD and container code to short-circuit the manual
> factory bean creation), given that your solution is more comprehensive.
>
> Let me know either way....
>
> Regards,
> Colin
>
> Rod Johnson wrote:
>
> >Colin
> >
> >I think my solution is the strategic one, as I wanted to avoid any
> >dependency on Spring in such cases. Can you work with yours in your own
> >patch until we can build in the better way?
> >
> >Rgds
> >Rod
> >
> >----- Original Message -----
> >From: "Colin Sampaleanu" <col...@ex...>
> >To: <spr...@li...>
> >Sent: Tuesday, May 11, 2004 5:05 PM
> >Subject: Re: [Springframework-developer] Prototype handling support
> >
> >
> >
> >
> >>Rod,
> >>
> >>I am almost done a much simpler interimn (aka not as good) solution,
> >>which is a FactoryBeanCreatingFactoryBean.
> >>
> >>It is simply a FactoryBean which produces a FactoryBean which will then
> >>be used for accessing a prototype. So you have the current definition.
> >>
> >>    <bean id="prototype" class="a.b.c.D" singleton="false">
> >>      ...
> >>    </bean>
> >>    <bean id="myX" class="a.b.c.XXX">
> >>      ...
> >>    </bean>
> >>
> >>and the current java code
> >>
> >>class XXX implements BeanFactoryAware {
> >>    BeanFactory _bf;
> >>    void setBeanFactory(BeanFactory beanFactory) throws BeansException
> >>{  ...  };
> >>
> >>    ... in some method
> >>    D dInstance = _bf.getBean("prototype");
> >>    ...
> >>}
> >>
> >>This would become:
> >>
> >>    <bean id="prototypeTarget" class="a.b.c.D" singleton="false">
> >>      ...
> >>    </bean>
> >>    <bean id="prototype"
> >>
> >>
> >>
>
>class="org.springframework.beans.factory.config.FactoryBeanCreatingFactoryB
e
> >an">
> >
> >
> >>      <property name="targetName"><idref
> >>local="prototypeTarget"/></property>
> >>    </bean>
> >>    <bean id="myX" class="a.b.c.XXX">
> >>      <property name="prototypeFactory"><ref
> >>
> >>
> >local="prototype"/></property>
> >
> >
> >>    </bean>
> >>
> >>with the Java code:
> >>
> >>class XXX  {
> >>    FactoryBean _prototypeFactory;
> >>    void setPrototypeFactory(FactoryBean factoryBean) {  ...  };
> >>
> >>    ... in some method
> >>    D dInstance = (D) _prototypeFactory.getObject();;
> >>    ...
> >>}
> >>
> >>Now is the second form better? Personally I think so; there is still a
> >>tie to Spring of course (FactoryBean), but at least it's not
> >>BeanFactoryAware, and the client can only get at one bean, not _any_
> >>bean in the BeanFactory. It would be a lot simpler of course if the
> >>container itself could create the FactoryBean on the fly as part of the
> >>property setting.
> >>
> >>Your solution is much nicer of course. I would be interested in using
> >>and polishing up your code, but I can't do it myself either until about
> >>1.5 to 2 weeks from now. We have a situation with an app running on "the
> >>most popular open-source EJB server" which has become intolerable due to
> >>unreliability in the face of increased usage, and I need to work to move
> >>my current CVS code to production next week.
> >>
> >>Colin
> >>
> >>
> >>Rod Johnson wrote:
> >>
> >>
> >>
> >>>Colin
> >>>
> >>>When it gets into Spring depends on when I have time to
> >>>polish it. Basically that means some time in June. It
> >>>basically works and it's _very_ useful. (I keep thinking of
> >>>cool things to use it for: I kept boring Juergen and Alef
> >>>about it on Sunday morning :-) It also needs discussion with
> >>>at least Juergen about the extensions to the DTD. (100%
> >>>backward compatible, of course.) And to accommodate the
> >>>upcoming AspectJ integration in 1.0.3 (new feature but again
> >>>very useful!) it needs to be implemented in a slightly
> >>>different, more open way.
> >>>
> >>>If you want to take responsibility for completing it, in
> >>>conjunction with myself and Juergen to discuss how the slight
> >>>enhancements to the core IoC stuff should work, that would be
> >>>great! I could send you the code and tests today.
> >>>
> >>>That way we will get it for 1.0.3, which would also be great.
> >>>Of course if you're on HEAD you could be using it by the end
> >>>of the week... As I said, it already works.
> >>>
> >>>Rgds,
> >>>Rod
> >>>---- Original message ----
> >>>
> >>>
> >>>
> >>>
> >>>>Date: Tue, 11 May 2004 09:05:59 -0400
> >>>>From: Colin Sampaleanu <col...@ex...>
> >>>>Subject: [Springframework-developer] Prototype handling
> >>>>
> >>>>
> >>>>
> >>>>
> >>>support
> >>>
> >>>
> >>>
> >>>
> >>>>To: spr...@li...
> >>>>
> >>>>Rod,
> >>>>
> >>>>At the TSS Symposium you mentioned having done some code to
> >>>>
> >>>>
> >>>>
> >>>>
> >>>allow the
> >>>
> >>>
> >>>
> >>>
> >>>>appcontext to dynamically modify a class so that a create or
> >>>>
> >>>>
> >>>>
> >>>>
> >>>getter
> >>>
> >>>
> >>>
> >>>
> >>>>method within it could actualy be hooked up to a prototype
> >>>>
> >>>>
> >>>>
> >>>>
> >>>bean within
> >>>
> >>>
> >>>
> >>>
> >>>>the factory. What are your thoughts on adding this code in
> >>>>
> >>>>
> >>>>
> >>>>
> >>>at this time?
> >>>
> >>>
> >>>
> >>>
> >>>>It would actually be of use to me...
> >>>>
> >>>>Colin
> >>>>
> >>>>
> >>>>
> >>>>-------------------------------------------------------
> >>>>This SF.Net email is sponsored by Sleepycat Software
> >>>>Learn developer strategies Cisco, Motorola, Ericsson &
> >>>>
> >>>>
> >>>>
> >>>>
> >>>Lucent use to
> >>>
> >>>
> >>>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by Sleepycat Software
> Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to
> deliver higher performing products faster, at low TCO.
> http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

Re: [Springframework-developer] Prototype handling support

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

I can certainly keep it to myself, it's not a big deal. I agree that 
your solution is the strategic one, and would be more convenient to use 
to boot. However, I don't think the two solutions are covering the exact 
same use cases given that my code is completely usable without cglib or 
other code modification. It actually consists of just the small 
FactoryBean implementation, plus a simpler variant of FactoryBean 
(called ObjectFactory) which is what it returns, that has only a 
getObject() method in it which throws BeansException (as opposed to 
FactoryBean's Exception).

I do agree that it's not worth modifying the container in any way (i.e. 
changes to the DTD and container code to short-circuit the manual 
factory bean creation), given that your solution is more comprehensive.

Let me know either way....

Regards,
Colin

Rod Johnson wrote:

>Colin
>
>I think my solution is the strategic one, as I wanted to avoid any
>dependency on Spring in such cases. Can you work with yours in your own
>patch until we can build in the better way?
>
>Rgds
>Rod
>
>----- Original Message -----
>From: "Colin Sampaleanu" <col...@ex...>
>To: <spr...@li...>
>Sent: Tuesday, May 11, 2004 5:05 PM
>Subject: Re: [Springframework-developer] Prototype handling support
>
>
>  
>
>>Rod,
>>
>>I am almost done a much simpler interimn (aka not as good) solution,
>>which is a FactoryBeanCreatingFactoryBean.
>>
>>It is simply a FactoryBean which produces a FactoryBean which will then
>>be used for accessing a prototype. So you have the current definition.
>>
>>    <bean id="prototype" class="a.b.c.D" singleton="false">
>>      ...
>>    </bean>
>>    <bean id="myX" class="a.b.c.XXX">
>>      ...
>>    </bean>
>>
>>and the current java code
>>
>>class XXX implements BeanFactoryAware {
>>    BeanFactory _bf;
>>    void setBeanFactory(BeanFactory beanFactory) throws BeansException
>>{  ...  };
>>
>>    ... in some method
>>    D dInstance = _bf.getBean("prototype");
>>    ...
>>}
>>
>>This would become:
>>
>>    <bean id="prototypeTarget" class="a.b.c.D" singleton="false">
>>      ...
>>    </bean>
>>    <bean id="prototype"
>>
>>    
>>
>class="org.springframework.beans.factory.config.FactoryBeanCreatingFactoryBe
>an">
>  
>
>>      <property name="targetName"><idref
>>local="prototypeTarget"/></property>
>>    </bean>
>>    <bean id="myX" class="a.b.c.XXX">
>>      <property name="prototypeFactory"><ref
>>    
>>
>local="prototype"/></property>
>  
>
>>    </bean>
>>
>>with the Java code:
>>
>>class XXX  {
>>    FactoryBean _prototypeFactory;
>>    void setPrototypeFactory(FactoryBean factoryBean) {  ...  };
>>
>>    ... in some method
>>    D dInstance = (D) _prototypeFactory.getObject();;
>>    ...
>>}
>>
>>Now is the second form better? Personally I think so; there is still a
>>tie to Spring of course (FactoryBean), but at least it's not
>>BeanFactoryAware, and the client can only get at one bean, not _any_
>>bean in the BeanFactory. It would be a lot simpler of course if the
>>container itself could create the FactoryBean on the fly as part of the
>>property setting.
>>
>>Your solution is much nicer of course. I would be interested in using
>>and polishing up your code, but I can't do it myself either until about
>>1.5 to 2 weeks from now. We have a situation with an app running on "the
>>most popular open-source EJB server" which has become intolerable due to
>>unreliability in the face of increased usage, and I need to work to move
>>my current CVS code to production next week.
>>
>>Colin
>>
>>
>>Rod Johnson wrote:
>>
>>    
>>
>>>Colin
>>>
>>>When it gets into Spring depends on when I have time to
>>>polish it. Basically that means some time in June. It
>>>basically works and it's _very_ useful. (I keep thinking of
>>>cool things to use it for: I kept boring Juergen and Alef
>>>about it on Sunday morning :-) It also needs discussion with
>>>at least Juergen about the extensions to the DTD. (100%
>>>backward compatible, of course.) And to accommodate the
>>>upcoming AspectJ integration in 1.0.3 (new feature but again
>>>very useful!) it needs to be implemented in a slightly
>>>different, more open way.
>>>
>>>If you want to take responsibility for completing it, in
>>>conjunction with myself and Juergen to discuss how the slight
>>>enhancements to the core IoC stuff should work, that would be
>>>great! I could send you the code and tests today.
>>>
>>>That way we will get it for 1.0.3, which would also be great.
>>>Of course if you're on HEAD you could be using it by the end
>>>of the week... As I said, it already works.
>>>
>>>Rgds,
>>>Rod
>>>---- Original message ----
>>>
>>>
>>>      
>>>
>>>>Date: Tue, 11 May 2004 09:05:59 -0400
>>>>From: Colin Sampaleanu <col...@ex...>
>>>>Subject: [Springframework-developer] Prototype handling
>>>>
>>>>
>>>>        
>>>>
>>>support
>>>
>>>
>>>      
>>>
>>>>To: spr...@li...
>>>>
>>>>Rod,
>>>>
>>>>At the TSS Symposium you mentioned having done some code to
>>>>
>>>>
>>>>        
>>>>
>>>allow the
>>>
>>>
>>>      
>>>
>>>>appcontext to dynamically modify a class so that a create or
>>>>
>>>>
>>>>        
>>>>
>>>getter
>>>
>>>
>>>      
>>>
>>>>method within it could actualy be hooked up to a prototype
>>>>
>>>>
>>>>        
>>>>
>>>bean within
>>>
>>>
>>>      
>>>
>>>>the factory. What are your thoughts on adding this code in
>>>>
>>>>
>>>>        
>>>>
>>>at this time?
>>>
>>>
>>>      
>>>
>>>>It would actually be of use to me...
>>>>
>>>>Colin
>>>>
>>>>
>>>>
>>>>-------------------------------------------------------
>>>>This SF.Net email is sponsored by Sleepycat Software
>>>>Learn developer strategies Cisco, Motorola, Ericsson &
>>>>
>>>>
>>>>        
>>>>
>>>Lucent use to
>>>
>>>      
>>>

Re: [Springframework-developer] Prototype handling support

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

Colin

I think my solution is the strategic one, as I wanted to avoid any
dependency on Spring in such cases. Can you work with yours in your own
patch until we can build in the better way?

Rgds
Rod

----- Original Message -----
From: "Colin Sampaleanu" <col...@ex...>
To: <spr...@li...>
Sent: Tuesday, May 11, 2004 5:05 PM
Subject: Re: [Springframework-developer] Prototype handling support


> Rod,
>
> I am almost done a much simpler interimn (aka not as good) solution,
> which is a FactoryBeanCreatingFactoryBean.
>
> It is simply a FactoryBean which produces a FactoryBean which will then
> be used for accessing a prototype. So you have the current definition.
>
>     <bean id="prototype" class="a.b.c.D" singleton="false">
>       ...
>     </bean>
>     <bean id="myX" class="a.b.c.XXX">
>       ...
>     </bean>
>
> and the current java code
>
> class XXX implements BeanFactoryAware {
>     BeanFactory _bf;
>     void setBeanFactory(BeanFactory beanFactory) throws BeansException
> {  ...  };
>
>     ... in some method
>     D dInstance = _bf.getBean("prototype");
>     ...
> }
>
> This would become:
>
>     <bean id="prototypeTarget" class="a.b.c.D" singleton="false">
>       ...
>     </bean>
>     <bean id="prototype"
>
class="org.springframework.beans.factory.config.FactoryBeanCreatingFactoryBe
an">
>
>       <property name="targetName"><idref
> local="prototypeTarget"/></property>
>     </bean>
>     <bean id="myX" class="a.b.c.XXX">
>       <property name="prototypeFactory"><ref
local="prototype"/></property>
>     </bean>
>
> with the Java code:
>
> class XXX  {
>     FactoryBean _prototypeFactory;
>     void setPrototypeFactory(FactoryBean factoryBean) {  ...  };
>
>     ... in some method
>     D dInstance = (D) _prototypeFactory.getObject();;
>     ...
> }
>
> Now is the second form better? Personally I think so; there is still a
> tie to Spring of course (FactoryBean), but at least it's not
> BeanFactoryAware, and the client can only get at one bean, not _any_
> bean in the BeanFactory. It would be a lot simpler of course if the
> container itself could create the FactoryBean on the fly as part of the
> property setting.
>
> Your solution is much nicer of course. I would be interested in using
> and polishing up your code, but I can't do it myself either until about
> 1.5 to 2 weeks from now. We have a situation with an app running on "the
> most popular open-source EJB server" which has become intolerable due to
> unreliability in the face of increased usage, and I need to work to move
> my current CVS code to production next week.
>
> Colin
>
>
> Rod Johnson wrote:
>
> >Colin
> >
> >When it gets into Spring depends on when I have time to
> >polish it. Basically that means some time in June. It
> >basically works and it's _very_ useful. (I keep thinking of
> >cool things to use it for: I kept boring Juergen and Alef
> >about it on Sunday morning :-) It also needs discussion with
> >at least Juergen about the extensions to the DTD. (100%
> >backward compatible, of course.) And to accommodate the
> >upcoming AspectJ integration in 1.0.3 (new feature but again
> >very useful!) it needs to be implemented in a slightly
> >different, more open way.
> >
> >If you want to take responsibility for completing it, in
> >conjunction with myself and Juergen to discuss how the slight
> >enhancements to the core IoC stuff should work, that would be
> >great! I could send you the code and tests today.
> >
> >That way we will get it for 1.0.3, which would also be great.
> >Of course if you're on HEAD you could be using it by the end
> >of the week... As I said, it already works.
> >
> >Rgds,
> >Rod
> >---- Original message ----
> >
> >
> >>Date: Tue, 11 May 2004 09:05:59 -0400
> >>From: Colin Sampaleanu <col...@ex...>
> >>Subject: [Springframework-developer] Prototype handling
> >>
> >>
> >support
> >
> >
> >>To: spr...@li...
> >>
> >>Rod,
> >>
> >>At the TSS Symposium you mentioned having done some code to
> >>
> >>
> >allow the
> >
> >
> >>appcontext to dynamically modify a class so that a create or
> >>
> >>
> >getter
> >
> >
> >>method within it could actualy be hooked up to a prototype
> >>
> >>
> >bean within
> >
> >
> >>the factory. What are your thoughts on adding this code in
> >>
> >>
> >at this time?
> >
> >
> >>It would actually be of use to me...
> >>
> >>Colin
> >>
> >>
> >>
> >>-------------------------------------------------------
> >>This SF.Net email is sponsored by Sleepycat Software
> >>Learn developer strategies Cisco, Motorola, Ericsson &
> >>
> >>
> >Lucent use to
> >
> >
> >>deliver higher performing products faster, at low TCO.
> >>http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
> >>_______________________________________________
> >>Springframework-developer mailing list
> >>Spr...@li...
> >>https://lists.sourceforge.net/lists/listinfo/springframework-
> >>
> >>
> >developer
> >
> >
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by Sleepycat Software
> Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to
> deliver higher performing products faster, at low TCO.
> http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

Re: [Springframework-developer] EBJ 3 and J2EE 1.5

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

MessageI/the Spring team will make an official comment on EJB 3 in the =
near future.=20

Unfortunately it's impossible due to the politics surrounding this issue =
to discuss at this point in open list.  Jeff, if you want to discuss =
this further with me off-list that's fine.

Regards,
Rod

----- Original Message -----=20
  From: Jeff Boring=20
  To: spr...@li...=20
  Sent: Monday, May 10, 2004 7:04 PM
  Subject: [Springframework-developer] EBJ 3 and J2EE 1.5


  I agree with most of Juergen's comments about EJB 3 =
(http://blog.hibernate.org/cgi-bin/pollxn.cgi?storypath=3D/Gavin =
King/ejb3.html).=20

  I'd like to see:

  1) Gavin's response
  2) Juergen and/or Rod join JSR 244

  Has anyone talked with Gavin (Juergen/Rod?) about this. Can you =
provide a synopsis of what he said? I'd like to believe that he has not =
completely gone over to the dark side :).

  Politics aside, somebody representing this point of view still needs =
to contribute. We all know that most of what we want will currently be =
vetoed by the big vendors. However, we should still try and fight for =
what we can get. Rod is the most qualified from what I know. Rod, can =
you let us know what is going on in this area? Is there something some =
of us could do to support you in this effort?

  Jeff W. Boring
  Impulse Point
  =20

Re: [Springframework-developer] EBJ 3 and J2EE 1.5

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

I don't think this is the right place for this discussion, 
but my discussion of what is now called Setter Injection 
in "Expert 1:1 J2EE" (published in 2002) and the 30,000 lines 
of code that accompanied it predated all the lightweight 
containers around. Even the Spring project on SourceForge 
began months before other present-generation container 
projects AFAIK. (Please note that I know the PicoContainer 
guys, and what they did was totally independent of Spring, 
but of course it wasn't initially doing Setter Injection.)

Please also note that I do not claim that EJB3 stole anything 
from Spring or that anyone stole anything from anyone else. 
There's just an undeniable similarity.

Regards,
Rod

---- Original message ----
>Date: Tue, 11 May 2004 10:45:52 -0400
>From: Tim Chen <tc...@ta...>  
>Subject: Re: [Springframework-developer] EBJ 3 and J2EE 1.5  
>To: spr...@li...
>
>Good point Thomas but Spring is not the only container with 
Setter 
>injection ;)
>
>-Tim
>
>tho...@tr... wrote:
>
>>Tim,
>>
>>I agree that the discussion on The ServerSide has centered 
around the Entity
>>Bean solution, but Linda's presentation did cover a lot 
more.  She talked a lot
>>about Session Beans and Dependency Injection.  Here is a 
transcript of a few of
>>her slides:
>>
>>Access to Bean's Environment
>> - Get JNDI APIs out of developer's view
>> - Techniques/mechanisms
>>    1)Declarative expression of dependencies in metadata
>>    2)Container injection of resource, etc. entries
>>    3)Simple programmatic lookup mechanisms
>> - Different usages, both have their place
>>    2) very simple; facilitates testability (esp. setter 
injection techniques)
>>    3) more flexible; dynamic
>>
>>Injection
>> - Container can initialize instance variables at time bean 
is made available
>> - Setter injection is better technique
>>   - Better testability
>>   - Can use to inject ejbContext, EntityManager, 
resources, etc
>>   - Considered constructor injection, but found it not as 
simple / flexible
>>
>>
>>One code example:
>>
>>@Session public class MySessionBean {
>>  private DataSource customerDB;
>>
>>  @Inject private void setCustomerDB(DataSource customerDB) 
{
>>    customerDB = myDB;
>>  }
>>
>>
>>  public void myMethod (String myString) {
>>    ...
>>    Connection conn = customerDB.getConnection();
>>    ...
>>  }
>>}
>>
>>I think it looks very familiar :-)
>>
>>Thomas
>>
>>
>>Quoting Tim Chen <tc...@ta...>:
>>
>>  
>>
>>>Jurgen's post quotes:
>>>"And there hasn't been a single credit to Spring and co in 
Linda's=20
>>>talk... (but lots and lots of credits to Hibernate)."
>>>Of course there is no credit to Spring. Why should there 
be?
>>>The main part of the EJB->Hibernate->EJB 3.0 and EJB 3.0 
discussions=20
>>>were centered around it's Entity Bean solution.
>>>Particularly CMP.
>>>
>>>"Spring=92s main aim is to make J2EE easier to use and 
promote good=20
>>>programming practice." *
>>>It does this by being a POJO/Dependency Injector 
container. And it does=20
>>>it very well. (Otherwise we wouldnt be using it ;)
>>>
>>>"Hibernate is a powerful, ultra-high performance 
object/relational=20
>>>persistence and query service for Java." **
>>>Given that, EJB (at least from the entity side) is closer 
to Hibernate=20
>>>than Spring.
>>>EJB is NOT a container.
>>>
>>>"There's a strong difference in terms of flexibility of 
deployment: EJB=20
>>>3 can by design never match Spring's capability of 
adapting to all sorts=20
>>>of environments, even if adopting the same development 
model."
>>>Again. Why should it?! EJB was never meant to run outside 
of a non-ejb=20
>>>container. You can still use Hibernate for that anyways so 
who really=20
>>>cares? If you chose to use EJB then you've chosen to run 
in container.=20
>>>If you don't want to then it's very simple.. don't use 
EJBs.
>>>
>>>"Why oh why does this have to be part of the EJB spec? Why 
not doing a=20
>>>separate O/R mapping spec - no matter if within or 
outsider the JDO=20
>>>scope? There's no technical reason for tying this to an 
EJB container"
>>>I completely disagree. BMP/CMP/EJB has been getting a bad 
rap for a=20
>>>while now due to it's performance issues. It was in fact 
just plain=20
>>>garbage in most cases. So why not fix it? Why create a 
whole new spec=20
>>>and leave the other one in its state? What good does that 
do anyone?
>>>
>>>"It is not good enough to have some EJB 3 EntityManager 
implementations=20
>>>that can run outside an EJB container. It's still part of 
the EJB spec,=20
>>>not allowing certification for anything but a complete EJB 
container=20
>>>implementation (which includes the entire EJB 2 model)."
>>>I agree with that one. Backwards compatibility with 
something that was=20
>>>intrinsically broken is just a bad idea.
>>>
>>>-Tim
>>>
>>>* http://www.theserverside.com/articles/article.tss?
l=3DSpringFramework
>>>** http://www.hibernate.org/
>>>
>>>Jeff Boring wrote:
>>>
>>>    
>>>
>>>>I agree with most of Juergen's comments about EJB 3=20
>>>>(http://blog.hibernate.org/cgi-bin/pollxn.cgi?
storypath=3D/Gavin=20
>>>>King/ejb3.html).
>>>>I'd like to see:
>>>>1) Gavin's response
>>>>2) Juergen and/or Rod join JSR 244
>>>>Has anyone talked with Gavin (Juergen/Rod?) about this. 
Can you=20
>>>>provide a synopsis of what he said? I'd like to believe 
that he has=20
>>>>not completely gone over to the dark side :).
>>>>Politics aside, somebody representing this point of view 
still needs=20
>>>>to contribute. We all know that most of what we want will 
currently be=20
>>>>vetoed by the big vendors. However, we should still try 
and fight for=20
>>>>what we can get. Rod is the most qualified from what I 
know. Rod, can=20
>>>>you let us know what is going on in this area? Is there 
something some=20
>>>>of us could do to support you in this effort?
>>>>Jeff W. Boring
>>>>Impulse Point
>>>>      
>>>>
>>>
>>>
>>>-------------------------------------------------------
>>>This SF.Net email is sponsored by Sleepycat Software
>>>Learn developer strategies Cisco, Motorola, Ericsson & 
Lucent use to
>>>deliver higher performing products faster, at low TCO.
>>>http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
>>>_______________________________________________
>>>Springframework-developer mailing list
>>>Spr...@li...
>>>https://lists.sourceforge.net/lists/listinfo/springframewor
k-developer
>>>
>>>    
>>>
>>
>>
>>
>>
>>
>>-------------------------------------------------------
>>This SF.Net email is sponsored by Sleepycat Software
>>Learn developer strategies Cisco, Motorola, Ericsson & 
Lucent use to 
>>deliver higher performing products faster, at low TCO.
>>http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
>>_______________________________________________
>>Springframework-developer mailing list
>>Spr...@li...
>>https://lists.sourceforge.net/lists/listinfo/springframework
-developer
>>
>>  
>>
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by Sleepycat Software
>Learn developer strategies Cisco, Motorola, Ericsson & 
Lucent use to 
>deliver higher performing products faster, at low TCO.
>http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-
developer

Re: [Springframework-developer] Prototype handling support

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

Rod,

I am almost done a much simpler interimn (aka not as good) solution, 
which is a FactoryBeanCreatingFactoryBean.

It is simply a FactoryBean which produces a FactoryBean which will then 
be used for accessing a prototype. So you have the current definition.

    <bean id="prototype" class="a.b.c.D" singleton="false">
      ...
    </bean>
    <bean id="myX" class="a.b.c.XXX">
      ...
    </bean>

and the current java code

class XXX implements BeanFactoryAware {
    BeanFactory _bf;
    void setBeanFactory(BeanFactory beanFactory) throws BeansException 
{  ...  };

    ... in some method
    D dInstance = _bf.getBean("prototype");
    ...
}

This would become:

    <bean id="prototypeTarget" class="a.b.c.D" singleton="false">
      ...
    </bean>
    <bean id="prototype" 
class="org.springframework.beans.factory.config.FactoryBeanCreatingFactoryBean"> 

      <property name="targetName"><idref 
local="prototypeTarget"/></property>
    </bean>
    <bean id="myX" class="a.b.c.XXX">
      <property name="prototypeFactory"><ref local="prototype"/></property>
    </bean>

with the Java code:

class XXX  {
    FactoryBean _prototypeFactory;
    void setPrototypeFactory(FactoryBean factoryBean) {  ...  };

    ... in some method
    D dInstance = (D) _prototypeFactory.getObject();;
    ...
}

Now is the second form better? Personally I think so; there is still a 
tie to Spring of course (FactoryBean), but at least it's not 
BeanFactoryAware, and the client can only get at one bean, not _any_ 
bean in the BeanFactory. It would be a lot simpler of course if the 
container itself could create the FactoryBean on the fly as part of the 
property setting.

Your solution is much nicer of course. I would be interested in using 
and polishing up your code, but I can't do it myself either until about 
1.5 to 2 weeks from now. We have a situation with an app running on "the 
most popular open-source EJB server" which has become intolerable due to 
unreliability in the face of increased usage, and I need to work to move 
my current CVS code to production next week.

Colin


Rod Johnson wrote:

>Colin
>
>When it gets into Spring depends on when I have time to 
>polish it. Basically that means some time in June. It 
>basically works and it's _very_ useful. (I keep thinking of 
>cool things to use it for: I kept boring Juergen and Alef 
>about it on Sunday morning :-) It also needs discussion with 
>at least Juergen about the extensions to the DTD. (100% 
>backward compatible, of course.) And to accommodate the 
>upcoming AspectJ integration in 1.0.3 (new feature but again 
>very useful!) it needs to be implemented in a slightly 
>different, more open way.
>
>If you want to take responsibility for completing it, in 
>conjunction with myself and Juergen to discuss how the slight 
>enhancements to the core IoC stuff should work, that would be 
>great! I could send you the code and tests today. 
>
>That way we will get it for 1.0.3, which would also be great. 
>Of course if you're on HEAD you could be using it by the end 
>of the week... As I said, it already works.
>
>Rgds,
>Rod
>---- Original message ----
>  
>
>>Date: Tue, 11 May 2004 09:05:59 -0400
>>From: Colin Sampaleanu <col...@ex...>  
>>Subject: [Springframework-developer] Prototype handling 
>>    
>>
>support  
>  
>
>>To: spr...@li...
>>
>>Rod,
>>
>>At the TSS Symposium you mentioned having done some code to 
>>    
>>
>allow the 
>  
>
>>appcontext to dynamically modify a class so that a create or 
>>    
>>
>getter 
>  
>
>>method within it could actualy be hooked up to a prototype 
>>    
>>
>bean within 
>  
>
>>the factory. What are your thoughts on adding this code in 
>>    
>>
>at this time? 
>  
>
>>It would actually be of use to me...
>>
>>Colin
>>
>>
>>
>>-------------------------------------------------------
>>This SF.Net email is sponsored by Sleepycat Software
>>Learn developer strategies Cisco, Motorola, Ericsson & 
>>    
>>
>Lucent use to 
>  
>
>>deliver higher performing products faster, at low TCO.
>>http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
>>_______________________________________________
>>Springframework-developer mailing list
>>Spr...@li...
>>https://lists.sourceforge.net/lists/listinfo/springframework-
>>    
>>
>developer
>  
>

Re: [Springframework-developer] minor annoyances

[Tom T. <tom...@pr...>]

Hello Juergen,

Sorry about the late reply :$, but I've tried the changes to
AbstractWizardFromController, and there's something wrong with
the logic in getCurrentPage.

Currently, the page attribute is fetched from the session and cached in
the request on the first call to getCurrentPage; all subsequent calls
will return the value cached in the request. But the session attribute is
later updated (in showPage), so the cached value returned by
getCurrentPage is then wrong.

This results in e.g. the page parameter passed to referenceData being 0
while on page 1.

I have locally changed the implementation into this, which works
correctly:

protected int getCurrentPage(HttpServletRequest request) {
    // get attribute from session
    Integer pageAttr =3D (Integer)
    request.getSession().getAttribute(getPageSessionAttributeName());
    if (pageAttr =3D=3D null) {
        // if attribute removed from session, try to get it from request
        pageAttr =3D (Integer)
        request.getAttribute(getPageSessionAttributeName());
        if (pageAttr =3D=3D null) {
            throw new IllegalStateException("Page attribute [" +
            getPageSessionAttributeName() +
                    "] neither found in session nor in request");
        }
    } else {
        // if attribute present in session...
        if
        (!pageAttr.equals(request.getAttribute(getPageSessionAttributeName(=
))))
        {
            // ...but not (equal) in request, expose in request as well
            request.setAttribute(getPageSessionAttributeName(),
            pageAttr);
        }
    }
    return pageAttr.intValue();
}

Kind regards,
Tom.

On Sun, 2 May 2004 13:09:32 +0200, "j=FCrgen h=F6ller [werk3AT]"
<jue...@we...> said:
> Tom,
>=20=20
> I've just addressed your AbstractWizardFormController issues:
> validatePagesAndFinish checks for page-specific binding errors now, and
> getCurrentPage allows to retrieve the current page at any point in
> request processing. So processFinish still doesn't have a page parameter,
> but you can now invoke getCurrentPage from there.
>=20=20
> Juergen
>=20=20
>=20
> ________________________________
>=20
> Von: spr...@li... im Auftrag von
> Tom Turelinckx
> Gesendet: Mi 28.04.2004 09:38
> An: spr...@li...
> Betreff: [Springframework-developer] minor annoyances
>=20
>=20
>=20
> Hello,
>=20
> While upgrading to spring 1.0.1, I've noticed some minor annoyances that
> may be easy to fix, possibly for 1.0.2:
>=20
> 1. HttpServletBean apparently does not support properties of type
> Resource, because BeanWrapperImpl does not register a Resource property
> editor by default. However, there's no possibility to register custom
> editors with the BeanWrapper used by HttpServletBean. Maybe an
> "initBeanWrapper" protected method could be added here, like initBinder
> in BaseCommandController?
>=20
> 2. Unlike ResourceBundleMessageSource, ResourceBundleViewResolver only
> has a basename property, no basenames property. As we keep controller
> cfg, dao cfg and messages in separate resource files by functional
> domain, it also makes sense to keep the view cfg in different files.
> We're currently using an adapted ResourceBundleViewResolver, but maybe
> this functionality could be added to spring, or maybe there's a good
> reason to keep all view cfg in a single file?
>=20
> 3. In AbstractWizardFormController, it would be useful if processFinish
> had an extra "int submissionPage" parameter (the currentPage value in
> processFormSubmission could be passed to validatePagesAndFinish and on to
> processFinish), though I have no suggestion how to add this in a
> backward-compatible way...
> It would be useful, because some of our legacy stored procedures perform
> validation logic that we can't duplicate in java, i.e. the result of a
> stored procedure could indicate a user-correctable error, which we would
> like to display in the same way as a global validation error, e.g.:
>=20
> protected ModelAndView processFinish( HttpServletRequest request,
>         HttpServletResponse response, Object command,
>         BindException errors, int page ) throws Exception {
>     // stored procedure is called in onSubmit,
>     // messageInfo is an output parameter
>     MessageInfo messageInfo =3D onSubmit( command );
>     if ( messageInfo.isError() ) {
>         errors.reject( "", messageInfo.getMessage() );
>         return showPage( request, errors, page );
>     }
>     if ( messageInfo.isWarning() ) {
>         return handleWarning( command, messageInfo );
>     }
>     return handleSuccess( command, messageInfo );
> }
>=20
> Note that getCurrentPage can't be called in processFinish, as we are
> "after processFormSubmission".
>=20
> Even if the page parameter can't be added to processFinish, it would
> still be useful to add it to validatePagesAndFinish:
>=20
> private ModelAndView validatePagesAndFinish(HttpServletRequest request,
>         HttpServletResponse response, Object command,
>         BindException errors, int currentPage) throws Exception {
>=20
>     // in case of binding errors  -> show current page
>     if (errors.getErrorCount() - errors.getGlobalErrorCount() > 0) {
>         return showPage(request, errors, currentPage);
>     }
>=20
>     for (int page =3D 0; page < pages.length; page++) {
>         validatePage(command, errors, page);
>         // in case of field errors on a page -> show the page
>         if (errors.getErrorCount() - errors.getGlobalErrorCount() > 0) {
>             return showPage(request, errors, page);
>         }
>     }
>     // no field errors -> maybe global errors, or none at all
>     return processFinish(request, response, command, errors,
>     currentPage);
> }
>=20
> The first if was added to ensure the current page is shown again if there
> were binding errors, such as typeMismatch. Otherwise, those errors will
> always result in the first page being shown, instead of the submission
> page where the error actually occured.
>=20
> Also, shouldn't the "if (pages =3D=3D null | pages.length =3D=3D 0)" in s=
etPages
> use "||" instead of "|"?
>=20
> Kind regards,
> Tom.
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle 10g.
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id=3D3149&alloc_id=3D8166&op=3Dclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle 10g.
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Prototype handling support

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

Colin

When it gets into Spring depends on when I have time to 
polish it. Basically that means some time in June. It 
basically works and it's _very_ useful. (I keep thinking of 
cool things to use it for: I kept boring Juergen and Alef 
about it on Sunday morning :-) It also needs discussion with 
at least Juergen about the extensions to the DTD. (100% 
backward compatible, of course.) And to accommodate the 
upcoming AspectJ integration in 1.0.3 (new feature but again 
very useful!) it needs to be implemented in a slightly 
different, more open way.

If you want to take responsibility for completing it, in 
conjunction with myself and Juergen to discuss how the slight 
enhancements to the core IoC stuff should work, that would be 
great! I could send you the code and tests today. 

That way we will get it for 1.0.3, which would also be great. 
Of course if you're on HEAD you could be using it by the end 
of the week... As I said, it already works.

Rgds,
Rod
---- Original message ----
>Date: Tue, 11 May 2004 09:05:59 -0400
>From: Colin Sampaleanu <col...@ex...>  
>Subject: [Springframework-developer] Prototype handling 
support  
>To: spr...@li...
>
>Rod,
>
>At the TSS Symposium you mentioned having done some code to 
allow the 
>appcontext to dynamically modify a class so that a create or 
getter 
>method within it could actualy be hooked up to a prototype 
bean within 
>the factory. What are your thoughts on adding this code in 
at this time? 
>It would actually be of use to me...
>
>Colin
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by Sleepycat Software
>Learn developer strategies Cisco, Motorola, Ericsson & 
Lucent use to 
>deliver higher performing products faster, at low TCO.
>http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-
developer

Re: [Springframework-developer] EBJ 3 and J2EE 1.5

[Tim C. <tc...@ta...>]

Good point Thomas but Spring is not the only container with Setter 
injection ;)

-Tim

tho...@tr... wrote:

>Tim,
>
>I agree that the discussion on The ServerSide has centered around the Entity
>Bean solution, but Linda's presentation did cover a lot more.  She talked a lot
>about Session Beans and Dependency Injection.  Here is a transcript of a few of
>her slides:
>
>Access to Bean's Environment
> - Get JNDI APIs out of developer's view
> - Techniques/mechanisms
>    1)Declarative expression of dependencies in metadata
>    2)Container injection of resource, etc. entries
>    3)Simple programmatic lookup mechanisms
> - Different usages, both have their place
>    2) very simple; facilitates testability (esp. setter injection techniques)
>    3) more flexible; dynamic
>
>Injection
> - Container can initialize instance variables at time bean is made available
> - Setter injection is better technique
>   - Better testability
>   - Can use to inject ejbContext, EntityManager, resources, etc
>   - Considered constructor injection, but found it not as simple / flexible
>
>
>One code example:
>
>@Session public class MySessionBean {
>  private DataSource customerDB;
>
>  @Inject private void setCustomerDB(DataSource customerDB) {
>    customerDB = myDB;
>  }
>
>
>  public void myMethod (String myString) {
>    ...
>    Connection conn = customerDB.getConnection();
>    ...
>  }
>}
>
>I think it looks very familiar :-)
>
>Thomas
>
>
>Quoting Tim Chen <tc...@ta...>:
>
>  
>
>>Jurgen's post quotes:
>>"And there hasn't been a single credit to Spring and co in Linda's=20
>>talk... (but lots and lots of credits to Hibernate)."
>>Of course there is no credit to Spring. Why should there be?
>>The main part of the EJB->Hibernate->EJB 3.0 and EJB 3.0 discussions=20
>>were centered around it's Entity Bean solution.
>>Particularly CMP.
>>
>>"Spring=92s main aim is to make J2EE easier to use and promote good=20
>>programming practice." *
>>It does this by being a POJO/Dependency Injector container. And it does=20
>>it very well. (Otherwise we wouldnt be using it ;)
>>
>>"Hibernate is a powerful, ultra-high performance object/relational=20
>>persistence and query service for Java." **
>>Given that, EJB (at least from the entity side) is closer to Hibernate=20
>>than Spring.
>>EJB is NOT a container.
>>
>>"There's a strong difference in terms of flexibility of deployment: EJB=20
>>3 can by design never match Spring's capability of adapting to all sorts=20
>>of environments, even if adopting the same development model."
>>Again. Why should it?! EJB was never meant to run outside of a non-ejb=20
>>container. You can still use Hibernate for that anyways so who really=20
>>cares? If you chose to use EJB then you've chosen to run in container.=20
>>If you don't want to then it's very simple.. don't use EJBs.
>>
>>"Why oh why does this have to be part of the EJB spec? Why not doing a=20
>>separate O/R mapping spec - no matter if within or outsider the JDO=20
>>scope? There's no technical reason for tying this to an EJB container"
>>I completely disagree. BMP/CMP/EJB has been getting a bad rap for a=20
>>while now due to it's performance issues. It was in fact just plain=20
>>garbage in most cases. So why not fix it? Why create a whole new spec=20
>>and leave the other one in its state? What good does that do anyone?
>>
>>"It is not good enough to have some EJB 3 EntityManager implementations=20
>>that can run outside an EJB container. It's still part of the EJB spec,=20
>>not allowing certification for anything but a complete EJB container=20
>>implementation (which includes the entire EJB 2 model)."
>>I agree with that one. Backwards compatibility with something that was=20
>>intrinsically broken is just a bad idea.
>>
>>-Tim
>>
>>* http://www.theserverside.com/articles/article.tss?l=3DSpringFramework
>>** http://www.hibernate.org/
>>
>>Jeff Boring wrote:
>>
>>    
>>
>>>I agree with most of Juergen's comments about EJB 3=20
>>>(http://blog.hibernate.org/cgi-bin/pollxn.cgi?storypath=3D/Gavin=20
>>>King/ejb3.html).
>>>I'd like to see:
>>>1) Gavin's response
>>>2) Juergen and/or Rod join JSR 244
>>>Has anyone talked with Gavin (Juergen/Rod?) about this. Can you=20
>>>provide a synopsis of what he said? I'd like to believe that he has=20
>>>not completely gone over to the dark side :).
>>>Politics aside, somebody representing this point of view still needs=20
>>>to contribute. We all know that most of what we want will currently be=20
>>>vetoed by the big vendors. However, we should still try and fight for=20
>>>what we can get. Rod is the most qualified from what I know. Rod, can=20
>>>you let us know what is going on in this area? Is there something some=20
>>>of us could do to support you in this effort?
>>>Jeff W. Boring
>>>Impulse Point
>>>      
>>>
>>
>>
>>-------------------------------------------------------
>>This SF.Net email is sponsored by Sleepycat Software
>>Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to
>>deliver higher performing products faster, at low TCO.
>>http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
>>_______________________________________________
>>Springframework-developer mailing list
>>Spr...@li...
>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>    
>>
>
>
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by Sleepycat Software
>Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
>deliver higher performing products faster, at low TCO.
>http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>  
>

Re: [Springframework-developer] EBJ 3 and J2EE 1.5

[Tim C. <tc...@ta...>]

>> For the record, I don't really expect to see a consequence regarding t=
he former point - I just wanted to >> publically note it. They will never=
 credit Spring in public, at least as long as it is not part of JBoss >> =
Group ;-)

hehe are you saying that politics are involved.. no way that would never =
happen ;)

>>The old EJB model, in particular EJB 2.x Entity Beans, will still be ar=
ound - live and kicking, without a single deprecation.

that is true and I don't know why they decided on this other than to say=20
that it is a way to give people upgrading to the new J2EE spec a chance=20
to ease into the transition? /me is always trying to find the good in thi=
ngs

 >> It seems they just don't want to admit that EJB 1.x/2.x Entity Beans=20
have been such a failure, by still calling the new thing "Entity Beans"=20
(even if it's something completely new).

actually I would disagree with this point solely from the pov of someone=20
attending the symposium. many times Gavin had trashed EJB 1.x/2.x and=20
Linda didn't disagree nor did she try to defend it in her own talks. I=20
think they (Sun) have pretty much acknowledged their failure.

-Tim

j=FCrgen h=F6ller [werk3AT] wrote:

>Tim,
>=20
><quote>
>Of course there is no credit to Spring. Why should there be?
>The main part of the EJB->Hibernate->EJB 3.0 and EJB 3.0 discussions
>were centered around it's Entity Bean solution.
>Particularly CMP.
></quote>
>=20
>As Thomas already elaborated, there's also a completely revamped Session=
 Bean model that does imitate Spring's development model, just like EJB 3=
 Entity Beans imitate Hibernate respectively HQL. Why give repeated expli=
cit credits to Hibernate but not a single one to Spring (or any other con=
crete lightweight container product)?
>=20
><quote>
>"Why oh why does this have to be part of the EJB spec? Why not doing a
>separate O/R mapping spec - no matter if within or outsider the JDO
>scope? There's no technical reason for tying this to an EJB container"
>I completely disagree. BMP/CMP/EJB has been getting a bad rap for a
>while now due to it's performance issues. It was in fact just plain
>garbage in most cases. So why not fix it? Why create a whole new spec
>and leave the other one in its state? What good does that do anyone?
></quote>
>=20
>The old EJB model, in particular EJB 2.x Entity Beans, will still be aro=
und - live and kicking, without a single deprecation. I don't see the poi=
nt in adding a completely new POJO persistence model to the EJB spec: It =
could simply refer to a separate O/R mapping spec (whether JDO or a new o=
ne) instead, allowing the latter to address any environment (rather than =
just EJB), and allowing persistence tool vendors to implement it (rather =
than just EJB container vendors).
>=20
>=20
>For the record, I don't really expect to see a consequence regarding the=
 former point - I just wanted to publically note it. They will never cred=
it Spring in public, at least as long as it is not part of JBoss Group ;-=
)
>=20
>I have a pretty strong opinion regarding the latter point, though. There=
 isn't a single technical reason for a completely new O/R mapping spec as=
 part of EJB 3. It seems they just don't want to admit that EJB 1.x/2.x E=
ntity Beans have been such a failure, by still calling the new thing "Ent=
ity Beans" (even if it's something completely new).
>=20
>Juergen
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by Sleepycat Software
>Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to=20
>deliver higher performing products faster, at low TCO.
>http://www.sleepycat.com/telcomwpreg.php?From=3Ddnemail3
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
> =20
>

Re: [Springframework-developer] EBJ 3 and J2EE 1.5

[Tim C. <tc...@ta...>]

>> Why is one approach a Java Specification while the other one is not?
I think Gavin alluded to this in his talk when he answered a question about the future of hibernate.
Hibernate is and will be a place to try new cutting edge methods.
Specs were never meant to be cutting edge. A spec is and should be something that has been tried and tested.
Hibernate (and other open source projects in general) allows for the new features to be tested.

>> What so magically about the EJB approach that it has it's own [container implementation] specification?
Containers require J2EE certification and J2EE certification = revenue for Sun? ;)
Besides.. rememeber that EJBs also deals with many other facets that Hibernate doesn't have to deal with.
ex. There is no session bean concept in Hibernate.

-Tim

Jeff Boring wrote:

>>EJB was never meant to run outside of a non-ejb container. <
>>    
>>
>
>Hum... but you are mixing specification with implementation. 
>
>
>  
>
>>You can still use Hibernate for that anyways so who really cares? If
>>    
>>
>you chose to use EJB then you've chosen to run in container. If you
>don't want to then it's very simple.. don't use EJBs. <
>
>Why is one approach a Java Specification while the other one is not?
>What so magically about the EJB approach that it has it's own [container
>implementation] specification?
>
>Jeff W. Boring
>Impulse Point
>jb...@im...
> 
>
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...] On Behalf
>Of Tim Chen
>Sent: Monday, May 10, 2004 3:56 PM
>To: spr...@li...
>Subject: Re: [Springframework-developer] EBJ 3 and J2EE 1.5
>
>
>Jurgen's post quotes:
>"And there hasn't been a single credit to Spring and co in Linda's 
>talk... (but lots and lots of credits to Hibernate)."
>Of course there is no credit to Spring. Why should there be? The main
>part of the EJB->Hibernate->EJB 3.0 and EJB 3.0 discussions 
>were centered around it's Entity Bean solution.
>Particularly CMP.
>
>"Spring's main aim is to make J2EE easier to use and promote good 
>programming practice." *
>It does this by being a POJO/Dependency Injector container. And it does 
>it very well. (Otherwise we wouldnt be using it ;)
>
>"Hibernate is a powerful, ultra-high performance object/relational 
>persistence and query service for Java." **
>Given that, EJB (at least from the entity side) is closer to Hibernate 
>than Spring.
>EJB is NOT a container.
>
>"There's a strong difference in terms of flexibility of deployment: EJB 
>3 can by design never match Spring's capability of adapting to all sorts
>
>of environments, even if adopting the same development model." Again.
>Why should it?! EJB was never meant to run outside of a non-ejb 
>container. You can still use Hibernate for that anyways so who really 
>cares? If you chose to use EJB then you've chosen to run in container. 
>If you don't want to then it's very simple.. don't use EJBs.
>
>"Why oh why does this have to be part of the EJB spec? Why not doing a 
>separate O/R mapping spec - no matter if within or outsider the JDO 
>scope? There's no technical reason for tying this to an EJB container" I
>completely disagree. BMP/CMP/EJB has been getting a bad rap for a 
>while now due to it's performance issues. It was in fact just plain 
>garbage in most cases. So why not fix it? Why create a whole new spec 
>and leave the other one in its state? What good does that do anyone?
>
>"It is not good enough to have some EJB 3 EntityManager implementations 
>that can run outside an EJB container. It's still part of the EJB spec, 
>not allowing certification for anything but a complete EJB container 
>implementation (which includes the entire EJB 2 model)."
>I agree with that one. Backwards compatibility with something that was 
>intrinsically broken is just a bad idea.
>
>-Tim
>
>* http://www.theserverside.com/articles/article.tss?l=SpringFramework
>** http://www.hibernate.org/
>
>Jeff Boring wrote:
>
>  
>
>>I agree with most of Juergen's comments about EJB 3
>>(http://blog.hibernate.org/cgi-bin/pollxn.cgi?storypath=/Gavin 
>>King/ejb3.html).
>>I'd like to see:
>>1) Gavin's response
>>2) Juergen and/or Rod join JSR 244
>>Has anyone talked with Gavin (Juergen/Rod?) about this. Can you 
>>provide a synopsis of what he said? I'd like to believe that he has 
>>not completely gone over to the dark side :).
>>Politics aside, somebody representing this point of view still needs 
>>to contribute. We all know that most of what we want will currently be
>>    
>>
>
>  
>
>>vetoed by the big vendors. However, we should still try and fight for 
>>what we can get. Rod is the most qualified from what I know. Rod, can 
>>you let us know what is going on in this area? Is there something some
>>    
>>
>
>  
>
>>of us could do to support you in this effort?
>>Jeff W. Boring
>>Impulse Point
>>    
>>
>
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by Sleepycat Software
>Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
>deliver higher performing products faster, at low TCO.
>http://www.sleepycat.com/telcomwpreg.php?From=dnemail3
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by Sleepycat Software
>Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
>deliver higher performing products faster, at low TCO.
>http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>  
>

[Springframework-developer] Simple (useful?) extension - HierarchicalListFactoryBean

[neuro <ne...@ka...>]

Hello spring developers,

Before spring I'm used WebWork2 in few projects. Spring can do everything
what WW2 can but Spring's generic config files seem little verbose and
lack some nice features what one can find in more focused framework.
I've developed some helper objects to make my configuration cleaner.

If anyone interested I've continue to share my expirience, and
of course I'll be happy to see some of my work will be so useful that
it will be integrated into Spring codebase.
I've do my best to keep stuff as much simple as useful. 8)

One of that is HierarchicalListFactoryBean (extends Spring ListFactoryBean).
It will prepend contents of parentList to its factored List.
IMHO this is is useful addition wich fits perfectly.

It is very nice for HandlerInterceptors (almost like nice ww2 Interceptor
stacks).

Example usage with HandlerInterceptors:
We define "defaultInterceptorList" to reuse and extend it in many
HandlerMappings... neat!

--------- snip servlet-context.xml { ---------
<bean id="defaultInterceptorList" class="org.springframework.beans.factory.config.ListFactoryBean">
    <property name="sourceList">
        <list>
            <ref local="webContentInterceptor"/>
            <ref local="themeChangeInterceptor"/>
            <ref local="localeChangeInterceptor"/>
        </list>
    </property>
</bean>

<bean id="freeUrlMapping" class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping">
    <property name="interceptors">
        <ref local="defaultInterceptorList"/>
    </property>
    .... urlMap, etc
</bean>

<bean id="protectedUrlMapping" class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping">
    <property name="interceptors">
        <bean id="protectedInterceptorList" class="neuro.util.spring.HierarchicalListFactoryBean">
            <property name="parentList"><ref local="defaultInterceptorList"/></property>
            <property name="sourceList">
                <list>
                    <ref local="protectionHandlerInterceptor"/>
                </list>
            </property>
        </bean>
    </property>
    .... urlMap, etc
</bean>
--------- } snip servlet-context.xml ---------

HierarchicalListFactoryBean source is in the attach.

Obiviously, there can be HierarchicalMapFactoryBean and
HierarchicalSetFactoryBean with same behaviour.

//regards, neuro