incubator-kato-spec mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Poole <spoole...@googlemail.com>
Subject Re: System Properties and Env vars
Date Tue, 12 Jan 2010 08:33:21 GMT
On Tue, Jan 12, 2010 at 2:38 AM, Daniel Julin <dpj@us.ibm.com> wrote:

>
> For what it's worth, the DTFJ-based DumpAnalyzer tool also has a module for
> extracting system properties: com.ibm.dtfj.analyzer.jvm.SystemProperties.
> It works by using DTFJ API calls to find the java.lang.System class
> instance in the list of classloaders, then traverse it, then interpret the
> fields in the java.util.Properties instance that it finds there.
>
> This is one of about 100 "utility" modules that have been built on top of
> DTFJ to facilitate the implementation of various common functions in
> DumpAnalyzer. I think that this may demonstrate that there are too many
> "common functions" and variations to hard-wire into a single low-level API.
> We really do need a low level API _and_ a powerful library on top of it.
> Similar to how in the runtime, we have the "low-level" JVM and a powerful
> class library on top of it... I guess this is similar to the "commons"
> library that Steve mentions below
>

Yes that's right.    I'm sure we'd all be interested in knowing more about
these utilitiy modules you mention -  could you provide a basic  1 liner
description for the most important ones?


> Incidentally, this simple example of a module for system properties is not
> as simple as it sounds. In a complex J2EE or OSGI world with a complex
> hierarchy of classloaders, we can't be sure that there will always be a
> single definition of java.lang.System, or of other similar classes that
> hold similar properties associated with various J2EE or OSGI modules. If
> that's the case, we would need to have an equivalent collection of analysis
> modules that deal with these variations.
>
>
> As for environment variables, I have not looked in Kato recently, but in
> DTFJ, they used to be available, but from the ImageProcess, not from the
> JavaRuntime.
>
> Your right - they are available from ImageProcess but I wanted to make them
available from JavaRuntime as well .

>
>
> -- Daniel --
>
> ==============================================================
> Daniel P. Julin
> Senior Technical Staff Member
> Technical Area Lead  -  IBM AIM WebSphere Serviceability Team
>
> EMail: dpj@us.ibm.com
> Phone: 347-273-2093          Tie-line 930-3468
> Notes: Daniel Julin/Pittsburgh/IBM@IBMUS
>
>
>
> Steve Poole <spoole167@googlemail.com> wrote on 2010-01-11 11:23:53 AM:
>
> > [image removed]
> >
> > Re: System Properties and Env vars
> >
> > Steve Poole
> >
> > to:
> >
> > kato-spec
> >
> > 10-01-11 11:24 AM
> >
> > Please respond to kato-spec
> >
> > On Mon, Jan 11, 2010 at 4:19 PM, David Griffiths
> > <david.griffiths@gmail.com>wrote:
> >
> > > Agreed about the system properties (as a Map). Env vars used to be
> > > available via ImageProcess but I guess you want to move away from
> > > that?
> > >
> > > I would like have the same data available from the JavaRuntime   for
> > completeness since java.lang.System  provides both properties and envvars
> > and , as you've guessed,  because the ImageProcess might not be
> available.
> >
> >
> >
> > Cheers,
> > >
> > > Dave
> > >
> > > On Mon, Jan 11, 2010 at 3:21 PM, Steve Poole <spoole167@googlemail.com
> >
> > > wrote:
> > > > Is it just me or does anyone else think its an unneccessary
> restriction
> > > that
> > > > the JavaRuntime API does not offer the ability to get to System
> > > Properties
> > > > or Environmental variables?  You can get them from a running JVM so
> why
> > > > should we not have the same capability on our API?
> > > >
> > > >
> > > > --
> > > > Steve
> > > >
> > >
> >
> >
> >
> > --
> > Steve
>



-- 
Steve

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