Re: [Engine-devel] VDSM Fake
On 30.4.2013 13:44, Yair Zaslavsky wrote: Great job. I guess you're communicating in "in-secure" way with fake-vdsm? Yes, I turned off SSL, but to add keys to e.g. Tomcat should not be difficult. The server load will increase a little bit. :) - Original Message - From: "Libor Spevak" To: "Liran Zelkha" Cc: engine-devel@ovirt.org Sent: Tuesday, April 30, 2013 2:00:33 PM Subject: Re: [Engine-devel] VDSM Fake I didn't have enough time to make a real stress test, I created 100 hosts running 300 VMs, all-in-one - one server running Engine, DB, VDSM Fake. I put the VMs into running state and tried migration. It was rather responsive. The server had still enough resources. On 30.4.2013 12:48, Liran Zelkha wrote: Awesome. I really need this for the stress tests I'm running. How many hosts were you able to simulate with one web application? ----- Original Message - From: "Libor Spevak" To: engine-devel@ovirt.org Sent: Tuesday, April 30, 2013 12:50:52 PM Subject: [Engine-devel] VDSM Fake Hi, let me introduce an experimental project called VDSM Fake. This is a small Java web application simulating selected VDSM features, but only from the Engine point of view. The aim was to get oVirt-Engine top performance characteristics in core features simulating hundreds of fake hosts and VMs, and in ecologic way. More info: http://www.ovirt.org/VDSM_Fake Sources: git clone git://github.com/lspevak/ovirt-vdsmfake.git git clone git://github.com/lspevak/ovirt-restapiconf.git Regards, Libor ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] VDSM Fake
I didn't have enough time to make a real stress test, I created 100 hosts running 300 VMs, all-in-one - one server running Engine, DB, VDSM Fake. I put the VMs into running state and tried migration. It was rather responsive. The server had still enough resources. On 30.4.2013 12:48, Liran Zelkha wrote: Awesome. I really need this for the stress tests I'm running. How many hosts were you able to simulate with one web application? - Original Message ----- From: "Libor Spevak" To: engine-devel@ovirt.org Sent: Tuesday, April 30, 2013 12:50:52 PM Subject: [Engine-devel] VDSM Fake Hi, let me introduce an experimental project called VDSM Fake. This is a small Java web application simulating selected VDSM features, but only from the Engine point of view. The aim was to get oVirt-Engine top performance characteristics in core features simulating hundreds of fake hosts and VMs, and in ecologic way. More info: http://www.ovirt.org/VDSM_Fake Sources: git clone git://github.com/lspevak/ovirt-vdsmfake.git git clone git://github.com/lspevak/ovirt-restapiconf.git Regards, Libor ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] VDSM Fake
Hi, let me introduce an experimental project called VDSM Fake. This is a small Java web application simulating selected VDSM features, but only from the Engine point of view. The aim was to get oVirt-Engine top performance characteristics in core features simulating hundreds of fake hosts and VMs, and in ecologic way. More info: http://www.ovirt.org/VDSM_Fake Sources: git clone git://github.com/lspevak/ovirt-vdsmfake.git git clone git://github.com/lspevak/ovirt-restapiconf.git Regards, Libor ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Move SQL out of stored procedures
Hi, apart from SQL vs. stored procedures discussion, I am trying to understand what we can get if we support more databases... Some points: 1. Is there a real need by end-users/customers to run it on e.g. Oracle only? (performance, stability, easier administration). What is the future of PostgreSQL? 2. Is it decided by architectural board, what kind of databases we would like to support? (cannot support any db) 3. Are we talking about the Engine only, or there will be a need to rewrite ETL mappings and upgrade DWH database, or maybe modify JasperReports templates (simply, some DB types behave differently)? Maybe we can look at JasperSoft solution, they support more databases. 4. Current full/incremental upgrade process of PostgreSQL is IMHO very good tuned (it is similar to dbmaintain.org tool - Java implementation - I used successfully on one project - after some changes of course). I do not believe we can use or easily develop general upgrade/migration tool, and XML based (I am sorry Alissa, not sure about Liquibase, I haven't studied it deeply, but there is a need to incrementally change db objects, but sometimes also to migrate data to new structures, the most flexible and quickest is to do it using native SQL, but yes, it depends on the project needs...). 5. As a developer, with every new column I need to write upgrade scripts, prepare test environments and test all scenarios several times on different databases, so time-consuming. On 27.3.2013 13:53, Itamar Heim wrote: On 03/26/2013 08:39 PM, Alon Bar-Lev wrote: - Original Message - From: "Juan Hernandez" To: engine-devel@ovirt.org Sent: Tuesday, March 26, 2013 7:34:04 PM Subject: [Engine-devel] Move SQL out of stored procedures Hello, I would like to start a discussion about the subject. I think this is something we need to do if one day we want to be able to use any database other than PostgreSQL. Hello, I think that database layer is a software interface like any other software interface, if done properly, a dba can convert the stored procedure to any other database without any code change. This way the database specific implementation lives within the database and maintained by the designated dba. Fixups and optimizations can be done in database without touching the code. Backward compatibility layer is much simpler to implement based on stored procedures than complex set of views and tables. Also, accessing the database via different technologies is simpler if there is maintained database interface (stored procedures). I've seen hibernate based java applications that promised to be database independent but at the edges when performance counts, the DAO became HQL, then a special dialect and finally database specific SQLS. there may be db specific optimization/logic, but I don't see why we need STPs for 80% (if not more) of the CRUD and basic queries. I also agree with Tal later in the thread that its a good question if we can't find a better solution than re-writing the sql's in the code ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Move SQL out of stored procedures
Hi, I would recommend always to avoid hard coding SQL into Java code. It is very hard to maintain and read. If there is something, which prevents using JPA/Hibernate, e.g. the database relational model doesn't reflect the object-oriented domain very well or we have to live with many stored procedures concurrently, I would choose a framework, which enables to externalize the SQL code (into XML). I worked on a larger project(s) with a lot of PL/SQL code, we moved to myBatis (previously iBatis) very soon for Java backend: https://code.google.com/p/mybatis/ Libor On 26.3.2013 18:34, Juan Hernandez wrote: Hello, I would like to start a discussion about the subject. I think this is something we need to do if one day we want to be able to use any database other than PostgreSQL. I did an small example of what it takes and how it looks like to have the SQL code into the DAOs: http://gerrit.ovirt.org/13347 It isn't rocket science, it isn't an exciting task, it isn't fun, but something I think we should eventually do. I appreciate any comment about how and when to do this, including those saying that instead of this primitive approach we should use this or that ORM framework. Regards, Juan Hernandez ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] REST API using BASH
On 6.3.2013 23:15, Eli Mesika wrote: - Original Message - From: "Libor Spevak" To: engine-devel@ovirt.org Sent: Wednesday, March 6, 2013 11:06:53 AM Subject: [Engine-devel] REST API using BASH Hi, let me introduce some basic concepts when using REST API from the command line. I hope, it would be useful for newcomers. Very useful in creating working instance from scratch. Are there any plans to extend it to cover more commands? Thanks It depends on available documentation and samples, too. Do you have ideas, what should be covered? The intent was to provide inspiration, not start a new project, but from practical point of view, extensions would be useful. E.g. probably everybody has tried curl and then grep, sed, ... for response, but XPath processing tool is more convenient for this task. http://www.ovirt.org/REST_API_Using_BASH_Automation Regards, Libor ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] REST API using BASH
Hi, let me introduce some basic concepts when using REST API from the command line. I hope, it would be useful for newcomers. E.g. probably everybody has tried curl and then grep, sed, ... for response, but XPath processing tool is more convenient for this task. http://www.ovirt.org/REST_API_Using_BASH_Automation Regards, Libor ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Engine table comments
Thanks for the confirmation. Appending a template for the columns :-) /psql engine -U postgres -c "SELECT 'COMMENT ON COLUMN ' || table_name || '.' || column_name || ' IS TODO;' sql FROM information_schema.columns where table_schema='public' order by table_name, column_name" > comments_columns_to_do.sql// / It looks like we have cca 73 tables and 2353 columns now. So probably better to start with the tables. On 26.2.2013 15:03, Yair Zaslavsky wrote: I think your idea is very good. I also think we should have it for columns as well. But since we already have many columns, maybe we should have an "on going effort" from various developers on this (i.e - each developer will do that for several tables). Thoughts? ---- *From: *"Libor Spevak" *To: *engine-devel@ovirt.org *Sent: *Tuesday, February 26, 2013 2:37:17 PM *Subject: *[Engine-devel] Engine table comments Hi, I would like to propose to create a patch assigning sql comment to each Engine table. The comments will be a part of the exported DB schema report, too. The terminology is not always consistent across all application layers, so for the newcomers it would be easier to understand the model. But, what would be general guidelines? I recommend to use singular form of entity name as used from end-user point of view (if somehow visible, of course), or just used frequently inside code. Examples: storage_pool ... Data center vds_groups ... Cluster but: vm_static ... Virtual machine configuration vm_dynamic ... Virtual machine runtime data vm_statistics ... Virtual machine statistics data ... etc. This command prepares a template for the patch: /psql engine -U postgres -c "select 'COMMENT ON TABLE ' || relname || ' IS ''TODO'';' sql from pg_stat_user_tables t WHERE schemaname='public' order by t.relname" > comments_to_do.sql// / or just I can prepare a page on the wiki with table containing table names and volunteers :-) can propose simple understandable comments for known tables. Is it useful? Thanks. Regards, Libor ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] Engine table comments
Hi, I would like to propose to create a patch assigning sql comment to each Engine table. The comments will be a part of the exported DB schema report, too. The terminology is not always consistent across all application layers, so for the newcomers it would be easier to understand the model. But, what would be general guidelines? I recommend to use singular form of entity name as used from end-user point of view (if somehow visible, of course), or just used frequently inside code. Examples: storage_pool ... Data center vds_groups ... Cluster but: vm_static ... Virtual machine configuration vm_dynamic ... Virtual machine runtime data vm_statistics ... Virtual machine statistics data ... etc. This command prepares a template for the patch: /psql engine -U postgres -c "select 'COMMENT ON TABLE ' || relname || ' IS ''TODO'';' sql from pg_stat_user_tables t WHERE schemaname='public' order by t.relname" > comments_to_do.sql// / or just I can prepare a page on the wiki with table containing table names and volunteers :-) can propose simple understandable comments for known tables. Is it useful? Thanks. Regards, Libor ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] DB Schema Reports
Hi, let me announce new database schema reports based on the SchemaSpy Java library available. Thanks to infra group for support, especially to David Caro, who set up Mr. Jenkins's jobs. oVirt-Engine: http://resources.ovirt.org/dbreports/latest/engine/public/index.html oVirt-DWH: http://resources.ovirt.org/dbreports/latest/dwh/public/index.html Wiki: http://www.ovirt.org/DB_model Regards, Libor ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] DB Performance Monitoring
On 21.2.2013 17:11, Eli Mesika wrote: - Original Message - From: "Libor Spevak" To: engine-devel@ovirt.org Sent: Tuesday, February 19, 2013 5:44:10 PM Subject: [Engine-devel] DB Performance Monitoring Hi, I just wanted to share a partial result from testing of engine db load during operation (SQL queries frequencies). Maybe, we can decide later, if some SQL queries result CACHING can boost throughput for larger deployments. The caching technology can be from a simple HashMap lookup to deployments of something like http://ehcache.org/ (memory database). I prepared two simple scenarios: - oVirt engine, 2 hosts, 1 VM, running 15 minutes (Power on + Up state) - oVirt engine, 2 hosts, 10 VMs from one pool, running 15 minutes (Power on + Up state) Appending 2 spreadsheets with data about the most used SQL queries (generated by PostgreSQL standard pg_statements_stat module). e.g. - 2nd row shows number of granted connections from the db pool (e.g. can be used to set optimal connection pool size) (check of connection health: select 1) - most of the queries are wrapped by a PLSQL function so we see a wrapper: select * from getvdsgroupbyvdsgroupid($1, $2, $3) and near to it the 'real' query: SELECT vds_groups_view.* FROM vds_groups_view WHERE vds_group_id = v_vds_group_id AND (NOT v_is_filtered OR EXISTS (SELECT 1 FROM user_vds_groups_permissions_view WHERE user_id = v_user_id AND entity_id = v_vds_group_id)) Just as an example, I selected in yellow color some queries, which probably do not change often, but are very frequent. Thanks Libor for taking te time to do that. The problematic queries are those that involves all kinds of *permissions* checks with the complicated & expensive permission handling views. I believe that using Snapshot Materialized Views as defined in http://www.ovirt.org/OVirt-DB-Issues/MaterializedViews will solve the major part of those problems. We are currently verifying this approach and my recommendation is to have all *permissions* views as Snapshot Materialized Views that are updated via a cron job. I think there could be performace improvement with M-views, of course. There is some overhead just with their maintainance, e.g. refreshing, updating existing dependent objects (table name renames, ...), not sure about NATIVE implementation level status in PostgreSQL, according to e.g. Oracle db capabilities (MV-logs + M-views). http://wiki.postgresql.org/wiki/Materialized_Views Still, if the Engine gathers statistics nearly in real time, my question would be, if there is a need of round-trip to the database and back at all for frequent queries. Other tools like 'pg_top' can provide runtime statistics of db processes (cpu, mem, locks, ... views). By enabling debug level logging of PostgreSQL we can check real values to the queries. Of course, it would be useful to run such tests with many hosts and VMs to predict scaling issues. More info about tools configuration: http://www.ovirt.org/Engine_database_performance_monitoring Regards, Libor ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] REST API calls from the GUI
It looks like there are several frameworks trying to support GWT and/or XML/JSon serialization, but still there is a lot of work to do + compatibility problems with the latest versions of GWT, etc. I investigated a little bit Restlet framework, which looked promising. The online documentation available is very limited. But good place to look is the book 'Restlet in Action'. Project examples: (size: 500M) git clone https://github.com/restlet/restlet-framework-java.git cd restlet-framework-java/modules/org.restlet.example.book.restlet.ch09.gwt Info from the book: "GWT and Restlet versions Restlet Framework version 2.0 supports version 2.0 and 2.1 of Google Web Toolkit, but not later, due to API breaking changes introduced in GWT 2.2. Restlet Framework version 2.1 supports GWT 2.3 and above, but not previous versions." but: "At the time of writing, the deferred binding support of Restlet only supports the special GWT object serialization format. In future versions, XML and JSON-based formats could be added by leveraging the Piriti library. This library provides JSON and XML mappers for GWT based on annotations and deferred binding. Further details are available on Google Code at http://code.google.com/p/piriti/."; Just DomRepresentation object and "manual" parsing is probably possible now. Still waiting for a hope, now 'piriti'? :-) git clone https://github.com/hpehl/piriti Has anybody seen it in action? On 15.2.2013 20:37, Vojtech Szocs wrote: Hi Daniel, The first alternative can be implemented by using GWT RequestBuilder (for sending the HTTP requests) and GWT overlay types (that can be generated from java POJOs). Probably best performance-wise/less data type conversions/etc; However, basically means writing a JavaScript SDK. Yes, we can use RequestBuilder for making AJAX HTTP requests, but using GWT overlay types is possible only if REST API fully supports JSON format. In case of XML format, we would have to use GWT XMLParser to map "restapi-types" entities/collections to/from XML strings, e.g. we could write GWT deferred binding generators to generate such mappers from current schema. The benefit of the second alternative is currently rather vague since the Java SDK can't be converted to JavaScript as is (can't use apache.commons and javax packages in GWT client side). Need to check how easily they can be replaced with JRE libraries that GWT can emulate (for supporting both GWT web and debug mode). Indeed, we can't use Java REST API SDK as it is with GWT: https://developers.google.com/web-toolkit/doc/latest/RefJreEmulation This means we need to implement our own transport layer (RequestBuilder) and most likely also the marshalling layer (XMLParser vs. JSONParser vs. overlay types). A third alternative could be simply maintaining the current GWT RPC mechanism we use. I.e. integrating the Java SDK into the GWT servlet, which means wrapping the API into GenericApiGWTService. The main drawback is an additional layer of data type conversion and round-trip: Backend <-> REST <-> Java SDK (servlet) <-> JavaScript (client). This is interesting, generic API could be used to transfer "restapi-types", along with extra information to emulate proper HTTP request, without any marshalling involved. Vojtech - Original Message - From: "Daniel Erez" To: "Michael Pasternak" Cc: engine-devel@ovirt.org, "Einav Cohen" , a...@ovirt.org, "Libor Spevak" , "Vojtech Szocs" Sent: Friday, February 15, 2013 7:17:43 PM Subject: Re: [Engine-devel] REST API calls from the GUI - Original Message - From: "Michael Pasternak" To: "Libor Spevak" Cc: engine-devel@ovirt.org, "Daniel Erez" , "Gilad Chaplik" , "Einav Cohen" , a...@ovirt.org Sent: Wednesday, February 13, 2013 12:55:36 PM Subject: Re: [Engine-devel] REST API calls from the GUI Hi Libor, This issue came across in one of the conversations i had with UX folks, but since we didn't end up with any conclusion/road map (nor discussed it properly to hear other thoughts), this is a perfect place to start this discussion, Intuitively REST is a way to go with GWT AJAX calls --- pros - api data objects can be reused by generating java classes (using jaxb) from the rest schema [1] - no backend logic will be duplicated as api abstracts the backend exposing RESTful collection/resources to operate on - development against api is "easy" as api describes itself in RSDL [2] cons - implementing transport layer (HTTP) under GWT - implementing own j2xml/json/yaml/... marshalling layer - implementing own error handling mechanism - implementing REST callback mechanism (in GWT) - constant maintenance of the data objects generated from the
[Engine-devel] REST API calls from the GUI
Hi, I would like to ask, if there have been discussions about an option to call REST API services directly from the Frontend (GWT layer)? GWT compiles Java frontend-side to Javascript, calls to backend services are performed "transparently" by the framework using AJAX support. But, there is still a need to have a special set of data objects and the server-side logic can duplicate. Java REST API SDK enables to build "thick" client. The calls are realized using e.g. Apache HttClient and supported libraries. I think the requirements of GWT can be a little bit different, but something overlaps. I found several links about REST API support from GWT, so there is something for inspiration... - http://www.spiffyui.org/ - http://www.zackgrossbart.com/hackito/gwt-rest/ - http://code.google.com/p/gwt-rest/ - http://restygwt.fusesource.org/ But, do you think it would be useful and what drawbacks can occur (authentication, authorization, response times, need to support larger set of services, painful refactoring, ...)? Regards, Libor ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Time for Spring?
On 12.2.2013 12:04, Asaf Shakarchi wrote: - Original Message - Hi, it is rather cold in Europe, but can I ask, what's the current opinion or plans about "full" integration of Spring Framework into oVirt engine (Backend)? This is a commonly accepted integration framework among Java programmers and industry standard, which solves many pains from small to large projects. And can lead to a better understanding of the program. There are several Spring dependencies inside oVirt project, but mostly for LDAP and database communication (JDBC template). Still missing (sorry, looks like marketing, but..): - dependency injection - aspect-oriented programming (AOP) - enterprise integration patterns Is something true? :-) 1. We tried, but it is too large and overcomplicated, it can be solved better way for the project purpose 2. We tried, but we think, we need just e.g. JDBC, LDAP layer covered now 3. We would like to integrate with e.g. Hibernate soon, EJB, remoting, unit tests, integration tests, ... , probably we will need it soon 4. We understand and need dependency injection, but there are other light DI containers (Pico, Guice, JBoss Seam). etc. Still, I think there is strong potential, probably not clear today. We cannot avoid Guice on frontend side because of GWTP, but the backend lacks something. It may be possible to avoid using Guice on frontend at some point in the future, There's some work going on with abstracting the DI impl of GWTP, this work is mainly done to integration ERAI with GWTP, You can follow the progress here: http://code.google.com/p/gwt-platform/issues/detail?id=423 https://groups.google.com/forum/#!msg/gwt-platform/rHiNXJGS0jY/UGU0vHQMJq0J Thanks for the links. http://www.jboss.org/errai project looks progressive and the technologies that it integrates together would fit into Engine project purpose. But I am not sure, if a mature project like oVirt can easily replace used libraries or frameworks. Because a lot of frameworks nowadays define not only technologies (mostly limited set), but also overall architecture, which is very useful for startup applications, but to add +1 technology requires some effort and for existing applications total refactoring. For massive changes like JPA/Hibernate integration I can imagine e.g. Spring support in the existing project, but I think the benefits and effort are questionable nowadays, although there are fans of this tool. :-) DI is probably the topic for the Backend, so we see soon after CDI patch (JEE standard + JBoss implementation) is applied and some refactoring proves the technology. The advantage is that the dependency injection changes can be applied gradually. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Time for Spring?
Thanks for the info, I just wanted to know, if there are fans of Spring Framework. If we concentrate just on dependency injection (CDI), probably "standard" JEE technology would be the best way. But, if we want to integrate with e.g. Hibernate/JPA, memory cache (e.g. EhCache) because of DB performance, weave transparently logging,monitoring and/or caching code to current classes (using aspects) without changing any line of current code (if we had services based on Spring beans), there are not many options. JEE container independence is here not an issue and I am not sure, if development on light container like Jetty would be quicker, but for integration tests the framework support is strong (e.g. "simulates" services of "real" JEE container). Libor On 4.2.2013 14:07, Laszlo Hornyak wrote: I have seen a CDI patch from Roy that may be related to the topic. I do not know what the general direction is. CDI is "more standard", while it's implementations for me look heavy weight and difficult to port to small containers like tomcat or jetty. In general, now we only inject the Backend deathstar bean to wherever it is needed and then it is used as registry for other service objects and DAOs. With spring dependency injection, we could be more independent from the container, since the ioC container is comming with us to the app container. But at the other hand, ovirt is a nice big ear app, so how would you put it together as a spring app? What changes would this need? Laszlo - Original Message - From: "Libor Spevak" To: engine-devel@ovirt.org Sent: Tuesday, January 29, 2013 11:42:35 AM Subject: [Engine-devel] Time for Spring? Hi, it is rather cold in Europe, but can I ask, what's the current opinion or plans about "full" integration of Spring Framework into oVirt engine (Backend)? This is a commonly accepted integration framework among Java programmers and industry standard, which solves many pains from small to large projects. And can lead to a better understanding of the program. There are several Spring dependencies inside oVirt project, but mostly for LDAP and database communication (JDBC template). Still missing (sorry, looks like marketing, but..): - dependency injection - aspect-oriented programming (AOP) - enterprise integration patterns Is something true? :-) 1. We tried, but it is too large and overcomplicated, it can be solved better way for the project purpose 2. We tried, but we think, we need just e.g. JDBC, LDAP layer covered now 3. We would like to integrate with e.g. Hibernate soon, EJB, remoting, unit tests, integration tests, ... , probably we will need it soon 4. We understand and need dependency injection, but there are other light DI containers (Pico, Guice, JBoss Seam). etc. Still, I think there is strong potential, probably not clear today. We cannot avoid Guice on frontend side because of GWTP, but the backend lacks something. Or not? Thanks. Regards, Libor ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] Time for Spring?
Hi, it is rather cold in Europe, but can I ask, what's the current opinion or plans about "full" integration of Spring Framework into oVirt engine (Backend)? This is a commonly accepted integration framework among Java programmers and industry standard, which solves many pains from small to large projects. And can lead to a better understanding of the program. There are several Spring dependencies inside oVirt project, but mostly for LDAP and database communication (JDBC template). Still missing (sorry, looks like marketing, but..): - dependency injection - aspect-oriented programming (AOP) - enterprise integration patterns Is something true? :-) 1. We tried, but it is too large and overcomplicated, it can be solved better way for the project purpose 2. We tried, but we think, we need just e.g. JDBC, LDAP layer covered now 3. We would like to integrate with e.g. Hibernate soon, EJB, remoting, unit tests, integration tests, ... , probably we will need it soon 4. We understand and need dependency injection, but there are other light DI containers (Pico, Guice, JBoss Seam). etc. Still, I think there is strong potential, probably not clear today. We cannot avoid Guice on frontend side because of GWTP, but the backend lacks something. Or not? Thanks. Regards, Libor ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
