java.lang.SecurityException: Unsupported keysize or algorithm or java.security.InvalidKeyException: Illegal key size

I have faced this issue when working with the Bouncy Castle Provider and the reason for that is the JCE files are not updated in the JVM. To fix it, one needs to download the JCE unrestricted policy files from oracle site, e.g download and copy the local_policy.jar and the US_export_policy.jar to jre/lib/security. This fixes the issue

Got the solution from the Frequently asked questions for Bouncy Castle, here

Copying properties from one object to another

There is always a need to copy the properties from one object to another if they have the same property names. There are available apis like Dozer which facilitates the same, but we need to add the dozer.jar in the classpath which may not always be the right approach and for certain clients can be a lengthy process to get permission.

There are alternative good ways of doing this, if you are using the Spring framework or already use the apache projects. Mentioning below few of the steps how we can do this

Using Apache BeanUtils

BeanUtils.copyProperties(targetObject, sourceObject);

this copies the values of the properties with the same name from the sourceObject  to targetObject. The problem with simply this step is that it will throw and exception if any of the values is null. To avoid the exception we can add the following lines before the copy

BeanUtilsBean.getInstance().getConvertUtils().register(false, false, 0); //This will work with apache-beanutils version 1.8 and above.

Using Springs WrapperImpl

  final PropertyDescriptor[] propertyDescriptors =
        BeanUtils.getPropertyDescriptors(source.getClass());

  final BeanWrapper src = new BeanWrapperImpl(source);
  final BeanWrapper trg = new BeanWrapperImpl(target); 
  for(final PropertyDescriptor propertyDescriptor : propertyDescriptors){
        String propName = propertyDescriptor.getName();

         trg.setPropertyValue(
            propName,
            src.getPropertyValue(propName)
        );
    } 

 
The above steps copies all properties from source to target. If needed we can also remove some properties from the propertyDescriptors if not to be copied 

How to insert multiple rows into a table from values in same table or another

This can be done by

Single table

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' )

Multiple Table

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 )

How to generate JAXB classes from xsd

if there is any application server installed in the machine, in the bin directory one can find the xjc bat file. To generate classes

cmd>xjc PRPA_IN201310UV02.xsd -p com.covisint.cep.healthcare.hl7v3.pix.jaxb.response

where PRPA_IN201310UV02.xsd is the xsd file and the -p is the package under which the files needs to be generated.

The other options are as follows

OPTIONS

-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:

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

In addition, the ordering of the schema files and binding files on the command line does not matter.

-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 -host and -port are 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 the top command, 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 and customizations.

-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.

Summary of Deprecated and Removed Command Line Options

-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.

Changing Default GlassFish v3 Prelude Port Numbers 4848, 8080, and 8181 (The Open Road)

1. To change the HTTP port to 10080:
   
   asadmin set server.http-service.http-listener.http-listener-1.port=10080
   
   
2. To change the HTTPS port to 10443:
   
   asadmin set server.http-service.http-listener.http-listener-2.port=10443
   
   
3. To change the administration server port to 14848:
   
   asadmin set server.http-service.http-listener.admin-listener.port=14848
   

How To Fix LinkageError when using JAXB with JDK 1.6

If you run across an error like this when trying to use JAXB:

java.lang.LinkageError: JAXB 2.0 API is being loaded from the bootstrap classloader, but this RI
(from jar:file:/somedirectory/jaxb-impl.jar!/com/sun/xml/bind/v2/model/impl/ModelBuilder.class) needs 2.1 API. Use the endorsed directory mechanism to place jaxb-api.jar in the bootstrap classloader. (See http://java.sun.com/j2se/1.5.0/docs/guide/standards/)

This is apparently only a problem with JDK 1.6, not with JDK 1.5. It can be fixed by setting the JRE to 1.6.21 or 1.6.24 patches and not the 1.6 version

It can als be fixed by putting the jaxb-api.jar that you're trying to use into JDK_HOME/jre/lib/endorsed. If the endorsed directory doesn't exist, make it.

Error while configuring Jersey in JBOSS 5.1.0.GA

15:46:27,736 WARNING [AnnotatedClassScanner] URL, vfszip:/F:/Covisint HIE/jboss-5.1.0.GA/server/default/deploy/RestFulPrj.war/WEB-INF/classes/com/rest/cannot be converted to a URI

15:46:27,879 INFO [WebApplicationImpl] Initiating Jersey application, version 'Jersey: 1.1.1-ea-SNAPSHOT 07/13/2009 06:16 AM'

15:46:28,189 SEVERE [WebApplicationImpl] The ResourceConfig instance does not contain any root resource classes.

15:46:28,190 ERROR [[/RestFulPrj]] StandardWrapper.Throwable

com.sun.jersey.api.container.ContainerException: The ResourceConfig instance does not contain any root resource classes.

Are you deploying resources classes in a jar in WEB-INF/lib ?

The issue was fixed for the scheme of "vfsfile" but not for a scheme
of "vfszip".

Looking at the URL: vfszip:/F:/Covisint HIE/jboss-5.1.0.GA/server/default/deploy/RestFulPrj.war/WEB-INF/classes/com/rest/cannot be converted to a URI is a JBOSS propriety code to access the jar

This has been solved by adding all the jersey 1.3 snapshot jars instead of jersey 1.1.1 jars which i had previously from the loc http://download.java.net/maven/2/com/sun/jersey/