I'm having problems deploying a simple WebServices app (like "Hello World" simple) to OC4J. The same code works fine under Jetty, but breaks in OC4J, and I'm wondering if anyone else has faced the same issue. I'm using Enterprise Manager to deploy the app, but the deployment fails with this message:
[Jan 23, 2009 8:46:20 AM] Binding TestWs web-module for application TestWs to site default-web-site under context root /TestWs
[Jan 23, 2009 8:46:22 AM] Operation failed with error: Configuration problem: Unable to locate Spring NamespaceHandler for XML schema namespace [http://cxf.apache.org/jaxws]
Offending resource: ServletContext resource [/WEB-INF/beans.xml]
Looking at the beans.xml, the offending code seems to be the XML namespace declarations:
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:jaxws="http://cxf.apache.org/jaxws"
xsi:schemaLocation="
http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
http://cxf.apache.org/jaxws http://cxf.apache.org/schemas/jaxws.xsd">
<import resource="classpath:META-INF/cxf/cxf.xml" />
<import resource="classpath:META-INF/cxf/cxf-extension-soap.xml" />
<import resource="classpath:META-INF/cxf/cxf-servlet.xml" />
<jaxws:endpoint
id="helloService"
implementor="com.test.endpoint.HelloImpl"
address="/HelloWorld" />
</beans>
The stack trace is not terribly illuminating:
09/01/23 08:57:28 oracle.oc4j.admin.internal.DeployerException: Configuration problem: Unable to locate Spring NamespaceHandler for XML schema namespace [http://cxf.apache.org/jaxws]
Offending resource: ServletContext resource [/WEB-INF/beans.xml]
09/01/23 08:57:28 at org.springframework.beans.factory.parsing.FailFastProblemReporter.error(FailFastProblemReporter.java:68)
09/01/23 08:57:28 at org.springframework.beans.factory.parsing.ReaderContext.error(ReaderContext.java:85)
09/01/23 08:57:28 at org.springframework.beans.factory.parsing.ReaderContext.error(ReaderContext.java:80)
09/01/23 08:57:28 at org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.error(BeanDefinitionParserDelegate.java:261)
09/01/23 08:57:28 at org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseCustomElement(BeanDefinitionParserDelegate.java:1120)
...
Has anyone else run into similar problems? And if so, what's the best way to go about fixing it? My XML skills are middling, and I'm a complete noob with WebServices. But this may be an OC4J issue.
Thanks in advance for your help!
EDIT: This is not, as far as I can tell, a classpath issue, unless OC4J is odd about what jars it want to see where (as I know Tomcat can be). My WEB-INF/lib folder has the CXF jar, the Spring jars (beans, context, core, and web), xml-resolver-1.2.jar, and XmlSchema-1.4.2.jar. If I need to list everything in the WEB-INF/lib folder, I will. But again, the program works in Jetty.
Another Edit: Based on what I'm reading here, this appears to be an issue between Spring and the CXF jar -- there's a NamespaceHandler class in the CXF jar (in org.apache.cxf.frontend.spring to be precise), but there seems to be a configuration issue preventing Spring from seeing it.
Last Edit: Thank you everyone for your help. I never ended up getting CXF working in OC4J, because my client is on version 10.1.3.3.0. It's not J2EE 5 compliant, and I'm pretty sure they're not going to go for unpacking their oc4j.jar in order to change the boot.xml. But without the document Daniel pointed me to, I never would have known that.
So I switched to XFire version 1.2.6, and got my test app working after a few hiccups. Along the way I learned some interesting things about OC4J:
When deploying in Enterprise Manager, make sure you choose to load the local classpath first.
OC4J uses non-standard XML files, so make sure your app is not using any of OC4J's native XML files (in the Deployment Settings, uncheck all the currently selected imports -- that way, you can ensure that the app is using only files you provide in WEB-INF/lib)
If you can, use another app server. :P
Thank you all again!
I hate to ask the obvious, but have you looked at all the stuff for configuring OS4J and CXF together from the CXF web site?
http://cwiki.apache.org/CXF20DOC/appserverguide.html#AppServerGuide-OC4J
Looks like a configuration issue with Spring:
Configuration problem: Unable to locate Spring NamespaceHandler for XML schema namespace [http://cxf.apache.org/jaxws]
Offending resource: ServletContext resource [/WEB-INF/beans.xml]
Do you have anything in your web.xml to read that when the app starts up? Do you see a NamespaceHandler declared for that namespace anywhere in your code?
I would think its a CLASSPATH issue.
I'm not that familiar with OC4J, but how are you packaging/deploying your web-application?
You need to ensure that the CXF jar is in the WEB-INF/lib directory of your WAR?
Update: A little confused by your comments - if your spring config is in the META-INF directory of your EAR, then this is not the same classpath as that used by your web-app. So, in fact, sticking the CXF jar in WEB-INF/lib isn't going to work. You will either need to stick the JAR in the top-level of your EAR, or in some lib shared by all classloaders of OC4J. I suggest studying the enterprise-app/web-app classloader hierarchy documentation of OC4J to see if this can give more advice?
Related
I've run into the classic issue of trying to run a web app on a weblogic server and running into errors because of the weblogic server having old copies of classes.
The main issue I run into is when trying to use JPA 2.1 I get the following issue:
weblogic.application.ModuleException: java.lang.NoSuchMethodError: javax.persistence.Table.indexes()[Ljavax/persistence/Index;
The obvious answer here is that it is using the JPA version on the server which does not have that class.
I've set my weblogic.xml file to the following:
<wls:weblogic-web-app xmlns:wls="http://xmlns.oracle.com/weblogic/weblogic-web-app" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd http://xmlns.oracle.com/weblogic/weblogic-web-app http://xmlns.oracle.com/weblogic/weblogic-web-app/1.7/weblogic-web-app.xsd">
<wls:weblogic-version>12.1.3</wls:weblogic-version>
<wls:jsp-descriptor/>
<wls:debug>true</wls:debug>
</wls:jsp-descriptor>
<wls:container-descriptor>
<wls:prefer-web-inf-classes>true</wls:prefer-web-inf-classes>
</wls:container-descriptor>
<wls:context-root>DiscoveryPortal</wls:context-root>
</wls:weblogic-web-app>
With the key line being:
prefer-web-inf-classes: true
This seems to work for some classes but not all.
Weblogic 12c (supposedly) allows class filtering in both .war and .ear files. I would recommend moving from:
<wls:container-descriptor>
<wls:prefer-web-inf-classes>true</wls:prefer-web-inf-classes>
</wls:container-descriptor>
to:
<prefer-application-packages>
<package-name>javax.persistence.*</package-name>
</prefer-application-packages>
<prefer-application-resources>
<resource-name>javax.persistence.*</resource-name>
<resource-name>META-INF/services/javax.servlet.ServletContainerInitializer</resource-name>
</prefer-application-resources>
The filtering seems to work much better than prefer-web-inf-classes.
See the Oracle docs here that says it works for .war files. If not, you may consider switching to an .ear to see what happens.
Placing following code into weblogic.xml
<container-descriptor>
<prefer-application-packages>
<package-name>javax.persistence.*</package-name>
</prefer-application-packages>
</container-descriptor>
seems to be enough for related expection, on WebLogic Server 12.1.2.0 if you have JPA 2.1 jar on your classpath.
Official answer: "While WebLogic Server 12.1.3 supports JPA 2.1, the Java Archive (JAR) files are not configured by default; some additional configuration is required to enable JPA 2.1 support. In this tutorial, the JPA 2.1 implementation is configured on the WebLogic Server classpath."
And solution for weblogic is here: http://www.oracle.com/webfolder/technetwork/tutorials/obe/fmw/wls/12c/01-06-004-JavaEE7andWebLogicServer/javaee7.html
you need to add:
PRE_CLASSPATH=/YOUR_MIDDLEWARE_HOME/oracle_common/modules/javax.persistence_2.1.jar:/YOUR_MIDDLEWARE_HOME/wlserver/modules/com.oracle.weblogic.jpa21support_1.0.0.0_2-1.jar
export PRE_CLASSPATH
to setDomainEnv.sh which is located in your domain folder under 'bin' directory.
so you have inconsistent JPA API jar and Hibernate jars in the CLASSPATH.
JPA API 2.1 brought in that method and Hibernate 4.3 would be required to support that IIRC
I confirm that <wls:prefer-web-inf-classes>true</wls:prefer-web-inf-classes> doesn't work with WebLogic12/Spring4/Hibernate4/HibernateValidator5/JPA2.1,
you have to resort to <prefer-application-packages> but listing only java.persistence.* is far to be enough...
You have also to list:
javassist.*
org.hibernate.*
org.hibernate.validator.*
javax.validation.*
+
any other ones the Class Loader Analysis Tool will recommend you to include
+
include a ServletContextListener filter in your web.xml to register an "HibernatePersistencerProviderResolver implements PersistenceProviderResolver" that will return an singleton Collection holding an HibernatePersistenceProvider when called "getPersistenceProviders()"
if you are using Spring
in your Spring applicationContext to support method validation:
you need a bean "validator" class="org.springframework.validation.beanvalidation.LocalValidatorFactoryBean"
and another one
class="org.springframework.validation.beanvalidation.MethodValidationPostProcessor"
for your entityManager (class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean") jpaProperties:
<prop key="java.persistence.transactionType">jta</prop>
<prop key="hibernate.transaction.jta.platform">org.hibernate.engine.transaction.jta.platform.internal.WebLogicJtaPlatform</prop>
<prop key="hibernate.event.merge.entity_copy_observer">allow</prop>
if you are using maven, in your pom.xml (if using another build system refer to its doc to do the equivalent set-up)
you have to exclude org.jboss.spec.javax.transaction:jboss-transaction-api_1.1_spec from the dependencies org.hibernate:(hibernate-core and hibernate-entitymanager)
and then add it org.jboss.spec.javax.transaction:jboss-transaction-api_1.1_spec but as a "provided" independent dependency.
and last but not least…
DON'T use a persistence.xml !
not only with a LocalContainerEntityManagerFactoryBean you don't need it anymore but it will mess-up with WebLogic too and if you need to generate a DDL you can't use hbm2ddl anymore since the hibernate maven plugin is no more compatible with JPA2.1, you have to use an EntityManagerFactoryBuilder.generateSchema()... (not Persistence.generateSchema(...) as you will find when googling: this doesn't work without a persistence.xml...)
I'm working on a java project with spring on eclipse using Maven, and running on a Tomcat server v6.0. Everything was working fine since yesterday morning.
Here his my problem : I'm building my project, I got a build success. Then I start my Tomcat server and got this error :
org.springframework.beans.factory.parsing.BeanDefinitionParsingException: Configuration problem: Failed to import bean definitions from URL location [classpath:applicationContext- core.xml]
Offending resource: ServletContext resource [/WEB-INF/applicationContext.xml]; nested exception is org.springframework.beans.factory.BeanDefinitionStoreException: IOException parsing XML document from class path resource [applicationContext-core.xml]; nested exception is java.io.FileNotFoundException: class path resource [applicationContext-core.xml] cannot be opened because it does not exist
I found out similar problem on some website but none of them give me a solution that worked for me.
It seems that eclipse isn't able to find applicationContext-core.xml when I'm doing this :
<import resource="classpath:applicationContext-core.xml" />
However, I do have the needed jar file nad-core-0.0.1-SNAPSHOT.jar in WEB-INF/lib containing applicationContext-core.xml.
I even tried to add it manually to the classpath but I was still having the same problem.
I keep on looking for a solution, when suddendly it work again once after restarting Eclipse and building while Eclipse was still updating indexes and my project was having this strange status Hg status pending instead of default. Surprised by this result I decide to build again my project after restarting Eclipse and I got the error again and I enable to make it work again. It's quite annoying...
This looks to be a really random problem.
Thanks a lot for your help :)
As you've not specified you web application structure. I assume you've a simple web application at hand with the following structures
webapp
WEB-INF/classes/applicationContext.xml
WEB-INF/lib/nad-core-0.0.1-SNAPSHOT.jar/applicationContext-core.xml
Application context.xml refers to the applicationContext-core.xml file using the import tag. I did encounter a similar situation in my web application, here're the check lists that you should go through and may be one of them can apply to your situation.
Check the generated snapshot jar file for the applicationContext-core.xml file and make sure it is in the root directory of the jar. As silly as it sounds, this was the root cause of the issue I faced in my deployment.
Make sure your Maven Pom.xml file is configured to include this XML file from the resources folder. You can use the resource tags in the build phase of Maven to package them within the jar file itself.
You can try removing the import tag from application context.xml file and instead load both of them from Spring's webapplication context itself.
Add a context loader listener class from spring org.springframework.web.context.ContextLoaderListener
Add context-param contextConfigLocation with value classpath:applicationContext-core.xml,classpath:applicationContext.xml. Spring has the ability to dynamically sort out the dependencies before initiating the bean factory.
Hope this check list helps.
I get pretty much the same config, six years later, I got the same error.
I also restart Eclipse, and it solved the issue.
I have a simple Spring MVC application that looks up some user details from an LDAP server and prints out a simple HTML page using a JSP. The application works fine on Tomcat 6. It uses Spring LDAP 1.3.1 and LDAPTemplate to do the LDAP lookups.
However, when I deploy this application WAR to Websphere 7, the app doesn't run -- Websphere returns a 500 Internal server error. Looking at Websphere's log file, I see
[14/12/10 14:50:09:169 GMT] 00000022 DispatcherSer E org.springframework.web.servlet.FrameworkServlet initServletBean Context initialization failed
org.springframework.beans.factory.CannotLoadBeanClassException: Error loading class [org.springframework.ldap.core.support.LdapContextSource] for bean with name 'contextSource' defined in ServletContext resource [/WEB-INF/spring-servlet.xml]: problem with class file or dependent class; nested exception is java.lang.NoClassDefFoundError: org.springframework.beans.factory.InitializingBean
at org.springframework.beans.factory.support.AbstractBeanFactory.resolveBeanClass(AbstractBeanFactory.java:1253)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.predictBeanType(AbstractAutowireCapableBeanFactory.java:576)
at org.springframework.beans.factory.support.AbstractBeanFactory.isFactoryBean(AbstractBeanFactory.java:1319)
at org.springframework.beans.factory.support.AbstractBeanFactory.isFactoryBean(AbstractBeanFactory.java:885)
at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:562)
at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:895)
at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:425)
My web-inf\lib directory has all the JAR files, including org.springframework.beans-3.0.5.RELEASE.jar, which contains InitializingBean. I'm therefore not sure why Websphere is reporting the class as missing.
Contents of my web-inf\lib:
aopalliance.jar
com.springsource.org.apache.commons.logging-1.1.1.jar
com.springsource.org.apache.log4j-1.2.15.jar
commons-lang-2.5.jar
commons-logging-1.1.1.jar
commons-pool-1.5.4.jar
jstl-api-1.2.jar
jstl-impl-1.2.jar
ldapbp-1.0.jar
org.springframework.aop-3.0.5.RELEASE.jar
org.springframework.asm-3.0.5.RELEASE.jar
org.springframework.beans-3.0.5.RELEASE.jar
org.springframework.context-3.0.5.RELEASE.jar
org.springframework.core-3.0.5.RELEASE.jar
org.springframework.expression-3.0.5.RELEASE.jar
org.springframework.jdbc-3.0.5.RELEASE.jar
org.springframework.oxm-3.0.5.RELEASE.jar
org.springframework.transaction-3.0.5.RELEASE.jar
org.springframework.web-3.0.5.RELEASE.jar
org.springframework.web.servlet-3.0.5.RELEASE.jar
spring-ldap-1.3.1.RELEASE-all.jar
And here's the definition of the contextSource bean which Websphere is having trouble loading (the username/password is valid and works with Tomcat):
<bean id="contextSource" class="org.springframework.ldap.core.support.LdapContextSource">
<property name="url" value="ldaps://moo.example.com:1300/" />
<property name="userDn" value="CN=foo,OU=baz,DC=bar,DC=blat,DC=org" />
<property name="password" value="*******" />
</bean>
I'd be very glad if someone could point out why this isn't working on Websphere. I'm not too sure about class-loading rules in Websphere and would appreciate any advice on this.
Turn on Class Loading trace. This would tell you what classes are loaded and from which Jar. As Sajan mentioned chances are that there are duplicate jars in the classpath and the classloader that you expect has not loaded this class (and a parent class loader has likely loaded a class).
NoClassDefFoundError (NCDFE) does mean it could not locate the class that it is looking for. Errors in static initialization would explicitly turn out as a "java.lang.ExceptionInInitializerError" (EIIE)
"
Both NCDFE and EIIE extend from Linkage error.
In general all these errors can easily be troubleshooted by turning on the class loading for the Server. Also use the Class Loader Viewer available in the admin console to aid in your troubleshooting activities.
HTH
Manglu
This is a sticky and common exception. Remember, that NoClassDefFoundError doesn't mean the class was not found, rather it means:
NoClassDefFoundError: The given class
could be found, but something went
wrong when initializing it (an
interface it implemented could not be
found, something went wrong in a
static initializer etc.).
From here.
Please check that you don't have the same class in any other possible jar
Please check if you have added the dependencies in pom.xml file.
I have an application that is running Jaxb 2.1.12. I am running JDK 1.5 and OC4J 10.1.3.4.0. When I try to use the portion of my application that is using Jaxb, I get the following error:
Unable to locate jaxb.properties for package
I narrowed this down to the xml.jar that comes with OC4J. It contains Jaxb 1.0 classes. I can fix this error by adding the following to the orion-application.xml file:
<imported-shared-libraries>
<remove-inherited name="oracle.xml"/>
</imported-shared-libraries>
The problem is that I am deploying the WAR file to OC4J by using the admin_client.jar utility. I do not have an EAR to put the orion-application.xml file in, so I decided to try adding the orion-web.xml file to the WAR's WEB-INF directory and setting the search-local-classes-first property to true:
<?xml version="1.0"?>
<orion-web-app
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="http://xmlns.oracle.com/oracleas/schema/orion-web-10_0.xsd" deployment-version="10.1.3.4.0"
jsp-cache-directory="./persistence"
jsp-cache-tlds="standard"
simple-jsp-mapping="false"
temporary-directory="./temp"
schema-major-version="10" schema-minor-version="0" >
<web-app-class-loader search-local-classes-first="true" />
<web-app>
</web-app>
</orion-web-app>
This causes the application to not deploy at all. I get an error saying that the Spring configuration files cannot be parsed. I would like to use search-local-classes-first. How can I use this property? Also is there a way that I can deploy the orion-application.xml file with the WAR file?
09/11/16 13:26:01 WARNING: DeployerRunnable.run Unexpected exception parsing XML document from Servl
etContext resource [/WEB-INF/applicationContext-acegi-security.xml]; nested exception is java.lang.C
lassCastException: oracle.xml.jaxp.JXDocumentBuilderFactoryoracle.oc4j.admin.internal.DeployerExcept
ion: Unexpected exception parsing XML document from ServletContext resource [/WEB-INF/applicationCon
text-acegi-security.xml]; nested exception is java.lang.ClassCastException: oracle.xml.jaxp.JXDocume
ntBuilderFactory
at oracle.oc4j.admin.internal.DeployerBase.execute(DeployerBase.java:126)
at oracle.oc4j.admin.jmx.server.mbeans.deploy.OC4JDeployerRunnable.doRun(OC4JDeployerRunnabl
e.java:52)
at oracle.oc4j.admin.jmx.server.mbeans.deploy.DeployerRunnable.run(DeployerRunnable.java:81)
at com.evermind.util.ReleasableResourcePooledExecutor$MyWorker.run(ReleasableResourcePooledE
xecutor.java:303)
at java.lang.Thread.run(Thread.java:595)
Note: I do not get this error with Java 1.6 and I believe that is because 1.6 comes packaged with Jaxb 2.
If creating a ear file solves the problem, I recomend you go this way. Also, when you deploy a war file, the container creates an ear for you. Check in the applications directory of the oc4j's install dir for the ear file.
In the documentation for "search-local-classes-first" I saw the following line:
In accordance with the servlet specification, search-local-classes-first functionality cannot be used in loading classes in java. or javax.* packages.*
Since, JAXB2 is included in JDK 1.6 and is now under javax.*, maybe the appserver ignores the classes/library even though it is present in the WEB-INF/lib directory. Try putting the JAXB jars in your $JRE_HOME/lib directory. If it is picked up, then you can try modifying the startup scripts for your appserver to include the JAXB jars in the primordial classpath.
The solution is a bit of a hack :). Here's a link with steps for doing the same thing for Apache CXF.
Replacing JAXB with JAXB2.0 in OC4j
What I want to do:
I want to use the #Configured annotation with Spring. It requires AspectJ to be enabled. I thought that using the AJDT plugin for compile time weaving would solve this problem. Before installing the plug in the dependencies which were supposed to be injected into my #Configured object remained null.
What I have done:
Installed the AJDT: AspectJ Development Tools plug in for Eclipse 3.4.
Right clicked on my web project and converted it into a AspectJ project.
Enabled compile time weaving.
What doesn't work:
When I start the Tomcat 6 server now, I get an exception*.
Other information:
I haven't configured anything in the AspectJ Build and AspectJ Compiler parts of the project properties.
JDT Weaving under Preferences says weaving is enabled.
I still have Java build path and Java Compiler under project properties. And they look like I previously configured them (while the above two new entries are not configured).
The icon of my #Configured object file looks like any other file (i.e. no indication of any aspect or such, which I think there should be). The file name is MailNotification.java (and not .aj), but I guess it should still work as I'm using a Spring annotation for AspectJ?
I haven't found any tutorial or similar which teaches: How to turn a Spring web application project into an AspectJ project and weave aspects into the files using the AJDT plugin, all within Eclipse 3.4. If there is anything like that out there I would be very interested in knowing about it.
What I would like to know:
Where to go from here? I just want to use the #Configured annotation of Spring. I'm also using #Transactional which I think also needs AspectJ.
If it is possible I would like to study AspectJ as little as possible as long as my needs are met. The subject seems interesting, but huge, all I want to do is use the above two mentioned Spring annotations.
*** Exception when Tomcat 6 is started:
Caused by: java.lang.IllegalStateException: ClassLoader [org.apache.catalina.loader.WebappClassLoader] does NOT provide an 'addTransformer(ClassFileTransformer)' method. Specify a custom LoadTimeWeaver or start your Java virtual machine with Spring's agent: -javaagent:spring-agent.jar
at org.springframework.context.weaving.DefaultContextLoadTimeWeaver.setBeanClassLoader(DefaultContextLoadTimeWeaver.java:82)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1322)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:473)
... 41 more
Have you added spring-aspects.jar to your aspect path for the project?
In the project properties, under 'AspectJ Build' -> 'Aspect Path' try adding spring-aspects.jar and clean building the project.
Sorry you might have already done this - but you didn't mention it.
It looks like the compile time weaving isn't working. Try adding the below lines to your applicationcontext.xml
<context:load-time-weaver />
<context:spring-configured/>
You'll probably want to add the following xsd to the xml file also
http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-2.5.xsd
For details see here:
http://static.springframework.org/spring/docs/2.5.x/reference/aop.html#aop-aj-ltw
You can use #Transactional without AspectJ. Your configuration file should contain something like following to make it work:
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:aop="http://www.springframework.org/schema/aop"
xmlns:tx="http://www.springframework.org/schema/tx"
xmlns:util="http://www.springframework.org/schema/util"
xsi:schemaLocation="
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
http://www.springframework.org/schema/aop
http://www.springframework.org/schema/aop/spring-aop-2.0.xsd
http://www.springframework.org/schema/tx
http://www.springframework.org/schema/tx/spring-tx-2.0.xsd
http://www.springframework.org/schema/util
http://www.springframework.org/schema/util/spring-util-2.5.xsd"
>
<tx:annotation-driven/>
tells spring to look for #transactional annotations when creating instances of configured beans. On finding such annotation, spring returns a dynamic proxy of the bean to the application code. This dynamic proxy ensures that whenever the annotated methods are called, spring is able to intercept it to provide intended transactional behavior. But the proxy-based AOP mandates that you code against interfaces and not concrete classes.