- Devel - oVirt List Archives

[Engine-devel] Simplifying our POJOs
by Mike Kolesnik 06 Feb '12

06 Feb '12

--=_fc18606d-6d0a-46bb-9d9b-34be55a9dcf7 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, Today many POJO s are used throughout the system to convey data: =E2=80=A2 Parameters - To send data to commands. =E2=80=A2 Business Entities - To transfer data in the parameters & to/f= rom the DB. These POJOs are (usually) very verbose and full of boilerplate code . This, in turn, reduces their readability and maintainability for a couple o= f reasons (that I can think of): =E2=80=A2 It's hard to know what does what: =E2=80=A2 Who participates in equals/hashCode? =E2=80=A2 What fields are printed in toString? =E2=80=A2 Consistency is problematic: =E2=80=A2 A field may be part of equals but not hashCode, or vice v= ersa. =E2=80=A2 This breaks the Object.hashCode() contract! =E2=80=A2 Adding/Removing fields take more time since you need to synchronize the cha= nge to all boilerplate methods. =E2=80=A2 Again, we're facing the consistency problem. =E2=80=A2 These simple classes tend to be very long and not very readable. =E2= =80=A2 Boilerplate code makes it harder to find out which methods don't beh= ave the default way. =E2=80=A2 Javadoc, if existent, is usually meaningless (but you might s= ee some banal documentation that doesn't add any real value). =E2=80=A2 Our existing classes are not up to standard! So what can be done to remedy the situation? We could, of course, try to simplify the classes as much as we can and mayb= e address some of the issues. This won't alleviate the boilerplate code problem altogether, though. We could write annotations to do some of the things for us automatically. The easiest approach would be runtime-based, and would hinder performance. = This also means we need to maintain this "infrastructure" and all the impli= cations of such a decision. Luckily, there is a much easier solution: Someone else already did it! Check out Project Lombok: http://projectlombok.org What Lombok gives us, among some other things, is a way to greatly simplify= our POJOs by using annotations to get the boilerplate code automatically g= enerated. This means we get the benefit of annotations which would simplify the code = a whole lot, while not imposing a performance cost (since the boilerplate c= ode is generated during compilation). However, it's also possible to create the methods yourself if you want them= to behave differently. Outside the POJO itself, you would see it as you would always see it. So what are the downsides to this approach? =E2=80=A2 First of all, Lombok provides also some other capabilities wh= ich I'm not sure are required/wanted at this time. =E2=80=A2 That's why I propose we use it for commons project, and m= ake use of it's POJO-related annotations ONLY. =E2=80=A2 There might be a problem debugging the code since it's auto-generated. =E2=80=A2 I think this is rather negligible, since usually you don'= t debug POJOs anyway. =E2=80=A2 There might be a problem if the auto-generated code throws an Exception. =E2=80=A2 As before, I'm rather sure this is an edge-case which we = usually won't hit (if at all). Even given these possible downsides, I think that we would benefit greatly = if we would introduce this library. If you have any questions, you're welcome to study out the project site whi= ch has very thorough documentation: http://projectlombok.org Your thoughts on the matter? Regards, Mike --=_fc18606d-6d0a-46bb-9d9b-34be55a9dcf7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html><head><style type=3D'text/css'>p { margin: 0; }</style></head><body><= div style=3D'font-family: Times New Roman; font-size: 12pt; color: #000000'= >Hi, Today many <a href=3D"http://en.wikipedia.org/wiki/Plain_Old_Ja= va_Object">POJO</a>s are used throughout the system to convey data: <ul>= <li>  Parameters - To send data to commands.</li><li>  Business E= ntities - To transfer data in the parameters & to/from the DB.</li></ul= >These POJOs are (usually) very verbose and full of <a href=3D"http://en.wi= kipedia.org/wiki/Boilerplate_code">boilerplate code</a>. This, in tu= rn, reduces their readability and maintainability for a couple of reasons (= that I can think of): <ul><li>It's hard to know what does what:</li><ul>= <li>Who participates in equals/hashCode?</li><li>What fields are printed in= toString?  </li></ul><li>Consistency is problematic:</li><ul><li>= A field may be part of equals but not hashCode, or vice versa.</li><li>This= breaks the <a href=3D"http://docs.oracle.com/javase/6/docs/api/java/lang/O= bject.html#hashCode%28%29">Object.hashCode()</a> contract!</li></ul><li>Adding/Removing fields take more time since you nee= d to synchronize the change to all boilerplate methods.</li><ul><li>Again, we're= facing the consistency problem.</li></ul><li>These simple classes tend to b= e very long and not very readable.</li><li>Boilerplate code makes it harder to fin= d out which methods don't behave the default way.</li><li>Javadoc, if existent, is usually meaningle= ss (but you might see some banal documentation that doesn't add any real value).</li><li>Our existing classes are not up to standard!</li></ul> <= span style=3D"font-weight: bold;">So what can be done to remedy the situati= on? We could, of course, try to simplify the classes as much = as we can and maybe address some of the issues. This won't alleviate the= boilerplate code problem altogether, though. We could write annotat= ions to do some of the things for us automatically. The easiest approach= would be runtime-based, and would hinder performance. This also means w= e need to maintain this "infrastructure" and all the implications of such a= decision. Luckily, there is = a much easier solution: Someone else already did it! Check ou= t Project Lombok: http://projectlombok.org What Lombok gives us, among s= ome other things, is a way to greatly simplify our POJOs by using annotatio= ns to get the boilerplate code automatically generated. This means we ge= t the benefit of annotations which would simplify the code a whole lot, whi= le not imposing a performance cost (since the boilerplate code is generated= during compilation). However, it's also possible to create the methods = yourself if you want them to behave differently. Outside the POJO itself= , you would see it as you would always see it. So what are the downs= ides to this approach? <ul><li>First of all, Lombok provides also some o= ther capabilities which I'm not sure are required/wanted at this time.</li>= <ul><li>That's why I propose we use it for commons project, and make use of= it's POJO-related annotations ONLY.</li></ul><li>There might be a problem = debugging the code since it's auto-generated.</li><ul><li>I think this is r= ather negligible, since usually you don't debug POJOs anyway.</li></ul><li>= There might be a problem if the auto-generated code throws an Exception.</l= i><ul><li>As before, I'm rather sure this is an edge-case which we usually = won't hit (if at all).</li></ul></ul> Even given these possible downside= s, I think that we would benefit greatly if we would introduce this library= . If you have any questions, you're welcome to study out the project= site which has very thorough documentation: http://projectlombok.org <b= r>Your thoughts on the matter? <div>Regards,= Mike </div> </div></body></html> --=_fc18606d-6d0a-46bb-9d9b-34be55a9dcf7--

5 10

[Engine-devel] Using categories in the Feature pages
by Oved Ourfalli 05 Feb '12

05 Feb '12

Hey all, When you write a feature page, please make sure you end it with: [[Category:Feature]] We will add a link to this category, so that features will be easier to track. In your detailed feature page, put: [[Category:DetailedFeature]] And in the design page put: [[Category:FeatureDesign]] If the feature is simple enough, and creating all the three pages is an overkill, then create the first one (with the correct category), and put all the details there. Thank you, Oved

2 2

[Engine-devel] multiple destinations for disks in create/import template?
by Jon Choate 05 Feb '12

05 Feb '12

Given the changes for multiple storage domains, do we want to allow a user to specify multiple storage domains per disk when creating or importing a template? Otherwise the user will need to use the copy(clone) template disk afterwards to create the copies of the storage domain disks where they want them. If so, what would the UI look for this? It would require the backend to receive something that looks like Map<DiskImage, List<StorageDomain>>. thoughts?

4 4

[Engine-devel] adding a second disk to a new VM
by Jon Choate 04 Feb '12

04 Feb '12

When creating new VM, you are asked if you want to add a virtual disk. If you do, you are asked if you want to add another. The issue is that while the first disk is being added, the VM is locked so unless the first disk is added very quickly, a second disk cannot be added and the user will get an error saying that the VM is not down. I think user may find this confusing and/or annoying. Is there anything that can be done to improve this experience?

3 2

[Engine-devel] Floating Disk feature description
by Daniel Erez 03 Feb '12

03 Feb '12

Hi, Floating Disk feature description Wiki page: http://www.ovirt.org/wiki/Features/DetailedFloatingDisk Best Regards, Daniel

6 17

[Engine-devel] in the UI - missing list of storage domains in detach modal
by Jon Choate 02 Feb '12

02 Feb '12

In the Data Center tab, if you select a storage domain to detach, a modal dialog box pops up saying "Are you sure you want to Detach the following storage(s)?". Below this there are no storage domains listed. I would suggest either listing them or changing the word 'following' to 'selected'

2 1

[Engine-devel] oVirt upstream meeting - setup networks MOM
by Roy Golan 02 Feb '12

02 Feb '12

Setup networks feature have been introduced and few question rose: mgoldboi asked to give attention to error handling or reporting AI - need to make sure I have proper error codes from VDSM on validation,failure in committing the new topology etc... acathrew raised an issue of known configuration that won't work e.g specific bonding over bridge that should fail AI - gather those improper configuratations ( Andy pls reply with the exact details if you have them) lpeer asked to set a UI sync meeting lead by them - done Thanks, Roy

1 0

[Engine-devel] Problem working with LDAP domains
by Oved Ourfalli 01 Feb '12

01 Feb '12

Hey all, There was an issue a week ago of problem performing DNS SRV records queries from the engine, and it caused issues when working with LDAP. In order to fix these issues please make sure you copy the file: <src>/deployment/modules/sun/jdk/main/module.xml To: $JBOSS_HOME/modules/sun/jdk/main/module.xml You should do that even if you are only working with the internal domain, as one day you might try to work with LDAP one. Note that a fix for that was posted, and it is a part of the RPMs as well, so it is only relevant for people who already have this environment set up, and not for new environments. Thank you, Oved

1 0

[Engine-devel] agenda for today's meeting
by Livnat Peer 01 Feb '12

01 Feb '12

Hi All, This week we'll continue the agenda from last meeting: - setupNetworks API - stable device addresses if we have time - Hot plug NIC - Direct LUN - Serialized commands Thanks, Livnat

1 1

[Engine-devel] ovirt core MOM
by Livnat Peer 01 Feb '12

01 Feb '12

Hi All, This is what we've discussed in the meeting today: Multiple storage domain: - Should have a single generic verb for removing a disk. - We block removing the last template disk - template is immutable. - We add a shared logic for multiple actions of cloning a disk. Clone VM from Snapshot: - Shared disk and direct LUN are open issues, Yair will start a discussion on this upstream. - The suggestion was to mark direct LUN and shared disk as unplugged disks when taking a snapshot. - We had no time to discuss setup networks and stable device addressed, we'll discuss this on the next meeting. Thanks, Livnat

4 14