Develop Reference

How do I resolve “Element bean is not allowed here” when configuring the XML file?

I was creating a simple Java project by importing 4 major jar packages of Spring(beans, core, context and expression, all are ver 5.2.6). However, IDEA kept indicating that "element bean is not allowed here" even though I checked repeatedly that the dependencies are placed correctly in the module section and restarted the IDE. The configuration is as follows:
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd">
<!--Creating User Object-->
<bean id = "user" class = "com.zhouss.User"><bean/> #bean is where it reports error
</beans>
And here's a snapshot of the dependency jars:
I'm a complete newbie on Spring, how do I resolve the issue?

As it turned out, it was a problem with the particular version of IDEA (2020.3, mac), I have updated to the latest version of 2022.1, mac and the error simply disappears by themselves.
I found very little info online when I tried to resolve this problem, so I find it necessary to write down my findings.

Maven+Spring Project failing to load dependent xsd files

I've been struggling with this issue for several days now. I am trying to initialize a standard Spring project with the usual spring namespaces: beans, aop, context, util... my current, very initial, beans.xml file is as follows:
<?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:context="http://www.springframework.org/schema/context"
xmlns:aop="http://www.springframework.org/schema/aop"
xmlns:util="http://www.springframework.org/schema/util"
xsi:schemaLocation="
http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xml
http://www.springframework.org/schema/context http://www.springframework.org/schema/beans/spring-context.xml
http://www.springframework.org/schema/aop http://www.springframework.org/schema/beans/spring-aop.xml
http://www.springframework.org/schema/util http://www.springframework.org/schema/beans/spring-util.xml"
</beans>
When I attempt to compile and run the project in Glassfish, I hit an IllegalStateException while invoking org.glassfish.weld.WeldDeployer. Further down it states that the XML of dependent documents must be well formed and shows the first line of one of the dependent files (e.g. spring-beans.xml) which is clearly HTML. After some further digging, I found that indeed in my mavencachedirs where these .xsd files are cached, every single one had identical HTML content referencing a 404 Not Found. I am working offline with internal maven repositories, but this should not be a problem given that my dependent Spring jar files all have the appropriate spring.schemas and spring.handlers files. It simply seems like my project is failing to recognize them.
I'm a bit new to Spring, but I feel like I've done my due diligence in researching this issue. Any suggestions that may point me in the right direction would be greatly appreciated.
UPDATE - Following some of the tips posted in Spring schemaLocation fails when there is no internet connection, I consolidated my spring.handlers and spring.schemas files into two files in src/main/resources/META-INF. Running getResource returns the consolidated version of each file in this directory. That said, this still did not resolve the problem.
UPDATE 2 - I've reproduced this issue at home. I created a new Spring project on Netbeans 7.3.1 using the following archetype:
Group ID: co.ntier
Version: 1.0.2
Artifact ID: spring-mvc-archetype
Repository: http://repo.maven.apache.org/maven2/
Once the project was created, I added a beans.xml file to the classpath and stripped it down to it's most basic form:
<?xml version="1.0" encoding="windows-1252"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd"
/>
I built the project and deployed to Glassfish 4.0 through NetBeans while still connected to the internet. This worked as expected with no errors. However, when I disconnected the computer from the internet and deployed again (AND cleared the cached xsd files from ...Netbeans\Cache\7.3.1\mavencachedirs), I got the following error several times:
WARNING: WELD-001210 Warning when validating file:/C:/Users/Elliott/Desktop/Development/SpringTest/target/SpringTest/WEB-INF/beans.xml#5 against xsd. schema_reference.4: Failed to read schema document 'http://www.springframework.org/schema/beans/spring-beans.xsd', because 1) could not find the document; 2) the document could not be read; 3) the root element of the document is not .
I understand that Spring is supposed to be reading from the spring.schemas and spring.handlers files to locate these resources, but it clearly isn't! I challenge anybody to attempt to reproduce this issue and demonstrate that this is actually working as it should be. Right now I'm not convinced.

PROGRESS!!
OK. I'm 90% sure I've figured out the problem. When I created the beans.xml file, Netbeans creates a nb-configuration.xml file with the following in it:
<spring-data xmlns="http://www.netbeans.org/ns/spring-data/1">
<config-files>
<config-file>beans.xml</config-file>
</config-files>
<config-file-groups/>
</spring-data>
If I create a servlet in the web.xml file:
<servlet>
<servlet-name>SpringDispatcher</servlet-name>
<servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
and rename beans.xml file to SpringDispatcher-servlet.xml, the project compiles and loads the xsd files correctly, whether online or offline.
Since this worked when using the SpringDispatcher-servlet.xml, but not with beans.xml configured by Netbeans, I think it's safe to assume that when Netbeans is configured to load a spring config file through nb-configuration, it fails to reference the required spring.schemas and spring.handlers files in the classpath.
Maybe I'm completely wrong and just super noob-y when it comes to Spring (I am), but it doesn't seem like this behavior is correct. Regardless, at least I have a way to move forward now.

When iam trying to run spring example i am facing the following exception

SEVERE: Context initialization failed
org.springframework.beans.factory.CannotLoadBeanClassException: Cannot find class [spring.test.StockValueFetcher] for bean with name 'stockBean' defined in ServletContext resource [/WEB-INF/applicationContext.xml]; nested exception is java.lang.ClassNotFoundException: spring.test.StockValueFetcher
and my applicationContext.xml is
<?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="stockBean" class="spring.test.StockValueFetcher">
</bean>
</beans>
i have searched for the same in stackoverflow and other sites but i couldnot find any helpful solution

2 possible causes
Your class isn't called StockValueFetcher or isn't declared in the package spring.test
Your class is not properly deployed and/or defined in the webserver application
It is easy to validate 1.
In case it is 1: correct the spring config file
In case it is 2: check your build & deploy procedure to correctly create the proper web application

I can think of below two possibilities:
Check your build/classes folder. Does it have the class file for "StockValueFetcher" in the appropriate package.
If you are using MAVEN, have you added "Maven Dependencies" to the project's "Web Deployment Assembly". If not, add that as follows (assuming you are using Eclipse):
Right Click on your project -> Properties -> Deployment Assembly -> Add -> Java Build Path Entries -> Next and then from there you can add "maven Dependencies". Then build and try to run your app.

Importing Spring beans from other Maven modules inside a WAR?

I have a new web app that is packaged as a WAR as part of a multi-module Maven project. The applicationContext.xml for this WAR references beans that are imported from the "service" module, which in turn imports beans from the "dao" module. The import statement in applicationContext.xml looks like this:
<import resource="classpath*:service.xml" />
and the one inside the service.xml file looks like this:
<import resource="classpath*:dao.xml" />
Neither Spring STS, nor Eclipse show any warnings or errors in my bean files. I reference the imported beans all over the place. The Maven build works fine and the DAO integration tests all pass (they use the beans). I don't have any service integration tests yet.
But when I start up the WAR in Jetty I get an error:
Error creating bean with name 'securityService'
Cannot resolve reference to bean 'userDAO' while setting constructor argument
All of the imported bean XML files can be found inside their respective JAR files in the WEB-INF/lib directory. Indeed, the service bean that threw the error is itself defined inside the service.xml file inside the service module's JAR file.
Apparently the service module can't find the bean that it imported from the dao module. Obviously I don't understand something...seems like this should this Just Work?

I enabled DEBUG logging for 'org.springframework' in order to see if I could learn anything. What I found were messages to the effect that the DAO beans had been created, but there was also a message about them having no name or id.
I check the file, and they all did have an id. So what was it? I check the XML namespace and saw:
http://www.springframework.org/schema/beans/spring-beans-2.0.xsd"
and noticed it was old (I am using Spring 3.0.2) and changed it to:
http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
Once I changed it, Spring instantly threw half a dozen errors regarding beans that were defined incorrectly (but never used apparently). Once I fixed those errors, everything Just Worked. I've since gone through the entire system checking Spring XML file namespace versions.
Thanks to all for the help. Can't believe I wasted a day on this stupidity!!

The difference between the classpath:thingy.xml and classpath*:thingy.xml notation is that the former uses the standard classpath mechanism to resolve one resource (using ClassLoader.getResource(name)), whereas the latter will use ClassLoader.getResources(name) to retrieve all matching resources on the classpath, a distinction that should be irrelevant in your situation as I guess there is only one dao.xml file on the class path.
I think your problem is different, you are missing a leading slash.
Use this for a single resource
<import resource="classpath:/dao.xml" />
and this for multiple resources
<import resource="classpath*:/dao.xml" />
See
Spring Reference: The classpath*
prefix
Sun JavaDocs: ClassLoader

It should be like
<import resource="classpath:service.xml"/>

Are you having multiple applicationContexts and possibly the parent context is referring to a bean defined in the child context?

How to figure out which jars are needed?

How can I systematically determine which jars I'll need, and thus should include in my pom.xml file (I'm using maven as my project management tool)?
When learning spring, to keep things simple, added all the jars (even the ones I never used) to the classpath.
Right now for the most part, I'm guessing which jars to include. For example, I know in my spring configuration file, I have:
<tx:annotation-driven />
<context:annotation-config />
<aop:aspectj-autoproxy />
So, I guess I'll need: spring-context-x.x.x.jar, spring-tx-x.x.x.jar, spring-aop-x.x.x.jar
Thanks.

For the general problem of finding which JAR(s) contain which classes and their associated dependencies, you can try http://www.jarvana.com/jarvana/. It takes a class name as input and spits out a bunch of Maven dependencies you can use to get said class.
For Spring in particular, I believe you'll have to refer to its documentation. If you have IDE support for Maven, you can typically simply fill in the spring groupId (org.springframework) and activate autocompletion inside <artifactId></artifactId> to see which JARs are available. The main sections in the Spring docs tend to have their own separate jars.
As I'm sure you've seen, another good indicator that you'll need a separate JAR are the XML namespaces used in your applicationContext.xml file. For example, here's an XML root node from a project using aop, tx and beans:
<?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"
xsi:schemaLocation="
http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
http://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx-2.5.xsd
http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop-2.5.xsd"
default-autowire="byName">
The example above would imply that you need the spring-beans, spring-aop and spring-tx JARs (Spring's JAR naming is fairly consistent). I'm not sure if the above is always true, but it should at least give you an indication.

I see only two possible alternatives. Either:
"know what you're doing" and add the required dependencies before the fact ~or~
In doubt, don't add the dependency, let things fail and add the dependency after the fact

An easy way to completely forget about the JAR files is to use nexus.
If you're a corporation, you can set up your own Nexus server. If not, use a public server such as http://repository.sonatype.org (note: I haven't used this yet as we have our own) and search for the library.
Once you found the library, copy/paste the <dependency> ... </dependency> section into your POM file and you're good to go.
I forgot how we linked maven with the nexus server, but it's not too hard.. do a bit of searching and you're golden. No more worrying about JAR files!