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.
Related
WebLogic 12c includes a Default JAX-RS resource (https://docs.oracle.com/cd/E24329_01/web.1211/e24983/configure.htm#RESTF191) that will register all classes annotated with JAX-RS annotations as resources.
I use the Jersey proxy client (http://blog.alutam.com/2012/05/04/proxy-client-on-top-of-jax-rs-2-0-client-api/), so my interface classes have all the JAX-RS annotations and are packaged in their own "API" jar. The API jar is then deployed to basically two different contexts: the service and the client. The Service provides an implementation of the API that is the actual business logic and is exposed as a JAX-RS web service. The client is just a consumer of the service and the implementations of the service interfaces in the API jar are Jersey Proxy Clients.
Unfortunately, WebLogic 12c is causing me two problems here:
1) It is automatically registering all the resources in my API jars and exposing them as web services from the client application (with the implementation being the (now literally) proxy client)! Which is extremely unintended.
2) Sometimes I want to use classes from an API without actually consuming the service, so I don't even provide implementations for the interfaces. This should be fine, but because WebLogic is attempting to automatically load the API resources, but not finding implementations for the annotated interfaces, it refuses to deploy the war.
I could hack around issue 1 with security policies or weird jax-rs configurations in the web.xml, but that doesn't solve issue 2. The best solution is just to turn off the Default Resource in WebLogic, but I can't find any documentation to do so.
Is there any way to turn off the Default Resource in WebLogic or turn off automatic Jersey scanning?
As far as I can tell, removing these files from weblogic 12.2.1.3 completely removes jersey from starting up and scanning the classpath for annotations:
wlserver/modules/weblogic.jaxrs.integration.jar
oracle_common/modules/com.sun.jersey.jersey-core.jar
oracle_common/modules/weblogic.jaxrs.portable.server.jar
The weblogic portable server is activated by the hk2 dependency injection system, which loads jersey as an OSGI bundle and activates it
Bit confused with Spring framework and what capabilities application server provides.
I was reading this answer on same site
There he says,
Additionally App Server have components and features to support
Application level services such as Connection Pooling, Object Pooling,
Transaction Support, Messaging services etc.
That means we can optionally use apis of application server to manage transaction in our web application (inject web application :()and I think spring also provides transaction apis. So whats the difference?
Please, help me to make it clear. Thanks you.
When you use app server resources (transactions, connection pools etc.) directly in your application code, you can only run it when it is deployed on an application server or even worse only on that syme type of application server.
Spring allows you to use those resources and configure your application for different environments. The application can be run on any application server or on a simple Tomcat, or on different servers in the cloud.
Spring also allows you to run your code in tests (unit tests) without the need to start up an application server. This is absolutely needed to write automated tests.
Everything that can be done with an application server, can be done with spring as well.
There is a whole world of spring libraries and framework that provide features that are not available directly on application servers.
I can really recomand to give spring a try.....
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.
I have a server running on tomcat exposing Spring services using HttpInvoker.
I have exposed the methods of 5 services using HTTPInvoker.
This works very well.
The spring configuration is described in a file named remoting-servlet.xml; and the remoting servlet (DispatcherServlet) is described in the web.xml.
I now have an additional need to expose one additional service using JAX-WS this time (I will have C# clients).
I will use Spring support to JAX-WS.
I have the option to use the default deployment, or to use JAX-WS RI's to deploy this additional service to the same server as the remoting servlet.
I would prefer this last solution, because I would have only one server providing the remote services (whether they are web services or httpinvokers).
My question is: is this possible?
I think that I can I put the 2 servlets on the same port. But my issue is that it seems to me that I will have to provide 2 different application contexts. One for the DispatcherServlet, and one for the WSSpringServlet.
Is that correct?
Is it possible to put the WSSpringServlet context definition to the same file as the one for the httpinvokers (remoting-servlet.xml)?
Many thanks
Gilles
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.