I have an older application that uses a jar named xerces.jar. Looking at this I can see that it is the same as xercesImpl-2.9.1.jar from the maven repository.
When I run the application the xml validation behaves differently depending on if the jar is named xerces.jar or xercesImpl-2.9.1.jar.
I suspect there is something going on with the order that it it found on the classpath but I don't fully understand what is going on.
Any ideas as to what is going on?
The particular change is this:
The start tag looks like:
<Message xmlns="http://www.foo.com/messaging" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" release="006" version="010" xsi:schemaLocation="file:///C:/SOME/PATH">
When the jar is named "xerces.jar" this accepted when the app validates against a specific schema. When the jar is named "xercesImpl-2.9.1.jar" then it gives the error: Attribute 'xsi:schemaLocation' is not allowed to appear in element
Related
Context
I'm developing a stand-alone application that reads input-data from a csv-file.
Until now I've used a self-written class to perform input validation,
and the method used for validating a single record from the input file was triggered
immediately after reading a single line. The method was called in the methode for reading the csv-file.
Since the input data will be retrieved by using RESTful Web Services in the future
and we'll forfeit using csv-files, I want to decouple the validation from the csv-reading.
I stumpled upon Bean Validation (JSR 380) and used Hibernate Validator to refactor the validation procedure.
I tried both, adding validation-annotations directly to the Bean class, and using a validation.xml file for configuration.
Both ways work when I run the application from Eclipse.
Problem
The application will be deployed as an executable JAR.
I would like to keep the option to change the validation constraints without the need to repack and redeploy the JAR.
So I'm trying to figure out, if there is a way to exclude the validation.xml (+ further configuration files) from the JAR and put it in some directory "close" to the JAR.
Something like this:
myApp/
|-- JAR
|-- conf/
|-- ValidationMessages.properties
|-- META-INF/
|-- validation.xml
|-- validation/
|-- constraints-myBean.xml
What I tried
Placing the META-INF/-folder in the same directory as the JAR
The JAR runs, but the validation doesn't work.
Referencing the absolute path to constraints-myBean.xml in validation.xml, specifically changing
<constraint-mapping>META-INF/validation/constraints-pbpRecord.xml</constraint-mapping>
to
<constraint-mapping>C:/path/to/myApp/META-INF/validation/constraints-pbpRecord.xml</constraint-mapping>
and including validation.xml in my JAR.
A ValidationException cancels the execution:
Exception in thread "main" javax.validation.ValidationException: HV000096: Unable to open input stream for mapping file C:/Users/wsteffler/Desktop/pbp_import_tool/pbp_orgunit_import/META-INF/validation/constraints-pbpRecord.xml.
at org.hibernate.validator.internal.xml.config.ValidationBootstrapParameters.setMappingStreams(ValidationBootstrapParameters.java:291)
at org.hibernate.validator.internal.xml.config.ValidationBootstrapParameters.<init>(ValidationBootstrapParameters.java:67)
at org.hibernate.validator.internal.engine.AbstractConfigurationImpl.parseValidationXml(AbstractConfigurationImpl.java:595)
at org.hibernate.validator.internal.engine.AbstractConfigurationImpl.buildValidatorFactory(AbstractConfigurationImpl.java:376)
at javax.validation.Validation.buildDefaultValidatorFactory(Validation.java:103)
at de.uniwuppertal.hisinone.orgunitimport.pbp.Main.main(Main.java:220)
Adding the parent-directory of META-INF/ to the classpath (with -classpath argument)
The JAR runs, but the validation doesn't work.
I've read the Bean Validation specification (6.5. Bootstrapping & 9. XML deployment descriptor) and the Hibernate Validator 6.1.0 Reference Guide (8. Configuring via XML), especially looking for solutions in the chapters in parentheses, and searched on StackOverflow and Google for solutions. Unfortunately I haven't found anything that would lead me to a solution so far.
Is it even possible to achieve bootstrapping an external validation.xml when executing a JAR?
If it is, how can I achieve this?
If you'll need more information or parts from my code, I'll update the question with the required information.
Hibernate Validator clearly doesn't support that. For sure the validation.xml needs to be in the jar. We could maybe support having the file: prefix to point to external constraint mappings. I would accept a patch if you were willing to work on that.
Not sure about the resource bundles though so that would be an half baked solution for you.
I wonder if you could just pass a carefully crafted class loader that can load resources from your external location (and delegate everything else to the standard class loader) and use externalClassLoader(ClassLoader) to pass it to HV when configuring the ValidatorFactory.
I am a little confused with how does xml xsi:schemaLocation works.
I am using Maven + IDEA to create a Spring project.
If miss org.springframework.spring-beans in my dependency, IDEA will warn me some error.
If I add this jar, warn will disappear.
Maybe it is not important, but it like a black magic to me, can any one help me how does this work?
Those XSDs are in fact included in the jar provided by spring. You can check this by doing a double shift and typing in the XSD's filename. So if you don't include the jar, your maven project cannot locate the XSD in your classpath.
The XSD you mentioned can be found here, as part of the spring-beans module
IntelliJ IDEA is helpfully indicating that it cannot location the XSD that it needs to validate the Spring project.
It turns the default namespace (beans/#xmls) red because it uses that along with the paired value of the namespace given by xsi:schemaLocation (also red) in order to find the governing XSD. Note that this does not necessarily have to be at the URL given by the paired value xsi:schemaLocation (https://www.springframework.org/schema/beans/spring-beans.xsd). Other mechanisms, including as XML Catalogs, can aid in the resolution of where the actual XSD can be found.
In this case, IDEA knows to check JARs on the classpath for the needed XSD.
See also:
How to link XML to XSD using schemaLocation or noNamespaceSchemaLocation?
xmlns, xmlns:xsi, xsi:schemaLocation, and targetNamespace?
How to reference a local XML Schema file correctly?
Must an XML namespace name URI be retrievable?
I get this error in a Java maven project. The weird thing is, it doesn't appear on every machine so I assume it has something to do with a configuration issue.
The class RoleKeyCacheImpl is a #Startup #Singleton:
#Startup
#Singleton
public class RoleKeyCacheImpl implements RoleKeyCache { ... }
That's the error Wildfly triggers when deploying the service.
Caused by: java.lang.IllegalArgumentException: WFLYEE0040: A component
named 'RoleKeyCacheImpl' is already defined in this module at
org.jboss.as.ee.component.EEModuleDescription.addComponent(EEModuleDescription.java:167)
at
org.jboss.as.ejb3.deployment.processors.EJBComponentDescriptionFactory.addComponent(EJBComponentDescriptionFactory.java:58)
I've tried:
installing a new Wildfly (V10, V13) on the same machine -> doesn't help
installing a completely new Eclipse on this machine -> doesn't help
cleaning & rebuilding all related projects
making sure the deployments-folder is empty and doesn't contain old versions of the same WAR
read the related question here which also didn't help (they use Spring): A component named 'XXX' is already defined in this module in JBoss 7.1.1
read and tried this q&a: Wrong dependencies with EJB in JBoss Wildfly (server-clean) -> doesn't help
deleted and rebuilt the local maven rep (".m2") -> no effect
checking out the same source on another computer -> does work on one machine, on another it gives the same error
I have absolutely no clue what the issue is or even could be. On one machine, we check it out and it runs without errors. On others, the exact same error happens.
Does anybody have an idea?
I had this same issue multiple times with EAP 7.1 and now again with WildFly 21.0.0. I know by experience this is an issue caused by Eclipse who tries to deploy automatically to a configured WildFly instance. During the deployment (or undeployment) some concurrent file issue arises and files who should be removed, are still on the filesystem, causing this error that a component is already defined.
In fact it is not already defined, it is just WildFly that is confused because it finds in his temporary directories some old files which shouldn't be there and reference your exact same component.
Solution: remove in the WildFly standalone directory the content in the 'deployments' directory and the 'tmp' directory. Rest assured, all what is there is okay to remove safely. Reboot and the error message will be gone ;-)
You should pay attention to not have two #Stateless EJB annotations on top of two classes with the same name - in the same module.
You may differentiate them by using the name attribute in the annotation and put different values in each class
Looks like the class already exists. Check if it does...you may have to rewrite that part of EEModuleDescription to use its own private methods (which would be what you would write) rather than overriding methods in RoleKeyCacheImpl. If the class actually does not exist then right-click on the project -> Maven 2 Tools -> Generate Eclipse Artifacts (Check for Updates). That will regenerate all of the dependencies that the project uses. Also please be sure that you have not added any new projects to the classpath by mistake as that may also cause this error.
I just ran into this today when a colleague added a maven dependency.
Turns out this dependency was a jar with a nasty classpath entry or "../" in the manifest.
I edited the jar's manifest.mf that was cached in my local maven repository using 7-zip and removed the "../" classpath entry.
Then re-packaged my war file (maven clean install) and bingo, it works!
In my case it was caused by org.libreoffice jurt version 5.4.2 (but other versions I checked also have the classpath nastiness).
Unfortunately I was lucky we pinpointed it to a dependency, YMMV!
Although I have been working in java for a while, there are many small things I have been ignoring, which at times have become bottleneck in productivity. I have difficulty in understanding this:
This is one of the bean.xml which gets placed in the final .war file (in a web application, built with spring framework).
<context:property-placeholder
location="classpath:/${deploy.env}/com.example.config/db.properties"
ignore-resource-not-found="false" />
I have following doubts:
1) At the time of building the code, i did like this for passing value of deploy.env
mvn clean install -Ddeploy.env=local
I ran the mvn in debug mode and could see this set to local. Now, the thing is, in the .war that gets generated, it is still ${deploy.env} (see above snippet). Doesn't this get replaced in the final .war? If not, then how do we pass the value which we intend to set?
2) what does "classpath:/${deploy.env}/com.example.config/db.properties" mean? Who sets the value of classpath? Are classpath capable of providing the location of resource files as well?
Assuming deploy.set --> local, so would this get translated to:
classpath:"/local/com.example.config/db.properties"
So does this mean db.properties would be present at: /local/com.example.config/db.properties
Any inputs to understand this would be of great help.
deploy.env is either environment variable or system property available to the JVM at run time.
The classpath:/${deploy.env}/com.example.config/db.properties will be resolved at run when your war is running in the container.
Set deploy.env=whatever in the shell from where you starting the tomcat or set in the environment of the user which starts the tomcat.
mvn clean install -Ddeploy.env=local here the deploy.env system property is available at build time. This will not replace the value of your spring config.
classpath is where all your classes and libraries bundled in the war are available along with the tomcat libraries. The spring property configurer will look for the db.properties file in the classpath at location e.g. /local/com.example.config
Spring documentation to learn more
Some explanation on my blog post
As stated in the Oracle Web site: The CLASSPATH variable is one way to tell applications, including the JDK tools, where to look for user classes.
That classpath: is referring to that location in particular, whatever it is, so it will start looking for those resources defined by Spring from that location and on, until it finds the first match.
Also, if you have that as a property in Maven, the value can be replaced with the right plug-in and configuration; not quite useful when you want a build that can be used with many values within those .properties files for different environments.
You can use other prefixes as file:, http:, etcetera. But you are just wondering about classpath:.
I have a JEE application that runs on WAS 6. It needs to have the class loader order setting to "Classes loaded with application class loader first", and the WAR class loader policy option set to "Single class loader for application".
Is it possible to specify these options inside the EAR file, whether in the ibm-web-bnd.xmi file or some other file, so the admin doesn't need to change these setting manually?
Since the app is deployed via an automated script, and the guy who is in charge of deployment is off site, and also for some other political reasons, this would greatly help!
Thanks to #Matthew Murdoch's answer, I was able to come up with a solution. Here it is, in case it helps someone else.
I created a deployment.xml like this:
<?xml version="1.0" encoding="UTF-8"?>
<appdeployment:Deployment xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:appdeployment="http://www.ibm.com/websphere/appserver/schemas/5.0/appdeployment.xmi" xmi:id="Deployment_1241112964096">
<deployedObject xmi:type="appdeployment:ApplicationDeployment" xmi:id="ApplicationDeployment_1241112964096" startingWeight="1" warClassLoaderPolicy="SINGLE">
<classloader xmi:id="Classloader_1241112964096" mode="PARENT_LAST"/>
<modules xmi:type="appdeployment:WebModuleDeployment" xmi:id="WebModuleDeployment_1241112964096" startingWeight="10000" uri="AGS.war">
<classloader xmi:id="Classloader_1241112964097"/>
</modules>
</deployedObject>
</appdeployment:Deployment>
Make sure to change the name of your WAR file(s) to match (mine is called AGS.war).
I also changed the numbers in the xmi:id attributes, to be sure they are unique, though I'm not sure it it really matters that they be unique across applications.
Then, I put the deployment.xml file in the root of my EAR file, via ANT:
<ear destfile="${artifactsDir}/${earName}.ear" appxml="${projectName}_EAR/application.xml">
<fileset dir="${artifactsDir}" includes="${warName}.war"/>
<fileset dir="${projectName}_EAR/" includes="deployment.xml"/>
</ear>
Edit (2): The WebSphere Application Server Toolkit (AST) is a tool you can use to enhance an EAR file with this information (see for example the 'Configure an Enhanced EAR' section in this document).
Edit (1): This post suggests that the 'Classes loaded with application class loader first' (the PARENT_LAST setting) can be set in the deployment.xml file within the EAR.
If you have control over the automated deployment scripts this can be done. Below is some wsadmin jython code for setting the web module class loader order to 'Classes loaded with application class loader first' (interestingly the setting is called PARENT_LAST which is what it was labelled in previous versions of the admin console...).
wsadmin example (jython):
def getWebModule(config, applicationName):
webModules = config.list('WebModuleDeployment').
split(system.getProperty('line.separator'))
for webModule in webModules:
if (webModule.find(applicationName) != -1):
return webModule
return None
applicationName = "<Your application name here>"
webModule = getWebModule(AdminConfig, applicationName)
if (webModule != None):
AdminConfig.modify(webModule, "[[classloaderMode PARENT_LAST]]")
AdminConfig.save()
else:
print "Error: Cannot find web module for application: " + applicationName
Check out this link. There are different ways to set class loader policy using Jython based on your server version -
http://pic.dhe.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=%2Fcom.ibm.websphere.express.doc%2Finfo%2Fexp%2Fae%2Frxml_7libapp4.html
Similar to the answer from pkaeding, I discovered as follows, not specific to a particular .war by name, but useful when applying to whatever is the default .war in the .ear file. (.ear files with one .war file in them have only that .war, so naming the .war isn't necessary in the entry.) This approach may be good for situations where you may need to re-name of the .war project later for some reason, and so you wouldn't need to worry about updating the deployment.xml file. I found the deployment.xml file buried inside a cell reference directory trail; dunno if it's fine as shown when the file is placed at directory level META-INF and no deeper.
In my particular case, I found deployment.xml in my .ear project at:
<project_root>\META-INF\ibmconfig\cells\defaultCell\applications\defaultApp\deployments\defaultApp\
The content of the file looks a lot like:
<appdeployment:Deployment xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI"
xmlns:appdeployment="http://www.ibm.com/websphere/appserver/schemas/5.0/appdeployment.xmi" xmi:id="Deployment_1262775196208">
<deployedObject xmi:type="appdeployment:ApplicationDeployment"
xmi:id="ApplicationDeployment_1262775196208" startingWeight="10">
<classloader xmi:id="Classloader_1262775196208" mode="PARENT_LAST" />
</deployedObject>
</appdeployment:Deployment>
The line:
<classloader xmi:id="Classloader_1262775196208" mode="PARENT_LAST" />
originally read:
<classloader xmi:id="Classloader_1262775196208" mode="PARENT_FIRST" />
Note no reference to any .war is being made. As pkaeding mentioned, you shouldn't expect the various id numbers to be the same for you.