I'm working on a large legacy application using stateless session beans that has recently been migrated from EJB2 to EJB3, and I'd like to use dependency injection. Unfortunately, in a (IMO misguided) attempt to achieve decoupling, all actual business logic lies in "manager" classes to which the session beans forward their calls. Those manager classes then often use other EJBs.
Can I somehow make these manager classes capable of being injected into the EJBs via #Resource and then having the other EJBs injected into them via #EJB?
The application has to run on glassfish 2.1.
(...) all actual business logic lies in "manager" classes to which the session beans forward their calls.
That was a very common pattern with EJB 2.x allowing to unit test the "manager" classes easily, outside the container, without any adherence to the EJB API.
Can I somehow make these manager classes capable of being injected into the EJBs via #Resource and then having the other EJBs injected into them via #EJB?
Not out-of-the-box with Java EE 5. Injection is limited only to first class constructs defined in the Java EE platform, including:
SessionContext object
DataSources object
UserTransaction
EntityManager interface
TimerService interface
Other enterprise beans
Web services
Message queues and topics
Connection factories for resource adaptes
Environment entries limited to String, Character, Byte, Short, Integer, Long, Boolean, Double, and Float.
In Java EE 6, this would be possible using CDI (JSR-199) and the #Inject annotation in EJBs to inject your managers and also in you managers to get EJBs injected.
Maybe you could try to deploy Weld (the RI of JSR-199) as part of your application on GlassFish v2.1. I didn't experiment this myself, so I can't confirm anything. Just in case, maybe have a look at the Chapter 18. Application servers and environments supported by Weld (GlassFish v2.1 hasn't been tested, but it doesn't mean it doesn't work).
Pascal's suggestion about upgrading to GlassFish 3 sounds probably like the most elegant approach ;)
I'd be curious to hear what prevents moving to a more recent version (not saying there can't be a reason, just wondering what the issue is here).
Related
My question is not only if action classes can be scoped to singleton, but I also want to know which are the best practices. Both in context of Struts2 and Spring. Best scope of VIEW (say request or session), for controller and model.
Struts2 Actions are managed by the Struts Container. They are ThreadLocal, hence every request has its own thread-safe copy of the Action.
If you use Spring to handle them through the Struts2-Spring-plugin, there are multiple levels of usage:
you can let the Struts container instantiate them, and handle them through Spring for the Dependency Injection, or
you can let Spring take over control and be fully responsible for the whole lifecycle of every Action. In this second case:
if you declare an action as a bean in a Spring XML configuration file, the action will get the default Spring scope, that is Singleton (scope="singleton"). THIS IS DANGEROUS, USELESS, and 99.99% of the times NOT WHAT YOU WANT, because you will lose a fundamental part of the framework capability, actions will be turned into kind-of servlets, thread-UNsafe, and many problems will arise;
to prevent that, you can put the scope="prototype" in the bean declaration, that will let Spring instantiate the action without affecting its nature.
If you are inside a container Java EE 6+ compliant (for example, Jboss 7, Wildfly 8, TomEE 1.7, Glassfish 3+, ecc...), the Contexts and the Dependency Injections are handled through CDI. If you want, you can use the Struts2-CDI-plugin to allow CDI to handle your actions and inject dependencies through the #Inject annotation (instead of the #Autowired one)
I've used Spring a lot in the past, then after discovering CDI and the CDI plugin, I've switched and never looked back, so I vote for the n.3
What is the best way to configure a Grails service with environment specific values? I believe there are two options:
access grailsApplication values from within the service class or
configure the service bean in a beans closure in Config.groovy or resources.groovy.
I've seen a couple of posts on stackoverflow and other places that show how to do #1 (accessing grailsApplication in the service). One such post is: Inject grails application configuration into service.
However, I think this creates an unnecessary coupling of the service to Grails. Isn't this similar to accessing Spring's applicationContext in a pojo rather than configuring/injecting the values? Also, I've not had any luck getting this to work in a unit test of the service class as of yet.
Two books have examples of injecting the properties (approach #2). The book The Definitive Guide to Grails 2, chapter 10, section entitled "Services in Action" shows how to do this, but without an environment specific value. The book Groovy and Grails Recipes, section 16-2 also shows an example using resources.groovy, but I've not been able to get it to work either yet.
The following blog post also has a nice example, but not environment specific: http://ldaley.com/post/1253952347/getting-more-out-of-property-override-configuration. Chapter 15 of the Grails Reference is consistent with these examples as well and shows how to set the properties on a bean on a per environment basis.
However, none of the examples of either approach give any opinion or rational for doing it one way or another. Is there really no pros and cons to either approach? Wouldn't the injection approach be easier to unit test and more consistent with the spring way of doing things?
Nathan
I'd say use whichever you're more comfortable with. I tend to go with accessing grailsApplication.config directly from the service, because that lets you make the configuration more "semantic" (for want of a better word) in the sense that you can name the configuration options after what they do, rather than which bean they control. And if two (or more) different beans need to know the site administrator's email address (for example) then they can both read grailsApplication.config.myapp.admin.email rather than my having to configure beans.monitorService.destinationEmail and beans.userService.fromEmail separately.
In unit tests you'd have to mock the grailsApplication config anyway, so it's no big deal filling in test values for the config options your services need to read.
There's a difference in the concept of services (classes that exists in the service folder) and Spring Beans defined in resources.groovy.
To services, Grails already setup transactions:
Services are typically involved with coordinating logic between domain
classes, and hence often involved with persistence that spans large
operations. Given the nature of services, they frequently require
transactional behaviour. You can use programmatic transactions with
the withTransaction method, however this is repetitive and doesn't
fully leverage the power of Spring's underlying transaction
abstraction.
The Spring Beans that you declared aren't transactional by default.
"However, I think this creates an unnecessary coupling of the service
to Grails"
Since Grails services differ from Spring Beans I don't see a problem using approach #1.
For Unit Tests you need to manually wire up you service instance. Example:
class MyService {
def grailsApplication
}
class MyServiceTests {
MyService getServiceInstance() {
MyService myService = new MyService()
myService.grailsApplication = grailsApplication //static attribute in unit tests
return myService
}
}
I'm replacing the service tier in an existing older Struts2 project with Spring service beans developed for another project.
I'd like to just #Inject these service beans into my Action classes.
Is it required to use Struts' Spring Plugin? Or can I add Spring into my Struts web application like I would any other (ContextLoaderListener, applicationContext.xml, context:component-scan)?
Am I missing some reason why the Struts Spring plugin helps me in another way?
Many thanks!
Well you can do the most of the things what you have described in your question as Services layer is completely out of view for the S2 and Struts2 do not care how you are creating your Service layer instances and other things.
Benefits i am seeing of using Struts2-Spring plugin is to delegate creation of Struts2 related things to Spring like Action classes creation,Interceptors,Results etc.
My Suggestion is to use the plugin as you are going to use the Spring in your application so its very good and flexible as well powerful to use the power of Spring DI to create required objects needed by S2 else S2 will use its own data creation factory to create framework component.
Why wouldn't you use the Spring plugin?
It's essentially invisible, uses Spring to create your actions (including injecting other Spring beans), etc.
Guice's #Inject doesn't know anything about Spring beans, AFAIK, so you'd be naming classes manually, they'd be instantiated via normal Java/Guice mechanisms, wouldn't be injected with their own Spring dependencies (unless you did it manually, or via AOP, or whatever).
You'd also need to use non-Spring mechanisms for doing injection in testing, which is fine, but unless you provide more details regarding your usecase, I don't really see a reason to bypass the functionality the Spring plugin provides out-of-the-box.
What is JNDI?
What is its basic use?
When is it used?
What is JNDI ?
It stands for Java Naming and Directory Interface.
What is its basic use?
JNDI allows distributed applications to look up services in an abstract, resource-independent way.
When it is used?
The most common use case is to set up a database connection pool on a Java EE application server. Any application that's deployed on that server can gain access to the connections they need using the JNDI name java:comp/env/FooBarPool without having to know the details about the connection.
This has several advantages:
If you have a deployment sequence where apps move from devl->int->test->prod environments, you can use the same JNDI name in each environment and hide the actual database being used. Applications don't have to change as they migrate between environments.
You can minimize the number of folks who need to know the credentials for accessing a production database. Only the Java EE app server needs to know if you use JNDI.
What is JNDI ?
The Java Naming and Directory InterfaceTM (JNDI) is an application programming interface (API) that provides naming and directory functionality to applications written using the JavaTM programming language. It is defined to be independent of any specific directory service implementation. Thus a variety of directories(new, emerging, and already deployed) can be accessed in a common way.
What is its basic use?
Most of it is covered in the above answer but I would like to provide architecture here so that above will make more sense.
To use the JNDI, you must have the JNDI classes and one or more service providers. The Java 2 SDK, v1.3 includes three service providers for the following naming/directory services:
Lightweight Directory Access Protocol (LDAP)
Common Object Request Broker Architecture (CORBA) Common Object Services (COS) name service
Java Remote Method Invocation (RMI) Registry
So basically you create objects and register them on the directory services which you can later do lookup and execute operation on.
JNDI in layman's terms is basically an Interface for being able to get instances of internal/External resources such as
javax.sql.DataSource,
javax.jms.Connection-Factory,
javax.jms.QueueConnectionFactory,
javax.jms.TopicConnectionFactory,
javax.mail.Session, java.net.URL,
javax.resource.cci.ConnectionFactory,
or any other type defined by a JCA resource adapter.
It provides a syntax in being able to create access whether they are internal or external. i.e (comp/env in this instance means where component/environment, there are lots of other syntax):
jndiContext.lookup("java:comp/env/persistence/customerDB");
JNDI Overview
JNDI is an API specified in Java
technology that provides naming and
directory functionality to
applications written in the Java
programming language. It is designed
especially for the Java platform using
Java's object model. Using JNDI,
applications based on Java technology
can store and retrieve named Java
objects of any type. In addition, JNDI
provides methods for performing
standard directory operations, such as
associating attributes with objects
and searching for objects using their
attributes.
JNDI is also defined independent of
any specific naming or directory
service implementation. It enables
applications to access different,
possibly multiple, naming and
directory services using a common API.
Different naming and directory service
providers can be plugged in seamlessly
behind this common API. This enables
Java technology-based applications to
take advantage of information in a
variety of existing naming and
directory services, such as LDAP, NDS,
DNS, and NIS(YP), as well as enabling
the applications to coexist with
legacy software and systems.
Using JNDI as a tool, you can build
new powerful and portable applications
that not only take advantage of Java's
object model but are also
well-integrated with the environment
in which they are deployed.
Reference
What is JNDI ?
JNDI stands for Java Naming and Directory Interface. It comes standard with J2EE.
What is its basic use?
With this API, you can access many types of data, like objects, devices, files of naming and directory services, eg. it is used by EJB to find remote objects. JNDI is designed to provide a common interface to access existing services like DNS, NDS, LDAP, CORBA and RMI.
When it is used?
You can use the JNDI to perform naming operations, including read operations and operations for updating the namespace. The following operations are described here.
I will use one example to explain how JNDI can be used to configure database without any application developer knowing username and password of the database.
1) We have configured the data source in JBoss server's standalone-full.xml. Additionally, we can configure pool details also.
<datasource jta="false" jndi-name="java:/DEV.DS" pool-name="DEV" enabled="true" use-ccm="false">
<connection-url>jdbc:oracle:thin:#<IP>:1521:DEV</connection-url>
<driver-class>oracle.jdbc.OracleDriver</driver-class>
<driver>oracle</driver>
<security>
<user-name>usname</user-name>
<password>pass</password>
</security>
<security>
<security-domain>encryptedSecurityDomain</security-domain>
</security>
<validation>
<validate-on-match>false</validate-on-match>
<background-validation>false</background-validation>
<background-validation-millis>1</background-validation-millis>
</validation>
<statement>
<prepared-statement-cache-size>0</prepared-statement-cache-size>
<share-prepared-statements>false</share-prepared-statements>
<pool>
<min-pool-size>5</min-pool-size>
<max-pool-size>10</max-pool-size>
</pool>
</statement>
</datasource>
Now, this jndi-name and its associated datasource object will be available for our application.application.
2) We can retrieve this datasource object using JndiDataSourceLookup class.
Spring will instantiate the datasource bean, after we provide the jndi-name.
Now, we can change the pool size, user name or password as per our environment or requirement, but it will not impact the application.
Note : encryptedSecurityDomain, we need to configure it separately in JBoss server like
<security-domain name="encryptedSecurityDomain" cache-type="default">
<authentication>
<login-module code="org.picketbox.datasource.security.SecureIdentityLoginModule" flag="required">
<module-option name="username" value="<usernamefordb>"/>
<module-option name="password" value="894c8a6aegc8d028ce169c596d67afd0"/>
</login-module>
</authentication>
</security-domain>
This is one of the use cases. Hope it clarifies.
A naming service associates names with objects and finds objects based on their given names.(RMI registry is a good example of a naming service.) JNDI provides a common interface to many existing naming services, such as LDAP, DNS.
Without JNDI, the location or access information of remote resources would have to be hard-coded in applications or made available in a configuration. Maintaining this information is quite tedious and error prone.
The best explanation to me is given here
What is JNDI
It is an API to providing access to a directory service, that is, a service mapping name (strings) with objects, reference to remote objects or simple data. This is called
binding. The set of bindings is called the context. Applications use the JNDI interface to access resources.
To put it very simply, it is like a hashmap with a String key and Object values representing resources on the web.
What Issues Does JNDI Solve
Without JNDI, the location or access information of remote resources would have to be hard-coded in applications or made available in a configuration. Maintaining this information is quite tedious and error prone.
If a resources has been relocated on another server, with another IP address, for example, all applications using this resource would have to be updated with this new information. With JNDI, this is not necessary. Only the corresponding resource binding has to be updated. Applications can still access it with its name and the relocation is transparent.
I am just curious why the official docs are so ignored which elaborate the details meticulously already.
But if you'd like to understand the cases, please refer to duffymo's answer.
The Java Naming and Directory InterfaceTM (JNDI) is an application programming interface (API) that provides naming and directory functionality to applications written using the JavaTM programming language. It is defined to be independent of any specific directory service implementation. Thus a variety of directories--new, emerging, and already deployed--can be accessed in a common way.
And its architecture
And normally how you use it.
The Java Naming and Directory InterfaceTM (JNDI) is an application programming interface (API) that provides naming and directory functionality to applications written using the JavaTM programming language. It is defined to be independent of any specific directory service implementation. Thus a variety of directories--new, emerging, and already deployed--can be accessed in a common way.
While JNDI plays less of a role in lightweight, containerized Java applications such as Spring Boot, there are other uses. Three Java technologies that still use JNDI are JDBC, EJB, and JMS. All have a wide array of uses across Java enterprise applications.
For example, a separate DevOps team may manage environment variables such as username and password for a sensitive database connection in all environments. A JNDI resource can be created in the web application container, with JNDI used as a layer of consistent abstraction that works in all environments.
This setup allows developers to create and control a local definition for development purposes while connecting to sensitive resources in a production environment through the same JNDI name.
reference :
https://docs.oracle.com/javase/tutorial/jndi/overview/index.html
I have two separate installs of WebSphere. (Actually one is WebSphere Application Server V6.1 with EJB 3.0 and Web Services feature packs, and the other server is WebSphere ESB Server V6.2). However, I know that ESB is really built on top of WAS, so it has all the configuration settings that a regualr WAS server has.
In my ESB server, I am trying to expose a service written as EJB 3.0 that will be deployed to the WAS 6.1 server. My question is not how to get EJB 2.1 calls to call into an EJB 3.0. We've done that already. My question is how to call across physical VM's. The WebSphere Application Server is running in its own cell/node/server from the ESB Server. From what I've read in IBM documentation, it is possible to set up a namespace binding on WAS to point to a remote EJB on another WAS instance. Thus you could use JNDI to lookup a bean on one WAS instance that really resides in another WAS instance. The beauty of this method is the location of the EJB you want is abstracted to the container level, and you don't have to drag around properties files of the IP addresses and ports that you need to access the bean should it change servers, etc. You just make a standard JNDI lookup to a remote EJB and you get it.
Sounds like it can be done. (See the following links:
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.express.doc/info/exp/ae/tnam_view_bindings.html) Especially follow the links on EJB and Indirect namespace bindings.
But I've been hitting my head against this for a while. It makes sense. It looks like it can be done. And the Indirect namespace binding looks the most promising. But I can't get it to work quite right. My ESB server keeps complaining about not finding comp/env/ejb in the context in which I am asking for it. Very puzzled by this one.
Just wondering if anybody has done this kind of thing before. Can you give me a concrete example of how you set this up in WAS to do so? Any help is appreciated
Well, I have since talked with IBM on how to do this and was surprised by their answer. They answered that if you are talking EJB to EJB within the same server or server cluster, then use EJB RMI via IIOP. With JNDI this abstracts where the bean is actually running (in a clustered environment).
If you are going from one server (or server cluster) across into a different server (or server cluster) regardless of whether or not the target and source are in the same cell, IBM recommended that you use messaging or web services. They felt that was a better method of abstraction between applications to keep them from being "tied" to each other. They did say that you could get EJB's to talk RMI via CORBA, but said to do that ONLY if absolutely necessary. And of course, you would need to know the IP and port number for coming in over CORBA (and that times each cluster member if in a clustered environment).
Again, this kind of surprised me, but it does make sense. Just thought I'd share these thoughts with the world, especially if you are working with WebSphere.
how to lookup from tomcat
use IBM JDK as runtime for tomcat
find bootstab port , use iiop in PROVIDER_URL
I was stuck with the same problem. After trying to include all the websphere and ibm orb jars found this article at ibm
How to lookup an EJB and other Resources in WebSphere Application Server using a Oracle JDK client - http://www-01.ibm.com/support/docview.wss?uid=swg21382740
basically used the CNCtxFactory instead of WsnInitialContextFactory
//props.put(Context.INITIAL_CONTEXT_FACTORY,"com.ibm.websphere.naming.WsnInitialContextFactory");
Hashtable env = new Hashtable();
env.put("java.naming.factory.initial", "com.sun.jndi.cosnaming.CNCtxFactory");
env.put("java.naming.provider.url", iioppath);