[Engine-devel] Moving to Jboss AS7
by Oved Ourfalli
Hey all,
The code changes required to make the engine work on Jboss AS7 will soon be push
It will, of course, require you to install it, and start working with it :-)
A separate E-mail will be sent to notify you all once pushed, and then you'll have to perform the following steps:
1. Download jboss 7.1.0 Beta1b (http://download.jboss.org/jbossas/7.1/jboss-as-7.1.0.Beta1b/jboss-as-7.1....) - There is a newer version, but it has issues in the REST-API, so we decided to work with the beta version until a proper fix will be released.
2. Fetch the latest changes from our git repository
3. Change the Jboss home to the new path, both in the JBOSS_HOME environment variable, and in maven settings file (~/.m2/settings.xml)
4. Build the engine, with profiles "dep" and "setup". This will put all the proper configuration files, postgresql driver and make all the other needed changes in Jboss in order to make it work properly
mvn clean install -Psetup,dep .......
5. In order to run Jboss go to JBOSS_HOME/bin and run ./standalone.sh
6. Look inside the JBOSS_HOME/bin/standalone.conf file in order to enable jboss debugging (just uncomment the line JAVA_OPTS="$JAVA_OPTS -Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=n")
7. If you have a krb5.conf file you are working with, put it in JBOSS_HOME/standalone/configuration directory
8. Run Jboss (and be impressed by the startup speed!)
The above will be also added to the wiki page for building the engine as soon as the patches will be pushed upstream.
Some facts about Jboss 7:
1. It supports both standalone deployment, and domain deployment. We use the standalone one.
2. Stuff related to the standalone mode can be found in the JBOSS_HOME/standalone directory:
* configuration - contains the main configuration file called standalone.xml file, plus some other configuration files
* deployments - that's where your deployments should be. When adding a new one, don't forget to create a file called "<deployment-name>.dodeploy" in order to make it deploy.
* log - that's where the log files are written (unless stated differently in the standalone.xml file).
3. The different modules that come with Jboss 7 are located in JBOSS_HOME/modules directory
* No more common/lib directory.
* Every module has a module.xml file which contains it's dependencies in other modules, the jars that are part of the module, and etc.
* In order to use a dependency from there you have to add "Dependencies" section to your manifest file (do git grep "Dependencies" to take a look at some examples done in the engine source code).
4. Useful links:
* Documentation - https://docs.jboss.org/author/display/AS7/Documentation
* Class loading changes - https://docs.jboss.org/author/display/AS7/Class+Loading+in+AS7
* The Jboss community - http://community.jboss.org/wiki
Please send issues/feedback to this mailing list.
Thank you all,
Oved
12 years, 9 months
[Engine-devel] Simplifying our POJOs
by Mike Kolesnik
--=_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,<br><br>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:<br><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>.<br><br>This, in tu=
rn, reduces their readability and maintainability for a couple of reasons (=
that I can think of):<br><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? <br></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 <strong>don't</strong>
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><br><=
span style=3D"font-weight: bold;">So what can be done to remedy the situati=
on?</span><br><br>We could, of course, try to simplify the classes as much =
as we can and maybe address some of the issues.<br>This won't alleviate the=
boilerplate code problem altogether, though.<br><br>We could write annotat=
ions to do some of the things for us automatically.<br>The easiest approach=
would be runtime-based, and would hinder performance.<br>This also means w=
e need to maintain this "infrastructure" and all the implications of such a=
decision.<br><br><br><span style=3D"font-weight: bold;">Luckily, there is =
a much easier solution: Someone else already did it!</span><br><br>Check ou=
t Project Lombok: http://projectlombok.org<br>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.<br>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).<br>However, it's also possible to create the methods =
yourself if you want them to behave differently.<br>Outside the POJO itself=
, you would see it as you would always see it.<br><br>So what are the downs=
ides to this approach?<br><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><br>Even given these possible downside=
s, I think that we would benefit greatly if we would introduce this library=
.<br><br>If you have any questions, you're welcome to study out the project=
site which has very thorough documentation: http://projectlombok.org<br><b=
r>Your thoughts on the matter?<br><br><div><span name=3D"x"></span>Regards,=
<br>Mike<span name=3D"x"></span><br></div><br></div></body></html>
--=_fc18606d-6d0a-46bb-9d9b-34be55a9dcf7--
12 years, 9 months
[Engine-devel] Using categories in the Feature pages
by Oved Ourfalli
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
12 years, 9 months
[Engine-devel] multiple destinations for disks in create/import template?
by Jon Choate
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?
12 years, 9 months
[Engine-devel] adding a second disk to a new VM
by Jon Choate
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?
12 years, 9 months
[Engine-devel] in the UI - missing list of storage domains in detach modal
by Jon Choate
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'
12 years, 9 months
[Engine-devel] oVirt upstream meeting - setup networks MOM
by Roy Golan
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
12 years, 9 months
[Engine-devel] Problem working with LDAP domains
by Oved Ourfalli
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
12 years, 9 months
[Engine-devel] agenda for today's meeting
by Livnat Peer
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
12 years, 9 months
