Ralf Pantförder

Sure! Thanks for the reply.

Hi Laurentiu,

do you go into Spring Batch in your book? If not: Can you recommend another book for Spring Batch?

Thanks for your answer!

Regards
Ralf

Hi Jonathan,
does the book cover tools for automated GUI testing, especially JMeter and Selenium?
Thanks for your reply.
Cheers
Ralf

Hi J Sharma & Ashish Sarin,

does the book cover Spring Batch – and if so, in which depth?

Thanks and regards
Ralf

Hi Raoul-Gabriel, Mario, and Alan,

I noticed there is a chapter in the book on "Tools, testing, debugging". I wonder whether debugging remains manageable and intuitional in such concise code employing streams, lambda expressions and the :: operator. Did you already have the chance to gain experience in debugging Java 8 code in some IDE? For instance, have you tried stepping into a lambda expression?

Thanks and regards
Ralf

Hi Panda, Reza, Ryan, and Michael,

I noticed there is a chapter in the book on using WebSockets with EJB 3. My question is rather a WebSockets question than an EJB-3 question: Is there a way of enclosing a WebSocket-communication into a technical transaction, and if so, would you regard WebSockets with EJB 3 as the preferred method of implementing transactional calls over the web (as opposed to classic JAX-WS with EJB 3)?

Thanks and regards
Ralf

Hi Cay,

I'd like to know your opinion about the benefit of the new language features of Java 8, like lambda expressions and the :: operator.

New Java language features of course make code more concise and coding more handy, but on the other hand they may considerably increase effort in (1) learning the language, (2) understanding code, (3) understanding what the compiler does, and, quite often, (4) debugging! Think of weird phenomena like a line of code as simple as i++; that triggers a NullPointerException due to autoboxing/-unboxing.

I'm personally not yet sure whether or not I like lambda expressions and the :: operator under these aspects. How do you feel about this?

Thanks and regards
Ralf

Suppose you have an EJB3 named MyBean in a module MyEJB.jar in an application MyApp. Suppose this bean has local and remote interfaces mypackage.MyBeanLocal and mypackage.MyBeanRemote. WebSphere then binds the local interface to two locations (see the server log output during startup):

ejblocal:mypackage.MyBeanLocal

ejblocal:MyApp/MyEJB.jar/MyBean#mypackage.MyBeanLocal

The former is the one I used in my above example. Employing the latter binding location, the lookup code would read something like this:
Context tContextEjblocal = (Context) new InitialContext().lookup("ejblocal:"); return (mypackage.MyBeanLocal) tContextEjblocal.lookup("MyApp/MyEJB.jar/MyBean#mypackage.MyBeanLocal");
But I don't see a need for this excess of complexity.

Likewise, WebSphere binds the remote interface to the following locations:

mypackage.MyBeanRemote

ejb/MyApp/MyEJB.jar/MyBean#mypackage.MyBeanRemote

Again, I would preferably use the simpler name for the lookup:
Context tInitialContext = new InitialContext(); return (mypackage.MyBeanRemote) tInitialContext.lookup("mypackage.MyBeanRemote");

From my point of view, this should work exactly as in my above example, i.e.:
SingleLocal singleLocal = NamingUtil.lookupEjbLocal(SingleLocal.class);
with Method NamingUtil.lookupEjbLocal(Class) defined as above.

Use global lookup, not local! For being able to locally lookup your bean, you would need to pollute you EJB 3.0 code with EJB-2.1-like interfaces (see above).

In your example, the global JNDI name ist ejblocal:org.siva.in.SingleLocal.

My approach would be the following:

Represent the whole matrix by a 3x3x3x3 array of cells, instead of a 9x9 array, so that, e.g., cell[0, 1, 2, 0] represents the lower (2) left (0) cell in the upper (0) middle (1) block.

This way, the 27 constraints ("no double number in each row / column / block") are much easier to formulate. More precisely: The block constraints are formulated analogously to the row and column constraints, like: "keep two of the four indices fixed, and vary the two other indices." You will have much less arithmetics in your program. In fact, I think there will be no "n / 3" and no "n % 3".

Represent the constraints by Sets of Integers. During initialization of the program, attach to each cell the pertinent constraints, so that each cell references three constraints, and each constraint is attached to nine cells.

Before filling a number into a cell, check whether this would violate any of the cell's three constraints, i.e., whether any of the three Sets already contains that number.

There is no <ejb-local-ref> in the above example. Instead, it uses the global JNDI name to lookup the bean's local interface. In a WebSphere AS, the default global JNDI name of an EJB 3.0 local interface is ejblocal:fully_qualified_classname.

The following helper method performs the global JNDI lookup, hiding the naming convention from client code:
public static <E> E lookupEjbLocal(Class<E> pClass) throws NamingException { // JNDI-Name ejblocal:<fully.qualified.classname> Context tContextEjblocal = (Context) new InitialContext().lookup("ejblocal:"); return (E) tContextEjblocal.lookup(pClass.getName()); }
It is used without type-cast in the following manner:
PlaceBid placeBid = NamingUtil.lookupEjbLocal(PlaceBid.class);
This is the most convenient way to lookup an EJB 3.0 from within EJB 2.1 code. However, it makes use of a proprietary naming convention. If you don't like this, or if you insist on using solely the environment naming context ("java:comp/env") for all lookups, you are in fact required to ad hoc define within your EJB 3.0 two additional EJB-2.1-like interfaces: (1) a local object, i.e. an interface extending javax.ejb.EJBLocalObject (not to be confused with the EJB3 local business interface), and (2) a local home, i.e. an interface extending javax.ejb.EJBLocalHome, specifying a standard create() method. These interfaces must then be referenced in the mandatory <local> and <local-home> sub-elements of the <ejb-local-ref> within your EJB 2.1 component.