looks to me you need tomcat or some other servlet engine for the web part.
what about data access part using hibernate and jms? Thanks.
No, you don't need an application server, you can see Spring as a proprietary, modular application server implementation / adapter. But you still need an a servlet container.
Data access part: you can use hibernate and some standalone connection pool
jms: Spring is not a JMS provider, but it nicely integrates POJOs with any JMS provider
Spring also has comprehensive transactions support
Finally you have jmx and aop support built-in and easy integration with bean validation, jpa, web services, rmi, jci, task scheduling, caching...
As you can see you can either use certified application server and Java EE stack or built on top of Tomcat and pick Spring modules you need. Sometimes Spring uses standard Java EE APIs (like JPA), more often it builts its own.
Related
I have just built a RESTful web service with Spring Boot.
I now want to utilise the RESTful web service and start making calls to it by building a java console application (eventually adding GUI and security).
I was wondering if I can use any of the Spring functionality outside of the Spring (Boot) environment and use it in my java console application? For example, can I use Spring's RestTemplate in my non-Spring java application to make the REST api calls? I am new to Spring and I want to stick as close to Spring as possible. I think you can't, but I just want to make sure.
If not possible, I know you can create non-web application with Spring. Is it possible to integrate a GUI? Might not be best practice, just exploring what is possible and conventional.
Spring Boot is not coupled, in any way, to an application type. You can run command-line only apps, batch apps, web apps or any other kind of apps with it. You can even benefit from Spring Boot's auto-configuration.
In the case of the RestTemplate you may want to import spring-web directly rather than spring-boot-starter-web. Or you could add the starter and exclude the embedded container (spring-boot-starter-tomcat). Spring Boot will auto-adapt and not start an embedded web server in that case.
Everything I found on the internet about Spring Cloud Netflix is about running microservices from Boot applications using #EnableEurekaClients and so on.
Now I'm trying to connect my logging microservice within a traditional war application (springmvc, jaxws etc) - piece of legacy which can not be converted to Boot or modified in any way (by technical task).
I've created a new maven module "log-server-client" that knows nothing about upper web layer and intended to be used as a simple dependency in any maven project.
How should I configure access to Spring Cloud Netflix for this simple dependency? At least, how to configure Eureka and Ribbon?
I just extracted some lines of code from RestTemplate and created my custom JmsTemplate (microservice works with jms remoting with apache camel and activemq), exactly how it is done in RestTemplate, but this code stil lacks connection to infrastructure
afaik, we can create a global singleton bean, run a separate thread from this bean, and run Boot app from this thread, but don't you think that it is very ugly and can lead to problems? How it really should be used?
Great question!
One approach is to use a "sidecar". This seems to be a companion Spring Boot application that registers with the Eureka Server on behalf of your traditional web app.
See e.g.:
http://www.java-allandsundry.com/2015/09/spring-cloud-sidecar.html
http://cloud.spring.io/spring-cloud-netflix/spring-cloud-netflix.html#_polyglot_support_with_sidecar
Another approach is to use the following library:
"A small lib to allow registration of legacy applications in Eureka service discovery."
https://github.com/sawano/eureka-legacy-registrar
This library can be used outside of Spring Boot.
In my project we are using JSF and Spring WS (web tier), EJB 3.0 (service layer) and JPA (integration layer). We have exposed EJB in Spring container.
All technologies are used with Spring. So, Spring is a used to bind all layers together. Hence, Spring is common for all layers of architecture.
I read that, many features provided by EJB is also available in Spring. Can't we replace EJB with Spring? Why, EJB and Spring both are used together.
I want to understand, what are benefits of using such architecture.
Spring is an alternative for EJB. Usually EJB and Spring are not used together unless it is a legacy application which is already developed based on EJB and Spring is wired later to support dependency injection and other framework benefits.
EJB is a heavy weight container which requires App containers like JBoss, WebSphere, or Weblogic.
Spring is a very light weight container which can be used in in web containers like Tomcat and even in Standalone applications. Also it provides support for many modules from front-end to back-end.
If there is a chance, you should consider replacing EJB with Spring bean in service layer.
Does it means that Spring provides all features which are available from EJB 3.0. Clustering and all other features of EJB can also be acheived from Spring.
I have two java web-app in the same application server (JBoss 7). And one web-app makes some remote calls to the other one.
Today I'm using Stateless EJB 3.1 to expose the services. Do you think that exposing the services with Spring Remoting (via httpinvoke or hessian) performs better?
Assuming that you currently expose the EJB via #WebService, there is a good chance that Hessian would be faster since it is a binary protocol.
The standard webservice serializer (JAXB) is fairly wasteful.
Here you can see a benchmark of remoting technologies:
http://daniel.gredler.net/2008/01/07/java-remoting-protocol-benchmarks/
I would like to know about what is the relationship between JNDI and Spring?
Is spring an advanced version of JNDI? Both are used to create an object from string names.
Can we say that an For JNDI an application server is neccesary to provide naming service?
on the other hand for Spring we may not need Application server so it could be used at Java SE?
Finally where we can put JMX on this relation between JNDI and Spring? Is there some common logic at the low level?
Just to clarify some definitions:
Spring: The Spring Framework is an open source application framework and Inversion of Control container.
JNDI: The Java Naming and Directory Interface, a Java API for a directory service that allows Java software clients to discover and look up data and objects via a name.
JMX: Java Management Extensions (JMX) is a Java technology that supplies tools for managing and monitoring applications, system objects, devices (e. g. printers) and service oriented networks.
JNDI is mostly a set of Java interfaces that define how a naming system should work in Java in such a way that a diverse set of services can be abstracted to a simple JNDI interface. For example, file systems, LDAP servers and DNS servers can all be accessed as a JNDI service.
Enterprise Java (Java EE) makes extensive use of JNDI to store objects in a common address where other services can find them by name. JNDI does not require an application server, but Java EE application servers almost always require (and provide) a JNDI service.
Spring is not a JNDI implementation, and does not require JNDI, but does support it, meaning that you can start a JNDI service in a Spring container, access JNDI based resources and use Spring's built in JNDI support classes.
JMX defines a standard on how to provide management interfaces, instrumentation and runtime "transparency" to a Java application. There's not much overlap between JNDI and JMX except that JMX remote connectors are frequently built in the form of java remote objects and bound into a JNDI service (so that remote clients can look them up and connect to a JMX managed application).
Spring does not require JMX but provides support for it in their framework libraries and this is frequently used as a simplified means of adding JMX based services to a Spring managed application or service.
It does not sound like you need JNDI, and as you say, if your application is going to be Spring managed Java SE based, you would have some fairly specialized requirement to call for JNDI.
As for JMX, Spring does make it fairly easy to add JMX "instrumentation" to your Spring managed Java SE application. My opinion: I feel (and could be wrong) that you need to develop a bit more expertise before tackling this as it could be a serious sidetrack for you.