Agreed. In many ways, Quartz introduces issues that the J2EE Timer JSR was 'supposed' to fix.
However, just because this is bogged down doesn't mean we can't move towards unifying this in 5.0. We can always retrofit if required when and if the spec ever comes up for air.
As Mark Little correctly points out in the ESB efforts, the SPI is defined by the existing requirements. Any existing APIs are mappings onto this. Existing APIs would simply be inputs as SPI requirements.
The discussion on the need for a timer SPI is over in my view; its needed. I'm fine with using quartz as the initial implementation provided it meets the SPI requirements. Choosing quartz as the timer SPI because we are lazy bastards and nothing else better exists is silly.
I'm currently trying to integrate Quartz into the EJB3 stack. I'm taking care that no Quartz classes are needed on the runtime classpath of clients.
The API towards the bean container is the EJB Timer Service API as defined in the EJB3 specs, with some helper classes in org.jboss.ejb3.timerservice (like TimerServiceFactory). I also don't want any Quartz classes exposed to a bean developer at compile time. But the extra functionality provided by Quartz should be exposed to bean developers most likely with a JBossTimerService interface which extends javax.ejb.TimerService.
I hope this is enough else someone needs to give me requirements of JBoss SPI's. I have no clue what you mean by jarjar.
Unfortunately, there is a JSR (236) for this, but it is bogged down in legality. As a result, we can't wait so the idea is to create a timer API that is applicable, as you said Dimitris, to all applicable subsystems. This would effectively become the spi Timer API for JBoss replacing all the 'one-offs' we have right now.
But how will JSR-236 differ from the TimerManager specification 1.1? Do you know?
In that spec I'm missing stuff on security and transactions to name some, or am I missing a beat here?
Will your Timer SPI be usable in the E-EJB3 environment?
Right. I am not using the spec letter for letter. Just adapting the 'spirit' of what has already been done. Security, transactions etc, etc will be added. And yes, it will work with EJB3. The point of it is to have it be project neutral..a Timer spi for the entire product.
Suggestions or specific needs/requirements are always welcome ;-)
The structure of the timer spi would seem to necessitate a new project, or at the very least rethinking putting this in common. I have started the spi, but I would like to also leverage AOP and the MC for transactions, security etc, etc. Further, I would like to leverage annotations for the listener interfaces.
I have no problems with the spi going into common, but the actually implementation, annotations etc, etc should probably go somewhere else. Further, we could take this chance to yank everything out timer related, create it's own project and integrate it as a core service in AS.
I think it's a bit too early to discuss (let's build something first :)
Actually, I am building something, or at the very least setting up the core structure. What I was concerned about is doing something, having it in the wrong place, moving it, breaking stuff etc, etc. Seems there has been a lot of this type of stuff lately, and I wanted to get it right up front so as to avoid agony later on.
Scott Stark wrote:
Its certainly not an addition to common and the existing jboss-common.jar
Ok, however, when we talked about this before, I thought we had said common (this was in email), but I could have misread this. Thanks for the clarification. I was also thinking about the SVN move and how this would effect something like this, so thanks again.
The first pass of this has been added to the connector project under
As well as
After looking at the working draft (the commonj stuff) there are some differences in the draft and Quartz (this is understandable). Quartz has the concept of a 'job', basically an executable piece of code that gets executed in response to a trigger (basically a timer). The working draft assumes that listeners will respond to timer expiration as well as a set of lifecycle events (ie stop, cancel etc).
The draft is concerned with timers in the managed scenario where it is assumed that the timer will not execute in a seperate thread, will not be persistent, not have transaction/security contexts etc, etc.
The mapping of the spi and the underlying implementations EJB3/JMX will have to make up for this discrepancy. This is where we will deviate from the draft.
We could try to get Quartz under the hood? Then we would have a working prototype within no time (so to speak).
I would like to ask for a timer manager which isn't dependant on JMX (for the embedded stack).
I've committed a timer service implementation in org.jboss.ejb3.timerservice, you can rip anything from there to integrate Quartz.
After that we can refactor org.jboss.ejb3.timerservice to the timer spi (can we have 1 timer manager per bean container?).