I am a little bit confused about Blueprint, Spring DM and DS (Declarative Services).
Form what I think it is:
Spring DM came first.
OSGi like the idea and defined the Blueprint standard based on Spring DM.
Spring DM became the reference implementation of Blueprint.
No?
And how does DS (Declarative Services) fit into the picture?
Well some others did not like the idea and created declarative services :-)
Blueprint is largely xml focused and declarative services is largely annotation focused. In the end I think it would have been better to have one project that allows both.
Related
I have read the spring guide with kotlin and its says data class for JPA is not recommended
but i am quite confused after seeing some tutorials and video using data class for JPA
did spring find a way to deal with data class in new versions?
We have developed several services with Spring and Kotlin and used data classes as e.g. entities. This works fine and leads to a lot less boilerplate. You do, however, need to configure your project with these build options/dependencies to avoid Spring interoperability issues:
https://kotlinlang.org/docs/all-open-plugin.html
You can use Kotlin for Spring Data entities. This is true for all Spring Data modules including JPA where Spring Data is not the one doing the mapping, but your JPA implementation does.
The problem is that all the libraries involved are developed with mainly Java in mind and Kotlin isn't developed with Hibernate or Spring Data in mind. Therefore problems are bound to occur.
For example Kotlin does generate a lot of stuff that isn't visible for normal users, like special constructors. But this is visible for reflection so in the past we had situations where the developer only sees a single constructor, but Spring Data saw multiple constructors and couldn't decide which one to use.
So you may use Kotlin, but especially when the next Kotlin version comes a long you might experience some extra pain.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
The Mule ESB project explains its difference to Spring Integration on its website. However, regarding dcterms.date 2012-07-19T18:43-03:00 of the document, the text might be outdated.
The main points of the quoted paragraph are
"Spring Integration takes [...] an 'application-centric' approach to integration".
"Rather than implement a shared bus, [...] Spring Integration is aimed at providing 'just a little' ESB-style integration to specific applications".
"Spring Integration is best suited to situations where a small number of components must be integrated, usually internally".
"[Spring Integration has a] very small number of supported transports and transformers available".
"[The] scope of Spring Integration is deliberately limited to small-scale integration within the Spring Portfolio context".
Are these points still valid? Does any more detailed and, if so, up-to-date comparison exist?
Mule ESB vs. Spring Integration
Recently, a new component called Spring Integration was added to the Spring Portfolio, which allows ESB-like functionalities and EIPs to be created and managed within the Spring Framework. Spring Integration takes what is known as an "application-centric" approach to integration.
Rather than implement a shared bus, which allows all integration and messaging between components and systems to be managed, administered, and configured centrally, Spring Integration is aimed at providing "just a little" ESB-style integration to specific applications by providing frameworks for implementing common EIPs such as a message bus and simple routing.
Due to its limited scope, Spring Integration is best suited to situations where a small number of components must be integrated, usually internally, and the infrastructure in question is made up of a large number of other Spring components. For anything more complicated, the lack of a common bus, coupled with the very small number of supported transports and transformers available for the young project makes Spring Integration unsuited for the task.
The advantage of using Mule ESB to handle integration in a Spring environment is that Mule ESB is not simply an ESB - it is an integration platform. Whereas the scope of Spring Integration is deliberately limited to small-scale integration within the Spring Portfolio context, Mule's intentionally modular architecture allows teams to quickly deliver the lightest possible integration solution for any scenario, from simple point to point integration to complicated SOA, cloud and partner ecosystem scenarios.
Full disclosure: I am the current a past Spring Integration project lead and have been a committer for over 10 years.
While it is true that Spring Integration promotes modularity and loose coupling within an application, it is also very well suited for integrating systems together without the need for a central ESB. I am personally aware of a number of very large enterprises that integrate all their business systems together using only Spring Integration, with no central bus server(s) to configure/administer.
Its POJO programming model makes it incredibly easy to customize/extend; if some transport/protocol is not supported out of the box, you can simply wrap it in a POJO and invoke it (or consider writing a more formal adapter and contribute it back to the framework!).
We are particularly excited that it forms the basis of the new and important Spring Cloud Stream.
You may want to take a look at DZone's recent Guide to Enterprise Integration which talks about Spring Integration as well as the competing technologies.
Hi I would like to learn spring data rest, but It is very confused. Which dependencies I have to add to the pom, as the default (spring-data-rest) How I structure the xml files or the configuration classes. It' s very heavy.
How I create an connection to database, and so on.
SDR documentation needs to be improved and I am sure Spring team are working on that. Having said that the best way to understand most of the SDR is through API docs. Also team lead is maintaining a Restbucks sample app that helps you understand/use various features of SDR
Moving from JSF to Wicket I continue my habits of having all JPA operations in a EJB facade use the container's transaction management. I use and know wicket-cdi for injection, which works fine.
Unfortunately, if I inject an EJB in a wicket page, the serialization checks of wicket complain that it is not serializable. This is true for EJB, I suppose since they are proxied.
My thinking is blocked at this point. How can I use jpa with container managed transactions with wicket? All examples I goggled are just reading data or are using Spring, what I do not want to do.
Thank You
Dieter
I repeated the question in the wicket-users mailing list and it was an interesting thread with 3 solutions.
One of them is my idea of encapsulating the EJB in a LoadableDetachableModel and realize the load by a JNDI lookup of the bean. See http://mail-archives.apache.org/mod_mbox/wicket-users/201210.mbox/%3C5072F013.9040702%40tremel-computer.de%3E
A little more generic solution I posted in my blog, sorry only in german language.
I have some experience with NHibernate and I'm trying to get started with Castle Nhibernate Facilities OR Castle NhibernateIntegration. I'd like to know, where I can find a demonstration project of how to configure and perform transactional control (with attributes) in a service layer (business, class library project)? There is no documentation, and I have a really difficult to find some content to getting started.
I found some samples on the web but only with pieces of code and not the demonstration project... I would like to download something to study. I'm not finding to a complete solution, just the configuration and transactional control in business classes (class library).
Sorry for this kind of thread here, but I do know how to start.
Thank you!
If you want to see an full example of Castle Windsor integrating with nHibernate then I would check out Sharp Architecture
Sharp is an attempt at a 'best practice' template project and utilises a number of tech's (Castle and nHibernate included). While some of the things it does may not be to your taste it will clearly show you one of the ways that it can all fit together.
You may need to go hunting into the source repository on GitHub if you want to see what is going on at a low level as Sharp uses it's own base classes in the template project that are pre-compiled (tho its still open source so you can see what is going on if you want).
It was an invaluable help to me when I was putting my architecture together and I can honestly say that Castle and nHibernate are the way to go, so you are very much on the right track.
EDIT FOR COMMENT 1: Perhaps I am a little confused here. According to the Castle notes
Facilities are main way of extending the container. Using facilities
you can integrate container with external framework, like WCF or
NHibernate, add new capabilities to the container like event wiring,
transaction support... or to components (synchronization, startable
semantics...).
To the best of my knowledge both Castle Nhibernate Facilities and Castle NhibernateIntegration are Facilities and must be based on a container.
If you want to work without a container then you need to use some form of Singleton Factory to manage the SessionFactory. There is an example of this here.
In terms of attributes controlling Transactions then this is how Sharp does it (see here). You may get away with reusing this code and replacing NHibernateSession with your own Singleton like theirs.
You don't need to implement UnitOfWork as nHibernate is effectively doing this for you. What you really need is an architecture that allows you to manage a transaction at a single point of control (Singleton) and is available in every repository.