aspose file tools*
The moose likes EJB and other Java EE Technologies and the fly likes To Bill 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 "To Bill" Watch "To Bill" New topic
Author

To Bill

Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8919

Hi Bill,
Chapter 6 has AntiPattern: Fragile Links.
Can you please throw more light on the above?


Groovy
Bill Dudney
Author
Ranch Hand

Joined: Sep 05, 2003
Posts: 234
Hi Pradeep,
The problem that we (the authors that is) see alot is that people deploy with hard coded JNDI names in their code. These names then go 'stale' if the deployer changes them and the app fails to function properly. Instead of using JNDI names use EJB references in your code.
Hope this helps. If not just let me know I'd be glad to add more detail if needed.


TTFN,<br /> <br />-bd-<br /> <br /><a href="http://www.amazon.com/exec/obidos/ASIN/0471449156/qid=1064343733/sr=2-1/ref=sr_2_1/002-8375300-3666449" target="_blank" rel="nofollow">Jakarta Pitfalls</a> | <a href="http://www.amazon.com/exec/obidos/tg/detail/-/0471146153/qid=1064343733/sr=1-2/ref=sr_1_2/002-8375300-3666449?v=glance&s=books" target="_blank" rel="nofollow">J2EE AntiPatterns</a> | <a href="http://www.amazon.com/exec/obidos/tg/detail/-/0471462071/qid=1064343733/sr=1-3/ref=sr_1_3/002-8375300-3666449?v=glance&s=books" target="_blank" rel="nofollow">Mastering JavaServer Faces</a> | <a href="http://bill.dudney.net/roller/page/bill" target="_blank" rel="nofollow">Blog</a> | <a href="http://www.jroller.com/page/BillDudney" target="_blank" rel="nofollow">Eclipse Blog</a> | <a href="http://www.sourcebeat.com/TitleAction.do?id=2" target="_blank" rel="nofollow">Eclipse 3 Live</a>
Andres Gonzalez
Ranch Hand

Joined: Nov 27, 2001
Posts: 1561
Originally posted by Bill Dudney:
Hi Pradeep,
The problem that we (the authors that is) see alot is that people deploy with hard coded JNDI names in their code. These names then go 'stale' if the deployer changes them and the app fails to function properly. Instead of using JNDI names use EJB references in your code.
Hope this helps. If not just let me know I'd be glad to add more detail if needed.

hmm.. is that what they're doing in this article then?

..For example, to acquire an EJB Home object for the first time, Service Locator first creates a JNDI initial context object and performs a lookup on the EJB Home object...

correct me if I'm wrong


I'm not going to be a Rock Star. I'm going to be a LEGEND! --Freddie Mercury
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Originally posted by Andres Gonzalez:
correct me if I'm wrong
<enter mode="nitpicking"/>
Without looking at the full source code, it doesn't say anywhere that "myEJBJNDI" would be the real JNDI name.


Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Faisal Khan
Ranch Hand

Joined: Jun 29, 2003
Posts: 285
Bill,
Is this antipattern specific to EJB. As is the case that from my Servlets/JSP app I access the DB defined in JNDI Datasource and then refer to the actual name defined in my server.xml inside the code.
Please shed more light on this.
- FK -


The secret to creativity is knowing how to hide your sources.
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8919

These names then go 'stale' if the deployer changes them and the app fails to function properly.

Wasn't that the main purpose of JNDI , location transparency?
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8919

Bill,
One more question
Chapter 4
AntiPattern: Too Much Code.
Are you talking about scriptlets? Doesn't JSTl solve the problem?
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Originally posted by Pradeep Bhat:
Are you talking about scriptlets? Doesn't JSTl solve the problem?
I don't know whether Bill refers to scriptlets or not, but the "too much code" anti-pattern can be seen also in a JSP which uses taglibs. The problem isn't really "too much Java code" but "too much any code".
Bill Dudney
Author
Ranch Hand

Joined: Sep 05, 2003
Posts: 234
Hi All,
I'll try to address all the questions at once...
1) On the JNDI article it does not specify if the name used to look up is a reference or the real JNDI name so I prefer to give Paulo the benifit of the doubt. But keep in mind that he is not really addressing the deployment of components except for the likelyhood of stale references. So he could have intentionally left out the reference discussion to focus on his point. A great article BTW...
2) This AntiPattern is not specific to EJB's, but that is where we have seen it most often.
3) One of the purposes of JNDI is location transparency, another is to have a standard api oveer naming services (which also have as a major goal location transparency). However during deployment a performance guru might want to move some components to different JNDI names for some performance trick. If you have the JNDI name hardcoded in your app then you will be broken on that move.
4) JSTL does solve some of the 'to much code' problems, however as was noted later in the thread the problem is more than just scriptlets. If you are doing business logic with JSTL tags then you are still violating the MCV paradigm and will thus be stuck with harder to maintian code. See also 'Ad Lib TagLibs' on pg 193 for more info.
Thanks for the great discussion!
Juan Rolando Prieur-Reza
Ranch Hand

Joined: Jun 20, 2003
Posts: 236
It seems to me that the Service Locator would be the curative pattern that you would use when refactoring a brittle links anti-pattern. I appreciate the informative material that helps us to find this anti-pattern in existing systems.


Juan Rolando Prieur-Reza, M.S., LSSBB, SCEA, SCBCD, SCWCD, SCJP/1.6, IBM OOAD, SCSA
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8919

Bill,
Do you consider EJB as an antipattern ? If yes have you mentioned this in your book?
John,
curative pattern ? what is that?
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8919

Bill,
Do you think that some of your antipattern solutions are taken care of by EJB 2.1?
Bill Dudney
Author
Ranch Hand

Joined: Sep 05, 2003
Posts: 234
Hi Pradeep,
No I don't think Entities are an anti-patter per-se. But they can be used incorrectly (like everything). My biggest beef with them is that we did not learn the historical lessons from CORBA. I've already gotten on and off my soap box here on this list about this topic so I won't prattle on, but... People were doing distributed entity computing with CORBA and it flopped badly, why did we have to relarn that lesson with EJB's. Ok now I'm off my soap box.
I agree with John that the Service Locator would be a great pattern to refactor to. However you still need to get the hard-coded JNDI names out of your Service Locator or it will have to be recompiled with each change to the JNDI name space.
Thanks again for the great discussion!
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8919

Bill,
About your section AntiPattern: Accessing Entities Directly. in the book.
Is it worth writing a session bean which is just a proxy for entity bean? Is n't better to access the entity directly when there is interaction with just a single entity.
Bill Dudney
Author
Ranch Hand

Joined: Sep 05, 2003
Posts: 234
Hi Pradeep,
I posted a long bit on this in the other thread (about Composite Entity).
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8919

Thanks Bill! I missed it some how.
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8919

Bill,
AntiPattern: DTO Explosion.
When does this happen. Usually there will be one or twoDTO for an entity, right?
[ November 21, 2003: Message edited by: Pradeep Bhat ]
Karthik Guru
Ranch Hand

Joined: Mar 06, 2001
Posts: 1209
Originally posted by Pradeep Bhat:
Bill,
AntiPattern: DTO Explosion.
When does this happen. Usually there will be one or twoDTO for an entity, right?
[ November 21, 2003: Message edited by: Pradeep Bhat ]

Ok i dont understand these terms ! I assume that there will be one value object that maps to entity bean. But my screens might need to display data related to multiple entities. Now the object that contains all such value objects is called a DTO?
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8919

Now the object that contains all such value objects is called a DTO?

Yes, in case you have a different object (DTO)for each screen.
Bill Dudney
Author
Ranch Hand

Joined: Sep 05, 2003
Posts: 234

Yes, in case you have a different object (DTO)for each screen.

Hi Pradeep,
This is exactly the case we are calling an antipattern. If you have mulitple 'screens' that are served by one entity and you add multiple DTO get methods to that entity you are facing the risk of major maintenance headaches (unless you are using XDoclet of course). A better way to do this is to have a single dto method on the entity (I actually prefer to have none actually) and then have a factory for DTO's in your session facade layer. The factory can then take the LocalEntity as an argument and produce any number or type of DTO that are needed by your clients. This has the added advantage of keeping your entity insulated from the use cases that it is used to implement.
Hope this helps.
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8919

That is a great answer. I am sure your book will have a lot more
(I actually prefer to have none actually)

Yes, it is better to have no DTO method so that uncessary data is not fetched from the entity.
I am also waiting for your JSF book.
[ November 21, 2003: Message edited by: Pradeep Bhat ]
 
jQuery in Action, 2nd edition
 
subject: To Bill