Last week, we had the author of TDD for a Shopping Website LiveProject. Friday at 11am Ranch time, Steven Solomon will be hosting a live TDD session just for us. See for the agenda and registration link
Last week, we had the author of TDD for a Shopping Website LiveProject. Friday at 11am Ranch time, Steven Solomon will be hosting a live TDD session just for us. See for the agenda and registration link

Ravi Bansal

Ranch Hand
+ Follow
since Aug 18, 2008
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 Ravi Bansal

Thank you Paul/Jayesh.

I agree that there might be something else . Is there any way that I can find out what that "something else" is which might be doing it. ?

Initially I thought may be its the SOAP UI tool itself from where I am testing the rest service call is doing that, Then I tested with chrome web store rest console. Same issue persisted and strangely Its not happening for all the header-names. I ran few tests on some of the headers

Actual Header name is LANGUAGEINTERPRETERREQUIRED and its getting Converted to LanguageinterpreterRequired
Actual Header name is MEDSTARTDATE and its getting Converted to MedStartDate
7 years ago
I am having Rest service exposed (using Spring framework ) where in I am trying to access custom http headers. When I am retrieving the headers in the controller class , Strange thing I observed is that spring framework is converting case of header names to camel case.

For example if I call rest service from soap UI by passing the http header name as "RAVIKUMAR" in caps , what I am seeing in the controller class, header name is now "RaviKumar" .

I know as per http spec , header names are case-insensitive. But I want to see the logic how spring framework is playing with header names . Does anyone know which class in Spring has this logic ?

I tried to have a look and related class but could not find the place where its converting the headernames to camel case.

There is one place where it seems that its converting the headernames to lower case but not to camel case.

Any help in this regard will be highly appreciated.
7 years ago
I am developing an application in Java. I have to upload data from flat text files into a DB tables. Problem is, as the application is used by several vendors who have different systems, which can generate different flat text files. For example Vendor V1 may generate a text file where certain field starts at column 10 and another Vendor V2 may generate a text file where same filed may start at column 12. So In a way I have different parsing rules for different vendors.

What I want to achieve is to create an application that loads “rules” from some specific place(may be some configurable file). These rules will be applied on flat text file to generate the data.

Afterwards there will be some transformations applied on that data ,before saving it to DB. Those transformations will again be vendor specific . For example vendor V1 may divide certain field with 10 before sending it to DB , while Vendor V2 may divide the same field 20 before saving it .

How can I achieve this? What is the best practice to design this solution ,you recommend?

I was thinking if I could create a MDB for this .

Use JPA for saving the data in DB (not sure if this is a gud idea ,as there could be 50-60k records in one text file)

But I am not sure what should I use to have parsing and transforming rules configurable .

Any Suggestions will be appreciated.
8 years ago
Hi Guys,

Do we have any tool/framework to calculate the response time of business methods in EJB container.?
I dont want to use manual way of writing the code logic to measure the time diff between method entry and exist.

Its sorted out now ...stupid mistake from me.....Map function in mapper class should have been fixed to remove upper case letter M , it should have been map
9 years ago
Hi ,
I am facing this exception when trying to run the first program on hadoop. (I am using hadoop new API on version 0.20.2).
I searched on web, it looks like most of the people faced this problem when they did not set MapperClass and ReducerClass in the configuration logic.
But I checked and it looks the code is ok . I will really appreciate if someone can help me out. Type mismatch in key from map: expected, recieved
at org.apache.hadoop.mapred.MapTask$MapOutputBuffer.collect(

Mapper class

Reducer Class

Configuration Class

9 years ago

Can you please try the following

  • Write A session bean and look up the connectionFactory from session bean (basically whatever you are doing in your Java SE Client)
  • deploy the session bean
  • Invoke the session bean from standalone client

  • If the above works , that will ensure that your server configuration of connection factory and queues is correct.

    Something must be wrong in your MDB client , other people who have experienced similiar problems , they fixed it by modifying the classpath.
    you need to make sure that you are referring the glassfish-client jar directly from installation directory (not from some other location on your system) because it contains MF file which includes the other liberaries automatically. see below link. Hope this will help you.

    Order of bean creation is not tied to order in which they recieve the messages
    MDB very much works like stateless session beans , where in container creates pool of MDB instances once the bean is deployed.
    once we have a pool , Container can pick any instance from the pool and delegate it to process the message. Order is not supposed to be preserved.

    Messages may be delivered out of sequence , EJB specs does not gurantee message delivery order.

    See Section 5.4.11 of ejb 3.1 spec.

    A container allows many instances of a message-driven bean class to be executing concurrently, thus allowing for the concurrent processing of a stream of messages. No guarantees are made as to the exact order in which messages are delivered to the instances of the message-driven bean class, although the container should attempt to deliver messages in order when it does not impair the concurrency of message processing. Message-driven beans should therefore be prepared to handle messages that are out of sequence: for example, the message to cancel a reservation may be delivered before the message to make the reservation.

    Hope this helps.
    Thanks Paul.

    Based on your answer , I have posted some further queries on the same topic . Can you please have a look at it ?
    I have a question regarding the @EJB Usage

    Is it possible to call inject an EJB using @EJB annotation , which is residing on different App Server than where Caller EJB is residing.

    For example AppServer server1 has an EJB A
    AppServer server2 has an EJB B

    I want to inject B into EJB A using @EJB annotation (without using any look up logic) , where will I give the host name information for AppServer 2 ? I dont see any attribute in EJB which I can use to provide that.

    is the only workaround to have in class path of EJB A ?
    EJB 3.1 Spec Section 5.4.2

    The message-driven bean class’s implementation of the javax.jms.MessageListenerinterface distinguishes the message-driven bean as a JMS message-driven bean.

    This means that MDB also supports non-JMS messages (means other than JMS message types) depending on listener interface it implements . Can anyone give any example of such interface.?
    I checked many references and seems that all of them are in context of processing JMS messages.

    From the same section of Spec , there is another qoute

    A bean’s message listener interface may define more than one message listener method. If the message listener interface contains more than one method, it is the resource adapter that determines which method is invoked.

    Again, I could not find any example of message listener interface which has more than message listener method. Can anyone explain this by some example ?

    Thanks in Advance
    Ok, reading this way, makes more sense .

    Thanks Frists. I found Your explaination really useful .
    Thanks Frits for spending time on this.

    Reading all this makes one point certain

    Stateless Seession bean will never be re-entered because every call to business method will take it to new/different instance.
    If specficaition say that "Stateless session beans do not have to be coded as re-enterant".

    Is there any way that this can be achieved ? I mean can I code re-enteant stateless session bean somehow?

    Thanks alot for your time Frits.

    Reading at your answer , I am having few more doubts now.

    4.10.13 Non-reentrant Instances
    The container must ensure that only one thread can be executing a stateless or stateful session bean instance at any time. Therefore, stateful and stateless session beans do not have to be coded as reentrant. One implication of this rule is that an application cannot make loopback calls to a stateless or stateful session bean instance.

    When a loopback call is a made , there is still a single thread of control (be it on same stateful session instance or new stateless instance), then why the reasoning for stopping the re-entering in the bean is given in terms of thread ? will this re-enterant bean result in multiple threads accessing the session beans (stateful or stateless ) instance somehow?

    You mentioned about ejb 3.2 spec, is it published somewhere (Draft version) ?

    You also mentioned

    This last explanation ("The existing....") is being discussed to be changed right now:

    The object reference returned from SessionContext.getBusinessObject is to be used for the subsequent invocations (see 4.3.3), not reentrant calls.

    What do you mean by subsequent invocations over here ? As I understand in ejb 3.2, In case of stateful session bean , it will be re-enterance call in the same instance and in case of stateless session bean , it will re-entry in a new/different instance. That also implies to me getBusinessObject will only be useful in case of singleton session beans.

    I am not sure if these questions make sense but seems that I am missing something here.