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é < > [email protected]> 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&branch >>> 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: >>> >> mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.quartz/2.2.4-SNAPSHOT >>> was updated to import package org.apache.karaf.scheduler.quartz.job >>> >>> b.) Karaf Scheduler Core imports package >>> org.apache.karaf.scheduler.quartz.job >>> >>> c.) Quartz producer exports org.apache.karaf.scheduler.quartz.job - but I >>> also scan for sub-packages, so I guess jobs should be in sub-packages, to >>> avoid conflicts. >>> >>> This is one part of my changes, I would really like better one, but for >>> what I need, this is ok -- and after all the headaches I am quite happy >>> with this. >>> >>> Example code is located at: >>> >> https://github.com/mibesis/karaf/tree/karaf-4.2.2-scheduler-quartz-api/examples/karaf-scheduler-example/karaf-scheduler-example-quartz >>> >>> but ( again ) this is not yet final commit, as I have few more errors to >>> fix, but I think not a show stoppers ( I hope ). >>> >>> So my final thoughts/questions: >>> >>> 1.) Is such a change welcome at Karaf - is this something that would >>> benefit Karaf? >>> >>> 2.) Is there any other existing solution, I should know of? >>> >>> 3.) How can I implement "dynamic" package - so that Quartz job can be in >>> any package, but just pre-defined ones. >>> >>> Kind regards, >>> Miroslav >>> >>> >> >> -- >> Jean-Baptiste Onofré >> [email protected] >> http://blog.nanthrax.net >> Talend - http://www.talend.com >> > > -- Jean-Baptiste Onofré [email protected] http://blog.nanthrax.net Talend - http://www.talend.com
