I have a Spring Boot Java application that among other things uses Apache Camel to do a little route interception and data modification. We have a separate "camel routes" file (camelRoutes.xml) that defines the camel routes that will be used. There is also a bit of configuration in that file that, as best I understand, configures a Jolokia MBean server and Jolokia agent.
There is something about the Jolokia config XML that the system is not happy with. I've done some very quick Googling and it seems like it's specified properly (see section 9.3.2 in https://jolokia.org/reference/html/jmx.html). The problem manifest itself in various ways. When the file is open in the XML editor in eclipse, the corresponding XML is highlighted with an error (although it provides no information about what it thinks is wrong). More importantly, when I attempt to run the application, it fails with cascading exceptions, basically pointing to a problem in the config file.
Excerpts from camelRoutes.xml:
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:jolokia="http://www.jolokia.org/jolokia-spring/schema/config"
xmlns:context="http://www.springframework.org/schema/context"
xsi:schemaLocation="
http://camel.apache.org/schema/spring http://camel.apache.org/schema/spring/camel-spring.xsd
http://www.jolokia.org/jolokia-spring/schema/config http://www.jolokia.org/jolokia-spring/schema/config/jolokia-config.xsd
http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context.xsd
http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">
...
<context:mbean-export server="jolokiaServer" />
<jolokia:mbean-server id="jolokiaServer" />
<jolokia:agent lookupConfig="false"
systemPropertiesMode="never">
<jolokia:config autoStart="true" host="0.0.0.0"
port="${jolokia.port:8778}"
agentDescription="${jolokia.agentName:jolokia}" />
</jolokia:agent>
Errors are displayed in eclipse for the line where the jolokia:mbean-server and jolokia:agent are defined.
Small section of the exception trace when application is executed:
Caused by: org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException: Line 85 in XML document from file [C:\Users\JO24447\workspace\RST_Service_Base\rust-service-base-rest\target\classes\rst_camel\camelRoutes.xml] is invalid; nested exception is org.xml.sax.SAXParseException; lineNumber: 85; columnNumber: 45; cvc-complex-type.2.4.c: The matching wildcard is strict, but no declaration can be found for element 'jolokia:mbean-server'.
Any ideas what could be wrong?
In my case the cause was that I used the Maven assembly plugin which did not merge the spring.schemas files. I switched to the shader plugin and schema validation worked.
At the startup time of a spring app, I want to scan a path on the computer, find the jar files and build a spring application context from an xml config files inside them. Every thing is OK to add jar file to the classpath and making an ApplicationContext. But I can't find any beans from new context. All of needed dependencies are available in the jar files in the specific path on computer (via a maven copier plugin) expect those dependencies which are in the base spring project (for example spring dependency itself).
The code is (In Kotlin language):
var loader = URLClassLoader(arrayOf(entry.toFile().toURL()), Thread.currentThread().contextClassLoader)
...
val context = ClassPathXmlApplicationContext("classpath*:/$name")//name is xml file. I'm sure the address in classpath is right. context is not creating when the address in wrong. for example: classpath://$name
val services = context.getBeanNamesForType(IService::class.java)//services is empty
I have tried many other ways to load the xml but none of them was successful. for example:
val beans = DefaultListableBeanFactory(applicationContext)
val reader = XmlBeanDefinitionReader(beans)
reader.beanClassLoader = loader
reader.resourceLoader = resourceLoader
reader.setValidationMode(XmlBeanDefinitionReader.VALIDATION_XSD)
jarFile.getInputStream(jarEntry).use {
reader.loadBeanDefinitions(EncodedResource(InputStreamResource(it)))
}
beans.preInstantiateSingletons()
the xml inside jar file looks like this:
<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"
xsi:schemaLocation="http://www.springframework.org/schema/context
http://www.springframework.org/schema/context/spring-context-3.0.xsd
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-3.0.xsd">
<import resource="classpath*:/xxx-logic-context.xml"/>
<context:annotation-config/>
<context:component-scan base-package="aa.bbb.ccc.server"/>
</beans>
It's really interesting: When I define regular Beans instead using package scaning feature, I can get the bean in a sort of code
Great answer from #talex guided me. I fixed it by setting the current class loader:
val loader = URLClassLoader(arrayOf(entry.toFile().toURL()), Thread.currentThread().contextClassLoader)
Thread.currentThread().contextClassLoader = loader
It seems like the Spring Batch 3.0.6 release points to the 2.2 schema by default.
In the spring.schemas file there is this definition
http\://www.springframework.org/schema/batch/spring-batch.xsd=/org/springframework/batch/core/configuration/xml/spring-batch-2.2.xsd
And when I add this namespace to my spring file, I then get the scope="step" option (in my IDE, although IntelliJ has been pretty reliable matching runtime issues)
...
xmlns:batch="http://www.springframework.org/schema/batch"
...
But everything seems to claim that scope="job" is invalid.
Is it the spring.schemas file doing this? Why would the 3.xx iteration point back to the 2.2 schemas?
I can't seem to get a declaration like xmlns:batch="http://www.springframework.org/schema/batch/spring-batch-3.0.xsd" to work. Surprisingly that totally invalidates the batch namespace. Even though the spring.schemas file points to 3.xx like so
http\://www.springframework.org/schema/batch/spring-batch-3.0.xsd=/org/springframework/batch/core/configuration/xml/spring-batch-3.0.xsd
If I do this:
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:batch="http://www.springframework.org/schema/batch"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:p="http://www.springframework.org/schema/p"
xsi:schemaLocation="http://www.springframework.org/schema/batch
http://www.springframework.org/schema/batch/spring-batch-3.0.xsd
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.5.xsd">
...
</beans>
I can then get the scope="step" to be valid, and everything seems to point to batch-3.0, but scope="job" is still invalid.
Does anyone have a clean example of importing batch & using a job scope declaration on a bean?
Thanks!
Supposing I have a jar with the persistence.xml configuration and the jpa entities.
I would like to have the same persistence unit shared among different applications.
For example deploy a war application and have the same persistence unit (that other applications use) injected.
#PersistenceContext(unitName="MySharedPersistence")
private EntityManager entityManager;
I can not consider packaging all the applications in an ear file since I want to have the other applications up and running while I reupload an application (the application reuploaded uses some remote ejbs from the already deployed applications and uses the same persistence unti as described above).
Are there any solutions to this problem?
Thank you in advance.
EDIT: Probably It is not recomended are there any appropriate tryouts with the same result?
You can place your Entity classes and your persistence.xml in a jar, and reuse this jar in all projects. As long as you also include a beans.xml file along with your persistence.xml, it should work just fine. You should then be able to inject the persistence context in any project that uses this jar file.
You need the beans.xml file for autodiscovery by the container. For reference, here's how a beans.xml file would look:
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://java.sun.com/xml/ns/javaee" 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/beans_1_0.xsd">
</beans>
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?