This content has been marked as final.
Show 9 replies
-
1. Re: Controller's execution env
adrian.brock Aug 4, 2008 9:21 AM (in response to alesj)http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/Executor.html
by "injection" on to the kernel.
The default implementation should just be to execute() on the same thread.
The main issue is introducing some kind of security as to who can change
the executor implementation. -
2. Re: Controller's execution env
adrian.brock Aug 4, 2008 9:33 AM (in response to alesj)"adrian@jboss.org" wrote:
http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/Executor.html
by "injection" on to the kernel.
I meant controller. ;-) -
3. Re: Controller's execution env
alesj Aug 4, 2008 9:51 AM (in response to alesj)"adrian@jboss.org" wrote:
"adrian@jboss.org" wrote:
http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/Executor.html
by "injection" on to the kernel.
I meant controller. ;-)
Do we even need a getExecutor method?public interface Controller extends JBossInterface { ... /** * Get the executor * * @return the executor */ Executor getExecutor(); /** * Set the executor * * @param executor the executor */ void setExecutor(Executor executor); }
Allowing some other MC code to re-use Controller's execution env? -
4. Re: Controller's execution env
adrian.brock Aug 4, 2008 9:56 AM (in response to alesj)"alesj" wrote:
"adrian@jboss.org" wrote:
"adrian@jboss.org" wrote:
http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/Executor.html
by "injection" on to the kernel.
I meant controller. ;-)
Do we even need a getExecutor method?public interface Controller extends JBossInterface { ... /** * Get the executor * * @return the executor */ Executor getExecutor(); /** * Set the executor * * @param executor the executor */ void setExecutor(Executor executor); }
Allowing some other MC code to re-use Controller's execution env?
I'd include the getter, subject to the same security check as invoking the setter.
Otherwise somebody could do:@Inject(...from the controller...) public void setExectuor(Executor ex) { // Fill the queue with tasks that don't end, a denial of service attack while(true) { ex.execute(new Runnable() { public void run() { // sleep forever } } }
-
5. Re: Controller's execution env
alesj Aug 4, 2008 10:05 AM (in response to alesj)"adrian@jboss.org" wrote:
@Inject(...from the controller...) public void setExectuor(Executor ex)
Controller will inject itself with its Executor? :-)
Currently we don't handle MC core objects
as MC's contexts, only as KernelRegistryEntry.
But looking at its impl, BeanKernelRegistryEntry,
looks like we might even inject something into the entry
via some factory. -
6. Re: Controller's execution env
adrian.brock Aug 4, 2008 10:16 AM (in response to alesj)You just use the kernel as a factory to create a seperate context
that references the controller. Then you change whatever parameters you like
(subject to security).<bean name="ReferenceToController"> <constructor> <factory bean="jboss.kernel:service=Kernel" method="getController"/> </constructor> <property name="executor"><inject bean="CustomExecutor"/></property> ... </bean>
That's why I said that it is probably not required to be on the interface,
except that it would make programmatic config easier (e.g. testing)
if you don't have to cast/know the implementation detail. -
7. Re: Controller's execution env
alesj Aug 4, 2008 10:27 AM (in response to alesj)"adrian@jboss.org" wrote:
You just use the kernel as a factory to create a seperate context
that references the controller. Then you change whatever parameters you like
(subject to security).<bean name="ReferenceToController"> <constructor> <factory bean="jboss.kernel:service=Kernel" method="getController"/> </constructor> <property name="executor"><inject bean="CustomExecutor"/></property> ... </bean>
That's what I said:"alesj" wrote:
looks like we might even inject something into the entry
via some factory
;-)
But this wasn't doable until we added BeanKernelRegistryEntry and
actually made it implement InvokeDispatchContext."adrian@jboss.org" wrote:
That's why I said that it is probably not required to be on the interface,
except that it would make programmatic config easier (e.g. testing)
if you don't have to cast/know the implementation detail.
I'll leave it on the interface - as you said, programmatic usage is much simpler - while it also makes sense as a spi contract.
e.g. Controller has an execution environment ~ executor -
8. Re: Controller's execution env
alesj Aug 4, 2008 10:32 AM (in response to alesj)"alesj" wrote:
I'll leave it on the interface - as you said, programmatic usage is much simpler - while it also makes sense as a spi contract.
e.g. Controller has an execution environment ~ executor
Or perhaps we could move these/** * Whether the controller is shutdown * * @return true when shutdown */ boolean isShutdown(); /** * Shutdown the controller */ void shutdown(); /** * Get the executor * * @return the executor */ Executor getExecutor(); /** * Set the executor * * @param executor the executor */ void setExecutor(Executor executor);
methods into sub interface.
As they seem to fit the same way we did with MainDeployer and DeployerClient. -
9. Re: Controller's execution env
alesj Aug 4, 2008 10:46 AM (in response to alesj)"alesj" wrote:
"alesj" wrote:
I'll leave it on the interface - as you said, programmatic usage is much simpler - while it also makes sense as a spi contract.
e.g. Controller has an execution environment ~ executor
Or perhaps we could move these
methods into sub interface.
As they seem to fit the same way we did with MainDeployer and DeployerClient.
Hmmm, looking it this way.
It now feels more as an impl detail. :-)