You are viewing a plain text version of this content. The canonical link for it is here.
Posted to kato-spec@incubator.apache.org by Adam Pilkington <pi...@googlemail.com> on 2009/03/02 09:21:03 UTC
J2EE user stories
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.
--
Regards
Adam Pilkington
Re: J2EE user stories
Posted by Adam Pilkington <pi...@googlemail.com>.
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 <st...@stoo.me.uk>
> 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.
>>
>>
>>
>
--
Regards
Adam Pilkington
Re: J2EE user stories
Posted by Stuart Monteith <st...@stoo.me.uk>.
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.
>
>
Re: J2EE user stories
Posted by Sonal Goyal <so...@gmail.com>.
+1
Thanks and Regards,
Sonal
On Tue, Mar 3, 2009 at 2:36 AM, Nicholas Sterling <Nicholas.Sterling@sun.com
> wrote:
> Good point. Even apart from J2EE being able to filter by package would be
> very handy.
>
> Of course if they ask a question like "What's keeping these objects in
> memory?" they may have to loosen up their filters a bit...
>
> Nicholas
>
>
>
> 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.
>>
>>
>>
>
Re: J2EE user stories
Posted by Nicholas Sterling <Ni...@Sun.COM>.
Good point. Even apart from J2EE being able to filter by package would
be very handy.
Of course if they ask a question like "What's keeping these objects in
memory?" they may have to loosen up their filters a bit...
Nicholas
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.
>
>