Menu
▾
▴
jboss-dev-forums
|
From: <bil...@jb...> - 2006-06-20 15:37:01
|
Per the private email. An SPI is a distraction not an abstraction. JAR JAR is not an option either as we want users to be able to extend EJB Timers (or whatever) with quartz APIs. We also want users to be able to use the Message Infow RAR in their applications as well. So, we (Gavin and I) don't see Quartz as just an implementation, but also an extension to any timer service out there. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3952029#3952029 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3952029 |
|
From: <sco...@jb...> - 2006-06-20 15:49:13
|
There has been zero proof that quartz does adequately address the layering of other server aspects such as security, transactions, persistence as well as other candidate javaee specs to be able to make this statement. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3952044#3952044 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3952044 |
|
From: <wes...@jb...> - 2006-06-20 16:00:04
|
Agreed. In many ways, Quartz introduces issues that the J2EE Timer JSR was 'supposed' to fix. http://www.jcp.org/en/jsr/detail?id=236 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. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3952049#3952049 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3952049 |
|
From: <sco...@jb...> - 2006-06-20 16:17:14
|
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. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3952059#3952059 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3952059 |
|
From: wolfc <do-...@jb...> - 2006-06-21 13:34:28
|
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. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3952380#3952380 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3952380 |
|
From: <dim...@jb...> - 2006-06-21 13:52:25
|
I think what Scott talks about is an API than can cover functionality needed by other timer related subsystems, too (copying from the beginning of this thread) ** jPBM timers ** EJB/EJB3 timers ** jmx timers ** jmx timer service ** org.jboss.util.* custom timers View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3952383#3952383 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3952383 |
|
From: <wes...@jb...> - 2006-06-21 13:55:35
|
Correct. 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. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3952384#3952384 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3952384 |
|
From: wolfc <do-...@jb...> - 2006-06-23 14:11:03
|
But how will JSR-236 differ from the TimerManager specification 1.1? Do you know? http://ftpna2.bea.com/pub/downloads/commonj/Commonj-TimerAndWorkManager-Specification-v1.1.pdf 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? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953002#3953002 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953002 |
|
From: <wes...@jb...> - 2006-06-23 14:21:01
|
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 ;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953005#3953005 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953005 |
|
From: <wes...@jb...> - 2006-06-24 05:21:21
|
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. Thoughts? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953166#3953166 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953166 |
|
From: <wes...@jb...> - 2006-06-24 05:23:55
|
Or...we use the connector project and keep the timer stuff close to the JCA timer defintions...another alternative. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953167#3953167 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953167 |
|
From: <dim...@jb...> - 2006-06-24 08:54:44
|
It could start as a seperate module for sure. Whether it can evolve into an independent project, I think it's a bit too early to discuss (let's build something first :) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953176#3953176 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953176 |
|
From: <sco...@jb...> - 2006-06-24 10:43:44
|
I would leave it in the jca/connector project for now. Its certainly not an addition to common and the existing jboss-common.jar. We can refactor this into a separate project as needed when we have moved jboss-head over to svn. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953193#3953193 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953193 |
|
From: <wes...@jb...> - 2006-06-24 15:27:03
|
Dimitris wrote anonymous wrote : | 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. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953212#3953212 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953212 |
|
From: <wes...@jb...> - 2006-06-24 15:29:27
|
Scott Stark wrote: anonymous 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. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953213#3953213 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953213 |
|
From: <wes...@jb...> - 2006-06-26 17:06:58
|
The first pass of this has been added to the connector project under org.jboss.resource.spi.timer As well as org.jboss.resource.timer 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. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953497#3953497 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953497 |
|
From: wolfc <do-...@jb...> - 2006-06-26 17:51:44
|
Looking good! 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?). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953506#3953506 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953506 |
|
From: <wes...@jb...> - 2006-06-26 18:00:41
|
Right I agree, I think it makes the most sense to integrate Quartz straightaway. In fact, I believe this was always the intent at least as far as implementation was concerned. anonymous wrote : | I would like to ask for a timer manager which isn't dependant on JMX (for the embedded stack). | Yeah, I went back and forth on this one. The idea is that the version that exists in connector today is JMX dependent, however, in the jca project (not currently on HEAD) I have added timer annotations, and was planning on adding a TimerManager that was embeddable, or at the very least, didn't require JBossAS to run. I am finishing up touches on this and will check this in as soon as I can. I agree with the spi integration. I really appreciate you looking at this so quickly. Thanks! View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953513#3953513 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953513 |
|
From: <sco...@jb...> - 2006-06-26 19:23:41
|
Some feedback. 1. Is the TimerPropertyKey key needed as a wrapper? Currently it does not even properly wrap its Object key, and even if it did provide an equals/hashCode it would seem to be an unnecessary wrapper around the real key. 2. Being able to access the TimerData from the Timer interface in the listener callback seems like something we need to support. In the case of both ejb and jmx timers there is a user data notion that can be passed in when the timer is created and retrieved from the timer callback object. 3. What is the usecase for the distinct TimerListener, CancelTimerListener, and StopTimerListener? Wouldn't these be better combined into a single interface with either all three callbacks, or a single callback with a state enum? 4. In terms of the most general timer scheduling method on the TimerManager, the method taking the TimerExcecutionContext would seem to be the place for extended scheduling semantics. Currently it has a period and data notion. I'm thinking we need more of a timer calendar notion to deal with non-trivial timer scheduling ala cron. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953534#3953534 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953534 |
|
From: <wes...@jb...> - 2006-06-26 19:28:12
|
All good suggestions. I will incorporate. Again, this was a 'rough' draft just to get people talking about this stuff. Thanks. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953535#3953535 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953535 |
|
From: <wes...@jb...> - 2006-06-26 19:38:10
|
Further, I agree with anonymous wrote : | | 3. What is the usecase for the distinct TimerListener, CancelTimerListener, and StopTimerListener? Wouldn't these be better combined into a single interface with either all three callbacks, or a single callback with a state enum? | | This is the way it was written in the spec, but I think this should be changed to a single interface including all three callbacks. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953536#3953536 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953536 |
|
From: <wes...@jb...> - 2006-07-01 21:44:10
|
I am moving what is currently in the connector project to the jboss-jca project. This is not in HEAD by default so you will have to cd src-dir cvs co jboss-jca Seems to be a better place for it. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3954857#3954857 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3954857 |
Thanks for helping keep SourceForge clean.
X