problem with sync classes in domain

John Mazzitelli mazz at redhat.com
Wed Aug 10 13:24:15 UTC 2011


If these classes are ONLY ever used server-side (even if GWT service 
impl- which, as you state is also server side), you should probably not 
put them in domain - they should probably go in server/jar. this will 
avoid confusion in the future ("can I use this in the GWT UI? "Am I 
supposed to use this in the agent?") and, as we see, will cause errors 
if you do try to use them in the GWT UI.

domain typically implies usable everywhere - GWT UI, the agent and/or 
plugins, CLI, other remote clients.

If they truly need to be accessible outside of the RHQ server, then we 
need to look at exclusion.

When there is some doubt, ask for some peer review/opinions from the 
team to get a consensus where things should go. This, for example, is 
what Jay, myself and John did with our conversations regarding the BLOB 
situation in the drift code.


On 08/10/2011 05:18 AM, Lukas Krejci wrote:
> 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
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/rhq-devel


More information about the rhq-devel mailing list