[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
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" <lspevak@redhat.com> 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
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" <lspevak@redhat.com> 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
----- Original Message -----
From: "Libor Spevak" <lspevak@redhat.com> To: "Laszlo Hornyak" <lhornyak@redhat.com> Cc: engine-devel@ovirt.org Sent: Tuesday, February 5, 2013 2:13:12 PM Subject: 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
* Not sure when we will go to Hibernate/JPA integration -> our current data model is quite complex and we might need to have additional layer of "data objects" if we want to work with Hibernate/JPA . For example - when VM object is loaded from DB, the hibernate session should be "notified" that the corresponding VmStatic and VmDynamic objects were loaded as well. And I can think of more examples like this. * Not sure also about caching - this should be done with care. IMHO the safest approach is to cache static entities. Bare in mind this will require to change the search engine project , which relies on DB queries , and serves the UI. * Regarding DB performance - we have issues to deal with it. * Regarding Aspects - where do you want to use it in the code? any concrete example. In general I would prefer to know where we need "cool features" of frameworks, before trying to adapt our code to support "future cool features of framework".
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).
* I would also consider to look into TomEE - Java EE over tomcat.
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" <lspevak@redhat.com> 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
On 02/05/2013 02:13 PM, Libor Spevak wrote:
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" <lspevak@redhat.com> 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.
Jboss weld an implementation reference the CDI JSR 299 and this is what is used in my CDI refactor patches.http://gerrit.ovirt.org/#/c/5575/
What we strive to achieve by using it is the separation of behavior from dependency resolution so its easy to 1. replace run time object with mock objects 2. dynamically switch implementation objects in runtime or 3. dynamically load plugins
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
----- 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
Or not?
Thanks.
Regards, Libor
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
----- 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
On 12.2.2013 12:04, Asaf Shakarchi wrote: 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.
participants (5)
-
Asaf Shakarchi -
Laszlo Hornyak -
Libor Spevak -
Roy Golan -
Yair Zaslavsky