Re: Scheduler Service to support/expose native Quartz
Hi JB, for now, I do not see other way, for me, than to go forward with my work. As I am already weeks behind schedule regarding project schedule. My main requirement ( right now ) is to migrate existing Quartz job classes ( this is about 600-700 classes , and with this my change to Scheduler - I will not really have any work on the Job class ), I have to migrate from Quartz 1.8.x to 2.2.x plus remove Spring Framework ( legacy spring ) + Hibernate to JPA, etc. so less change - better for me. With that said. I am missing what is "main guide line" for the Karaf Scheduler: a.) to be "simple way" in to scheduling - that is perfect now, b.) add full-working Scheduling service ( like Quartz ). I was looking at different options, also implemented few. Current gihtub push is like third implementation I did. I was working on one, where I basically rewrote Quartz API -- end up dropping it as at the end I was adding extra code with little benefits -- only benefit being that code was not inside Quartz packages -- but for my specific usecase that also meant I have to rewrite all the existing code -- not something I want. Another thing was, that in current Karaf Scheduler job name is same as tigger name -== trigger is job and vice versa. Well, this is not even close to my usecase, as I have about two or three sometimes even more triggers for one job class, so this is no go for me too. But I guess for some "simple" scheduling tasks existing code is perfect - clean and easy to use. So I would be glad to work on this, but for sure I need some "big picture" puzzles to be put in - where Karaf Scheduler is trying to go. Kind Regards, Miroslav V V tor., 11. sep. 2018 ob 10:38 je oseba Jean-Baptiste Onofré < j...@nanthrax.net> napisala: > Hi, > > So, I propose two actions: > > 1. Let me take a look on the PR and see how we can extend the Karaf > Scheduler API, still with Quartz "hidden" > 2. I think in your case, you can create your own Scheduler using Quartz. > That would gives you complete control if (1) is not fully convenient for > you. I would be more than happy to help on this one. > > Regards > JB > > On 11/09/2018 10:27, Miroslav Beranič wrote: > > Hi JB, > > > > yes, I thought about this - and agree, this change is not all that > > favorable for main-stream Karaf implementation. > > > > I did not look at camel-quartz, will look it up - thanks. > > > > One note though - in my "solution" Karaf imports Quartz, not exports, but > > either way, I know what you mean. > > > > Regards, > > Miroslav > > > > > > > > V V tor., 11. sep. 2018 ob 10:19 je oseba Jean-Baptiste Onofré < > > j...@nanthrax.net> napisala: > > > >> Hi, > >> > >> I don't think this approach is the good one. > >> > >> Quartz is an implementation of the Karaf Scheduler, but we can imagine > >> other implementations. > >> > >> That's why the Quartz packages are not directly exported by the Karaf > >> Scheduler (it's private package). That's really my main concern: Karaf > >> scheduler should not export or be tight to Quartz. > >> > >> If you want to create your own scheduler, than you can directly use the > >> Quartz bundle, like camel-quartz for instance. > >> Is it not what you need ? > >> > >> On the other hand, I think we can improve/extend the Karaf scheduler > >> API. I already changed it in Karaf 4.2.x but I think we can move forward > >> on this. > >> > >> Regards > >> JB > >> > >> On 11/09/2018 09:09, Miroslav Beranič wrote: > >>> Hi guys, > >>> > >>> I am porting multiple existing production backend/middlware systems > from > >>> Tomcat/JBoss to Karaf. > >>> > >>> At first I had issues with JPA+Hibernate, seems to be work now. Now I > >> have > >>> task to migrate existing Quartz 1.8.x code to 2.2.x. At first look I > >>> thought all is done in Karaf, also Quartz was a dependency - and > example > >>> looked really simple. > >>> > >>> Here I do not know what is a common guideline in Karaf : Is it good to > >>> support "native" API or is more in favor to implement "common" API. My > >>> decision was, to move to support native Quartz API , as it is really > >> "well > >>> done" and has all and more any one should need. > >>> > >>> So here I will explain why I've decided to update Scheduler service and > >> how > >>> ( in general ) I did it. I am working on last few changes, before I > push > >> to > >>> forked github repository. > >>> Repository & branch is already online and anyone can check it out, but > it > >>> is not final - I have few more errors needed to be fixed. > >> Repository > >>> location is: > >>> > >>> https://github.com/mibesis/karaf/tree/karaf-4.2.2-scheduler-quartz-api > >>> > >>> What I've changed: > >>> > >>> 1.) in existing scheduler/pom.xml I've changed so no Quartz package is > >>> private package - stored inside a Scheduler bundle, but all Quartz > >>> dependencies are pulled from existing ServiceMix Quartz bundle: > >>> > >>> > >> >
Re: Scheduler Service to support/expose native Quartz
Hi,
So, I propose two actions:
1. Let me take a look on the PR and see how we can extend the Karaf
Scheduler API, still with Quartz "hidden"
2. I think in your case, you can create your own Scheduler using Quartz.
That would gives you complete control if (1) is not fully convenient for
you. I would be more than happy to help on this one.
Regards
JB
On 11/09/2018 10:27, Miroslav Beranič wrote:
> Hi JB,
>
> yes, I thought about this - and agree, this change is not all that
> favorable for main-stream Karaf implementation.
>
> I did not look at camel-quartz, will look it up - thanks.
>
> One note though - in my "solution" Karaf imports Quartz, not exports, but
> either way, I know what you mean.
>
> Regards,
> Miroslav
>
>
>
> V V tor., 11. sep. 2018 ob 10:19 je oseba Jean-Baptiste Onofré <
> j...@nanthrax.net> napisala:
>
>> Hi,
>>
>> I don't think this approach is the good one.
>>
>> Quartz is an implementation of the Karaf Scheduler, but we can imagine
>> other implementations.
>>
>> That's why the Quartz packages are not directly exported by the Karaf
>> Scheduler (it's private package). That's really my main concern: Karaf
>> scheduler should not export or be tight to Quartz.
>>
>> If you want to create your own scheduler, than you can directly use the
>> Quartz bundle, like camel-quartz for instance.
>> Is it not what you need ?
>>
>> On the other hand, I think we can improve/extend the Karaf scheduler
>> API. I already changed it in Karaf 4.2.x but I think we can move forward
>> on this.
>>
>> Regards
>> JB
>>
>> On 11/09/2018 09:09, Miroslav Beranič wrote:
>>> Hi guys,
>>>
>>> I am porting multiple existing production backend/middlware systems from
>>> Tomcat/JBoss to Karaf.
>>>
>>> At first I had issues with JPA+Hibernate, seems to be work now. Now I
>> have
>>> task to migrate existing Quartz 1.8.x code to 2.2.x. At first look I
>>> thought all is done in Karaf, also Quartz was a dependency - and example
>>> looked really simple.
>>>
>>> Here I do not know what is a common guideline in Karaf : Is it good to
>>> support "native" API or is more in favor to implement "common" API. My
>>> decision was, to move to support native Quartz API , as it is really
>> "well
>>> done" and has all and more any one should need.
>>>
>>> So here I will explain why I've decided to update Scheduler service and
>> how
>>> ( in general ) I did it. I am working on last few changes, before I push
>> to
>>> forked github repository.
>>> Repository & branch is already online and anyone can check it out, but it
>>> is not final - I have few more errors needed to be fixed.
>> Repository
>>> location is:
>>>
>>> https://github.com/mibesis/karaf/tree/karaf-4.2.2-scheduler-quartz-api
>>>
>>> What I've changed:
>>>
>>> 1.) in existing scheduler/pom.xml I've changed so no Quartz package is
>>> private package - stored inside a Scheduler bundle, but all Quartz
>>> dependencies are pulled from existing ServiceMix Quartz bundle:
>>>
>>>
>> mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.quartz/2.2.4-SNAPSHOT
>>>
>>> 2.) I extracted interfaces for QuartzScheduler ( Karaf's Scheduler Quartz
>>> wrapper ) so it can be exposed, also for other exposed classes.
>>>
>>> 3.) Exporting all the packages inside Scheduler bundle. This is not
>>> something I am really happy about, but when I was trying to go around
>> this,
>>> I had more problems than benefits.
>>>
>>> 4.) Made all data passed to "datamap" as Serializable, as Quartz as RAM
>>> Storage most of the time only for fun, I guess most of the real usage is
>>> using some kind of persistence - SQL DB - as this is also my case, I had
>> to
>>> support this.
>>>
>>> 5.) I bypass almost all existing "wrapping" code as this introduced
>>> complexity at only additional cost -- when I talk about support for
>> "native
>>> Quartz API".
>>>
>>> So now I can write Quartz producer as :
>>>
>>> @Component
>>> public class KarafSchedulerQuartzJobProducer {
>>>
>>> private final Logger log = LoggerFactory.getLogger(getClass());
>>>
>>> @Reference
>>> private Scheduler scheduler;
>>>
>>> @Activate
>>> public void start() {
>>> JobDataMap data = new JobDataMap();
>>> data.put("message", "Hello Karaf user from Quartz Job.");
>>> final QuartzScheduler quartzScheduler =
>>> (QuartzScheduler)this.scheduler;
>>> JobDetail job =
>>> JobBuilder.newJob(KarafSchedulerComplexJobService.class)
>>> .withIdentity("KarafSchedulerComplexJobService",
>>> "NativeQuartz")
>>> .usingJobData(data)
>>> .build();
>>>
>>> Date runTime = DateBuilder.evenMinuteDate(new Date());
>>>
>>> // Trigger the job to run on the next round minute
>>> Trigger trigger = TriggerBuilder.newTrigger()
>>> .withIdentity("KarafSchedulerComplexJobServiceTrigger",
>>> "NativeQuartz")
>>> .startAt(runTime)
>>>
Re: Scheduler Service to support/expose native Quartz
Hi JB,
yes, I thought about this - and agree, this change is not all that
favorable for main-stream Karaf implementation.
I did not look at camel-quartz, will look it up - thanks.
One note though - in my "solution" Karaf imports Quartz, not exports, but
either way, I know what you mean.
Regards,
Miroslav
V V tor., 11. sep. 2018 ob 10:19 je oseba Jean-Baptiste Onofré <
j...@nanthrax.net> napisala:
> Hi,
>
> I don't think this approach is the good one.
>
> Quartz is an implementation of the Karaf Scheduler, but we can imagine
> other implementations.
>
> That's why the Quartz packages are not directly exported by the Karaf
> Scheduler (it's private package). That's really my main concern: Karaf
> scheduler should not export or be tight to Quartz.
>
> If you want to create your own scheduler, than you can directly use the
> Quartz bundle, like camel-quartz for instance.
> Is it not what you need ?
>
> On the other hand, I think we can improve/extend the Karaf scheduler
> API. I already changed it in Karaf 4.2.x but I think we can move forward
> on this.
>
> Regards
> JB
>
> On 11/09/2018 09:09, Miroslav Beranič wrote:
> > Hi guys,
> >
> > I am porting multiple existing production backend/middlware systems from
> > Tomcat/JBoss to Karaf.
> >
> > At first I had issues with JPA+Hibernate, seems to be work now. Now I
> have
> > task to migrate existing Quartz 1.8.x code to 2.2.x. At first look I
> > thought all is done in Karaf, also Quartz was a dependency - and example
> > looked really simple.
> >
> > Here I do not know what is a common guideline in Karaf : Is it good to
> > support "native" API or is more in favor to implement "common" API. My
> > decision was, to move to support native Quartz API , as it is really
> "well
> > done" and has all and more any one should need.
> >
> > So here I will explain why I've decided to update Scheduler service and
> how
> > ( in general ) I did it. I am working on last few changes, before I push
> to
> > forked github repository.
> > Repository & branch is already online and anyone can check it out, but it
> > is not final - I have few more errors needed to be fixed.
> Repository
> > location is:
> >
> > https://github.com/mibesis/karaf/tree/karaf-4.2.2-scheduler-quartz-api
> >
> > What I've changed:
> >
> > 1.) in existing scheduler/pom.xml I've changed so no Quartz package is
> > private package - stored inside a Scheduler bundle, but all Quartz
> > dependencies are pulled from existing ServiceMix Quartz bundle:
> >
> >
> mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.quartz/2.2.4-SNAPSHOT
> >
> > 2.) I extracted interfaces for QuartzScheduler ( Karaf's Scheduler Quartz
> > wrapper ) so it can be exposed, also for other exposed classes.
> >
> > 3.) Exporting all the packages inside Scheduler bundle. This is not
> > something I am really happy about, but when I was trying to go around
> this,
> > I had more problems than benefits.
> >
> > 4.) Made all data passed to "datamap" as Serializable, as Quartz as RAM
> > Storage most of the time only for fun, I guess most of the real usage is
> > using some kind of persistence - SQL DB - as this is also my case, I had
> to
> > support this.
> >
> > 5.) I bypass almost all existing "wrapping" code as this introduced
> > complexity at only additional cost -- when I talk about support for
> "native
> > Quartz API".
> >
> > So now I can write Quartz producer as :
> >
> > @Component
> > public class KarafSchedulerQuartzJobProducer {
> >
> > private final Logger log = LoggerFactory.getLogger(getClass());
> >
> > @Reference
> > private Scheduler scheduler;
> >
> > @Activate
> > public void start() {
> > JobDataMap data = new JobDataMap();
> > data.put("message", "Hello Karaf user from Quartz Job.");
> > final QuartzScheduler quartzScheduler =
> > (QuartzScheduler)this.scheduler;
> > JobDetail job =
> > JobBuilder.newJob(KarafSchedulerComplexJobService.class)
> > .withIdentity("KarafSchedulerComplexJobService",
> > "NativeQuartz")
> > .usingJobData(data)
> > .build();
> >
> > Date runTime = DateBuilder.evenMinuteDate(new Date());
> >
> > // Trigger the job to run on the next round minute
> > Trigger trigger = TriggerBuilder.newTrigger()
> > .withIdentity("KarafSchedulerComplexJobServiceTrigger",
> > "NativeQuartz")
> > .startAt(runTime)
> > .withSchedule(sb.withIntervalInMilliseconds(period *
> 1000))
> > .build();
> >
> > try {
> > quartzScheduler.scheduleJob(job, trigger);
> > } catch (Exception e) {
> > log.warn(e.getLocalizedMessage(), e);
> > }
> > }
> > }
> >
> > and Quartz job as any already existing Quartz job -- without any change
> to
> > existing code:
> >
> > import org.quartz.Job;
> > public class KarafSchedulerComplexJobService implements Job {
> >
> >
Re: Scheduler Service to support/expose native Quartz
Hi,
I don't think this approach is the good one.
Quartz is an implementation of the Karaf Scheduler, but we can imagine
other implementations.
That's why the Quartz packages are not directly exported by the Karaf
Scheduler (it's private package). That's really my main concern: Karaf
scheduler should not export or be tight to Quartz.
If you want to create your own scheduler, than you can directly use the
Quartz bundle, like camel-quartz for instance.
Is it not what you need ?
On the other hand, I think we can improve/extend the Karaf scheduler
API. I already changed it in Karaf 4.2.x but I think we can move forward
on this.
Regards
JB
On 11/09/2018 09:09, Miroslav Beranič wrote:
> Hi guys,
>
> I am porting multiple existing production backend/middlware systems from
> Tomcat/JBoss to Karaf.
>
> At first I had issues with JPA+Hibernate, seems to be work now. Now I have
> task to migrate existing Quartz 1.8.x code to 2.2.x. At first look I
> thought all is done in Karaf, also Quartz was a dependency - and example
> looked really simple.
>
> Here I do not know what is a common guideline in Karaf : Is it good to
> support "native" API or is more in favor to implement "common" API. My
> decision was, to move to support native Quartz API , as it is really "well
> done" and has all and more any one should need.
>
> So here I will explain why I've decided to update Scheduler service and how
> ( in general ) I did it. I am working on last few changes, before I push to
> forked github repository.
> Repository & branch is already online and anyone can check it out, but it
> is not final - I have few more errors needed to be fixed. Repository
> location is:
>
> https://github.com/mibesis/karaf/tree/karaf-4.2.2-scheduler-quartz-api
>
> What I've changed:
>
> 1.) in existing scheduler/pom.xml I've changed so no Quartz package is
> private package - stored inside a Scheduler bundle, but all Quartz
> dependencies are pulled from existing ServiceMix Quartz bundle:
>
> mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.quartz/2.2.4-SNAPSHOT
>
> 2.) I extracted interfaces for QuartzScheduler ( Karaf's Scheduler Quartz
> wrapper ) so it can be exposed, also for other exposed classes.
>
> 3.) Exporting all the packages inside Scheduler bundle. This is not
> something I am really happy about, but when I was trying to go around this,
> I had more problems than benefits.
>
> 4.) Made all data passed to "datamap" as Serializable, as Quartz as RAM
> Storage most of the time only for fun, I guess most of the real usage is
> using some kind of persistence - SQL DB - as this is also my case, I had to
> support this.
>
> 5.) I bypass almost all existing "wrapping" code as this introduced
> complexity at only additional cost -- when I talk about support for "native
> Quartz API".
>
> So now I can write Quartz producer as :
>
> @Component
> public class KarafSchedulerQuartzJobProducer {
>
> private final Logger log = LoggerFactory.getLogger(getClass());
>
> @Reference
> private Scheduler scheduler;
>
> @Activate
> public void start() {
> JobDataMap data = new JobDataMap();
> data.put("message", "Hello Karaf user from Quartz Job.");
> final QuartzScheduler quartzScheduler =
> (QuartzScheduler)this.scheduler;
> JobDetail job =
> JobBuilder.newJob(KarafSchedulerComplexJobService.class)
> .withIdentity("KarafSchedulerComplexJobService",
> "NativeQuartz")
> .usingJobData(data)
> .build();
>
> Date runTime = DateBuilder.evenMinuteDate(new Date());
>
> // Trigger the job to run on the next round minute
> Trigger trigger = TriggerBuilder.newTrigger()
> .withIdentity("KarafSchedulerComplexJobServiceTrigger",
> "NativeQuartz")
> .startAt(runTime)
> .withSchedule(sb.withIntervalInMilliseconds(period * 1000))
> .build();
>
> try {
> quartzScheduler.scheduleJob(job, trigger);
> } catch (Exception e) {
> log.warn(e.getLocalizedMessage(), e);
> }
> }
> }
>
> and Quartz job as any already existing Quartz job -- without any change to
> existing code:
>
> import org.quartz.Job;
> public class KarafSchedulerComplexJobService implements Job {
>
> private final Logger log = LoggerFactory.getLogger(getClass());
>
> public KarafSchedulerComplexJobService() {
> super();
> }
>
> @Override
> public void execute(final JobExecutionContext context) {
> final JobDataMap jobDataMap =
> context.getJobDetail().getJobDataMap();
>
> message = jobDataMap.getString("message");
> log.info(message);
>
> }
>
> }
>
> So to me this is great solution , as I can now quite easy migrate existing
> source. What I am asking now is: how good solution would this be for Karaf
> - as this makes Scheduler service "bound" to Quartz API, but this is only
Scheduler Service to support/expose native Quartz
Hi guys,
I am porting multiple existing production backend/middlware systems from
Tomcat/JBoss to Karaf.
At first I had issues with JPA+Hibernate, seems to be work now. Now I have
task to migrate existing Quartz 1.8.x code to 2.2.x. At first look I
thought all is done in Karaf, also Quartz was a dependency - and example
looked really simple.
Here I do not know what is a common guideline in Karaf : Is it good to
support "native" API or is more in favor to implement "common" API. My
decision was, to move to support native Quartz API , as it is really "well
done" and has all and more any one should need.
So here I will explain why I've decided to update Scheduler service and how
( in general ) I did it. I am working on last few changes, before I push to
forked github repository.
Repository & branch is already online and anyone can check it out, but it
is not final - I have few more errors needed to be fixed. Repository
location is:
https://github.com/mibesis/karaf/tree/karaf-4.2.2-scheduler-quartz-api
What I've changed:
1.) in existing scheduler/pom.xml I've changed so no Quartz package is
private package - stored inside a Scheduler bundle, but all Quartz
dependencies are pulled from existing ServiceMix Quartz bundle:
mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.quartz/2.2.4-SNAPSHOT
2.) I extracted interfaces for QuartzScheduler ( Karaf's Scheduler Quartz
wrapper ) so it can be exposed, also for other exposed classes.
3.) Exporting all the packages inside Scheduler bundle. This is not
something I am really happy about, but when I was trying to go around this,
I had more problems than benefits.
4.) Made all data passed to "datamap" as Serializable, as Quartz as RAM
Storage most of the time only for fun, I guess most of the real usage is
using some kind of persistence - SQL DB - as this is also my case, I had to
support this.
5.) I bypass almost all existing "wrapping" code as this introduced
complexity at only additional cost -- when I talk about support for "native
Quartz API".
So now I can write Quartz producer as :
@Component
public class KarafSchedulerQuartzJobProducer {
private final Logger log = LoggerFactory.getLogger(getClass());
@Reference
private Scheduler scheduler;
@Activate
public void start() {
JobDataMap data = new JobDataMap();
data.put("message", "Hello Karaf user from Quartz Job.");
final QuartzScheduler quartzScheduler =
(QuartzScheduler)this.scheduler;
JobDetail job =
JobBuilder.newJob(KarafSchedulerComplexJobService.class)
.withIdentity("KarafSchedulerComplexJobService",
"NativeQuartz")
.usingJobData(data)
.build();
Date runTime = DateBuilder.evenMinuteDate(new Date());
// Trigger the job to run on the next round minute
Trigger trigger = TriggerBuilder.newTrigger()
.withIdentity("KarafSchedulerComplexJobServiceTrigger",
"NativeQuartz")
.startAt(runTime)
.withSchedule(sb.withIntervalInMilliseconds(period * 1000))
.build();
try {
quartzScheduler.scheduleJob(job, trigger);
} catch (Exception e) {
log.warn(e.getLocalizedMessage(), e);
}
}
}
and Quartz job as any already existing Quartz job -- without any change to
existing code:
import org.quartz.Job;
public class KarafSchedulerComplexJobService implements Job {
private final Logger log = LoggerFactory.getLogger(getClass());
public KarafSchedulerComplexJobService() {
super();
}
@Override
public void execute(final JobExecutionContext context) {
final JobDataMap jobDataMap =
context.getJobDetail().getJobDataMap();
message = jobDataMap.getString("message");
log.info(message);
}
}
So to me this is great solution , as I can now quite easy migrate existing
source. What I am asking now is: how good solution would this be for Karaf
- as this makes Scheduler service "bound" to Quartz API, but this is only
if you need it -- all existing API is still working and was not changes -
API not, but in the section where data is passed to Quartz any
non-serializable data was moved to temporary storage and than before
calling Runnable task re-attached back again, so producer and consumer do
not really know for any change.
But all is not all that good, at it might seem. To me this perfect
solution, but I know it can be made better - more robust/general.
What are the problems:
1.) Quartz is loading classes - so it needs to know where they are. I
needed quite some time, knocks at the wall and coffee cups to figure this
out. ( I am not OSGi expert ). So my solution was, to agree on a common
package, where all Quartz Jobs must be. To me this is issue, but issue I
can handle - for now.
Package I've decided for is: org.apache.karaf.scheduler.quartz.job
a.) To make this work, I have to update ServiceMix Quartz bundle:
