springframework-developer — Spring Framework developers list

Re: [Springframework-developer] spring ldap - extending DirContextAdapter

[Ulrik S. <ulr...@ja...>]

Thanks, Petr.

We will take this under consideration. We have a splendid forum for  
these kinds of questions:

http://forum.springframework.org/forumdisplay.php?f=40

Please post a thread there, and we can continue the discussion.

--
Ulrik Sandberg
Spring LDAP



> Hi,
> I would like to post spring-ldap team my extension of  
> DirContextAdapter.
> When item in the ldap is not set, method context.getStringAttribute  
> throw
> exception NullPointerException. In practise application is it  
> obstruction.
>
> When getStringAttribute throw exception, method get default value.  
> You can
> get other the string values such as double,boolean, long, int.
>
> This is source code of extension.
>
> ---
>
> package net.itsynapse2.utils.data;
>
> import org.springframework.ldap.support.DirContextAdapter;
>
> public class DirContextAdapterImpl extends DirContextAdapter {
>      public String getStringAttribute(String attrName, String  
> defaultValue)
> {
>          String result = defaultValue;
>
>          try {
>              result = getStringAttribute(attrName);
>          } catch(java.lang.NullPointerException npe) {}
>
>          return result;
>      }
>      public boolean getBooleanAttribute(String attrName, boolean
> defaultValue) {
>          boolean result = defaultValue;
>
>          try {
>              result = Boolean.parseBoolean(getStringAttribute 
> (attrName));
>          } catch(java.lang.NullPointerException npe) {}
>
>          return result;
>      }
>      public long getIntegerAttribute(String attrName, int  
> defaultValue) {
>          int result = defaultValue;
>
>          try {
>              result = Integer.parseInt(getStringAttribute(attrName));
>          } catch(java.lang.NullPointerException npe) {}
>
>          return result;
>
>      }
>      public long getLongAttribute(String attrName, long  
> defaultValue) {
>          long result = defaultValue;
>
>          try {
>              result = Long.parseLong(getStringAttribute(attrName));
>          } catch(java.lang.NullPointerException npe) {}
>
>          return result;
>
>      }
>      public double getDoubleAttribute(String attrName, double  
> defaultValue)
> {
>          double result = defaultValue;
>
>          try {
>              result = Double.parseDouble(getStringAttribute 
> (attrName));
>          } catch(java.lang.NullPointerException npe) {}
>
>          return result;
>      }
>
> }
>
> -- 
> Petr Burdik
>
> ---------------------------------------------------------------------- 
> ---
> Using Tomcat but need to do more? Need to support web services,  
> security?
> Get stuff done quickly with pre-integrated technology to make your  
> job easier.
> Download IBM WebSphere Application Server v.1.0.1 based on Apache  
> Geronimo
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

[Springframework-developer] spring ldap - extending DirContextAdapter

[Petr B. <pe...@it...>]

Hi,
I would like to post spring-ldap team my extension of DirContextAdapter.=
  =

When item in the ldap is not set, method context.getStringAttribute thro=
w  =

exception NullPointerException. In practise application is it obstructio=
n.

When getStringAttribute throw exception, method get default value. You c=
an  =

get other the string values such as double,boolean, long, int.

This is source code of extension.

---

package net.itsynapse2.utils.data;

import org.springframework.ldap.support.DirContextAdapter;

public class DirContextAdapterImpl extends DirContextAdapter {
     public String getStringAttribute(String attrName, String defaultVal=
ue)  =

{
         String result =3D defaultValue;

         try {
             result =3D getStringAttribute(attrName);
         } catch(java.lang.NullPointerException npe) {}

         return result;
     }
     public boolean getBooleanAttribute(String attrName, boolean  =

defaultValue) {
         boolean result =3D defaultValue;

         try {
             result =3D Boolean.parseBoolean(getStringAttribute(attrName=
));
         } catch(java.lang.NullPointerException npe) {}

         return result;
     }
     public long getIntegerAttribute(String attrName, int defaultValue) =
{
         int result =3D defaultValue;

         try {
             result =3D Integer.parseInt(getStringAttribute(attrName));
         } catch(java.lang.NullPointerException npe) {}

         return result;

     }
     public long getLongAttribute(String attrName, long defaultValue) {
         long result =3D defaultValue;

         try {
             result =3D Long.parseLong(getStringAttribute(attrName));
         } catch(java.lang.NullPointerException npe) {}

         return result;

     }
     public double getDoubleAttribute(String attrName, double defaultVal=
ue)  =

{
         double result =3D defaultValue;

         try {
             result =3D Double.parseDouble(getStringAttribute(attrName))=
;
         } catch(java.lang.NullPointerException npe) {}

         return result;
     }

}

-- =

Petr Burdik

[Springframework-developer] Should DisposableBeanAdapter be Serializable and potencial for double destruction

[Michael Y. <yo...@gm...>]

1.  Would DisposableBeanAdapter and
ServletRequestAttributes.DestructionCallbackBindingListener not being
Serializable cause any problems?  Since it would not survive the
session being persisted or being distributed in a cluster?  The
BeanPostProcessors would need to be Serializable but the programmer
would probably have more control over that.  What do you think?

2. When a scope is registered it registers a DisposableBeanAdapter as
a destruction callback.  The Scope.remove method is called by
AbstractBeanFactory.destroyScopedBean which in ture calls destroyBean
with calls destroy on a DisposableBeanAdapter.  So is it part of the
contract for Scope.remove to not call the destroy callback?

Mike

[Springframework-developer] Spring build.87 SUCCEEDED

[<bu...@in...>]

Snapshot has been uploaded to http://www.springframework.org/snaphots
    			
The list of modifications for this build can be found in the build log (http://static.springframework.org/spring/build/index.html).    			
			

Re: [Springframework-developer] your humme

[Selene S. <sh...@ya...>]

Hi,

If you have a problem getting or keeping an erection, 
your sexlife can suffer. You should know that you're not alone. 

In fact, more than half of all men over 40 have difficulties 
getting or maintaining an erection. This issue, also called 
erectile dysfunction, occurs with younger men as well.

You should know there is something you can do about it.

http://parkerokaynow.*com
( Important! Remove "*" )

--
strict Ministry guidelines. But unless you watch your step, you might
just find that my hand slips  he shook the crystal bottle
slightly  right over your evening pumpkin juice. And then. Potter...

[Springframework-developer] Spring build.86 SUCCEEDED

[<bu...@in...>]

Snapshot has been uploaded to http://www.springframework.org/snaphots
    			
The list of modifications for this build can be found in the build log (http://static.springframework.org/spring/build/index.html).    			
			

[Springframework-developer] Spring build.85 SUCCEEDED

[<bu...@in...>]

Snapshot has been uploaded to http://www.springframework.org/snaphots
    			
The list of modifications for this build can be found in the build log (http://static.springframework.org/spring/build/index.html).    			
			

[Springframework-developer] Spring build.84 SUCCEEDED

[<bu...@in...>]

Snapshot has been uploaded to http://www.springframework.org/snaphots
    			
The list of modifications for this build can be found in the build log (http://static.springframework.org/spring/build/index.html).    			
			

[Springframework-developer] Spring build.83 SUCCEEDED

[<bu...@in...>]

Snapshot has been uploaded to http://www.springframework.org/snaphots
    			
The list of modifications for this build can be found in the build log (http://static.springframework.org/spring/build/index.html).    			
			

[Springframework-developer] Spring build.82 SUCCEEDED

[<bu...@in...>]

Snapshot has been uploaded to http://www.springframework.org/snaphots
    			
The list of modifications for this build can be found in the build log (http://static.springframework.org/spring/build/index.html).    			
			

[Springframework-developer] Spring build.81 SUCCEEDED

[<bu...@in...>]

Snapshot has been uploaded to http://www.springframework.org/snaphots
    			
The list of modifications for this build can be found in the build log (http://static.springframework.org/spring/build/index.html).    			
			

Re: [Springframework-developer] [Springframework-user] Annotation-based Spring Configuration

[Chris N. <C.N...@AB...>]

Thanks for the reply. You are the only one so far, which I think answers
my question to the demand for such a feature...

I'm not religious about this subject - there are various alternative
ways of configuring Spring these days and each have their pros and cons.
I discussed this very briefly with Alef and Arjen after their JavaPolis
talk - they were unable to offer a solution to code and configuration
getting out of synch (but suggested we added extra tests to our
testsuite).

Our experience with the team repeatedly getting code and Spring
configuration out of synch (at which point Spring won't even start up
and no other developer can do any work) points to the principle of DRY
(don't repeat yourself) being a valuable one. My opinion is that having
separate POJO code and XML configuration *is* repeating yourself,
however that seems to be a minority opinion!

My prototyped solution allows use of user-defined annotations, in which
case no dependency on Spring code is introduced. In principle such POJOs
could be ported to an alternative IoC container without any changes, if
it could also understand the user-defined annotations as well.

I also try to be pragmatic about how truly "portable" POJOs are, and how
useful it is that they are portable. Using IoC features (e.g. setter
injection) ties the code to the subset of IoC containers that support
those features, even if Spring-specific APIs aren't being called. If
Spring MVC or Spring Transaction Annotations are being used, then
obviously that is a dependency on Spring. If you wanted to move from
Spring to an alternative IoC container, or to a completely different
approach (e.g. EJB 3), you are bound to have to review all the code and
change a substantial portion of it.=20

As an Architect I think in layers, so I think it's much more important
to prevent hide the internal implementation details of one layer from
other layers than it is to isolate implementation details inside a
layer. My experience tells me that it is much more common to
re-implement a layer (e.g. moving from JSP to JSF, or iBATIS to
Hibernate) than it is to move an entire application away from Spring. I
welcome any feedback from anyone else that has experience of regularly
porting applications between different POJO frameworks?

We currently use Spring 1.x, Java 1.4 and XDoclet with our own
sub-classed Jakarta Commons Attributes (so no Spring API dependency) for
Transaction demarcation, and our own utility class for obscure
situations where we have to do an explicit dependency lookup (again
hiding the Spring APIs). We put as much Spring configuration as possible
in XDoclet annotations, so our XML configuration just contains:

- "infrastructure" beans (e.g. MVC configuration, DataSources etc)
- abstract beans (e.g. common configuration for all our iBATIS DAOs)
- anything with complex configuration that can't be expressed in XDoclet
(e.g. we have a complex XML processing pipeline with various lists of
lists of beans)

Our experience is that the XDoclet-based configuration is based on our
application's functionality and never tends to change, whereas the XML
configuration is the "plumbing" that does tend to change over time.=20

Chris.

-----Original Message-----
From: Axel Wienberg [mailto:axe...@go...]=20
Sent: 31 January 2007 07:40
To: Chris Nappin
Subject: Re: [Springframework-user] Annotation-based Spring
Configuration

There doesn't seem to be much discussion going on on the list, so I'll
try direct email :-)

My understanding so far is that beans (Java source) should be
reusable, and the spring config defines the wiring. Annotations seem
to mix up this distinction - how would you instantiate the same class
(java source) twice, with different property settings?

For bean properties like initMethod and destroyMethod, if you are
willing to edit your source file, you might as well implement
InitializableBean and DisposableBean. You'll have a spring dependency
either way (annotations can be ignored, but your application will not
work if the annotations are not interpreted).

We're currently using the IDE to connect XML config and Java code - in
IntelliJ Idea, "find usages" on a class will also find occurrences in
a spring XML file, and likewise for property setters, and conversely
for "goto definition".

It could be that your Controller code is very application specific
anyway, so reusability in other configurations is not an issue. Is
that so? I'd be curious to learn when you feel the wiring should be
integrated into the code.

Regards,
Axel

2007/1/30, Chris Nappin <C.N...@ab...>:
> I've been working on an Annotation-based Spring Configuration solution
which
> I'd be happy to donate to the Spring project, so I wanted to determine
> whether there is any interest?
>
>  Such initiatives seem to have received a cool reception in the past,
e.g.
>
http://opensource.atlassian.com/projects/spring/browse/SPR-1987?page=3Dal=
l
.
>
>  I'm an Architect working with a mainly junior development team, and
when we
> first started using Spring we quickly came across the problem of
keeping the
> XML configuration files in step with the code. As we were already
using
> XDoclet for J2EE configuration, we moved to using that for Spring
> configuration as well. It has served us as a very good solution for a
couple
> of years now.
>
>  We're now looking to move to Spring 2.x and Java 5, and it makes
great
> sense for us to use type-safe Annotations instead of XDoclet (which
seems to
> be a dying project). I've put together a prototype that allows for
custom
> (e.g. user-defined) annotations to be used (so no dependency on Spring
code
> is introduced to the POJOs). The default annotations work as follows:
>
>  @Bean(id=3D"createNewPerson")
>  @BaseProperties({
>      @Property(name=3D"formView", value=3D"createPerson"),
>      @Property(name=3D"successView", value=3D"createSucceeded")
>
> })
>  public class CreateNewPersonController extends SimpleFormController {
>
>      @Property(ref=3D"personService")
>      public void setPersonService(PersonService service) {
>          ...
>      }
>  }
>
>  Properties can be configured by annotating the setter method,
base-class
> properties can be added to the class declaration, and so on. I'm
working on
> fleshing out support for all Spring features. I'd be happy for the
shape of
> these default annotations to be further discussed.
>
>  All this is enabled via adding one class (a BeanFactoryPostProcessor)
to
> the XML configuration. XML and Annotation-based configuration can be
mixed
> without restriction - typically just the abtract and "plumbing" bean
> configuration is required in XML.
>
>  Please let me know if this is of interest. I would imagine it would
be a
> useful feature for all existing XDoclet users?
>
>
>
> (PS. All code has been written on my own time and has no relation with
my
> employer)
>
>
>
> Chris Nappin.
>
>
>
> CONFIDENTIALITY NOTICE
>
> This e-mail is confidential to the addressee. It may also be
privileged.
> Neither the confidentiality nor any privilege attaching to this e-mail
is
> waived lost or destroyed by reason that it has been mistakenly
transmitted
> to a person or entity other than the addressee. If you are not the
addressee
> please notify us immediately by telephone or fax at the numbers
provided
> above or e-mail by Reply To Author and return the printed e-mail to us
by
> post at our expense. We believe, but do not warrant, that this e-mail
and
> any attachments are virus-free, but you should check. We may monitor
traffic
> data of both business and personal e-mails. We are not liable for any
> opinions expressed by the sender where this is a non-business e-mail.
If you
> do not receive all the message, or if you have difficulty with the
> transmission, please telephone us immediately.
>
> ABM United Kingdom Ltd
>
> Registered in England & Wales, number 03319098
>
> Registered Office: Peterbridge House, 3 The Lakes, Northampton, UK.
NN4 &HB
>
> ABM America Inc
>
> Registered in Delaware, number 03174068
>
> Registered Office: 1220 N Market Street, Wilmington, Delaware, USA.
19801
>
>
>
------------------------------------------------------------------------
-
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to
share your
> opinions on IT & business topics through brief surveys - and earn cash
>
http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D=
DEVDE
V
>
> _______________________________________________
> Springframework-user mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-user
>
>
>


CONFIDENTIALITY NOTICE

This e-mail is confidential to the addressee. It may also be privileged. =
Neither the confidentiality nor any privilege attaching to this e-mail is=
=20waived lost or destroyed by reason that it has been mistakenly transmi=
tted to a person or entity other than the addressee. If you are not the a=
ddressee please notify us immediately by telephone or fax at the numbers =
provided above or e-mail by Reply To Author and return the printed e-mail=
=20to us by post at our expense. We believe, but do not warrant, that thi=
s e-mail and any attachments are virus-free, but you should check. We may=
=20monitor traffic data of both business and personal e-mails. We are not=
=20liable for any opinions expressed by the sender where this is a non-bu=
siness e-mail. If you do not receive all the message, or if you have diff=
iculty with the transmission, please telephone us immediately.
ABM United Kingdom Ltd
Registered in England & Wales, number 03319098
Registered Office: Peterbridge House, 3 The Lakes, Northampton, UK. NN4 &=
HB
ABM America Inc
Registered in Delaware, number 03174068
Registered Office: 1220 N Market Street, Wilmington, Delaware, USA. 19801=

[Springframework-developer] Spring build.80 SUCCEEDED

[<bu...@in...>]

Snapshot has been uploaded to http://www.springframework.org/snaphots
    			
The list of modifications for this build can be found in the build log (http://static.springframework.org/spring/build/index.html).    			
			

[Springframework-developer] Annotation-based Spring Configuration

[Chris N. <C.N...@AB...>]

I've been working on an Annotation-based Spring Configuration solution
which I'd be happy to donate to the Spring project, so I wanted to
determine whether there is any interest?=20

Such initiatives seem to have received a cool reception in the past,
e.g.=20
http://opensource.atlassian.com/projects/spring/browse/SPR-1987?page=3Dal=
l
.=20

I'm an Architect working with a mainly junior development team, and when
we first started using Spring we quickly came across the problem of
keeping the XML configuration files in step with the code. As we were
already using XDoclet for J2EE configuration, we moved to using that for
Spring configuration as well. It has served us as a very good solution
for a couple of years now.=20

We're now looking to move to Spring 2.x and Java 5, and it makes great
sense for us to use type-safe Annotations instead of XDoclet (which
seems to be a dying project). I've put together a prototype that allows
for custom (e.g. user-defined) annotations to be used (so no dependency
on Spring code is introduced to the POJOs). The default annotations work
as follows:=20

@Bean(id=3D"createNewPerson")=20
@BaseProperties({=20
=20   @Property(name=3D"formView", value=3D"createPerson"),=20
=20   @Property(name=3D"successView", value=3D"createSucceeded")

})=20
public class CreateNewPersonController extends SimpleFormController {=20

=20   @Property(ref=3D"personService")=20
=20   public void setPersonService(PersonService service) {=20
=20       ...=20
=20   }=20
}=20

Properties can be configured by annotating the setter method, base-class
properties can be added to the class declaration, and so on. I'm working
on fleshing out support for all Spring features. I'd be happy for the
shape of these default annotations to be further discussed.=20

All this is enabled via adding one class (a BeanFactoryPostProcessor) to
the XML configuration. XML and Annotation-based configuration can be
mixed without restriction - typically just the abtract and "plumbing"
bean configuration is required in XML.=20

Please let me know if this is of interest. I would imagine it would be a
useful feature for all existing XDoclet users?

=20

(PS. All code has been written on my own time and has no relation with
my employer)

=20

Chris Nappin.

=20


CONFIDENTIALITY NOTICE

This e-mail is confidential to the addressee. It may also be privileged. =
Neither the confidentiality nor any privilege attaching to this e-mail is=
=20waived lost or destroyed by reason that it has been mistakenly transmi=
tted to a person or entity other than the addressee. If you are not the a=
ddressee please notify us immediately by telephone or fax at the numbers =
provided above or e-mail by Reply To Author and return the printed e-mail=
=20to us by post at our expense. We believe, but do not warrant, that thi=
s e-mail and any attachments are virus-free, but you should check. We may=
=20monitor traffic data of both business and personal e-mails. We are not=
=20liable for any opinions expressed by the sender where this is a non-bu=
siness e-mail. If you do not receive all the message, or if you have diff=
iculty with the transmission, please telephone us immediately.
ABM United Kingdom Ltd
Registered in England & Wales, number 03319098
Registered Office: Peterbridge House, 3 The Lakes, Northampton, UK. NN4 &=
HB
ABM America Inc
Registered in Delaware, number 03174068
Registered Office: 1220 N Market Street, Wilmington, Delaware, USA. 19801=

[Springframework-developer] Spring build.79 SUCCEEDED

[<bu...@in...>]

Snapshot has been uploaded to http://www.springframework.org/snaphots
    			
The list of modifications for this build can be found in the build log (http://static.springframework.org/spring/build/index.html).    			
			

[Springframework-developer] (no subject)

[Don H. <jus...@gm...>]

[Springframework-developer] Spring build.78 SUCCEEDED

[<bu...@in...>]

Snapshot has been uploaded to http://www.springframework.org/snaphots
    			
The list of modifications for this build can be found in the build log (http://static.springframework.org/spring/build/index.html).    			
			

[Springframework-developer] Spring build.77 SUCCEEDED

[<bu...@in...>]

Snapshot has been uploaded to http://www.springframework.org/snaphots
    			
The list of modifications for this build can be found in the build log (http://static.springframework.org/spring/build/index.html).    			
			

[Springframework-developer] Spring build.76 SUCCEEDED

[<bu...@in...>]

Snapshot has been uploaded to http://www.springframework.org/snaphots
    			
The list of modifications for this build can be found in the build log (http://static.springframework.org/spring/build/index.html).    			
			

[Springframework-developer] Spring build.75 SUCCEEDED

[<bu...@in...>]

Snapshot has been uploaded to http://www.springframework.org/snaphots
    			
The list of modifications for this build can be found in the build log (http://static.springframework.org/spring/build/index.html).    			
			

[Springframework-developer] Spring build.74 SUCCEEDED

[<bu...@in...>]

Snapshot has been uploaded to http://www.springframework.org/snaphots
    			
The list of modifications for this build can be found in the build log (http://static.springframework.org/spring/build/index.html).    			
			

Re: [Springframework-developer] BridgeMethodResolver does not like large hierarchy

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

Thanks for pointing this out, Serge. I've fixed this in CVS HEAD; the fix
should be available in the next 2.0.3 snapshot.

Juergen
 

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf
Of Serge Bogatyrjov
Sent: Thursday, January 25, 2007 1:54 PM
To: spring-dev
Subject: [Springframework-developer] BridgeMethodResolver does not likelarge
hierarchy

There is a closed issue
http://opensource.atlassian.com/projects/spring/browse/SPR-2648. But the
problem still alive. The file contains a test case.

This bug appears only when I building with sun jdk compiler. If you will
build the project  from eclipse, then the test will execute successfully. To
get the real result use "mvn clean test".

I have found that the problem arises when the long hierarchy is used (more
then two chains from bean class to some parent class or interface with
generics).


Serge Bogatyrjov.

[Springframework-developer] Spring build.73 SUCCEEDED

[<bu...@in...>]

Snapshot has been uploaded to http://www.springframework.org/snaphots
    			
The list of modifications for this build can be found in the build log (http://static.springframework.org/spring/build/index.html).    			
			

[Springframework-developer] spring-hibernate integration with DispatcherServlet

[aussiestaceus <aus...@ya...>]

I am having a very peculiar problem and I was hoping all the Spring Gurus
would have a simple answer for it.

Problem: Transactions are not run properly when service is called as bean in
the DispatcherServlet. Therefore no transaction checks are done on my
hibernate-dao calls.

Here are my config files:
1-applicationContext.xml
[CODE]<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN"
"http://www.springframework.org/dtd/spring-beans.dtd">

<!--
  - Application context definition for Express on Hibernate.
	-->
<beans>


    <bean id="exampleDataSource"
class="org.apache.commons.dbcp.BasicDataSource">
		<property
name="driverClassName"><value>org.apache.derby.jdbc.EmbeddedDriver</value></property>
        <property
name="url"><value>jdbc:derby:springexample;create=true</value></property>
	</bean> 
	
	<bean id="exampleHibernateProperties"
class="org.springframework.beans.factory.config.PropertiesFactoryBean">
		<property name="properties">
			<props>
				<prop key="hibernate.hbm2ddl.auto">update</prop>
				<prop
key="hibernate.dialect">net.sf.hibernate.dialect.DerbyDialect</prop>
				<prop key="hibernate.query.substitutions">true 'T', false 'F'</prop>
				<prop key="hibernate.show_sql">true</prop>
				<prop key="hibernate.c3p0.minPoolSize">5</prop>
				<prop key="hibernate.c3p0.maxPoolSize">20</prop>
				<prop key="hibernate.c3p0.timeout">600</prop>
				<prop key="hibernate.c3p0.max_statement">50</prop>
				<prop key="hibernate.c3p0.testConnectionOnCheckout">false</prop>
			</props>
		</property>
	</bean>
	
	

	<!-- Hibernate SessionFactory -->
	<bean id="exampleSessionFactory"
class="org.springframework.orm.hibernate.LocalSessionFactoryBean">
		<property name="dataSource"><ref local="exampleDataSource"/></property>
		<property name="hibernateProperties">
			<ref bean="exampleHibernateProperties" />
		</property>
		<!-- Must references all OR mapping files. -->
		<property name="mappingResources">
			<list>
		        <value>Customer.hbm.xml</value>
		         <value>Account.hbm.xml</value>
		   	</list>
		</property>
		
		
	</bean>
	
	<!-- Pass the session factory to our UserDAO -->
	<bean id="customerDAOTarget"
class="springexample.hibernate.CustomerDAOImpl">
		<property name="sessionFactory"><ref
local="exampleSessionFactory"/></property>
	</bean>
	
		
    <bean id="transactionManager"
class="org.springframework.orm.hibernate.HibernateTransactionManager">
       <property name="sessionFactory"><ref
bean="exampleSessionFactory"/></property>
    </bean>

    <bean id="userService"
     
class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean">
		<property name="transactionManager"><ref
local="transactionManager"/></property>
		<property name="target"><ref local="customerDAOTarget"/></property>
		<property name="transactionAttributes">
			<props>
				<prop key="get*">PROPAGATION_REQUIRED,readOnly</prop>
				<prop key="save*">PROPAGATION_REQUIRED</prop>
				<prop key="update*">PROPAGATION_REQUIRED</prop>
				<prop key="delete*">PROPAGATION_REQUIRED</prop>
				<prop key="search*">PROPAGATION_REQUIRED,readOnly</prop>
				<prop key="find*">PROPAGATION_REQUIRED,readOnly</prop>
			</props>
		</property>
	</bean>
	
	
	
</beans>
[/CODE]

2-webapp-servlet.xml
[CODE]<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN"
"http://www.springframework.org/dtd/spring-beans.dtd">

<beans>	

	<bean id="urlMapping"
	
class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping[COLOR="Red"][/COLOR]">
		<property name="mappings">
			<props>
				<prop key="/userService.rpc">userService</prop>
			</props>
		</property>
	</bean>
</beans>
[/CODE]
[COLOR="Red"]As you can see I am refrencing the 'userService' bean from my
applicationContext in my DispatcherServlet. The reason for doing this is so
I can make RPC calls straight to the server over HTTP. Furthermore I want to
avoid the need to make a controller class that makes simple pass-thru calls
to my userService, especially when there is no need.(i.e UserLogic
userService =
(UserLogic)WebApplicationContextUtils.getRequiredWebApplicationContext(this.getServletContext()).getBean("userService");[/COLOR]

3-web.xml
[CODE]<?xml version="1.0" encoding="ISO-8859-1"?>

<!DOCTYPE web-app
    PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
    "http://java.sun.com/dtd/web-app_2_3.dtd">

<web-app>

  <servlet>
   <servlet-name>webapp</servlet-name>  
   
<servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
   <load-on-startup>2</load-on-startup>
   </servlet>


 <servlet-mapping>
 	<servlet-name>webapp</servlet-name>
 	<url-pattern>*.rpc</url-pattern>
 </servlet-mapping>

 	<listener>
  	
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
	</listener>

	 <!--Hibernate Filter -->
	<filter>
		<filter-name>hibernateFilter</filter-name>
	
<filter-class>org.springframework.orm.hibernate3.support.OpenSessionInViewFilter</filter-class>
	</filter>
	
	<!--Hibernate Mapping-->
	<filter-mapping>
		<filter-name>hibernateFilter</filter-name>
		<url-pattern>*.rpc</url-pattern>
	</filter-mapping>

  
</web-app>
[/CODE]

Ok so after loads of testing I have figured out for the transactions to
work, I cant just reference the bean in the DispatcherServlet config file. I
have to get the bean from the context, specifically I need to have
<UserLogic userService
=(UserLogic)WebApplicationContextUtils.getRequiredWebApplicationContext(this.getServletContext()).getBean("userService")>.

Otherwise you start getting the following errors because Spring doesn't
invoke AOP transactions for the method being called.
[CODE]org.springframework.dao.InvalidDataAccessApiUsageException: Write
operations are not allowed in read-only mode (FlushMode.NEVER) - turn your
Session into FlushMode.AUTO or remove 'readOnly' marker from transaction
definition[/CODE]


So any ideas as far as referncing the service from the applicationContext
and still have the TransactionProxyFactoryBean work as intended.

Any help is greatly appreciated
-- 
View this message in context: http://www.nabble.com/spring-hibernate-integration-with-DispatcherServlet-tf3108991.html#a8618523
Sent from the springframework-developer mailing list archive at Nabble.com.

[Springframework-developer] BridgeMethodResolver does not like large hierarchy

[Serge B. <ser...@gm...>]

There is a closed issue
http://opensource.atlassian.com/projects/spring/browse/SPR-2648. But
the problem still alive. The file contains a test case.

This bug appears only when I building with sun jdk compiler. If you
will build the project  from eclipse, then the test will execute
successfully. To get the real result use "mvn clean test".

I have found that the problem arises when the long hierarchy is used
(more then two chains from bean class to some parent class or
interface with generics).


Serge Bogatyrjov.