1

I'm a Java EE nooby developer, According to many resources on the internet which claim that service locator design pattern is an anti-pattern because it hides classes dependecies and more things and should be avoided as many as possbile and using Dependecy Injection instead, as we know JNDI is an implemantation of service locator pattern.

I googled to check that JNDI is an implementation of service locator and i found this response which claims this : Understanding JNDI

Althought i see that JNDI is used in Java EE application for many purposes (Datasources, EJB lookup ...), So should i use it or should i avoid it as more as possible?, if JNDI isn't bad then service locator isn't?

Community
  • 1
  • 1
La VloZ Merrill
  • 173
  • 1
  • 10
  • Not sure why the down votes, sure the question isn't 'right' but the 'question' itself isn't "bad" It is worth asking if they are confused. – mawalker Jan 01 '16 at 22:47
  • @mawalker It is worth asking if there is some universally agreed meaning of 'evil' in software (which there isn't, as using it in this context is a category mistake), and if there is some broadly agreed reason why the service locator pattern exhibits it, which I have never heard of. Otherwise the OP is just using words at random without explanation and asking whether he's right. – user207421 Jan 01 '16 at 22:50
  • @mawalker thank you for comment, me too i didn't understand why especially without a comment which clear it, i'm not here for points nor up vote :) – La VloZ Merrill Jan 02 '16 at 00:23
  • your wording is a bit hyperbolic, but the general question remains the same. (I don't know too much about JNDI to comment on the question itself) but edit out the 'evil' part of the question, and try to explain in more detail why you think it is an anti-pattern, etc. might be of use. – mawalker Jan 02 '16 at 00:28
  • @EJP thank you for answer, there is alots of resources in the internet claim that service locator design pattern is an anti-pattern because it hide classes dependencies and more, and about the term "evil" i've googled and found an answer who the user used the term evil : http://programmers.stackexchange.com/questions/138144/are-service-locators-really-that-bad, there many people in this world think like me :) – La VloZ Merrill Jan 02 '16 at 00:30
  • @mawalker okey thank you for your time :) – La VloZ Merrill Jan 02 '16 at 00:32
  • 1
    It wasn't an answer, it was a comment. Merely claiming there are many such resources without citing any of them is not sufficient here, and I don't see why SO should become a validation site for arbitrary Internet junk. – user207421 Jan 02 '16 at 02:24
  • @EJP thank you for your time. – La VloZ Merrill Apr 03 '16 at 08:05

3 Answers3

3

I think that the one part of your question, whether service locator is good or not or whether JNDI is about this pattern is a bit esoteric. I can give a general advice here as being a software architect for some years now, that a pattern by itself is not good and not bad, it is just a piece of solution that was successfully used before in many cases and thus be declared a pattern in order to be used for future cases which are similar. And another thing is, as opposed to many years ago, when one had to know the GoF book by heart in order to survive an interview, nowadays it is much more important to understand the underlying concepts of a framework like Java EE than to implement all those patterns, because what you have to implement is very often very simple and straightforward, but using them relies on those concepts.

Concerning the second part of your question, you are almost never in need of directly using JNDI, but to use concepts built on top of it, as injection - that is what you should use in your application.

cngzz1
  • 143
  • 2
  • 9
Alexander Rühl
  • 6,769
  • 9
  • 53
  • 96
  • of course, all the time we don't need to make lookup with JNDI, but i've found many sources says that service locator is an antipattern for many reasons, any way thank you for your time. – La VloZ Merrill Apr 03 '16 at 08:05
0

It's a horrible pattern IMHO since it is a massive security flaw. If dependencies are known at compile time and do not change, then its much easier to audit, gate and control possible vulenrabilities. Even within an organization JDNI is a Trojan horse waiting to be put to nefarious use, if a bad actor ca compromise some other area and your network, then get load whatever they want via a poorly/unwittingly implemented app. This log4j debacle is proof of that: don't allow apps to look-up and load whatever, whenever. It's a stupid idea. It's unsafe.

Mister Mister
  • 71
  • 3
0

In a business environment we end up needing different kinds of data across applications so that it makes sense to store them in a shared location. For instance you may have a set of applications that share the same set of users, and we need authorization information for each of them listing what roles they have so we can know what they need to access. That kind of thing goes into an LDAP data store, you can think of it as a hierarchical database optimized for fast read access.

All sorts of things can go in these datastores, it's normal for an application server to stash connection pools in them, for instance. A lot of these, like users, roles, and connection pools, are vital things you need to do your job.

JNDI is the standard Java API for accessing these LDAP datastores.

The nasty thing about the service locator design pattern is that the client code doing the lookup has to know too much about the thing it is querying (mainly, where to get it from), and having that lookup hard-coded in the client makes the code inflexible and hard to test. But if we use dependency injection (whether it's CDI, Spring, whatever) we can have the framework inject the value we want into the code, while the JNDI lookups are handled within the framework code and not in the application. That means you can use JNDI without your application code having to use the service locator pattern.

Nathan Hughes
  • 94,330
  • 19
  • 181
  • 276