problem with sync classes in domain

Lukas Krejci lkrejci at redhat.com
Wed Aug 10 09:18:46 UTC 2011


Well, these sync classes are not exactly domain classes in the sense that they 
would be backed by the database but they are more of DTOs that are shared 
between the server/jar, cli and GUI (in the future, more detail below). I know 
that I could have just put them in the server/jar and be done with it but I 
thought that the domain is just a more logical place for them.

Why they use java.io.InputStream? It's a DTO produced by the export that 
provides a convenient way of storing the lazily initialized export file (the 
InputStream itself) and error messages / notes produced by the export (which 
is filled up while the input stream is being read). It is a way to provide the 
(future) GUI with a way of saying "here's your export file and here's what we 
have to say about it (thinks like "this might not import cleanly because blah 
blah, you need to make sure that blah blah" or "These 5 entities failed to 
export but otherwise it went fine. Are you okay with that?").

I know about the errors the GWT compiler gives out but since it is not harming 
anyone, I left it like that. These classes will never cross to the client side 
(at most they will be used by the GWT service impls to prepare the data for 
the GUI consumption in an efficient way).

Why I even bothered with a complicated approach like this? Currently, the 
export only handles system settings and metric templates and the XML it 
produces has 0.5MB (it's sent zipped up over the wire and it's only a few KB 
then) and I wanted to make sure we don't need several passes through that data 
(and thus either having to store it on the disk or in the memory serverside) 
to provide all the information to the user. This will become more of an issue 
when/if more is added to the export file (alert templates with all the configs 
for notifications, groups, roles, users, ...).

On Wednesday, August 10, 2011 10:21:17 Heiko W.Rupp wrote:
> Am 09.08.2011 um 23:51 schrieb John Mazzitelli:
> > It may be true that these classes are not going to be used by GWT
> > clients, however, we need to keep stuff out of the GWT compilation if
> > they a) are not to be intended to be used by GWT clients and/or b) they
> > can't be compiled by GWT.
> > 
> > We can discuss tomorrow how to fix this. We either a) must move these
> > out of the domain module entirely or b) figure out a good "exclusion"
> 
> Remember that there may be other clients that may need those
> classes.
> 
> > policy for putting things in domain but keeping them out of the GWT
> > compilation unit. We already have one class in domain where we are doing
> 
> So exclusion may make more sense.
> 
> The underlying question here is why domain classes need java.io


More information about the rhq-devel mailing list