incubator-kato-spec mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Pilkington <>
Subject Re: J2EE user stories
Date Tue, 03 Mar 2009 17:27:50 GMT
I think that I have some actual J2EE user stories which may be useful as
discussion points

1. As a J2EE developer I want to be able to see the classloader scoping
rules which are defining which classes are being loaded and where. This is
to address the issue of actually knowing which class is being loaded, say in
servlet, and whether it comes from the application specific, shared or
system context.

2. As a J2EE developer I want to be able to categorise what I am shown by a
tool into broad areas of responsibility. My thoughts are that this would be
something along the lines of if I am debugging a custom JCA component, I
would like to be able to breakdown what I see into VM artifacts, application
server infrastructure artifacts, J2EE framwork artifacts (in this case JCA)
and finally my own application artifacts. The reason for this is that you
are potentially going to want to dip below the level of your application
into the underlying J2EE framework in order to be able to see what
references etc. are being held, but you don't want to deep dive into the
entire application server infrstructure.

3. I want to be able to see application server lifecycle state. Taking EJBs
as an example, I want to see the number of instances of my beans that have
been created, how many are actually active and if any have been passivated
(of course this will depend on the bean type). I'm thinking along the lines
of thread state in the VM, but exposing J2EE object state in the same way.

2009/3/3 Stuart Monteith <>

> 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 = 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.


Adam Pilkington

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message