This week's book giveaway is in the Python forum.
We're giving away four copies of High Performance Python for Data Analytics and have Tiago Rodrigues Antao on-line!
See this thread for details.
Win a copy of High Performance Python for Data Analytics this week in the Python forum!

Ralf Pantförder

+ Follow
since May 10, 2010
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Ralf Pantförder

Sure! Thanks for the reply.
2 months ago
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!

2 months ago
Hi Jonathan,
does the book cover tools for automated GUI testing, especially JMeter and Selenium?
Thanks for your reply.
4 years ago
Hi J Sharma & Ashish Sarin,

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

Thanks and regards
6 years ago
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
6 years ago
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
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
6 years ago
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:

    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:

    From my point of view, this should work exactly as in my above example, i.e.:

    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
    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.
    9 years ago
    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:

    It is used without type-cast in the following manner:

    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.