Sanjeev Verma

Ranch Hand
+ Follow
since Aug 24, 2000
Merit badge: grant badges
For More
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 Sanjeev Verma

We have a use case where a web app running on JBoss 5.1 (say Application A) needs to programatically log into another application (say Application B). Application B uses Kerbros as its authentication mechanism.
1.We first created a standalone client that is able to successfully log into Application B using JAAS and Java GSS-API. So that works.
2.Next, we created a very simple, HelloWorld like web app, with only one servlet. Inside the doGet method of this servlet we incorporated the same code as the standalone client we had created in #1 and deployed it to a fresh install of JBoss 5.1. When this servlet is invoked, we see the exception inlined below.
3.The same servlet web-app when deployed to Weblogic 10.x works without any changes, as is.

What are we missing here? My hunch is that JBoss has a implementation of the security APIs (*) that is being picked up by the server at runtime in place of the default JRE implementation, causing this exception. So how do we tell JBoss not to use its own implementation? What needs to be done to make this work inside JBoss 5.1?

I am listing entire code from inside the test servlet below. The exception gets thrown from inside the "public LoginContext login(Subject subject)" method. Please let me know if any further information is needed, I will be happy to provide.



9 years ago
Awesome, this might be exactly what I need ! I will try this out later today and let you know. Thanks Jaikiran !
12 years ago

Jaikiran Pai wrote:A non-persistence timer would still be transactional. It just won't be able to maintain state across restarts.

That is exactly the answer I was hoping for, thanks! As I mentioned, app design takes care of timer initialization in my case, so i think I am good then.

Thanks much for you help, very appreciated!
12 years ago

This is a very newbie question I guess - I am trying to use Spring to get reference to my JPA EntityManager in a application deployed on JBoss. My question is, what JNDI name do I use? Below is some configuration:

My persistence.xml looks like this:

My spring configuration looks like this:

Whenever I try to access the injected entityManager reference from inside dealPersistor bean, I get the following error from JBoss:

Obviously I am not doing some configuration correct...Can someone please help!

Thanks for looking.
12 years ago
Ok, so I had another breakthrough today. After carefully examining the difference between my standalone java client that was sending the messages to the servletcontextlistener impl that was not successful, I saw only one difference - the parameters that I was passing in the createSession() method of the Connection. In the client, it looks like this:

In the ServletContextListener impl, it looked like this:

So, while I was trying to get a non transacted session in the java client, I was trying to get a transacted session from inside the servletcontextlistener impl. I changed the boolean parameter to false, and sure enough, everything came together!

But surely this is not a good thing. My question is, how can I get a transacted session? I tried using the XAConnectionfactory instead of Connectionfactory to get the jmsConnection, but that did not help. Any ideas please?

Thanks for all your help!
12 years ago
Thanks for the response Jaikiran, very appreciated.

Jaikiran Pai wrote:Using persistent or non-persistent timers is something that your application has to decide. For example, what behaviour do you want to see if a timer is scheduled 30 minutes from now and the server is stopped before the timer is triggered? Would you want to trigger it when the server is up (let's say 5 hours later)?

As I explained above, I am designing the app such that on every start up, the timer is initialized. So I think I am ok with the timer not being persisted across server restarts. Thanks for clarifying! One more related question - what impact, if any, will using a non persistent timer have on the transactional behavior of the timer? If there is any, then I will have to rethink my design.

Thanks again for all your help!
12 years ago
Bumping this...any help on how to get my servletcontextlistener impl send messages to the MDB? Please!

12 years ago
Hi All:

I am observing some strange behavior in a MDB that I am deploying to a JBoss server (v5.1.0). This MDB also has a EJB3 timer component to it. My current strategy is like this:

1. I have a ServletContextListener impl as part of my application. This impl will execute as the application starts up, and as part of execution, it will send a message to the above timer MDB.
2. On receipt of this message, the MDB will configure the timer from inside the onMessage method, which in my case, is to execute the @Timeout method first time after 5 minutes, and then after every 30 minutes.

The behavior I see is actually quite strange. First of all, for some reason I am not able to send a message to the queue on which my MDB is listening, but that is a question I am pursuing in another thread here. However, using a standalone java client, when I do activate the MDB, I see that the MDB sets up the timer appropriately. So now when I shut down the server and start it up back again, my expectation is w/o the initialization, the Timer inside the MDB will not fire, but that is not the case! So the second time around if I again initialize the MDB with a message, now I will have two timers executing the @Timeout method! and if I shutdown the server and repeat this process again, I will have 3 timers now, and so on.

I did some research, and I think I know what might be going on. In JBoss, timers are persisted by default, so every time I create a timer, it is persisted across server restarts, I think. Inside my server install, I found this text inside the ejb2-timer-service.xml:

I think all I need to do is to uncomment the "A persistence policy that does not persist the timer" and comment out the "persistence policy that persists timers to a database". Is that correct? And, more importantly, is that the right thing to do in the case of my application, given the scenario that I have described above? What have others experienced and what is the best practice around this? Please let me know.

Thanks is advance for looking!
12 years ago
Thanks for the reply Jaikiran, very appreciated.

To answer your question - Yes, I did, and it did not make a difference.

I did try something else though, and that worked. I basically built a standalone java client to send messages to the two queues, and that did activate the MDBs. So that makes me believe that the MDBs are set up properly, its is only the part where i am sending messages from inside my ServletContextListener that is not working for some reason. My Java client impl looks like this:

And my MDB looks like this:

Finally, my ServletContextListener impl looks like this:

And I do see some more strange behavior on the timer, but i will save that question for another thread.

Thanks again for all your help.
12 years ago
Yup, tried that, and no change. Still the same .

Another question - what does the annotation below do?

My understanding is that it tells the MDB not to start till the above service (JMS queue) is available. Is that correct? Does it do anything else? Could it be playing a role in what I am experiencing?
12 years ago

I am trying to deploy a MDB application onto JBoss 5.1.0 instance. The MDB in discussion has a timer associated with it. I am seeing two issues that I am trying to get to the root of:

1. The messages that I am sending from a ServletContextListener implementation are not being received by the MDB. I do not see any exceptions in the server log file, but in looking at the admin console, I see that the message count on the queue is not going up either, making me think that either the counter on the console is buggy, or really my messages are not being delivered. What is annoying is that JBoss is silent about it, does not want to give any error!

2. The MDB has a timer associated with it. The way I have defined the timer is that it should fire the first time 5 minutes after the timer is setup, and then every 30 minutes. The purpose of sending the message from the ServletContextListener implementation above is to initialize/setup the timer. Unfortunately, although as i note above, the messages i am sending are not being processed, but, strangely enough, the method that is annotated as @Timeout does fire up immediately on deployment. Why is this happening.

For problem #1 above, I think it has something to do with the way I have set up my queue and how I am mapping the queue inside the ServletContextListener and the MDB setup itself. I have tried many combos, but all in vain.

For problem #2 above, i am really in the not know why it is displaying this behavior.

So, HELP!!!

Enough said, some code now:

I define my destinations inside a *-destinations-service.xml file, which is pakaged inside the META-INF folder of the ejb-jar file. The definition looks like this:

My MDB looks like this:

My ServletContextListener Implementation looks like this:

Please let me know if you need any more info.

Thanks in advance for all your help!!!
12 years ago
We are using Sybase 11.9, which does not support XA. And lets just say the environment is not in my hands, I cannot change it on my free will .

Any ideas?
Hi Guru's

We are using Weblogic 8.1 with sybase, and are using Sybase JConnect driver to connect to database. JConnect is a non XA compliant driver, so we are using the "Emulating Two-Phase Commit" feature that weblogic offers. It is not really much as weblogic clearly states that:

When the Emulate Two-Phase Commit for non-XA Driver option is selected (EnableTwoPhaseCommit is set to true), the non-XA JDBC resource always returns XA_OK during the XAResource.prepare() method call. The resource attempts to commit or roll back its local transaction in response to subsequent XAResource.commit() or XAResource.rollback() calls. If the resource commit or rollback fails, a heuristic error results. Application data may be left in an inconsistent state as a result of a heuristic failure.

My question is - is there a best practice to manage a distributed transaction is such a scenario. In my specific case, I have to make updates across to sybase servers, and send out a JMS message, all in one transaction. Any ideas how best to satisfy transactionality in this case while still letting the container manage majority of the work? Any pattern?

I have one idea on this. Not much, in fact quite dirty. I will share it later, don't want to pollute your minds right now!

Thanx for reading.


Already I have used weblogic API to deploy my ear file, it was successful.

Now, I have a typical problem like I would like create a single program through which I want to deploy ear file on different app servers (say weblogic, websphere, oas etc.).

So, I would like to use pure jsr 88 API (from sun java), so that it would be a common API and only class differs is that app server specific classes for registering the implementation factory.

Again, unless you have a very specific reason for doing it the way you are planning to, i.e., via the JSR 88 way, I would not advise this approach. I would rather prefer using ANT build scripts for doing this. Most app servers today provide integration with ANT for deployment purposes, and that is the easiest interface to use.

I am able to get the DeploymentManager instance using jsr 88 APIs. Now, next step is getting the DeployableObject for the given ear file, as far as I have searched there is no implementation class for this interface or any classes seem to give the instance of DeployableObject. But, I have seen WebLogicDeployableObject implements DeployableObject, but it would be narrow to weblogic. If I use this class, then for other app servers, I need to have app server specific DeployableObject, isn't it? So, looking for pure jsr 88 api for this.

I do not know much about JSR 88, but I will chance a guess here. In all likelyhood, *JSR 88 compliant* app servers need to provide an implementation of the DeployableObject interface, which JSR 88 compliant IDE's can then access in a vendor nuetral way to deploy ears, like in the case of what you experienced for weblogic. Does that make sense?

I know the person who was involved in this JSR. I will try and get her to comment on this as well.
Hi Guru:

It is not clear from your query as to what you are tryng to accomplish. To just deploy an ear file, you do not need to do anything w.r.t. JSR 88, or the DeployableObject interface. Just follow the standard weblogic documentation.

On the other hand, if you are developing a plugin for some JSR 88 compliant IDE to deploy ears to weblogic, that is a different matter. The following URL might of help in that case.