The Websphere Liberty documentation says that JNDI objects can be registered and retrieved as OSGi services by Liberty features.
Is this general to all JNDI objects (so, for instance, a session bean in an application could be discovered), or does it only apply to the objects that are registered to JNDI by using the OSGi registration method?
Objects bound in the default JNDI namespace are available from the OSGi service registry, but it is not true for other namespaces. In particular, session EJBs are only bound in the java: namespace, not the default namespace, so they are not available as OSGi services.
Related
Does SpringBoot use JNDI for the data base connection (auto configuration) ?
Can you give sample use cases which requires JNDI implementation in Spring Boot Application ?
JNDI is very useful when the servlet container or the application server provides some resources to the application.
The usual example is the datasource. It is useful, because binding the datasource to the JNDI allows you to deploy the same application into different environments without changing any configuration file.
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
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.
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.
If I follow spring and bitronix instructions and I run web application on tomcat, do I still need to configure:
in web.xml the resource-ref
in context.xml the resrouce and transaction tag
in web.xml the bitronix.tm.integration.tomcat55.BTMLifecycleListener
in resource.properies the Data resource?
I prefer to configure the bitronix (btm) only in spring and not in tomcat. is it possible in web application?
Transactions ought to be associated with the service tier, which does not depend at all on the web tier. (The web tier, however, does use the service tier to fulfill requests.)
If that's the case, there shouldn't be a reason to embed information about transactions in any configuration except Spring's.