insert into TABLE1 (COL1,COL2,COL3)
select my_seq.nextval, a, 'Some other Value'
from
(SELECT COL2 as a FROM TABLE1 where COL3 ='some value' )insert into TABLE1 (COL1,COL2,COL3, COL4)
select my_seq.nextval, a, 'Some other Value',b
from
(SELECT COL2 as a FROM TABLE2 where COL3 ='some value'UNION ALL
SELECT COL4 as b FROM TABLE3 )
- -nv
- By default, the XJC binding compiler performs strict validation of the source schema before processing it. Use this option to disable strict schema validation. This does not mean that the binding compiler will not perform any validation, it simply means that it will perform less-strict validation.
- -extension
- By default, the XJC binding compiler strictly enforces the rules outlined in the Compatibility chapter of the JAXB Specification. Appendix E.2 defines a set of W3C XML Schema features that are not completely supported by JAXB v1.0. In some cases, you may be allowed to use them in the "-extension" mode enabled by this switch. In the default (strict) mode, you are also limited to using only the binding customizations defined in the specification. By using the "-extension" switch, you will be allowed to use the JAXB Vendor Extensions
- -b
- Specify one or more external binding files to process. (Each binding file must have its own
"-b"switch.) The syntax of the external binding files is extremely flexible. You may have a single binding file that contains customizations for multiple schemas or you can break the customizations into multiple bindings files:In addition, the ordering of the schema files and binding files on the command line does not matter.xjc schema1.xsd schema2.xsd schema3.xsd -b bindings123.xjb
xjc schema1.xsd schema2.xsd schema3.xsd -b bindings1.xjb -b bindings2.xjb -b bindings3.xjb- -d
- By default, the XJC binding compiler will generate the Java content classes in the current directory. Use this option to specify an alternate output directory. The output directory must already exist, the XJC binding compiler will not create it for you.
- -p
- Specifying a target package via this command-line option overrides any binding customization for package name and the default package name algorithm defined in the specification.
- -httpproxy
- Specify the HTTP/HTTPS proxy. The format is [user[:password]@]proxyHost[:proxyPort]. The old
-hostand-portare still supported by the RI for backwards compatibility, but they have been deprecated. Note that the password specified with this option is an argument that is visible to other users who use thetopcommand, for example. For greater security, use-httpproxyfile, below.- -httpproxyfile
- Specify the HTTP/HTTPS proxy using a file. Same format as above, but the password specified in the file is not visible to other users.
- -classpath
- Specify where to find client application class files used by the
andcustomizations.- -catalog
- Specify catalog files to resolve external entity references. Supports TR9401, XCatalog, and OASIS XML Catalog format. Please read the XML Entity and URI Resolvers document or the
catalog-resolversample application.- -readOnly
- By default, the XJC binding compiler does not write-protect the Java source files it generates. Use this option to force the XJC binding compiler to mark the generated Java sources read-only.
- -npa
- Supress the generation of package level annotations into **/package-info.java. Using this switch causes the generated code to internalize those annotations into the other generated classes.
- -no-header
- Supress the generation of a file header comment that includes some note and timestamp. Using this makes the generated code more diff-friendly.
- -target 2.0
- Avoid generating code that relies on any JAXB 2.1 features. This will allow the generated code to run with JAXB 2.0 runtime (such as JavaSE 6.)
- -xmlschema
- Treat input schemas as W3C XML Schema (default). If you do not specify this switch, your input schemas will be treated as W3C XML Schema.
- -relaxng
- Treat input schemas as RELAX NG (experimental, unsupported). Support for RELAX NG schemas is provided as a JAXB Vendor Extension.
- -relaxng-compact
- Treat input schemas as RELAX NG compact syntax(experimental, unsupported). Support for RELAX NG schemas is provided as a JAXB Vendor Extension.
- -dtd
- Treat input schemas as XML DTD (experimental, unsupported). Support for RELAX NG schemas is provided as a JAXB Vendor Extension.
- -wsdl
- Treat input as WSDL and compile schemas inside it (experimental,unsupported).
- -quiet
- Suppress compiler output, such as progress information and warnings.
- -verbose
- Be extra verbose, such as printing informational messages or displaying stack traces upon some errors.
- -help
- Display a brief summary of the compiler switches.
- -version
- Display the compiler version information.
- Specify one or more schema files to compile. If you specify a directory, then xjc will scan it for all schema files and compile them.
- -host & -port
- These options have been deprecated and replaced with the -httpproxy option. For backwards compatibility, we will continue to support these options, but they will no longer be documented and may be removed from future releases.
- -use-runtime
- Since the JAXB 2.0 specification has defined a portable runtime, it is no longer necessary for the JAXB RI to generate **/impl/runtime packages. Therefore, this switch is obsolete and has been removed.
- -source
- The -source compatibility switch was introduced in the first JAXB 2.0 Early Access release. We have decided to remove this switch from future releases of JAXB 2.0. If you need to generate 1.0.x code, please use an installation of the 1.0.x codebase.
- -Xlocator & -Xsync-methods
- These switches have been disabled for now. We plan on releasing this functionality as a separate download in the future.
asadmin set server.http-service.http-listener.http-listener-1.port=10080asadmin set server.http-service.http-listener.http-listener-2.port=10443asadmin set server.http-service.http-listener.admin-listener.port=14848Typically the Command pattern is used to make an object out of what needs to be done -- to take an operation and its arguments and wrap them up in an object to be logged, held for undo, sent to a remote site, etc. There will tend to be a large number of distinct Command objects that pass through a given point in a system over time, and the Command objects will hold varying parameters describing the operation requested.
The Strategy pattern, on the other hand, is used to specify how something should be done, and plugs into a larger object or method to provide a specific algorithm. A Strategy for sorting might be a merge sort, might be an insertion sort, or perhaps something more complex like only using merge sort if the list is larger than some minimum size. Strategy objects are rarely subjected to the sort of mass shuffling about that Command objects are, instead often being used for configuration or tuning purposes.
Both patterns involve factoring the code and possibly parameters for individual operations out of the original class that contained them into another object to provide for independent variability. The differences are in the use cases encountered in practice and the intent behind each pattern.
What does volatile do?
This is probably best explained by comparing the effects that volatile and synchronized have on a method. volatile is a field modifier, while synchronized modifies code blocks and methods. So we can specify three variations of a simple accessor using those two keywords:
int i1;
int geti1() {return i1;} volatile int i2;
int geti2() {return i2;} int i3; synchronized int geti3() {return i3;}
geti1() accesses the value currently stored in i1 in the current thread. Threads can have local copies of variables, and the data does not have to be the same as the data held in other threads. In particular, another thread may have updated i1 in it's thread, but the value in the current thread could be different from that updated value. In fact Java has the idea of a "main" memory, and this is the memory that holds the current "correct" value for variables. Threads can have their own copy of data for variables, and the thread copy can be different from the "main" memory. So in fact, it is possible for the "main" memory to have a value of 1 for i1, for thread1 to have a value of 2 for i1 and for thread2 to have a value of 3 for i1 if thread1 and thread2 have both updated i1 but those updated value has not yet been propagated to "main" memory or other threads.
On the other hand, geti2() effectively accesses the value of i2 from "main" memory. A volatile variable is not allowed to have a local copy of a variable that is different from the value currently held in "main" memory. Effectively, a variable declared volatile must have it's data synchronized across all threads, so that whenever you access or update the variable in any thread, all other threads immediately see the same value. Of course, it is likely that volatile variables have a higher access and update overhead than "plain" variables, since the reason threads can have their own copy of data is for better efficiency.
Well if volatile already synchronizes data across threads, what is synchronized for? Well there are two differences. Firstly synchronized obtains and releases locks on monitors which can force only one thread at a time to execute a code block, if both threads use the same monitor (effectively the same object lock). That's the fairly well known aspect to synchronized. But synchronized also synchronizes memory. In fact synchronized synchronizes the whole of thread memory with "main" memory. So executing geti3() does the following:
this (assuming the monitor is unlocked, otherwise the thread waits until the monitor is unlocked).i3, which may have just been reset from "main" memory).geti3() we have no changes.)this.So where volatile only synchronizes the value of one variable between thread memory and "main" memory, synchronized synchronizes the value of all variables between thread memory and "main" memory, and locks and releases a monitor to boot. Clearly synchronized is likely to have more overhead than volatile.
Often we use the try block while using resources like Streams and Connections. In these cases it is mandatory to close the resources after the completion of the task. We usually do the same in the finally block as in the example below
BufferedReader br = new BufferedReader(new FileReader(path));
try {
return br.readLine();
} finally {
br.close();
}
In Java 7 this process has been shortened by the try-with-resource statement. In this the resources are implicitly closed on the completion of the try fragment irrespective of whether the code was successfully executed or with exception. The only change is that the resource must implement the java.lang.AutoCloseable interface. The classes java.io.InputStream, OutputStream, Reader, Writer, java.sql.Connection, Statement, and ResultSet have been retrofitted to implement the AutoCloseable interface and can all be used as resources in a try-with-resources statement.
Java 7.0 has come up with a new feature where it is possible to catch multiple exceptions in a particular catch block. For example
catch (IOException | SQLException ex) {
logger.log(ex);
throw ex;
}
In this case both IOException and SQLException will be caught in the same block.It has to be noted though that the parameter is implicitly final i.e the parameter cannot be assigned to any other Object.
Web services have been around a while now. First there was SOAP. But SOAP only described what the messages looked like. Then there was WSDL. But WSDL didn't tell you how to write web services in Java™. Then along came JAX-RPC 1.0. After a few months of use, the Java Community Process (JCP) folks who wrote that specification realized that it needed a few tweaks, so out came JAX-RPC 1.1. After a year or so of using that specification, the JCP folks wanted to build a better version: JAX-RPC 2.0. A primary goal was to align with industry direction, but the industry was not merely doing RPC web services, they were also doing message-oriented web services. So "RPC" was removed from the name and replaced with "WS" (which stands for web Services, of course). Thus the successor to JAX-RPC 1.1 is JAX-WS 2.0 - the Java API for XML-based web services.
Before we itemize the differences between JAX-RPC 1.1 and JAX-WS 2.0, we should first discuss what is the same.
JAX-RPC and JAX-WS support SOAP 1.1. JAX-WS also supports SOAP 1.2.
The WSDL 1.1 specification defined an HTTP binding, which is a means by which you can send XML messages over HTTP without SOAP. JAX-RPC ignored the HTTP binding. JAX-WS adds support for it.
JAX-RPC supports WS-I's Basic Profile (BP) version 1.0. JAX-WS supports BP 1.1. (WS-I is the web services interoperability organization.)
javax.xml.soap.SOAPElement.JAX-WS's basic interface mapping model is not extensively different from JAX-RPC's; however:
JAX-WS, via JAXB, adds support for MTOM, the new attachment specification. Microsoft never bought into the SOAP with Attachments specification; but it appears that everyone supports MTOM, so attachment interoperability should become a reality.
In the remainder of this tip, we will discuss SOAP 1.2, XML/HTTP, the WS-I Basic Profiles, and Java 5. Each of the remaining five bullets above will be a separate tip in this series.
There is really not a lot of difference, from a programming model point of view, between SOAP 1.1 and SOAP 1.2. As a Java programmer, the only place you will encounter these differences is when using the handlers, which we will cover in a future tip. SAAJ 1.3 has been updated to support SOAP 1.2.
Like the changes for SOAP 1.2, there is really not a lot of difference, from a programming model point of view, between SOAP/HTTP and XML/HTTP messages. As a Java programmer, the only place you will encounter these differences is when using the handlers, which we will cover in a future tip. The HTTP binding has its own handler chain and its own set of message context properties.
JAX-RPC 1.1 supports WS-I's Basic Profile (BP) 1.0. Since that time, the WS-I folks have developed BP 1.1 (and the associated AP 1.0 and SSBP 1.0). These new profiles clarify some minor points, and more clearly define attachments. JAX-WS 2.0 supports these newer profiles. For the most part, the differences between them do not affect the Java programming model. The exception is attachments. WS-I not only cleared up some questions about attachments, but they also defined their own XML attachment type: wsi:swaRef.
Many people are confused by all these profiles. You will need a little history to clear up the confusion.
WS-I's first basic profile (BP 1.0) did a good job of clarifying the various specs. But it wasn't perfect. And support for SOAP with Attachments (Sw/A) in particular was still rather fuzzy. In their second iteration, the WS-I folks pulled attachments out of the basic profile - BP 1.1 - and fixed some of the things they missed the first time around. At that point they also added two mutually exclusive supplements to the basic profile: AP 1.0 and SSBP 1.0. AP 1.0 is the Attachment Profile which describes how to use Sw/A. SSBP 1.0 is the Simple SOAP Binding Profile, which describes a web services engine that does not support Sw/A (such as Microsoft's .NET). The remaining profiles that WS-I has and is working on build on top of those basic profiles.
There are a number of changes to the Java language. JAX-WS relies on: annotations, generics, and executors. We will detail exactly how JAX-WS relies on this new functionality in follow-on tips. For information on these new features of Java, see the Java 5 link in Resources.
JAX-WS 2.0 is the successor to JAX-RPC 1.1. There are some things that haven't changed, but most of the programming model is different to a greater or lesser degree. The topics introduced in this tip will be expanded upon in a series of tips which we will publish over the coming months that will compare, in detail, JAX-WS and JAX-RPC. At a high level though, here are a few reasons why you would or would not want to move to JAX-WS from JAX-RPC.
Reasons you may want to stay with JAX-RPC 1.1:
Reasons to step up to JAX-WS 2.0: