cxf webservice in standalone spring application packaged as jar-with-dependencies using maven - maven

When running the packaged app like "java -jar my-app-0.0.1-SNAPSHOT-jar-with-dependencies.jar", I get the following error:
org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException: Line 47 in
XML document from URL [jar:file:/.../cxf/javafirst/target/my-app-0.0.1-SNAPSHOT-jar-with-dependencies.jar!/application-context.xml]
is invalid; nested exception is org.xml.sax.SAXParseException; lineNumber: 47;
columnNumber: 61; cvc-complex-type.3.2.2: Attribute 'sendServerVersion'
is not allowed to appear in element 'httpj:engine'.
This is due to an outdated http-jetty.xsd schema published at apache.org. And that is NOT my problem. My problem is that this does not happen in cases like:
maven jetty:run
or
maven exec:java
where the service runs directly against the unpacked binary directories and obviously finds the updated and correct http-jetty.xsd schema file.
I want to do basically one thing:
put the webservice into one jar including dependencies. That should also include all XML schema files because, obviously, it is not a good idea to make a web service dependent on outside resources.
What's the best way to do that using maven?
My possibly naive solution would be to copy the XML schema files manually into the resources directory and tell CXF to resolve them in the jar file. Therefore I have two more specific questions:
1.) Is it possible to let maven find the XML schema files and copy them into appropriate places?
2.) What's the recommended way to make CXF look up the schema files in the jar file?
3.) Is there any better, best-practice solution to that problem?
My maven configuration regarding the maven assembly plugin is the direct combination of the last two sections at http://maven.apache.org/plugins/maven-assembly-plugin/usage.html.

Spring has a very good mechanism to resolve the schema files that it requires - it typically does not download it from the web at all, instead using locally available files within jar files to get the schema and validate the xml, for eg. consider the context custom namespace schema in Spring, if you look at the META-INF/spring.schemas file in spring-context.jar file, you will see an entry along these lines:
http\://www.springframework.org/schema/context/spring-context-3.1.xsd=org/springframework/context/config/spring-context-3.1.xsd
basically what it is saying is to resolve the spring-context-3.1.xsd files from the classpath org.springframework.context.config.spring-context-3.1.xsd file
This applies for any third party library also, which in your case is http-jetty.xsd.
I think what I would recommend is to simply create a spring.schemas file in your jar file in META-INF/ folder, put an entry for the full path to the schema and replace it with a classpath version of http-jetty.xsd.

Related

I need spring framework xml schema

I'm trying to execute a small spring application in my eclipse ide.I have downloaded the spring-framework-4.1 zip file. I want xml schema to put it in my spring.xml file.where can i get the schema from the downloaded zip file?
thanks.
Usually the xsd schemas come in one of the packaged within the jar files, for example within org.springframework.beans.factory.xml there are the spring-beans-X.X.xsd files, try to search the entire zip looking for the files that ends with .xsd.
Sometimes the xsd files are contained within the config packages for example.
org.springframework.data.jpa.repository.config
I should recomment to use STS it can be create the namespace configuration on behalf you, just clicking in the namespace tab and add what you required.
Or you can download from here, but again I should recommend use maven to download dependencies.

Spring boot createJarFileFromFileEntry

I have a spring boot app and I start it with -Dloader.path=. One of the jar files is hive-exec.jar. This has a jar file bundled called minlog-1.2.jar. If I specify this file in -Dloader.path, I get an error,
java.lang.IllegalStateException: Unable to open nested entry 'minlog-1.2.jar'. It has been compressed and nested jar files must be stored without compression. Please check the mechanism used to create your executable jar file
at org.springframework.boot.loader.jar.JarFile.createJarFileFromFileEntry(JarFile.java:378)
at org.springframework.boot.loader.jar.JarFile.createJarFileFromEntry(JarFile.java:355)
at org.springframework.boot.loader.jar.JarFile.getNestedJarFile(JarFile.java:341)
at org.springframework.boot.loader.archive.JarFileArchive.getNestedArchive(JarFileArchive.java:108)
at org.springframework.boot.loader.archive.JarFileArchive.getNestedArchives(JarFileArchive.java:92)
at org.springframework.boot.loader.PropertiesLauncher.getClassPathArchives(PropertiesLauncher.java:445)
at org.springframework.boot.loader.Launcher.launch(Launcher.java:60)
at org.springframework.boot.loader.PropertiesLauncher.main(PropertiesLauncher.java:564)
However, if I copy this file into a folder and add that folder in -Dloader.path, I don't get any error.
What am I missing?
Thank You,
I am trying to manage the database driver as external jar instead of a project's maven's dependency. The application use the JPA framework, and we wanted to be able to switch from one SQL-database implementation from one environment to another (for example, H2 in DEV, Oracle in production). I had to manage the h2-database-driver jar as an external dependency. While loading it with the "-Dloader.path" command line option, I came accross he same problem as you described.
Viewing the org.springframework.boot.loader.jar.JarFile source code, the class manage an folder-entry and a jar-entry differently.
The method getNestedArchives seems to invoke the createJarFileFromFileEntry method which throw this exception.
There must be a good reason for it, if someone know about it, any comment is welcomed!
When loading jar dependencies from a directory, the java.util.jar.JarFile constructor is used instead and does not seem to throw any exception...
In the createJarFileFromFileEntry method, instad of throwing an exception, wouldn't it be possible to only have a log.warn and not throw an exception?

Getting Jar file after its OSGi related URI

In a specific point in my deployed OSGi bundle, I get a jar file URI in OSGi standard format, jar file that I need to parse for entity classes. So, having the URI like: bundle://233.0:1, would it be possible to get the jar file so that, I will be able to parse it for what kind of entity it has?
Note: I'm trying to solve an issue that I have with OpenJPA, Apache Servicemix and Spring Framework.
If you need any further clarifications, ask me please.
You do not need the jar. You can query the entries of a bundle with the following functions:
http://www.osgi.org/javadoc/r4v43/core/org/osgi/framework/Bundle.html#findEntries(java.lang.String,%20java.lang.String,%20boolean)
http://www.osgi.org/javadoc/r4v43/core/org/osgi/framework/wiring/BundleWiring.html#findEntries(java.lang.String,%20java.lang.String,%20int)
http://www.osgi.org/javadoc/r4v43/core/org/osgi/framework/wiring/BundleWiring.html#listResources(java.lang.String,%20java.lang.String,%20int)
First one returns only entries that is available in the bundle directly. Second one returns entries from the bundle and its fragments. Third one returns entries that the bundle's classloader sees (entries of the bundle, its fragments and entries from imported packages)

Spring how to get Maven artifact name in runtime

I have a Spring Integration requirement , where I need to externalize the libraries and properties file from my war file. I am able to achieve this through Maven assembly plugin, where i create a zip file which may contain
lib/*.jar
properties/{artifactId}/*.properties
The reason I am adding the artifact Id to the path is, I will be creating 100s of wars in future and would need to distinguish between them.
This wars will not contain Web.xml and the Initializer is part of one of my libraries file.
THe Initializer should know the artifactId in order to load the correct properties.
With maven, the maven artifact details gets published to
META-INF/maven/${groupId}/${artifactId}/pom.properties
META-INF/maven/${groupId}/${artifactId}/pom.xml
If I could move these files to
META-INF/maven/pom.properties
META-INF/maven/pom.xml
My application would be able to read the artifact id from pom.properties.
I need help in achieve this.
Or if there are any other approach please help in solving the issue.
The Maven archiver component does that: see here at addMavenDescriptor element. It doesn't seem to be possible to customize the paths of these files.
But I guess every property you need can just be placed in a specific file and so you just have to create a resource file (properties like) containing all the information you want and let Maven filter that file for you.

Need understanding of spring.handlers and spring.schemas

I have some questions derived from a problem that I have already solved through this other question. However, I am still wondering about the root cause. My questions are as follows:
What is the purpose of spring.handlers and spring.schemas?
As I understand it's a way of telling the Spring Framework where to locate the xsd so that everything is wired and loaded correctly. But...
Under what circumstances should I have those two files under the META-INF folder?
In my other question linked above, does anybody know why I had to add the maven-shade-plugin to create those two files (based on all my dependencies) under META-INF? In other words, what was the ROOT CAUSE that made me have to use the maven shade plugin?
What is the purpose of spring.handlers and spring.schemas?
well you more or less found it out by yourself, let's add some more details:
some spring libraries contain a spring.schemas and a spring.handlers file inside a META-INF directory
META-INF/spring.schemas
re-maps(*) schemalocation to a xsd inside the library
(abstract) only re-mapped versions are supported by this library
META-INF/spring.handlers
provides namespace handler classes for specific namespaces
the namespace handler class provides the parser logic to parse spring-batch beans, like job,
step, etc.
(*) the actual re-mapping happens during the build of the spring application context
Under what circumstances should I have those two files under the
META-INF folder?
normally the files are inside the spring library jars you use, but you can use the mechanism to implement own namespace bean parsing, then you would have own files
In my other question linked above, does anybody know why I had to add
the maven-shade-plugin to create those two files (based on all my
dependencies) under META-INF? In other words, what was the ROOT CAUSE
that made me have to use the maven shade plugin?
if you use a spring namespace in your spring configuration, you need the appropriate files
the problem arises when you want to run a java application:
with a main class either
the spring libraries need to be on the classpath
or all is merged into one jar, which has to be on the classpath (*)
as war/ear server application, the spring libaries need to be on the classpath, normally inside the war
i guess you did not start the mainclass with the complete classpath and i updated my answer for your first question too
(*) if you merge all into one jar, you have to make sure, that the contents of all spring.schemas/spring.handlers files are merged into one spring.schemas and one spring.handlers file, see this answer for a configuration with maven to create an all-in-one.jar

Resources