> -----Message d'origine-----
> De: Andreas Schaefer [mailto:[EMAIL PROTECTED]]
> I will add now the feature to the Scheduler to
> call a MBean instead of a Schedulable class.
> This would need two new attributes:
> - setSchedulableMBean: JMX MBean name
> - setSchedulableMBeanMethod: method name and what attributes
> are to pass
> which can be:
> - 'Notification' the notification from the Timer
> - 'Date' date of the call
> - 'Repetitions' number of the remaining repetitions
> - 'SchedulerName' MBean name of the Scheduler called
> - any Datatype like 'java.lang.String' where a NULL will
> be passed to (which will not work with basic data types)
>
> Any other suggestions or remarks ?
this seems really cool. The Scheduler is an important
tool in an enterprise app... crontab often does the job, but
running inside jboss is an advantage
One need I had was to call some of my own application
EJB from the scheduler. (this would make the application
less dependent on jboss, since an external crontab may call
an EJB method itself)
with your proposed architecture, one would only need
to design a MBean that respect the schdulable mbean
contract, and then should call a wellknown EJB.
here is a discussion about HOW in my opinion
an EJB should be called (what's your opinion on that?) :
short version:
I propose to support 2 kind of MBean to invoke an EJB periodicaly :
1- an MBean that calls a stateless session bean method.
- the most simple would be to declare a home/remote interface
globally, that the MBean could call, and the business
session bean could implement. moreover thing could be easily ported
to a n
-there should exists a parameters in the MBean
indicating wether to "queue", "ignore" or "invoke concurently"
notifications calls that ovelap.
2- an MBean that send a JMS message to a message bean.
- message content is not very important, so they will be either empty,
constant text (a CDATA ?)
or just contain the java.util.Date.toString of the notification
date.
- session factory and topic/destination will be found in JNDI
- if someone want to change the content,
either should he derive that MBean, or
use a session bean that does the job...
long version (arguments...):
the most simple would be to call a stateless EJB.
whether to reuse the same session bean or to create one
each time is a performance and reliability
(what if an EJB is undeployed meanwhile) issue.
another issue is how to behave if one call takes much time,
and if one call overlap another (overlap, queue, ignore)...
calling a stateful EJB could seems useful if one want
to parametrize the call... but deploying a new stateless
session bean with diffrent env-entry does the same and is simpler.
(so I think this is not usefull).
calling an entity bean could be done for two distinc reasons
- to parametrize the notification, with the same opinion as stateful session
(ei: not very usefull)
- to implement a kind of singleton and control concurent call to
the notification method... one could implement this control in the
stateless session bean, but as this is a common need, it would be
practical to ease that. however my opinion is that the best place to
do that is in the notification Mbean, or in the scheduler,
that should be configurable to forbide reentry...
calling a message bean through JMS could be a nice feature, because
message bean invokation are naturally queued, and supports
long operations. parameters is not really a problem since
there are no essential parameters to be transmited...
the mbean could refers to JNDI-stored JMS destinations and factory...
for most application sending an empty message to a dedicated message bean,
or sending a constant text message to a polyvalent message bean
would do the job...
sending the date could be useful in some rare cases, where the initial date
of notification is important, because calls may be queued for a long time...
but anyway if one want to generate complex JMS message
one won't avoid writing code, either derivating the MBean, or writing a
stateles session bean that send the JMS...
for session bean the question could be also wether to depend on a static
remote/home interface of to support dynamic calls...
if we wan our application to be easily portable to a classic
crontab of java thread system, the best would be to avoid
dynamic invocation which is not perfect on some J2EE system...
does it seems reasonable to you ?
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
