Classes in shared depend upon server

Bug #734769 reported by Matt Giuca
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
MUGLE
Fix Released
Critical
Prageeth Silva

Bug Description

In the data-wrapper branch, the client-side build is not compiling, because some classes in 'shared' are depending upon classes in 'server'.

(On the command-line build, note that it doesn't come up if you write "ant javac" -- that is, compiling the server-side code only -- it's only an error if you run "ant" -- compile both the client and server-side code -- or actually run the dev server.)

mugle.shared cannot import anything from mugle.server, because when you compile the client code, you only compile mugle.client and mugle.shared.

That DevTeamExists is in mugle.shared implies that the exception can be constructed on either the client or server side, which is impossible for the client to do since it doesn't have access to the DevTeam class.

It looks like DevTeamExists only uses the DevTeam to get the urlname out. Therefore, an easy fix would be to modify DevTeamExists to accept a urlname rather than a whole DevTeam object:

    public DevTeamExists(String devTeamUrlName) {
        super("DevTeam '" + devTeamUrlName + "' already exists.");
    }

But before making that change, we need to ask: Does DevTeamExists need to be in 'shared', or is it just a server-side thing? I suppose the point is that only the server will construct this exception object, but it can propagate up to the client, and therefore it has to be in shared? In which case, I would recommend the above fix. I assume all the other exceptions can have similar fixes.

Revision history for this message
Matt Giuca (mgiuca) wrote :

De-assigning myself. If anyone else gets to it first, do so.

Changed in mugle:
assignee: Matt Giuca (mgiuca) → nobody
Revision history for this message
Prageeth Silva (prageethsilva) wrote :

Oh I thought I already fixed this yesterday or day before. Scott said it works fine now.

Changed in mugle:
assignee: nobody → Prageeth Silva (prageethsilva)
Revision history for this message
Prageeth Silva (prageethsilva) wrote :

gwtc:
     [java] Compiling module au.edu.unimelb.csse.mugle.Mugle
     [java] Validating newly compiled units
     [java] [ERROR] Errors in 'file:/home/prageeth/Desktop/Mugle/data-wrapper/src/au/edu/unimelb/csse/mugle/shared/model/GameFile.java'
     [java] [ERROR] Line 60: No source code is available for type java.io.InputStream; did you forget to inherit a required module?
     [java] [ERROR] Line 107: No source code is available for type java.io.PrintWriter; did you forget to inherit a required module?

Need to work around the java.io for GameFile.java

Changed in mugle:
status: Triaged → In Progress
Revision history for this message
Matt Giuca (mgiuca) wrote :

When I did it in trunk, it was in server, correct? So I think it broke because in data-wrapper it moved to shared.

I think this is an example of where we can't just naively use these data wrapper objects around database objects. We need to consider the use of it on the client. GameFile's contents will only really be used in two situations: by a direct HTTP GET or a direct HTTP POST from an upload box. The GWT will not be involved and its javascript doesn't need access to those files. So they don't need to be exposed to the client at all.

Therefore, move them to GameFileData and don't expose them to client, and this should be solved. The public GameFile constructor can, for the moment, simply take no contents, and create an empty file (I don't think GameFiles will usually be constructed on the client).

Revision history for this message
Scott Ritchie (sritchie) wrote :

Now that the data-wrapper branch has been merged it should work fine; the shared classes no longer need to know anything about the server.

From eclipses point of view, the only thing it is complaining about is the use of Java.io.*; in GameFile -> which will need to be wrapped client side when we figure out how to store blobs in the data store.

Revision history for this message
Matt Giuca (mgiuca) wrote :

You are right, this bug is no longer applicable, but it does not "work fine" ... a compiler error is not good!

As you point out, there is no longer a dependency from shared to server. But it is not only sufficient for shared not to depend upon server. It also may not depend upon any Java classes which are not available in GWTC.

Closing this bug, opening a new one, bug #736029.

Changed in mugle:
status: In Progress → Fix Committed
Matt Giuca (mgiuca)
Changed in mugle:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.