[Engine-devel] Time for Spring?

Yair Zaslavsky yzaslavs at redhat.com
Wed Feb 6 06:05:26 UTC 2013



----- Original Message -----
> From: "Libor Spevak" <lspevak at redhat.com>
> To: "Laszlo Hornyak" <lhornyak at redhat.com>
> Cc: engine-devel at 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 at redhat.com>
> >> To: engine-devel at 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 at ovirt.org
> >> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 



More information about the Engine-devel mailing list