Failed to create schema for JAX-B, only during CORS call for REST service

I have developed a REST service / resource that runs in Glassfish 4 and also designed a UI in AngularJS. When I deploy the UI code via a WAR file (along with the REST code) to Glassfish and test access directly from the browser accessing the Glassfish app ( http: // localhost: 8080 ) everything works as expected.

However, the strange thing is that when I deploy the UI code separately to the Tomcat server (running on port 8090) one of the GET requests (which returns a Response with an entity like Map keyValues ​​= new HashMap (); ... doesn't even have access either to one of my entity classes). I got the following error in the Glassfish server log:

Severe: Failed to create schema for JAX-B members com.sun.xml.bind.v2.runtime.IllegalAnnotationsException: 2 counts IllegalAnnotationExceptions The "salesOrderUid" property has an XmlID annotation, but its type is not a string. this issue is related to the following location: at public int business.salesOrderMgmt.entity.SalesOrder.getSalesOrderUid () at business.salesOrderMgmt.entity.SalesOrder in private business .salesOrderMgmt.entity.SalesOrder business.salesOrderMgmt.Lineity.Sales.salesOrder. salesOrderMgmt.entity.SalesOrderLine on private java.util.List business.salesOrderMgmt.entity.CatalogItem.salesOrderLines at business.salesOrderMgmt.entity.CatalogItem on private java.util.List business.salesOrderMgtems.catalog.sales entity.Item at private business.salesOrderMgmt.entity.Item business.salesOrderMgmt.entity.ProductCategoryItem.item at business.salesOrderMgmt.entity.ProductCategoryItem The class has two properties with the same name "salesOrderUid" this issue is related to the following location: at public int business. salesOrderMgmt.entity.SalesOrder.getSalesOrderUid () on business.salesOrderMgmt.entity.SalesOrder on private business .salesOrderMgmt.entity.SalesOrder business.salesOrderMgmt.entity.SalesOrderLine.salesOrder on businessLalesOrderLine on businessLalesOrder on privateList business.salesOrderMgmt.entity.CatalogItem.salesOrderLines at business.salesOrderMgmt.entity.CatalogItem on private java.util.List business.salesOrderMgmt.entity.Item.catalogItems at business.salesOrderMgmt.entity.Item at private business.salesOrderMgmt.entity.Item business.salesOrderMgmt.entity.ProductCategoryItem.item at business.salesOrderMgmt.entity.ProductCategoryItem this issue is due to the following location: at private int business.salesOrderMgmt.entity.SalesOrder.salesOrderMgmt.entity.SalesOrder. .entity.SalesOrder in private business .salesOrderMgmt.entity.SalesOrder business.salesOrderMgmt.entity.SalesOrderLine.salesOrder on business.salesOrderMgmt.entity.SalesOrderLine on private java.utilines.List business.salesOrder.Mgmt.Mt.List. .entity.CatalogItem on private java.util.List business.salesOrderMgmt.entity.Item.catalogItems at business.salesOrderMgmt.entity.Item on private business.salesOrderMgmt.entity.Item business.salesOrderMgmt.entity.ProductCategoryItem.item at business.salesOrderMgmt.entity.ProductCategoryItem

And on the Chrome console, I get the following error (which I believe is misleading because I am setting the "Access-Control-Allow-Origin" header on the server side before the response object is returned to the client / requester.

No "Access-Control-Allow-Origin" header is present on the requested resource. Origin ' http: // localhost: 8090 ' is therefore not allowed.

I find the Chrome / client-side error is misleading because on the server side I add a header for each response ("Access-Control-Allow-Origin", " http: // localhost: 8090 ") ... works for other requests, so why not work for that?

The strangest thing to me is that the REST resource method doesn't have access to entity classes that supposedly have invalid identity types. It calls the service to calculate taxes and shipping using the parameters passed to it, which are promotionCode, zipCode, and subTotal - no SalesOrder object.

There are two differences between this particular REST call and others that work: 1) This particular call passes parameters with the request, while the others do not, and 2) This request filter detects the HTTP method (OPTIONS).

Note that in all my resource REST methods, I include the following as a parameter to the "resourceMethod (@QueryParam (" callback ") String callback ...)" method.

Any ideas what might be causing these mysterious errors?

+3


source to share


1 answer


As I guessed, the errors were very buggy and not related to the problem. The browser "preempted" a GET request with an OPTIONS request that did not return the expected information to the browser to indicate that the browser / client-side application could continue.

I had to do two things: 1) Catch the OPTIONS method in the Request Filter and set the response headers, and 2) in the headers of the response filter set to allow CORS as well as methods and other headers .. Below are the code snippets:



@Provider
@PreMatching
public class RESTRequestFilter implements ContainerRequestFilter {

    private final static Logger log = Logger.getLogger( RESTRequestFilter.class.getName() );

    @Override
    public void filter( ContainerRequestContext requestCtx ) throws IOException {
        log.info( "Executing REST request filter" );
          requestCtx.getHeaders().add( "Access-Control-Allow-Credentials", "true" );
          requestCtx.getHeaders().add( "Access-Control-Allow-Origin", "http://localhost:8090");
          requestCtx.getHeaders().add( "Access-Control-Allow-Methods", "OPTIONS, GET, POST, DELETE, PUT" );
          requestCtx.getHeaders().add( "Access-Control-Allow-Headers", "Content-Type" );

        // When HttpMethod comes as OPTIONS, just acknowledge that it accepts...
        if ( requestCtx.getRequest().getMethod().equals( "OPTIONS" ) ) {
           log.info( "HTTP Method (OPTIONS) - Detected!" );

            // Just send a OK signal back to the browser (Abort the filter chain with a response.)
           Response response = Response.status( Response.Status.OK )
                   .header("Access-Control-Allow-Methods", "GET, POST, DELETE, PUT")
                   .header("Access-Control-Allow-Origin", "http://localhost:8090")
                   .header("Access-Control-Allow-Headers", "Content-Type, accept, headers")
                   .build();           
           requestCtx.abortWith( response );

        }

    }

}

@Provider
@PreMatching
public class RESTResponseFilter implements ContainerResponseFilter {

    private final static Logger log = Logger.getLogger( RESTResponseFilter.class.getName() );

    @Override
    public void filter( ContainerRequestContext requestCtx, ContainerResponseContext responseCtx ) throws IOException {
        log.info( "Executing REST response filter" );

        // The following was required to permit testing outside the Application Server Container
//        responseCtx.getHeaders().add( "Access-Control-Allow-Origin", "http://127.0.0.1:53307" );
        responseCtx.getHeaders().add( "Access-Control-Allow-Origin", "http://localhost:8090");
        responseCtx.getHeaders().add( "Access-Control-Allow-Credentials", "true" );
        responseCtx.getHeaders().add( "Access-Control-Allow-Methods", "OPTIONS, GET, POST, DELETE, PUT" );
        responseCtx.getHeaders().add( "Access-Control-Allow-Headers", "Content-Type, Access-Control-Allow-Origin, Access-Control-Allow-Credentials, Access-Control-Allow-Methods, Access-Control-Allow-Headers, Authorization, X-Requested-With" );
    }
}

      

+4


source







All Articles