From kato-spec-return-48-apmail-incubator-kato-spec-archive=incubator.apache.org@incubator.apache.org Tue Mar 03 16:51:48 2009 Return-Path: Delivered-To: apmail-incubator-kato-spec-archive@minotaur.apache.org Received: (qmail 9295 invoked from network); 3 Mar 2009 16:51:48 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 3 Mar 2009 16:51:48 -0000 Received: (qmail 20040 invoked by uid 500); 3 Mar 2009 16:51:48 -0000 Delivered-To: apmail-incubator-kato-spec-archive@incubator.apache.org Received: (qmail 20027 invoked by uid 500); 3 Mar 2009 16:51:48 -0000 Mailing-List: contact kato-spec-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: kato-spec@incubator.apache.org Delivered-To: mailing list kato-spec@incubator.apache.org Received: (qmail 20016 invoked by uid 99); 3 Mar 2009 16:51:48 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 03 Mar 2009 08:51:48 -0800 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=SPF_HELO_PASS,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [212.227.17.10] (HELO moutng.kundenserver.de) (212.227.17.10) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 03 Mar 2009 16:51:40 +0000 Received: from [9.20.183.162] (blueice1n1.uk.ibm.com [195.212.29.67]) by mrelayeu.kundenserver.de (node=mreu1) with ESMTP (Nemesis) id 0MKv1o-1LeXps2zVM-000Ddv; Tue, 03 Mar 2009 17:51:16 +0100 Message-ID: <49AD6008.7010001@stoo.me.uk> Date: Tue, 03 Mar 2009 16:51:20 +0000 From: Stuart Monteith User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.19) Gecko/20081204 SeaMonkey/1.1.14 MIME-Version: 1.0 To: kato-spec@incubator.apache.org Subject: Re: J2EE user stories References: <986b4acf0903020121o3380f54aqde9fed5f2424a9d2@mail.gmail.com> In-Reply-To: <986b4acf0903020121o3380f54aqde9fed5f2424a9d2@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V01U2FsdGVkX1/sXn6d0ymr+kmGMNyLHWhIK6hyrVd3cZ6nc6j dd11qbNZ8rhMCwZJbs+ZWmCBqxQfsT/+rdzBRA0hNh0RxxI7vv Hf/XbpiBHXkCbVFvfVwiNDOvchZsjxN X-Virus-Checked: Checked by ClamAV on apache.org I would see the layout being like this: JEE View ============ JVM View ============ Process View Where the higher level views can refer to elements of the view below. IBM centric example: Websphere Application Server (WAS) ===================== IBM JVM ===================== Linux Where tools written ontop of "JEE" view would be able to query, say, stateless session bean in WAS. But equally, the same tool should work with: Sun GlassFish ============= Sun Hotspot ============= Solaris The reason I suggest a stacked API is because JEE is Java, and so has all the same issues as Java programs. I don't see the JEE View as being a peer with the JVM View. What I'd actually suggest is a little broader. JEE is just one framework that sits on Java. I'd envisage OSGi, Hibernate, all able to sit on top. In fact, if we view JEE as just an umbrella, then we might have a picture like: >-------------JEE---------------------< +-------------------------------------+--------------+ |EJB|JTA|XMLstream|JMS|JSF|persistence|Hibernate|OSGi| +----------------------------------------------------+ | JVM View | +----------------------------------------------------+ | Process View | +----------------------------------------------------+ How much the JVM View is encapsulated within JEE view would depend on the use cases that are generated. Regardless of the degree of encapsulation, I'd see us accessing JEE container like so: JEERuntime jee1 = com.sun.glassfish.JEEFactory(JavaRuntime jr); JEERuntime jee2 = com.ibm.was.JEEFactory(JavaRuntime jr2); Anyhow, I always viewed the JVM View as being rather basic and in need of interpretation. The reason I use the term "JVM View" rather than "Java View" is to recognise that languages other than Java run on JVMs. e.g.: +------------------------------------------------------------------+ | Java View? | Scala View | Groovy View | Jython View | JRuby View | +------------------------------------------------------------------+ | JVM View | +------------------------------------------------------------------+ | Process View | +------------------------------------------------------------------+ Regards, Stuart Adam Pilkington wrote: > I was thinking about the user stories that we currently have and realise > that we don't have anything to cover the J2EE arena. I'm not sure how much a > typical J2EE developer actually makes use of a dump, given that they are > running within a container there is the possibility that they just refer the > problem to their particular vendor. However, assuming that a J2EE developer > is going to make use of a postmortem artifact, then I'm not sure that I have > any more new user stories than those already posted to the list, but what I > do think is that there are some refinements to be made. Primarily the > additional issue I see is being able to present the developer with > information that they are interested in, rather than it being swamped by the > much larger amount of container data. This means that I would like to add > the following extension to the existing user stories (I'm not sure if > extensions are even possible but I don't really want to duplicate the > previous stores) > > * As a J2EE developer I only want to see my application artifacts and not > those of the hosting container. > >