is muleContext.getRegistry() the right place for application wide runtime info?

[richrem]

Mule gurus,

I was poking around the docs for some hints/ideas/best practices for storing application wide runtime info.  I ran across the Registry object, available from a MuleContext instance.  Is this a good place to store runtime information that is needed by components or other architectural elements - e.g. routers?  Or, is there another place where I could/should store application wide info that may change over time and is fairly easily accessible to various components in the system?

Also, are there any gotchas I should be aware of with the Registry, if that is the right place to put stuff?

FYI, we're using Mule 2.0.1 currently.

TIA,
Rich

[ddossot]

Have you considered using Spring managed beans an inject them into your various components?

D.

On Thu, Aug 7, 2008 at 1:54 PM, richrem <rich@...> wrote:

Mule gurus,

I was poking around the docs for some hints/ideas/best practices for storing
application wide runtime info.  I ran across the Registry object, available
from a MuleContext instance.  Is this a good place to store runtime
information that is needed by components or other architectural elements -
e.g. routers?  Or, is there another place where I could/should store
application wide info that may change over time and is fairly easily
accessible to various components in the system?

Also, are there any gotchas I should be aware of with the Registry, if that
is the right place to put stuff?

FYI, we're using Mule 2.0.1 currently.

TIA,
Rich

--
View this message in context: http://www.nabble.com/is-muleContext.getRegistry%28%29-the-right-place-for-application-wide-runtime-info--tp18879443p18879443.html
Sent from the Mule - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email

[richrem]

Thanks for the response, but I don't think this would work for the underlying purpose, which requires learning of changes that occur during runtime.  I need to store cached information that is updated periodically when changes occur and make it available to the security system.  The other components need to reference this cached information at runtime as well.

It's possible I'm missing something very obvious, though...

Please see my other post, which you can find at [http://www.nabble.com/How-to-handle-dynamic-ACL-type-updates--tt18879529.html] and let me know if this changes your thinking any.

Cheers,
Rich

ddossot wrote:

Have you considered using Spring managed beans an inject them into your
various components?

D.

[Andrew Perepelytsya]

Wouldn't something very obvious be a simple static field reference in some holder class?

HTH,
Andrew

[richrem]

Thanks for the response.  This would work, and suggests to me that Mule does not have anything equivalent to the web application storage maps provided for various scopes - e.g. application, session, request.  I was hoping to use something that might already be designed for this purpose.

Does anyone else think it would be a good idea to design this type of thing into Mule?  I could see sharing information across the entire application as well as in a scope larger than a simple synchronous request - e.g. choreographed and/or asynch reply services.

Rich

Andrew Perepelytsya wrote:

Wouldn't something very obvious be a simple static field reference in some
holder class?

HTH,
Andrew

[Andrew Perepelytsya]

Mule does have those, the session, but it's not really a good fit for your use case.

Andrew

On Sat, Aug 9, 2008 at 1:11 AM, richrem <rich@...> wrote:

Thanks for the response.  This would work, and suggests to me that Mule does
not have anything equivalent to the web application storage maps provided
for various scopes - e.g. application, session, request.  I was hoping to
use something that might already be designed for this purpose.

Does anyone else think it would be a good idea to design this type of thing
into Mule?  I could see sharing information across the entire application as
well as in a scope larger than a simple synchronous request - e.g.
choreographed and/or asynch reply services.

Rich

Andrew Perepelytsya wrote:
>
> Wouldn't something very obvious be a simple static field reference in some
> holder class?
>
> HTH,
> Andrew
>
>

--
View this message in context: http://www.nabble.com/is-muleContext.getRegistry%28%29-the-right-place-for-application-wide-runtime-info--tp18879443p18902303.html

Sent from the Mule - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email

[Dimitar Dimitrov]

Andrew Perepelytsya wrote:

Mule does have those, the session, but it's not really a good fit for your
use case.

Andrew

Hi Andrew, is there any documentation about the session use cases in Mule?

I could never really figure what is the session scope and how is it mapped to the different transports (JMS, HTTP, File)

Regarding the original topic - one can use Spring custom scopes to swap beans at runtime.

http://static.springframework.org/spring/docs/2.5.x/reference/beans.html#beans-factory-scopes-other-injection

http://static.springframework.org/spring/docs/2.5.x/reference/beans.html#beans-factory-scopes-custom

[Travis Carlson-2]

Sorry, just catching up on this thread 2 months later.

You could use the Registry for this, yes.  Anywhere you have the
MuleContext available (within most Mule entities), you can get a handle
to the Registry.  So to store an object:

muleContext.getRegistry().registerObject("foo", new MyFoo());

Then someplace else you could update the object:

Foo foo = (Foo) muleContext.getRegistry().lookupObject("foo");
foo.setBarVal(25);
// Replace the previous object
muleContext.getRegistry().registerObject("foo");

etc...  

Travis

On Thu, 2008-08-07 at 13:54 -0700, richrem wrote:

> Mule gurus,
>
> I was poking around the docs for some hints/ideas/best practices for storing
> application wide runtime info.  I ran across the Registry object, available
> from a MuleContext instance.  Is this a good place to store runtime
> information that is needed by components or other architectural elements -
> e.g. routers?  Or, is there another place where I could/should store
> application wide info that may change over time and is fairly easily
> accessible to various components in the system?
>
> Also, are there any gotchas I should be aware of with the Registry, if that
> is the right place to put stuff?
>
> FYI, we're using Mule 2.0.1 currently.
>
> TIA,
> Rich
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email