Meaningless Drivel is fun!*
The moose likes EJB and other Java EE Technologies and the fly likes MDB @PostConstruct error Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "MDB @PostConstruct error" Watch "MDB @PostConstruct error" New topic
Author

MDB @PostConstruct error

Alessandro Ilardo
Ranch Hand

Joined: Dec 23, 2005
Posts: 218
Hi there,
I'm trying to run a sample MDB which should send emails.
Jboss 4.0.5 GA - EJB3
I can correctly deploy the EJB Module,

10:28:17,683 INFO [Ejb3Deployment] EJB3 deployment time took: 26
10:28:17,692 INFO [JmxKernelAbstraction] installing MBean: jboss.j2ee:jar=Mail-EJBModule.jar,name=MailMDB,service=EJB3 with dependencies:
10:28:17,722 INFO [EJBContainer] STARTED EJB: eu.virtualLab.mail.MailMDB ejbName: MailMDB
10:28:17,725 WARN [MessagingContainer] Could not find the queue destination-jndi-name=queue/outGoingEmail
10:28:17,727 WARN [MessagingContainer] destination not found: queue/outGoingEmail reason: javax.naming.NameNotFoundException: outGoingEmail not bound
10:28:17,729 WARN [MessagingContainer] creating a new temporary destination: queue/outGoingEmail
10:28:17,762 INFO [outGoingEmail] Bound to JNDI name: queue/outGoingEmail
10:28:17,854 INFO [EJB3Deployer] Deployed: file:/etc/jboss-4.0.5.GA/server/default/deploy/Mail-EJBModule.jar
11:27:17,659 INFO [Ejb3Deployment] EJB3 deployment time took: 66
11:27:17,670 INFO [JmxKernelAbstraction] installing MBean: jboss.j2ee:jar=Mail-EJBModule.jar,name=MailMDB,service=EJB3 with dependencies:
11:27:17,712 INFO [EJBContainer] STARTED EJB: eu.virtualLab.mail.MailMDB ejbName: MailMDB
11:27:17,760 INFO [EJB3Deployer] Deployed: file:/etc/jboss-4.0.5.GA/server/default/deploy/Mail-EJBModule.jar


but I can't run it from a Client, belowe the stack trace from JBoss
11:38:55,699 INFO [ClientDeployer] Removing client ENC from: Mail-EJBModuleClient
11:38:55,737 INFO [ClientDeployer] Client ENC bound under: Mail-EJBModuleClient
11:38:56,686 ERROR [JmsServerSession] Unexpected error delivering message org.jboss.mq.SpyObjectMessage {
Header {
jmsDestination : QUEUE.outGoingEmail
jmsDeliveryMode : 2
jmsExpiration : 0
jmsPriority : 4
jmsMessageID : ID:9-11741279366781
jmsTimeStamp : 1174127936678
jmsCorrelationID: null
jmsReplyTo : null
jmsType : null
jmsRedelivered : false
jmsProperties : {sent=1174127936673}
jmsPropReadWrite: false
msgReadOnly : true
producerClientId: ID:9
}
}
java.lang.RuntimeException: java.lang.NullPointerException
at org.jboss.ejb3.interceptor.LifecycleInterceptorHandler.postConstruct(LifecycleInterceptorHandler.java:113)
at org.jboss.ejb3.EJBContainer.invokePostConstruct(EJBContainer.java:505)
at org.jboss.ejb3.AbstractPool.create(AbstractPool.java:112)
at org.jboss.ejb3.StrictMaxPool.get(StrictMaxPool.java:122)
at org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:54)


The client code is


and the MDB

from the logger the code seems to break off in the line where it try to get a Mail session.
What's my mistake here?
Thank you in advance.
[ March 17, 2007: Message edited by: Alessandro Ilardo ]

trying to decode a woman mind....
Reza Rahman
author
Ranch Hand

Joined: Feb 01, 2005
Posts: 580
    
    5
Take a careful look at your JNDI tree. It looks like the mail session is never being retrieved...


Independent Consultant — Author, EJB 3 in Action — Expert Group Member, Java EE 6 and EJB 3.1
Jaikiran Pai
Marshal

Joined: Jul 20, 2005
Posts: 10101
    
164

private SessionContext context;
private javax.mail.Message msg = null;
Properties htmlTags = new Properties();
private final Logger logger = Logger.getLogger(getClass().getName());

@PostConstruct
public void initialize() {
logger.info("[initialize] PostConstruct. ok!");
Session session =(Session)context.lookup("java:comp/env/mail/Mail");


Looks like the "context" member variable is not yet initialized and you are invoking the lookup method on that null object.


[My Blog] [JavaRanch Journal]
Alessandro Ilardo
Ranch Hand

Joined: Dec 23, 2005
Posts: 218
thanks for your replies.
I went trough the J2EE tutorial about JNDI and I have corrected my mistake.
However it is not clear to me why on JBoss the file mail-service.xml comes with a default jndi name as java:/Mail and if I try change it as the tutorial says
Note: To avoid collisions with names of other enterprise resources in the JNDI
namespace, and to avoid portability problems, all names in a J2EE application
should begin with the string java:comp/env.

so, java:comp/env/mail/Mail a get an error

(code)

while if I call it with its default name I don't get any error.
[ March 18, 2007: Message edited by: Alessandro Ilardo ]
Jaikiran Pai
Marshal

Joined: Jul 20, 2005
Posts: 10101
    
164

To do that, you have to first add some more additional contents to your configuration files. And once you do that the java:/comp/env/mail/Mail will act as a indirection to the actual java:/Mail
Alessandro Ilardo
Ranch Hand

Joined: Dec 23, 2005
Posts: 218
The bean now works properly, but I don't understand what you mean with your last reply.

which additional contents should I add to the conf. file?
Is it not sufficient to match both jndi names between the configuration file and the the bean?

The conf. file now looks like this:


If you don't mind, I've still got a doubt about my code shown above. Can I ask you when I should use SessionContext object instead the Context for the lookup?

Thank you again.
Jaikiran Pai
Marshal

Joined: Jul 20, 2005
Posts: 10101
    
164

The bean now works properly, but I don't understand what you mean with your last reply.

which additional contents should I add to the conf. file?
Is it not sufficient to match both jndi names between the configuration file and the the bean?


Here's what i meant - If you did a lookup of java:/Mail then its going to work because the jndi name matches the configuration file. Using the java:/Mail would mean that you are using the jndi namespace which is accessible to all the applications deployed in the application server's JVM.

As you already pointed out in one of your posts :

Note: To avoid collisions with names of other enterprise resources in the JNDI
namespace
, and to avoid portability problems, all names in a J2EE application
should begin with the string java:comp/env.


To avoid collisions with names of other enterprise resources in the JNDI
namespace it is recommended that the application should use the java:comp/env namespace which is specific to the application. Each application deployed in the application server's JVM will have its own java:/comp/env jndi namespace. This would mean that App1 deployed on the JBoss server can bind an object to "java:/comp/env/xyz" and another App2 deployed on the same JBoss server can bind a different object to the "java:/comp/env/xyz" without overwritting the object of App1. This is possible because each application will have its own java:/comp/env namespace. Now consider the same scenario in the case of java:/ namespace. As already mentioned above, the java:/ namespace is *shared* by all applications deployed on the application server. This would mean that the two applications App1 and App2 deployed on the server CANNOT bind their objects to the same jndi name java:/xyz.

Now coming to the other part:


Note: To avoid collisions with names of other enterprise resources in the JNDI
namespace, and to avoid portability problems, all names in a J2EE application
should begin with the string java:comp/env.


To avoid portability problems - Let's assume JBoss provides it naming service at java:/Mail jndi name. And in your code you do a lookup as follows:



This would work. But now lets assume you want to port this application to a different application server (maybe websphere). Its not guaranteed that the other application would also provide its mailing service at java:/Mail. It might provide that service at java:/SomeOtherName. This would mean that you will have to change your code to make it work. To avoid changing this code, J2EE allows applications to provide an indirection to the actual resources through the deployment descriptors. In this case you would have a resource-ref entry in the ejb-jar.xml and jboss.xml as follows:

ejb-jar.xml


jboss.xml


The above configuration is nothing more than an indirection to the resource of type javax.mail.Session bound at java:/Mail. The above configurations will bind the resource at java:/comp/env/mail/Mail jndi name. So you can lookup the resource as follows in your code:



So when you port the application to some other server you DONT have to change the code. You just have to change your deployment descriptor as follows:



I know, the answer is bit too lengthy. So take your time to understand it and let us know if you have any questions
[ March 18, 2007: Message edited by: Jaikiran Pai ]
Jaikiran Pai
Marshal

Joined: Jul 20, 2005
Posts: 10101
    
164

Your other question
Can I ask you when I should use SessionContext object instead the Context for the lookup?


The SessionContext object is available only in the Session beans. So if you are doing any lookups other than in the session beans, you will have to use the InitialContext object. Something like:



You can even use the InitialContext object in the session beans to do the lookup. You need not use the SessionContext object in the bean to do the lookup.
Alessandro Ilardo
Ranch Hand

Joined: Dec 23, 2005
Posts: 218
To avoid collisions with names of other enterprise resources in the JNDI
namespace it is recommended that the application should use the java:comp/env namespace which is specific to the application. Each application deployed in the application server's JVM will have its own java:/comp/env jndi namespace. This would mean that App1 deployed on the JBoss server can bind an object to "java:/comp/env/xyz" and another App2 deployed on the same JBoss server can bind a different object to the "java:/comp/env/xyz" without overwritting the object of App1. This is possible because each application will have its own java:/comp/env namespace. Now consider the same scenario in the case of java:/ namespace. As already mentioned above, the java:/ namespace is *shared* by all applications deployed on the application server. This would mean that the two applications App1 and App2 deployed on the server CANNOT bind their objects to the same jndi name java:/xyz.

I've just started with EJB and I've been quite confused by the tutorials out there having different configurations from each other. But that's perfectly clear. I finally made some order in my head about ejb modules and jndi.
Thank you very much for your time.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: MDB @PostConstruct error