Re: provide a default Scheduler which is not using quartz as default?

[Romain Manni-Bucau]

@Mark: here cause tomee already has ee concurrency utilities which could be
used to impl @Schedule(persistent=false) - just no will/need yet.

Le 5 janv. 2018 20:10, "John D. Ament"  a écrit :

> On Fri, Jan 5, 2018 at 2:00 PM John D. Ament 
> wrote:
>
> > On Fri, Jan 5, 2018 at 1:21 PM Mark Struberg 
> > wrote:
> >
> >> > Shouldnąt we just disable the update check in our quartz
> configuration?
> >>
> >> Well there is a flag to disable this behaviour, but a.) it's hard to set
> >> (requires -D) and it doesn't disable 100%.
> >> The code still does some http calls out :/
> >>
> >
> > You can disable it programmatically.  I've done wireshark checks, there
> is
> > no other HTTP calls made out.  Here's a quick patch that does it:
> >
> >
> > https://github.com/johnament/deltaspike/commit/
> 5a4fec98ff3f8f6ed6b54c36332bb8621cd3b09d
> >
>
> Here's a more interesting thing, looks like for Quartz 2.3 they changed
> from an opt out to an opt in -
> https://github.com/quartz-scheduler/quartz/commit/
> dfe1e5a3cc248e2a46a6ea55567aaa6dc8e15ca5
>
> John
>
>
> >
> >
> > John
> >
> >
> >>
> >> That's really bad, and the terracotta community (or rather the firm
> >> behind it) declined to disable it by default since 2010 :/
> >>
> >> @Tomas, yes there is additional effort to maintain it. But imo it's
> worth
> >> it.
> >>
> >> @Romain, John the question for me is rather where we do like to keep the
> >> code.
> >> Either here in DeltaSpike or at geronimo? The reason is that we might
> >> also later use this in other projects (TomEE) as well.
> >>
> >> For now I'd just start to play a bit with it over here and then we can
> >> still move it around later.
> >>
> >> LieGrue,
> >> strub
> >>
> >>
> >> > Am 05.01.2018 um 17:44 schrieb Arne Limburg <
> >> arne.limb...@openknowledge.de>:
> >> >
> >> > Hi Mark,
> >> >
> >> > Shouldnąt we just disable the update check in our quartz
> configuration?
> >> >
> >> > Cheers,
> >> > Arne
> >> >
> >> >
> >> > Am 05.01.18 17:39 schrieb "Mark Struberg" unter
> >> > :
> >> >
> >> >> Hi folks!
> >> >> Since I've now had a few complaints about Quartz 'phoning home'
> >> (totally
> >> >> useless update check), I'm really inclined to just kick out quartz
> and
> >> >> implement the Scheduler ourselves.
> >> >> Implementing a proper Scheduler is not that complicated anyway, so do
> >> we
> >> >> like to roll this ourselves?
> >> >> Or do you think I underestimate the effort?
> >> >>
> >> >> LieGrue,strub
> >> >
> >>
> >>
>

Re: provide a default Scheduler which is not using quartz as default?

[John D. Ament]

On Fri, Jan 5, 2018 at 2:00 PM John D. Ament  wrote:

> On Fri, Jan 5, 2018 at 1:21 PM Mark Struberg 
> wrote:
>
>> > Shouldnąt we just disable the update check in our quartz configuration?
>>
>> Well there is a flag to disable this behaviour, but a.) it's hard to set
>> (requires -D) and it doesn't disable 100%.
>> The code still does some http calls out :/
>>
>
> You can disable it programmatically.  I've done wireshark checks, there is
> no other HTTP calls made out.  Here's a quick patch that does it:
>
>
> https://github.com/johnament/deltaspike/commit/5a4fec98ff3f8f6ed6b54c36332bb8621cd3b09d
>

Here's a more interesting thing, looks like for Quartz 2.3 they changed
from an opt out to an opt in -
https://github.com/quartz-scheduler/quartz/commit/dfe1e5a3cc248e2a46a6ea55567aaa6dc8e15ca5

John


>
>
> John
>
>
>>
>> That's really bad, and the terracotta community (or rather the firm
>> behind it) declined to disable it by default since 2010 :/
>>
>> @Tomas, yes there is additional effort to maintain it. But imo it's worth
>> it.
>>
>> @Romain, John the question for me is rather where we do like to keep the
>> code.
>> Either here in DeltaSpike or at geronimo? The reason is that we might
>> also later use this in other projects (TomEE) as well.
>>
>> For now I'd just start to play a bit with it over here and then we can
>> still move it around later.
>>
>> LieGrue,
>> strub
>>
>>
>> > Am 05.01.2018 um 17:44 schrieb Arne Limburg <
>> arne.limb...@openknowledge.de>:
>> >
>> > Hi Mark,
>> >
>> > Shouldnąt we just disable the update check in our quartz configuration?
>> >
>> > Cheers,
>> > Arne
>> >
>> >
>> > Am 05.01.18 17:39 schrieb "Mark Struberg" unter
>> > :
>> >
>> >> Hi folks!
>> >> Since I've now had a few complaints about Quartz 'phoning home'
>> (totally
>> >> useless update check), I'm really inclined to just kick out quartz and
>> >> implement the Scheduler ourselves.
>> >> Implementing a proper Scheduler is not that complicated anyway, so do
>> we
>> >> like to roll this ourselves?
>> >> Or do you think I underestimate the effort?
>> >>
>> >> LieGrue,strub
>> >
>>
>>

Re: provide a default Scheduler which is not using quartz as default?

[John D. Ament]

On Fri, Jan 5, 2018 at 1:21 PM Mark Struberg 
wrote:

> > Shouldnąt we just disable the update check in our quartz configuration?
>
> Well there is a flag to disable this behaviour, but a.) it's hard to set
> (requires -D) and it doesn't disable 100%.
> The code still does some http calls out :/
>

You can disable it programmatically.  I've done wireshark checks, there is
no other HTTP calls made out.  Here's a quick patch that does it:

https://github.com/johnament/deltaspike/commit/5a4fec98ff3f8f6ed6b54c36332bb8621cd3b09d

John


>
> That's really bad, and the terracotta community (or rather the firm behind
> it) declined to disable it by default since 2010 :/
>
> @Tomas, yes there is additional effort to maintain it. But imo it's worth
> it.
>
> @Romain, John the question for me is rather where we do like to keep the
> code.
> Either here in DeltaSpike or at geronimo? The reason is that we might also
> later use this in other projects (TomEE) as well.
>
> For now I'd just start to play a bit with it over here and then we can
> still move it around later.
>
> LieGrue,
> strub
>
>
> > Am 05.01.2018 um 17:44 schrieb Arne Limburg <
> arne.limb...@openknowledge.de>:
> >
> > Hi Mark,
> >
> > Shouldnąt we just disable the update check in our quartz configuration?
> >
> > Cheers,
> > Arne
> >
> >
> > Am 05.01.18 17:39 schrieb "Mark Struberg" unter
> > :
> >
> >> Hi folks!
> >> Since I've now had a few complaints about Quartz 'phoning home' (totally
> >> useless update check), I'm really inclined to just kick out quartz and
> >> implement the Scheduler ourselves.
> >> Implementing a proper Scheduler is not that complicated anyway, so do we
> >> like to roll this ourselves?
> >> Or do you think I underestimate the effort?
> >>
> >> LieGrue,strub
> >
>
>

Re: provide a default Scheduler which is not using quartz as default?

[Mark Struberg]

> Shouldnąt we just disable the update check in our quartz configuration?

Well there is a flag to disable this behaviour, but a.) it's hard to set 
(requires -D) and it doesn't disable 100%. 
The code still does some http calls out :/

That's really bad, and the terracotta community (or rather the firm behind it) 
declined to disable it by default since 2010 :/

@Tomas, yes there is additional effort to maintain it. But imo it's worth it.

@Romain, John the question for me is rather where we do like to keep the code. 
Either here in DeltaSpike or at geronimo? The reason is that we might also 
later use this in other projects (TomEE) as well.

For now I'd just start to play a bit with it over here and then we can still 
move it around later.

LieGrue,
strub


> Am 05.01.2018 um 17:44 schrieb Arne Limburg :
> 
> Hi Mark,
> 
> Shouldnąt we just disable the update check in our quartz configuration?
> 
> Cheers,
> Arne
> 
> 
> Am 05.01.18 17:39 schrieb "Mark Struberg" unter
> :
> 
>> Hi folks!
>> Since I've now had a few complaints about Quartz 'phoning home' (totally
>> useless update check), I'm really inclined to just kick out quartz and
>> implement the Scheduler ourselves.
>> Implementing a proper Scheduler is not that complicated anyway, so do we
>> like to roll this ourselves?
>> Or do you think I underestimate the effort?
>> 
>> LieGrue,strub
> 

Re: provide a default Scheduler which is not using quartz as default?

[John D. Ament]

-0

There's already so many solutions around scheduling.  It makes sense to
disable it out of the box using configuration, as well as documenting it
for users.  I'm not sure how well maintained quartz is.

John

On Fri, Jan 5, 2018 at 11:39 AM Mark Struberg 
wrote:

> Hi folks!
> Since I've now had a few complaints about Quartz 'phoning home' (totally
> useless update check), I'm really inclined to just kick out quartz and
> implement the Scheduler ourselves.
> Implementing a proper Scheduler is not that complicated anyway, so do we
> like to roll this ourselves?
> Or do you think I underestimate the effort?
>
> LieGrue,strub
>

Re: provide a default Scheduler which is not using quartz as default?

[Thomas Andraschko]

+0.5
Of course it would be great to get rid of the quartz dependency per default
but not sure...
It's still effort and we have to maintain it...

2018-01-05 17:44 GMT+01:00 Arne Limburg :

> Hi Mark,
>
> Shouldn¹t we just disable the update check in our quartz configuration?
>
> Cheers,
> Arne
>
>
> Am 05.01.18 17:39 schrieb "Mark Struberg" unter
> :
>
> >Hi folks!
> >Since I've now had a few complaints about Quartz 'phoning home' (totally
> >useless update check), I'm really inclined to just kick out quartz and
> >implement the Scheduler ourselves.
> >Implementing a proper Scheduler is not that complicated anyway, so do we
> >like to roll this ourselves?
> >Or do you think I underestimate the effort?
> >
> >LieGrue,strub
>
>

Re: provide a default Scheduler which is not using quartz as default?

[Arne Limburg]

Hi Mark,

Shouldn¹t we just disable the update check in our quartz configuration?

Cheers,
Arne


Am 05.01.18 17:39 schrieb "Mark Struberg" unter
:

>Hi folks!
>Since I've now had a few complaints about Quartz 'phoning home' (totally
>useless update check), I'm really inclined to just kick out quartz and
>implement the Scheduler ourselves.
>Implementing a proper Scheduler is not that complicated anyway, so do we
>like to roll this ourselves?
>Or do you think I underestimate the effort?
>
>LieGrue,strub

Re: provide a default Scheduler which is not using quartz as default?

[Romain Manni-Bucau]

+100


Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn 

2018-01-05 17:39 GMT+01:00 Mark Struberg :

> Hi folks!
> Since I've now had a few complaints about Quartz 'phoning home' (totally
> useless update check), I'm really inclined to just kick out quartz and
> implement the Scheduler ourselves.
> Implementing a proper Scheduler is not that complicated anyway, so do we
> like to roll this ourselves?
> Or do you think I underestimate the effort?
>
> LieGrue,strub
>

provide a default Scheduler which is not using quartz as default?

[Mark Struberg]

Hi folks!
Since I've now had a few complaints about Quartz 'phoning home' (totally 
useless update check), I'm really inclined to just kick out quartz and 
implement the Scheduler ourselves. 
Implementing a proper Scheduler is not that complicated anyway, so do we like 
to roll this ourselves?
Or do you think I underestimate the effort?

LieGrue,strub