I'm trying to generate java classes using JAXB from a schema in my class path. For CXF I generated java classes from a wsdl in my classpath like so:
<wsdlOptions>
<wsdlOption>
<wsdl>classpath:wsdl/MetsInterfaceService.wsdl</wsdl>
</wsdlOption>
</wsdlOptions>
I was hoping something similar existed with JAXB. I did try using a catalog but this seems to be more in line when a schema (stored in the same maven module) imports another schema in the classpath.
Any help would be appreciated!
-Sal
The CXF XJC Maven Plugin appears to support classpath:.
The XsdOption object is used to pass specific options and
configuration for each XSD file that is to be processed.
The example on the site shows classpath: used in several ways in <xsdOption> paths for <xsd>, <bindingFile>, and <catalog> paths:
<configuration>
<sourceRoot>${basedir}/target/generated/src/main/java</sourceRoot>
<xsdOptions>
<xsdOption>
<xsd>classpath:/schemas/wsdl/http.xsd</xsd>
<bindingFile>classpath:/schemas/wsdl/http.xjb</bindingFile>
<catalog>${basedir}/src/main/build-resources/catalog.cat</catalog>
</xsdOption>
<xsdOption>
<xsd>classpath:/schemas/wsdl/ws-addr.xsd</xsd>
<packagename>org.apache.cxf.ws.addressing</packagename>
</xsdOption>
<xsdOption>
<xsd>classpath:/schemas/wsdl/addressing.xsd</xsd>
<bindingFile>classpath:/schemas/wsdl/addressing.xjb</bindingFile>
</xsdOption>
<xsdOption>
<xsd>classpath:/schemas/configuration/security.xsd</xsd>
<bindingFile>classpath:/schemas/configuration/security.xjb</bindingFile>
<catalog>${basedir}/src/main/build-resources/catalog.cat</catalog>
<extensionArgs>
<extensionArg>-Xdv</extensionArg>
</extensionArgs>
</xsdOption>
<xsdOption>
<xsd>classpath:/schemas/wsdl/ws-addr-wsdl.xsd</xsd>
<bindingFile>classpath:/schemas/wsdl/ws-addr-wsdl.xjb</bindingFile>
<extension>true</extension>
</xsdOption>
<xsdOption>
<xsd>classpath:/schemas/wsdl/addressing200403.xsd</xsd>
<bindingFile>classpath:/schemas/wsdl/addressing200403.xjb</bindingFile>
</xsdOption>
</xsdOptions>
</configuration>
Related
My application uses log4j2 and we have two of them one for production and another for development environment. I am using maven to run the application using mvn clean jetty:run. My plugin configuration in pom.xml looks like this:
<plugin>
<groupId>org.eclipse.jetty</groupId>
<artifactId>jetty-maven-plugin</artifactId>
<version>9.4.8.v20171121</version>
<configuration>
<systemProperties>
<systemProperty>
<name>log4j.configuration</name>
<value>${log4j-dev.location}</value>
</systemProperty>
</systemProperties>
</configuration>
</plugin>
But my app still uses the log4j2.xml present in the WEB-INF/classes directory instead of the one in the log4j-dev.location path. Any ideas?
I found the solution for this problem. In the webdefault.xml file, I had to add the following code:
<context-param>
<param-name>log4jConfiguration</param-name>
<param-value>log4j2-custom.xml</param-value>
</context-param>
Hope it helps somebody who spent a whole day looking everywhere like me :)
Here is my configuration file :
<configuration>
<jdbc>
<driver>org.postgresql.Driver</driver>
<url>jdbc:postgresql://localhost:5432/db</url>
<user>myuser</user>
<password>mypwd</password>
</jdbc>
<generator>
<database>
<name>org.jooq.util.postgres.PostgresDatabase</name>
</database>
<generate>
<pojos>true</pojos>
<daos>true</daos>
</generate>
<target>
<packageName>com.myproject.gen</packageName>
<directory>src/main/java</directory>
</target>
</generator>
</configuration>
It used to work but now I have the following error :
The <generator/> tag is mandatory
I use jOOQ 3.8.2
Any idea ?
I had the same problem. Found that in JOOQ > 3.8 the encoding in target tag is mandatory.
Try to add the <encoding> in the <target> tag, i.ex. <encoding>UTF-8</encoding>
I was able to fix this in my code. Make sure the code gen library matches the xsd version. See my example
My project contains A.xsd which imports schema as follows from B.xsd which is part of another project:
<xsd:import namespace="http://com.test.schema/common/Context" schemaLocation="http://com.test.schema/common/Context/B.xsd"/>
I am trying to use the episode from the project which contains B.xsd so that classes related to B.xsd do not get re-generated when A.xsd is parsed. So I referred this and this to come up with the following configuration:
Here is the pom.xml
<dependencies>
<dependency>
<groupId>com.bar.foo</groupId>
<artifactId>schema-b</artifactId>
<version>1.2</version>
</dependency>
<dependencies>
.
.
.
.
.
<build>
<plugins>
<dependency>
<plugin>
<groupId>org.jvnet.jaxb2.maven2</groupId>
<artifactId>maven-jaxb2-plugin</artifactId>
<version>0.13.0</version>
<executions>
<execution>
<goals>
<goal>generate</goal>
</goals>
<configuration>
<extension>true</extension>
<episodes>
<episode>
<groupId>com.bar.foo</groupId>
<artifactId>schema-b</artifactId>
</episode>
</episodes>
<catalog>src/main/resources/catalog.cat</catalog>
<schemas>
<schema>
<fileset>
<directory>${basedir}/src/main/schemas</directory>
<includes>
<include>A.xsd</include>
<include>...</include>
<include>...</include>
</includes>
</fileset>
</schema>
</schemas>
<bindingDirectory>${basedir}/src/main/schemas</bindingDirectory>
<bindingIncludes>
<include>*.xjb</include>
</bindingIncludes>
<args>
<arg>-Xannotate</arg>
</args>
<plugins>
<plugin>
<groupId>org.jvnet.jaxb2_commons</groupId>
<artifactId>jaxb2-basics</artifactId>
<version>0.6.0</version>
</plugin>
<plugin>
<groupId>org.jvnet.jaxb2_commons</groupId>
<artifactId>jaxb2-basics-annotate</artifactId>
<version>0.6.0</version>
</plugin>
</plugins>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
Here is the catalog file:
PUBLIC "http://com.test.schema/common/Context" "maven:com.bar.foo:schema-a:jar::1.2!"
There is some configuration in the xjb file to make sure that XmlRootElement is written into some generated classes:
<jxb:bindings xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:jxb="http://java.sun.com/xml/ns/jaxb"
jxb:version="2.1" xmlns:xjc="http://java.sun.com/xml/ns/jaxb/xjc"
xmlns:annox="http://annox.dev.java.net" extensionBindingPrefixes="xjc">
<jxb:globalBindings>
<xjc:simple />
</jxb:globalBindings>
<jxb:bindings
schemaLocation="A.xsd">
<jxb:bindings node="//xsd:complexType[#name='ADataType']">
<jxb:class name="AData" />
<annox:annotate>
<annox:annotate annox:class="javax.xml.bind.annotation.XmlRootElement"
name="AData" />
</annox:annotate>
</jxb:bindings>
</jxb:bindings>
Inspite of providing the episode to the xjc execution and the location of the schema for B.xsd in the catalog file, the classes for B.xsd is getting generated.
The issue is that the maven artifact referred to by the catalog file is not being picked up. I see the following error in the maven build logs:
Malformed URL on system identifier: maven:com.bar.foo:schema-b:jar::1.2!
PUBLIC: http://com.test.schema/common/Context
maven:com.bar.foo:schema-a:jar::1.2!
Can anyone help tell me why am I hitting this malformed URL error for the artifact that contains B.xsd? Any help will be really appreciated.
Disclaimer: I'm the author of the maven-jaxb2-plugin.
First, you're probably mixing A and B here. You're saying A imports B but then you're using the schema-a artifact as episode. If B is imported, you should use schema-b as episode to not regenerate B stuff when compiling A.
But I think this is probably just a minor mistake in the question.
You have two aspects here - episodes and catalogs.
Episodes allow you to skip generation of classes you've generated somewhere else already. So if you use schema-b artifact when compiling schema-a then XJC should not generate classes for schema-b. You don't need catalogs for that, it's independent.
Sometimes XJC still generates few leftovers - even if you use an episode. I often get ObjectFactory and maybe some enums or top-level-elements generated. I believe this is an issue in XJC, there's nothing I can do in the maven-jaxb2-plugin about it.
So as a workaround I just use maven-antrun-plugin to delete unnecessary generated things.
If you get all of the B stuff generated then you should check if schema-b artifact really have the episode file generated. Check if you have META-INF/sun-jaxb.episode inside the JAR. See this answer for some trivia on the episode file.
So if you correctly configure the correct episode artifact you should not get B things generated, you don't need catalogs for this.
What you need the catalog for is to avoid downloading http://com.test.schema/common/Context/B.xsd when compiling. You can use catalogs to point to anothe location. I think your problem here is that you refer http://com.test.schema/common/Context to maven:com.bar.foo:schema-a:jar::1.2! which obviously does not point to the schema resource.
If you have an import like
<xsd:import namespace="http://com.test.schema/common/Context" schemaLocation="http://com.test.schema/common/Context/B.xsd"/>
Then you should probably rewrite it as follows:
PUBLIC "http://com.test.schema/common/Context" "maven:com.bar.foo:schema-b:jar::1.2!/common/Context/B.xsd"
Assuming schema-b artifact contains your schema under /common/Context/B.xsd. Note that it maps namespace, not schema location.
You can also use REWRITE_SYSTEM to rewrite schema location. For example:
REWRITE_SYSTEM "http://com.test.schema" "maven:com.bar.foo:schema-b:jar::1.2!"
If you have an URL like http://com.test.schema/common/Context/B.xsd, it will be rewritten to maven:com.bar.foo:schema-b:jar::1.2!/common/Context/B.xsd. This will point to the resource /common/Context/B.xsd inside your schema-b JAR.
Another hint - if you use schema-b as dependency in your project, you can omit the version.
Here's an example of catalog from a real world project:
https://github.com/highsource/ogc-schemas/blob/master/schemas/src/main/resources/ogc/catalog.cat
It contains rewrites like:
REWRITE_SYSTEM "http://schemas.opengis.net" "maven:org.jvnet.ogc:ogc-schemas:jar::!/ogc"
I have been reading a lot on this forum,jboss docs and on the internet to successfully get log4j configuration to work with jboss as 7.1.1, I do not want to use the logging subsystem in jboss. I want to use my own log4j configuration. My jboss server is configured in standalone mode. The following is what I did to get log4j configured based on docs :
Define a jboss-deployment-structure.xml as per https://docs.jboss.org/author/display/AS71/How+To#HowTo-HowdoIuselog4j.propertiesorlog4j.xmlinsteadofusingtheloggingsubsystemconfiguration%3F, and I added this in the META-INF directory of my EAR
I added a log4j.xml as is, and packaged inside a jar in the lib directory of my ear.
Removed the logging subsystem and the extension module="org.jboss.as.logging" from standalone.xml.
I did not change the logging.properties that is provided as a startup parameter in the startup.sh as I've read that is the logging that the jboss server will use before the subsystem kicks in.
Inspite of doing all of this I cannot get the application to log as per my log4j configuration.
My reason to use my own log4j configuration instead of the logging subsytem is to be able to use a custom rolling file appender for size-rotating-file-handler, as I want the rotated files to have a timestamp attached to the file name.
Help appreciated,
Ok, so I created a class MyHandler.java that extends from the SizeRotatingFileHandler.java and I override the preWrite method. MyHandler.java is in a package a.b.c. I create a sub directory under modules a/b/c and inside the c directory I add a jar that has just the Myhandler.class file. I add a module.xml
<?xml version="1.0" encoding="UTF-8"?>
<module xmlns="urn:jboss:module:1.0" name="a.b.c">
<resources>
<resource-root path="RotatingHandler.jar"/>
<!-- Insert resources here -->
</resources>
<dependencies>
<module name="org.jboss.logging"/>
</dependencies>
</module>
Then in the standalone.xml I added an entry for the custom handler
<custom-handler name="FILE3" class="a.b.c.MyHandler" module="a.b.c">
<level name="INFO"/>
<formatter>
<pattern-formatter pattern="%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n"/>
</formatter>
<file relative-to="jboss.server.log.dir" path="srveree.log"/>
</custom-handler>
When I start Jboss it says it cant find the class a.b.c.MyHandler. How do I resolve this error ?
UPDATE : I resolved this error. There was a problem in the package structure inside the module. However, I am still going back to the original question of configuring log4j with jboss-as-7.1.1.Final.
I was able to configure log4j with jboss. It turns out that you need to add exculsions seperately for each of the sub-deployments inside your main deployment. For example, I have an ear that has jar and war files budled inside. So I added seperate entries for each of the them in the jboss-deployment-structure.xml and it worked.
<sub-deployment name="your-subdeployment.jar">
<exclusions>
<module name="org.apache.log4j"/>
<module name="org.slf4j" />
<module name="org.apache.commons.logging"/>
<module name="org.log4j"/>
<module name="org.jboss.logging"/>
</exclusions>
</sub-deployment>
One thing you didn't indicate was whether or not you added a log4j library in your EAR/lib folder as well. I assume you probably have though or you should be seeing other errors.
I'm not sure whether or not log4j would have a log4j.xml inside a JAR inside your EAR to be honest. I would think that the EAR/META-INF would be a more appropriate place for your log4j configuration file.
There is no real reason to remove the logging subsystem in this case. Also, I'm not trying to convince you to use it, but you could create a custom handler fairly easily to do what you're looking to do. You could base it on the SizeRotatingFileHandler and then just add a suffix on the rename.
Consider configuration in your standalone.xml at
<subsystem xmlns="urn:jboss:domain:logging:1.1">
Here you can set
<console-handler name="CONSOLE">
<level name="DEBUG"/>
...
<logger category="com.myCompany">
<level name="DEBUG"/>
</logger>
...
Means: your logger in you classes which are in package com.myCompany should log from level DEBUG.
How can I use log4j with JBoss 7.1?
I have a log4j-1.2.16.jar in my WebContent/WEB-INF/lib folder. When I output the result of Logger.getRootLogger().getClass().toString() I get class org.jboss.logmanager.log4j.BridgeLogger which is wrong.
If I add Dependencies: org.apache.commons.logging to my MANIFEST.MF file I get the same result.
This results into the problem that my log4j.properties file (which I created unter WEB-INF/classes) is ignored.
There will soon be a way that will just work for you, but currently you have to exclude the log4j dependency from your deployment. You will also have to manually invoke the PropertyConfigurator.configure() to load the properties file.
The following file (jboss-deployment-structure.xml) needs to contain the following:
<jboss-deployment-structure>
<deployment>
<!-- Exclusions allow you to prevent the server from automatically adding some dependencies -->
<exclusions>
<module name="org.apache.log4j" />
</exclusions>
</deployment>
</jboss-deployment-structure>
Then adding including your own version of log4j in the WEB-INF/lib directory should work as you expect it to.