Bug 697114 - look to convert interfaces to concrete classes in GWT RPC interfaces
Summary: look to convert interfaces to concrete classes in GWT RPC interfaces
Keywords:
Status: NEW
Alias: None
Product: RHQ Project
Classification: Other
Component: Core UI
Version: 4.0.0.Beta1
Hardware: Unspecified
OS: Unspecified
medium
high
Target Milestone: ---
: ---
Assignee: Nobody
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: rhq4
TreeView+ depends on / blocked
 
Reported: 2011-04-15 21:23 UTC by John Mazzitelli
Modified: 2022-03-31 04:28 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed:
Embargoed:


Attachments (Terms of Use)

Description John Mazzitelli 2011-04-15 21:23:58 UTC
read: http://stackoverflow.com/questions/3059787/gwt-using-listserializable-in-a-rpc-call

That indicates we should not use interface classes like List or Set as params or return types in our RPC interfaces. I have not found this in the GWT docs, but this sounds like its true.

We do use List, Set and other interface types in some of our GWT service interfaces. We should go through and convert them to concrete classes. This might reduce the size of the app that needs to be downloaded and might speed up compilation times.

Comment 1 John Mazzitelli 2011-04-19 15:22:02 UTC
this will involve alot of work. Not only will we have to change the parameter types and return types for all GWT services, but it means all GWT Impls will need to change to use the concrete types which would (and almost certainly will) means changing SLSB API to use concrete types OR we do unchecked casting which could cause problems in the future if we change SLSB implementations.

For example:

in TagGWTService we have this:

    Set<Tag> addTags(Set<Tag> tags) throws RuntimeException;

We'd have to change both parameter and return type to this:

    HashSet<Tag> addTags(HashSet<Tag> tags) throws RuntimeException;

This means we need to change TagGWTServiceImpl from:

    public Set<Tag> addTags(Set<Tag> tags) throws RuntimeException {
        try {
            return SerialUtility.prepare(tagManager.addTags(getSessionSubject(), tags), "TagService.addTags");
        } catch (Throwable t) {
            throw getExceptionToThrowToClient(t);
        }
    }

to something like:

    public HashSet<Tag> addTags(HashSet<Tag> tags) throws RuntimeException {
        try {
            HashSet<Tag> results = new HashSet<Tag>(tagManager.addTags(getSessionSubject(), tags)); // new collection that is explicitly of concrete type HashSet
            return SerialUtility.prepare(results, "TagService.addTags");
        } catch (Throwable t) {
            throw getExceptionToThrowToClient(t);
        }
    }

which requires a duplicate HashSet object to be created, just so we can have a concreate class, which is probably stupid. So we would alternatively have to do something like:


    public HashSet<Tag> addTags(HashSet<Tag> tags) throws RuntimeException {
        try {
            HashSet<Tag> results = (HashSet<Tag>) tagManager.addTags(getSessionSubject(), tags); // unchecked cast - what if addTags isn't really returning a HashSet?
            return SerialUtility.prepare(results, "TagService.addTags");
        } catch (Throwable t) {
            throw getExceptionToThrowToClient(t);
        }
    }

This just does a cast to the concrete type - but requires us to know the SLSB implementation details - that is, what is the actual concrete type that it is returning.

The other alternative is to change the SLSB API to explicitly return the concrete type, so TagManager would be something like "HashSet addTags(....)". The negative of this is it now forces changes to everyone calling that API, which may affect remote interfaces/clients/CLI scripts.


Note You need to log in before you can comment on or make changes to this bug.