• 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

To Bill

 
Ranch Hand
Posts: 8945
Firefox Browser Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Bill,
Chapter 6 has AntiPattern: Fragile Links.
Can you please throw more light on the above?
 
Author
Posts: 234
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 1561
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
 
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Ranch Hand
Posts: 285
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 -
 
Pradeep bhatt
Ranch Hand
Posts: 8945
Firefox Browser Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 8945
Firefox Browser Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Bill,
One more question
Chapter 4
AntiPattern: Too Much Code.
Are you talking about scriptlets? Doesn't JSTl solve the problem?
 
Lasse Koskela
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 234
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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!
 
Ranch Hand
Posts: 237
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Pradeep bhatt
Ranch Hand
Posts: 8945
Firefox Browser Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 8945
Firefox Browser Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Bill,
Do you think that some of your antipattern solutions are taken care of by EJB 2.1?
 
Bill Dudney
Author
Posts: 234
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 8945
Firefox Browser Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 234
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Pradeep,
I posted a long bit on this in the other thread (about Composite Entity).
 
Pradeep bhatt
Ranch Hand
Posts: 8945
Firefox Browser Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Bill! I missed it some how.
 
Pradeep bhatt
Ranch Hand
Posts: 8945
Firefox Browser Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ]
 
Ranch Hand
Posts: 1209
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 8945
Firefox Browser Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 234
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


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
Posts: 8945
Firefox Browser Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ]
 
He puts the "turd" in "saturday". Speaking of which, have you smelled this tiny ad?
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic