You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jmeter-dev@jakarta.apache.org by David Glick <dg...@cox.net> on 2003/05/15 21:17:54 UTC
Detecting removal of a sampler
Hi,
I'm designing JMeter extensions to support my client's execution environment,
and one of the capabilities that I'm building is for each sampler to register
with a global listener so that the listener can query the sampler for
specific properties at a later time. In order to do this, the sampler
invokes a static register() method on the listener when it is instantiated.
Now I need the sampler to invoke the unregister() method when it is removed
from the tree. I'm thinking about overriding the setNode() method in
AbstractJMeterGuiComponent and adding a tree listener that can detect when
the sampler is removed.
Is this the best way to detect removal, or is there an easier way to do so?
Thanks for any help,
David Glick
Transmit Consulting, Inc
619-475-4052
dglick@transmitconsulting.com
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
Re: Detecting removal of a sampler
Posted by David Glick <dg...@cox.net>.
Thanks, Mike, I'd be happy to. Unfortunately, I don't know either the IRC
chat room nor your IM handle. If you wouldn't mind supplying me with one or
the other, I'll start up a direct dialog.
Thanks for your help,
David
On Thursday 15 May 2003 1:32 pm, mstover1@apache.org wrote:
> Well, I got the impression you were modifying currently existing Samplers.
>
> Maybe you should stop by the IRC chat room sometime, or IM me directly
> and we can talk about it more efficiently. Honestly, I could think of
> nearly a dozen different ways for you to do what you want. It all depends
> on what exactly you want, and clearly I don't have a good picture of what
> that is.
>
> -Mike
>
> On 15 May 2003 at 13:29, David Glick wrote:
> > The way that I currently have my extensions organized, my build script
> > creates a custom jar file and adds it to the $JMETER_HOME/lib/ext
> > directory, where JMeter automatically adds the custom samplers and
> > listeners to the
>
> framework.
>
> > Am I correct in thinking that, in order to make the changes as you've
> > suggested, I'll need to modify the core JMeter source code? My concern
> > is that my client may decide to upgrade at some point in the future when
> > I'm
>
> no
>
> > longer associated with the project, and I'm concerned that whomever does
>
> the
>
> > migration won't follow directions (clearly written, of course!) and
> > things will just stop working for the client. My preference is to do
> > more work on the front end to avoid problems like this down the line. Of
> > course, I could be wrong...
> >
> > On Thursday 15 May 2003 1:11 pm, mstover1@apache.org wrote:
> > > In that case, you might have an easier time modifying Remove.java
>
> directly.
>
> > > This will also make migration easier as you can make your own class
>
> that
>
> > > does the work you need, and make a one line addition to Remove.java
>
> that
>
> > > calls your class. Then, in the future, your class registers to receive
> > > events instead of this direct call.
> > >
> > > Similarly, you can modify Load.java and AddToTree.java to detect when
> > > Samplers are added.
> > >
> > > I highly recommend inserting your code at these points instead of in
> > > the tree listener. These classes are simpler, and much more decoupled
> > > from
>
> the
>
> > > rest of JMeter - should make your job easier.
> > >
> > > -Mike
> > >
> > > On 15 May 2003 at 13:02, David Glick wrote:
> > > > Thanks, Mike. Unfortunately, I'm stuck with 1.8.1 for this iteration
> > > > and won't be looking at migrating in the near future. Given this, is
> > > > there any other implementation I should be looking at, or would you
>
> recommend I
>
> > > move
> > >
> > > > forward with the tree listener?
> > > >
> > > > David
> > > >
> > > > On Thursday 15 May 2003 12:38 pm, mstover1@apache.org wrote:
> > > > > Actually, there is a simpler solution, I think. You can register
> > > > > with ActionRouter to be a pre or post processor for any action
> > > > > class. In this case, you are interested in the activity of the
> > > > > Remove.java command
> > >
> > > class.
> > >
> > > > > You probably want to make a class that will be a pre-processor
> > > > > prior
>
> to
>
> > > > > Remove.java running. By doing so you can first look at the
> > > > > selected
> > >
> > > nodes,
> > >
> > > > > see if any are Samplers, and call the methods you want to call.
> > > > >
> > > > > Also, it seems like you could use this mechanism for creation of
> > > > > the Sampler as well and avoid having to change Sampler code at all.
>
> Just
>
> > > make
> > >
> > > > > your new action class responsible for registering and unregistering
> > > > > Samplers with your special listener.
> > > > >
> > > > > This is new to 1.9 and not available in 1.8.1.
> > > > >
> > > > > -Mike
> > > > >
> > > > > On 15 May 2003 at 12:17, David Glick wrote:
> > > > > > Hi,
> > > > > >
> > > > > > I'm designing JMeter extensions to support my client's execution
> > > > >
> > > > > environment,
> > > > >
> > > > > > and one of the capabilities that I'm building is for each sampler
> > > > > > to register with a global listener so that the listener can query
> > > > > > the sampler for specific properties at a later time. In order to
> > > > > > do this, the sampler invokes a static register() method on the
> > > > > > listener when it is instantiated. Now I need the sampler to
> > > > > > invoke the unregister() method when it is
> > > > >
> > > > > removed
> > > > >
> > > > > > from the tree. I'm thinking about overriding the setNode()
> > > > > > method in AbstractJMeterGuiComponent and adding a tree listener
> > > > > > that can
> > >
> > > detect
> > >
> > > > > when
> > > > >
> > > > > > the sampler is removed.
> > > > > >
> > > > > > Is this the best way to detect removal, or is there an easier way
> > > > > > to do so?
> > > > > >
> > > > > >
> > > > > > Thanks for any help,
> > > > > >
> > > > > > David Glick
> > > > > > Transmit Consulting, Inc
> > > > > > 619-475-4052
> > > > > > dglick@transmitconsulting.com
> > > > > >
> > > > > >
> > > > > > -----------------------------------------------------------------
> > > > > >---- To unsubscribe, e-mail: jmeter-dev-
>
> unsubscribe@jakarta.apache.org
>
> > > > > > For additional commands, e-mail: jmeter-dev-
>
> help@jakarta.apache.org
>
> > > > --
> > > > David Glick
> > > > Transmit Consulting, Inc
> > > > 619-475-4052
> > > > dglick@transmitconsulting.com
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> >
> > --
> > David Glick
> > Transmit Consulting, Inc
> > 619-475-4052
> > dglick@transmitconsulting.com
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
--
David Glick
Transmit Consulting, Inc
619-475-4052
dglick@transmitconsulting.com
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
Re: Detecting removal of a sampler
Posted by ms...@apache.org.
Well, I got the impression you were modifying currently existing Samplers.
Maybe you should stop by the IRC chat room sometime, or IM me directly
and we can talk about it more efficiently. Honestly, I could think of nearly a
dozen different ways for you to do what you want. It all depends on what
exactly you want, and clearly I don't have a good picture of what that is.
-Mike
On 15 May 2003 at 13:29, David Glick wrote:
> The way that I currently have my extensions organized, my build script creates
> a custom jar file and adds it to the $JMETER_HOME/lib/ext directory, where
> JMeter automatically adds the custom samplers and listeners to the
framework.
> Am I correct in thinking that, in order to make the changes as you've
> suggested, I'll need to modify the core JMeter source code? My concern is
> that my client may decide to upgrade at some point in the future when I'm
no
> longer associated with the project, and I'm concerned that whomever does
the
> migration won't follow directions (clearly written, of course!) and things
> will just stop working for the client. My preference is to do more work on
> the front end to avoid problems like this down the line. Of course, I could
> be wrong...
>
>
> On Thursday 15 May 2003 1:11 pm, mstover1@apache.org wrote:
> > In that case, you might have an easier time modifying Remove.java
directly.
> > This will also make migration easier as you can make your own class
that
> > does the work you need, and make a one line addition to Remove.java
that
> > calls your class. Then, in the future, your class registers to receive
> > events instead of this direct call.
> >
> > Similarly, you can modify Load.java and AddToTree.java to detect when
> > Samplers are added.
> >
> > I highly recommend inserting your code at these points instead of in the
> > tree listener. These classes are simpler, and much more decoupled from
the
> > rest of JMeter - should make your job easier.
> >
> > -Mike
> >
> > On 15 May 2003 at 13:02, David Glick wrote:
> > > Thanks, Mike. Unfortunately, I'm stuck with 1.8.1 for this iteration and
> > > won't be looking at migrating in the near future. Given this, is there
> > > any other implementation I should be looking at, or would you
recommend I
> >
> > move
> >
> > > forward with the tree listener?
> > >
> > > David
> > >
> > > On Thursday 15 May 2003 12:38 pm, mstover1@apache.org wrote:
> > > > Actually, there is a simpler solution, I think. You can register with
> > > > ActionRouter to be a pre or post processor for any action class. In
> > > > this case, you are interested in the activity of the Remove.java
> > > > command
> >
> > class.
> >
> > > > You probably want to make a class that will be a pre-processor prior
to
> > > > Remove.java running. By doing so you can first look at the selected
> >
> > nodes,
> >
> > > > see if any are Samplers, and call the methods you want to call.
> > > >
> > > > Also, it seems like you could use this mechanism for creation of the
> > > > Sampler as well and avoid having to change Sampler code at all.
Just
> >
> > make
> >
> > > > your new action class responsible for registering and unregistering
> > > > Samplers with your special listener.
> > > >
> > > > This is new to 1.9 and not available in 1.8.1.
> > > >
> > > > -Mike
> > > >
> > > > On 15 May 2003 at 12:17, David Glick wrote:
> > > > > Hi,
> > > > >
> > > > > I'm designing JMeter extensions to support my client's execution
> > > >
> > > > environment,
> > > >
> > > > > and one of the capabilities that I'm building is for each sampler to
> > > > > register with a global listener so that the listener can query the
> > > > > sampler for specific properties at a later time. In order to do
> > > > > this, the sampler invokes a static register() method on the listener
> > > > > when it is instantiated. Now I need the sampler to invoke the
> > > > > unregister() method when it is
> > > >
> > > > removed
> > > >
> > > > > from the tree. I'm thinking about overriding the setNode() method in
> > > > > AbstractJMeterGuiComponent and adding a tree listener that can
> >
> > detect
> >
> > > > when
> > > >
> > > > > the sampler is removed.
> > > > >
> > > > > Is this the best way to detect removal, or is there an easier way to
> > > > > do so?
> > > > >
> > > > >
> > > > > Thanks for any help,
> > > > >
> > > > > David Glick
> > > > > Transmit Consulting, Inc
> > > > > 619-475-4052
> > > > > dglick@transmitconsulting.com
> > > > >
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: jmeter-dev-
unsubscribe@jakarta.apache.org
> > > > > For additional commands, e-mail: jmeter-dev-
help@jakarta.apache.org
> > >
> > > --
> > > David Glick
> > > Transmit Consulting, Inc
> > > 619-475-4052
> > > dglick@transmitconsulting.com
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
>
> --
> David Glick
> Transmit Consulting, Inc
> 619-475-4052
> dglick@transmitconsulting.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
>
--
Michael Stover
mstover1@apache.org
Yahoo IM: mstover_ya
ICQ: 152975688
AIM: mstover777
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
Re: Detecting removal of a sampler
Posted by David Glick <dg...@cox.net>.
The way that I currently have my extensions organized, my build script creates
a custom jar file and adds it to the $JMETER_HOME/lib/ext directory, where
JMeter automatically adds the custom samplers and listeners to the framework.
Am I correct in thinking that, in order to make the changes as you've
suggested, I'll need to modify the core JMeter source code? My concern is
that my client may decide to upgrade at some point in the future when I'm no
longer associated with the project, and I'm concerned that whomever does the
migration won't follow directions (clearly written, of course!) and things
will just stop working for the client. My preference is to do more work on
the front end to avoid problems like this down the line. Of course, I could
be wrong...
On Thursday 15 May 2003 1:11 pm, mstover1@apache.org wrote:
> In that case, you might have an easier time modifying Remove.java directly.
> This will also make migration easier as you can make your own class that
> does the work you need, and make a one line addition to Remove.java that
> calls your class. Then, in the future, your class registers to receive
> events instead of this direct call.
>
> Similarly, you can modify Load.java and AddToTree.java to detect when
> Samplers are added.
>
> I highly recommend inserting your code at these points instead of in the
> tree listener. These classes are simpler, and much more decoupled from the
> rest of JMeter - should make your job easier.
>
> -Mike
>
> On 15 May 2003 at 13:02, David Glick wrote:
> > Thanks, Mike. Unfortunately, I'm stuck with 1.8.1 for this iteration and
> > won't be looking at migrating in the near future. Given this, is there
> > any other implementation I should be looking at, or would you recommend I
>
> move
>
> > forward with the tree listener?
> >
> > David
> >
> > On Thursday 15 May 2003 12:38 pm, mstover1@apache.org wrote:
> > > Actually, there is a simpler solution, I think. You can register with
> > > ActionRouter to be a pre or post processor for any action class. In
> > > this case, you are interested in the activity of the Remove.java
> > > command
>
> class.
>
> > > You probably want to make a class that will be a pre-processor prior to
> > > Remove.java running. By doing so you can first look at the selected
>
> nodes,
>
> > > see if any are Samplers, and call the methods you want to call.
> > >
> > > Also, it seems like you could use this mechanism for creation of the
> > > Sampler as well and avoid having to change Sampler code at all. Just
>
> make
>
> > > your new action class responsible for registering and unregistering
> > > Samplers with your special listener.
> > >
> > > This is new to 1.9 and not available in 1.8.1.
> > >
> > > -Mike
> > >
> > > On 15 May 2003 at 12:17, David Glick wrote:
> > > > Hi,
> > > >
> > > > I'm designing JMeter extensions to support my client's execution
> > >
> > > environment,
> > >
> > > > and one of the capabilities that I'm building is for each sampler to
> > > > register with a global listener so that the listener can query the
> > > > sampler for specific properties at a later time. In order to do
> > > > this, the sampler invokes a static register() method on the listener
> > > > when it is instantiated. Now I need the sampler to invoke the
> > > > unregister() method when it is
> > >
> > > removed
> > >
> > > > from the tree. I'm thinking about overriding the setNode() method in
> > > > AbstractJMeterGuiComponent and adding a tree listener that can
>
> detect
>
> > > when
> > >
> > > > the sampler is removed.
> > > >
> > > > Is this the best way to detect removal, or is there an easier way to
> > > > do so?
> > > >
> > > >
> > > > Thanks for any help,
> > > >
> > > > David Glick
> > > > Transmit Consulting, Inc
> > > > 619-475-4052
> > > > dglick@transmitconsulting.com
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> >
> > --
> > David Glick
> > Transmit Consulting, Inc
> > 619-475-4052
> > dglick@transmitconsulting.com
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
--
David Glick
Transmit Consulting, Inc
619-475-4052
dglick@transmitconsulting.com
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
Re: Detecting removal of a sampler
Posted by ms...@apache.org.
In that case, you might have an easier time modifying Remove.java directly.
This will also make migration easier as you can make your own class that
does the work you need, and make a one line addition to Remove.java that
calls your class. Then, in the future, your class registers to receive events
instead of this direct call.
Similarly, you can modify Load.java and AddToTree.java to detect when
Samplers are added.
I highly recommend inserting your code at these points instead of in the tree
listener. These classes are simpler, and much more decoupled from the rest
of JMeter - should make your job easier.
-Mike
On 15 May 2003 at 13:02, David Glick wrote:
> Thanks, Mike. Unfortunately, I'm stuck with 1.8.1 for this iteration and
> won't be looking at migrating in the near future. Given this, is there any
> other implementation I should be looking at, or would you recommend I
move
> forward with the tree listener?
>
> David
>
>
> On Thursday 15 May 2003 12:38 pm, mstover1@apache.org wrote:
> > Actually, there is a simpler solution, I think. You can register with
> > ActionRouter to be a pre or post processor for any action class. In this
> > case, you are interested in the activity of the Remove.java command
class.
> > You probably want to make a class that will be a pre-processor prior to
> > Remove.java running. By doing so you can first look at the selected
nodes,
> > see if any are Samplers, and call the methods you want to call.
> >
> > Also, it seems like you could use this mechanism for creation of the
> > Sampler as well and avoid having to change Sampler code at all. Just
make
> > your new action class responsible for registering and unregistering
> > Samplers with your special listener.
> >
> > This is new to 1.9 and not available in 1.8.1.
> >
> > -Mike
> >
> > On 15 May 2003 at 12:17, David Glick wrote:
> > > Hi,
> > >
> > > I'm designing JMeter extensions to support my client's execution
> >
> > environment,
> >
> > > and one of the capabilities that I'm building is for each sampler to
> > > register with a global listener so that the listener can query the
> > > sampler for specific properties at a later time. In order to do this,
> > > the sampler invokes a static register() method on the listener when it is
> > > instantiated. Now I need the sampler to invoke the unregister() method
> > > when it is
> >
> > removed
> >
> > > from the tree. I'm thinking about overriding the setNode() method in
> > > AbstractJMeterGuiComponent and adding a tree listener that can
detect
> >
> > when
> >
> > > the sampler is removed.
> > >
> > > Is this the best way to detect removal, or is there an easier way to do
> > > so?
> > >
> > >
> > > Thanks for any help,
> > >
> > > David Glick
> > > Transmit Consulting, Inc
> > > 619-475-4052
> > > dglick@transmitconsulting.com
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
>
> --
> David Glick
> Transmit Consulting, Inc
> 619-475-4052
> dglick@transmitconsulting.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
>
--
Michael Stover
mstover1@apache.org
Yahoo IM: mstover_ya
ICQ: 152975688
AIM: mstover777
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
Re: Detecting removal of a sampler
Posted by David Glick <dg...@cox.net>.
Thanks, Mike. Unfortunately, I'm stuck with 1.8.1 for this iteration and
won't be looking at migrating in the near future. Given this, is there any
other implementation I should be looking at, or would you recommend I move
forward with the tree listener?
David
On Thursday 15 May 2003 12:38 pm, mstover1@apache.org wrote:
> Actually, there is a simpler solution, I think. You can register with
> ActionRouter to be a pre or post processor for any action class. In this
> case, you are interested in the activity of the Remove.java command class.
> You probably want to make a class that will be a pre-processor prior to
> Remove.java running. By doing so you can first look at the selected nodes,
> see if any are Samplers, and call the methods you want to call.
>
> Also, it seems like you could use this mechanism for creation of the
> Sampler as well and avoid having to change Sampler code at all. Just make
> your new action class responsible for registering and unregistering
> Samplers with your special listener.
>
> This is new to 1.9 and not available in 1.8.1.
>
> -Mike
>
> On 15 May 2003 at 12:17, David Glick wrote:
> > Hi,
> >
> > I'm designing JMeter extensions to support my client's execution
>
> environment,
>
> > and one of the capabilities that I'm building is for each sampler to
> > register with a global listener so that the listener can query the
> > sampler for specific properties at a later time. In order to do this,
> > the sampler invokes a static register() method on the listener when it is
> > instantiated. Now I need the sampler to invoke the unregister() method
> > when it is
>
> removed
>
> > from the tree. I'm thinking about overriding the setNode() method in
> > AbstractJMeterGuiComponent and adding a tree listener that can detect
>
> when
>
> > the sampler is removed.
> >
> > Is this the best way to detect removal, or is there an easier way to do
> > so?
> >
> >
> > Thanks for any help,
> >
> > David Glick
> > Transmit Consulting, Inc
> > 619-475-4052
> > dglick@transmitconsulting.com
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
--
David Glick
Transmit Consulting, Inc
619-475-4052
dglick@transmitconsulting.com
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
Re: Detecting removal of a sampler
Posted by ms...@apache.org.
Actually, there is a simpler solution, I think. You can register with
ActionRouter to be a pre or post processor for any action class. In this case,
you are interested in the activity of the Remove.java command class. You
probably want to make a class that will be a pre-processor prior to
Remove.java running. By doing so you can first look at the selected nodes,
see if any are Samplers, and call the methods you want to call.
Also, it seems like you could use this mechanism for creation of the Sampler
as well and avoid having to change Sampler code at all. Just make your new
action class responsible for registering and unregistering Samplers with your
special listener.
This is new to 1.9 and not available in 1.8.1.
-Mike
On 15 May 2003 at 12:17, David Glick wrote:
> Hi,
>
> I'm designing JMeter extensions to support my client's execution
environment,
> and one of the capabilities that I'm building is for each sampler to register
> with a global listener so that the listener can query the sampler for
> specific properties at a later time. In order to do this, the sampler
> invokes a static register() method on the listener when it is instantiated.
> Now I need the sampler to invoke the unregister() method when it is
removed
> from the tree. I'm thinking about overriding the setNode() method in
> AbstractJMeterGuiComponent and adding a tree listener that can detect
when
> the sampler is removed.
>
> Is this the best way to detect removal, or is there an easier way to do so?
>
>
> Thanks for any help,
>
> David Glick
> Transmit Consulting, Inc
> 619-475-4052
> dglick@transmitconsulting.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
>
--
Michael Stover
mstover1@apache.org
Yahoo IM: mstover_ya
ICQ: 152975688
AIM: mstover777
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org