Configuration is done via system property
org.jboss.ejb3.timerservice.factory, it defaults to
org.jboss.ejb3.timer.jboss.JBossTimerServiceFactory. Which is a factory
around jboss.ejb:service=EJBTimerService (the ejb2 timer impl).
So it's fine to remove the descriptor.
Carlo
Dimitris Andreadis wrote:
This is fine for a mid-term target, my question is what to do now
with
the existing quartz based prototype. If it's not used, we shouldn't
instantiate it by default. Either remove the descriptor or move it to
docs/examples.
And the other question still hold: where EJB3 gets its timer service
configured? I can't find a trace in the deployment descriptors of the
ejb3.deployer so my guess is that is falling back to ejb2 timer impl.
Carlo de Wolf wrote:
>
https://jira.jboss.org/jira/browse/EJBTHREE-1697
>
> The idea is to have one timer service factory spi and create a couple
> of implementations on top.
> 1. a light variant that does no persistency
> 2. a variant with persistence
> 3. a clustered variant
>
> Note that each implementation might depend on the other, if such a
> thing leads to efficient code reuse.
>
> org.jboss.ejb3.timerservice.TimerServiceFactory forms the starting
> point for the SPI.
>
> Carlo
>
> Dimitris Andreadis wrote:
>>
https://jira.jboss.org/jira/browse/JBAS-6304
>>
>> Can we remove deploy/ejb3-timer-service.xml ?
>>
>> I understand this service
>>
>> a) creates 10 idle quartz threads
>> b) have trouble configuring different DBs
>> c) is not actually used in the existing configs
>> d) it's going to be dropped anyway
>>
>> BTW, where EJB3 gets its timer service configured? I can't find a
>> trace in the deployment descriptors of the ejb3.deployer so my guess
>> is that is falling back to ejb2 timer impl.
>>
>> Cheers
>> /D
>>
>> _______________________________________________
>> jboss-development mailing list
>> jboss-development(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/jboss-development
>