You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Leo Simons <ma...@leosimons.com> on 2001/09/02 15:20:28 UTC
signing of...almost
hi!
I'm leaving for Australia sept. 8, and am not taking
a computer with me. This means I will not participate
in Avalon Development for (estimated) 7 1/2 months.
I will be back after that.
It's been great fun working on Avalon, I've learned a
lot about many things in doing so and intend to get
back to it as soon as I have a computer again. Of course,
I expect y'all to have a complete release out by then =)
Two things have really been "my pets": XCommander & JMX.
Here's info about them for those that wish to refactor/
code/use it.
---
JMX
---
JMX is very cool, there are also some serious errs in the
current spec which I haven't got around to solving, which
is why the code in org.apache.jmx.introspector is not
functioning the way it should.
The problem is that most classes in javax.management do not
override equals(). This leads to a utility function like
/**
* Strips the attributes array from unwanted entries.
*/
protected void restrictOperationsTo( Class[] interfaces ) throws
IllegalArgumentException
{
ArrayList allowedOperations = new ArrayList();
ArrayList operationInfo = new ArrayList();
for( int i = 0; i < interfaces.length; i++ )
{
BeanInfo beanInfo = null;
try { beanInfo = Introspector.getBeanInfo( interfaces[i] ); }
catch( Exception e ) {
throw new IllegalArgumentException(
"The supplied interfaces are not all valid
javabeans!" ); }
final MethodDescriptor[] md = beanInfo.getMethodDescriptors();
for( int j = 0; j < md.length; j++ )
{
final MBeanOperationInfo info = new MBeanOperationInfo(
md[i].getShortDescription(),
md[i].getMethod() );
allowedOperations.add( info );
}
}
MBeanOperationInfo[] m =
(MBeanOperationInfo[])allowedOperations.toArray( new
MBeanOperationInfo[0] );
for( int i = 0; i < m.length; i++ )
{
for( int j = 0; j < m_operations.length; j++ )
{
if( m[i].equals( m_operations[j] ) )
operationInfo.add( m_operations[j] );
}
}
m_operations = (MBeanOperationInfo[])operationInfo.toArray( new
MBeanOperationInfo[0] );
}
not functioning. The solution is to replace all calls to equals()
with a utility method that does work. After that, introspection
should work and it should be easy to use it in the phoenix Manager.
The code also needs some refactoring (as per my last e-mail) and
testing.
Note that it might not be a good idea to try and follow all of
the JMX spec on the initial run. Instead, wrap the RI and rely on
it to handle all stuff we have no time for. Note that there are
several open source projects that include it in a download. I am
not sure whether sun's license is compatible with the apache
license; this is something to look at.
Paul (or anyone else), if you will be looking into this, cool =)
I will try to get to my e-mail on friday to answer any questions.
After that, it will take weeks.
----------
XCommander
----------
The basic thought behind XCommander is really cool. It can serve
as a framework for building apps talking to flash 5. It works
perfectly and scales pretty well. The main thing it needs is some
refactoring to separate the delegating sax handler from the rest
so it's use becomes even broader.
Also, a common need for flash 5 apps is support for user management;
it would make sense to provide hooks to use the recently discussed
avalon user management code.
The docs on it are pretty extensive; the only part lacking here are
unit tests.
Finally, with a little refactoring XCommander could really be a
selling point for Avalon, as everyone is doing flash right now and
with the v5 plugin become ever wider distributed it is becoming
a real option to use for just about any client-server app.
There's a mail server, an ftp server and an xml socket server
running on top of Avalon. All we need now is the web/appserver (tomcat)
running on it...
bla, bla, bla. Gotta start packing...
greetz,
- Leo Simons
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: signing of...almost
Posted by Peter Donald <do...@apache.org>.
On Mon, 3 Sep 2001 10:36, Paul Hammant wrote:
> >Thanks for all contribs and seeya when you get back. I usually wander up
> > to Sydney every few months so maybe I should stop by and say hi! ;)
> >
> >Anyways thanks for all the fish and have fun doing whatever it is you do
> > ;)
>
> Ditto man, have fun partying. Make a trip to go out and see Peter on
> his (I suspect) farm ;-)
baaah farm ... what do I sound like a hick ? ;)
Im a city-boy - couldn't live without the cafes, pubs and clubs ;) (Music +
Comedy scene in Melbourne == good)
> Please come back later on and help out again :-)))
>
> - Paul H
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
--
Cheers,
Pete
----------------------------------------
Why does everyone always overgeneralize?
----------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: signing of...almost
Posted by Paul Hammant <Pa...@yahoo.com>.
>
>
>Thanks for all contribs and seeya when you get back. I usually wander up to
>Sydney every few months so maybe I should stop by and say hi! ;)
>
>Anyways thanks for all the fish and have fun doing whatever it is you do ;)
>
Ditto man, have fun partying. Make a trip to go out and see Peter on
his (I suspect) farm ;-)
Please come back later on and help out again :-)))
- Paul H
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: signing of...almost
Posted by Peter Donald <do...@apache.org>.
Thanks for all contribs and seeya when you get back. I usually wander up to
Sydney every few months so maybe I should stop by and say hi! ;)
Anyways thanks for all the fish and have fun doing whatever it is you do ;)
On Sun, 2 Sep 2001 23:20, Leo Simons wrote:
> hi!
>
> I'm leaving for Australia sept. 8, and am not taking
> a computer with me. This means I will not participate
> in Avalon Development for (estimated) 7 1/2 months.
> I will be back after that.
>
> It's been great fun working on Avalon, I've learned a
> lot about many things in doing so and intend to get
> back to it as soon as I have a computer again. Of course,
> I expect y'all to have a complete release out by then =)
>
> Two things have really been "my pets": XCommander & JMX.
> Here's info about them for those that wish to refactor/
> code/use it.
>
> ---
> JMX
> ---
>
> JMX is very cool, there are also some serious errs in the
> current spec which I haven't got around to solving, which
> is why the code in org.apache.jmx.introspector is not
> functioning the way it should.
> The problem is that most classes in javax.management do not
> override equals(). This leads to a utility function like
>
> /**
> * Strips the attributes array from unwanted entries.
> */
> protected void restrictOperationsTo( Class[] interfaces ) throws
> IllegalArgumentException
> {
> ArrayList allowedOperations = new ArrayList();
> ArrayList operationInfo = new ArrayList();
>
> for( int i = 0; i < interfaces.length; i++ )
> {
> BeanInfo beanInfo = null;
> try { beanInfo = Introspector.getBeanInfo( interfaces[i] ); }
> catch( Exception e ) {
> throw new IllegalArgumentException(
> "The supplied interfaces are not all valid
> javabeans!" ); }
> final MethodDescriptor[] md = beanInfo.getMethodDescriptors();
> for( int j = 0; j < md.length; j++ )
> {
> final MBeanOperationInfo info = new MBeanOperationInfo(
> md[i].getShortDescription(),
> md[i].getMethod() );
> allowedOperations.add( info );
> }
> }
> MBeanOperationInfo[] m =
> (MBeanOperationInfo[])allowedOperations.toArray( new
> MBeanOperationInfo[0] );
>
> for( int i = 0; i < m.length; i++ )
> {
> for( int j = 0; j < m_operations.length; j++ )
> {
> if( m[i].equals( m_operations[j] ) )
> operationInfo.add( m_operations[j] );
> }
> }
> m_operations = (MBeanOperationInfo[])operationInfo.toArray( new
> MBeanOperationInfo[0] );
> }
>
> not functioning. The solution is to replace all calls to equals()
> with a utility method that does work. After that, introspection
> should work and it should be easy to use it in the phoenix Manager.
> The code also needs some refactoring (as per my last e-mail) and
> testing.
> Note that it might not be a good idea to try and follow all of
> the JMX spec on the initial run. Instead, wrap the RI and rely on
> it to handle all stuff we have no time for. Note that there are
> several open source projects that include it in a download. I am
> not sure whether sun's license is compatible with the apache
> license; this is something to look at.
>
> Paul (or anyone else), if you will be looking into this, cool =)
> I will try to get to my e-mail on friday to answer any questions.
> After that, it will take weeks.
>
> ----------
> XCommander
> ----------
>
> The basic thought behind XCommander is really cool. It can serve
> as a framework for building apps talking to flash 5. It works
> perfectly and scales pretty well. The main thing it needs is some
> refactoring to separate the delegating sax handler from the rest
> so it's use becomes even broader.
> Also, a common need for flash 5 apps is support for user management;
> it would make sense to provide hooks to use the recently discussed
> avalon user management code.
> The docs on it are pretty extensive; the only part lacking here are
> unit tests.
> Finally, with a little refactoring XCommander could really be a
> selling point for Avalon, as everyone is doing flash right now and
> with the v5 plugin become ever wider distributed it is becoming
> a real option to use for just about any client-server app.
>
> There's a mail server, an ftp server and an xml socket server
> running on top of Avalon. All we need now is the web/appserver (tomcat)
> running on it...
>
> bla, bla, bla. Gotta start packing...
>
> greetz,
>
> - Leo Simons
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
--
Cheers,
Pete
---------------------------------------------------------
Clarke's Third Law: "Any technology distinguishable from
magic is insufficiently advanced".
---------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org