Win a copy of Functional Reactive Programming this week in the Other Languages forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Only one object instance - ServletContextListener, JNDI

 
Piotr Nowicki
Ranch Hand
Posts: 611
1
IntelliJ IDE Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Howdy Ranchers!

I would like to have only one instance of the business object in my application (let's call it service). I can:

Create its instance in Initializer class which extends ServletContextListener
This approach will allow me to create exactly once instance of my object for each context (which is basically what I need) and i.e. bind it as a ServletContext attribute for other Servlets

But then I read about business delegate pattern and wanted to use it. So, I have a BusinessDelegate class which should be the only class who has the access to the "service" object. But here is a problem. My Initializer class added the service object to a context attributes, and my BusinessDelegate is nothing even close to a Servlet. It's just plain Java class.
I am not even considering passing a servlet context object, as it is totally invalid in my opinion.

So I've got an idea of using the JNDI. I modified my code, so that the Initializer now binds the service object to the JNDI instead of ServletContext and the BusinessDelegate takes it from there.
So it's like:



Now I'm wondering.
Should it be made like that in the real world? I read the Tomcat JNDI resource documentation and they are talking about a factory for a bean. Well, I could do that:
- modify my Initializer from being an ServletContextListener to a standard JavaBean,
- in it's constructor do all the stuff related with the service initialization.

My question is - should I use this approach in my case (i.e. when I do not need any parameters set declaratively)?
Is my approach a "dirty one" and I always should use the resource factory mechanism and registering my JNDI resource in web.xml?
Is it a good practice and a rule of thumb?

Thanks in advance Ranchers!

Cheers!
 
Ankit Garg
Sheriff
Posts: 9528
33
Android Google Web Toolkit Hibernate IntelliJ IDE Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Nothing to do with SCWCD, I'll move it to Servlets forum...
 
Bear Bibeault
Author and ninkuma
Marshal
Pie
Posts: 65223
95
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Forgive me if I have this wrong, but you have a simple and straight-forward approach, but you want to create an over-complicated approach just to use a pattern?
 
Piotr Nowicki
Ranch Hand
Posts: 611
1
IntelliJ IDE Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
@Bear OK, I understand the confusion, as I might blurred the main question with all this pattern stuff... I insist on using Business Delegate pattern plainly for educational purposes. I just want to see how it works and what added value can it give me in the future, but this is not the main point.

The real question is - if I want to have only one instance of some object and I want to register it with the JNDI, should I always use the resource-approach and provide a Factory class:


or can I plainly add this object into the JNDI from within the ServletContextListener?
Is it a matter of style, like:
'always point your JNDI resources declaratively, so the future developers would understand your code more easily', or just:
'use what suits you'?

This question might feel somewhat stupid, but that's probably because it's the first time I use a JNDI...
 
Pete Nelson
Ranch Hand
Posts: 147
Debian Eclipse IDE Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
As far as I know, the best way to guarantee a singleton is to remove it's constructor, and use a static getInstance() method instead. Then regardless of if you use JNDI, a bean, or a plain-old POJO, you can be sure there's only a single instance in the running jvm.

The only trick is you must make sure anything that uses this class uses MySingleton.getInstance() instead of new MySingleton(). (You probably want to add synchronization & error handling to the singleton well).
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic