comonents and spring beans

View: New views
10 Messages — Rating Filter:   Alert me  

comonents and spring beans

by Mike Carr-6 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Using Spring Beans as Service Components - http://www.mulesoft.org/display/MULE2USER/Using+Spring+Beans+as+Service+Components

States "We now have beans called restaurantWaiter and kitchenService that will be created by Spring. Notice the resturantWaiter bean scope is set to prototype (by default, all beans in Spring are singletons unless specified otherwise). This is important because Mule will pool your components, and telling Spring not to create a singleton ensures that each pooled instance will be a unique instance.";

Does this imply that MULE will always pool components?

Lets' say I want to create a pool...

What if I have another bean that was used resturantWaiter, presumably I'd have to make that prototype as well?

If I had another bean that used restaurantWaiter outside of MULE should I create a second bean e.g. restaurantWaiterSingleton to serve that; so I have a restaurantWaiterPrototype and a restaurantWaiterSingleton?

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

    http://xircles.codehaus.org/manage_email



Re: comonents and spring beans

by Dirk Olmes :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

David O'Brien wrote:
> States "We now have beans called restaurantWaiter and kitchenService
> that will be created by Spring. Notice the resturantWaiter bean scope
> is set to prototype (by default, all beans in Spring are singletons
> unless specified otherwise). This is important because Mule will pool
> your components, and telling Spring not to create a singleton ensures
> that each pooled instance will be a unique instance.";
>
> Does this imply that MULE will always pool components?

Yes.

> Lets' say I want to create a pool...
>
> What if I have another bean that was used resturantWaiter, presumably
> I'd have to make that prototype as well?

Makes the most sense. With Spring's default scope (singleton) you'll end
up with a pool full of the same singleton. See
http://www.mulesoft.org/jira/browse/MULE-4514 for some discussion around
this topic.

-dirk

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

    http://xircles.codehaus.org/manage_email



Re: comonents and spring beans

by Mike Carr-6 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Mule In Action seems to give the opposite impression 6.3.3 Handling workload with a pool

It suggests that components are not pooled by default.

I'm assuming you are correct and the book is wrong.

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

    http://xircles.codehaus.org/manage_email



Re: comonents and spring beans

by David Dossot-3 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

> States "We now have beans called restaurantWaiter and kitchenService
> that will be created by Spring. Notice the resturantWaiter bean scope
> is set to prototype (by default, all beans in Spring are singletons
> unless specified otherwise). This is important because Mule will pool
> your components, and telling Spring not to create a singleton ensures
> that each pooled instance will be a unique instance.";
>
> Does this imply that MULE will always pool components?

Yes.

I'm really surprised by this response.

I thought you have to do this to get Spring prototype beans to be pooled:
  <pooled-component>
<spring-object bean="restaurantWaiter"/>
</pooled-component>
Are you saying that this:
  <component>
<spring-object bean="creditAgencyEJB" />
</component>
will also pool the Spring prototype instances?

If that's the case, how do you control the pool size?

Thanks for the precision. We will issue a book erratum if accordingly.

Cheers,
D.


Re: comonents and spring beans

by Daniel Feist :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

> States "We now have beans called restaurantWaiter and kitchenService
> that will be created by Spring. Notice the resturantWaiter bean scope
> is set to prototype (by default, all beans in Spring are singletons
> unless specified otherwise). This is important because Mule will pool
> your components, and telling Spring not to create a singleton ensures
> that each pooled instance will be a unique instance.";
>
> Does this imply that MULE will always pool components?

Yes.

I'm really surprised by this response.

Me too!  Back in Mule 1.3 and 1.4 Mule used to pool your components by default unless you turned off that functionality, but in 2.0->  it is a bit more explicit and two different xml elements are used.

<component> = no-pooling
<pooled-component> = pooling

My guess is that the documentation you referenced was updated from 1.4 documentation and that slipped through.


sorry for the confusion,

Dan

Re: comonents and spring beans

by Steve A. :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Just to clarify, is this the case for <scripting:component> too?

Steve

Dirk Olmes wrote:
David O'Brien wrote:
> Does this imply that MULE will always pool components?

Yes.

Re: comonents and spring beans

by Steve A. :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Just to clarify, is this the case for too? Steve
Dirk Olmes wrote:
David O'Brien wrote: > Does this imply that MULE will always pool components? Yes.

Re: comonents and spring beans

by Steve A. :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

I'm not sure what happened with my previous reply, but please disregard.

However, what I meant to ask was are scripting components pooled or not by default?

Steve
Dirk Olmes wrote:
> Does this imply that MULE will always pool components?

Yes.

Re: comonents and spring beans

by Steve A. :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

So, was this a stupid question or hard question? :-)

Steve

Just to clarify, is this the case for <scripting:component> too?

Steve

Dirk Olmes wrote:
David O'Brien wrote:
> Does this imply that MULE will always pool components?

Yes.


Re: comonents and spring beans

by antoine.borg :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

I've never done this with a scripting component but my understanding is
that it's still a component so the answer would be "yes it is"

My 2c worth.

A

Steve A. wrote:

> So, was this a stupid question or hard question? :-)
>
> Steve
>
> Steve A. wrote:
>  
>> Just to clarify, is this the case for <scripting:component> too?
>>
>> Steve
>>
>>
>> Dirk Olmes wrote:
>>    
>>> David O'Brien wrote:
>>>      
>>>> Does this imply that MULE will always pool components?
>>>>        
>>> Yes.
>>>
>>>
>>>      
>>    
>
>  
--

Antoine Borg , Director of Services | Tel: +32 28 504 696
ricston Ltd., BP 2, 1180 Uccle, Brussels, BELGIUM
See our full schedule of Mule and Android courses online: Ricston Course
Schedules <http://www.ricston.com/courses/schedules>
email: antoine.borg@... <mailto:antoine.borg@...> |
twitter: twitter.com/antoinericston <http://www.twitter.com/antoinericston>
----------
* Disclaimer* - This email and any files transmitted with it are
confidential and contain privileged or copyright information. You must
not present this message to another party without first gaining
permission from the sender. If you are not the intended recipient you
must not copy, distribute or use this email or the information contained
in it for any purpose other than to notify us. If you have received this
message in error, please notify the sender immediately and delete this
email from your system. We do not guarantee that this material is free
from viruses or any other defects although due care has been taken to
minimise the risk. Any views stated in this communication are those of
the actual sender and not necessarily those of Ricston Ltd. or its
subsidiaries.


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

    http://xircles.codehaus.org/manage_email