2 Replies Latest reply on Sep 20, 2012 9:18 PM by Matthew Casperson

    Streamline classes listed in ErraiApp.properties

    Matthew Casperson Newbie

      We use JAX-RS between Errai and standard Java EE projects, so we avoid non-standard annotations like @Portable. This means that all classes sent between the REST server and the Errai app need to be listed in the ErraiApp.properties file. Lately this has become quite hard to maintain, as every class needs to be listed individually.

       

      Is there any possibility of being able to make classes Portable through the use of wildcards. So instead of having a ErraiApp.properties file like

       

      errai.marshalling.serializableTypes=org.jboss.pressgang.ccms.rest.v1.entities.RESTUserV1 org.jboss.pressgang.ccms.rest.v1.entities.RESTRoleV1 org.jboss.pressgang.ccms.rest.v1.entities.RESTTagV1 org.jboss.pressgang.ccms.rest.v1.entities.RESTProjectV1
      

       

      You would use something like

       

      errai.marshalling.serializableTypes=org.jboss.pressgang.ccms.rest.v1.entities.*
      
        • 1. Re: Streamline classes listed in ErraiApp.properties
          Mike Brock Master

          This has come up before and I've thus far resisted implementing this feature. The main reason is I am a bit of a security nut when it comes to marshalling. There's a reason why I didn't allow @Portable to be inherited. And I didn't add implicit marshallability -- I want it to be very clear exactly what model is exposed to the wire.

           

          In general, with Errai, we try to err on the side of convenience, but this is one of those areas where we've treaded carefully. And the exemption of wildcards was quite deliberate.

           

          That said, I'd consider adding this in conjunction with a new flag. But I'd also probably want to output a warning with all the implicit portable types on startup. =)

          • 2. Re: Streamline classes listed in ErraiApp.properties
            Matthew Casperson Newbie

            For our project, a new flag and an output would definitely be preferable. To deal with the increasing number of classes we need to list in ErraiApp.properties, we generate the list from a simple script, which (in hindsight) removes any incidental security that would have been found in manually adding the classes to the properties file. So maybe a list and a count of the classes made portable would be a improvement - I'd see tthe compiler output and notice a change in the total number of portable classes more often than I would look through the list of classes listed in ErraiApp.properties.