TSS Presents The J2EE Project Survival Guide, Book-In-Review

Discussions

News: TSS Presents The J2EE Project Survival Guide, Book-In-Review

  1. TheServerSide is pleased to announce the public book review of 'J2EE Project Survival Guide'. The guide gives you an in-depth view of strategies for successful J2EE projects, illustrating architectural and design concepts to address various issues. Chapters on Practical J2EE, Classloading, and Deployment are available for download.

    Download and Review:

    J2EE in Practice
    Classloaders and J2EE
    Deployment Considerations

    Threaded Messages (47)

  2. Excellent Content[ Go to top ]

    Hi,

    I would like to know when this book will be completed fully and available in market. I consider this book is really the bible for developing J2EE apps.

    Regards
    Ramagopal
  3. Excellent Content[ Go to top ]

    I consider this book is really the bible for developing J2EE apps.

    you are saying this by looking at the content table and one-two sample chapters. hmm...

    -talip
  4. Titles and Contents !!![ Go to top ]

    I saw the sample chapters presented here... it clearly addresses the underlying issues that we face in the J2EE app development. The content explains the concept rather than examples...

    Regards
    Ramagopal
  5. Titles and Contents !!![ Go to top ]


    > I saw the sample chapters presented here... it clearly addresses the underlying issues that we face in the J2EE app development. The content explains the concept rather than examples...
    >
    > Regards
    > Ramagopal



    Hi Ramagopal,

    I am glad that you liked the chapter.

    The book is tentatively scheduled to be published in August 2004. I foresee it to be of 600+ pages of quality content priced at $39.95

    We have a great Java and J2EE community around here. This book has content that is very relevant to J2EE developer community. I hope I can take advatnage of your collective experience to improve the book and hopefully you might benefit from my book too. In view of this I am looking forward for your feedback:

    1) Is there any area you think that is not covered?
    2) Is the content and presentation good?
    3) Do you have suggestions that can help me make the book better?
    4) Is the content technically incorrect?

    Please let me know.

    Regards,
    Srikanth Shenoy
  6. Suggested Improvements[ Go to top ]

    1) Is there any area you think that is not covered?

    >2) Is the content and presentation good?
    >3) Do you have suggestions that can help me make the book better?
    >4) Is the content technically incorrect?


    I feel that following points need to be covered to make the book complete...

    1. J2EE Cluster Management - Do's And dont's
    2. Clustering techniques
    3. Workload management
    4. J2EE application considerations for clustered environments
    5. Application configuration management across different environments (Development/Integration/QA/production)
    6.Object oriented modelling
    7. Guidelines for Session management


    Regards
    Ramagopal
  7. Suggested Improvements[ Go to top ]

    > I feel that following points need to be covered to make the book complete...
    >
    > 1. J2EE Cluster Management - Do's And dont's
    > 2. Clustering techniques
    > 3. Workload management
    > 4. J2EE application considerations for clustered environments
    > 5. Application configuration management across different environments (Development/Integration/QA/production)
    > 6.Object oriented modelling
    > 7. Guidelines for Session management
    >
    >
    > Regards
    > Ramagopal


    Very good points Ramagopal. Can you also please email your comments to
    book-comments at objectsource dot com, so that the publishers can contact you to mail the free copy of the book, if selected as one of the Top 10 reviewers for the book.

    Regards,
    Srikanth Shenoy
  8. chapter 21 & classloaders[ Go to top ]

    hi;
    i have read the remarks regarding this chapter.
    i have a couple of things on my mind.
    1. you cant state as a rule that the WAR/EJB hirarchy is a child or sibling one. i have seen an AS implementations where they are siblings and other AS (more common) where the WAR is the child of the EJB. we should remember that in order to be portable a solution must be found that would satisfy both instances.
    2. In J2EE 1.3, you cant really use the manifest of a WAR to 'point' to a utility jar in the EAR level. the spec was to vague about which deployment units can use the manifest file like this and the result is that you can only count on using it with EJBs not with WAR (of course, it will work on some AS but not portable!).
  9. chapter 21 & classloaders[ Go to top ]

    2. In J2EE 1.3, you cant really use the manifest of a WAR to 'point' to a utility jar in the EAR level. the spec was to vague about which deployment units can use the manifest file like this and the result is that you can only count on using it with EJBs not with WAR (of course, it will work on some AS but not portable!).


    Actually, it's not vague at all. Check out 9.8 of the Servlet 2.3 spec.

    However, it's only recommended, not mandated.
  10. chapter 21 & classloaders[ Go to top ]

    Guy:

    Your point (1) is so true! I really do not understand how can we talk of class loaders without talking about application server specifics. This is my favorite topic and anytime I talk about this - I just cant talk without an app server in context. I found the chapter a bit weird because of that (sorry for being frank !). For example, Websphere has a setting called "PARENT_FIRST"/"PARENT_LAST" and that reverses the entire story to fiction :-).

    Thanks for pointing out! I was wondering the same.

    -Sanjay
  11. chapter 21 & classloaders[ Go to top ]

    > Guy:
    >
    > Your point (1) is so true! I really do not understand how can we talk of class loaders without talking about application server specifics. This is my favorite topic and anytime I talk about this - I just cant talk without an app server in context. I found the chapter a bit weird because of that (sorry for being frank !). For example, Websphere has a setting called "PARENT_FIRST"/"PARENT_LAST" and that reverses the entire story to fiction :-).
    >
    > Thanks for pointing out! I was wondering the same.
    >
    > -Sanjay


    Sanjay,

    I philosophically (and practically) disagree with your suggestion that talk about class loaders should always be coupled to application server. This is equivalent to saying "design your application based on the application server and not on J2EE" and the portability of J2EE is all lost.

    Hence, there is need for some general principles and understanding about the classloaders while designing the J2EE application without getting into the application server specifics. That is what the chapter does.

    BTW, PARENT_LAST is not the default in WebSphere. PARENT_FIRST is the default (which means the child delegates to its parent to load the class) and is generally used unless you have compelling reason not to. PRENT_LAST usage is a exception, not a rule.
    While it is true that every Application Server has its value added features (Like PARENT_LAST feature in WebSphere), designing your J2EE application based on the value added feature is philosphically against the J2EE standard (in my opinion).

    Now on to the practical side of it: Let me consider the two application Servers - WebLogic and WebSphere. (I am not 100% sure about JBoss classloader hierarchy. I would have loved to include it in my discussion below. Perhaps somebody can enlighten me about JBoss class loading.)

    WebLogic's class loading mechanism matches 100% to the discussion in the chapter and is also the most restrictive of the two. WebSphere's (Version 5)class loading mechanism is almost similar to that discussed in the chapter except that EJB class loader and EAR class loader are exactly the same. In other words WebSphere is more lenient in that it lets you to refer the EJBs from the dependency classes.

    In WebSphere 4, Web app class loader and EJB class loader were siblings. Not so in WebSphere 5. With WebSphere 5, the Web app class loader is the child of Application class loader (the one that loads EJB and dependency).

    In general, I think the trend in the industry is to move away from sibling to parent-child relationship among EJB and web class loaders becuase that's the usage pattern. Web applications need to invoke EJBs.

    Hope I have addressed your concerns.

    Cheers,
    Srikanth Shenoy
  12. chapter 21 & classloaders[ Go to top ]

    Dear Srikanth:

    I guess I mis-understood your book title. I thought a title that says "J2EE Project Survival Guide" has to address Application Server specifics as they are the practical issues one will face. "Generic J2EE stuff" is handled well in so many other books and so I thought this will be a difference that you want to bring in. Sorry if I was wrong about interpreting your title.

    -Sanjay
  13. chapter 21 & classloaders[ Go to top ]

    > Dear Srikanth:
    >
    > I guess I mis-understood your book title. I thought a title that says "J2EE Project Survival Guide" has to address Application Server specifics as they are the practical issues one will face. "Generic J2EE stuff" is handled well in so many other books and so I thought this will be a difference that you want to bring in. Sorry if I was wrong about interpreting your title.
    >
    > -Sanjay


    Hi Sanjay,

    Those where my thoughts before I started this book - To deal with the intricacies of different application servers. However I quickly realized that the vendor manuals do a better job at explaining the intricacies than I would. After all, they developed the product...

    Moreover each application server has so many intricacies that might need its own book - WebLogic Survival Guide, WebSphere Survival Guide and so on.

    "Generic J2EE stuff" is handled well in so many other books - Agreed.
    But new ideas in regards to Generic J2EE are so much that this and many other books can still make a difference. My 2 cents.

    Cheers,
    Srikanth Shenoy
  14. "J2EE in Practice" chapter[ Go to top ]

    I would like to see more in the "Development-time considerations" portion of the book about technology/framework choices and alternatives. For example, how would using JMS (and it's implementations like MQ) affect the stability/performace/deployment of the application? What if the application is Web Service driven? When do chooce web service?

    I would like the issues related to Web Services and web security to be addressed in the "Deployment" portion of the book as well. I am not sayin that it should contain detailed information on firewalls, authentication, hackers, etc. But the issue of internet security and firewalls are critical for any J2EE project that is exposed to external clients (and often internal clients as well). And the popularity of Web Services add additional dimension to these issues.
  15. A word about PARENT_LAST setting and Websphere.

    Some thing as simple as using latest XML parsers by dropping them in the EAR class path (manifest) or WAR classpath ( web-inf/lib) breaks the functioning of EJBS or JSPs. In one case the JSP compilers are comfortable only with Websphere bundled parsers. It seems that JSP compiler running when the app runs - dynamically- calls the WAR class loader to resolve classes in that path. If WAR class loader loads an XML parser that we supply in WEB-INF/lib JSP compiler errors out unable to read tld files. This happened in WAS V4 , but does not happen currently in WAS V5, but it will sure happen as parsers evolve to be incompatible with the bundled ones.

    With EJBs the problem shows up even in WAS V5. The JDBC resource adapter fails unable to read ejb-jar.xml - with the PARENT_LAST setting.
  16. Shankaran,

    You are right.
    The app servers themselves come with a pre defined version of XML Parser.
    When using JAXP to get the parser, the XML Parser defined in the app server is picked up. The XML parser bundled with the EAR is totally ignored.
    In other words, the application server is forcing you to use a fixed version of XML Parser.

    Personally, I would like to see both WebLogic and WebSphere change this aspect of class loading and instead adopt Tomcat's model. With Tomcat, the Catalina Class loader is not a parent to any of the application class loaders. All application class loaders ultimately inherit from the Common Class loader - which is also the parent of Catalina. With this model Catalina is free to have its own XML parser and your web app can have its own (as long as the XML Parser is not copied into the Common folder in Tomcat - which corresponds to COmmon Class loader)

    http://jakarta.apache.org/tomcat/tomcat-5.0-doc/class-loader-howto.html

    Cheers,
    Srikanth
  17. chapter 21 & classloaders[ Go to top ]


    > Hi Sanjay,
    >
    > Those where my thoughts before I started this book - To deal with the intricacies of different application servers. However I quickly realized that the vendor manuals do a better job at explaining the intricacies than I would. After all, they developed the product...
    >
    > Moreover each application server has so many intricacies that might need its own book - WebLogic Survival Guide, WebSphere Survival Guide and so on.
    >
    > "Generic J2EE stuff" is handled well in so many other books - Agreed.
    > But new ideas in regards to Generic J2EE are so much that this and many other books can still make a difference. My 2 cents.
    >

    May be makes sense - but I still differ (it is OK to differ, I guess :-), because let us consider the life of a normal J2EE developer - "A Day In the Life of a J2EE Developer" :-). He has so many application servers to worry and so many bulky manuals to handle. The name of the game is "Reduce time to market". He has to make it work on 4 app servers before 6PM evening :-). Do you think these bulky manuals will help or a cute book like what your book's title says. I still personally believe that is J2EE project survival game. It is well OK for you to differ and proceed. NO issues - but I dont get sleep if I dont express my opinion :-).

    BTW, overall a nice job on the book - I finished reading the samples. Apart from above one distress, following is what I would like to see in such a title.

    (1) Garbage collection techniques is left out totally. Tools like HPJTune, JProbe et al which allow tracing GC issues is core to any sensitive J2EE app. Also I have seen many abuse the -X settings just by hearing that "JDK 1.4 has parallel GC and concurrent GC and adaptive GC policies". How to avoid the abuse?

    (2) I dont know what is in Security - part1, part2, part3, but covering single sign on frameworks would be great as that is what enterprises always want.

    3. Nothing on wireless , J2ME areas

    4. Core Operating System considerations for performance tuning. Ultimately any J2EE is a process. For example, J2EE app servers are thread oriented than process oriented. So kernel settings like large "nproc" just dont make sense for appserver boxes. So on and so forth...

    5. Would love see "disasters with EJBs" - which is something I have witnessed time and again in my J2EE world from 1997 !

    Thanks and good job!!
    Sanjaya Ganesh H

    PS: You would also be interested in Gartner Report ID SPA-21-6950 (Strategic Enterprise Software Planning for 2008 - J2EE vs .NET) - where vendor lockins is going to be the name of the game. But then, some - like me - dont believe in what Gartner says :-)).
  18. Can this be included?[ Go to top ]

    We can add real-life challanges involved in following different areas:
    1.Transaction and J2EE
    2.Support for Multiple devices/clients.
      How a particular PresentationTier Framework addresses this.

    3.Communication
    4.Internationalization and localization

    Slightly elaborating few things ,which i am sure book is/must be covering that one can not figure out from TOC only.

    Architectural Issues:

    .Layers:
      Deciding 'n' architectural layers.[client+business+data]
      For each layer what is the right technology/framework.
      [Deciding whether one needs EJB?]
      Flexibility of swapping in/out a particular layer without
      significantly affecting Upper/Below Layers.
      

    .Supporting different clients.
       Java Application
       Web Browser
       J2ME
       Symbian
       PalmOS
       WinCE
       ..
          
    . System<-->System Communication and Interoperability
    Local vs. Distrbuted
    Interoperable vs. Java Specific
    alternatives:
    1. http
    2. RMI-IIOP
    3. JMS
    4. SOAP[over http]
    .Security
    Authentication Framework and JAAS
    Authorization Framework and JAAS

    Communication Security alternatives:
    1. PKI
    2. SSL
    3. RMI-IIOPoverSSL
    3. Asymmetric-Key
    4. Custom Application
    Data Security
    1. Asymmetric-Key
                    2. other

    .Persistance Management
    CMP or JDO or Hibernate
       
       
    .Transaction is ACIDic.Handle with care!

    Testing of Transactional Behaviour of application with different
    combination of AppServer+Database.
    Transaction and Performance Testing
    Transaction and Deadlock Testing

    .Internationalization and loacalization:
    Not just presentation framework but almost all tier may need to consider
    Internationalization

    Performance
    H/W
    ..
    S/W
    Application
    Application Server
    Database
    ..

    J2EE Application Portablity : Testing with different combination of AppServer+Database
  19. Mistake in Chapter 21??[ Go to top ]

    Hi Srikanth,
    I've only read this one chapter on Classloading and its great. It really gives a goood, clear description. So thanks for that.

    However I do think there may be a little mistake or maybe I'm just confused.Here is the paragraph form section 21.3:

    WAR classloaders are the siblings of EJB classloader. The key difference
    between these classloaders is that while all EJB modules whether in the single or different EJB-JARs, share the same EJB classloader, each WAR gets its own
    classloader. All of the WAR classloaders however inherit from the same parent viz.EJB classloader. The rationale behind ....

    In the first sentence, I think the author meant to say "WAR classloaders are the child classloaders of the EJB classloader" instead of "siblings". It is a contradiction to say the they are siblings but then continue to say "WAR classloaders however inherit from the same parent EJB classloader". It is clear from the diagram that the WAR clasloaders are children of the EJB classloaders and not siblings - siblings suggets a brother/sister relationship i.e. that the nodes are on the same level in the node diagram.

    Maybe I am wrong about this, but it I would really apprecicate it if you could let me now if this was really a mistake or not.

    Thanks for a great chapter. I will look forward to reading the other chapters when time permits. It is authored and explained very well.
  20. Mistake in Chapter 21??[ Go to top ]

    Hi Martin,

    You are right. I really meant to say WAR classloaders are the child classloaders of the EJB classloader

    Thanks for pointing that out.

    Srikanth
  21. We're not alone[ Go to top ]


    > 1) Is there any area you think that is not covered?
    > 2) Is the content and presentation good?
    > 3) Do you have suggestions that can help me make the book better?
    > 4) Is the content technically incorrect?
    >

    Hi,

    I just reviewed the first chapter and the TOC and it sounds quite promising.

    The thing I'm missing are the integration issues.
    1) Backend integration
    1.1) Relational Database (Entity Beans with CMP or BMP, JDO, O/R Mapping Tools)
    I can't how much this is discussed in part IV.
    1.2) Other Backends: Mainframe (CTG, Messaging, ...), Peoplesoft, SAP (with JCA for example), CORBA based systems ...
    2) Providing Services for other Frontends or systems
    2.1) WebServices (e.g. to .NET clients)
    2.2) B2B communication
    3) Integration issues and strategies with other J2EE projects.
    3.1) outside of your organization
    3.2) within your organization
    3.3) within the same appserver but maybe on a different (logical) node
  22. Suggested Topics[ Go to top ]

    I am listing some topics that I found to be very useful for J2EE architects/designers/developers. I haven't seen any one book covering these topics in detail (especially from a practical stand-point).

    Best Practices, Dos and Don'ts in the following areas:

    1. Deploy a typical J2EE application to different environments (usually these environments have different operating systems (Windows vs UNIX/Linux), server configurations (configuration files using directory paths (\ in windows vs / in UNIX-based OS's), security policies (including http vs https, encrypted passwords etc), and logging preferences (such displaying all debug messages in Devl environment but limiting log messages to Errors in production environment).

    2. What's involved in automating pretty much all phases of a J2EE software development project especially the development, unit/functional/load testing (response times), application profiling (memory leaks) areas. Instrumentation methodologies to collection the data when running load (stress) testing on the web application. Recommended response times for different types of objects in the web application (such as HTML pages, JSP scripts, JavaBeans, EJB objects etc).

    3. Session Management issues especially when we need to store the data in both web and EJB tiers (what kind of data should be stored in HTTP Session versus data stored in the application server without duplicating the effort).

    4. Role of XP tools such as Ant, XDoclet, Code Generation techniques in a J2EE application development.

    5. Design and implementation considerations in deploying a web application in a cluster environment.

    6. Importance of integrating the frameworks such as Caching, Logging into J2EE application at design time rather than wait until Testing phase.

    7. System Monitoring/Application Monitoring design considerations.

    8. J2EE application maintenance issues.
  23. Suggested Topics[ Go to top ]

    Hi Srini,

    Good points. I already have some of them in my list.
    The rest, I am adding to my list.

    One of the points I find tough to cover is 1.
    The scope of 1 is so large that I am afraid it is tough to make justice in a single book.

    -Srikanth Shenoy
  24. Suggested Topics[ Go to top ]

    You are right. It's a vast topic. But it would be helpful for application developers and especially builders/deployers to know what are the things that need to avoided when automating the builds. So, it will be worth the effort if you can briefly explain some of the "anti-patterns" and more importantly the best practices in application build/deployment topic.
  25. Suggested Topics[ Go to top ]

    Hi Srini,

    You just read my mind. That is the plan for the Ant and Advanced Maven chapters

    Thanks,
    Srikanth Shenoy
  26. Is the book released yet?[ Go to top ]

    Hi Srikanth,

    First of all, excellent book, read all three chapters. You have mentioned that the book would be released by Aug 2004, I am trying to get hold of it (India/Bangalore), unable to. Could you please let me know if it is released yet and if so, who is the publisher? (so that I can get a copy in my local store)

    Thanks
  27. Has the book been released? If so who are the publishers.
  28. Reference http://www.objectsource.com/j2eechapters.html

    Unfortunately, the book could not be published due to the busy schedules of the authors.

    but you can get some of the completed chapters from the below link:
    http://www.objectsource.com/j2eechapters.html

    Thanks,
    Raj
  29. Hi,

    >
    > I would like to know when this book will be completed fully and available in market. I consider this book is really the bible for developing J2EE apps.
    >
    > Regards
    > Ramagopal

    Will all the chapters available for the review ? And when are you planning for the release of the book?

    Regards
    Vicky
  30. > Will all the chapters available for the review ? And when are you planning for the release of the book?
    >
    > Regards
    > Vicky


    The plan is to provide all chapters for review if I get useful review and feedback from the community. So, it is basically in your hands ;-D.

    The book will be released in August.

    Regards,
    Srikanth Shenoy
  31. How about Cache in J2EE?[ Go to top ]

    Custermers always conplian the performance. How could we balance the performance and using cache to reduce the time to access database? any practice way to do it? can you discuss those in book? Thank you.
  32. 90% of "j2ee in practice" chapter content is about performance only. I see no any real advices to performance gurus about topics such as characteristics of successful j2ee projects, effective planning, requirements management, and other more significant aspects that not included in this chapter.
    After reading this chapter my opinion is that 90% of successful j2ee project is performance issue only 8)
  33. > 90% of "j2ee in practice" chapter content is about performance only. I see no any real advices to performance gurus about topics such as characteristics of successful j2ee projects, effective planning, requirements management, and other more significant aspects that not included in this chapter.


    May be I could have placed too much stress on Performance in Chapter 1. I will work on it.

    Regarding the lack of real advices in Chapter 1, well, remember that Chapter 1 is only introduction or a high level overview. It sets the tone for the rest of the book, rather than providing solutions. Chapter 28 is completely dedicated to Performance related issues and will provide some good stuff.

    Also I did not quite get what you meant by this:

    After reading this chapter my opinion is that 90% of successful j2ee project is performance issue only 8)

    Cheers,
    Srikanth Shenoy
  34. Great effort![ Go to top ]

    Srikanth,
             This book of yours is definitely a grear effort towards covering most of the issues that a J2EE project team faces during the project life cycle. I'm eagerly awaiting the release of this guide. I have a question for you. In the section "Performance and Architecture Planning" , would you be including examples that quantify how a particular design pattern would induce or reduce performance issues? In other words would you be providing code samples that actually meet certain SLA requirements?

    Thanks & Best regards,
    Suraj
  35. Some problems with ClassLoader![ Go to top ]

    21.2 three principles of classloader operation
    Delegation Principle
    First Scenario:
    I have some misunderstandings in this scenario, The following is my understanding:
        The System ClassPath classloader delegate the load of class MyApp to Extensions ClassLoader.
        The Extensions ClassLoader delegate the load of class java.util.Vector
    to Bootstrap ClassLoader.
        If it is meaning of the book, Why not Extensions ClassLoader delegate the load of class MyApp to Bootstrap ClassLoader?
        I want to know in this situation which ClassLoader loads class MyApp and which loads class java.util.Vector.
        What make a ClassLoader load a specific class?
        Thank you all
  36. Some problems with ClassLoader![ Go to top ]

    21.2 three principles of classloader operation

    > Delegation Principle
    > First Scenario:
    > I have some misunderstandings in this scenario, The following is my understanding:
    >     The System ClassPath classloader delegate the load of class MyApp to Extensions ClassLoader.
    >     The Extensions ClassLoader delegate the load of class java.util.Vector
    > to Bootstrap ClassLoader.
    >     If it is meaning of the book, Why not Extensions ClassLoader delegate the load of class MyApp to Bootstrap ClassLoader?
    >     I want to know in this situation which ClassLoader loads class MyApp and which loads class java.util.Vector.
    >     What make a ClassLoader load a specific class?
    >     Thank you all

    Hi Amose:

    Each class loader is associated with a "Class Path". Typically there are various "stages" in class loading process - which the book does not seem to address at all. Each class loader can be visualized as having a CACHE of loaded classes, which it checks first - if found it is considered, else it delegates to the parent and so on and so forth. If all of them fail to load the current class loader tries to load.

    In your example, MyApp is loaded by System Class loader BECAUSE ITS PARENTS FAIL TO FIND IT IN CLASS PATH. Typically following are the class paths associated with each loader.

    bootstrap - The JDK Home lib directory
    Extensions = JDK "ext" library area.
    System = Your CLASSPATH variable.

    So in your example, MyApp is loaded by SYSTEM loader (why - you know why by now, I hope). VECTOR is loaded by Bootstrap (why? You know by now :-)

    JDK 1.4 has one more concept called endorsed libraries - anyways, the book does not seem to address that as well.

    Hope I am clear !

    -Sanjaya Ganesh H
  37. Some problems with ClassLoader![ Go to top ]

    Amose;

    To clarify on my previous post, the "technical jargon" for that path associated with each loader is what is known as "Code Source"


    =Sanjay
  38. Some problems with ClassLoader![ Go to top ]

    Tnank you,Sanjaya!
    But I'm not sure if I have got your meaning.
    The following is my understanding:
    1. Each classloader has its own CACHE(Code Source)
        classloader code source
        bootstrap The JDK Home lib directory
        Extensions JDK "ext" library area.
        System Your CLASSPATH variable.

    2. One classloader loads a class only if the class
       in its CACHE but not in any of its ancestors CACHE
  39. Some problems with ClassLoader![ Go to top ]

    Tnank you,Sanjaya!

    > But I'm not sure if I have got your meaning.
    Almost - but slightly missed...As below...

    > The following is my understanding:
    > 1. Each classloader has its own CACHE(Code Source)
    >     classloader code source
    >     bootstrap The JDK Home lib directory
    >     Extensions JDK "ext" library area.
    >     System Your CLASSPATH variable.
    >
    CACHE is NOT Code Source. Cache is an internal "stuff" of already loaded classes. Code Source is something outside from where a class loader can load if something is not in cache.
    > 2. One classloader loads a class only if the class
    >    in its CACHE but not in any of its ancestors CACHE
    NO. 4 conditions...One Class Loader will load a class, if it is not in ITS cache, its ancestors do not have in THEIR cache, its ancestors do not have it in THEIR code source and is available in its own (SELF) code source !! Clear? or confused :-)

    -Sanjay
  40. Some problems with ClassLoader![ Go to top ]

    My recent understanding:
    1. a ClassLoader load a class only if this class is not in its cache, nor in its ancestors' cache, nor in its ancestors' code source, but in its code source.
    2. the action is: a ClassLoader loads a class
       befor this action: this class in the ClassLoader's code source.
       after this action: this class in the ClassLoader's cache.
  41. Some problems with ClassLoader![ Go to top ]

    Perfect, Amose. You are there!
  42. code on page 10:

    public static Integer getDiscount(){
    Integer disc = cache.get("discount");
    //Incorrect
    if(obj == null){
    //Correct
    if(disc == null){
  43. ClassLoader Chapter[ Go to top ]

    I have gone through the class loader chapter. I would appreciate if the example you had take is not bookish. It would be great if you had taken the example which uses JSP vs EJB. e.g if an EJB uses a support class A in EJB's public interface, on deployement this class is exported. Now while packaging JSP, an identical dependent class is also included, then the servlet classloader also loads an identical class. Now if the JSP page tries to load an EJB to obtain a new object of class A we get a classcast exception. And if you can explain how we avoid such practical issues i.e by application partition which you had already explained, ( in this context ) it would be great.

    It would also be great if you have a Best Practice section for each chapter.

    Also if you can list out soem existing patterns which are available for the relevent chapter it would be an interesting read.

    Regards

    Rajeev Jayaram
  44. Possible Error?[ Go to top ]

    In the last paragraph on page 7 of chap 21, Person class is mentioned but not shown up in fig 21.3 hierarchy at all. Is it an error? I cannot figure out the relation between X, B, and Person at all.

    Thanks!

    Chao Tang
  45. Impressive First chapter.[ Go to top ]

    I read the first chapter of "'J2EE Project Survival Guide". I was impressed by the variety of issues which the authors have brought to light as typical of a J2EE project development and deployment lifecycle. It holds a lot of promise.
    It is clear from the narration style that the authors are writing exactly what they have gone through in real life J2EE Projects. The successful steps to a good J2EE implementation mentioned near the end of the chapter is very good and in my opinion should be followed from the inception of a new project. I am quite eager to study the remaining 2 chapters that are available for review.
  46. Chapter 21[ Go to top ]

    Hi,

    my posting may come a bit late in the process but my question, as a newbies in classloading pbs, may still be interesting to the author.

    After a thorough read of the chapter, I'm still missing some point:
    About the Figure 21.4 'Sample EAR Structure', I don't understand why dependency libraries have to be referenced in the manifest file of EAR and WAR since they are loaded in a parent ClassLoader to which they both have access?
    Same for the WAR, why would he have to reference the ejb-jar in its manifest file since ejb-jar are in its parent ClassLoader?

    More generally, the visibility principle as I understand it, makes referencing a library in a MANIFEST.MF only usefull when you would like to access classes in a child classloader (which is anyway a bad practice).

    So maybe some clarification on this point might be usefull in this chapter...

    regards,
    Jean
  47. When will this book be published?
  48. Coverage on SOA architecure along with other J2EE architures and web services would add value to the book. I am not sure whether this has been thought of to be added or already added.