Classloading and J2EE Packaging Article


News: Classloading and J2EE Packaging Article

  1. Classloading and J2EE Packaging Article (3 messages)

    Back by popular demand and intriguing questions, there is a follow up to my J2EE packaging issues article now posted on OReilly's site. This article discusses nuances with classloading and the different schemes that vendors can use to implement enterprise application classloading schemes. This article even points out an ambiguity in the specification relating to web application packaging.

    This article will be followed up with a classloading super example for J2EE packaging that you can use to test your platform to see how it behaves. That example will be posted here and at the BEA Developer Center in the future.

    You can read the article here:
  2. Hi Tyler!

    I'm completely confused by this article. It talks about Pre-EJB 2.0 PFD2 Option and Post-EJB 2.0 PFD2 Option, but I do not see any references to classloading architecture in the EJB 2.0 spec. Both J2EE 1.2 and 1.3 specs require support for bundled extensions (Class-Path in jar manifest), but they do not define classloading architecture as well.

    As far as I can tell, WebLogic 6.x implements 2-level classloading: EJB classloader common for all ejb's in the EAR and multiple WAR classloaders for each WAR in the EAR (parent is EJB classloader for this EAR). It will be interesting to know how other vendors implement this.
  3. i agree its getting a bit confusing. i know websphere 4 has an option of "Visibility", where in u can set the visibilty of ur class files. the options are - Application(EAR level), Module(EJB/WAR level), server and i think another one, cant recollect.

  4. That was the point of the whole article -- since the specification doesn't specify the rules for classloading, vendors can pick an architecture that works for them. Prior to EJB 2.0 PFD2, vendors could choose either of the options listed in the article. However, after the latest release of the EJB specification, the first option is no longer allowed because of local interfaces -- there is no other way around it. It's an implication that vendors have to deal with.

    As a result, EJBs and dependency libraries need to be loaded at the EAR level -- other vendors will have to support this in the near future. This is what WLS 6.1 does along with Persistence and the J2EE RI.