This is related to this question and the subsequent patch applied to cxf .
When using a WSDL-first approach to generate java stubs, is there a way to make exceptions extend RuntimeException instead of Exception?
Thanks Daniel and Piepera for the patch . But the generated code only adds the classname instead of fully qualified name and there is no import statement added for the custom exception supplied.
I have specified to use "com.google.adwords.api.AdwordsException" as exceptionSuper and wsdl2java maven plugin creates the following wsdl fault . But it didn't add an import statement for com.google.adwords.api.AdwordsException and compilation failed.
#WebFault(name = "ApiExceptionFault", targetNamespace = "https://adwords.google.com/api/adwords/billing/v201209")
public class ApiException extends AdwordsException {
Could you please fix it to either add the import statement or use the fully qualified name.
WSDL2JAVA Usage
wsdl2java -d C:\Dev\src\main\java -exceptionSuper com.google.adwords.api.AdwordsException -client -verbose -xjc-Xvalue-constructor -xjc-npa https://adwords.google.com/api/adwords/cm/v201209/CampaignService?wsdl
Related
I've created a new converter with the following structure:
package com.mycompany;
#Converter
public final class MyCustomConverter {
#Converter
public static TypeB convert(TypeA typeA) {
// do the conversion
}
}
I've also created in my src/main/java/resources folder the following package, META-INF.services.org.apache.camel and within that a TypeConverter file which just says:
com.mycompany
Within my route from TypeA I have got:
<convertBodyTo type="com.mycompany.TypeB" />
Yet my tests constantly fail to pick up the file and thus cannot find the converter, with the exception being:
Caused by: org.apache.camel.NoTypeConversionAvailableException: No
type converter available to convert from type: com.mycompany.TypeA to
the required type: com.mycompany.TypeB with value TypeA[value1="blah"]
Am I meant to do something else to get my test to pick up the TypeConverter file? Surely putting it in that resources folder with the exact structure adds it to the classpath and so it would be accessible.
Its recommended in the TypeConverter file to list the FQN of all the type conveters, eg
com.mycompany
Should be
com.mycompany.MyCustomConverter
This is also what we say on this page: http://camel.apache.org/type-converter.html
And could you check inside the generated JAR file of yours, that the META-INF/services/org/apache/camel directory is there, and that the TypeConverter file is present (and it is not in some directory like META-INF/org.apache.camel).
Also what is the runtime environment you use? Do you run Camel standalone, Tomcat, OSGi or something else?
I would like to experiment with map features in Saxon (http://www.saxonica.com/documentation/expressions/xpath30maps.xml), but I am unable to get past query compilation. Maybe I am missing some parameter or I use a wrong namespace, but I just can't find the right answer. This is my query code:
xquery version "3.0";
(: i have also tried http://www.w3.org/2005/xpath-functions/map, no difference :)
import module namespace map = "http://ns.saxonica.com/map";
map:get(map { 1 := 'aaa'}, 1)
invoked from command line:
"c:\Program Files\Saxonica\SaxonEE9.4N\bin\Query.exe" -s:play.xml -q:play2.xq" -qversion:3.0
The commands ends with error Cannot locate module for namespace "http://ns.saxonica.com/map"
When I leave out the module namespace map declaration, the error is Prefix map has not been declared, so I assume it must be.
Michael Kay has just posted a new blog entry with details on the Saxon Map implementation:
http://dev.saxonica.com/blog/mike/2012/01/#000188
You should use declare namespace instead of import module namespace for access to builtin functions. As far as I understand it, module import is for user-supplied modules only.
File map.xq:
declare namespace map="http://www.w3.org/2005/xpath-functions/map";
map:get(map { 1 := 'aaa'}, 1)
Works just fine:
> "C:\Program Files\Saxonica\SaxonEE9.4N\bin\Query.exe" -qversion:3.0 map.xq
<?xml version="1.0" encoding="UTF-8"?>aaa
I tried it with Saxon-EE 9.4.0.2J (the Java version) too, with the same effect.
Dunno if this helps, but the BaseX XQuery Processor also offers an implementation of Michael Kay's map proposal (still to be finalized by the W3): http://docs.basex.org/wiki/Map_Module
I've been unable to find any easy way of figuring out the version string for a WAR file deployed with Tomcat 7 versioned naming (ie app##version.war). You can read about it here and what it enables here.
It'd be nice if there was a somewhat more supported approach other than the usual swiss army knife of reflection powered ribcage cracking:
final ServletContextEvent event ...
final ServletContext applicationContextFacade = event.getServletContext();
final Field applicationContextField = applicationContextFacade.getClass().getDeclaredField("context");
applicationContextField.setAccessible(true);
final Object applicationContext = applicationContextField.get(applicationContextFacade);
final Field standardContextField = applicationContext.getClass().getDeclaredField("context");
standardContextField.setAccessible(true);
final Object standardContext = standardContextField.get(applicationContext);
final Method webappVersion = standardContext.getClass().getMethod("getWebappVersion");
System.err.println("WAR version: " + webappVersion.invoke(standardContext));
I think the simplest solution is using the same version (SVN revision + padding as an example) in .war, web.xml and META-INF/MANIFEST.MF properties files, so you could retrieve the version of these files later in your APP or any standard tool that read version from a JAR/WAR
See MANIFEST.MF version-number
Another solution described here uses the path name on the server of the deployed WAR. You'd extract the version number from the string between the "##" and the "/"
runningVersion = StringUtils.substringBefore(
StringUtils.substringAfter(
servletConfig.getServletContext().getRealPath("/"),
"##"),
"/");
Starting from Tomcat versions 9.0.32, 8.5.52 and 7.0.101, the webapp version is exposed as a ServletContext attribute with the name org.apache.catalina.webappVersion.
Link to the closed enhancement request: https://bz.apache.org/bugzilla/show_bug.cgi?id=64189
The easiest way would be for Tomcat to make the version available via a ServletContext attribute (org.apache.catalina.core.StandardContext.webappVersion) or similar. The patch to do that would be trivial. I'd suggest opening an enhancement request in Tomcat's Bugzilla. If you include a patch then it should get applied fairly quickly.
I have a simple JPA #Entity that has a property of type
java.util.Locale.
When I try and persist this, I get the following error:
java.lang.IllegalArgumentException: locale: java.util.Locale is not a supported property type.
at com.google.appengine.api.datastore.DataTypeUtils.checkSupportedSingleValue( DataTypeUtils.java:174)
...
In the appengine SDK (1.3.1), datanucleus-core-1.1.5.jar contains
plugin.xml which contains the following type conversion "extension":
<java-type name="java.util.Locale" persistent="true" embedded="true"
string-converter="org.datanucleus.store.types.LocaleStringConverter"/>
How do I "activate" this type converter in my #Entity class?
This seems to be a significant limitation of Google's use of datanucleus. See the following (2nd last heading):
http://datanucleus.blogspot.com/2010/01/gaej-and-jdojpa.html
Since in log4j javadoc is
WARNING: This version of JDBCAppender is very likely to be completely replaced in the future. Moreoever, it does not log exceptions.
What should I do to log to a database?
If you are looking for a database appender which not only works, but also supports connection pooling, is maintained and properly documented, than consider logback's DBAppender.
Ironically enough, the warning in the javadocs about removing JDBCAppender in future versions of log4j was written by me.
You can use an alternative appender, but really Log4j 1.2 is going to be around and standard for a long time. They developed DBAppender as part of their receivers companions, which isn't officially released, but you can download the source code and get your own going as well.
Unless the issue of not logging exceptions bothers you, JDBCAppender is just fine. Any further upgrade to 2.0 is going to be more radical than just changing JDBCAppender (if 2.0 happens), so I wouldn't worry about using it, despite the warning. They clearly don't have a solid roadmap or timeline to introducing a new version, and 1.2.15 was released in 2007.
**log4j.properties file**
# Define the root logger with appender file
log4j.rootLogger = DEBUG, DB
# Define the DB appender
log4j.appender.DB=org.apache.log4j.jdbc.JDBCAppender
# Set JDBC URL
log4j.appender.DB.URL=jdbc:mysql://localhost/log
# Set Database Driver
log4j.appender.DB.driver=com.mysql.jdbc.Driver
# Set database user name and password
log4j.appender.DB.user=root
log4j.appender.DB.password=root
# Set the SQL statement to be executed.
log4j.appender.DB.sql=INSERT INTO actionlg(user_id, dated, logger, level, message) values('%X{userId}',' %d{yyyy-MM-dd-HH-mm}','%C','%p','%m')
# Define the layout for file appender
log4j.appender.DB.layout=org.apache.log4j.PatternLayout
**Java Class**
Log4jExamples.java
import java.sql.*;
import java.io.*;
import org.apache.log4j.Logger;
import org.apache.log4j.MDC;
public class Log4jExample {
/* Get actual class name to be printed on */
static Logger log = Logger.getLogger(Log4jExample.class.getName());
public static void main(String[] args)throws IOException,SQLException{
log.error("Error");
MDC.put("userId", "1234");
}
}
**libs required**
- mysql-connector-java-3.1.8-bin.jar
- log4j-1.2.17.jar