geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Genender <jgenen...@apache.org>
Subject Re: GBeans representing separately persistent data
Date Mon, 12 Jun 2006 01:14:04 GMT


Aaron Mulder wrote:
> Here's another way to think of it.  Quartz is a Job container, just
> like Tomcat is a Servlet container and OpenEJB is an EJB container.
> 

Correct, thus leave the container to manage its own configuration.
Tomcat does not create Servlet Gbeans, Filter GBeans, etc (although it
has been requested).  I surely would not want to get into the business
of making everything a GBean in the long run.  This has caused us
extreme pain when upgrading to new versions of the 3rd party
implementations (look at Tomcat clustering components...which were made
as GBeans...this has caused stress when there are changes to the Tomcat
API).

If I had my druthers and had to do the TC integration all over again, I
likely would have backed away from the GBeans (other than the container
for lifecycle and dependency management), as it has waged a number of
complaints from both developers and and corporate users, and my own
headaches in keeping up with the Tomcat APIs when we upgrade to new
versions.  Letting Tomcat use its own configuration files for what it
was developed would have made the integration a bit more seamless and
friendly to Tomcat users moving to Geronimo.


Jeff

> Thanks,
>    Aaron
> 
> On 6/11/06, Jeff Genender <jgenender@apache.org> wrote:
>>
>> Why would you want Jobs based GBeans?  This makes no sense to me.  Those
>> are innately Quartz objects in their own right. IMHO, everything does
>> not need to be a GBean...especially when working with 3rd party
>> components.  I am personally against Jobs being GBeans...
>>
>> I would leave every thing underneath Quartz as "native" Quartz as
>> possible.
>>
>> Just my .02.
>>
>> Jeff
>>
>> Aaron Mulder wrote:
>> > So I've been playing around with a Quartz integration plugin.  My
>> > first stab only supported an in-memory schedule, but Quartz also
>> > supports storing to a database.  Here's my issue with that.
>> >
>> > Right now I have a GBean representing a scheduled job.  When you start
>> > it, the job is scheduled.  When you stop it, the job is deleted.
>> > Therefore when you start the server, the scheduler is started and the
>> > deployed jobs are started, and I guess they're effectively persistent
>> > using config.xml as storage instead of using a DB.
>> >
>> > So let's say we let you store the job info to a database.  What
>> > happens to the job GBeans?  You can take down the server, delete all
>> > your jobs from config.xml, add some new jobs to the database, and
>> > start the server again.  So the GBeans can get totally out of sync
>> > with the data they represent.
>> >
>> > I guess what would be most appropriate for this case would be some
>> > kind of "transient GBean" that does not save to config.xml.  So when
>> > the scheduler starts it could create GBeans representing all the jobs,
>> > which you could use to manage it, but changes to the GBeans would only
>> > affect the Quartz database (not config.xml) and when you shut down
>> > they'd all go away.  Until next time you start up, and the scheduler
>> > would recreate all the job GBeans again.  What do you think?
>> >
>> > The alternative is to keep using GBeans as persistence, and just add
>> > GBeans to represent calendars and triggers, which are the other two
>> > fundamental types in Quartz.  That certainly seems like the more
>> > expedient path for now.
>> >
>> > Thanks,
>> >     Aaron
>>

Mime
View raw message