[kkress: Re: [Openjmx-devel] Velocity Http Adapter]

[k***@myslo.com]

sorry I replied directly to Carlos.

--KMK
----- Forwarded message from kkress -----

To: Carlos Quiroz <***@welho.com>
Subject: Re: [Openjmx-devel] Velocity Http Adapter

- Let's try to keep the same look and feeling in both XSLT and Velocity
version. Notice that this doesn't mean they have to be equal, just keep them
in synch.

Not a problem, I will keep the same look and feel as the XSL Proccessor.

- Eventually some code from XSLT processor can be useful to you, then we can
refactor it and move it to an abstract antecessor

I will create a common base Class for shared methods.... I will do this whereever possible.

- Look at the current code for code formatting

OK

- We'd like test, however I'm very against testing HTML since it seems a real
waste of time, so if that's the only thing to test, don't do it :-)

not a problem. I will test stuff before submitting :)

--Kevin Kress


----- End forwarded message -----

[Carlos Quiroz]

Post by k***@myslo.com
Not a problem, I will keep the same look and feel as the XSL Proccessor.

ok

Post by k***@myslo.com

- Eventually some code from XSLT processor can be useful to you, then we
can refactor it and move it to an abstract antecessor

I will create a common base Class for shared methods.... I will do this whereever possible.

ok

Post by k***@myslo.com

- Look at the current code for code formatting

OK

- We'd like test, however I'm very against testing HTML since it seems a
real waste of time, so if that's the only thing to test, don't do it :-)

not a problem. I will test stuff before submitting :)

About JDOM. Are you planing to use Anakia? I like it a lot but I didn't use
it to avoid having too many dependencies. But if is required by anakia then
so be it.

One thing we have to discuss is how to avoid the explosion of libs. We
already have several and with this will be adding jdom, velocity, and also
JSSE for SSL support. We should probably have ant decide what to build
depending on the available classes

[k***@myslo.com]

<snip>

Post by Carlos Quiroz
About JDOM. Are you planing to use Anakia? I like it a lot but I didn't use
it to avoid having too many dependencies. But if is required by anakia then
so be it.

I was looking into JDOM, I am not sure it gives that much of an advantage over pure org.w3c classes, with one exception, jdom supports the java.util.List interface for listing nodes, where org/w3c uses their own classes. I am just plaing around with the JDOM stuff right now, I probably will not use it.

As for the use of anakia... If I am not mistaken anakia is a build task for ant that takes variables as input and dumps them to a .vm file. I am not sure this is something we need to use. The idea is the same here init the Velocity engine, toss it a template and a context to fill in, pipe the output from the Template file to an outputstream.

I will go back an look at anakia again, but I am fairly certain it is just a wrapper around Velocity for "ant".

On a side note, is there an easy way to have the reply-t for this list to auto send to the list instead of replying to the sender.

--Kevin Kevin

Post by Carlos Quiroz
One thing we have to discuss is how to avoid the explosion of libs. We
already have several and with this will be adding jdom, velocity, and also
JSSE for SSL support. We should probably have ant decide what to build
depending on the available classes
_______________________________________________
Openjmx-devel mailing list
https://lists.sourceforge.net/lists/listinfo/openjmx-devel

[Carlos Quiroz]

Post by k***@myslo.com
<snip>

Post by Carlos Quiroz
About JDOM. Are you planing to use Anakia? I like it a lot but I didn't
use it to avoid having too many dependencies. But if is required by
anakia then so be it.

I was looking into JDOM, I am not sure it gives that much of an advantage
over pure org.w3c classes, with one exception, jdom supports the
java.util.List interface for listing nodes, where org/w3c uses their own
classes. I am just plaing around with the JDOM stuff right now, I probably
will not use it.

I think JDOM it is a very nice lib but we may want to live with the w3c
classes unless it is really necessary

Post by k***@myslo.com
As for the use of anakia... If I am not mistaken anakia is a build task for
ant that takes variables as input and dumps them to a .vm file. I am not
sure this is something we need to use. The idea is the same here init the
Velocity engine, toss it a template and a context to fill in, pipe the
output from the Template file to an outputstream.
I will go back an look at anakia again, but I am fairly certain it is just
a wrapper around Velocity for "ant".

Perhaps I missunderstood but It seemed to me that you could use anakia for
XML integration into Velocity. But I may be very mistaken, just let us know
your ideas

Post by k***@myslo.com
On a side note, is there an easy way to have the reply-t for this list to
auto send to the list instead of replying to the sender.

Unfortunately this is Sourceforge policy
http://sourceforge.net/docman/display_doc.php?docid=6693&group_id=1

Post by k***@myslo.com
--Kevin Kevin

Post by Carlos Quiroz
One thing we have to discuss is how to avoid the explosion of libs. We
already have several and with this will be adding jdom, velocity, and
also JSSE for SSL support. We should probably have ant decide what to
build depending on the available classes
_______________________________________________
Openjmx-devel mailing list
https://lists.sourceforge.net/lists/listinfo/openjmx-devel

_______________________________________________
Openjmx-devel mailing list
https://lists.sourceforge.net/lists/listinfo/openjmx-devel

[Remy Maucherat]

Hi,

Is there a problem with the patch on the query algorithm ? I can't use
OpenJMX at all, nor recommend others attempt to use it (with Tomcat) until
the query algorithm is fixed.

That's funny, usually I'm at the other end of this, and I'm the one being
nagged ;-)

Thanks (and sorry for being annoying),
Remy

[Carlos Quiroz]

Post by Remy Maucherat
Hi,
Is there a problem with the patch on the query algorithm ? I can't use
OpenJMX at all, nor recommend others attempt to use it (with Tomcat) until
the query algorithm is fixed.

I think there is no problem, I'd would like to hear Simone's opinion tough
since it is his part of the code

Post by Remy Maucherat
That's funny, usually I'm at the other end of this, and I'm the one being
nagged ;-)
Thanks (and sorry for being annoying),
Remy
_______________________________________________
Openjmx-devel mailing list
https://lists.sourceforge.net/lists/listinfo/openjmx-devel

[Bordet, Simone]

Hi Remy,

Post by Remy Maucherat
Hi,
Is there a problem with the patch on the query algorithm ? I can't use
OpenJMX at all, nor recommend others attempt to use it (with
Tomcat) until
the query algorithm is fixed.

Eh, just had not time, if you want I can add you as developer, just ping me.

However, I'm working on it right now ;)
Hold on for a little while.

Post by Remy Maucherat
That's funny, usually I'm at the other end of this, and I'm
the one being nagged ;-)

You asked for it, you got it ;)

I was looking at Tomcat source 4.0.1 the CatalinaManager MBean, don't know if you already fixed this in CVS, but:
1) a constructor that take the catalina home directory is needed (useful in MLet files)
2) you should really return the given object name in preRegister if not null (otherwise the default one you now always return).

Hold on ! ;)

Simon

[Remy Maucherat]

Post by Bordet, Simone
Eh, just had not time, if you want I can add you as developer, just ping me.

Sorry, no time ;-)
The project is very interesting, and I may send a patch once in a while, but
I'm afraid I can't make the commitment of being a committer.

Post by Bordet, Simone
However, I'm working on it right now ;)
Hold on for a little while.

Thanks :)

Post by Bordet, Simone
You asked for it, you got it ;)
I was looking at Tomcat source 4.0.1 the CatalinaManager MBean,
1) a constructor that take the catalina home directory is
needed (useful in MLet files)
2) you should really return the given object name in
preRegister if not null (otherwise the default one you now always return).

Ah yes, this is the old stuff I "wrote" (actually copied from some beans in
JBoss, to make integrating with it slightly easier) loooong ago. Anyway, it
shouldn't even be looked at ;)
The JMX functionality I was talking about and I'm trying to use with OpenJMX
is only available in the HEAD branch of the Tomcat CVS.

Remy

[Bordet, Simone]

Hi,

Post by Remy Maucherat
Sorry, no time ;-)
The project is very interesting, and I may send a patch once
in a while, but
I'm afraid I can't make the commitment of being a committer.

I understand. I'm anyhow happy to see you on this list :)

Post by Remy Maucherat

Post by Bordet, Simone
However, I'm working on it right now ;)
Hold on for a little while.

Thanks :)

It's fixed in CVS. Things were a little bit more complicated than your patch, but thanks for pointing out this bug.
I also added a test in QueryTest to check that scoping of queries is done properly.
Let us know if it is ok.

Post by Remy Maucherat

Post by Bordet, Simone
You asked for it, you got it ;)
I was looking at Tomcat source 4.0.1 the CatalinaManager MBean,
1) a constructor that take the catalina home directory is
needed (useful in MLet files)
2) you should really return the given object name in
preRegister if not null (otherwise the default one you now

always return).
Ah yes, this is the old stuff I "wrote" (actually copied from
some beans in
JBoss, to make integrating with it slightly easier) loooong
ago. Anyway, it
shouldn't even be looked at ;)

Ah.

Post by Remy Maucherat
The JMX functionality I was talking about and I'm trying to
use with OpenJMX
is only available in the HEAD branch of the Tomcat CVS.

And will be in 4.1 ? Which is scheduled when ?

Thanks

Simon