Re: Using @Resource causes NPE at org.jboss.ejb3.JndiUtil.lookup
by samk＠twinix.com
See Thread at: http://www.techienuggets.com/Detail?tx=30772 Posted on behalf of a User
I have had a similar problem with MDBs.
My problem was that the resource is was referring to via the mapped name was not infact a QueueConnectionFactory but infact something completely different... the provider adapter.
By correcting the mapped name, the problem was fixed.
The exception / stack trace provided no guidance to solving this problem... only through trial and error did I realise the cause.
In Response To:
Hello,
In a stateless EJB im using:
| @Resource(name = "mail/localMail", mappedName = "Mail", shareable = true, type = Session.class)
| private Session m_mailSession;
|
Trying to connect the Bean from a Client I got an NullPointerException.
Im using JBoss-4.2.2.GA default installation without any changes
Windows XP
Any hints?
Regards,
Georg
| Exception in thread "main" java.lang.NullPointerException
| at org.jboss.ejb3.JndiUtil.lookup(JndiUtil.java:49)
| at org.jboss.injection.JndiPropertyInjector.lookup(JndiPropertyInjector.java:87)
| at org.jboss.injection.JndiPropertyInjector.inject(JndiPropertyInjector.java:112)
| at org.jboss.injection.JndiPropertyInjector.inject(JndiPropertyInjector.java:107)
| at org.jboss.injection.JndiPropertyInjector.inject(JndiPropertyInjector.java:65)
| at org.jboss.ejb3.AbstractPool.create(AbstractPool.java:111)
| at org.jboss.ejb3.InfinitePool.get(InfinitePool.java:49)
| at org.jboss.ejb3.ThreadlocalPool.create(ThreadlocalPool.java:50)
| at org.jboss.ejb3.ThreadlocalPool.get(ThreadlocalPool.java:90)
| at org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:54)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at org.jboss.aspects.security.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:77)
| at org.jboss.ejb3.security.Ejb3AuthenticationInterceptor.invoke(Ejb3AuthenticationInterceptor.java:110)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:46)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at org.jboss.ejb3.asynchronous.AsynchronousInterceptor.invoke(AsynchronousInterceptor.java:106)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at org.jboss.ejb3.stateless.StatelessContainer.dynamicInvoke(StatelessContainer.java:304)
| at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:106)
| at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
| at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:769)
| at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:573)
| at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:373)
| at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:166)
| at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:163)
| at org.jboss.remoting.Client.invoke(Client.java:1634)
| at org.jboss.remoting.Client.invoke(Client.java:548)
| at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:62)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:67)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:53)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:74)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at org.jboss.ejb3.stateless.StatelessRemoteProxy.invoke(StatelessRemoteProxy.java:107)
| at $Proxy0.registration(Unknown Source)
| at gse.client.Client.main(Client.java:13)
| at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:74)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:67)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:53)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:74)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at org.jboss.ejb3.stateless.StatelessRemoteProxy.invoke(StatelessRemoteProxy.java:107)
| at $Proxy0.registration(Unknown Source)
| at gse.client.Client.main(Client.java:13)
|
|
18 years, 3 months
[JBoss Messaging] - JMSServerInvocationHandler deadlock
by azafran
Similar to post http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4051404#4051404, we are facing a dead lock in the JMSServerInvocationHandler.
JBM version 1.3.0 GA
JBAS version 4.2.0 GA
Java 1.5.0_08
OS Sun sparc 5.10 on Sun-Fire-V490
This is the stack trace of the running tread:
Thread: WorkManager(2)-222223 : priority:5, demon:true, threadId:536697, threadState:RUNNABLE, lockName:null
java.net.SocketOutputStream.socketWrite0(Native Method)
java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)
java.net.SocketOutputStream.write(SocketOutputStream.java:136)
java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65)
java.io.BufferedOutputStream.flush(BufferedOutputStream.java:123)
java.io.DataOutputStream.flush(DataOutputStream.java:106)
org.jboss.jms.wireformat.ClientDelivery.write(ClientDelivery.java:93)
org.jboss.jms.wireformat.JMSWireFormat.write(JMSWireFormat.java:237)
org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedWrite(MicroSocketClientInvoker.java:969)
org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:557)
org.jboss.remoting.transport.bisocket.BisocketClientInvoker.transport(BisocketClientInvoker.java:339)
org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:122)
org.jboss.remoting.Client.invoke(Client.java:1550)
org.jboss.remoting.Client.invoke(Client.java:530)
org.jboss.remoting.Client.invokeOneway(Client.java:580)
org.jboss.remoting.callback.ServerInvokerCallbackHandler.handleCallback(ServerInvokerCallbackHandler.java:687)
org.jboss.remoting.callback.ServerInvokerCallbackHandler.handleCallbackOneway(ServerInvokerCallbackHandler.java:564)
org.jboss.jms.server.endpoint.ServerConsumerEndpoint.handle(ServerConsumerEndpoint.java:296)
org.jboss.messaging.core.local.RoundRobinPointToPointRouter.handle(RoundRobinPointToPointRouter.java:120)
org.jboss.messaging.core.ChannelSupport.deliverInternal(ChannelSupport.java:608)
org.jboss.messaging.core.ChannelSupport.handleInternal(ChannelSupport.java:769)
org.jboss.messaging.core.ChannelSupport.handle(ChannelSupport.java:157)
org.jboss.messaging.core.local.PagingFilteredQueue.handle(PagingFilteredQueue.java:114)
org.jboss.messaging.core.plugin.postoffice.DefaultPostOffice.route(DefaultPostOffice.java:333)
org.jboss.jms.server.endpoint.ServerConnectionEndpoint.sendMessage(ServerConnectionEndpoint.java:692)
org.jboss.jms.server.endpoint.ServerSessionEndpoint.send(ServerSessionEndpoint.java:297)
org.jboss.jms.server.endpoint.advised.SessionAdvised.org$jboss$jms$server$endpoint$advised$SessionAdvised$send$aop(SessionAdvised.java:80)
org.jboss.jms.server.endpoint.advised.SessionAdvised$send_6145266547759487588.invokeNext(SessionAdvised$send_6145266547759487588.java)
org.jboss.jms.server.container.SecurityAspect.handleSend(SecurityAspect.java:152)
sun.reflect.GeneratedMethodAccessor430.invoke(Unknown Source)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
java.lang.reflect.Method.invoke(Method.java:585)
org.jboss.aop.advice.PerInstanceAdvice.invoke(PerInstanceAdvice.java:121)
org.jboss.jms.server.endpoint.advised.SessionAdvised$send_6145266547759487588.invokeNext(SessionAdvised$send_6145266547759487588.java)
org.jboss.jms.server.container.ServerLogInterceptor.invoke(ServerLogInterceptor.java:105)
org.jboss.jms.server.endpoint.advised.SessionAdvised$send_6145266547759487588.invokeNext(SessionAdvised$send_6145266547759487588.java)
org.jboss.jms.server.endpoint.advised.SessionAdvised.send(SessionAdvised.java)
org.jboss.jms.wireformat.SessionSendRequest.serverInvoke(SessionSendRequest.java:85)
org.jboss.jms.server.remoting.JMSServerInvocationHandler.invoke(JMSServerInvocationHandler.java:141)
org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:734)
org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:101)
org.jboss.remoting.Client.invoke(Client.java:1550)
org.jboss.remoting.Client.invoke(Client.java:530)
org.jboss.remoting.Client.invoke(Client.java:518)
org.jboss.jms.client.delegate.DelegateSupport.doInvoke(DelegateSupport.java:186)
org.jboss.jms.client.delegate.DelegateSupport.doInvoke(DelegateSupport.java:157)
org.jboss.jms.client.delegate.ClientSessionDelegate.org$jboss$jms$client$delegate$ClientSessionDelegate$send$aop(ClientSessionDelegate.java:446)
org.jboss.jms.client.delegate.ClientSessionDelegate$send_6145266547759487588.invokeNext(ClientSessionDelegate$send_6145266547759487588.java)
org.jboss.jms.client.container.SessionAspect.handleSend(SessionAspect.java:634)
org.jboss.aop.advice.org.jboss.jms.client.container.SessionAspect28.invoke(SessionAspect28.java)
org.jboss.jms.client.delegate.ClientSessionDelegate$send_6145266547759487588.invokeNext(ClientSessionDelegate$send_6145266547759487588.java)
org.jboss.jms.client.container.FailoverValveInterceptor.invoke(FailoverValveInterceptor.java:91)
org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:105)
org.jboss.jms.client.delegate.ClientSessionDelegate$send_6145266547759487588.invokeNext(ClientSessionDelegate$send_6145266547759487588.java)
org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:170)
org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:105)
org.jboss.jms.client.delegate.ClientSessionDelegate$send_6145266547759487588.invokeNext(ClientSessionDelegate$send_6145266547759487588.java)
org.jboss.jms.client.delegate.ClientSessionDelegate.send(ClientSessionDelegate.java)
org.jboss.jms.client.container.ProducerAspect.handleSend(ProducerAspect.java:243)
org.jboss.aop.advice.org.jboss.jms.client.container.ProducerAspect46.invoke(ProducerAspect46.java)
org.jboss.jms.client.delegate.ClientProducerDelegate$send_3961598017717988886.invokeNext(ClientProducerDelegate$send_3961598017717988886.java)
org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:170)
org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:105)
org.jboss.jms.client.delegate.ClientProducerDelegate$send_3961598017717988886.invokeNext(ClientProducerDelegate$send_3961598017717988886.java)
org.jboss.jms.client.delegate.ClientProducerDelegate.send(ClientProducerDelegate.java)
org.jboss.jms.client.JBossMessageProducer.send(JBossMessageProducer.java:164)
org.jboss.jms.client.JBossMessageProducer.send(JBossMessageProducer.java:207)
org.jboss.jms.client.JBossMessageProducer.send(JBossMessageProducer.java:145)
org.jboss.jms.client.JBossMessageProducer.send(JBossMessageProducer.java:136)
com.cisco.nm.dmm.ejb.DMMJ2EEQueueNtfsTask.publishMessage(DMMJ2EEQueueNtfsTask.java:134)
This is a sample stack trace of a blocked tread:
Thread: WorkerThread#70[64.104.149.89:4031] : priority:5, demon:false, threadId:539469, threadState:BLOCKED, lockName:java.lang.Class@1a31dd
org.jboss.jms.server.remoting.JMSServerInvocationHandler.invoke(JMSServerInvocationHandler.java:105)
org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:734)
org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:560)
org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:369)
org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:165)
Regards,
Asaf
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4144217#4144217
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4144217
18 years, 3 months
[EJB 3.0] - dependency graph issues with durable MDBs
by joe.marques＠jboss.com
I have a queue defined statically, in a *-service.xml file. I have an MDB listening to this durable queue.
As a consequence of the data processing that happens upstream, this queue has messages inserted into it in bulk, so it's possible that a user will shutdown the app server while there are still messages in the queue because they couldn't all be processed before the server was taken down.
When the server starts back up, the messages are processed, but they result in errors. Essentially, I gather that some of the downstream @EJB annotations haven't been resolved before the first message is delivered to the MDB.
Our service layer has a few dozen SLSBs that have various cyclic dependencies. These cycles were broken as necessary by the use of @IgnoreDependency. Unfortunately, it just so happens that if the MDB's @EJB annotations are following (to determine what services need to be started in order to process a message), the @IgnoreDependency annotations are encountered earlier in the cycle, and some things remain unstarted.
A fuller explanation of the problem, with an example and proposed work-around, can be found here: http://jira.rhq-project.org/browse/RHQ-217
Aside from the fact that the solution is time-consuming (given that we have about 2 dozen uses of @IgnoreDependency that need to be moved around), I don't feel the solution will work in every scenario (I explain that too). I'm hoping someone can point me in the direction of a simpler, complete solution that will work no matter what the dependency graph looks like.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4144212#4144212
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4144212
18 years, 3 months
[Security & JAAS/JBoss] - Security with Web Services
by thoism
Hi everybody,
I have implemented some web services residing in a war file deployed on my Tomcat. The web services module is a client to some EJBs deployed on my JBoss. I need to log the user in my realm on each WS request and log the user out before the WS response.
I have implemented security on web applications with JBoss and used JAAS realms succesfully but what do I do in this case with Web Services? I mean the requests are stateless. If I use the org.jboss.security.ClientLoginModule
won't this override the credentials of another user who is already logged in the realm?
I have also implemented a standalone application which spawns a thread for each user request and I am wondering about the same thing. This application is a service listening for some kind of messages; on a message the application should log the user in the realm before calling an EJB and log the user after the request is completed. So it's more or less the same situation as above.
Is this possible? I mean logging many users in the same realm in one non-web application?
Any ideas?
Thank you in advance!!!
thoism
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4144211#4144211
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4144211
18 years, 3 months