You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by Rick Curtis <cu...@gmail.com> on 2010/10/12 20:31:47 UTC
Compiling a JConsole plugin
I wrote a small proof-of-concept jconsole[1] plugin that can display
DataCache statistics. To write the custom plugin[2][3] I had to extend
com.sun.tools.jconsole.JConsolePlugin which exists in
[java_home]/lib/jconsole.jar on both IBM and Sun JDKs. For my first pass I
manually added that jar to my classpath, but how do I get the OpenJPA build
to do the same?
[1] http://java.sun.com/developer/technicalArticles/J2SE/jconsole.html
[2] http://filebin.ca/swset/jconsole.jpg
[3] http://filebin.ca/atogum/jconsole_plugin.patch
Thanks,
Rick
Re: Compiling a JConsole plugin
Posted by Pinaki Poddar <pp...@apache.org>.
> My only concern is that separation of tools can lead to confusion.
Firstly if that is your 'only' concern -- it is good news. Confusion can be
resolved :)
> As a user how am I supposed to know where a given tool lives? To enhance I
> need to
> look at the runtime jar, to use the migration tool I need to look at the
> tools jar, etc, etc.
The currently kernel-resident tools require a face-lift. I remember a
thread of discussion where we talked about having a unified command-line
options, having the command-line tools self-describable and may be also a
graphical UI. All of these ergonomic extensions on the proven capabilities
of OpenJPA tools are better executed in a 'sand-box' like environment that
will enjoy higher velocity/fluidity. I think current tools repo is serving
that purpose well.
Once the activity gathers momentum and certain degree of solidity, then the
concerns you raise regarding the codebase location, issue tracking,
packaging etc would be more timely.
-----
Pinaki
--
View this message in context: http://openjpa.208410.n2.nabble.com/Compiling-a-JConsole-plugin-tp5627913p5633225.html
Sent from the OpenJPA Developers mailing list archive at Nabble.com.
Re: Compiling a JConsole plugin
Posted by Michael Dick <mi...@gmail.com>.
+1.
-mike
On Thu, Oct 14, 2010 at 10:54 AM, Donald Woods <dw...@apache.org> wrote:
> If there are tight version/API depends, then I'd put it in the main
> trunk source in a module like openjpa-jconsole. We can then pull it
> into the binary assembly, but not into openjpa.all.jar.
>
>
> -Donald
>
>
> On 10/13/10 12:08 PM, Rick Curtis wrote:
> > Good points Pinaki.
> >
> > My only concern is that separation of tools can lead to confusion. As a
> user
> > how am I supposed to know where a given tool lives? To enhance I need to
> > look at the runtime jar, to use the migration tool I need to look at the
> > tools jar, etc, etc.
> >
> > Thanks,
> > Rick
> >
>
Re: Compiling a JConsole plugin
Posted by Donald Woods <dw...@apache.org>.
If there are tight version/API depends, then I'd put it in the main
trunk source in a module like openjpa-jconsole. We can then pull it
into the binary assembly, but not into openjpa.all.jar.
-Donald
On 10/13/10 12:08 PM, Rick Curtis wrote:
> Good points Pinaki.
>
> My only concern is that separation of tools can lead to confusion. As a user
> how am I supposed to know where a given tool lives? To enhance I need to
> look at the runtime jar, to use the migration tool I need to look at the
> tools jar, etc, etc.
>
> Thanks,
> Rick
>
Re: Compiling a JConsole plugin
Posted by Pinaki Poddar <pp...@apache.org>.
Jeremy,
> A version dependencies could be documented and/or handled within the
tooling itself.
Absolutely agree. In fact, tooling over current kernel-resident tools
(enhancer, reverse mapper) etc act as a buffer -- to introduce experimental
features or deprecate older (hard-to-support) ones. That is where a
graphical UI shines.
-----
Pinaki
--
View this message in context: http://openjpa.208410.n2.nabble.com/Compiling-a-JConsole-plugin-tp5627913p5633237.html
Sent from the OpenJPA Developers mailing list archive at Nabble.com.
Re: Compiling a JConsole plugin
Posted by Jeremy Bauer <te...@gmail.com>.
I agree with Pinaki. I think tools like these should live under the tools
portion of the source tree. My one sticking point was that many of the
tools may have a particular version dependency on OpenJPA, even the OpenJPA
revision. I think I'm over that now. A version dependencies could be
documented and/or handled within the tooling itself. The tools link on the
OpenJPA website[1] provides a location to document installation,
dependencies, usage, etc. for tools.
-Jeremy
[1] http://openjpa.apache.org/tools.html
On Wed, Oct 13, 2010 at 11:08 AM, Rick Curtis <cu...@gmail.com> wrote:
> Good points Pinaki.
>
> My only concern is that separation of tools can lead to confusion. As a
> user
> how am I supposed to know where a given tool lives? To enhance I need to
> look at the runtime jar, to use the migration tool I need to look at the
> tools jar, etc, etc.
>
> Thanks,
> Rick
>
Re: Compiling a JConsole plugin
Posted by Rick Curtis <cu...@gmail.com>.
Good points Pinaki.
My only concern is that separation of tools can lead to confusion. As a user
how am I supposed to know where a given tool lives? To enhance I need to
look at the runtime jar, to use the migration tool I need to look at the
tools jar, etc, etc.
Thanks,
Rick
Re: Compiling a JConsole plugin
Posted by Pinaki Poddar <pp...@apache.org>.
> As of writing this email I'm leaning toward putting this plugin in
openjpa-kernel,
> but I could be persuaded. Thoughts?
A tool repo is available and that is my preference. My reasons are
a) tools development is expected to have higher velocity than kernel at this
point.
b) a separate repo will enforce better design isolation. The tools, by
design, should act more as a client to the kernel. You generally will not
like clients to be too near to the server -- do you?
c) tools are expected to have dependency to wider libraries (JConsole,
Swing, IDE libs...) -- having them in kernel will increase core runtime
footprint
-----
Pinaki
--
View this message in context: http://openjpa.208410.n2.nabble.com/Compiling-a-JConsole-plugin-tp5627913p5631489.html
Sent from the OpenJPA Developers mailing list archive at Nabble.com.
Re: Compiling a JConsole plugin
Posted by Rick Curtis <cu...@gmail.com>.
Jeremy -
Good blog post... that would have come in handy. Maybe next time. I think I
have my pom problem squared away and now I need to figure out where to put
this.
I know there were some discussions a while back on the mailing list about
the tools repo but I'm curious as to what is the criteria to decide code
goes (tools vs openjpa repo)? As of writing this email I'm leaning toward
putting this plugin in openjpa-kernel, but I could be persuaded. Thoughts?
Thanks,
Rick
On Tue, Oct 12, 2010 at 2:01 PM, Jeremy Bauer <te...@gmail.com> wrote:
> Hi Rick,
>
> I started on a similar undertaking with JConsole after adding the initial
> JMX support. Perhaps we can merge the two efforts at some point. I have
> the beginnings of a simple call framework over JMX that also allows one to
> easily plug calculated attributes (cache hit rate, etc.) into the
> instrumentation query, abstracting that logic from the rendering layer.
> My plan was to add the plugin under the tools side of the repo. I ended
> up
> creating a pom that picked up the necessary dependency from the local
> JDK/SDK. Unfortunately, I don't have the pom handy. It is on a remote
> machine that is powered down at the moment. I'll post it tomorrow. IIRC,
> The dependency looked *something* like this, but was more OS + JDK path
> smart/friendly...
>
> <dependency>
> <groupId>com.sun</groupId>
> <artifactId>jconsole</artifactId>
> <version>1.6</version>
> <scope>system</scope>
> <systemPath>C:/Program
> Files/Java/jdk1.6.0_21/lib/jconsole.jar</systemPath>
> </dependency>
>
> Also, if you happen to be having problems debugging a jConsole plugin from
> Eclipse, I blogged about it a while back.
>
>
> http://techhusky.blogspot.com/2010/08/debugging-jconsole-plugins-from-eclipse.html
>
> -Jeremy
>
> On Tue, Oct 12, 2010 at 1:31 PM, Rick Curtis <cu...@gmail.com> wrote:
>
> > I wrote a small proof-of-concept jconsole[1] plugin that can display
> > DataCache statistics. To write the custom plugin[2][3] I had to extend
> > com.sun.tools.jconsole.JConsolePlugin which exists in
> > [java_home]/lib/jconsole.jar on both IBM and Sun JDKs. For my first pass
> I
> > manually added that jar to my classpath, but how do I get the OpenJPA
> build
> > to do the same?
> >
> > [1] http://java.sun.com/developer/technicalArticles/J2SE/jconsole.html
> > [2] http://filebin.ca/swset/jconsole.jpg
> > [3] http://filebin.ca/atogum/jconsole_plugin.patch
> >
> > Thanks,
> > Rick
> >
>
Re: Compiling a JConsole plugin
Posted by Jeremy Bauer <te...@gmail.com>.
Hi Rick,
I started on a similar undertaking with JConsole after adding the initial
JMX support. Perhaps we can merge the two efforts at some point. I have
the beginnings of a simple call framework over JMX that also allows one to
easily plug calculated attributes (cache hit rate, etc.) into the
instrumentation query, abstracting that logic from the rendering layer.
My plan was to add the plugin under the tools side of the repo. I ended up
creating a pom that picked up the necessary dependency from the local
JDK/SDK. Unfortunately, I don't have the pom handy. It is on a remote
machine that is powered down at the moment. I'll post it tomorrow. IIRC,
The dependency looked *something* like this, but was more OS + JDK path
smart/friendly...
<dependency>
<groupId>com.sun</groupId>
<artifactId>jconsole</artifactId>
<version>1.6</version>
<scope>system</scope>
<systemPath>C:/Program
Files/Java/jdk1.6.0_21/lib/jconsole.jar</systemPath>
</dependency>
Also, if you happen to be having problems debugging a jConsole plugin from
Eclipse, I blogged about it a while back.
http://techhusky.blogspot.com/2010/08/debugging-jconsole-plugins-from-eclipse.html
-Jeremy
On Tue, Oct 12, 2010 at 1:31 PM, Rick Curtis <cu...@gmail.com> wrote:
> I wrote a small proof-of-concept jconsole[1] plugin that can display
> DataCache statistics. To write the custom plugin[2][3] I had to extend
> com.sun.tools.jconsole.JConsolePlugin which exists in
> [java_home]/lib/jconsole.jar on both IBM and Sun JDKs. For my first pass I
> manually added that jar to my classpath, but how do I get the OpenJPA build
> to do the same?
>
> [1] http://java.sun.com/developer/technicalArticles/J2SE/jconsole.html
> [2] http://filebin.ca/swset/jconsole.jpg
> [3] http://filebin.ca/atogum/jconsole_plugin.patch
>
> Thanks,
> Rick
>