• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Only one object instance - ServletContextListener, JNDI

 
Ranch Hand
Posts: 623
1
IntelliJ IDE Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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!
 
Sheriff
Posts: 9708
43
Android Google Web Toolkit Hibernate IntelliJ IDE Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Nothing to do with SCWCD, I'll move it to Servlets forum...
 
Sheriff
Posts: 67749
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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: 623
1
IntelliJ IDE Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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...
 
Ranch Hand
Posts: 147
Eclipse IDE Tomcat Server Debian
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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).
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic