Michael Remijan

Author
+ Follow
since May 29, 2002
Michael likes ...
Java
Merit badge: grant badges
Biography
Java Team Manager | Java Developer | Java EE Developer | Java EE Architect | Author | Writer | Instructor
Cows and Likes
Cows
Total received
7
In last 30 days
0
Total given
0
Likes
Total received
11
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Michael Remijan

I'm personally biased because I worked on the EJB In Action Second Edition book. But the common believe that Spring is small and light-weight with Java EE being big and heavy is a complete myth. Stick with standard Java EE technology until there is a very, very good reason to use something else. If you do that, you'll find very little that you'll actually need outside of Java EE. The easiest way to learn is to get the Java EE 7 tutorial and start covering the major topics being used today: Part III The Web Tier, Part V Contexts and Dependency Injection for Java EE (No need to use an external framework for dependency injection), Part VI Web Services, Part VII Enterprise Beans, Part VIII Persistence,
Confusion-1: I have started with EJB. There are so many types of beans out there! Other than EJB (stateful, stateless, singleton, message-driven), I am coming across more types. Would you please tell me what is a managed bean?

EJBs are the part of Java EE which provide thread-safe high performance transactional operations for your application. Do you need to read-write to a database? Do that with an EJB. Do you need to need to update multiple database and send JMS message all within a transactions so all that work is atomic? Do that with an EJB.

Typically @Stateless beans are most commonly used. They can be deployed as part of a WAR, stand-alone as part of a JAR, or bundled into an EAR. Start your application by putting everything into the WAR and if you have great need then separate them later. @Stateless beans are also great for “micro services” because they are a thread-safe pooled resource so they provide very high performance servicing requests.

@Stateful beans are like a webapp session…each session gets its own instance to store its own stuff. These aren’t used much anymore.

@Singleton beans are most commonly used for configuration and reference data. They can be deployed as part of a WAR, stand-alone as part of a JAR, or bundled into an EAR. They can be configured to automatically instantiate when the application is deployed. They can cache reference data for the lifetime of the application – use your imagination for what kind of read-only reference data your application may need. Combine this with the @Scheduled annotation to automatically refresh the cached data periodically.

@MessageDriven beans are typically used for listing to JMS topics or queues for messages to process. Very valuable, but not needed by all applications.

BTW, this stuff is supported by a server that implements a the full Java EE specification or one that implements the Java EE Web Profile. Payara, WildFly, and TomEE are good. Avoid using Tomcat…it’s just Servlet/JSP container and as such lacks may of the Java EE features.

As the Java EE specification evolves, it’s looking like the having a separate specification defining the EJB components will eventually go away and a lot of the functionality that EJBs provide will move into the CDI specification. Every application (typically) needs thread-safe transaction management so in my opinion they are essential. Question is do you use functionally provided to you by your EE server or roll your own solution?

Confusion-2: I see that EJB's are sometimes referred to as CDI beans. What are these CDI creatures actually?

Context and Dependency Injection (CDI) is a completely different specification from EJBs. CDI is the Java SE and Java EE standard for doing dependency injection for your code. As the Java SE and Java EE standard, its preferable to use over other 3rd party dependency injection frameworks because your code is much more portable for use with either Java SE or Java EE applications because it avoids class path and backward compatibility issues.

From the standpoint of history, EJB components were part of the Java EE specification right from the beginning because of critical need for a component to handle transactional operations. A few years later, CDI was added to the Java EE specification to provide a standard for dependency injection.

Confusion-3: Are all types of beans (EJB, managed, entity, CDI, others I have not seen yet) sup posed to conform to the Java Beans Model by defining SET and GET methods? Is that a mandatory requirement?

No, it’s not a requirement. The Java Beans model is most heavily used by JPA and JSF. JPA is the Java SE and Java EE ORM standard, so it’s @Entity classes typically follow the Java Beans getter/setter because you need to get and set your data. JSF is the Java EE standard web view technology and it relys on the Java Beans model for mapping data coming in from HTTP GET/POST to Java objects.

Confusion-4: From my Java EE client application, I can easily obtain a reference to a stateless session bean with the @EJB annotation. But I am having a hard time trying to distinguish between @EJB, @Inject, and @Resource.

@EJB was the very first dependency injection supported by Java EE. @EJB came before the CDI specification existed for Java EE. Once the CDI specification became part of Java EE, it’s @Inject tag could anything, including instances of EJBs. So there is some overlap between the two. There are some very subtle differences between using @EJB and @Inject and it’s one of those things that if you have a need for the subtle difference then you’ll know about it – you’re using a remote EJB. Using @Inject is preferred and will be correct the majority of the time. Using @Inject is used for injecting instances of classes from you’re application’s code. The @Resource annotation also does dependency injection but thing of using @Resource as a way to get something from your application server – an EntityManger for JPA, a JNDI variable, etc.

Confusion-5: Regarding message driven beans, what is the difference between a MessageDrivenContext and transaction context? When would I prefer one to the other?

I’m not too familiar with messaging so I won’t comment on this one.

Confusion-6: Where does a messaging service provider fit in the n-tier hierarchy? The EIS tier? Aren't queues/topics part of the messaging service provider? Then why is a queue configured separately for use with Glassfish MQ?

GlassFish comes with its own messaging server and yes, you use the GlassFish admin console to setup queues and topics your application needs to use. How you use messaging in your application is outside the scope of a quick discussion, but, in general your code should always connect to a topic or queue provided by the application server and not have any concern for how the queue or topic is actually configured. For example, the queue may be using the messaging server provided by GlassFish or the queue may be connecting to a messaging server at another company you want to do business with. Your application doesn’t care about the details…it just know that the queue I want to connect to is bound to “java/com/env/jms/myqueue” and that’s it. The messaging servers take care of all the nasty details of making sure no message gets lost and all messages eventually get delivered.


Confusion-7: This is giving me a really hard time. JDNI. I know that java:comp/env is a naming space/environment that is private to each EE component, but what is its role actually? Is it us ed when a component attempts to find a reference by using portable global JDNI lookup? Is it used when a component attempts to find a reference by using @EJB?

JNDI namespaces are confusing. Here’s a summary:

java:comp
Lookups in this namespace are scoped per component. For example, an EJB is a component, so each EJB in a JAR file gets its own unique java:comp namespace. This means both AccountEJB and CartEJB can look up java:comp/LogLevel and get different values. For backward compatibility, this isn’t true for the web module. All components deployed as part of a WAR share the same java:comp namespace. It’s unlikely you’ll use this namespace very often. It’s mostly there for backward compatibility. Prior to Java EE 6, java:comp was really the only standard namespace.

java:module
Lookups in this namespace are scoped per module. All components in the module share the java:module namespace. An EJB-JAR file is a module, as is a WAR file. For backward compatibility, the java:comp and java:module namespaces are treated identically in web modules and refer to the same namespace. You should favor the use of java:module over java:comp when possible.

java:app
Lookups in this namespace are scoped per application. All components in all modules in the application share the java:app namespace. An EAR is an example of an application. All WARs and EJBs deployed from the EAR would share
this namespace.

java:global
Lookups in this namespace are global and shared by all components in all modules in all applications.


In general, Java EE applications are supposed to be configured like this. Suppose you need a database DataSource so you can read/write from a database. Your application code can use a JNDI lookup like this to get it: ctx.lookup(“java:module/env/jdbc/myoracledb”). Now when you go to your application server’s admin console and you create a database connection pool, your application server (this is application server specific) may put the DataSource in JNDI at “java:global/jdbc/OracleProdDB”. At this point your code is different than the application server, but that’s OK. At this point you would look at what application server-specific configuration files you can include in you WAR that specify a configuration to map java:module/env/jdbc/myoracledb to java:global/jdbc/OracleProdDB so your application code can actually find the resource.

Because this can get so confusing, it’s typically better to stick with the annotations which inject the resources and figure it out for you.
I've done work with remote EJBs and GlassFish/Payara. I wrote an blog article about it an number of years ago: http://mjremijan.blogspot.com/2011/06/secure-ssl-ejb-communication-with.html. This article details GlassFish-to-GlassFish remote EJB communcation. It also details how to do the communication between the two serves over SSH (which was my requirement at the time and prompted the writing of the article) which you won't need. I've not done this with a stand-alone Java SE client, but my article could provide you with some information that you need, especially when it comes to JNDI names. Hope this helps somewhat.
EJBs are just annotated pojos so yes they are very easy to test. remember to write your unit tests to test ONLY that EJB and mock out any other resources/dependencies the bean needs. As for TDD, everyone has an opinion and from my experience I would not take this approach. Code your bean, get it working, then use a unit test as a code-quality and -review tool to make your bean better. Once you start coding a unit tests, how to make your bean better will usually be very apparent. Got 20 dependencies in your bean you need to mock...probably you bean is doing too much work and taking too much responsibility. Got to write 10 tests to cover all branches of a method...method is probably too complicated. etc.
I've done some research on this and so far the solution I've found is to combine CDI producers with an injected Instance. I'll give some cliff notes on what I mean.

The code that needs an EntityManager would inject an Instance instead of an EntityManager directly. here is what it woiuld look like:



Then when an EntityManager is needed, call the get() method.



You couple this with a class which @Produces an EntityManager. For example, here is one I put together doing some R&D.



The @Produces public EntityManager getEntityManager() {} method is resposible for producing the EntityManager. The setDatabaseDirectory(...) responsible for changing the configuration to attach to a different database. In my case I have a single PU in my persistence.xml and this class simply changes the file system directory of the Derby database to connect to. In my application, I @Inject EntityManagerProducer just like any other bean and call the setDatabaseDirectory() method to switch to a different database. Once any db activity happens after that it' happens on the new database.

How you change the internals of EntityManagerProducer to point to a different database is up to you. using a method like setDatabaseDirectory() is easy. Another option is to create your own annotations (not CDI qualifiers, just regular annotations) to pass additional information to the @Produces producer method. I'd take the easiest approach first. One you have somet8ing working then you can make it fancier.



Hopefully this will give you enough info to apply to your use case.



easiest thing to do is to create a 3rd project, which is Maven EAR project. Have dependencies on both the EJB and the Servlet project so they both get packaged in the EAR. Then deploy the EAR as a single unit to weblogic. From your servlet, you can either use either @EJB MyTestEJBLocal MmyTestEJBLocal; or @Inject MyTestEJBLocal myTestEJBLocal;
Code the interceptor to do some logging. If all else fails, throw an exception in the Interceptor then it should be prettyy clear if the interceptor is firing or not.
You shouldn't be using JNDI. It has its uses but not in this case. If your bean's interface is LocalInterface.java, then inject it with either:

@Inject LocalInterace myBean

or

@EJB LocalInterface myBean


So since you are doing a remote bean you need some special iiop configuration on the client mvc side in order to access the remote bean. If both EARS are on the same server you can try a local bean. I'd start with putting everything into a single ear and use local beans first.
Are you trying to do a remote bean deployed on a different server?
And this solved the issue having the client and server on different hosts?
EJB SSL communication is tricky. It took me a couple weeks and I was working with a GlassFish security developer on it. I have a HOW-TO blogger article on it. http://mjremijan.blogspot.com/2011/06/secure-ssl-ejb-communication-with.html. This was written before GlassFish 4 but hopefully it is still applicable.
Yes, they are safe to delete. It is what arquillian does in order to run integration tests in the EJB embedded container.
Servlets aren't singletons either. Not sure if that configuration was removed in EE 7 but you can have multiple instances of servlets pooled just like EJBs to handle incoming requests. This pooling is all handled by the app server.